Cisco’s SD-WAN Solution at A Glance

If you’re reading this, you probably already have an idea of what Software-Defined Wide Area Networks or SD-WANs are. You’ll likely also know that SD-WANs deliver interconnectivity between multiple remote sites for a fraction of the cost of other specialized WAN services provided by telcos, such as MPLS or Metro Ethernet. You may even know that SD-WANs can deliver highly advanced network services, such as QoS, SLAs, and carrier-grade levels of redundancy, all using consumer-grade internet connections, such as cable, xDSL, and cellular.

But for many, the implementation of an SD-WAN is still a black box, with its intricate inner workings remaining a mystery. This article will open that black box and shed some light on how an SD-WAN achieves these feats.

In this article, we’ll take a specific look at the anatomy of Cisco’s SD-WAN solution and, in the process, give you a glimpse into the operation of this impressive technology.

Various SD-WAN solutions from Cisco

Cisco has three distinct SD-WAN products:

• Intelligent WAN (iWAN) – This product leverages preexisting technologies and features, such as DMVPN, QoS, Performance Routing (PfR), and wide area application services (WAAS), to deliver SD-WAN services.
• Meraki SD-WAN – Building on Meraki’s strong cloud-based operational model, this solution offers turnkey SD-WAN services on networks using Cisco’s Meraki series of devices.
• Cisco SD-WAN – This is Cisco’s current flagship SD-WAN solution, delivering enterprise-grade SD-WAN services

In typical Cisco fashion, in August of 2017, Cisco acquired Viptela Inc., a privately held SD-WAN company whose product was rebranded as Cisco SD-WAN. It is this solution that we’ll be talking about in this article.

Cisco SD-WAN solution

SD-WAN is not a new technology, but it is vital for today’s enterprises. It delivers high reliability and performance over cheap consumer-grade internet connections, with exceptional interconnectivity between remote sites comparable, and in some cases superior, to the majority of expensive VPN services provided by telcos.

If you want to learn more about SD-WAN in general, take a look at our SD-WAN: The WAN is getting a facelift article.

Cisco SD-WAN components

• Cisco’s SD-WAN consists of various components or entities:
• vManage – the Network Management System (NMS)
• vSmart – The SD controller
• vEdge – The edge routers at the customer premises
• vBond – The orchestrator
• vAnalytics – performance analysis and monitoring

All of the above are mandatory components except for the vAnalytics. These components can be seen in how they inter-operate in the following diagram.

Let’s take a closer look at each of these components and what they do:

vManage

vManage, as its name suggests, is the component from which the SD-WAN solution can be managed and administered. It is essentially the NMS of the entire SD-WAN network. vManage sports a GUI via which configurations and parameters can be set up. vManage can also be accessed using REST APIs, delivering another layer of network automation into the works. Device configurations and network policies are defined and applied at the vManage device, and it is also responsible for alerting network admins in the event of a problem.

vSmart

vSmart is essentially the control plane of the design. It is the entity that communicates directly with the vEdge devices, about which we will speak shortly, to transmit routes, security, and policy information that has been configured in the vManage management system. In other words, vSmart simply implements the policies that have been configured in vManage. vSmart will receive the policy defined in vManage, translate it into specific commands for particular devices on the network and send out those commands to the appropriate devices.

vSmart uses a Cisco proprietary protocol, called Overlay Management Protocol (OMP), to deliver all control plane information to vEdge devices. vSmart lives only in the control plane and plays no role in the data plane.

vBond

This entity is known as the orchestrator. It is responsible for coordinating and authenticating the communication between the vSmart controllers and the vEdge routers. It is the device that must be reachable by all other components, so it should have a public IP address in most implementations. The vBond orchestrator is the first device with which a newly connected vEdge device communicates.

vAnalytics

Out of all the components involved in Cisco’s SD-WAN solution, this is the only one that is optional. However, it is an instrumental component as it enables network and application visibility within the SD-WAN infrastructure. As a result, it can be used for network analysis, forecasting, and giving recommendations about traffic and WAN connections, allowing you to determine if you need to upgrade or downgrade your underlying WAN network.

