In the past…

Unless you have lived under a rock for the past 10 years, you know that these days everything is software defined. Networking is software defined, data center is software defined, you name it, is software defined. Makes sense of course. Networks have become so vast, so central to application innovation, and so crucial to business differentiation, that the network must be swiftly adaptive and brutally reliable. And currently only software provides the speed and innovation needed for the networks of tomorrow.

According to a loose consensus in the industry, SDN or software defined networking usually means the separation of control and data planes and the functionality that comes with them. What this means is that the control plane functionality, routing and policy decisions are made centrally usually in the confines of a redundant server setup and are pushed out throughout a network of dumbed down network devices that listen to the master controller’s decision on how to forward the user traffic in the data plane.

There are many reasons why one would adapt this new architecture and paradigm, but the most prominent ones are:

economic — concentrate the expensive intelligence centrally in a few devices and deploy a sleuth of cheaper devices to perform the actual packet forwarding
scalability and speed — a much smaller number of control plane nodes means a much faster control plane convergence).

When I first heard of Software Defined WAN, the first thing that crossed my mind was a seminar that I watched years before on Cisco PfR (Performance Routing) delivered by Brian Dennis from INE. In those days I was considering starting the sisyphean journey of becoming a CCIE and so I was watching and studying any and all technologies coming out of Cisco. My first impression on PfR was that, while the technology is extremely powerful, there are a lot of moving pieces and moreover the configuration needed to implement it is very convoluted and extensive to say the least. Most people were scared and wary about PfR in the confines of the CCIE exam for these reasons.

The technology evolved over the years. These days PfR has reached version 3 and is part of the Cisco IWAN solution. PfR and IWAN proved difficult to implement not only in a testing environment but in real life as well. IWAN was integrated within APIC-EM to abstract the complicated technology components and make it easier to configure. And this is where my next interaction with it happened, while working with APIC-EM. And while integrating IWAN into APIC-EM was a step in the right direction, giving users and network administrators a single pane of glass, central point to plan, configure, manage and monitor their enterprise networks, it was not enough. I still had my worries around the amount of time needed to implement IWAN and the user friendliness of the interface and the solution overall.

IWAN integrated within APIC-EM to abstract the complicated technology components and make it easier to configure, was a step in the right direction.

SD-WAN makes the network more scalable and faster to converge

The next breakthrough came with the Viptela acquisition and their elegant solution to software defined WAN. Viptela managed to separate the control plane from the data plane by having different components in their WAN fabric performing different functions. vBond is the orchestrator, vSmart is the policy enforcer, vManage is the one pane glass management solution while the vEdges are the data plane components of the solution. Separating the WAN fabric this way makes it more scalable, faster to converge and (some might say) cheaper. On top of a transport independent underlay that supports all types of WAN circuits you can imagine (MPLS, DSL, broadband, 4G, etc.) an overlay is being built that runs OMP (Overlay Management Protocol) the magic sauce that brings the whole solution together.

Separating the control plane from the data plane makes the
WAN fabric more scalable and faster to converge.

Fabric functionality was exposed over a REST API interface

As with any Cisco acquisition, I was interested to have a look at the Viptela solution and see how it fits in the bigger picture. So I’ve started reading about it, and set up a complete fabric with 4 vEdges in my lab. As a DevNet engineer, what really piqued my interest was the fact that all the fabric functionality was exposed over a REST API interface. So I started to explore the API, first reading the documentation, then using the swagger interface that comes with vManage, to then build a Postman environment and collection with custom API calls to authenticate, get a list of all the devices in the fabric, get a list of all the configuration templates, etc.

Then I started generating Python code with Postman and building my own Python scripts to automate small everyday tasks. I ended up building a CLI application in Python and together with a colleague of mine (thanks Tom!) we’ve built another application that gives the option to MSPs (Managed Service Providers) that have single tenant clients to view statistics and manage them through a unified web-based interface.

I’ve been able to build my own Python scripts to automate small everyday tasks. In the above application,Managed Service Providers (MSPs) can give clients the option to view statistics through a unified web-based interface.

Get videos, learning labs, sample code for your journey

All the content that I mentioned so far, plus links to learning labs, sandboxes, partners, sample code can be found on DevNet. You can also find there a 13 videos course that takes you from introduction to what SD-WAN is, to building your first Python application using the vManage REST API.

Add functionality with just a code upgrade

Having Cisco ISRs, ASRs, CSR1000V and ENCS devices capable of joining an SD-WAN fabric and being managed by Cisco vManage means that you can now have additional functionality in your trusted Cisco network with just a code upgrade not needing to do a complete over-haul of your infrastructure. If you already invested in having your branches or your cloud workloads connected with Cisco devices you can now easily extend or build an SD-WAN fabric with them. If you already invested in Viptela vEdges you now have additional Cisco device options, both hardware and software, to connect your branches, headquarters, data centers or whatever the use case may be.

The comprehensive security features that were recently announced with enterprise firewall, IPS, URL filtering security capabilities, Cisco Umbrella as well as DUO integrated in all the SD-WAN vEdges are a differentiating factor for Cisco in a very competitive SD-WAN market.

The future

I’m anxiously waiting to see what the Enterprise Networking team will come with next for Cisco SD-WAN. I’d love to see vManage integrated in one shape or another into Cisco DNA Center and also I’d like to have policy consistency and enforcement throughout the enterprise. Wouldn’t it be great if we can have a seamless traffic policy in our SDA fabrics as well as our SD-WAN fabrics? Some of my fears regarding IWAN have been addressed, so these days I’ve become a big proponent of SD-WAN and can definitely see the advantages it brings.

Be on the lookout for more SD-WAN related content for developers being released from DevNet. Several workshops and classroom sessions around this topic are already scheduled for Cisco Live US 2019 following the interest we’ve noticed at Cisco Live Barcelona and Cisco Live Melbourne.

That’s me leading a DevNet Zone workshop on SD-WAN at Cisco Live Europe in February. I’m bringing the workshop to Cisco Live US as well. Hope you’ll join me!

Let me know in the comments below how you started your SD-WAN journey and how far you’ve come so far. Also please let me know what else you’d like to see around SD-WAN from DevNet.

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel