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

Bringup Sequence of Events

The bringup process for the Viptela devices—which includes authenticating and validating all Viptela devices and establishing a functional overlay network—occurs largely under the covers, with only minimal user input. From a conceptual point of view, the bringup process can be divided into two parts, one that requires user input and one that happens automatically:

  • In the first part, you design the network, create virtual machine (VM) instances for Viptela device,s and install and boot hardware routers. Then, on the vManage Network Management System (NMS), you add the Viptela devices to the network and create configurations for each device. This process is described in User Portion of the Bringup.
  • The second part of the bringup process occurs automatically, orchestrated by the Viptela software.​ As Viptela devices join the overlay network, they validate and authenticate themselves automatically, and they establish secure communication channels between each other. For vBond orchestrators and vSmart controllers, a network administrator must download the necessary authentication-related files from the vManage NMS, and then these devices automatically receive their configurations from the vManage NMS. For vEdge Cloud routers, you must generate a certificate signing request (CSR), install the received certificate, and then upload the serial number that is included in the certificate to the vManage NMS. the For vEdge hardware routers, once they boot up, they are authenticated on the network and receive their configurations automatically from the vManage NMS through a process called zero-touch provisioning (ZTP). This process is described in the Automatic Portion of the Bringup.

The end result of this two-part process is an operational overlay network.

This article describes the sequence of events that occurs during the bringup process, starting with the user portion and then explaining how the automatic authentication and device validation occur.

Bringup Sequence of Events

From a functional point of view, the bringup of the Viptela devices in the overlay network occurs in the following sequence:

s00043.png

  1. The vManage NMS software starts on a server in the data center.
  2. The vBond orchestrator starts on a server in the DMZ.
  3. The vSmart controller starts on a server in the data center.
  4. The vManage NMS and the vBond orchestrator authenticate each other, the vManage NMS and the vSmart controller authenticate each other, and the vSmart controller and the vBond orchestrator authenticate each other.
  5. The vManage NMS sends configurations fo the vSmart and vBond devices.
  6. The vEdge routers start in the network.
  7. The vEdge routers authenticate themselves with the vBond orchestrator.
  8. The vEdge routers authenticate themselves with the vManage NMS.
  9. The vEdge routers authenticate themselves with the vSmart controller.
  10. The vManage NMS sends configurations to the vEdge routers.

Before you start the bringup process, note the following:

  • To provide the highest level of security, only authenticated and authorized devices are allowed access to and participation in the Viptela overlay network. To this end, the vSmart controller performs automatic authentication on all vEdge routers before they can send any data traffic over the network.
  • Once the Viptela devices are authenticated, data traffic flows regardless of whether the devices are in a private address space (behind a NAT gateway) or in a public address space.

To bring up the hardware and software components in a Viptela overlay network, a transport network (also called a transport cloud) must be available that connects all the Viptela devices and other network hardware components. Typically, these components are in data centers and branch offices. The only purpose of the transport network is to connect all the network devices in the domain. The Viptela solution is agnostic with regards to the transport network, so it can be any kind, including the Internet, MPLS, Layer 2 switching, Layer 3 routing, and LTE, or any mixture of transports.

For hardware vEdge routers, you can use  the Viptela zero-touch provisioning (ZTP) SaaS to bring up the routers. For more information, see Prepare vEdge Routers for ZTP

Summary of the User Portion of the Bringup

In a general sense, what you do to bring up the Viptela overlay network is what you would do to bring up any network: you plan out the network, create device configurations, and then deploy the network hardware and software components. These components include all the Viptela devices, all the traditional routers that participate in the overlay network, and all the network devices that provide shared services across the overlay network, such as firewalls, load balancers, and IDP systems.​

The table below summarizes the steps for the user portion of the Viptela overlay network bringup. The details of each step are provided in the articles listed in the Procedure column. While you can bring up the Viptela devices in any order, it is recommended that you deploy them in the order listed below, which is the functional order in which the devices verify and authenticate themselves.

If your network has firewall devices, see Firewall Ports for Viptela Deployments.

Step

Workflow

Procedure

1

b1.png

