Encap & Decap by Yilong Geng

Name

encap_decap

Location

contrib-projects/encap_decap

IP Cores

• NetFPGA-10G Specific cores
  • nf10_10g_interface
  • nf10_mdio
  • dma
  • nf10_nic_output_port_lookup
  • nf10_bram_output_queues
  • nf10_input_arbiter
  • nf10_encap
  • nf10_decap
• Xilinx AXI Peripheral
  • axi_interconnect
  • axi_uartlite
  • axi_timebase_wdt
• Microblaze Subsystem
  • MicroBlaze
  • lmb_v10
  • lmb_bram_if_cntlr
  • bram_block
  • proc_sys_reset
  • clock_generator
• Other
  • diff_input_buf

Software

• Driver and User Apps

Description

This is a testing project for the nf10_encap module and the nf10_decap module. This project added the nf10_encap module and the nf10_decap module into the NIC data path. It can add an IP header to the packet according to its output port, or remove the additional IP header of an packet if it's using the encapsulation protocol.

Block Diagram

Testing

In the following sections, we will show how to test the nf10_encap module and the nf10_decap module on the NetFPGA.

Testing Hardware

To run the test, you need two machines, A and B. Let's say Machine A is equipped with NetFPGA and Machine B is equipped with a third-party 10G NIC.

Download the encap_decap bitfile from contrib-projects/encap_decap/bitfiles/encap_decap.bit. (Refer to Production Test Manual if you don't know how to download the bitfile and/or not setup JTAG cable yet.)

Connect Machine A and Machine B using a 10G cable. Assume we use nf0 (the port nearest to the PCI Express) and nf1 on Machine A and eth1 on Machine B.

Build and Install the NIC Driver

Make the driver in the sw/host/driver directory and insert it as a module.

cd sw/host/driver
make
sudo insmod nf10.ko
dmesg

If everything went smoothly dmesg will output that nf10 device is ready.

Setup IP address

On Machine A

sudo ifconfig nf0 192.168.1.1

sudo ifconfig nf1 192.168.1.2

On Machine B

sudo ifconfig eth1 192.168.1.3

Test 1: Reading the configuration registers

The base address of the nf10_encap module in this project is 0x79c00000.

The base address of the nf10_decap module in this project is 0x79c20000.

On Machine A, under folder encap_decap/sw/host/apps

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x79c00040

AXI reg 0x79c00040=0x100ffb2

Encap_base_address + 0x40 is the configuration register of nf10_encap. This example says the "protocol" field we use for tunneling encapsulation is 0xb2, the "ttl" is 255, the "type of service" in the new IP header is 0x00. This also means we only encapsulate traffic going out of port nf0.

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x79c00000

AXI reg 0x79c00000=0x6401a8c0

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x79c00001

AXI reg 0x79c00001=0x6501a8c0

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x79c00002

AXI reg 0x79c00002=0x33445566

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x79c00003

AXI reg 0x79c00003=0x66771122

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x79c00004

AXI reg 0x79c00004=0x22334455

These four registers store the source/destination IP/MAC addresses for the new header added to the traffic going out of port nf0. In this example, the source IP address is 192.168.1.100, the destination IP address is 192.168.1.101, the source MAC address is 66:55:44:33:22:11, the destination MAC address is 77:66:55:44:33:22.

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x79c20000

AXI reg 0x79c20000=0xb20501

The above says the default first IP-MAC address pair is 192.168.1.100 --- 66:55:44:33:22:11.

Still on machine A, under folder arp_reply/sw/host/apps

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x78a00010

AXI reg 0x78a00010=0x6501a8c0

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x78a00011

AXI reg 0x78a00011=0x44556677

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x78a00012

AXI reg 0x78a00012=0x2233

The above says the default second IP-MAC address pair is 192.168.1.101 --- 77:66:55:44:33:22.

Test 2: Setting the configuration registers

On machine A, under folder arp_reply/sw/host/apps

[gengyl08@machine_A apps]$ sudo ./wraxi 0x78a00010 0x0a01a8c0

[gengyl08@machine_A apps]$ sudo ./wraxi 0x78a00011 0x12345678

[gengyl08@machine_A apps]$ sudo ./wraxi 0x78a00012 0x3210

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x78a00010

AXI reg 0x78a00010=0xa01a8c0

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x78a00011

AXI reg 0x78a00011=0x12345678

[gengyl08@machine_A apps]$ sudo ./rdaxi 0x78a00012

AXI reg 0x78a00012=0x3210

The above sets the second IP-MAC address pair to 192.168.1.10 --- 87:65:43:21:10:32 and tests it.

Test 3: ARP Reply

First ping machine A from machine B to validate the link connectivity.

[gengyl08@machine_B ~]$ ping 192.168.1.1

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=0.252 ms

64 bytes from 192.168.1.1: icmp_req=2 ttl=64 time=0.127 ms

64 bytes from 192.168.1.1: icmp_req=3 ttl=64 time=0.123 ms

Second ping on machine B some IP addresses in or out of the configuration registers in the ARP_Reply module to test its function. In theory, we would get no ICMP replies on machine B. But if the target IP address is in the configuration register, we would capture ARP replies on machine B.

On machine B:

[gengyl08@machine_B ~]$ ping 192.168.1.50

PING 192.168.1.50 (192.168.1.50) 56(84) bytes of data.

From 192.168.1.2 icmp_seq=1 Destination Host Unreachable

From 192.168.1.2 icmp_seq=2 Destination Host Unreachable

From 192.168.1.2 icmp_seq=3 Destination Host Unreachable

From 192.168.1.2 icmp_seq=4 Destination Host Unreachable


[gengyl08@machine_B ~]$ ping 192.168.1.10

PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.

--- 192.168.1.10 ping statistics ---

10 packets transmitted, 0 received, 100% packet loss, time 8999ms