Skip to main content
Cisco SD-WAN
Support
Product Documentation
Viptela Documentation

Primary SEN Components

The secure, virtual IP fabric of the Viptela Secure Extensible Network (SEN) is made up of four fundamental components:

  • vManage Network Management System (NMS)—The vManage NMS is a centralized network management system that lets you configure and manage the entire overlay network from a simple graphical dashboard.
  • vSmart Controller—The vSmart controller is the centralized brain of the Viptela solution, controlling the flow of data traffic throughout the network. The vSmart controller works with the vBond orchestrator to authenticate Viptela devices as they join the network and to orchestrate connectivity among the vEdge routers.
  • vBond Orchestrator—The vBond orchestrator automatically orchestrates connectivity between vEdge routers and vSmart controllers. If any vEdge router or vSmart controller is behind a NAT, the 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 Viptela hardware device or software that runs as a virtual machine, and the remaining three are software-only components. The software vEdge router, vManage NMS, and 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 Viptela SEN. The sections below describe each component in detail.

s00012.png

vManage NMS

The vManage NMS is a centralized network management system. The vManage NMS dashboard provides a visual window into the network, and it allows you to configure and manage Viptela network devices. The vManage NMS 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 the vManage NMS software to run on the same physical server as vSmart controller software.

You can use vManage NMS to store certificate credentials, and to create and store configurations for all Viptela network components. As these components come online in the network, they request their certificates and configurations from the vManage NMS. When the vManage NMS receives these requests, it pushes the certificates and configurations to the Viptela network devices.

For vEdge Cloud routers, vManage NMS can also sign certificates and generate bootstrap configurations, and it can decommission the devices.

vSmart Controller

The vSmart controller oversees the control plane of the Viptela overlay network, establishing, adjusting, and maintaining the connections that form the Viptela fabric.

The major components 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. (In a network with multiple vSmart controllers, a single 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 vSmart controller and the vEdge router. This payload consists of route information necessary for the 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 vSmart controller and a vEdge router is a permanent connection. The 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 Viptela 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 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.
  • Authentication—The 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 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, segmentation, extranets, and other network needs.
  • Netconf and CLI—Netconf is a standards-based protocol used by the vManage NMS to provision a vSmart controller. In addition, each vSmart controller provides local CLI access and AAA.

The 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 vSmart controllers in the Viptela overlay 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 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 Viptela website. A single Viptela root-of-trust public certificate is embedded into all vSmart software images.

During the initial startup of a vSmart controller, you enter minimal configuration information, such as the IP addresses of the controller and the vBond orchestrator. With this information and the root-of-trust public certificate, the vSmart controller authenticates itself on the network, establishes a DTLS control connection with the vBond orchestrator, 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 vSmart controller through a console connection.) The 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 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 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 vSmart controllers, the vBond orchestrator tells the vSmart controllers about each other and tells each vSmart controller which vEdge routers in the domain it should accept control connections from. (Different vEdge routers in the same domain connect to different vSmart controllers, to provide load balancing.) If one vSmart controller becomes unavailable, the other controllers automatically and immediately sustain the functioning of the overlay network.

vBond Orchestrator

The vBond orchestrator automatically coordinates the initial bringup of vSmart controllers and vEdge routers, and it facilities connectivity between vSmart controllers and vEdge routers. During the bringup processes, the 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 vBond orchestrator is the only Viptela device that is located in a public address space. This design allows the vBond orchestrator to communicate with vSmart controllers and vEdge routers that are located behind NAT devices, and it allows the vBond orchestrator to solve any NAT-traversal issues of these Viptela devices.

The major components of the vBond orchestrator are:

  • Control plane connection—Each vBond ​orchestrator has a persistent control plane connection in the form of a DTLS tunnel with each vSmart controller in its domain. In addition, the 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 vBond orchestrator facilitates the initial orchestration between vEdge routers and 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 vSmart controllers, the vBond orchestrator automatically performs load balancing of vEdge routers across the vSmart controllers when routers come online.

The vBond orchestrator is a software module that authenticates the 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 Viptela 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 node that is requesting control plane connectivity. This authentication behavior assures that only valid customer nodes can participate in the Viptela overlay network. The DTLS connections with vSmart controllers are permanent so that the vBond controller can inform the vSmart controllers as vEdge routers join the network. The DTLS connections with vEdge routers are 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. 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. The vBond orchestrator maintains no state.

To provide redundancy for the vBond orchestrator, you can create multiple vBond entities in the network and point all vEdge routers to those vBond orchestrators. Each vBond orchestrator maintains a permanent DTLS connection with each vSmart controller in the network. If one vBond orchestrator becomes unavailable, the others are automatically and immediately able to sustain the functioning of the overlay network. In a domain with multiple vSmart controllers, the vBond orchestrator pairs a vEdge router with one of the 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. s00021.pngTo 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 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 vSmart controller. This payload consists of route information necessary for the 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 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 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 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.

Additional Information

Software Services
Viptela Terminology

  • Was this article helpful?