[ovs-dev] [PATCH v2 12/12] work on packet aware test

Jan Scheurich jan.scheurich at ericsson.com
Tue Jun 20 13:32:52 UTC 2017


Hi Ben,

Thanks for working on updating the PTAP test. I have found and fixed three main issues that prevented the triangular bridge test from working.

1. The tunnel ports in (formerly packet-type-aware) bridge br-in2 had to be declared with "packet-type=ptap".
2. A typo in the peer name for patch port p0-1 caused packets to be dropped.
3. The remote tunnel end-point MAC addresses were not aligned with the MAC addresses of the br-pX bridge local ports, causing the tunnel port lookup to fail on the receiving side.

All the rest was just adapting to datapath flow consequences of switching back to patch ports and using port names.

Trouble-shooting (typically config) issues with (native) tunneling is one of the most tedious tasks in OvS. It almost always requires use of a debugger to understand why packets are dropped or not recognized as tunnel packets. This is for sure an area that would deserve better trouble-shooting support (DBG logging and/or ovs-appctl commands). Something for the future!

Anyway, the attached patch, replacing your original patch 12/12, seems to work on top of the latest v3 series plus your port name patches.

There is one anomaly that I have noticed inspecting the datapath flows generated for packet received from L3 GRE tunnels in ptap or legacy-l3 mode:

tunnel(src=10.0.0.2,dst=10.0.0.1,flags(-df-csum)),recirc_id(0),in_port(gre_sys),packet_type(ns=1,id=0x800),eth_type(0x0800),ipv4(dst=192.168.10.10,frag=no), packets:1, bytes:84, used:0.0s, actions:push_eth(src=00:00:00:00:00:00,dst=aa:55:aa:55:00:01),n1
tunnel(src=20.0.0.3,dst=20.0.0.2,flags(-df-csum)),recirc_id(0),in_port(gre_sys),packet_type(ns=1,id=0x800),eth_type(0x0800),ipv4(dst=192.168.10.10,tos=0/0x3,frag=no), packets:1, bytes:84, used:0.0s, actions:tnl_push(tnl_port(gre_sys),header(size=38,type=3,eth(dst=aa:55:00:00:00:01,src=aa:55:00:00:00:02,dl_type=0x0800),ipv4(src=20.0.0.2,dst=20.0.0.1,proto=47,tos=0,ttl=64,frag=0x4000),gre((flags=0x0,proto=0x800))),out_port(br-p2))

These include an eth_type(0x0800) match even though their packet type is not ethernet: packet_type(ns=1,id=0x800). Apparently this does not cause lookup failure. I believe this must be a bug in [PATCH v3 4/7] userspace: Handling of versatile tunnel ports, which I will have a look at now.

BR, Jan


More information about the dev mailing list