[Bridge] BPDU's not passing through bridge when STP is disabled

[Bridge] BPDU's not passing through bridge when STP is disabled

[Cameron Schaus]

I have noticed a change in the linux bridge implementation between 
2.1.15 and 2.1.17.  Specifically, I do not think BPDU's (generated from 
another bridge) are passed across the bridge when STP is disabled.  I 
think this relates to the LLC handling of BPDU's directly invoking 
br_bpdu_rcv.

In 2.6.15, the br_handle_frame function would pass a BPDU to the 
br_handle_frame_finish function which would transmit it across the 
bridge.  But in 2.6.17, the br_bpdu_rcv function is invoked directly by 
the LLC layer, which does nothing if stp is disabled.

Was this change intentional?  The reason I ask is that I can introduce a 
loop into the network by doing the following:

Two machines, both with eth0 and eth1 bridged and STP is enabled:

        ----- A -----
-----+                +------
        ----- B -----


When I disable STP on machine A, it reverts to a standard bridge, with 
both eth0 and eth1 in the forwarding state.  Bridge B has STP enabled, 
and is sending out BPDU's.  Bridge B should disable one of its ports to 
prevent a loop in the network, but it doesn't, because bridge A does not 
pass the BPDU's across, so bridge B cannot detect the loop.  With the 
2.6.15 kernel, this loop was prevented.

Can br_handle_frame_finish be called from br_stp_rcv in the event that 
stp is not enabled, or would doing so cause problems?

Cam

Re: [Bridge] BPDU's not passing through bridge when STP is disabled

[Stephen Hemminger]

On Fri, 08 Dec 2006 18:24:07 -0500
Cameron Schaus <cam@schaus.ca> wrote:

> I have noticed a change in the linux bridge implementation between 
> 2.1.15 and 2.1.17.  Specifically, I do not think BPDU's (generated from 
> another bridge) are passed across the bridge when STP is disabled.  I 
> think this relates to the LLC handling of BPDU's directly invoking 
> br_bpdu_rcv.
> 
> In 2.6.15, the br_handle_frame function would pass a BPDU to the 
> br_handle_frame_finish function which would transmit it across the 
> bridge.  But in 2.6.17, the br_bpdu_rcv function is invoked directly by 
> the LLC layer, which does nothing if stp is disabled.
> 
> Was this change intentional?  The reason I ask is that I can introduce a 
> loop into the network by doing the following:
> 
> Two machines, both with eth0 and eth1 bridged and STP is enabled:
> 
>         ----- A -----
> -----+                +------
>         ----- B -----
> 
> 
> When I disable STP on machine A, it reverts to a standard bridge, with 
> both eth0 and eth1 in the forwarding state.  Bridge B has STP enabled, 
> and is sending out BPDU's.  Bridge B should disable one of its ports to 
> prevent a loop in the network, but it doesn't, because bridge A does not 
> pass the BPDU's across, so bridge B cannot detect the loop.  With the 
> 2.6.15 kernel, this loop was prevented.
> 
> Can br_handle_frame_finish be called from br_stp_rcv in the event that 
> stp is not enabled, or would doing so cause problems?
> 
> Cam
> 
> _______________________________________________
> Bridge mailing list
> Bridge@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/bridge
> 

The change was intentional because the bridge follows the 802 spec
and doesn't pass link local multicast frames. 

If you are running STP on the network, you need to run STP on
the bridge.