Configure Inter-Virtual Network Routing Through Route Targets

Virtual Networks and Routing Instances Overview

A routing instance is a collection of routing tables, interfaces, and routing protocol parameters. The set of interfaces in a routing instance belongs to the routing tables, and the routing protocol parameters control the information in the routing tables. A single routing instance might have multiple routing tables—for example, unicast IPv4, unicast IPv6, and multicast IPv4 routing tables can exist in a single routing instance.

In virtual networking, a physical networking device might be split into multiple virtual routers, each with its own interfaces, routing instances, and associated virtual networks. Routing instances isolate traffic within a VirtualNetwork. If you want to route traffic between your virtual networks, you can define common route targets for those networks.

Route Target Overview

Route targets enable your virtual networks (namespaces) to exchange virtual routing and forwarding (VRF) routing tables in an MPLS (Multiprotocol Label Switching) configuration. A route target is a BGP Extended Communities Attribute that defines VPN membership. In other words, all routes defined within an Extended Communities Attribute are shared by other members of that VPN. You define the following two route targets in your VRF policy:

• Route-target import list: Defines a list of acceptable route targets for a VRF to import. When a provider edge (PE) router receives a route from another PE router, it compares the route targets attached to each route against the route-target import list defined for each of its VRFs. If no new route target matches the route targets defined in the import list, the VRF rejects the route.

• Route-target export list: Defines a list of route targets attached to every route advertised to other PE routers in your VPN.

Depending on your network configuration, the import and export lists might be identical. Typically, you do the following:

• Allocate one route target extended-community value per VPN.

• Configure the import list and the export list to include the same information: the set of VPNs comprising the sites associated with the VRF.

For more complicated configurations like hub-and-spoke VPNs, the route-target import list and the route-target export list might not be identical.

Enable Inter-Virtual Network Routing Through Route Targets with NAD

Establish route-target communities by defining matching route targets in your VirtualNetwork resource. This enables you to route traffic between your virtual networks (namespaces). Add route targets to a VirtualNetwork resource object using NAD (Network Attachment Definition).

The Network Attachment Definition (NAD) is a Custom Resource Definition (CRD) specified by the Kubernetes Network Plumbing Working Group. This CRD, NAD, defines how a pod attaches to a logical (virtual) or physical network referenced by the NAD object. In other words, the NAD object contains networking information (namespace, subnet, routing, interface) for a pod in relation to a network. You can define the following options for your VirtualNetwork resource in the annotations of a NAD YAML:

• ipamV4Subnet (optional): Specifies an IPv4 CIDR subnet for your VirtualNetwork.

• ipamV6Subnet (optional): Specifies an IPv6 CIDR subnet for your VirtualNetwork.

• routeTargetList (optional): Lists import and export route targets.

• importRouteTargetList (optional): Lists route targets used as import.

• exportRouteTargetList (optional): Lists route targets used as export.

• fabricSNAT (optional): Toggles connectivity to the underlay network by port mapping. The default setting is false.

Additionally, the NAD-Controller monitors NAD object creation events and creates and updates a VirtualNetwork accordingly. The juniper.net/networks-status annotation of the NAD updates success or error events during VirtualNetwork creation.

Note:

If you do not specify a juniper.net/networks annotation, then Cloud-Native Contrail Networking treats the NAD resource as a third party resource and does not create Contrail resources (such as VirtualNetwork and Subnet).

The following example shows a sample NAD YAML file with several annotations defined:

Example 1:

The NAD-Controller automatically updates the VirtualNetwork resource after you apply your NAD YAML file.

The following example shows a VirtualNetwork resource with several route-target options defined:

Example 2:

After establishing your desired network annotations, you can create a pod with custom interfaces that are attached to networks with shared route targets. These networks route traffic between one another as a result of the shared route targets defined in the NAD and VirtualNetwork objects.

The following example shows a pod YAML file with custom interfaces derived from the annotations in Example 1.

Example 3:

Note that the two interfaces shown in the preceding code example (nasa-network1 and nasa-network2) attach to different networks. As a result of NAD functionality, you can route traffic between these networks.