Learning SD-WAN with Cisco: Transform Your Existing WAN Into a Cost-effective Network

© Stuart Fordham 2021

S. FordhamLearning SD-WAN with Cisco https://doi.org/10.1007/978-1-4842-7347-0_1

1. An Introduction to SD-WAN

Stuart Fordham¹  

(1)

Bedfordshire, UK

In this chapter, we are going to look at what SD-WAN is and how it came about.

The Traditional Network

The networks we rely on for both business and pleasure on a day-to-day basis are susceptible to many factors that can result in a slow and unreliable experience.

We can experience latency, which either refers to the time between a data packet being sent and received or the round-trip time, which is the time it takes for the packet to be sent and for it to get a reply, such as when we use ping.

We can also experience jitter, which is the variance in the time delay between data packets in the network, basically a disruption in the sending and receiving of packets.

We have fixed bandwidth networks that can experience congestion: with 5 people sharing the same Internet link, each could experience a stable and swift network, add another 20 or 30 people onto the same link and the experience will be markedly different.

There are ways we can help manage the experience for all. We can implement quality of service (QoS), which we can use to prioritize traffic, such as voice and video, where fluctuations in the network due to these factors are noticeable. We can also use QoS to give each user their fair share of bandwidth and to ensure that the right amount of bandwidth is assured for our mission-critical applications.

QoS works well within the boundaries of the network but requires manual intervention. We need to know what our traffic is, where that traffic needs to go, and what our priority traffic is. We can help it get there faster and with a larger degree of assured delivery, but it still requires the network administrators to ensure that the paths the traffic is to take are present, working, and reliable. QoS, combined with policy-based routing (PBR), can also provide a way to route traffic out of different interfaces, making use of dedicated high-speed links for mission-critical traffic and other links for user traffic such as Internet browsing and media streaming. These do, again, require the network administrator to plan this traffic splitting out, and this method is not exactly dynamic.

There are mechanisms to dynamically route traffic though, such as Multiprotocol Label Switching Traffic Engineering (MPLS-TE). Through the use of MPLS, a link-state protocol such as OSPF or IS-IS, RSVP (Resource Reservation Protocol), and CBR (Constraint-Based Routing), we can have a network that learns about changes in the network and reacts by performing path selection in the network.

MPLS-TE is very much in the realm of large enterprises and ISPs, though, and with it comes increased costs in both infrastructure and engineering.

Today, we are, however, deep into cloud adoption, where pretty much everything can now be offered As a Service. Platform, infrastructure, and software are all deployable at a click of a button, and whole virtual data centers can be stood up in minutes. Names such as Microsoft Azure, Amazon Web Services (AWS), and Google Cloud are so embedded in 21st-century technology that it is fast approaching the time where we will soon not even begin to comprehend how we managed before the cloud.

So how do we marry up the needs of today’s cloud computing, the benefits of QoS, and MPLS-TE as well as the dynamism we need for modern networks, while, at the same time, increasing security, reducing costs, and having a technology that is easy to use? These seem like a lot of contradictory criteria to fulfil.

The answer is SD-WAN, or software-defined networking in a wide area network.

SD-WAN

SD-WAN has taken the concept of software-defined networking (within a local area network) and cloud orchestration and applied it to the wide area network.

There are, according to Gartner,¹ four requirements for an SD-WAN:

It must have the ability to support multiple connection types.

It should be able to perform dynamic path selection.

It should have the ability to support VPNs and third-party services (such as firewalls).

It must have a simple interface.

It is not just Gartner that has put these requirements on paper. This is also the standard defined by MEF (which once stood for the Metro Ethernet Forum) in MEF 70. MEF is an international industry consortium that looks to promote the adoption of assured and orchestrated connectivity services across automated networks. Members of MEF include Cisco, Ericsson, Huawei, Juniper, Nokia Networks, VMWare, and more companies with telecommunications or telecom in their names than you can shake a stick at.

MEF 70² is not the easiest document to understand. It uses many TLAs (three-letter acronyms) and contains nuggets like this:

MEF Services, such as SD-WAN, are specified using Service Attributes. A Service Attribute captures specific information that is agreed on between the Service Provider and the Subscriber of a MEF Service, and it describes some aspect of the service behavior.

