What is Cisco SD-WAN?
At its heart, Cisco SD-WAN is about ensuring that business applications leverage the optimal transport, aka ‘intent-based SD-WAN’.
Intent-Based SD-WAN is about leveraging business use cases and business outcomes as the basis for WAN design, rather than building a WAN based on transports and then deciding how to traffic engineer to meet business requirements.
There is no such thing as a network which is not intent-based (I plugged two routers into a switch a week ago, they still have yet to spontaneously configure a routing protocol between them), but the design of the WAN can now be orchestrated arbitrarily on top of transports, utilizing the strengths of each while minimizing the weaknesses.
What Challenges does SD-WAN solve?
Consider the traditional WAN design. Businesses make decisions based on cost, requirements, return on investment, and value add. When it comes to traditional WAN design, these dice are thrown into a large plastic cup, shaken around, and out comes a budget with requirements.
I’m pretty sure this is actually how budgets are created .
Now, based on these considerations, a decision is made on what WAN transports to utilize, as well as how much redundancy is required. In some remote locations, the availability of transports can be a limiting factor before any of this is done. At the end of this process, a business has the business requirements and the WAN transport(s) with which to meet them.
At this point in traditional WAN design, network architects must begin engineering the routing to meet the business requirements utilizing the options available from the carrier. Let’s look at a few.
MPLS Layer 3 VPN: With traditional L3VPN, organizations share their routes with a carrier in order to establish reachability between sites. This is often done with BGP, though other options exist. This requires coordination with the carrier in order to honor any QOS markings, to establish peering and allow traffic engineering.
MPLS Layer 2 VPN: Also known as VPLS, this simulates a layer 2 adjacent LAN. While useful for certain legacy application flows, or other corner cases, the main draw of VPLS is to allow organizations to utilize an IGP across the WAN and control routing without the need for carrier interaction. From a QoS perspective, markings still have to be coordinated and honored with the carrier, but the business controls all the routing themselves. However, since the LAN is virtual, the network topology requires coordination with the carrier.
IPSEC Site-to-Site: Less an actual transport, and more a security solution over an insecure transport, this covers insecure transports such as wireless, internet, and other third-party connections. Often times this ends up landing on a firewall or other security appliance, and so the ability to do routing and preference path selection is severely lacking. For example, if there are multiple internet transports, whichever tunnel is active will end up being utilized, without taking into account cost or speed. The tunnel with interesting traffic will be used until it goes down or is forced to change manually.
DMVPN Over Internet: Very popular in more recent years, and part of the Cisco IWAN solution, DMVPN allows the security of a VPN with the granular traffic engineering associated with routing, all packaged in a low-cost transport. This solution provides a lot of advantages with the only real disadvantage being taht the transport itself is unreliable in some countries and carries a very poor SLA, if any. Because of the low cost, low confidence, high bandwidth nature of Internet transport, DMVPN tends to be used for either backup connectivity, or to pin large, fault-resistant application movements such as TCP-based applications that have a lot of data to move but lack a strict SLA.
Dark Fiber/Metro Ring: By far the simplest and easiest transport, and sometimes not even considered part of a WAN, this transport consists of leased/purchased fiber that connects geographically seperated areas, usually within a metropolitan area or across long distances, but differ from traditional WAN insofar as there is often no carrier or a more or less end-to-end physical layer.
As you can see, each transport solves some problems and introduces others. For each transport, the traffic engineering solutions that are available are different (or nonexistent). What if there were a way to do traffic engineering irrespective of the transport itself, and provide a clear and consistent set of criteria in order to create a single engineering vision?
Of course, we still have to be aware of the capabilities of each transport. Some do and don’t honor QOS markings, for example, and there are different SLAs and reliabilities associated. But what if we had a consistent policy across all the transports, and could use health monitoring to choose the best transport for the job?
This is a challenge which Cisco IWAN attempted to address, but whereas IWAN consisted of multiple solutions working toward a common goal, Viptela was purpose-built to be a single solution. Cisco IWAN was and is capable of maximizing the intelligent usage of WAN transports, but it lacks a single fabric pulling it all together, and orchestration is complicated.
That is what Cisco SD-WAN offers – the ability to provide consistent policy design, orchestration, application, and adherence, which creates a consistent fabric across any transport.
How Does Cisco SD-WAN Solve The Challenges?
Much in the same way that we are able to separate underlay from overlay routing via DMVPN with Front-Door VRF, Viptela establishes an overlay network across disparate transports in order to allow policy to be consistently designed and applied. By creating a fabric over top of the transports, we can utilize the best transport to satisfy the business intent. Using health monitoring of the underlay transports, the fabric can react quickly to changing conditions to ensure business continuity.
That’s a Lot of Marketing Buzzwords…
We should step back and explain the basic pieces of Viptela in order to put some solid details in front of the fluff.
First, there are multiple planes of the Viptela solution, and different pieces live within different planes, with some overlap. Let’s examine them at a high level.
Data Plane: This is where the physical or virtual vEdge / cEdge will be and is probably the most recognizable piece of the solution. This is where the WAN transport is most likely to terminate, or at least the tunnels. This is the ingress/egress point for the SD-WAN fabric, and each vEdge/cEdge will generally establish tunnels to the others on available transports.
Control Plane: The control plane is abstracted from the data plane by the vSmart appliance. The vSmart is basically a route reflector in BGP terms. vEdges establish Overlay Management Protocol (OMP) adjacencies with the vSmarts, not other vEdges, for the purposes of route exchange and traffic engineering. OMP is the protocol that Viptela uses to do routing within the fabric and includes the enterprise routes as well as transport information. I’ll explain OMP more in detail when we start to do deep dives on Viptela VPN routing.
Management Plane: vManage is the place where all the magic happens. It provides the single pane of glass for management, monitoring and troubleshooting for the entire Cisco SD-WAN solution. It is with the vManage that consistent policies can be deployed at scale to transform business intent into optimal WAN traffic flows. The vManage allows network engineers to scale the business intent to an entire WAN fabric using the web interface or a programmable REST API.
Without the vManage, the solution would be decentralized and scale would be as difficult as the traditional WAN.
Orchestration Plane: Viptela is a whitelist solution, which means that only allowed devices can become part of the fabric, establish tunnels and inject routes. Because of this, a device is needed to help orchestrate the onboarding of devices into the fabric. The vBond Orchestrator maintains the list of allowed vSmart, vManage, and vEdge devices and serves to authenticates devices that want to join the fabric. The vBond also helps the vEdges detect that they are behind NAT. You can think of the vBond as the glue that stitches all these components together.
Bringing it Together
If this sounds like marketing hype, understand that I’m not a sales guy. I was an enterprise network engineer before I ever came to Cisco, and I know the pain associated with trying to enforce a singular vision across multiple transports and solutions. The more I learn and use Cisco SD-WAN with Viptela, the more I really believe in the benefits it can bring to just about any enterprise.
I’m going to link some resources to learning more about Viptela from a high level below, as I don’t believe in reinventing the wheel. In the days/weeks to come, I’ll also be showing off Cisco SD-WAN with Viptela hands-on using Cisco dCloud. Dustin Schuemann has built some very good content. Not all of it is freely available, so to get hands-on with it you may need to contact your Cisco account representative to see more. In the meantime, I’ll be creating some posts around how to use vManage, and later, how to leverage the Templates and Policies to scale.
Eventually, I’d like to show some of the programmability options, but I’m still far from being good at development. But then again, it’s projects like this that motivate me.
Tune In Next Time…
The Viptela solution is far more complicated than this high-level look, and as I start digging into the hands-on we’ll need to discuss it in more detail. For now, though, this is a good first step to start.
Links:
Cisco Live 2018 Orlando Introduction to Next-Gen (Viptela) SD-WAN
