BiB 063: Can An SD-WAN Device Replace A WAN Router?

The following is a transcript of the audio you can hear in the player above.

Welcome to Briefings In Brief, an audio digest of IT news and information from the Packet Pushers, including vendor briefings, industry research, and commentary. (And today we’re going to do a lot of commentary.)

I’m Ethan Banks, it’s November 30, 2018 and here’s what’s going on. I had a briefing with Silver Peak earlier this month. Silver Peak is a software defined WAN company. They make devices and controllers that allow you to manage your wide area network fabric centrally, leveraging a mix of different circuit types, as they take care of security and traffic optimization for you.

In this briefing, Silver Peak offered a current status of their company and a series of deeply technical demos which you can find on YouTube by searching for Silver Peak and Tech Field Day. All of this was in the context of using Silver Peak devices as WAN router replacements. Silver Peak is invested in a marketing campaign to displace Cisco WAN routers. Yep, they called Cisco out specifically.

The campaign is a series of tongue-in-cheek videos built around the character Wayne McFarkus. Wayne is a mullet-wearing 80’s stereotype bearing the not-so-subtle message that routers are old and outdated. Modern networks wouldn’t use something so antiquated as a router. Instead, they’d use a modern solution from, oh I don’t know, Silver Peak.

Replace A WAN Router With An SD-WAN Device?

Let’s examine this assertion from Silver Peak. Is an SD-WAN device able to be a drop-in replacement for a WAN router from Cisco or whomever?

First, we have to back away from the FUD claiming that routers are ancient technology that should be banished along with parachute pants and the mullet. WAN routers are, of course, an integral part of most networks of any size. They tend to have complex configurations for several reasons.

They connect TDM circuits, such as T1s or T3s. These circuit types are still present in many markets particularly in the US, and it takes special cards to support them.

They often sit at the edge of a routing domain, so they might have complicated routing policies.

They tend to represent a chokepoint between high-bandwidth LANs and low-bandwidth WANs, so there’s usually a QoS policy for traffic prioritization and congestion management.

If they are sitting at the Internet edge they might be handling public Internet routing tables and/or announcing routes themselves via BGP.

They are often candidates to be endpoints for tunnels like GRE or IPSEC.

They are frequently used as stateful firewalls, or at least for traffic filtering with access-lists, as they might be governing traffic flows between two or more different organizations.

For organizations requiring multicast, the WAN router needs to be a proper multicast router to avoid dropped traffic or traffic being flooded across WAN links where bandwidth is precious.

For those companies that are rolling out IPv6, the WAN router needs to support data-plane and ideally control-plane v6 functionality. V6 is 20 years old, so you wouldn’t think this is an issue. It’s a huge issue, especially as more organizations are getting serious about bringing the v6 running around their network already under control.

And finally, WAN routers are often asked to participate in network segmentation, using schemes such as VRFs, or in larger organizations, L3VPN over MPLS.

I say all that to raise the point that routers are, for the most part, anything but mullet-wearing 80’s throwbacks. Assuming the appropriate network operating system and licensing, plenty of modern WAN routers can do all of these things. Often, they can do them all at scale with specialized silicon for forwarding and crypto operations.

If I were to stick a mullet on a router, it would be in the area of management. For all the talk of network automation these days, the average fleet of enterprise WAN routers are still managed device by device using the CLI. This approach makes it difficult to maintain configuration parity, changes somewhat risky, and meshed tunnel operations untenable at scale without something like DMVPN phase 3.

Can Silver Peak Replace A WAN Router?

So back to Silver Peak. Are their SD-WAN devices a technically viable router replacement? And if so, is this something you’d want to do?

The short answer is that, for the most part, yes–the Silver Peak SD-WAN solution is a viable router replacement. Silver Peak is one of the leaders in the SD-WAN market. I rank them up there with Cisco Viptela and VMware’s VeloCloud. The Silver Peak solution is full-featured.

I don’t have a sense of how buggy the codebase might be, but Silver Peak has brought Packet Pushers some customers to discuss the solutions they’ve built with the product, and those stories have been both compelling and believable.

Silver Peak also has a history of WAN optimization, and that code lives on as the “Boost” optional feature of their solution, great stuff for increasing packet efficiency and reducing latency over WAN links.

Add to that stateful firewalling, integration with cloud security services such as zScaler, network segmentation, and, of course, centralized policy management, and the Silver Peak story of replacing WAN routers feels plausible. You could do it, at least in many cases.

I’m not going to go through every point I made earlier for the sake of time, but you can at least ask Silver Peak to demo how they measure up and get straightforward answers about routing, QoS, tunneling, stateful firewalling, multicast, v6, and network segmentation. I believe most shops will find the functionality Silver Peak SD-WAN is offering compares adequately with traditional WAN routers from Cisco and others.

But Is Replacing A WAN Router A Good Idea?

But is replacing your old friend the WAN router with an SD-WAN device something you’d want to do? As the old saying goes, just because you can, doesn’t mean you should. Let’s consider some issues.

Anytime you make a significant infrastructure change, there is an operational impact. People need to be trained. New processes need to be developed. A coexistence strategy must be adopted as you transition from legacy to new technology.

You need to understand your routing well. There are strategies for handling the routing issues that come up when operating what amounts to two parallel WANs. But if you assume, “plug and play,” as you turn up SD-WAN nodes, you could be in for a routing loop debacle. Silver Peak should be able to help you with this issue during implementation. They talked about this problem a bit in their presentation. It’s commonly faced by organizations transitioning from legacy WAN to SD-WAN.

You have to consider the circuit types you’re terminating. I could be wrong, but there are no devices from Silver Peak, or most other SD-WAN vendors, that can handle T1-type circuits. That doesn’t mean an SD-WAN device is a no-go, but it does mean you would keep your existing WAN router in place just for the TDM circuit, while moving the rest of the functionality over to the Silver Peak device.

Return on investment must be considered. SD-WAN technology, including Silver Peak, allows you to use public Internet circuits to achieve a similar or even better performing WAN than you have with private, MPLS-based circuits you lease from your carrier. Replacing WAN routers means you can drop support contracts on those devices. Those are good ways to save money, but SD-WAN itself isn’t free, often priced as a monthly subscription. What’s the ROI calculation, especially if you’ve got a WAN router infrastructure that’s been amortized already?

I tend to think most shops will come out ahead by shifting to an SD-WAN solution, and I think the ideal play is to proceed with WAN router replacements where you can. Consolidate the edge in remote offices. Simplify operations. But while the approach is viable, you need to ask Silver Peak hard questions about exactly how you get there.

Do More Research

That was Briefings in Brief from the Packet Pushers. For more IT podcasts, blogs and news created for engineers, visit packetpushers.net where you can subscribe for free. And for even more great information, become a member at ignition.packetpushers.net. When you join Ignition, you support the Packet Pushers directly.