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@ubuntu:~# ovs-vsctl add-port br0 tun1 -- set interface tun1 type=geneve options:remote_ip=4.4.4.4root@ubuntu:~# ovs-vsctl add-port br0 vport1 -- add-port br0 vport2 root@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@ubuntu:~# ovs-dpctl show (partial output) system@ovs-system: port 0: ovs-system (internal) port 1: br0 (internal) port 2: genev_sys_6081 (geneve) port 3: vport2 port 4: vport1 root@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@ubuntu:~# ovs-vsctl add-port br1 vport3 -- add-port br1 vport4 root@ubuntu:~# ovs-vsctl add-port br1 tun2 -- set interface tun2 type=geneve options:remote_ip=5.5.5.5 root@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@ubuntu:~# ovs-dpctl show (partial output) system@ovs-system: port 0: ovs-system (internal) port 2: genev_sys_6081 (geneve) port 5: br1 (internal) port 6: vport3 port 7: vport4 root@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
_______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