Got that? Great, neither did I. However, if we take an SD-WAN deployment from a more practical angle and put it into some context, it does start to make sense. I will try to translate as we go through the various components.

We start with the SD-WAN edge device. These devices can either be physical ones or virtual appliances. The SD-WAN edge devices need to support multiple connection types, such as MPLS, Internet such as leased lines, and LTE. The edge device is "situated between the SD-WAN UNI, on its Subscriber side, and UCS UNIs of one or more Underlay Connectivity Services on its network side," meaning that these devices live at the demarcation point between the business network (Customer Premises) and the ISP, the SD-WAN UNI (User Network Interface), and the Underlay Connectivity Service (UCS), or the Internet circuit.

Because we have an underlay service, it makes sense that we also have an overlay. The overlay is the network we are orchestrating, and we do this through the SD-WAN Controller and the SD-WAN Orchestrator; these devices control our policies concerning application flow and security. The overlay needs to be able to understand the network and feed information back to the edge devices so that they may choose the best paths across the network, as well as controlling our VPNs and other services.

So once we start looking at SD-WAN from a practical standpoint, MEF 70 actually starts to make sense.

Cisco, along with Huawei, Nokia Networks, and Verizon, among others, participated in the development of MEF 70, but this was by no means Cisco’s first step into the world of SD-WAN.

Cisco and SD-WAN

Cisco had a product called iWAN (intelligent WAN), which provided traffic control and security and integrated into Cisco branch office routers. It offered QoS, WAN optimization, and VPN tunneling, without the cost of expensive MPLS VPNs.

iWAN made a lot of sense, as with the lowering cost of today’s Internet links, along with the improvement in their SLAs, MPLS is becoming less attractive. iWAN could provide similar capabilities to MPLS VPN, such as WAN optimization, QoS, and VPN tunneling, all without affecting performance, security, or reliability.

The network overlay used by iWAN is DMVPN (Dynamic Multipoint VPN) and IPSec, which enables the use of any carrier service (MPLS, broadband, and 3G/4G/LTE).

Traffic is routed based on metrics such as SLA, endpoint type, and network conditions. This is achieved using PfRv3 (Performance Routing Version 3), which uses differentiated services code points (DSCP) , and an application-based policy framework to optimize bandwidth and path control, protecting applications and increasing bandwidth utilization. PfRv3 looks at the application type, network performance in terms of jitter, packet loss, and delay and can make decisions to forward traffic over the best-performing path.

We can, with iWAN, make networks use MPLS networks for some traffic (e.g., business-critical and VoIP) and other traffic (less critical) use the public Internet, as shown in Figure 1-1.

Figure 1-1

The iWAN network

With PfR, border routers collect traffic and path information, sending it to a master controller (a dedicated router). The master controller is responsible for enforcing the service policies to match the requirements of the application.

Applications are optimized over the WAN using Cisco’s Application Visibility and Control (AVC) and Wide Area Application Services (WAAS). AVC (which includes technologies such as Network-Based Application Recognition 2 [NBAR 2], NetFlow, and QoS) is essential here as many applications use the same ports (such as 443). Spotify, for example, uses a destination port of 4070 for its player, but will use port 443 or even 80 if the former port is unavailable, making the implementation of traffic control on Spotify impossible when based on the destination port. Because of this reuse of ports, we can no longer rely on static port classification, so AVC uses deep packet inspection to identify applications and to monitor their performance. iWAN also leverages Akamai for branch router caching.

iWAN is secured through IPSec encryption, zone-based firewalling, and ACLs (access control lists), protecting the WAN over the public Internet. It also uses Cisco’s Cloud Web Security to provide a proxy to protect users over the Internet and is controlled using the APIC-EM (Application Policy Infrastructure Controller Enterprise Module).

All this sounds great. But why has Cisco rapidly moved to SD-WAN, instead of investing more in its existing product, iWAN?

The simple answer is that while all its benefits made it very attractive, in reality, iWAN was hard to deploy and manage. iWAN is not alone in technologies that have been sidelined, two more of which are PfR and NBAR, which, coincidentally, are two technologies used by iWAN.

The use of APIC-EM, for example, while great for managing iWAN, was only really useful in greenfield deployments. If you already had the building blocks of iWAN in place (DMVPN, QoS, PfR), then rolling out APIC-EM would pretty much require replacing all the existing configurations, which made switching to use the APIC-EM a tough and potentially expensive decision to make.

