Spanning Tree, Three States & Why Committees can Suck

Have you ever wondered why there are two intermediate states in the 802.1d Spanning Tree Standard ? I have. The five states in 802.1d are:

  • Listening
  • Learning
  • Forwarding
  • Blocking
  • Disable

I’ve always wondered what the difference between Listening and Learning states in STP are for. Can’y you just Listen for BPDUs and process the data there and move into Forwarding mode ? What else can you do during the Learning phase that can’t be achieved in the Listening Phase ?

It should be noted that in the RSTP 802.1w the states are

  • Discarding
  • Learning
  • Forwarding

And the listening state has been removed.

Why have Complexity ?

There is a maxim that GONERS will regularly tell junior engineers. Well, there are several. But one of the them is:

Just because you can doesn’t mean you should

Radia Perlman Explains Why Listening and Learning exists.

As a practical example, Radia Perlman from Section 3.4.2 of her book Interconnections, Second Edition says about the Spanning Tree Protocol (which she invented when working the Digital Equipment Corporation) :

The 802.1d standard actually calls for two intermediate states. This arrangement is designed to minimize learning of incorrect station locations while the topology has not yet stabilized. To minimize unnecessarily forwarded frames, the committee deemed it desirable not to allow a bridge to start forwarding until it has built up its learned cache. During the initial portion of the intermediate state, the bridge does not learn station addresses; then during the latter part, the bridge still does not forward packets over that port, but it does start learning station locations on that port. In other words, the intermediate state is subdivided into two substates: listening and learning. Note: in the original spanning tree algorithm, I had only a single intermediate state, known as preforwarding. The committee asked whether bridges should learn station addresses in the preforwarding state. I said I didn’t think it mattered. The committee decided to break preforwarding into the two aforementioned states. I believe that having two states is unnecessary and that bridges would work fine whether or not they learn station addresses in preforwarding. Breaking this period into two states makes the algorithm more complicated but does no harm. It would be an interesting project to study the trade-offs between the three strategies:

Translation: Someone on the committee wanted to make it more complicated, and because “it did no harm” it was approved and allowed to become part of the standard. From that day forward, every port on a bridge has an extra 15 second delay interval added to to the startup. Because someone didn’t seem to understand what happened.

What changed then ?

In the question of Chapter 3:

As stated in Section 3.4.2, the original spanning tree algorithm had only a single intermediate state between blocking and forwarding and did not indicate whether a bridge should perform learning of station addresses on a port in the intermediate state. The 802 bridge spec subdivides the intermediate state into two states. In the first, learning is not done; in the second, learning is done. Compare the following three strategies: a. A single intermediate state, in which learning is done b. A single intermediate state, in which learning is not done c. As in the spec, two intermediate states Consider the implications, such as unnecessarily forwarded frames and incorrect cache entries, of each strategy.

I can’t really see the advantage of breaking Listening and Learning states into two parts. If anyone knows what the logic was, or why they did it, I’d be interested in knowing why.

Complexity is Unnecessary

Complexity is the enemy of reliability and it seems such a shame that this happened. How many people were affected by this decision ? How much time has been spent attempting to engineer faster recovery and convergence within failure domains at Layer 2 ? In the end, Rapid Spanning Tree Protocol implemented the recommendation and had only two states.

It’s a demonstration that complexity in a design is always a bad choice and, in my opinion, must be rigorously proven before it is used. Always look for the simple design, don’t do complexity “just because”.

Postscript

I started the notes for this post in Aug 2008. Either I’m:

  • realising I’ve been doing this for a long time now.
  • too lazy to finish what I start and should have posted it in 2008.
  • well organised for keeping the notes for that long
  • not a very good writer.

Anyone who wants to say “all of the above” will also be correct.

About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

You can contact Greg via the site contact page.

  • ananth

    Hi

    I think learning state is needed and listening of BPDUs should be performed during learning state itself. I do not agree with Perlman ( with due respect) that learning of mac address does not matter.

    Think about big layer 2 domain and analyze the broadcast storm during convergence without learning
    state.

    Regards
    Ananth

  • Niall

    FYI the link to the definition of GONER is b0rked … think it should start with a ‘/’ :-)

    • http://etherealmind.com Greg Ferro

      Thanks Niall. Fixed.

  • Aries

    Super like this write-up. I always wondered this myself, but for once my thinking is correct. They are unnecessarily wasting 15 seconds of valuable time in listening / learning.

Subscribe For Weekly Updates by Email

Get a Weekly Summary of Latest Articles and Posts to your Email Inbox Every Sunday

Thanks for signing up. Look for the email from MailChimp & make sure you confirm your email address. You may need to check your spam or gmail settings to be sure of receiving the email.

Note: You can unsubscribe at any time using the link at the bottom of every email.