[<<][pool][>>][..]
Sun May 15 13:35:47 CEST 2011

Debugging vlan

Weird stuff.  I'm jet-lagged so it could just be PEBKAC.  Following setup:

I have qemu/kvm VM with interface called ubit, bridged to br1 together
with eth0.2 which is eth0's VLAN2.  The VM's dhcp requests do not seem
to pass through.  The weird thing is that I see the dhcp requests on
eth0.2 and the replies on eth0, tagged with vlan2.  WTF?


## eth0.2 (or the bridge br1) sees the client bootpc > server bootps ..

zni:/home/tom# tcpdump -i eth0.2
tcpdump: WARNING: eth0.2: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.2, link-type EN10MB (Ethernet), capture size 96 bytes
13:38:56.200120 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:05 (oui Unknown), length 300
13:38:59.717661 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:12:34:05 (oui Unknown), length 300


## eth0 has the server bootps > client bootpc reply packets, tagged as "vlan 2"

zni:/etc/network# tcpdump -i eth0 vlan
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:38:56.201403 vlan 2, p 0, IP gate-13.i.bootps > ubit-13.i.bootpc: BOOTP/DHCP, Reply, length 300
13:38:59.718744 vlan 2, p 0, IP gate-13.i.bootps > ubit-13.i.bootpc: BOOTP/DHCP, Reply, length 300
13:39:04.717947 vlan 2, p 0, ARP, Request who-has ubit-13.i tell gate-13.i, length 42
13:39:05.718014 vlan 2, p 0, ARP, Request who-has ubit-13.i tell gate-13.i, length 42
13:39:06.718085 vlan 2, p 0, ARP, Request who-has ubit-13.i tell gate-13.i, length 42



Q: These should really be the same, since eth0.2 is VLAN2.  Or is it not?

zni:/etc/network# cat /proc/net/vlan/config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth0.2         | 2  | eth0



Performing an eth0 dump to file and analyzing with wireshark, and I do
see both discover (request) and offer (reply) packets.  I don't know
why "tcpdump -i eth0 vlan" doesn't show them on the console.

Doing the same for the eth0.2 dump, the reply packets do not show up.

Q: Why do the packets show up properly as VLAN-tagged on the eth0
   dump, but only one direction in the eth0.2 dump?

Packet size?  Hmm..  Unlikely.  DHCP packets are around 300 bytes.



I tried to add ubit to br0 and that works flawlessly.  Maybe it has
something to do with eth0 being part of br0.  Maybe I should use br0
as the interface for untagging?  I'm using the same setup on zoo and
there it seems to work fine..

Q: What is this?



Then another problem pops up.  Still works fine on zoo, but on zwizwa
I don't see any UDP reply packets for the vpn.  After shutdown and a
run on zoo it seems that it's working now on zni.  I don't know why..

Maybe it's time to move away from bridges.  Is it the MAC learning
that gets in the way?


I tried to take VLAN 2 from br0 instead of eth0 directly, but that
doesn't make any difference, except that I can't even see the reply
packets on the br0 any more.

Maybe it's just the "bridge id"?  On zni the two bridges have the same
id.

zoo:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.90fba6e47b21       no              eth0
br1             8000.425d46586bb6       no              eth0.11

zni:~#  brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.002421230e4b       no              eth0
br1             8000.002421230e4b       no              eth0.2


Why is this?


I found another thing that works: disabling br0, using eth0 directly.
Then on br1 everything works as expected.




[Reply][About]
[<<][pool][>>][..]