[Bridge] 802.1D/Linux STP issue

Tony Jeffree tony at jeffree.co.uk
Thu Sep 14 09:51:50 PDT 2006


Steve/Brian -

You've probably seen Mick Seaman's comments on this by now - as he points 
out in his email, tinkering with existing STP implementations is not likely 
to be a rewarding exercise and I would encourage you not to go there.

I would suggest that it would be a much more valuable exercise for the 
Linux community to replace the existing STP support with an implementation 
of RSTP.

Regards,
Tony

At 02:06 14/09/2006, Stephen Hemminger wrote:
>On Wed, 13 Sep 2006 15:58:49 -0700
>Brian Braunstein <brian at bristyle.com> wrote:
>
> > hi stephen and tony,
> >
> > i have been in contact with both of you and i figured it would make
> > sense to get you to in contact on this issue, so here's the story:
> >
> > stephen is the maintainer of the linux spanning tree bridging code, an
> > implementation of 802.1D-1998 that has very wide spread use.
> >
> > tony is the chair of the IEEE802.1 working group.
> >
> > i am trying to get my patch submitted in the linux kernel to fix a bug
> > in the way STP behaves.  stephen and i discovered that the flaw is
> > actually in the IEEE802.1D-1998 spec, and that the linux implementation
> > was merely following this.  i contacted tony to try to see if we can get
> > an update to the 802.1D-1998 spec, as this is what is implemented in the
> > linux kernel, but tony said that the 1998 standard is obsolete, will not
> > be updated,  and that the 2004 RSTP spec should be used.
> >
> > so here's a review of what i've come across:
> >
> > first lets start with the bug in the 802.1D-1998 spec
> >
> > 1998 - 8.6.2.2 Record Configuration Information - Use
> >     you will notice that if the path cost ever goes up and everything
> > else is held constant, the BPDU will be dropped and the network not
> > react to the change, and the dropping of the BPDUs will make it seem
> > like the link is down.
> >
> > now lets look at the equivalent section in the 8021.D-2004 spec:
> >
> > 2004 - 17.6 Priority vector calculations
> >
> >     as you can see here, this bug has been fixed, because the last
> > condition takes care of the problem, if the config message is received
> > from the same designated bridge and designated port, then the config
> > message is processed. so path cost increases will be recorded and
> > reacted to.
> >
> >
> > the issue is whether or not the linux kernel should go with the 1998 or
> > 2004 spec.  i would assume that the goal is to make the linux
> > implmentation a functional implementation of the original STP, not a
> > complete rewrite to conform to all of RSTP, so lets look at what the new
> > standard says for normal legacy STP, to see if the bug is fixed there as
> > well:
> >
> > 2004 - 17.4 STP compatibility
> >
> >     this section seems to say that an RSTP bridge  will revert to STP as
> > defined in section 8.  so then we go to section 8...
> >
> > 2004 - 8 Spanning tree algorithm protocol
> >
> >     this one then refers to 802.1D-1998 for the STP spec, but also says
> > that it is obsolete and RSTP should be used
> >
> > so this is a bit confusing.  section 17.4 says use STP to interoperate
> > with legacy bridges, then section 8 either says use the 1998 spec, or
> > don't use STP at all, but if bugs in the 1998 spec cannot be correct,
> > what are we to do with the linux code?  i can write the patch to
> > implement the new algorithm from 2004-17.6 to replace the algorithm from
> > 1998-8.6.2.2.
> >
> > thanks for you help guys,
> > hopefully we can get this bug fixed up soon, you both have been great
> > about timely responses and it is much appreciated.
> >
> > Brian Braunstein
> > 858.245.0434
>
>
>I have no problem fixing the code to be spec noncompliant, there
>are several case where we implement the "right thing" rather than
>the "standard way". I just want to make sure any such changes don't
>have unintended consequences.






More information about the Bridge mailing list