Plan out your overlay network. See Components of the Viptela Solution.

2

b2.png

On paper, create device configurations that implement the desired architecture and functionality. See the Software documentation for your software release.

3

b3.png

Download the software images from the Viptela support portal.

4

b4.png

Deploy the vManage NMS in the data center:

  1. Create a vManage VM instance, either on an ESXi or a KVM hypervisor.
  2. Create either a minimal or a full configuration for each vManage NMS.
  3. Configure certificate settings and generate a certificate for the vManage NMS.
  4. Create a vManage cluster.

5

b10.png

Deploy the vBond orchestrator:

  1. Create a vBond VM instance, either on an ESXi or a KVM hypervisor.
  2. Create a minimal configuration for the vBond orchestrator.
  3. Add the vBond orchestrator to the overlay network. During this process, you generate a certificate for the vBond orchestrator.
  4. Create a full configuration for the vBond orchestrator.

6

b12.png

Deploy the vSmart controller in the data center:

  1. Create a vSmart VM instance, either on an ESXi or a KVM hypervisor.
  2. Create a minimal configuration for the vSmart controller.
  3. Add the vSmart controller to the overlay network. During this process, you generate a certificate for the vSmart controller.
  4. Create a full configuration for the vSmart controller.

7

Deploy the vEdge routers in the overlay network:

  1. For software vEdge Cloud routers, create a VM instance, either on an AWS server, or on an ESXi or a KVM hypervisor.
  2. For software vEdge Cloud routers, send a certificate signing request to Symantec and then install the signed certificate on the router.
  3. From the vManage NMS, send the serial numbers of all vEdge routers to the vSmart controllers and vBond orchestrators in the overlay network.
  4. Create a full configuration for the vEdge routers.

Automatic Portion of the Bringup: What Happens Under the Covers

After the Viptela devices boot and start running with their initial configurations, the second part of the bringup process begins automatically. This automatic process is led by the vBond orchestrator, as illustrated in the figure below. Under the leadership of the vBond software, the Viptela devices set up encrypted communication channels between themselves. Over these channels, the devices automatically validate and authenticate each other, a process that establishes an operational overlay network. Once the overlay network is running, the Viptela devices automatically receive and activate their full configurations from the vManage server. (The exception is the vManage NMSs themselves. You must manually configure each vManage server itself.)

s00029.png

The following sections explain what happens under the covers, during the automatic portion of the bringup process. This explanation is provided to help you understand the detailed workings of the Viptela software so that you can better appreciate the means by which the Viptela solution creates a highly secure overlay framework to support your networking requirements.

User Input Required for the ZTP Automatic Authentication Process

The automatic validation and authentication of Viptela devices that occurs during the bringup process can happen only if the vSmart controllers and the vBond orchestrators know the serial and chassis numbers of the devices that are permitted in the network. Let's first define these two terms:

  • Serial number—​Each Viptela device has a serial number, which is a 40-byte number that is included in the device's certificate. For the vBond orchestrator and the vSmart controller, the certificate can be provided by Symantec or by an enterprise root CA. For the vEdge routers, the certificate is provided in the hardware's trusted board ID chip.
  • Chassis number—In addition to a serial number, each vEdge router is identified by a chassis number. Because the vEdge router is the only Viptela-manufactured hardware, it is the only Viptela device that has a chassis number. There is a one-to-one mapping between a vEdge router's serial number and its chassis number.

The vSmart controllers and vBond orchestrators learn the serial and chassis numbers during the initial configuration of these devices:

  • vSmart authorized serial numbers—The vManage NMS learns the serial numbers for all the vSmart controllers that are allowed to be in the network while it is creating a CSR and installing the signed certificate. You download these serial numbers to the vBond orchestrator, and the vBond orchestrator pushes them to the vSmart controller during the automatic authentication process.
  • vEdge authorized serial number file—This file contains the serial and chassis numbers of all the vEdge routers that are allowed to be in the network. You upload this file to the vBond orchestrator and vSmart controllers.

