[ovs-discuss] Does port addition order matter when bridge is in normal mode and contains a tunnel port?

Chaithan M.P. chaithanmp at yahoo.co.in
Sun Jul 16 01:16:18 UTC 2017


Hi,
I was looking at this simple tunneling example from the docs. 
http://docs.openvswitch.org/en/latest/howto/tunneling/

It says "Pings between any of the VMs should work, regardless of whether the VMs are running on the same host or different hosts".
But it seems to me that the order in which the ports are added to the bridge matters. If we add the tunnel port before adding the tap interfaces, then the datapath flows are setup such that the VMs on the same host may not be able to communicate with each other.
For example, ignoring the remote host, I just add 2 tap interfaces and a geneve tunnel port to the OVS bridge.I will use ofproto/trace to generate the datapath flows for a broadcast packet originating from one of the tap interfaces. 
In this first attempt, I will reverse the order from the above doc by adding the tunnel port first and then add the tap interfaces to the bridge. Please look at the Datapath actions that get generated. The packet is transformed by the set_tunnel action before outputting to port-4 (vport1). Is this expected? If I was pinging from vport2 to vport1 and this were an initial broadcast arp packet, it would have been dropped at vport1 as malformed and ping wouldn't succeed.
root at ubuntu:~# ovs-vsctl add-port br0 tun1 -- set interface tun1 type=geneve options:remote_ip=4.4.4.4root at ubuntu:~# ovs-vsctl add-port br0 vport1 -- add-port br0 vport2

root at ubuntu:~# ovs-ofctl show br0 (partial output)
 1(tun1): addr:0e:ba:6b:40:fb:52
 2(vport2): addr:a2:2c:48:53:e7:e5
 3(vport1): addr:fa:6a:41:04:ac:ee
root at ubuntu:~# ovs-dpctl show (partial output)
system at ovs-system: port 0: ovs-system (internal)
 port 1: br0 (internal) port 2: genev_sys_6081 (geneve) port 3: vport2 port 4: vport1 
root at ubuntu:~# ovs-appctl ofproto/trace br0 in_port=2,dl_dst=ff:ff:ff:ff:ff:ffBridge: br0Flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0000
Rule: table=0 cookie=0 priority=0OpenFlow actions=NORMALno learned MAC for destination, floodingoutput to kernel tunnel
Final flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0000Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000/0x1fff,dl_src=00:00:00:00:00:00,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0000Datapath actions: 1,set(tunnel(dst=4.4.4.4,ttl=64,flags(df))),2,4
-------------------
On the other hand, if I follow the order from the doc, i.e., add tap interfaces first and then the tunnel port, then the datapath actions look fine as the output to vport happens before the set_tunnel action and so ping would succeed.
root at ubuntu:~# ovs-vsctl add-port br1 vport3 -- add-port br1 vport4
root at ubuntu:~# ovs-vsctl add-port br1 tun2 -- set interface tun2 type=geneve options:remote_ip=5.5.5.5
root at ubuntu:~# ovs-ofctl show br1 (partial output) 1(vport3): addr:0e:9c:cb:2e:3c:c2
 2(vport4): addr:26:7f:e7:2c:3c:6a
 3(tun2): addr:4e:f4:ec:6e:9f:a3
root at ubuntu:~# ovs-dpctl show (partial output)
system at ovs-system: port 0: ovs-system (internal)
 port 2: genev_sys_6081 (geneve)
 port 5: br1 (internal)
 port 6: vport3 port 7: vport4
root at ubuntu:~# ovs-appctl ofproto/trace br1 in_port=1,dl_dst=ff:ff:ff:ff:ff:ffBridge: br1Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0000
Rule: table=0 cookie=0 priority=0OpenFlow actions=NORMALno learned MAC for destination, floodingoutput to kernel tunnel
Final flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0000Megaflow: recirc_id=0,in_port=1,vlan_tci=0x0000/0x1fff,dl_src=00:00:00:00:00:00,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0000Datapath actions: 5,7,set(tunnel(dst=5.5.5.5,ttl=64,flags(df))),2

Thanks,Chaithan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170716/59366f42/attachment-0001.html>


More information about the discuss mailing list