-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I have made some additional testing on a new server that have the same
hardware/setup than other I have uncounter the same issue.
but in fact, the issue occurs with I use fake-bridge with a vlan.
root@stri:~# ovs-vsctl show
b7c26499-2586-4dac-a5c0-52d80cb24cd9
Bridge "br-eth0"
Port "vlan3199"
tag: 3199
Interface "vlan3199"
type: internal
Port "vlan3132"
tag: 3132
Interface "vlan3132"
type: internal
Port "vlan3175"
tag: 3175
Interface "vlan3175"
type: internal
Port "br-eth0"
Interface "br-eth0"
type: internal
Port "eth0"
Interface "eth0"
ovs_version: "2.3.90"
# modinfo openvswitch
filename: /lib/modules/3.16-2-amd64/updates/dkms/openvswitch.ko
version: 2.3.90
license: GPL
description: Open vSwitch switching datapath
srcversion: 3DE816749EC5E2768BB59E1
depends: libcrc32c,vxlan,gre
vermagic: 3.16-2-amd64 SMP mod_unload modversions
I have used the master branch of openvswitch for userland and kernel
land (commit ff601a08a44c37fa8a6e0e569dc00d6731f55555 - Fri Oct 10
14:41:10 2014 -0700).
root@stri:~# ip a s dev vlan3175
14: vlan3175: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN group default
link/ether 62:e7:3c:9e:d4:45 brd ff:ff:ff:ff:ff:ff
inet 192.168.3.106/24 scope global vlan3175
valid_lft forever preferred_lft forever
inet6 fe80::60e7:3cff:fe9e:d445/64 scope link
valid_lft forever preferred_lft forever
root@stri:~# ovs-dpctl show
system@ovs-system:
lookups: hit:22902 missed:3675 lost:0
flows: 3
masks: hit:35144 total:3 hit/pkt:1.32
port 0: ovs-system (internal)
port 1: vlan3132 (internal)
port 2: vlan3199 (internal)
port 3: eth0
port 4: vlan3175 (internal)
port 5: br-eth0 (internal)
Then I run the ping in background:
root@stri:~# ping 192.168.3.101
...
From 192.168.3.106 icmp_seq=187 Destination Host Unreachable
From 192.168.3.106 icmp_seq=188 Destination Host Unreachable
From 192.168.3.106 icmp_seq=189 Destination Host Unreachable
...
And I look at traffic with "ovs-dpctl dump-flows" and "tcpdump"
root@stri:~# ovs-dpctl dump-flows
recirc_id(0),in_port(4),eth(src=62:e7:3c:9e:d4:45,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=192.168.3.106,tip=192.168.3.101,op=1/0xff),
packets:17, bytes:714, used:0.436s,
actions:push_vlan(vid=3175,pcp=0),5,3
recirc_id(0),in_port(1),eth(src=62:e7:3c:9e:d4:45,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=89.234.156.234,tip=91.224.149.254,op=1/0xff),
packets:234, bytes:9828, used:1.068s,
actions:push_vlan(vid=3132,pcp=0),5,3
recirc_id(0),in_port(1),eth(src=62:e7:3c:9e:d4:45,dst=33:33:ff:00:00:31),eth_type(0x86dd),ipv6(frag=no),
packets:2, bytes:172, used:1.096s, actions:push_vlan(vid=3132,pcp=0),5,3
Here, they are a first weird thing, openvswitch have created port 1 and
port 4 with the same MAC, this is not the case on my other server with
kernel 3.14
root@stri:~# tcpdump -eni eth0 '(icmp or arp)'
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144
bytes
01:36:04.924148 62:e7:3c:9e:d4:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 46: vlan 3175, p 0, ethertype ARP, Request who-has
192.168.3.101 tell 192.168.3.106, length 28
01:36:05.922944 62:e7:3c:9e:d4:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 46: vlan 3175, p 0, ethertype ARP, Request who-has
192.168.3.101 tell 192.168.3.106, length 28
01:36:06.922948 62:e7:3c:9e:d4:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 46: vlan 3175, p 0, ethertype ARP, Request who-has
192.168.3.101 tell 192.168.3.106, length 28
01:36:07.940165 62:e7:3c:9e:d4:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 46: vlan 3175, p 0, ethertype ARP, Request who-has
192.168.3.101 tell 192.168.3.106, length 28
...
It seems that the icmp does not succeed because we didn't get the reply
for the ARP request.
So i'm looking to the destination host of the ping request:
# tcpdump -eni eth0 '(icmp or arp) and host 192.168.3.106'
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144
bytes
08:37:40.352416 62:e7:3c:9e:d4:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 64: vlan 3175, p 0, ethertype ARP, Request who-has
192.168.3.101 tell 192.168.3.106, length 46
08:37:40.352434 42:54:b1:1b:15:45 > 62:e7:3c:9e:d4:45, ethertype 802.1Q
(0x8100), length 46: vlan 3175, p 0, ethertype ARP, Reply 192.168.3.101
is-at 42:54:b1:1b:15:45, length 28
08:37:41.370635 62:e7:3c:9e:d4:45 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q
(0x8100), length 64: vlan 3175, p 0, ethertype ARP, Request who-has
192.168.3.101 tell 192.168.3.106, length 46
08:37:41.370648 42:54:b1:1b:15:45 > 62:e7:3c:9e:d4:45, ethertype 802.1Q
(0x8100), length 46: vlan 3175, p 0, ethertype ARP, Reply 192.168.3.101
is-at 42:54:b1:1b:15:45, length 28
...
So, the arp reply never come back to the host.
The underlying network driver module is a 'ixgbe'.
I have made an other test, if I create the vlan on eth0 with the regular
'ip link add link eth0 name vlan3175 type vlan id 3175', the ping works.
So the issue only occurs with I create vlan with ovs fake-bridge
Regards and thanks for your help,
- - ---
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht
-----BEGIN PGP SIGNATURE-----
Version: OpenPGP.js v.1.20131017
Comment: http://openpgpjs.org
wsFcBAEBCAAQBQJUPMziCRAYkrQvzqrryAAAoMwP/10YUHDLA1KaFWtjsxUn
o/hJErBzsUILasvqQM4GEz3+UCk5wTJDrs9TGobIOoruY8LO/FtLMpYF+8gD
lWyODqdT6MKzhQBFu7995RUI9bLwBsbUg1/eYxSv8z9/ZIDnkq8MBjyxce2l
1Wy27/94uHHfD1y3GaCKf46dY3bWdIZ4OrGbTfZK25ru707+JqPRCH8TSl/3
fAT1oicPNaZRW3KDjYKgdnl47E7mE93tbnjO2U0fYCu6lgvBeldUibKl8qQV
XKYH2HesFXE+xrE7PeBnQcWE7hFTPaEeCv2tigpLUs8QxMSXqeujx/iBH1NB
k38fVynwZU+5c82OJ8NYNmB0yQLTlj8we7AreTSQplM9lPrx6Dx7OTtNVyLs
Sjdk/VXqKU3okzit9tRFzY7Ib/G2d9HvThy0dCoWQxmBrANexO6HUOX6NVtg
sxVSvx8qCahjTl/+H7nU3TsFjrzPsjO36TmGcgTEsEa6qzmRnUbBVqSlmJCX
vx53Vpb8RCuvqMan4MIaAmJQQ+qJS/MOtg1VfF1/GicEOr/q7vNABrMGr/eJ
Pl3DjR6vXxH4AceVJHdqAkCR+NtBde+gYQ5f0MGy4WLZD1t1p8CKsj1iNFy1
tY1l/Y3OfSUaWRbnlkkaF36eyhiTKu578CcH+rhcP6eDERcJnTiAhMuHfIX4
EptF
=xYMy
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
