RSTP: The Cisco Docs Aren't the Spec

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 RSTP implementation.)

The issue is around how the not-to-be-named switch responds to Proposal BPDUs. Upon receiving a favorable BPDU from previously unknown Switch A, 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 BPDU, 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 BPDUs.

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 dc:9f:db:80:a9:e7 and 0x8004 the bridge-id and port-it of the Ubiquiti switch (not-to-be-named doesn't even have a connection on port 0x8004)!

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 RSTP. STP uses similar acknowledgement mechanics to RSTP.

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!

1: 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!