In addition to the device serial and chassis numbers, the automatic validation and authentication procedure depends on having each device configured with the same organization name. You configure this name on the vManage NMS, and it is included in the configuration file on all devices. The organization name must be identical on all the devices that belong to a single organization (the name is case-sensitive). The organization name is also included in the certificate for each device, which is created either by Viptela or by an enterprise root CA.

Authentication between the vSmart Controller and the vBond Orchestrator

From a functional point of view, the first two devices on the Viptela overlay network that validate and authenticate each other are the vSmart controller and the vBond orchestrator. This process is initiated by the vSmart controller.

s00034.pngWhen the vSmart controller comes up, it initiates a connection to the vBond orchestrator, which is how the vBond orchestrator learns about the vSmart controller. These two devices then automatically begin a two-way authentication process—the vSmart controller authenticates itself with the vBond orchestrator, and the vBond orchestrator authenticates itself with the vSmart controller. The two-way handshaking between the two devices during the authentication process occurs in parallel. However, for clarity, the figure here, which is a high-level representation of the authentication steps, illustrates the handshaking sequentially. If the authentication handshaking succeeds, a permanent DTLS communication channel is established between the vSmart and vBond devices. If any one of the authentication steps fails, the device noting the failure tears down the connection between the two devices, and the authentication attempt terminates.

The vSmart controller knows how to reach the vBond orchestrator, because one of the parameters that you provision when you configure it is the IP address or DNS name of the vBond orchestrator. The vBond orchestrator is primed to respond to requests from the vSmart controller because:

  • It knows that its role is to be the authentication system, because you included this information in the vBond configuration.
  • You downloaded the vSmart authorized serial numbers from the vManage NMS to the vBond orchestrator.

If the vBond orchestrator has not yet started when the vSmart controller initiates the authentication process, the vSmart controller periodically attempts to initiate a connection until it is successful.

Below is a more detailed step-by-step description of how the automatic authentication occurs between the vSmart controller and the vBond orchestrator.

To initiate a session between the vSmart controller and the vBond orchestrator, the vSmart controller initiates an encrypted DTLS connection to the vBond orchestrator. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots.

Over this encrypted channel, the vSmart controller and the vBond orchestrator authenticate each other. Each device authenticates the other in parallel. For our discussion, let's start with the vSmart controller authentication of the vBond orchestrator:

  1. The vBond orchestrator sends its trusted root CA signed certificate to the vSmart controller.s00036.png
  2. The vBond orchestrator sends the vEdge authorized serial number file to the vSmart controller.
  3. The vSmart controller uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the vSmart controller. If the two organization names match, the vSmart controller knows that the organization of the vBond orchestrator is proper. If they do not match, the vSmart controller tears down the DTLS connection.
  4. The vSmart controller uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vSmart controller knows that the certificate itself is valid. If the signature is incorrect, the vSmart controller tears down the DTLS connection.

After performing these two checks, the vSmart authentication of the vBond orchestrator is complete.

In the other direction, the vBond orchestrator​ authenticates the vSmart controller:

  1. The vSmart controller sends its trusted root CA signed certificate to the vBond orchestrator.s00037.png
  2. The vBond orchestrator uses its chain of trust to extract the vSmart controller's serial number from the certificate. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, the vBond orchestrator tears down the DTLS connection.
  3. The vBond orchestrator uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the vBond orchestrator. If the two organization names match, the vBond orchestrator knows that the organization of the vSmart controller is proper. If they do not match, the vBond orchestrator tears down the DTLS connection.
  4. The vBond orchestrator uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vBond orchestrator knows that the certificate itself is valid. If the signature is incorrect, the vBond orchestrator tears down the DTLS connection.

After performing these three checks, the vBond authentication of the vSmart controller is complete.

After the bidirectional authentication completes between the two devices, the DTLS connection between the vBond orchestrator and the vSmart controller transitions from being a temporary connection to being a permanent connection, and the two devices establish an OMP session over the connection.

In a domain that has multiple vSmart controllers for redundancy, this process repeats between each pair of vSmart and vBond devices. In coordination with the vBond orchestrator, the vSmart controllers learn about each other and they synchronize their route information. It is recommended that you connect the different vSmart controllers to the WAN network through different NAT devices for higher availability.

