Part-1 of this blog series answered the question “why SDWAN and why now?” by focusing on the needs and driver.
This part is the first where we will start dive into the technical aspect of the Cisco SDWAN solution.
For those who are familiar or experienced with the MPLS L3VPN architecture ( which is a proven reliable, scaleable and multi-tenant architecture), there are two key planes ( but not only ones) the forwarding and control plane. The forwarding plane is taking care of by the MPLS labels’ distribution and switching across the data forwarding path also referred to in MPLS terms as the label switched path LSP. On top of that we have the MP-BGP established among the MPLS edge node ( provider edge PE) and for scalability reasons BGP sessions are formed with the BGP route reflectors and not directly among the PE nodes. The label stack in this architecture provide the flexibility to offer separations (VPN label) traffic engineering (TE label) etc.
If we look at Cisco SDWAN architecture from 10000 feet view, it uses similar foundational architecture concept of the reliable, scalable and multi-tenant MPLS L3VPN architecture. Think of the SDWAN overlay fabric as the LSP path and the central control plane as the BGP RR and the control protocol used between the SDWAN edge node and the central controller acting like BGP in the MPLS L3VPN.
Considering similar foundational approach to the proven and reliable MPLS L3VPN, makes the foundation of Cisco SDWAN architecture reliable and flexible enough to promote scalability, and many other capabilities natively, like segmentation, without building a complete separate forwarding plane (overlay).
Note: these similarities are from architecture point of view and not capabilities, because Cisco SDWAN can offer way more capabilities than a typical MPLS L3VPN, like cloud ready, flexibility of its control components, application aware, visibility with analytics, advanced security etc. which is what this blog series will discuss.
If we Zoom-in a bit more, we will find that, what’s interesting about Cisco SDWAN architecture, is the modularity aspect of its architecture components.
Each architecture function or plane is deployed as a separate component, and all collectively construct the Cisco SDWAN solution architecture that operate as a “system”. Such a modular architecture promotes: flexibility and scalability to a high extent as each comment can be scaled or treated in a different manner, based on the use case scenario.
Cisco SDWAN Architecture Components
vBond: the vBond is orchestration component of the Cisco SDWAN solution, and plyas a very key role as it facilitates the mutual discovery of the control and management elements of the fabric by leveraging a zero-trust certificate-based white-listed model. As well as it automate the distribution list of the available control and management plane components (vSmart & vManage) to the WAN edge nodes during the bring-up process. Even if any of these components residing behind a NAT device, vBond is capble to facilitate the function of NAT traversal, by allowing learning public (post-NAT) and private (pre-NAT) IP addresses. The discovery of public and private IP addresses allows establishing connectivity across public (Internet, 4G) and private (MPLS, point-to-point) WAN transports. Because the vBond role as orchestrator (like the man in the middle) it should reside in the public IP space or reside on the private IP space with 1:1 NAT, if Internet is one of the mediums used for SDWAN transport or hosted in the cloud.
vSmart: the vSmart is the control plane ( the brain) of the SDWAN fabric that facilitate the fabric discovery by learning about the edge nodes and connected networks using the Overlay Management Protocol (OMP), in similar fashion of a BGP RR in a BGP/MPLS VPN environment (among themselves as well as between the WAN edge nodes).in addition, vSmart controllers also distribute data plane and application aware routing policies to the WAN edge nodes.
Edge Nodes: the Cisco WAN edge nodes ( vEdge from the Viptela or cEdge > Cisco ISR/ASR1K routers as well as virtual nodes e.g. CSR1Kv, vedge cloud, ENCS) are the data plane components of the Cisco SDWAN fabric. Think of it like the PE node in an MPLS L3VPN environment. The PE typically participate in customer routing from one side ( multi-tenant/segment per VRF) and in the core routing from another side MPLS core to build the LSP, as well as the PE peer with the MP-BGP RR to advertise and learn routes. Similarly the Cisco SDWAN edge nodes follow the same approach (participate in LAN side routing and establish control plane relationship with vSmart controller to exchange pertinent information required to establish the fabric and learn centrally provisioned policies). Also SDWAN edge nodes are responsible for encrypting and decrypting application traffic between the sites if IPSec is used instead of GRE.
vManage: It is the single pane of the management plane glass. It used for Day0, Day1 and Day2 operations, like: centralized provisioning, centralized policies, device configuration templates, Security (FW, IPS, URL filtering), troubleshooting and monitor the entire environment. Also, support programmability/APIs to enable DevOps operations. Moreover, vManage GUI can be used to extract performance statistics collected from the entire fabric.
All the component of the SDWAN architecture support multitenant web-scale architecture that are capable to cater to the needs of the enterprise and service provider environments.
The way multitenancy can be deployed can vary, based on the definition of a tenant it could be a virtual network or user group by an enterprise or it could a customer of an SP. The following figure shows some of the possible multitenant deployment models with Cisco SDWAN. Therefore, the selection of any of the below models or other ones, depends on the use case scenario, targeted environment, scale etc. in which there is no one single best option.
Furthermore, the consumption models of the Cisco SDWAN controllers is flexible, as illustrated below. As highlighted in part-1 of this blog series, the selection of any of the models below, depends on several factors and there is no one best recommended model.
The Subsequent blog, will focus on the Cisco SDWAN Control and Data plane elements.