Tunneling App¶

Ingress Processing¶

The classification flow should match against the tunnel in_port, a port of a specific segmentation id and tunnel’s virtual network key, according to which metadata will be set as network_id to identify incoming traffic being part of the network identified by the segmentation id.

An example classification flow, for two VMS, one is part of “admin-private” network, with segmentation id 0x13 and the second which is part of “private” network with segmentation id 0x49, the classification flows for these tunnels are:

dump-flows  br-int table=0

table=0, priority=100,in_port=4,tun_id=0x13 actions=load:0x3->OXM_OF_METADATA[],resubmit(,100)
table=0, priority=100,in_port=4,tun_id=0x49 actions=load:0x1->OXM_OF_METADATA[],resubmit(,100)

Currently in the ingress port lookup table (100), a match is done according to unique network id and vm’s port mac, where vm’s port key is set into reg7, and sent to table (105), the ingress conn-track table which passes the packet to ingress dispatch table

Set fields are: * reg7 <- Unique port key

dump-flows br-int table=100

table=100, priority=200,metadata=0x3,dl_dst=fa:16:3e:4d:a9:26 actions=load:0x2->NXM_NX_REG7[],resubmit(,105)
table=100, priority=200,metadata=0x1,dl_dst=fa:16:3e:bc:5b:08 actions=load:0x6->NXM_NX_REG7[],resubmit(,105)

Eventually the processing reaches table (115), the ingress dispatch table where the packet is matched against vm’s port’s key, and forwarded to the local vm port.

table=115, priority=100,reg7=0x6 actions=output:7

Egress Processing¶

A classification flow related to egress dispatching is set to be initially filtered by the security table, the flow sets port key and network id to reg6, and metadata ovs registers, respectively.

table=0, priority=100,in_port=8 actions=load:0xa->NXM_NX_REG6[],load:0x1->OXM_OF_METADATA[],resubmit(,5)

In the security table (5), the flow makes sure that the packet has originated from VM’s assigned address and prevent network address spoofing, making the packet goto the ‘connection track’ table (10).

table=5, priority=200,in_port=8,dl_src=fa:16:3e:95:bf:e9,nw_src=10.0.0.5 actions=resubmit(,10)

The ‘connection track’ table is used to create a connection track entry in Linux Kernel, and pass the packet to the service classification table. The service classification table filters out service oriented packets and pass the packet to the L2 lookup table, same as any other network type.

table=10, priority=1 actions=resubmit(,20)

Egress processing - L2 lookup¶

For locally originated traffic, the destination mac and network membership are translated to port key which is pushed to reg7, and passed to egress table 64, it will go through the connection track table and eventfully dispatched locally same as ingress traffic

table=75, priority=100,reg7=0xa actions=resubmit(,105)

For BUM replication on all known ports in a certain network traffic the following flow is set

table=55, priority=100,metadata=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=load:0xa->NXM_NX_REG7[],resubmit(,75),load:0x2->NXM_NX_REG7[],resubmit(,75),load:0->NXM_NX_REG7[],resubmit(,75)

Add remote port¶

A flow in the L2 lookup (55) is planted to translate VM mac and network membership to it’s port key in Reg7 and pass to egress table 75

table=55,priority=100,metadata=0x1,dl_dst=fa:16:3e:2d:cc:cd actions=load:0xc->NXM_NX_REG7[],resubmit(,75)

To forward the traffic via the tunnel port this flow is matched against the remote port key set in reg7 and is output through the tunnel port. 192.168.20.22 is the IP address of the destination compute host.

table=75,reg7=0xc actions=load:0x49->NXM_NX_TUN_ID[],load:0xC0A81416->NXM_NX_TUN_IPV4_DST[],output:8

Ingress processing¶

it will set the tunnel matching classification flow in table 0, and forward it to l2 port lookup table (100). The lookup mechanism should treat all port equally and filter according to port key.

table=0, priority=100,in_port=4,tun_id=0x13 actions=load:0x3->OXM_OF_METADATA[],resubmit(,100)
table=0, priority=100,in_port=4,tun_id=0x49 actions=load:0x1->OXM_OF_METADATA[],resubmit(,100)

Egress processing¶

it will set the flows to dispatch traffic going from the chassis to the remote port via the tunnel port and match locally dispatched traffic and set egress bum traffic flows.

table=75, priority=100,reg7=0xa actions=resubmit(,105)
table=100, priority=100,metadata=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=load:0xa->NXM_NX_REG7[],resubmit(,75),load:0x2->NXM_NX_REG7[],resubmit(,75),load:0->NXM_NX_REG7[],resubmit(,75)

Impact on other DF applications¶

The changes in the L2 application will affect the Provider Networks App. DNAT App, SNAT App et al.

According to the propsed design, L2 application deals with local chassis flows, while the ‘tunneling app’, ‘provider networks app’, ‘DNAT app’ and ‘SNAT app’, should deal with setting the flows for incoming/outgoing packets from/to external nodes.

Work Items¶

1. Create a new tunneling application.
2. Add tunneling app to “Plugin.sh”.
3. Remove the tunneling code from the l2 application.
4. Add unit tests, to reflect code changes.