Updated: Oct 21, 2019
Hi everyone, welcome to the first official blog post of the #NotLayer3 Blog.
My name is Jon Spindler, and I want to thank you for your interest!
My goal for this entire site is to provide a clear video blueprint for folks looking to sharpen their skills and add #SDWAN Ninja to their resume. Over the past year I have been blessed with the opportunity to support some very important clients and lead the shift towards #SDWAN. In doing so, I've gained a great deal of experience with all sorts of deployment scenarios. If I had hair it would have been ripped out a couple of times, so I figured why not make some content to capture my lessons learned and contribute to this rapidly growing ecosystem of material.
I HIGHLY RECOMMEND SUBCRIBING to the NotLayer3 SD-WAN Channel for an exclusive look into building an SD-WAN environment from the ground up!
In this post, we're going to cover:
The Cisco SDWAN Solution Overview
Let's get started!
1st, What is #SDWAN? SD-WAN isn't really defined which is part of the reason why you see a lot (and I mean a lot) of companies offering an SD-WAN product. Luckily, this channel is only focusing on Cisco's Implementation, so I won't get into the weeds on other products at this time.
Here is how
Cisco Defines SD-WAN and the benefits:
They say "SD-WAN is a software-defined approach to managing the wide-area network, or WAN.
Key advantages include:
Reducing costs with transport independence across MPLS, 3G/4G LTE, etc.
Improving business application performance and increasing agility.
Optimizing the user experience and efficiency for SaaS and public cloud applications.
Simplifying operations with automation and cloud-based management."
Now that we've briefly skimmed the "Why SD-WAN?", Let's see how this accomplished by acquainting ourselves with the solution components.
1. vManage. This is your single pane of glass Management Server. With vManage you gain the power of orchestration, traffic analytics, exposed APIs for full programmability, Monitoring, troubleshooting, and more all in a super intuitive dashboard. We'll get some time behind the wheel of vManage in some upcoming videos on the SD-WAN Channel.
2. vBond. This is the SD-WAN Police. Just Kidding. But Seriously think of vBond as the gatekeeper of your SD-WAN.
The vBond orchestrator is a software module that authenticates the vSmart controllers and the vEdge routers in the overlay network and gets everyone talking. It needs a publicly reachable address so devices in the network can connect to it. (It is the only Viptela device that must have a public address.)
The vBond orchestrator orchestrates the initial control connection between vSmart controllers and vEdge routers. It creates DTLS tunnels to the vSmart controllers and vEdge routers to authenticate each vEdge or cEdge that is requesting control plane connectivity on the SD-WAN. This ensures only the devices you authorize are allowed on your network. The DTLS connections with vSmart controllers are permanent so that the vBond controller can inform the vSmart controllers as vEdge or cEdge routers join the network. The DTLS connections with vEdge routers are only temporary; once the vBond orchestrator has matched a vEdge router with a vSmart controller, there is no need for the vBond orchestrator and the vEdge router to communicate with each other continuously. The vBond orchestrator shares only the information that is required for control plane connectivity, and it instructs the proper vEdge routers and vSmart controllers to initiate secure connectivity with each other via DTLS or TLS.
The vSmart controller is the brains of the SD-WAN operation. It oversees the control plane of the Viptela overlay network, establishing, adjusting, and maintaining the connections that form the SD-WAN fabric.
The main pieces of the vSmart controller are:
Control plane connections—Each vSmart controller establishes and maintains a control plane connection with each vEdge router in the overlay network. Each connection, which runs as a DTLS tunnel, is established after device authentication succeeds, and inside of it is the communication between the vSmart controller and the vEdge router. This traffic is mostly the route information necessary for the vSmart controller to determine the network topology, and then to calculate the best routes to network destinations and give this route information to the vEdge routers. The DTLS connection between a vSmart controller and a vEdge router is a permanent connection.
OMP (Overlay Management Protocol)—The OMP protocol is a routing protocol like BGP that manages the SD-WAN overlay network. I say it is like BGP because of its Address-family structure. OMP runs inside the DTLS control plane connections and carries the routes, next hops, keys, and policy information needed to establish and maintain the overlay network. OMP runs between the vSmart controller and the vEdge routers and carries only control plane information. The vSmart controller processes the routes and advertises reachability information learned from these routes to other vEdge routers in the overlay network.
Key reflection and rekeying—The vSmart controller receives data plane keys from a vEdge router and reflects them to other relevant vEdge routers that need to send data plane traffic.
Policy engine—The vSmart controller provides rich inbound and outbound policy constructs to manipulate routing information, access control, and segmentation.
The vSmart controller maintains a centralized route table that stores all the route information, called OMP routes, that it learns from the vEdge routers and from any other vSmart controllers in the SD-WAN network. Based on the configured policy, the vSmart controller shares this route information with the Viptela network devices in the network so that they can communicate with each other.
The vSmart controller is just software that runs as a virtual machine on a server configured with ESXi or VMware hypervisor software.
4. vEdge or cEdge
The vEdge router can be deployed as a hardware or software device. It is your data plane or forwarding component. When you place a vEdge router into an existing network, it is like any other normal router. vEdges and cEdges support typical routing & switching functions such as OSPF, BFD, VRRP, DOT1Q, and QoS to name a few. In newer versions of Viptela Code, vEdges & cEdges also support EIGRP. For the purposes of this Channel, we will be sticking with Cisco’s recommended 18.4.1 which will be used exclusively on all upcoming certifications.
The vEdge router's components are:
DTLS control plane connection—Each vEdge router has one permanent DTLS connection to each vSmart controller it talks to. This permanent connection is established after device authentication succeeds, and it carries encrypted control plane traffic between the vEdge router and the vSmart controller.
OMP (Overlay Management Protocol)—As described for the vSmart controller, OMP runs inside the DTLS connection and carries the routes, next hops, keys, and policy information needed to establish and maintain the overlay network. OMP runs between the vEdge router and the vSmart controller and carries only control information.
Protocols—The vEdge router supports standard protocols, including OSPF, BGP, VRRP, and BFD.
RIB (Routing Information Base)—Each vEdge router has multiple route tables that are populated automatically with direct interface routes, static routes, and dynamic routes learned via BGP and OSPF. Route policies can affect which routes are stored in the RIB.
FIB (Forwarding Information Base)—This is a distilled version of the RIB that the CPU on the vEdge router uses to forward packets.
Netconf and CLI—Netconf is a standards-based protocol used by the vManage NMS to provision a vEdge router. In addition, each vEdge router provides local CLI access and AAA.
Key management—vEdge routers generate symmetric keys that are used for secure communication with other vEdge routers, using the standard IPsec protocol.
Data plane—The vEdge router provides a rich set of data plane functions, including IP forwarding, IPsec, BFD, QoS, ACLs, mirroring, and policy-based forwarding.
The vEdge router has local intelligence to make site-local decisions regarding routing, high availability (HA), interfaces, ARP management, ACLs, and so forth. The OMP session with the vSmart controller influences the RIB in the vEdge router, providing non-site-local routes and the reachability information necessary to build the overlay network.
The hardware vEdge router includes a Trusted Board ID chip, which is a secure crypto processor that contains the private key and public key for the router, along with a signed certificate. All this information is used for device authentication if you are deploying with Cisco’s hosted SD-WAN solution. When you initially start up a vEdge router, you enter basic configuration information, such as the IP addresses of the vEdge router and the vBond orchestrator. With this information and the information on the Trusted Board ID chip, the vEdge router authenticates itself on the network, establishes a DTLS connection with the vSmart controller in its domain, and receives and activates its full configuration from the vManage NMS if one is present in the domain. Otherwise, you can manually download a configuration file or create a configuration directly on the vEdge router through a console connection.
Now that we have a grasp on the Why and the How from a 30,000 ft view, we’re ready to start exploring the process of building an SD-WAN from the ground up. For the purposes of learning as much as possible, this channel will only focus on deployments as if you were to do everything yourself (not pushing the Cisco SD-WAN As A Service Easy Button).
In order to build a lab like mine, you’ll need access to Cisco Downloads via an active service contract connected to your Cisco Account. Unfortunately, there is no way around this, and I can’t share any image files. I can however share the name of the exact images you will need, and the emulator I recommend.
vEdge & vBond share the same image. The vBond Daemon is run on top of the vEdge software. It is not recommended to also use this node as a data plane router.
You will also need some routing image to load into the lab in order to setup a “Mock ISP” scenario for your SD-WAN lab. I’ll show you some places you might look in order to find these on the internet.
We’ll need some sort of management desktop image as well as an image to run as a Certificate Authority for the environment. There are plenty of options out there and the selection is highly dependent on your individual skillset.
Don’t be worried about this file format. Just think of it as a regular Virtual Machine image, but for #Linux. The reason we are downloading this file format is because the emulator I am using (and recommending) runs Linux KVM as the hypervisor.
The emulator is called #EVENG. It is bar none the BEST emulator tool on the market. It works flawlessly and can be run on bare metal or as a VM itself. I recommend finding a dedicated server to run a baremetal instance of EVE-NG or if that is not an option, they have very easy instructions on how to deploy in Google Cloud. For this channel, I highly recommend the Google Cloud Deployment. In the next post, I’ll show you how to get your eve-ng instance up and running in Google Cloud, and show you some basic management operations you will need in order to manage images, access, and get labbing!
I hope that you learned a lot in this post, and I can’t wait to keep going further.
Make sure to FOLLOW US for updates on what sort of SD-WAN Goodness is coming on our channel and blog!