A vBond orchestrator has only as many permanent DTLS connections as the number of vSmart controllers in the network topology. These DTLS connections are part of the network's control plane; no data traffic flows over them. After all the vSmart controllers have registered themselves with the vBond orchestrator, the vBond orchestrator and the vSmart controllers are ready to validate and authenticate the vEdge routers in the Viptela network.

Authentication between vSmart Controllers

In a domain with multiple vSmart controllers, the controllers must authenticate each other so that they can establish a full mesh of permanent DTLS connection between themselves for synchronizing OMP routes. A vSmart controller learns the IP address of the other vSmart controllers from the vBond orchestrator.

A vSmart controller learns about the possibility of other vSmart controllers being present on the network during the authentication handshaking with the vBond orchestrator, when it receives a copy of the vSmart authorized serial number file. If this file has more than one serial number, it indicates that the network may, at some point, have multiple vSmart controllers.

As one vSmart controller authenticates with a vBond orchestrator, the vBond orchestrator sends the vSmart controller the IP address of other vSmart controllers it has authenticated with. If the vBond orchestrator later learns of another vSmart controller, it sends that controller's address to the other already authenticated vSmart controllers.

Then, the vSmart controllers perform the steps below to authenticate each other. Again, each device authenticates the other in parallel, but for clarity, we describe the process sequentially.

  1. vSmart1 initiates an encrypted DTLS connection to vSmart2 and sends its trusted root CA signed certificate to vSmart2.
  2. vSmart2 uses its chain of trust to extract the vSmart1's serial number. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, vSmart2 tears down the DTLS connection.s00094.png
  3. vSmart2 uses its chain of trust to extract the organization name from the certificate and compares it to the locally configured organization name. If the two organization names match, vSmart2 knows that the organization of vSmart1 is proper. If they do not match, vSmart2 tears down the DTLS connection.
  4. vSmart2 uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, vSmart2 knows that the certificate itself is valid. If the signature is incorrect, vSmart2 tears down the DTLS connection.

After performing these three checks, vSmart2​ authentication of vSmart1 is complete.

Now, vSmart1 authenticates vSmart2, performing the same steps as above.

  1. First, vSmart2 sends its trusted root CA signed certificate to vSmart1.
  2. vSmart1 uses its chain of trust to extract the vSmart2's serial number. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, vSmart1 tears down the DTLS connection.
  3. vSmart1 uses its chain of trust to extract the organization name from the certificate and compares it to the locally configured organization name. If the two organization names match, vSmart2 knows that the organization of vSmart2 is proper. If they do not match, vSmart1 tears down the DTLS connection.
  4. vSmart1 uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, vSmart2 knows that the certificate itself is valid. If the signature is incorrect, vSmart1 tears down the DTLS connection.

After performing these three checks, vSmart1​ authentication of vSmart2 is complete, and the temporary DTLS connection between the two devices becomes permanent.

After all the vSmart controllers have registered themselves with the vBond orchestrator, the vBond orchestrator and the vSmart controllers are ready to validate and authenticate the vEdge routers in the Viptela network.

Authentication between the vBond Orchestrator and a vEdge Router

When you deploy a vEdge router in the network, it first needs to do two things:

  • Establish a secure connection with the vManage NMS so that it can receive its full configuration.
  • Establish a secure connection with the vSmart controller can begin participating in the Viptela overlay network.s00033.png

So, when a vEdge device comes up, how does it automatically discover the vManage NMS and vSmart controller and establish connections with them? It does so with help from the vBond orchestrator. The initial configuration on the vEdge router contains the vBond system’s IP address (or DNS name). Using this information, the vEdge router establishes a DTLS connection with the vBond orchestrator, and the two devices authenticate each other to confirm that they are valid Viptela devices. Again, this authentication is a two-way process that happens automatically. When the authentication completes successfully, the vBond orchestrator sends the vEdge router the IP addresses of the vManage NMS and the vSmart controller. Then, the vEdge router tears down its connection with the vBond orchestrator and begins establishing secure DTLS connections with the othe two devices.

