STP – do we really need a Listening state?
Long story, but I had a reason today to try and think of a case in which a temporary loop might occur for which the listening state in STP was really necessary. The short answer? I couldn’t come up with one. And I found an interesting quote along the way. Maybe you’ll find the quote from Radia Perlman, creator of STP, to be interesting – I sure did.
First off, listening state is that interim 802.1D STP state in which a switch listens for BPDUs, but does not learn MAC addresses. The reason for the state is to allow time for the MAC table entries to timeout, so that during learning state, the switch can learn new states. With default timers, a switch will timeout all entries in the MAC table in the same time it spends in a listening state.
What I can’t do is find a case in which if the listening state allowed a switch to learn new MAC address table entries, a loop would occur with unicast frames. First off, the MAC address table learning process does not change the STP topology (the set of forwarding and blocking interfaces). But if the STP topology had a temporary loop, then broadcasts would loop. The question is, could unicast frames loop, assuming that the “wrong” MAC table entry was learned, assuming listening state allowed switches to learn new MAC table entries?
Whew, that’s a lot. I couldn’t come up with a good example. Can you? Post away.
In the mean time, I looked to the source: Radia Perlman. She create spanning tree while at MIT, and wrote a wonderful book 20 years or so about spanning tree and routing, called “interconnections”. And here’s an interesting quote on this very subject – very telling about whether we really need a listening state, in which no new MAC table entries are learned. From page 63:
“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 (added by Wendell: listening, learning). I believe that having two states is unnecessary and that bridges would work fine regardless of whether or not they learn station addresses in preforwarding. Breaking this period into two states makes the algorithm more complicated to understand but does not harm”
Looks like the listening state may not have been needed at all, all these years. Of course, today, in real life, we’d just use the RSTP 802.1w version of spanning tree. But maybe you found this brief diversion interesting as well. Here’s a link to the book if interested – an oldie but a goodie.