[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <de5a9b44-fd6d-466a-822b-334343713b9b@lunn.ch>
Date: Wed, 12 Jul 2023 02:55:30 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Harry Coin <hcoin@...etfountain.com>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, netdev@...r.kernel.org
Subject: Re: llc needs namespace awareness asap, was Re: Patch fixing STP if
bridge in non-default namespace.
> Something like that, but to your point about regression -- It a
> statistically good bet there are many bridges with STP enabled in
> non-default name spaces that simply have no loops in L2 BUT these are
> 'buried' inside docker images or prepackaged setups that work 'just fine
> standalone' and also 'in lab namespaces (that just don't have L2 loops...)
> and so that don't hit the bug. These users are one "cable click to an open
> port already connected somewhere they can't see" away from bringing down
> every computer on their entire link (like me, been there, it's not a happy
> week for anyone...), they just don't know it. And their vendors 'trust STP,
> so that can't be it' --- but it is.
>
> If the patch above gets installed-- then packagers downstream will have to
> respond with effort to add code to turn off STP if finding themselves in a
> namespace, and not if not. They will be displeased at having to
> accommodate then de-accommodate when the fix lands. As a 'usually
> downstream of the kernel' developer, I'd rather be warned than blocked.
I don't know this code at all, so maybe a dumb question. What about
user space STP and RSTP? Do they get to see BPDUs? If that works, we
need to ensure any checking you add does not break that use case.
Andrew
Powered by blists - more mailing lists