[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0199E0D51A61344794750DC57738F58E6D6B0C79D7@GVW1118EXC.americas.hpqcorp.net>
Date: Mon, 17 Aug 2009 21:16:04 +0000
From: "Fischer, Anna" <anna.fischer@...com>
To: Stephen Hemminger <shemminger@...ux-foundation.org>,
David Miller <davem@...emloft.net>
CC: "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@...l.org>, Arnd Bergmann <arnd@...db.de>
Subject: RE: [RFC] bridge: prevent hairpin and STP problems?
> 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.
Anna
--
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