KERNEL BUG: Bridge - Vlan id are not applied to multicast groups

R

robynhub

Renowned Member
Nov 15, 2011
64
0
71
After a LOT of debugging i've found that the bridge vmbr0 of my host machine was propagating multicast traffic to the bridge without caring of vlan id.

To let me better explain, i've this setup:

VLAN 1 -> Native Vlan (no IPv6)
VLAN 2 -> Tagged vlan (with IPv6 autoconfiguration)

Interfaces:
eth1 -> Trunk interface (vlan 1 native and vlan 2 tagged)
vmbr0 -> VM bridge

I've discovered that after configuring IPv6 Router advertisement over a specific VLAN and I saw that other machines on the native vlan get automatically the addresses.
It seems that this beaviour it's mono-directional (from outside to inside the host machine) but it's sufficient to create troubles.

To check the issue you can simply run a couple of tcpdump:

Tcpdump run over the host machine
# tcpdump -e -s0 -A -i eth1 dst ip6-allnodes
tcpdump: WARNING: eth1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:36:44.659492 00:XX:XX:eb:80 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 122: vlan 2, p 0, ethertype IPv6, fe80::xxxx:xxxx:xxx:eb80 > ip6-allnodes: ICMP6, router advertisement, length 64
....n....@:.....................................@@............................@..'... :.....*...............
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

Tcpdump run over the host machine bridge vmbr0
# tcpdump -e -s0 -A -i vmbr0 dst ip6-allnodes
tcpdump: WARNING: vmbr0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:41:24.380759 00:XX:XX:eb:8 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype 802.1Q (0x8100), length 122: vlan 2, p 0, ethertype IPv6, fe80::xxxx:xxxx:xxx:eb80 > ip6-allnodes: ICMP6, router advertisement, length 64
....n....@:.....................................@@............................@..'... :.....*...............
^C

Tcpdump run over the virtual machine (the ethernet interface it's NOT on VLAN 2)
# tcpdump -e -s0 -A -i eth0 dst ip6-allnodes
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:58:33.768602 00:XX:XX:eb:80 (oui Unknown) > 33:33:00:00:00:01 (oui Unknown), ethertype IPv6 (0x86dd), length 118: fe80::xxxx:xxxx:xxx:eb80 > ip6-allnodes: ICMP6, router advertisement, length 64
n....@:.....................................@@............................@..'... :.....*...............


The bug seems to be already recognized and solved by this patch:
http://www.spinics.net/lists/linux-ethernet-bridging/msg04643.html

Workaround

a simple workaround could be done with ip6tables:

echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
ip6tables -A FORWARD -i vmbr0 -p ipv6-icmp --icmpv6-type router-advertisement -j DROP

This issue apply to the last Proxmox 3.1 kernel:

# pveversion -v
proxmox-ve-2.6.32: 3.1-114 (running kernel: 2.6.32-26-pve)
pve-manager: 3.1-21 (running version: 3.1-21/93bf03d4)
pve-kernel-2.6.32-26-pve: 2.6.32-114
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.0-2
pve-cluster: 3.0-8
qemu-server: 3.1-8
pve-firmware: 1.0-23
libpve-common-perl: 3.0-8
libpve-access-control: 3.0-7
libpve-storage-perl: 3.0-17
pve-libspice-server1: 0.12.4-2
vncterm: 1.1-4
vzctl: 4.0-1pve4
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.4-17
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.1-1


Best Regards.
 
Just a note. The bridge it's configured with those options:

auto vmbr0
iface vmbr0 inet manual
bridge_ports eth1
bridge_stp off
bridge_fd 0
bridge_maxwait 0
bridge_ageing 0
 
You must log in or register to reply here.
Top Bottom
Back