- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have two x520-DA2 10G nics set to bridge one port from each nic. The bridge has no problems forwarding traffic for untagged frames, but tagged frames will not forward. I am using the latest ixgbe driver (3.8.21-NAPI) under Centos 6.2 (kernel: 2.6.32-220.7.1.el6.x86_64)
bridge name bridge id STP enabled interfaces
br0 8000.001b21d73a78 no eth0
eth2
bridge.net filter is disabled:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
In case the nics were not in promiscuous mode by the dridge, I ran tcpdump on each interface, and I also explicitly added the vlan interfaces to the bridge in case they were being filtered. Using tcpdump, I can see the tagged frames coming into the bridge, but never leave.
bridge name bridge id STP enabled interfaces
br0 8000.001b21d73a78 no eth0
eth0.560
eth2
eth2.560
Is the bridge lossing the vlan information, or is the ixgbe driver not preserving the vlan tags for the bridge?
Note, the above setup with tagged vlans across a bridge works fine using e1000 driver under 2.6.18-53.1.14.el5 kernel.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On further testing, it seems the second case, where vlans are explicitly added to the bridge, traffic is being forwarded.
ie:
bridge name bridge id STP enabled interfaces
br0 8000.001b21d73a78 no eth0
eth0.560
eth2
eth2.560
My understanding was that adding the untagged device (ie. eth0) to the bridge, placed the interface into promiscuous mode
and disabled any HW vlan filtering on the x520. Is that not the intended case?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This seems to work as the reporter expects in the software stack at least in 3.3. Do you know if this can be repro'd on the 3.3 kernel?
Our test setup looks like this on 3.3,
vlan0 ---> veth1 ---> veth0 ---> bridge ---> veth2 ---> veth3
|
-------> veth4 ---> veth5
I see vlan tags forwarded through the tunnel into the bridge and forwarded or flooded correctly by the bridging code.
17: bridge0: mtu 1500 qdisc noqueue state UP
link/ether 02:a5:4e:70:ae:74 brd ff:ff:ff:ff:ff:ff
18: veth0: mtu 1500 qdisc pfifo_fast master bridge0 state UP qlen 1000
link/ether e2:01:74:38:8f:84 brd ff:ff:ff:ff:ff:ff
19: veth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 5e:41:dd:8c:95:3d brd ff:ff:ff:ff:ff:ff
20: veth2: mtu 1500 qdisc pfifo_fast master bridge0 state UP qlen 1000
link/ether 02:a5:4e:70:ae:74 brd ff:ff:ff:ff:ff:ff
21: veth3: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether a2:c4:8b:6a:d0:6d brd ff:ff:ff:ff:ff:ff
22: veth4: mtu 1500 qdisc pfifo_fast master bridge0 state UP qlen 1000
link/ether 2a:4c:c4:cc:ed:ff brd ff:ff:ff:ff:ff:ff
23: veth5: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 26:e2:5f:00:45:7f brd ff:ff:ff:ff:ff:ff
24: vlan0@veth1: mtu 1500 qdisc noqueue state UP
link/ether 5e:41:dd:8c:95:3d brd ff:ff:ff:ff:ff:ff
25: vlan1@vlan0: mtu 1500 qdisc noqueue state UP
link/ether 5e:41:dd:8c:95:3d brd ff:ff:ff:ff:ff:ff

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page