JCNR-vRouter

Benefits of JCNR vRouter

• Integration of the DPDK into the JCNR-vRouter:

  • Forwarding plane provides faster forwarding capabilities than kernel-based forwarding

  • Forwarding plane is more scalable than kernel-based forwarding

  • Support for the following NICs:

    • Intel E810 (Columbiaville) with Intel Adapter Virtual Function (IAVF) and Dynamic Device Personalization (DDP)

    • Intel XL710 (Fortville) with Intel Adapter Virtual Function (IAVF)

    Note:

    Dynamic Device Personalization (DDP) is not supported on the Intel XL710 NIC

  • Support for the following drivers on Intel XL710 NICs:

    • Intel Adapter Virtual Function (IAVF)

    • Linux base driver i40E

• Interface Support:

  • Pod interfaces using virtio

    You define these DPDK-enabled vhost-based user socket interfaces as workload interfaces in the values.yaml file. The system maintains the socket details for all active interfaces of this type in the /dpdk directory of the workload container. You usually define this type of pod interfaces as trunk interfaces rather than access interfaces.

  • Pod interfaces using kernel veth pair

    You define pod interfaces with kernel veth pairs in the values.yaml file as access interfaces so the pod can pass traffic through the kernel rather than using DPDK.

  • DPDK Virtual Function (VF) workload interfaces

    You define the DPDK VF fabric trunk interfaces in the values.yaml file that is used in the vRouter deployment. This makes JCNR aware of the names of the interfaces, their MAC addresses, and their PCI slot ID.

  • DPDK VF fabric trunk interfaces

    You define the DPDK VF fabric trunk interfaces in the values.yaml file that is used in the vRouter deployment. This makes JCNR aware of the names of the interfaces, their MAC addresses, and their PCI slot ID. To keep traffic flows manageable, we apply VLAN filtering to the physical interfaces. When you configure VLANs for use with the cloud-native router, only the configured VLANs can pass through the physical interfaces.

  • Physical Function (PF) workload interfaces

    You define PF workload interfaces in the values_l3.yaml file. The system equips each PF workload interfaces with only one receive and one transmit queue. The system assigns one forwarding CPU core to the task of polling the interface for traffic.

  • PF fabric interfaces

    You define PF fabric interfaces in the values.yaml file. The system equips each PF fabric interface with as many receive and transmit queues as you assign forwarding CPU cores to handle the polling. For example, if you assign three forwarding CPU cores to the PF fabric interface, the system allocates three receive and three transmit queues to the PF fabric interface.

  • No vhost0 interface when run in L2 mode

    vRouter-agent detects L2 mode in values.yaml, so does not wait for the vhost0 interface to come up before completing installation. There is no vhost interface add message sent so the vRouter doesn't create the vhost0 interface.

• Interface Bonding

  DPDK vRouter supports interface bonding in active/standby mode on DPDK VF fabric interfaces. The values.yaml file specifies the interface names, mode value, and primary and secondary interface designations. DPDK contains a library with its own bonding driver that it uses for bonding. In operation, the vRouter uses the primary interface to pass traffic. If the primary link goes down, the secondary interface in the pair passes traffic until the primary interface reconnects.

• Pod DPDK Interfaces

  JCNR-vRouter supports virtio communication to the POD application. The JCNR-CNI allocates unique socket directories that it passes to Pod applications and to vRouter. JCNR-CNI ensures that one Pod cannot access the resources of another Pod through isolation of vhost sockets and Pod volume mounts.

• Pod Kernel Interfaces

  JCNR supports the veth interface type to communicate with pod applications that use the Linux Kernel's networking stack.

Access vRouter CLI

The output of the command looks like:

To access the vRouter-agent CLI, you use the full pod name from your system in the following command:

The output of the command looks like: Defaulted container "contrail-vrouter-agent" out of: contrail-vrouter-agent, contrail-vrouter-agent-dpdk, contrail-vrouter-telemetry-exporter, contrail-init (init), contrail-vrouter-kernel-init-dpdk (init).

After you access the vRouter CLI, there are a number of commands that you can run to monitor and troubleshoot the system. We illustrate some of the available commands in Monitoring vRouter with CLI Commands.

L2 Mode Packet Flow in vRouter

To understand a switch or router, you must know what happens to packets as they flow through. This section describes the life of a packet in the vRouter when deployed in L2 mode. In this section, we show how the vRouter MAC and bridge domain (BD) tables are populated and introduces some of the CLI commands that you can use to see various parts of the vRouter from inside.

The flowchart Figure 1 illustrates one possible generic packet flow through cloud-native router. It does not cover all possible interactions with the packet.

Figure 1: The Life of a Packet in vRouter

The vRouter makes a lot of decisions about a received packet to ensure that the packet is handled correctly. Let's look at what the vRouter does with a packet. You can see in Figure 1 that there are several choices made based on the VLAN or BD. One of the tables that vRouter consults for making forwarding decisions is the Table 1.

The BD table tells the vRouter which interfaces can carry traffic with a specific VLAN ID. Thus, the VLAN ID serves as the key for the table while the Interface ID List serves as the values for each entry.

The Table 2 is closely related to the BD table. The MAC table uses the MAC address and VLAN ID as a key pair. Then, the Interface ID and hit count serve as the values for each entry in the table as shown in this section.

The primary purpose of the MAC table is to map which MAC addresses can be reached through which interface. The vRouter makes entries in and consults the MAC table while processing packets.

Monitoring vRouter with CLI Commands

In the vRouter, CLI commands are useful for troubleshooting and monitoring purposes. As mentioned in Access vRouter CLI, you can access the CLI of the vRouter. By executing commands in that CLI, you can learn about various aspects of the running vRouter. The following examples assume that you have already connected to the vRouter CLI. The commands that we show in this section do not show a command prompt so that you can copy and paste them into your own vRouter.

We use the purel2cli command in most of the examples in this setion. The command has more options than we show in the examples. In addition, the purel2cli has a help command that you can use to see the available options.

The dropstats Command

The vRouter tracks the packets that it drops and includes the reason for dropping them. Table 5shows the common reasons for vRouter to drop a packet. When you execute the dropstats command, the vRouter does not show a counter if the count for that counter is 0.

Example output from the dropstats command looks like:

The dpdkinfo Command

The dpdkinfo command provides insight into the status and statistics of DPDK. The dpdkinfo command has many options. The following sections describe the available options and the example output from the dpdkinfo command. You can run the dpdkinfo command only from within the vRouter-agent CLI.

Troubleshooting vRouter

For vRouter-agent debugging, we use Introspect. You can access the Introspect data at http://<host server IP>:8085. Table 6 shows a sample of the Introspect data..