After you boot vEdge routers and manually perform the initial configuration, they automatically start looking for their vBond orchestrator. The vBond orchestrator and vSmart controllers are able to recognize and authenticate the vEdge routers in part because you have installed the vEdge authorized device list file on both these devices.

After you boot a vEdge router, you manually perform the initial configuration, at a minimum setting the IP address of DNS name of the vBond orchestrator. The vEdge router uses this address information to reach the vBond orchestrator. The vBond orchestrator is primed to respond to requests from a vEdge router because:

  • It knows that its role is to be the authentication system, because you included this information in the initial vBond configuration.
  • As part of the initial configuration, you installed the vEdge authorized serial number file on the vBond orchestrator.

If the vBond orchestrator has not yet started when a vEdge router initiates the authentication process, the vEdge router periodically attempts to initiate a connection until the attempt succeeds.

Below is a more detailed step-by-step description of how the automatic authentication occurs between the vBond orchestrator and a vEdge router.

First, the vEdge router initiates an encrypted DTLS connection to the public IP address of the vBond orchestrator. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots. The vBond orchestrator receives the vEdge router's original interface address and uses the outer IP address in the received packet to determine whether the vEdge router is behind a NAT. If it is, the vBond orchestrator creates a mapping of the vEdge router's public IP address and port to its private IP address.

Over this encrypted DTLS channel, the vEdge router and the vBond orchestrator proceed to authenticate each other. As with other device authentication, the vEdge router and vBond orchestrator authenticate each other in parallel. We start our discussion by describing how the vEdge router authenticates the vBond orchestrator:

  1. The vBond orchestrator sends its trusted root CA signed certificate to the vEdge router.​s00038.png
  2. The vEdge router uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the router itself. If the two organization names match, the vEdge routers knows that the organization of the vBond orchestrator is proper. If they do not match, the vEdge router tears down the DTLS connection.
  3. The vEdge router uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vEdge router knows that the certificate itself is valid. If the signature is incorrect, the vEdge router tears down the DTLS connection.

After performing these two checks, the vEdge router knows that the vBond orchestrator is valid, and its authentication of the vBond orchestrator is complete.

In the opposite direction, the vBond orchestrator authenticates the vEdge router:

  1. The vBond orchestrator sends a challenge to the vEdge router. The challenge is a 256-bit random value.s00039.png
  2. The vEdge router sends a response to the challenge that includes the following:
    • vEdge serial number
    • vEdge chassis number
    • vEdge board ID certificate
    • 256-bit random value signed by the vEdge router's private key
  3. The vBond orchestrator compares the serial and chassis numbers to the list in its vEdge authorized device list file. The numbers must match one of the number pairs in the file. If there is no match, the vBond orchestrator tears down the DTLS connection.
  4. The vBond orchestrator checks that the signing of the 256-bit random value is proper. It does this using the vEdge router's public key, which it extracts from the router's board ID certificate. If the signing is not correct, the vBond orchestrator tears down the DTLS connection.
  5. The vBond orchestrator uses the root CA chain from the vEdge routers board ID certificate to validate that the board ID certificate is itself valid. If the certificate is not valid, the vBond orchestrator tears down the DTLS connection.

After performing these three checks, the vBond orchestrator knows that vEdge router is valid, and its authentication of the router is complete.

When the two-way authentication succeeds, the vBond orchestrator performs the final step of its orchestration, sending messages to the vEdge router and the vSmart controller in parallel. To the vEdge router, the vBond orchestrator sends the following:

  • The IP addresses of the vSmart controllers in the network so that the vEdge router can initiate connections to them. The address can be public IP addresses, or for the controllers that are behind a NAT gateway, the addresses are a list of the public and private IP addresses and port numbers. If the vEdge router is behind a NAT gateway, the vBond orchestrator requests that the vEdge router initiate a session with the vSmart controller.
  • Serial numbers of the vSmart controllers that are authorized to be in the network.

To the vSmart controller, the vBond orchestrator sends the following:

  • A message announcing the new vEdge router in the domain.
  • If the vEdge router is behind a NAT gateway, the vBond orchestrator sends a request to the vSmart controller to initiate a session with the vEdge router.

