[ovs-discuss] multi-tun_id VXLAN tunnel works only for one tun_id

Matteo Olivi matteoolivi7 at gmail.com
Mon Dec 31 18:28:42 UTC 2018


I just ran tcpdump on one of the interfaces with tun_id=2 (aka one of those
for which communication is not working) while pinging from the other one.
This is what I got:

> 18:26:40.157190 ARP, Request who-has 10.0.0.4 tell 10.0.0.3, length 28
>

On Mon, Dec 31, 2018 at 1:25 PM Matteo Olivi <matteoolivi7 at gmail.com> wrote:

> Hello everyone.
>
> I have two Vagrant machines with Ubuntu 16.04, OvS 2.5.5 is installed on
> both. I'm trying to set-up VXLAN tunneling by following the instructions at
> https://www.youtube.com/watch?v=tnSkHhsLqpM as a reference. More
> specifically, there are two couples of interfaces. Within each couple, the
> two interfaces are on different vms. Each couple uses its own tunnel id, 1
> and 2 respectively.
>
> On each machine I created a bridge named "kos", then I ran the commands
> "ovs-vsctl add-port kos vtep -- set interface vtep type=vxlan
> option:remote_ip=172.28.128.5 option:key=flow" and "ovs-vsctl add-port kos
> vtep -- set interface vtep type=vxlan option:remote_ip=172.28.128.4
> option:key=flow" on vm1 and vm2 respectively. 172.28.128.4 and 172.28.128.5
> are the IP addresses associated with the enp0s8 interfaces of the vms. The
> two vms can ping each other from the said interfaces.
>
> Then, I set up tunneling between the first couple of interfaces. I created
> two internal interfaces with the following commands executed on vm1 and vm2
> respectively: "ovs-vsctl add-port kos kos11 -- set interface kos11
> type=internal mac="02\:00\:00\:00\:00\:11" && ip addr add 10.0.0.1/8
> scope link dev kos11 && ip link set kos11 up" and "ovs-vsctl add-port kos
> kos12 -- set interface kos12 type=internal mac="02\:00\:00\:00\:00\:12" &&
> ip addr add 10.0.0.2/8 scope link dev kos12 && ip link set kos12 up". I
> retrieved the open flow ports of kos11, kos12 and vtep on both machines
> (3,3,2,2)  and ran "ovs-ofctl add-flows kos flows" where flows is a file
> with this content:
>
> vm1:
>
>> table=0,in_port=3,actions=set_field:1->tun_id,resubmit(,1)
>> table=0,actions=resubmit(,1)
>>
>> table=1,tun_id=1,arp,arp_tpa=10.0.0.2,actions=output:2
>> table=1,tun_id=1,dl_dst=02:00:00:00:00:12,actions=output:2
>>
>> table=1,tun_id=1,arp,arp_tpa=10.0.0.1,actions=output:3
>> table=1,tun_id=1,dl_dst=02:00:00:00:00:11,actions=output:3
>>
>> table=1,actions=drop
>>
>
> vm2:
>
>> table=0,in_port=3,actions=set_field:1->tun_id,resubmit(,1)
>> table=0,actions=resubmit(,1)
>>
>> table=1,tun_id=1,arp,arp_tpa=10.0.0.2,actions=output:3
>> table=1,tun_id=1,dl_dst=02:00:00:00:00:12,actions=output:3
>>
>> table=1,tun_id=1,arp,arp_tpa=10.0.0.1,actions=output:2
>> table=1,tun_id=1,dl_dst=02:00:00:00:00:11,actions=output:2
>>
>> table=1,actions=drop
>>
>
> Where the in and out ports are the correct openflow ports. After this
> step, kos11 and kos12, which use tun_id=1, could ping each other perfectly
> fine.
>
> Then I proceeded to set up tunneling between the second couple of
> interfaces, with the same steps aforementioned: I created the interfaces
> with "ovs-vsctl add-port kos kos21 -- set interface kos21 type=internal
> mac="02\:00\:00\:00\:00\:21" && ip addr add 10.0.0.3/8 scope link dev
> kos21 && ip link set kos21 up" and "ovs-vsctl add-port kos kos22 -- set
> interface kos22 type=internal mac="02\:00\:00\:00\:00\:22" && ip addr add
> 10.0.0.4/8 scope link dev kos22 && ip link set kos22 up", I retrieved the
> openflow ports of the said interfaces (4 and 4) and added the following
> openflow flows to the switches on vm1 and vm2 respectively:
>
> vm1:
>
>> table=0,in_port=4,actions=set_field:2->tun_id,resubmit(,1)
>>
>> table=1,tun_id=2,arp,arp_tpa=10.0.0.4,actions=output:2
>> table=1,tun_id=2,dl_dst=02:00:00:00:00:22,actions=output:2
>>
>> table=1,tun_id=2,arp,arp_tpa=10.0.0.3,actions=output:4
>> table=1,tun_id=2,dl_dst=02:00:00:00:00:21,actions=output:4
>>
>
> vm2:
>
>> table=0,in_port=4,actions=set_field:2->tun_id,resubmit(,1)
>>
>> table=1,tun_id=2,arp,arp_tpa=10.0.0.4,actions=output:4
>> table=1,tun_id=2,dl_dst=02:00:00:00:00:22,actions=output:4
>>
>> table=1,tun_id=2,arp,arp_tpa=10.0.0.3,actions=output:2
>> table=1,tun_id=2,dl_dst=02:00:00:00:00:21,actions=output:2
>>
>
> The interfaces kos11 and kos12 (tun_id=1) can still ping each other. On
> the contrary, kos21 and kos22 (tun_id=2) cannot: If I ping I get
> destination host unreachable. How can I fix this? Here's some config of
> ovs, let me know if something else might be useful:
> vm1:
> ovs-vsctl show:
>
>> 20b70bc9-534d-44e9-b83f-3ce9bcb5e68e
>>     Bridge kos
>>         Port "kos21"
>>             Interface "kos21"
>>                 type: internal
>>         Port kos
>>             Interface kos
>>                 type: internal
>>         Port vtep
>>             Interface vtep
>>                 type: vxlan
>>                 options: {key=flow, remote_ip="172.28.128.5"}
>>         Port "kos11"
>>             Interface "kos11"
>>                 type: internal
>>     ovs_version: "2.5.5"
>>
>
> ovs-ofctl dump-flows kos:
>
>> NXST_FLOW reply (xid=0x4):
>>  cookie=0x0, duration=2850.073s, table=0, n_packets=15, n_bytes=1278,
>> idle_age=2312, in_port=3 actions=load:0x1->NXM_NX_TUN_ID[],resubmit(,1)
>>  cookie=0x0, duration=2374.035s, table=0, n_packets=6, n_bytes=252,
>> idle_age=2305, in_port=4 actions=load:0x2->NXM_NX_TUN_ID[],resubmit(,1)
>>  cookie=0x0, duration=2850.073s, table=0, n_packets=14, n_bytes=1316,
>> idle_age=2326, actions=resubmit(,1)
>>  cookie=0x0, duration=2850.073s, table=1, n_packets=1, n_bytes=42,
>> idle_age=2355, arp,tun_id=0x1,arp_tpa=10.0.0.2 actions=output:2
>>  cookie=0x0, duration=2850.073s, table=1, n_packets=1, n_bytes=42,
>> idle_age=2355, arp,tun_id=0x1,arp_tpa=10.0.0.1 actions=output:3
>>  cookie=0x0, duration=2374.034s, table=1, n_packets=6, n_bytes=252,
>> idle_age=2305, arp,tun_id=0x2,arp_tpa=10.0.0.4 actions=output:2
>>  cookie=0x0, duration=2374.034s, table=1, n_packets=0, n_bytes=0,
>> idle_age=2374, arp,tun_id=0x2,arp_tpa=10.0.0.3 actions=output:4
>>  cookie=0x0, duration=2850.073s, table=1, n_packets=6, n_bytes=588,
>> idle_age=2340, tun_id=0x1,dl_dst=02:00:00:00:00:12 actions=output:2
>>  cookie=0x0, duration=2850.073s, table=1, n_packets=13, n_bytes=1274,
>> idle_age=2326, tun_id=0x1,dl_dst=02:00:00:00:00:11 actions=output:3
>>  cookie=0x0, duration=2374.034s, table=1, n_packets=0, n_bytes=0,
>> idle_age=2374, tun_id=0x2,dl_dst=02:00:00:00:00:22 actions=output:2
>>  cookie=0x0, duration=2374.034s, table=1, n_packets=0, n_bytes=0,
>> idle_age=2374, tun_id=0x2,dl_dst=02:00:00:00:00:21 actions=output:4
>>  cookie=0x0, duration=2850.072s, table=1, n_packets=8, n_bytes=648,
>> idle_age=2312, actions=drop
>>
>
> vm2:
> ovs-vsctl show:
>
>> e4e79d2c-d133-4517-aabc-332dd60cd8f9
>>     Bridge kos
>>         Port "kos12"
>>             Interface "kos12"
>>                 type: internal
>>         Port kos
>>             Interface kos
>>                 type: internal
>>         Port "kos22"
>>             Interface "kos22"
>>                 type: internal
>>         Port vtep
>>             Interface vtep
>>                 type: vxlan
>>                 options: {key=flow, remote_ip="172.28.128.4"}
>>     ovs_version: "2.5.5"
>>
>
> ovs-ofctl dump-flows kos:
>
>> NXST_FLOW reply (xid=0x4):
>>  cookie=0x0, duration=2942.446s, table=0, n_packets=14, n_bytes=1316,
>> idle_age=2395, in_port=3 actions=load:0x1->NXM_NX_TUN_ID[],resubmit(,1)
>>  cookie=0x0, duration=2450.006s, table=0, n_packets=0, n_bytes=0,
>> idle_age=2450, in_port=4 actions=load:0x2->NXM_NX_TUN_ID[],resubmit(,1)
>>  cookie=0x0, duration=2942.446s, table=0, n_packets=13, n_bytes=882,
>> idle_age=2374, actions=resubmit(,1)
>>  cookie=0x0, duration=2942.446s, table=1, n_packets=1, n_bytes=42,
>> idle_age=2424, arp,tun_id=0x1,arp_tpa=10.0.0.2 actions=output:3
>>  cookie=0x0, duration=2942.446s, table=1, n_packets=1, n_bytes=42,
>> idle_age=2424, arp,tun_id=0x1,arp_tpa=10.0.0.1 actions=output:2
>>  cookie=0x0, duration=2450.006s, table=1, n_packets=6, n_bytes=252,
>> idle_age=2374, arp,tun_id=0x2,arp_tpa=10.0.0.4 actions=output:4
>>  cookie=0x0, duration=2450.005s, table=1, n_packets=0, n_bytes=0,
>> idle_age=2450, arp,tun_id=0x2,arp_tpa=10.0.0.3 actions=output:2
>>  cookie=0x0, duration=2942.446s, table=1, n_packets=6, n_bytes=588,
>> idle_age=2409, tun_id=0x1,dl_dst=02:00:00:00:00:12 actions=output:3
>>  cookie=0x0, duration=2942.446s, table=1, n_packets=13, n_bytes=1274,
>> idle_age=2395, tun_id=0x1,dl_dst=02:00:00:00:00:11 actions=output:2
>>  cookie=0x0, duration=2450.006s, table=1, n_packets=0, n_bytes=0,
>> idle_age=2450, tun_id=0x2,dl_dst=02:00:00:00:00:22 actions=output:4
>>  cookie=0x0, duration=2450.005s, table=1, n_packets=0, n_bytes=0,
>> idle_age=2450, tun_id=0x2,dl_dst=02:00:00:00:00:21 actions=output:2
>>  cookie=0x0, duration=2942.446s, table=1, n_packets=0, n_bytes=0,
>> idle_age=2942, actions=drop
>>
>>
> Thanks,
> Matteo.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20181231/8a481fc9/attachment-0001.html>


More information about the discuss mailing list