Hiya,
I'm having an issue with a combination of VLAN and bridges that
pretty much looks like a kernel bug, though I have to admit I'm
not sure I do everything proper. Would anyone here be able to
help?
Basically, I'm trying to replicate a physical network setup onto
virtual networks with qemu/libvirt
On the physical network, I've got a smart switch with 2 VLANs
(ID 2 and 3), port 1 of the switch is configured with tagged
vlans and connects to one host (A running FreeBSD 8.1). port 2
is member of VLAN 3 untagged and connects to a debian host B.
Now, I'm doing the same with virtual machines.
So here is the setup I have:
$ ip link show
[...]
3: virbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether fe:54:00:f4:e4:e6 brd ff:ff:ff:ff:ff:ff
4: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether fe:54:00:2c:37:cd brd ff:ff:ff:ff:ff:ff
6: virbr1.3@virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether a2:99:41:ba:e6:ae brd ff:ff:ff:ff:ff:ff
7: virbr1.2@virbr1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether a2:99:41:ba:e6:ae brd ff:ff:ff:ff:ff:ff
8: virbr1_3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether a2:99:41:ba:e6:ae brd ff:ff:ff:ff:ff:ff
9: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether fe:54:00:ce:01:08 brd ff:ff:ff:ff:ff:ff
10: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether fe:54:00:2c:37:cd brd ff:ff:ff:ff:ff:ff
11: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/ether fe:54:00:f4:e4:e6 brd ff:ff:ff:ff:ff:ff
$ brctl show
bridge name bridge id STP enabled interfaces
virbr1 8000.fe54002c37cd no vnet1
virbr1_3 8000.a29941bae6ae no virbr1.3
vnet0
virbr2 8000.fe5400f4e4e6 yes vnet2
(actually, you may ignore everything related to virbr2 as it's not related to the issue).
host A has NICs mapped to vnet2 and vnet1 (that one with tagged vlans configured).
host B has a NIC mapped to vnet0.
IP communication is fine except between A and the host, between B and the host
but not between A and B.
If I try to have B talk to A (to its interface on virbr1 tagged
with PVID 3), the ARP traffic is OK, but then anything else is
garbbled when it goes out to the vnet1 interface.
If I tshark on vnet0 or virbr1_3, I can see the TCP SYN OK without the VLAN
802.1Q header as expected. If I tshark on virbr1, I can see a
correct 802.1Q header as expected.
But if I tshark on vnet1, the ethernet headers are garbbled. the
ethernet type is IP instead of 802.1Q, but I can see 8 extra
bytes between the ethernet header and IP header the first four
being 00 00 00 00, and the next ones being the 802.1Q header.
Here is a tshark dissect of that packet:
Frame 1 (106 bytes on wire, 106 bytes captured)
Ethernet II, Src: RealtekU_ce:01:08 (52:54:00:ce:01:08), Dst: RealtekU_2c:37:cd (52:54:00:2c:37:cd)
Destination: RealtekU_2c:37:cd (52:54:00:2c:37:cd)
Address: RealtekU_2c:37:cd (52:54:00:2c:37:cd)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: RealtekU_ce:01:08 (52:54:00:ce:01:08)
Address: RealtekU_ce:01:08 (52:54:00:ce:01:08)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Type: IP (0x0800)
Internet Protocol
Version: 0
Header length: 0 bytes (bogus, must be at least 20)
0000 52 54 00 2c 37 cd 52 54 00 ce 01 08 08 00 00 00 RT.,7.RT........
~~~~~
0010 00 00 00 03 08 00 45 00 00 54 00 00 40 00 40 01 ......E..T..@.@.
~~~~~~~~~~~~~~~~~
0020 12 8c 0a 0b 0a 07 0a 0b 0a 01 08 00 36 8f 04 d1 ............6...
0030 00 01 f4 e3 98 4c 00 00 00 00 6a 9b 06 00 00 00 .....L....j.....
0040 00 00 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d ................
0050 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d .. !"#$%&'()*+,-
0060 2e 2f 30 31 32 33 34 35 36 37 ./01234567
Is there anything I'm doing wrong here? Or another way to
achieve what I'm trying to do?
packets from A to B are fine.
Initially found on 2.6.32 on debian sid amd64, but the same
occurs with 2.6.35 from experimental.
Thanks,
Stephane
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
