Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Community Manager
1,100 Views

X520-DA2 (82599EB) will not bridge tagged frames.

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.

0 Kudos
2 Replies
Highlighted
Community Manager
26 Views

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?

0 Kudos
Highlighted
Employee
26 Views

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

0 Kudos