All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cameron Schaus <cam@schaus.ca>
To: bridge@lists.osdl.org
Subject: [Bridge] BPDU's not passing through bridge when STP is disabled
Date: Fri, 08 Dec 2006 18:24:07 -0500	[thread overview]
Message-ID: <4579F417.4050007@schaus.ca> (raw)

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


             reply	other threads:[~2006-12-08 23:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 23:24 Cameron Schaus [this message]
2006-12-13 18:24 ` [Bridge] BPDU's not passing through bridge when STP is disabled Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4579F417.4050007@schaus.ca \
    --to=cam@schaus.ca \
    --cc=bridge@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.