iWAN is not dead though, far from it. While new customers into the field will be steered toward SD-WAN, the ISR routers that are key to an iWAN deployment hold around 80% of the market share of branch office routers, and each year, Cisco sells around $1.6 billion of ISRs. There is too much invested by Cisco and its customers for iWAN to be ditched completely. However, the focus is now pointed directly at SD-WAN, which has some of the features that iWAN missed, such as an easy-to-use interface, which is, perhaps, why Cisco set its sights on Viptela.

Viptela

Viptela was founded in 2012 by ex-Cisco directors Amir Khan and Khalid Raza. While it was in stealth mode and no one (in the general public) knew what it was doing, it received financial backing from Sequoia Capital. Considering the companies that Sequoia has backed in the past, such as Apple, Google, PayPal, YouTube, Instagram, and WhatsApp, Viptela was probably a surefire winner early on.

Over the next couple of years, Viptela emerged from stealth mode into the taking-the-network-world-by-storm mode. It garnered much praise and many customers. It was named several times in CRN’s 10 Coolest Networking Startups, named a Gartner Cool Vendor and a Next Billion Dollar Startup by Forbes. Not a bad start (for a startup)!

Between 2012 and 2017, Viptela boasted customers such as Verizon, Singtel, and The Gap. Others were used in published case studies but preferred to remain unnamed, which is pretty common in the banking world.

The lure of Viptela is that it offers virtualization of the WAN and is carrier agnostic. Through the WAN overlay technology, communications are secured across whichever medium is used, even broadband and 4G/LTE. Similar to iWAN, in essence, but vastly different in deployment.

The report from clothing retailer The Gap makes for interesting reading and gives the reader a good idea about how and why Viptela was able to make such good ground within such a short amount of time.

The Gap started to roll out SD-WAN in 2015, to alleviate the reliance on the expensive MPLS lines and instead move to the cheaper public Internet. With SD-WAN, they could still do this, as well as keeping the traffic encrypted. Snehal Patel, Gap’s network architect, said that they could connect up to 25 or more of their stores per night. Each upgraded store also had between ten and fifteen times the bandwidth it had previously. SD-WAN was also about 50% less expensive than their original method.

It is easy to see the benefits of Viptela’s SD-WAN. You get the increased speed, at a lower cost, and rolling it out can be done at a very impressive pace.

You can read the original transcript from the Wall Street Journal here: https://web.archive.org/web/20160726182850/http://blogs.wsj.com/cio/2015/11/05/gap-connects-stores-over-the-internet-with-software-defined-networking/.

By 2017, Viptela had 16,000+ branch office deployments and proclaimed on its website the following benefits:

50% lower costs

10x more bandwidth

5x cloud performance

With such stores as The Gap putting their success story in the light, it’s easy to see why Viptela did so well so quickly.

This brand-new network as a service offered seamless integration with Office 365, Azure, and AWS and used a simple interface (especially when compared to iWAN’s APIC-EM). Policies can be used to send latency-sensitive traffic across dedicated MPLS lines and use the regular Internet for less critical applications, such as Office 365, and 4G/LTE for remote office where MPLS or broadband is not an option (Figure 1-2).

Figure 1-2

The Viptela SD-WAN

The difference between Viptela’s fabric and Cisco’s iWAN is in the ease of connectivity into the likes of AWS, Azure, and Office 365, as well as the simplified management (again, compared to APIC-EM).

It is no wonder, therefore, that in 2017, Cisco bought Viptela for $610 million. Viptela aligned perfectly with Cisco’s principles of security, virtualization, automation, and analytics, in their DNA (Digital Network Architecture).

Let’s look at the different components that make up the (Cisco) SD-WAN (or SD-WAN Secure Extensible Network [SEN] as they also term it).

Components of a Cisco SD-WAN

From Figure 1-2, you can see that there are four distinct areas to the SD-WAN. At the bottom, we have the connectivity aspect, the data plane. This can be offices or third-party services such as AWS and Office 365. For this connection, we need an edge device.

vEdge and cEdge

Because of the purchase by Cisco, the Cisco ISR, ASR, and CSR1000v routers are now part of the Viptela ecosystem (subject to running the correct software image); this is in addition to the products already made by