Hi JP; I understand more clearly now - thank you for the example. In the use case that I struggled against I needed the BPDU's to traverse the bridge as we were counting on the Cisco switches to force a blocking state on a redundant link. I have seen the case you are describing and assumed that I would have to live with it as the Linux bridge was "doing the right thing". PVST is a proprietary Cisco protocol. I guess wouldn't expect an open source project to "re-write" the VLAN header for a proprietary protocol. Anyone else have any thoughts on this? G -----Original Message----- From: Joao Pedro [mailto:countzero@xxxxxxx] Sent: 25 November 2008 5:10 PM To: Geoff Wiener Subject: RE: Bridging VLANs and PVST+ Hi Geoff, thank you for your answer. Geoff Wiener <gwiener@xxxxxxxxxxxxxxx> wrote: > I've had this very issue. I know that 2.6.24-16 allows PVST BPDUs > to cross the bridge. Linux won't speak Cisco PVST+ but it will pass > the BPDU's so that Cisco devices on both sides can communicate about > the link state. > But isn't that part of the problem? Imagine this situation, I have: 1 physical interface - eth0; 2 virtual lan interfaces - vlan15 and vlan16. 1 bridge - br0 - bridging vlan15 and vlan16. The reason I have to filter the PVST+ BPDUs out (with ebtables) is that, when the Cisco switch sees a BDPU on VLAN 15 that belonged originally to VLAN 16, it will assume a loop was detected and shut down the switch port where eth0 is connected. If Linux could convert the VLAN 15 BDPU to a VLAN 16 BDPU, before sending it to VLAN 16, I believe the problem would be solved. Regards, JP _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
