Following me migrating my website to github pages a couple of weeks ago, it became pretty apparent that my Blog was barren and largely empty. So I decided to resurrect it and pledge to add content more frequently.
This week BT sent me on some Cisco sponsored SD-WAN training in Manchester. The venue Cisco chose for the event was the home of Manchester United Football club - Old Trafford. As a Liverpool fan, the venue is a place that doesn’t allure me in the way it would united fans, but it was a welcome change from some of the uniform BT buildings I have been in training at recently :)
I’ll include a few pictures below as, part of the two day event, Cisco arranged for a stadium tour and sit down evening meal at the venue which was excellent.
The purposes of the training, which was pitched for both technical pre-sales and technical design or solutions architects from within BT (hence my attendance), was to do a deep dive and comparison between Cisco’s two main SD-WAN market plays. That is - Cisco Meraki and Cisco Viptela
Both technologies originated from companies that Cisco acquired with Viptela being the most recent of the two following the acquisition that many saw as an attempt to save face and paper over the cracks of IWAN as an SD-WAN proposition.
Viptela
First part of the two day workshop/training was based around Viptela. Some will be familiar with the standard Network Architecture that Viptela tries to promote, but for those that are not I’ll bring it down really quickly. The core concept of the technical (as is the case with most if not all SD-WAN technologies) is that there is a complete abstraction of the Management and Control Plane from physical CPE to a cloud located function. In simple terms, the Data Plane is pretty much the only function that’s required at the CPE - that is to say forwarding packets via pre-established IPSec based tunnels. Here’s the Vendor image of the promoted Architecture that most will be familiar with below.
The default location of the devices acting as Management Plane (vManage), Orchestration Plane (vBond) and Control Plane (vSmart) is currently Amazon AWS. Most feel that this could be a barrier for the more security conscious potential customers. This is something that Cisco conceed to be true also and so, unlike the Meraki solutions, customers have autonomy to deploy their vManage/vBond/vSmart where they feel it most appropriate. This is also true of any Viptela SD-WAN solution purchased through BT therefore.
In the above;
- Cisco Cloud Ops assumes deployment with AWS as I stated.
- MSP Ops Team assumes BT or some other SP (Service Provider) manage the deployment within their own infrastructure.
- Enterprise IT would be the model where the customer themselves choose to deploy within their own Enterprise WAN network somewhere - presumably in their Data Centre(s)
We got into a bit more detail about how deep the encryption is on both the VPN Registry piece of the solution and also the IPSec tunnels that are created between the CPE devices (vEdge) to create the overlay. Public Key Infrastrucutre (PKI) is at the centre of many elements of a Viptela based network.
Let’s work through the various planes to examine them further
The Orchestration Plane
This is the first point at which PKI becomes relevant. We white-list our CPE to allow them create a TLS connection with the vBOND by way of the first point of authentication referred to as VPN Registration. Key at this plane also is the specification of the details of all our vSmarts and the vManage in use in the network. You starting to get the picture? This allows for a Zero Touch Provision process to occur. That’s to say we;
- whitelist a vEdge CPE device or set of devices within the vBond.
- we specify the vSmarts and vManage that is in use
- the vEdge(s) authenticates with our vBond securely (TLS/DTLS)
- by virtue of the fact that in this authentication process, the vBond discloses the details for it’s vSmart(s) and vManage, the vEdge creates a secure (TLS/DTLS) connection to the vSmart(s)
The nuts and bolts of how 4 above happens is down to a proprietary (surprise surprise) protocol called OMP or Overlay Management Protocol.
The Control Plane
This piece is pretty interesting as things go and it would be nice to get some deeper knowledge of how this really works (the protocol itself) under the hood but that’s for another day and is only my inner inquestive geek coming out.
The Management Plane
In terms of the Management Plane one big thing for those of use that are keen to automate, one thing you’ll note, which to be fair is pretty common across all SD-WAN vendors that I can see, is that the vManage devices have been released by Cisco with Programmatic interfaces that can use REST or NETCONF for instance. For Cisco this gives them a future ability to integrate it into the likes of DNA Centre. For others that could mean a whole host of possibilities.
The Data Plane
One of the beautiful things Viptela do is the concept of a TLOC or Transport Locator. This is especially relevant in a more robust and resilient WAN network design where there may be dual or even multiple WAN links and indeed CPE devices at play. One traditionally difficult phenomenon that comes with resilient WAN networks is the possibility of assymmetrical routing. This is never a good thing. What Viptela have done to try and make this a worry of the past is creating TLOCs. Furthermore, in the Data Plane establishment process (i.e. the way in which devices create their IPSec tunnels between each other) tunnels are formed through the advertisement of available TLOCs by vEdges to the vSmarts, which in turn advise other vEdges of their presence with TLOC Routes. In simple terms this means that Data Flows are not just between one box and another but rather a particular link on a box (TLOC) and another link on another box. Think of limitless possibilities to create resiliency in the network now and not need to worry about async routing!!!
In terms of how traffic is forwarded via these overlay tunnels there are a number of different designs that can be achieved as per below.
This gives a good graphic representation of end to end operations between Control and Data Plane I thought.
Another key element of Viptela that differentiates it from Meraki and indeed some other SD-WAN technologies is the concept of multiple VRFs akin to the Multi-Protocol BGP networks we’re very familiar with today living on MPLS networks. For some customers this is an absolute must. It’s simply inherent in Viptela. Below are some of the key examples in terms of secure segmentation that can be achieved.
The product scales very well and you can be pretty smart with your network design, especially if we’re talking about a pan-Global network deployment. Anywhere AWS exists, a vBond and vSmart can be placed. To that end customers can cluster their control planes by regions.
For example, using the various EMEA Data Centres within the AWS footprint (of which there’s many) to place maybe a vBond for that region. Then within the same spread of EMEA Data Centres they could deploy one or more distributed vSmarts. Then simply repeat this in the various other regions/continents if so inclined.