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.
Wendell
Great stuff my friend!
Thanks dude! This one was sort of an interesting mental exercise. Hope you’re doing well.
Interesting..
Hello,You told: ‘With default timers, a switch will timeout all entries in the MAC table in the same time it spends in a listening state’, but default aging for MAC Address entries is 300Sec and default listening state time is 15Sec. how all all entries in the MAC table get timeout?
Hi Ehsan,
Wow, I wrote this post over ten years ago… 🙂
To answer:
Independent of STP logic, I agree that Cisco switches default to a MAC table timeout of 300 seconds. What I didn’t fully explain in the 2nd paragraph above (which is where the sentence you quoted comes from) is this: When STP on a switch realizes the topology has changed, it no longer uses the 300 second MAC table timeout. It dynamically switches to using a different timeout value, equal to the current STP Forward Delay variable setting (default 15 seconds.) As a result, by the end of the Listening state, all related MAC table entries have expired. Hope that clears it up.
Also, FYI, RSTP just flushes the table – doesn’t have to wait. See section 13.27.28 of the 802.1Q-2018 standard if you want a little more.
Wendell
I did not know that after 10 years of this post, you will answer so quickly. Thank you very much
“It dynamically switches to using a different timeout value, equal to the current STP MaxAge variable setting (default 15 seconds.)”
Did you mean Forward delay instead of MaxAge? Default Forward delay is 15 seconds and MaxAge is 20 seconds.
Anyways, why reduce the MAC address aging timer and wait for it to expire? Why not just flush the MAC Address table immediately?
Sakar,
To your first point, yes, I referenced the wrong term for that timer. I just edited the comment – it’s Forward Delay.
As to your second point, asking why, well, I don’t know if I can help with that. RSTP does that, and it seems better. Anything I could say about why would be speculating about other people’s thoughts from decades ago, so… sorry, can’t really add anything there.
From Radia Perlman’s quote (eg “The committee asked whether bridges should learn station addresses in the preforwarding state. I said I didn’t think it mattered”), isn’t she saying that the learning state isn’t necessary? How does this imply that the listening state isn’t necessary?
Thank you.
Well, it’s been 12 years since I wrote this, and I don’t think it matters, but here’s what I recall, without doing any research.
What I recall is that the pre-forwarding state including learning. So, before the PhD committee interview, pre-forwarding behaved like learning. The additional state then was listening. So I probably concluded that it was listening that isn’t necessary. But I don’t recall ever reading anything that was overt from Dr. Perlman stating that overtly, so you can draw your own conclusions.
Hope this gives you some direction.
Wendell