Then, the vEdge router tears down the DTLS connection with the vBond orchestrator​.

Authentication between the vEdge Router and the vManage NMS

After the vEdge router and vBond orchestrator have authenticated each other, the vEdge router receives its full configuration over a DTLS connection with the vManage NMS:

  1. The vEdge router establishes a DTLS connection with the vManage NMS.
  2. The vManage server sends the configuration file to the vEdge router.
  3. When the vEdge router receives the configuration file and activates its full configuration.
  4. The vEdge router starts advertising prefixes to the vSmart controller.

If you are not using a vManage NMS, you can log in to the vEdge router and either manually load its configuration file or manually configure the router.

Below is a more detailed step-by-step description of how the automatic authentication occurs between a vEdge router and a vManage NMS.

First, the vEdge router initiates an encrypted DTLS connection to the IP address of the vManage NMS. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots. The vManage NMS receives the vEdge router's original interface address and uses the outer IP address in the received packet to determine whether the vEdge router is behind a NAT. If it is, the vManage NMS creates a mapping of the vEdge router's public IP address and port to its private IP address.

Over this encrypted DTLS channel, the vEdge router and vManage NMS proceed to authenticate each other. As with other device authentication, the vEdge router and vManage NMS authenticate each other in parallel. We start our discussion by describing how the vEdge router authenticates the vManage NMS:

  1. The vManage NMS sends its trusted root CA signed certificate to the vEdge router.​s00193.png
  2. The vEdge router uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the router itself. If the two organization names match, the vEdge routers knows that the organization of the vManage NMS is proper. If they do not match, the vEdge router tears down the DTLS connection.
  3. The vEdge router uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vEdge router knows that the certificate itself is valid. If the signature is incorrect, the vEdge router tears down the DTLS connection.

After performing these two checks, the vEdge router knows that the vManage NMS is valid, and its authentication of the vManage NMS is complete.

In the opposite direction, the vManage NMS authenticates the vEdge router:

  1. The vManage NMS sends a challenge to the vEdge router. The challenge is a 256-bit random value.s00192.png
  2. The vEdge router sends a response to the challenge that includes the following:
    • vEdge serial number
    • vEdge chassis number
    • vEdge board ID certificate (for a hardware vEdge router) or the signed certification (for a vEdge Cloud router)
    • 256-bit random value signed by the vEdge router's private key
  3. The vManage NMS compares the serial and chassis numbers to the list in its vEdge authorized device list file. The numbers must match one of the number pairs in the file. If there is no match, the vManage NMS tears down the DTLS connection.
  4. The vManage NMS checks that the signing of the 256-bit random value is proper. It does this using the vEdge router's public key, which it extracts from the router's board ID certificate. If the signing is not correct, the vManage NMS tears down the DTLS connection.
  5. The vManage NMS uses the root CA chain from the vEdge routers board ID certificate to validate that the board ID certificate is itself valid. If the certificate is not valid, the vManage NMS tears down the DTLS connection.

After performing these three checks, the vManage NMS knows that vEdge router is valid, and its authentication of the router is complete.

When the two-way authentication succeeds, the vManage server sends the configuration file to the vEdge router. When the vEdge router receives the configuration file, it activates its full configuration and starts advertising prefixes to the vSmart controller.

Authentication between the vSmart Controller and the vEdge Router

The last step in the automatic authentication process is for the vSmart controller and the vEdge router to authenticate each other. In this step, the vSmart controller performs authentication to ensure that the vEdge router belongs in its network, and the vEdge router also authenticates the vSmart controller.s00095.png When the authentication completes, the DTLS connection between the two devices becomes permanent, and the vSmart controller establishes an OMP peering session running over the DTLS connection. Then, the vEdge router starts sending data traffic over the Viptela overlay network.

Below is a more detailed step-by-step description of how the automatic authentication occurs between the vSmart controller and a vEdge router.

To initiate a session between a vSmart controller and a vEdge router, one of the two devices initiates an encrypted DTLS connection to the other. The encryption is provided by RSA. Each device automatically generates an RSA private key‒public key pair when it boots.

