JCNR-vRouter

Read this chapter to understand details about JCNR-vRouter, the JCNR DPDK-based forwarding plane.

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:
  DDP is not supported on the Intel XL710 NIC
Interface Support:
- POD interfaces using virtio
- POD interfaces using kernel veth pair
- DPDK Virtual Function (VF) workload interfaces
- DPDK VF fabric trunk interfaces
  
  You define DPDK VF fabric trunk interfaces in the values.yaml file that is used in 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 cloud-native router, only those configured VLANs can pass by the physical interfaces.
  
  Physical interfaces defined in values.yaml as workload interfaces are equipped with only one receive and one transmit queue. The system assigns one forwarding CPU core to the task of polling the interface for traffic. Physical interfaces defined in values.yaml as fabric interfaces are equipped 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 fabric interface, the system allocates three receive and three transmit queues to the 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 (slave) 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 which 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.

How to Access vRouter CLI

The output of the command above 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 above 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).

Once on 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.

Packet Flow in vRouter

When you must understand something like a switch or router, it is useful to know what happens to packets as they flow through. This section describes the life of a packet in the vRouter. We use that description to illustrate how the vRouter MAC and bridge domain (BD) tables are populated and to introduce some of the CLI commands that you can use to see various parts of the vRouter from inside.

The flow chart below 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

As you can see, the vRouter makes a lot of decisions about a received packet to ensure that the packet is handled correctly. Let's look at some of what the vRouter does with a packet. You can see in the figure above that there are several choices made based on the VLAN or bridge domain (BD). One of the tables that vRouter consults for making forwarding decisions is the BD table. A small example of a BD table is shown below.

Table 1: BD Table
VLAN ID (KEY)	Interface ID List (Value)
1024	2,3,4
1042	4,5
1022	1
1044	6

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.

Closely related to the BD table is the MAC 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. We show an example below.

Table 2: MAC Table
MAC Address	VLAN ID	Interface ID	Hit Count
00:11:22:33:44:55	1024	2	123234
00:22:33:44:55:66	1042	4	823948
00:33:44:55:66:77	1022	1	45980
00:44:55:66:77:88	1044	6	86578

The primary purpose of the MAC table is to map which MAC addresses can be reached through which interface. 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 How to 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 examples below 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 below. 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 purel2cli Command

To see all the options of the purel2cli command in the vRouter CLI, execute the command with the --help option.

See the Current Status of Your Running vRouter

To see the status of the vRouter, enter the following command in the vRouter CLI:

The output from the command above looks like: root 127 93 99 Jul29 ? 82-20:31:49 /contrail-vrouter-dpdk --no-daemon --socket-mem=1024 1024 --allow=0000:01:10.1 --allow=0000:01:10.0 --l2_table_size=10240 --yield_option 0 --ddp --l2_mode

There are several things shown in the output:

Table 3: vRouter Status
Flag	Meaning
`--l2_mode`	The vRouter is running in L2 mode.
`--l2_table_size`	The current number of entries in the MAC table. The default size is 10240 entries.
`--allow=<PCI Id>`	The PCI ID of fabric and fabric workload interfaces. More than one ID can appear in the output. These IDs serve as an allowlist.
`--ddp`	Enable Intel DDP support. We enable DDP by default in the values.yaml file in the vRouter. Note: The Intel XL710 NIC does not support DDP.

Show MAC Table

The following command shows the MAC addresses that the vRouter has dynamically learned.

The output from the above command looks like:

Show Bridge Domain Table

The following command shows the VLAN to port mapping in the vRouter.

The output from the above command looks like:

You can use the following form of the purel2cli command to see the bridge domain table entry for a specific VLAN: purel2cli --vlan get <vlan-id>

Show L2 Statistics

There are several command variations of the purel2cli command that allow you to display and filter L2 statistics in the vRouter. The base form of the command is: purel2cli -- l2stats get <virtual_interface_ID> <VLAN_ID>. The table below shows the available command options and what they do. We follow the table with a sample output using one of the options.

Sample Command	Function
`purel2cli --l2stats get '' ''`	Get statistics for all virtual interfaces (vif) and all VLAN IDs.
`purel2cli --l2stats get '*' 100`	Get statistics for all vif that are part of VLAN 100
`purel2cli --l2stats get 1 '*'`	Get statistics for all VLANs for which interface 1 is a member
`purel2cli --l2stats get 1 100`	Get statistics for interface 1 and VLAN 100

As an example, the following command shows the L2 statistics for interface 2 and VLAN 1221:

Clear L2 Statistics

The following example shows commands that allow you to clear L2 statistics information from the vRouter.

You can clear the statistics from the vRouter with the purel2cli command in the form: purel2cli --clear <VLAN_ID>.

clears all statistics from all VLANs in the vRouter. clears all statistics for VLAN id 100.

The dropstats Command

vRouter keeps track of the packets it drops for any reason. The table below shows some of the most common reasons that vRouter would drop a packet. When you execute the dropstats command, the vRouter does not show a counter if the count for that counter is 0.

Table 4: Dropstats Counters
Counter Name	Meaning
`L2 bd table drop`	No interfaces in bridge domain
`L2 untag pkt drop`	Untagged packet arrives on trunk or sub-interface
`L2 Invalid Vlan`	Packet VLAN does not match interface VLAN
`L2 Mac Table Full`	No more entries available in the MAC table
`L2 ACL drop`	Packet matched firewall filter (ACL) drop rule
`L2 Src Mac lookup fail`	Unable to match (or learn) the source MAC address

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. First we show the available options, then we show some example output from the dpdkinfo command. You can only run the dpdkinfo command from within the vRouter-agent CLI.

dpdkinfo Command Usage

dpdkinfo

dpdkinfo Lcore Information

This command shows the Lcores assigned to DPDK VF fabric interfaces and the queue ID for each interface.

dpdkinfo Memory Pool Information

This command shows all of the memory pool information.

dpdkinfo Statistics Information

This command displays statistical information for a specific interface.

dpdkinfo Extended Statistics Information

This command displays extended statistical information for a specific interface.

Troubleshooting vRouter

For vRouter-agent debugging we use Introspect. You access the Introspect data at http://<host server IP>:8085. A sample of the data you can see is shown below.

Note:

We have grouped the output shown in the table below. Cloud-native router does not group or sort the output on live systems.

The page that displays when you go to http://<host server IP address>:8085 shows only a list of html links. The items on the list of links are shown in bold.

Table 5: Cloud-Native Router vRouter Debug
Group	Links and Description
Modules for contrail-vrouter-agent	agent.xml Shows agent operational data. Using this introspect, you can see the list of interfaces, VMs, VNs, VRFs, security groups,ACLs and mirror configurations. agent_ksync.xml Shows agent ksync layer for data objects such as interfaces and bridge ports. agent_profile.xml shows agent operdb, tasks, flows, and statistics summary. agent_stats_interval.xml View and set collection period for statistics. controller.xml Shows the connection status of the jcnr-controller (cRPD) cpuinfo.xml Shows the CPU load and memory usage on the compute node. ifmap_agent.xml Shows the current configuration data receved from ifmap. kstate.xml Shows data configured in the vRouter data path. mac_learning.xml Shows entries in vRouter-agent MAC learning table. sandesh_trace.xml Gives the different agent module traces such as oper, ksync, mac learning, and grpc. sandesh_uve.xml Lists all the user visible entitites (UVEs) in the vRouter-agent. The UVEs are used for analytics and telemetry. stats.xml Shows vRouter-agent slow path statistics such as error packets, trapped packets, and debug statistics. task.xml Shows vRouter-agent worker task details.

ON THIS PAGE