Cloud-Native Router L3 Features

Starting in Juniper Cloud-Native Router Release 22.4, you can deploy and operate Juniper Cloud-Native Router in either L2 or L3 mode. You control the deployment mode by editing the appropriate values.yaml file prior to deployment.

To deploy the cloud-native router in L2 mode, retain or modify the values in the file Juniper_Cloud_Native_Router_version-number/helmchart/values.yaml.

Throughout the rest of this chapter we identify those features that are only available in L2 mode by beginning the feature name with L2.

In L2 mode, the cloud-native router behaves like a switch and so performs no routing functions and runs no routing protocols. The pod network uses VLANs to direct traffic to various destinations.

To deploy the cloud-native router in L3 mode, retain or modify the values in the file Juniper_Cloud_Native_Router_version-number/helmchart/values_L3.yaml,

In L3 mode, the cloud-native router behaves like a router and so performs routing functions and runs routing protocols such as ISIS, BGP, OSPF, and segment routing-MPLS. In L3 mode, the pod network is divided into an IPv6 underlay network and an IPv4 or IPv6 overlay network. The IPv6 underlay network is used for control plane traffic.

Starting in Juniper Cloud-Native Router Release 22.4, you control the types of traffic with the use of security groups when you use cloud-native router in L3 mode.

A security group is a container for security group rules. Security groups and security group rules allow administrators to specify the type of traffic that passes through an interface port. When you create a pod in a virtual network (VN), you can associate a security group with the pod and its virtual machine interface (VMI). The VMI is the interface connecting the pod to the vrouter-dpdk. When the cloud-native router launches the pod, it applies the rules in the security group to the pod's VMI port. If you do not specify a security group for the pod, the cloud-native router associates a default security group with the pod's VMI. The default security group rule is to allow all traffic to and from the port. The default security group allows both ingress and egress traffic. Security rules can be added to the default security group to change the traffic behavior.

You can apply each rule in the security group to either ingress or egress traffic. Ingress traffic is the traffic coming to the pod's VMI. Egress traffic is the traffic that leaves the pod through the VMI.

Juniper Cloud-Native Router supports the following types of interfaces:

• Agent interface

  vRouter has only one agent interface. The agent interface enables communication between the vRouter-agent and the vRouter. On the vRouter CLI when you issue the vif --list command, the agent interface looks like this:

• Data Plane Development Kit (DPDK) Virtual Function (VF) workload interfaces

  These interfaces connect to the radio units (RUs) or millimeter-wave distributed units (mmWave-DUs) On the vRouter CLI when you issue the vif --list command, the DPDK VF workload interface looks like this:

• DPDK VF fabric interfaces

  DPDK VF fabric interfaces, which are associated with the physical network interface card (NIC) on the host server, accept traffic from multiple VLANs. On the vRouter CLI when you issue the vif --list command, the DPDK VF fabric interface looks like this:

• Active or standby bond interfaces

  Bond interfaces accept traffic from multiple VLANs. A bond interface runs in the active or standby mode (mode 0).

  On the vRouter CLI when you issue the vif --list command, the bond interface looks like this:

• Pod interfaces using virtio and the DPDK data plane

  Virtio interfaces accept traffic from multiple VLANs and are associated with pod interfaces that use virtio on the DPDK data plane.

  On the vRouter CLI when you issue the vif --list command, the virtio with DPDK data plane interface looks like this:

• Pod interfaces using virtual Ethernet (veth) pairs and the DPDK data plane

  Pod interfaces that use veth pairs and the DPDK data plane are access interfaces rather than trunk interfaces. This type of a pod interface allows traffic from only one VLAN to pass.

  On the vRouter CLI when you issue the vif --list command, the veth pair with DPDK data plane interface looks like this:

• VLAN sub-interfaces

  Starting in Juniper Cloud-Native Router Release 22.4, the cloud-native router supports . VLAN sub-interfaces are like logical interfaces on a physical switch or router. When we run the cloud-native router in L2 mode, each sub-interface must be associated with a specific VLAN. On the JCNR-vRouter, a VLAN sub-interface look like this:

• Physical Function (PF) workload interfaces

• PF fabric interfaces

Note:

vRouter does not support the vhost0 interface when run in L2 mode.

The vRouter-agent detects L2 mode in values.yaml during deployment, so does not wait for the vhost0 interface to come up before completing installation. The vRouter-agent does not send a vhost interface add message so the vRouter doesn't create the vhost0 interface.

In L3 mode, the vhost0 interface is present and functional.

Pods are the Kubernetes element that contains the interfaces used in cloud-native router. You control interface creation by manipulating the value portion of the key:value pairs in YAML configuration files. The cloud-native router uses a pod-specific file and a network attachment device (NAD)-specific file for pod and interface creation. During pod creation, Kubernetes consults the pod and NAD configuration files and creates the needed interfaces from the values contained within the NAD configuration file.

You can see example NAD and pod YAML files in the L2 - Add User Pod with Kernel Access to a Cloud-Native Router Instance and L2 - Add User Pod with virtio Trunk Ports to a Cloud-Native Router Instance examples.

A security group is a construct for holding security rules. When you create a pod in a virtual network, the cloud-native router associates a security group with the Virtual Management Interface (VMI). The VMI is the interface connecting the Pod and the vRouter container. Each rule in the security group is applied to either ingress or egress traffic. Ingress traffic is the traffic coming from the Pod over the VMI. Egress traffic is the traffic going from the VMI to the Pod.

With the Cloud-Native Router, you configure networking policy, including security groups, locally using gRPC messages from the cloud-native router controller. You can configure security groups using API calls, NETCONF, or the cloud-native router controller CLI by using the edit routing-options flow security-group security group name rule rule name command hierarchy.

When you use bond interfaces on cascaded nodes in L2 mode, you can make an API call to force traffic to switch from the active interface to the standby interface.

The Juniper Cloud-Native Router contains support for MPLS routing protocols. You use the JCNR-controller, or cRPD, to configure MPLS. The cRPD then sends the configuration to the vRouter-agent, using gRPC. The vRouter-agent then converts the configuration to network policies that it imlements in the vRouter. The cloud-native router supports the following MPLS-based routing protocols:

• L3 MPLS VPN (MPLS)–L3 MPLS VPNs are also known as BGP/MPLS VPNs because BGP is used to distribute VPN routing information across the provider’s backbone, and MPLS is used to forward VPN traffic across the backbone to remote VPN sites. The cloud-native router can particpate as a sending, receiving, or transit router using the MPLS protocol

• Segment Routing-MPLS (SR-MPLS)–Segment routing is a control-plane architecture that enables an ingress router to steer a packet through a specific set of nodes and links in the network without relying on the intermediate nodes in the network to determine the actual path it should take. SR-MPLS employs segment routing in MPLS. The cloud-native router can participate as a sending, receiving or transit router in SR-MPLS networks.

• MPLS over UDP (MPLSoUDP)–MPLSoUDP is an overlay technology that encapsulates MPLS packets within UDP packets to traverse through some networks that do not support native MPLS or SR-MPLS. The cloud-native router can participate as a sending, receiving, or transit router using MPLSoUDP.