Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Deploy VirtualNetworkRouter in Cloud-Native Contrail Networking

SUMMARY Cloud-Native Contrail® Networking supports the VirtualNetworkRouter (VNR) construct. This construct provides connectivity between VirtualNetworks.

VirtualNetworkRouter Overview

Typically, VirtualNetwork (VN) traffic is isolated to maintain tenant separation. In Cloud-Native Contrail Networking (CN2), VirtualNetworkRouter (VNR) performs route leaking. Route leaking establishes connectivity between VirtualNetworks by importing routing instances (RI) and the routing tables associated with these instances. As a result, devices in one routing table can access resources from devices in another routing table.

The VNR provides connectivity for the following two common network models:

  • Mesh: Pods in all connected VirtualNetworks communicate with each other.

  • Hub-spoke: VirtualNetworks connect to two different VNR types (spoke, hub). VirtualNetworks connected to spoke-type VNRs communicate with VirtualNetworks connected to hub-type VNRs and vice versa. VirtualNetworks connected to spoke VNRs cannot communicate with other VirtualNetworks attached to spoke VNRs.

VNR is a Kubernetes construct deployed within CN2.

VirtualNetworkRouter Use Cases

The following examples are common use cases that demonstrate the functionality of VNR in CN2.

Mesh VNR That Connects Two or More Virtual Networks in the Same Namespace

  1. Figure-1: The user creates VN1 and VN2 in namespace-1. Pods in VN1 cannot connect to pods in VN2. This is the default behavior of VirtualNetworks in CN2.
  2. Figure-2: The user defines a VNR of type mesh that selects VN1 and VN2. This VNR allows Pods in VN1 to communicate with Pods in VN2 and vice-versa.
  3. Figure-3: Pods in VN1 connect to Pods in VN2. The route-target of VNR is importExported to both VirtualNetworks.

Back to VirtualNetworkRouter Use Cases

Add New Virtual Networks Within the Same Namespace to an Existing Mesh-Type VNR

  1. Figure-1: Two VirtualNetworks (VN1, VN2) connect to VNR in namespace-1.
  2. Figure-2: The user creates two new VirtualNetworks (VN3, VN4).
  3. Figure-3: VN3 and VN4 connect to VNR. As a result, all VirtualNetworksconnected to the VNR receive connectivity.

Back to VirtualNetworkRouter Use Cases

Two Mesh VNRs in the Same Namespace

  1. Figure 1 and Figure 2: VNR-web and VNR-db of type mesh already exist in namespace-1. Only VNRs connected to respective VNRs communicate with each other.

  2. Figure 1 and Figure 2: VNR-web and VNR-db communicate with each other.

  3. Figure 3: All VirtualNetworks connected to both VNR-web and VNR-db communicate with each other.

Back to VirtualNetworkRouter Use Cases

Two Mesh VNRs with Different Namespaces

  1. Figure 1: VNR-web selects VN1 and VN2. Pods in VN1 and VN2 communicate with each other. VN1 and VN2 cannot communicate with VN3 or VN4.

  2. Figure 2: VNR-db selects VN3 and VN4. Pods in VN3 and VN4 communicate with each other. VN3 and VN4 cannot communicate with VN1 or VN2.

  3. Figure 3: The user updates VNR-web to select VNR-db.

  4. Figure 3: The user updates VNR-db to select VNR-web.

  5. Figure 3: Since two VNRs select each other, VNR-web's RT (route target) is added to VN3 and VN4. VNR-db's RT is added to VN1 and VN2. Pods in VN1, VN2, VN3, and VN4 communicate with each other.

    Note:

    VNRs select VNs based on matchExpression labels in a virtualNetworkSelector spec. For example, in the illustration above, VNR-web in namespace-1 selects VN1 and VN2 based on the label vn: web from namespace-1. A virtualNetworkSelector only looks for matching labels within it's own namespace.

Back to VirtualNetworkRouter Use Cases

Hub and Spoke VNRs in the Same Namespace

  • Figure-1: Pods in VN1 cannot communicate with pods in VN2. VN1 and VN2 cannot communicate with VN3.

  • Figure-2: The user creates a VNR of type "spoke" and "hub." VNR-spoke and VNR-hub import each other's RTs.

  • Figure-3: VNR-spoke and VNR-hub's RTs are added to VN1, VN2, and VN3 because they import each others' RTs. As a result, pods in VN1 and VN2 communicate with VN3. Pods in VN1 and VN2 cannot communicate with each other.

Back to VirtualNetworkRouter Use Cases

Hub and Spoke VNRs in Different Namespaces

Back to VirtualNetworkRouter Use Cases

Same Virtual Networks Under Multiple VNRs

  • Figure 1: Pods in VN1 and VN2 cannot communicate with each other. Also resources on VN3, VN4 can communicate with each other.

  • Figure 2: You create a VNR-spoke by selecting VN1 and VN2. You create a VNR-hub by selecting VN3 and VN4. You create a VNR-mesh by selecting VN3 and VN4.

  • Figure 3: VNR-spoke ensures that VN1 and VN2 cannot communicate each other, VNR-hub lets VN1 and VN2 reach VN3 and VN4, and VNR-mesh enables communication between VN3 and VN4.

Back to VirtualNetworkRouter Use Cases

Use Case Explanation

This section comprises the following two VNR use cases along with end-to-end explanations of each use case:

Standard Use Case: Single VNR Connecting Two Virtual Networks

This use case comprises the following:

  • Two VirtualNetworks (vn-1 and vn-2) in namespace ns-single-mesh. Both virtual networks have the label vn: web. Each VirtualNetwork contains a single pod. The VirtualNetwork vn-1 contains pod-vn-1. The VirtualNetwork vn-2 contains pod-vn-2.

  • A type: mesh VNR with the name vnr-1. This VNR establishes connectivity between the two VirtualNetworks using matchExpressions and vn: web. he VNR imports the RI and routing table of vn-1 to vn-2 and vice versa. Since vnr-1 is a mesh-type VNR, all pods in connected VirtualNetworks communicate with each other.

Update Use Case: Single VNR Connecting Two Additional Virtual Networks

This use case is similar to the standard use case, except that in this use case the user updates the YAML file with an additional type: mesh VNR to connect two new VirtualNetworks (vn-3 and vn-4) in namespace ns-single-mesh. Note the following:

  • The VNR shown has the name vnr-2 in namespace ns-single-mesh with matchExpressions: db, middlware.

  • The VirtualNetwork vn-3 has the label vn: db, and vn-4 has the label vn: middleware.

As a result, vnr-2 imports the RI and routing table of vn-3 to vn-4 and vice versa.

VirtualNetworkRouter Configuration

The following section provides YAML configuration information for the following resources:

API Type (Schema)

Mesh VNR

The preceding YAML file is an example of a mesh VNR with the name vnr-1 in namespace frontend, with the labels vnr: web and ns: frontend. This VNR imports its route-target to any VNR in the namespace backend with matchLabel vnr: db.

Spoke VNR

The preceding YAML file is an example of a spoke VNR with the name vnr-1 in namespace frontend with the labels vnrgroup: spokes and ns: frontend. This VNR imports its route-targets to any VNR in the namespace backend with matchLabel vnrgroup: hubs.

Hub VNR

The preceding YAML file is an example of a hub VNR with the name vnr-2 in the namespace backend with labels vnrgroup: hubs and ns: backend. This VNR imports its route-targets to any VNR in the namespace frontend with matchLabels vnrgroup: spokes.