The authentication between a vSmart controller and a vEdge router is a two-way process that occurs in parallel. Let's start our discussion with how a vSmart controller authenticates a vEdge router:

  1. The vSmart controller sends a challenge to the vEdge router. The challenge is a 256-bit random value.s00040.png
  2. The vEdge router sends a response to the challenge that includes the following:
    • vEdge serial number
    • vEdge chassis number
    • vEdge board ID certificate
    • 256-bit random value signed by the vEdge router's private key
  3. The vSmart controller compares the serial and chassis numbers to the list in its vEdge authorized device list file. The numbers must match one of the number pairs in the file. If there is no match, the vSmart controller tears down the DTLS connection.
  4. The vSmart controller checks that the signing of the 256-bit random value is proper. It does this using the vEdge router's public key, which it extracts from the router's board ID certificate. If the signing is not correct, the vSmart controller tears down the DTLS connection.
  5. The vSmart controller uses the root CA chain from the vEdge routers board ID certificate to validate that the board ID certificate is itself valid. If the certificate is not valid, the vSmart controller tears down the DTLS connection.
  6. The vSmart controller compares the response with the original challenge. If the response matches the challenge that the vBond orchestrator issued, authentication between the two devices occurs. Otherwise, the vSmart controller tears down the DTLS connection.

After performing these three checks, the vSmart controller knows that vEdge router is valid, and its authentication of the router is complete.

In the other direction, the vEdge router authenticates the vSmart controller:

  1. The vSmart controller sends its trusted root CA signed certificate to the vEdge router.s00041.png
  2. The vEdge router uses its chain of trust to extract the vSmart controller's serial number from the certificate. The number must match one of the numbers in the vSmart authorized serial number file. If there is no match, the vEdge router tears down the DTLS connection.
  3. The Edge router uses its chain of trust to extract the organization name from the certificate and compares it to the organization name that is configured on the vEdge router. If the two organization names match, the vEdge router knows that the organization of the vSmart controller is proper. If they do not match, the vEdge router tears down the DTLS connection.
  4. The vEdge router uses the root CA chain to verify that the certificate has indeed been signed by the root CA (either Symantec or the enterprise CA). If the signature is correct, the vEdge router knows that the certificate itself is valid. If the signature is incorrect, the vEdge router tears down the DTLS connection.

After performing these three checks, the vEdge authentication of the vSmart controller is complete. The DTLS connection used for authentication now becomes a permanent (non-transient) connection, and the two devices establish an OMP session over it that is used to exchange control plane traffic.

This authentication procedure repeats for each vSmart controller and each vEdge router that you introduce into the overlay network.

Each vEdge router in the network must connect to at least one vSmart controller. That is, a DTLS connection must be successfully established between each vEdge router and one vSmart controller. The Viptela network has the notion of a domain. Within a domain, it is recommended that you have multiple vSmart controllers for redundancy. Then each vEdge router can connect to more than one vSmart controller.

Over the OMP session, a vEdge router relays various control plane–​related information to the vSmart controller so that the vSmart controller can learn the network topology:

  • The vEdge router advertises the service-side prefixes and routes that it has learned from its local static and dynamic (BGP and OSPF) routing protocols.
  • Each vEdge router has a transport address, called a TLOC, or transport location, which is the address of the interface that connects to the WAN transport network (such as the Internet) or to the NAT gateway that connects to the WAN transport. Once the DTLS connection comes up between the vEdge router and the vSmart controller, OMP registers the TLOCs with the vSmart controller.
  • The vEdge router advertises the IP addresses of any services that are located on its service-side network, such as firewalls and intrusion detection devices.

The vSmart controller installs these OMP routes in its routing database and advertises them to the other vEdge routers in the Viptela overlay network. The vSmart controller also updates the vEdge router with the OMP route information that it learns from other vEdge routers in the network. The vSmart controller can apply inbound policy on received routes and prefixes before installing them into its routing table, and it can apply outbound policy before advertising routes from its routing table.

  • Was this article helpful?