On Thu, 2008-05-08 at 14:58 +0200, Joakim Tjernlund wrote:
> On Thu, 2008-05-08 at 14:13 +0200, Francesco Dolcini wrote:
> > Joakim Tjernlund wrote:
> > > On Thu, 2008-05-08 at 11:04 +0200, Francesco Dolcini wrote:
> > >> cisco and others solved this kind of problem using proprietary
> > >> unidirectional link detection protocols (see cisco informational rfc
> > >> 5171 for example). No standard exists as far as I know (BFD rfc does not
> > >> consider the layer 2 case).
> > >
> > > Are these proprietary unidirectional link detection protocols the only
> > > way to solve the problem?
> > spanning tree protocol, in the various IEEE incarnation (802.1D, 802.1Q)
> > and cisco (PVSTP) does not handle this problem, so an external mechanism
> > is needed.
>
> Do they explicitly ban it? Otherwise I don't see why not the kernel STP
> can be enchanted. You could even view it as an external mechanism.
>
> >
> > > Would STP break if the interface was set to "non forwarding" in this
> > > case until the bridge stops seeing its own STP messages?
> > At least this will not solve the more general problem of a
> > unidirectional link (rx working and tx broken).
>
> hmm, if TX is broken there won't be a loop anyway?
>
> Anyhow, even if my proposed change doesn't solve all cases it seems like
> a useful, very simple, ad don to STP. I am just concerned that it can
> break some other aspect of STP. So far it seems OK.
>
> What is the bridge maintainers view on this?
Stephen, whats is your view about extending the bridge code according to
above? Also, after looking at the bride code I don't see where this
should be added, I must be getting old :(
Jocke
_______________________________________________
Bridge mailing list
Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/bridge
