At the (gigabit wireless) ISP we were looking to use new low-cost switches, and were doing hands-on testing with several models. It wasn't long into testing before we discovered not-to-be-named manufacturer didn't follow the spec for
RSTP. Ahh, another day, another vendor that didn't follow the spec. Well this switch was interesting in how it violated the specs. Instead of having the correct IEEE 802.1w/d behavior, the switch happens to have the same erroneous behavior as described in the RSTP page on Cisco's learning center! (Makes you wonder what the engineers were reading as they built their
The issue is around how the not-to-be-named switch responds to Proposal
BPDUs. Upon receiving a favorable
BPDU from previously unknown
Switch B is supposed to set a few internal state variables, like port role, learning state, and topology change counter. Then, according to the spec, in its next
Switch B is supposed to send this state information along with some background info like the bridge-id and port-id.
Let's see what happens. No-to-be-named is happily sending
The Ubiquiti switch is connected, not-to-be-named receives a
BPDU from Ubiqiuti with a lower bridge-id.
Not-to-be-named recognizes that the Ubiquiti should be the new root bridge and it sends out a
BPDU. And in that
BPDU, not-to-be-named-switch sends its own bridge-id and port-id as specified sends
0x8004 the bridge-id and port-it of the Ubiquiti switch (not-to-be-named doesn't even have a connection on port
It's almost as if not-to-be-named took the Ubiquiti Proposal
BPDU, scratched out the proposal flag, added the agreement, forwarding, learning, and root-port flag, and sent it right back to Ubiquiti. This is interesting, because this is exactly how the the Cisco docs say
RSTP proposal acceptance works.
"Switch A can unblock its newly selected root port p1 and send an agreement message to reply to the root. (see step 3). This [agreement] message is a copy of the proposal BPDU, with the agreement bit set instead of the proposal bit. This ensures that port p0 knows exactly to which proposal the agreement it receives corresponds."
- Cisco Understanding Rapid Spanning Tree Protocol
So the switch gets
RSTP wrong the same way the Cisco docs get
RSTP wrong. It's fun to imagine the engineers were mislead by the Cisco docs, but it's probably a coincidence. Or possibly confounding. There is probably some other equipment or doc out there that both not-to-be-named and Cisco were looking at when they made their respective errors. Cisco has proprietary STP implementations, perhaps one of these uses the erroneous flip-the-ack-bit-and-return behavior. I can say that this error does not arise from mixing old
STP mechanics into
STP uses similar acknowledgement mechanics to
Cisco has helpful learning materials, but they aren't IEEE specs, and as we've seen, they aren't always correct. If you're developing a product, there is really no excuse for not following the official IEEE spec 1. In this case IEEE 802.1W-2001 or updated IEEE 802.1D-2004.
I can't help but try to imagine how this mistake came about. I imagine confused engineers in corporate offices, building the switch with one book in hand: Switches for Dummies. Let's hope the LACP chapter was better!
Additionally, there really is no excuse for not running the equipment through a test suite like IxANVL. The proceedure isn't 1) try my best to implement the spec, 2) just release it. The proceedure is 1) try my best to implement the spec, 2) verify my work with a protocol tester!