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:
apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: blue spec: config: '{ "cniVersion":"0.4.0", "name": "blue-net", "plugins": [ { "type": "jcnr", "args": { "instanceName": "bluenet", "instanceType": "virtual-router" }, "kubeConfig":"/root/.kube/config" } ] }'
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):
apiVersion: v1 kind: Pod metadata: name: podblue annotations: k8s.v1.cni.cncf.io/networks: | [ { "name": "blue", "interface":"net1", "cni-args": { "interfaceType":"veth", "dataplane":"dpdk", "mac":"aa:bb:cc:dd:ee:10", "ipConfig":{ "ipv4":{ "address":"192.168.11.10/24", "gateway":"192.168.11.1", "routes":["192.168.11.0/24"] }, "ipv6":{ "address":"abcd::192.168.11.10/112", "gateway":"abcd::192.168.11.1", "routes":["abcd::192.168.11.0/112"] } } } } ] spec: ...
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:
Configure the local fabric interface and the BGP protocol:
set interfaces ens2f0 unit 0 family inet address 10.10.10.11/24 set protocols bgp group overlay type internal set protocols bgp group overlay local-address 10.10.10.11 set protocols bgp group overlay local-as 64520 set protocols bgp group overlay neighbor 10.10.10.12 peer-as 64520
where
10.10.10.12/24
is the IP address of the BGP peer or neighbor router.Export the
inet
routes using the BGP protocol:set policy-options policy-statement send_direct term 1 from protocol direct set policy-options policy-statement send_direct term 1 then accept set policy-options policy-statement send_direct term reject then reject set protocols bgp group overlay export send_direct
Leak the routes from the
bluenet
routing instance to thedefault
routing instance:set groups cni routing-instances bluenet routing-options interface-routes rib-group inet blue_to_inet set routing-options rib-groups blue_to_inet import-rib bluenet.inet.0 set routing-options rib-groups blue_to_inet import-rib inet.0
Leak only the BGP routes matching prefix
192.168.12.0
frominet.0
to thebluenet
routing instance, where192.168.12.0/24
is the remote pod network:set policy-options policy-statement inet_to_blue term from_bgp from instance master set policy-options policy-statement inet_to_blue term from_bgp from protocol bgp set policy-options policy-statement inet_to_blue term from_bgp from route-filter 192.168.12.0/24 orlonger set policy-options policy-statement inet_to_blue term from_bgp then accept set policy-options policy-statement inet_to_blue term reject then reject set routing-options rib-groups inet_to_blue import-rib inet.0 set routing-options rib-groups inet_to_blue import-rib bluenet.inet.0 set routing-options rib-groups inet_to_blue import-policy inet_to_blue set groups cni routing-instances bluenet routing-options instance-import inet_to_blue
JCNR supports route leaking between virtual router routing instances for routes with interface, receive, resolve and table next-hops.