Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Virtual Routing Instance (VRF-Lite)

SUMMARY Read this topic to understand the implementation of virtual routing instances in JCNR.

Virtual routing instances allow administrators to divide the cloud-native router into multiple independent virtual routers, each with its own routing table. Splitting a device into many virtual routing instances isolates traffic traveling across the network without requiring multiple devices to segment the network. You can use virtual routing instances to isolate customer traffic on your network and to bind customer-specific instances to customer-owned interfaces. Virtual routing and forwarding (VRF) is often used in conjunction with Layer 3 subinterfaces, allowing traffic on a single physical interface to be differentiated and associated with multiple virtual routers. Each logical Layer 3 subinterface can belong to only one routing instance. Review the Virtual Router Instances topic for more information.

Configuration

You can create a virtual routing instance in JCNR via a network attachment definition (NAD) manifest. Here is an example NAD to create a bluenet virtual router routing instance:

Note the instanceType is set to virtual-router. Refer to JCNR Use-Cases and Configuration Overview for more information on NAD.

Here is an example configuration for a podblue pod with an interface (192.168.11.10/24) attached to the blue network (output is trimmed for brevity):

As you apply the NAD and the pod manifests using the kubectl apply -f manifest command, the bluenet routing instance and bluenet.inet.0 routing table is created in the JCNR controller. You can configure JCNR to enable communication from podblue to pods on the remote network. Additional cRPD configuration can be perfomed by accessing the cRPD shell. Here is an example cRPD configuration:

  1. Configure the local fabric interface and the BGP protocol:

    where 10.10.10.12/24 is the IP address of the BGP peer or neighbor router.

  2. Export the inet routes using the BGP protocol:

  3. Leak the routes from the bluenet routing instance to the default routing instance:

  4. Leak only the BGP routes matching prefix 192.168.12.0 from inet.0 to the bluenet routing instance, where 192.168.12.0/24 is the remote pod network:

Note:

JCNR supports route leaking between virtual router routing instances for routes with interface, receive, resolve and table next-hops.