vEdge

This is the edge device at each physical location interconnected via the SD-WAN infrastructure. It is the device that delivers user traffic and is thus responsible for the data plane. As we’ll see later on, this device can be a compatible physical router of various types or implemented in software as a virtual machine. vEdge devices use Datagram Transport Layer Security (DTLS) connections with the vSmart devices to maintain secure communication, through which the OMP protocol is used to relay control plane information.

Cloud-based or on prem

There’s a lot of flexibility concerning where and how to deploy your devices. The following list shows the deployment options available for each component:

*The hardware options for vEdge include:

• vEdge routers (formerly Viptela vEdge routers) including the 100, 1000, 2000, and 5000 models
• Cisco ISR and ASR devices, including the ISR 1000, ISR 4000, and ASR 1000 series, with the appropriate IOS XE SD-WAN-enabled software

You can mix and match the various options of hardware, software, on-premises, and cloud-based for each of the components as you see fit, making the solution highly flexible and configurable for the requirements of each enterprise.

What does a Cisco SD-WAN solution look like?

OK, enough of the theory for now. What does it look like if we put this all together into an enterprise SD-WAN solution? Where do all of these entities reside? Well, let’s take a look.

SD-WAN deployment

Once you determine what each location needs and how you will deploy each component, next, you must deploy each of the components. The process below is a high-level description of how these components are deployed, what kinds of technologies are involved, and some of the processes you will have to consider.

There are two primary tasks to perform. The first is the deployment of the controllers, while the second is the vEdge onboarding process. We’ll examine both here.

Deploying Controllers

The controllers in Cisco’s SD-WAN solution are the vManage, the vSmart, and the vBond entities. When deploying them, note the following:

• When installed for the first time, all three of these devices will offer only CLI connectivity, so initial configuration must be achieved via the command line.
• Three items must be configured on each controller:
  • The system configuration, which includes hostname, organization name, and other information.
  • A VPN0 interface, which is used for communication on the overlay network.
  • A unique system IP—although it takes the form of an IPv4 address, this is not an IP address, but it is similar to a router ID used in OSPF or BGP.
• Cisco SD-WAN requires certificates on every device for secure communication and authentication.

With a basic configuration of all of the above for these three components, these controllers will have network connectivity and will be able to communicate with each other.

Typically, these three devices are deployed in a virtual environment. As such, they can be located either on-premises, in the cloud, or some combination of both. Most often, all three are found within the same infrastructure, although multiple entities of each type may also be deployed for redundancy.

vEdge onboarding

After the controllers are up and running, the next step is known as vEdge onboarding. This is the process by which you prepare a vEdge device to connect to the SD-WAN network. Once this is achieved for a single device, the process is the same for all additional devices.

This process involves:

• Creating a basic configuration including the system settings as well as the VPN0 overlay network configuration for initial communication with the vBond
• Configuring certificates for security and authentication of communication between SD-WAN devices
• Adding the vEdge device to the vManage controller

Note that the process of adding the vEdge device to the vManage controller has changed recently for versions 20.X and above.

For Cisco SD-WAN versions before 20.X, the process involved taking the chassis number and the serial number from the vEdge device and applying them to the vManage and vBond devices. This allowed the vManage device to create the appropriate WAN Edge list and certificates to enable communication.

However, from version 20.X and on, it is necessary to create device licenses on www.cisco.com to complete the process, ensuring that the correct licenses have been purchased from Cisco.

Once onboarding is complete, the list of vEdge devices that vManage control can be seen within the GUI.

Conclusion

Deploying Cisco’s SD-WAN solution can seem to be a daunting task. It is indeed time-consuming, but it is pretty straightforward when the process and its components are understood. Hopefully, this has given you a head start in your deployment scenario, enabling you to create the high-performance, low-cost SD-WAN solution your enterprise needs!