[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090817153725.47c04fca@nehalam>
Date: Mon, 17 Aug 2009 15:37:25 -0700
From: Stephen Hemminger <shemminger@...ux-foundation.org>
To: "Fischer, Anna" <anna.fischer@...com>
Cc: David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"ptcongdon@...avis.edu" <ptcongdon@...avis.edu>,
"evb@...oogroups.com" <evb@...oogroups.com>,
"bridge@...ts.linux-foundation.org"
<bridge@...ts.linux-foundation.org>,
"kaber@...sh.net" <kaber@...sh.net>,
"arnd@...db.de" <arnd@...db.de>,
"Dickson, Mike (ISS Software)" <mike.dickson@...com>,
"adobriyan@...il.com" <adobriyan@...il.com>,
"bridge@...l.org" <bridge@...ux-foundation.org>
Subject: Re: [RFC] bridge: prevent hairpin and STP problems?
On Mon, 17 Aug 2009 21:16:04 +0000
"Fischer, Anna" <anna.fischer@...com> wrote:
> > Subject: [RFC] bridge: prevent hairpin and STP problems?
> >
> > Do we need to add this to block Spanning Tree from being enabled
> > with hairpin mode? I am not sure what the exact usage of hairpin
> > mode and if it is possible to create loops and get STP confusion.
> >
> > For comment only, do not apply as is.
>
> Your patch disables STP on the whole bridge if one or more ports
> are set to hairpin mode.
>
> However, I don't really see that this is necessary.
>
> A hairpin mode port should not reflect BPDUs, because otherwise the
> connected port would think it has detected a loop. The hairpin mode
> port should still be able to generate BPDUs though, and in any case
> the bridge should still be able to run STP.
>
> The hairpin patch we submitted reflects packets on the forwarding /
> data path whereas BPDUs are processed with a separate hook, so we
> should not be reflecting BPDUs back out of a hairpin mode port.
So if user is using hairpin properly, the STP would work. In fact
it would be a good thing since it would detect looping configurations.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists