What is so special about the new Software-Defined WAN concept besides the many marketing slogans like “Redefining Networks for Cloud era” or “Transport independent secure fabric” or where the “66% cost reduction” comes from? First of all, when we talk about SDWAN we can think of it as the practical enforcement of the Software-Defined Network (SDN) concept. The main point in the SDN approach is network data plane and control plane disaggregation and flavour of API-based open networking for better interoperability between the systems and processes automation. Executing the SDN concept, in SD-WAN everything related to control plane logic is transferred to the central brain which is called the controller. There is also a management plane and API-enabled body for management purposes and CPE instances (physical or virtual routers) that execute the data plane part (also known as forwarding plane). Looking at the history of WANs we have been configuring (even still today we do) hop by hop, device by device, QOS classes, policy maps, routing, security features with great attention, but still doing some mistakes, having large administration overhead and need for network engineers expertise. With SD-WAN we can avoid a significant part of the above having at the same time a nice bunch of additional features.
Cisco Viptela SD-WAN components.
In Cisco Viptela solution the role of network controller is played by vSmart controller (located in the cloud). We see vEdges that are CPEs and every vEdge has to be connected with vBond and vSmart to kick off full operability. vEdge can be physical or virtual and they are typically located at customer premises but can also be installed on private and public clouds. The vManage is the tool or simply kind of a dashboard that helps administrators to clearly define WAN communication rules and manage policies from a graphical interface. Using vManage, administrators are allowed to construct different topologies depending on their needs, such as branches with single or dual MPLS/Internet lines, hub and spoke topologies or spoke to spoke connectivity. Below picture shows how the functional modules are connected to each other.
The whole concept consists of four elements:
- vBond – initiates the bring-up process of every vEdge device, at the first step it creates a secure tunnel with vEdge and informs vSmart and vManage about its parameters like for instance ip address. It has to be fully connected with every device.
- vSmart – this is a controller for your network, it is responsible for managing all control and data policies by using a special Overlay Management Protocol (OMP).
- vEdge – router which receives complete control and data policies from the vSmart, it is able to run routing protocol like OSPF, BGP to create connectivity on LAN side but also with MPLS provider if necessary. It establishes secure IPSec tunnels with other vEdges depending on the selected topology.
- vManage – fully manageable centralized portal to run and operate software-defined network (SD-WAN).
Every piece of the above list plays a separate significant role in the whole puzzle, however, to configure and operate the network typically we have to spend most of the time on vManage.
Looking closely at each component.
Let’s firstly look at a vEdge device, what parameter we should predefine to be able to use zero-touch provisioning functionality. The requirements are the vBond IP address to which we have to build the secure control connectivity, organization name and basic external interface WAN configuration. It can be set statically or allocated dynamically. We should do it inside the VPN service which is designed to serve as a transport purpose. We have also a special VPN 512 only for management purposes and others 1-511 for common use cases. Additional parameters we will apply with template directly from the vManage portal. To successfully connect a vEdge device to the cloud-based piece of infrastructure they are staged with pre-generated private and public keys together with a certificate signed by Avnet. The certificate is loaded into the TPM chip and has a root CA trust chain for Symantec Root CA.
Connecting vEdge to vBond
vEdge base configuration:
System
organization-name „NAME”
vbond b.b.b.b
!
vpn 0
interface eth0
ip address 1.2.3.4/xx or ip dhcp-client
!
no shutdown
!
ip route 0.0.0.0/0 x.x.x.x
In a few words, vEdge exchanges certificate with vBond which also validates vEdge serial number and chassis identifier. Once this part is completed vBond informs vSmart and vManage of the newly attached device IP address. Finally, it shares to vEdge a complete list of vSmart and vManage instances. Then the just provisioned DTLS tunnel between vBond and vEdge is terminated.
Picture 1 – vManage status before vEdge attachment
vedge# show control connections
PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME ID
--------------------------------------------------------------------
vbond dtls - 0 0 198.18.1.11 12346 198.18.1.11 12346 biz-internet connect 0
Above control connection is created between vEdge and vBond during the initialization process, at the beginning device has only a single tunnel with vBond, though when the process completes the device will pick up full control connectivity with vSmarts and vManages over every possible means of transport.
vEdge control connections to vSmart and vManage
vedge# show control connections
PEER PEER CONTROLLER
PEER PEER PEER SITE DOMAIN PEER PRIV PEER PUB GROUP
TYPE PROT SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME ID
--------------------------------------------------------------------
vsmart dtls 12.12.12.12 10 1 198.18.1.12 12346 198.18.1.12 12346 biz-internet up 0:00:00:32 0
vsmart dtls 12.12.12.12 10 1 198.18.1.12 12346 198.18.1.12 12346 mpls up 0:00:00:18 0
vmanage dtls 10.10.10.10 10 0 198.18.1.10 12346 198.18.1.10 12346 biz-internet up 0:00:00:32 0
Configuration templates
Later we should define a template for the rest important part of the configuration like users’ VPNs or management protocols. Then we could attach it to the device as per the below picture.
Picture 2 – Template attachment process
Picture 3 – Template fulfilment process
During this process, we could assign and modify dynamic variables which could vary based on location.
Picture 4- Template attached
Finally, everything was fine and the device receives complete configuration according to the pushed template.
Picture 5 – vManage status after vEdge attachment
When we have parts of SDWAN connected, we can go forward with the planning and configuration tasks.
Ref: https://www.grandmetric.com/2018/02/19/cisco-viptela-sd-wan-components-connectivity-viptela-part-1/
Primary SEN Components
The secure, virtual IP fabric of the Cisco SD-WAN Secure Extensible Network (SEN) is made up of four fundamental components:
- Cisco vManage—Cisco vManage is a centralized network management system that lets you configure and manage the entire overlay network from a simple graphical dashboard.
- Cisco vSmart Controller—The Cisco vSmart Controller is the centralized brain of the Cisco SD-WAN solution, controlling the flow of data traffic throughout the network. The Cisco vSmart Controller works with the Cisco vBond Orchestrator to authenticate Cisco vEdge devices as they join the network and to orchestrate connectivity among the vEdge routers.
- Cisco vBond Orchestrator—The Cisco vBond Orchestrator automatically orchestrates connectivity between vEdge routers and Cisco vSmart Controllers. If any vEdge router or Cisco vSmart Controller is behind a NAT, the Cisco vBond Orchestrator also serves as an initial NAT-traversal orchestrator.
- vEdge Routers—The vEdge routers sit at the perimeter of a site (such as remote offices, branches, campuses, data centers) and provide connectivity among the sites. They are either hardware devices or software, called a vEdge Cloud router, that runs as a virtual machine. vEdge routers handle the transmission of data traffic.
Of these four components, the vEdge router can be a Cisco SD-WAN hardware device or software that runs as a virtual machine, and the remaining three are software-only components. The software vEdge router, Cisco vManage, and Cisco vSmart Controller software runs on servers, and the vBond orchestrator software runs as a process (daemon) on a vEdge router.
The figure below illustrates the components of the Cisco SD-WAN SEN. The sections below describe each component in detail.
Cisco vManage
Cisco vManage is a centralized network management system. Cisco vManage dashboard provides a visual window into the network, and it allows you to configure and manage Cisco vEdge network devices. Cisco vManage software runs on a server in the network. This server is typically situated in a centralized location, such as a data center. It is possible for Cisco vManage software to run on the same physical server as Cisco vSmart Controller software.
You can use Cisco vManage to store certificate credentials, and to create and store configurations for all Cisco vEdge network components. As these components come online in the network, they request their certificates and configurations from Cisco vManage. When Cisco vManage receives these requests, it pushes the certificates and configurations to the Cisco vEdge network devices.
For vEdge Cloud routers, Cisco vManage can also sign certificates and generate bootstrap configurations, and it can decommission the devices.
Cisco vSmart Controller
The Cisco vSmart Controller oversees the control plane of the Cisco SD-WAN overlay network, establishing, adjusting, and maintaining the connections that form the Cisco SD-WAN fabric.
The major components of the Cisco vSmart Controller are:
- Control plane connections—Each Cisco vSmart Controller establishes and maintains a control plane connection with each vEdge router in the overlay network. (In a network with multiple Cisco vSmart Controllers, a single Cisco vSmart Controller may have connections only to a subset of the vEdge routers, for load-balancing purposes.) Each connection, which runs as a DTLS tunnel, is established after device authentication succeeds, and it carries the encrypted payload between the Cisco vSmart Controller and the vEdge router. This payload consists of route information necessary for the Cisco vSmart Controller to determine the network topology, and then to calculate the best routes to network destinations and distribute this route information to the vEdge routers. The DTLS connection between a Cisco vSmart Controller and a vEdge router is a permanent connection. The Cisco vSmart Controller has no direct peering relationships with any devices that a vEdge router is connected to on the service side.
- OMP (Overlay Management Protocol)—The OMP protocol is a routing protocol similar to BGP that manages the Cisco SD-WAN overlay network. OMP runs inside 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 Cisco vSmart Controller and the vEdge routers and carries only control plane information. The Cisco vSmart Controller processes the routes and advertises reachability information learned from these routes to other vEdge routers in the overlay network.
- Authentication—The Cisco vSmart Controller has pre-installed credentials that allow it to authenticate every new vEdge router that comes online. These credentials ensure that only authenticated devices are allowed access to the network.
- Key reflection and rekeying—The Cisco 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 Cisco vSmart Controller provides rich inbound and outbound policy constructs to manipulate routing information, access control, segmentation, extranets, and other network needs.
- Netconf and CLI—Netconf is a standards-based protocol used by Cisco vManage to provision a Cisco vSmart Controller. In addition, each Cisco vSmart Controller provides local CLI access and AAA.
The Cisco vSmart Controller maintains a centralized route table that stores the route information, called OMP routes, that it learns from the vEdge routers and from any other Cisco vSmart Controllers in the Cisco SD-WAN overlay network. Based on the configured policy, the Cisco vSmart Controller shares this route information with the Cisco vEdge network devices in the network so that they can communicate with each other.
The Cisco vSmart Controller is software that runs as a virtual machine on a server configured with ESXi or VMware hypervisor software. The vSmart software image is a signed image that is downloadable from the Cisco SD-WAN website. A single Cisco SD-WAN root-of-trust public certificate is embedded into all vSmart software images.
During the initial startup of a Cisco vSmart Controller, you enter minimal configuration information, such as the IP addresses of the controller and the Cisco vBond Orchestrator. With this information and the root-of-trust public certificate, the Cisco vSmart Controller authenticates itself on the network, establishes a DTLS control connection with the Cisco vBond Orchestrator, and receives and activates its full configuration from Cisco vManage if one is present in the domain. (Otherwise, you can manually download a configuration file or create a configuration directly on the Cisco vSmart Controller through a console connection.) The Cisco vSmart Controller is now also ready to accept connections from the vEdge routers in its domain.
To provide redundancy and high availability, a typical overlay network includes multiple Cisco vSmart Controllers in each domain. A domain can have up to 20 vSmart controllers. To ensure that the OMP network routes remain synchronized, all the Cisco vSmart Controllers must have the same configuration for policy and OMP. However, the configuration for device-specific information, such as interface locations and addresses, system IDs, and host names, can be different. In a network with redundant Cisco vSmart Controllers, the Cisco vBond Orchestrator tells the Cisco vSmart Controllers about each other and tells each Cisco vSmart Controller which vEdge routers in the domain it should accept control connections from. (Different vEdge routers in the same domain connect to different Cisco vSmart Controllers, to provide load balancing.) If one Cisco vSmart Controller becomes unavailable, the other controllers automatically and immediately sustain the functioning of the overlay network.
Cisco vBond Orchestrator
The Cisco vBond Orchestrator automatically coordinates the initial bringup of Cisco vSmart Controllers and vEdge routers, and it facilities connectivity between Cisco vSmart Controllers and vEdge routers. During the bringup processes, the Cisco vBond Orchestrator authenticates and validates the devices wishing to join the overlay network. This automatic orchestration process prevents tedious and error-prone manual bringup.
The Cisco vBond Orchestrator is the only Cisco vEdge device that is located in a public address space. This design allows the Cisco vBond Orchestrator to communicate with Cisco vSmart Controllers and vEdge routers that are located behind NAT devices, and it allows the Cisco vBond Orchestrator to solve any NAT-traversal issues of these Cisco vEdge devices.
The major components of the Cisco vBond Orchestrator are:
- Control plane connection—Each vBond orchestrator has a persistent control plane connection in the form of a DTLS tunnel with each Cisco vSmart Controller in its domain. In addition, the Cisco vBond Orchestrator uses DTLS connections to communicate with vEdge routers when they come online, to authenticate the router, and to facilitate the router’s ability to join the network. Basic authentication of a vEdge router is done using certificates and RSA cryptography.
- NAT traversal—The Cisco vBond Orchestrator facilitates the initial orchestration between vEdge routers and Cisco vSmart Controllers when one or both of them are behind NAT devices. Standard peer-to-peer techniques are used to facilitate this orchestration.
- Load balancing—In a domain with multiple Cisco vSmart Controllers, the Cisco vBond Orchestrator automatically performs load balancing of vEdge routers across the Cisco vSmart Controllers when routers come online.
The Cisco vBond Orchestrator is a software module that authenticates the Cisco vSmart Controllers and the vEdge routers in the overlay network and coordinates connectivity between them. It must have a public IP address so that all Cisco vEdge devices in the network can connect to it. (It is the only Cisco vEdge device that must have a public address.)
The Cisco vBond Orchestrator orchestrates the initial control connection between Cisco vSmart Controllers and vEdge routers. It creates DTLS tunnels to the Cisco vSmart Controllers and vEdge routers to authenticate each node that is requesting control plane connectivity. This authentication behavior assures that only valid customer nodes can participate in the Cisco SD-WAN overlay network. The DTLS connections with Cisco vSmart Controllers are permanent so that the vBond controller can inform the Cisco vSmart Controllers as vEdge routers join the network. The DTLS connections with vEdge routers are temporary; once the Cisco vBond Orchestrator has matched a vEdge router with a Cisco vSmart Controller, there is no need for the Cisco vBond Orchestrator and the vEdge router to communicate with each other. The Cisco vBond Orchestrator shares only the information that is required for control plane connectivity, and it instructs the proper vEdge routers and Cisco vSmart Controllers to initiate secure connectivity with each other. The Cisco vBond Orchestrator maintains no state.
To provide redundancy for the Cisco vBond Orchestrator, you can create multiple vBond entities in the network and point all vEdge routers to those Cisco vBond Orchestrators. Each Cisco vBond Orchestrator maintains a permanent DTLS connection with each Cisco vSmart Controller in the network. If one Cisco vBond Orchestrator becomes unavailable, the others are automatically and immediately able to sustain the functioning of the overlay network. In a domain with multiple Cisco vSmart Controllers, the vBond orchestrator pairs a vEdge router with one of the Cisco vSmart Controllers to provide load balancing.
vEdge Routers
The vEdge router, whether a hardware or software device, is responsible for the data traffic sent across the network. When you place a vEdge router into an existing network, it appears as a standard router.
To illustrate this, the figure here shows a vEdge router and an existing router that are connected by a standard Ethernet interface. These two routers appear to each other to be Layer 3 end points, and if routing is needed between the two devices, OSPF or BGP can be enabled over the interface. Standard router functions, such as VLAN tagging, QoS, ACLs, and route policies, are also available on this interface.
The vEdge router’s components are:
- DTLS control plane connection—Each vEdge router has one permanent DTLS connection to each Cisco vSmart Controller it talks to. This permanent connection is established after device authentication succeeds, and it carries encrypted payload between the vEdge router and the Cisco vSmart Controller. This payload consists of route information necessary for the Cisco vSmart Controller to determine the network topology, and then to calculate the best routes to network destinations and distribute this route information to the vEdge routers.
- OMP (Overlay Management Protocol)—As described for the Cisco 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 Cisco 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 Cisco vManage 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 Cisco 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 cryptoprocessor that contains the private key and public key for the router, along with a signed certificate. All this information is used for device authentication. When you initially start up a vEdge router, you enter minimal configuration information, such as the IP addresses of the vEdge router and the Cisco 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 Cisco vSmart Controller in its domain, and receives and activates its full configuration from Cisco vManage 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.
Ref: https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/system-overview.html