[RSTP] [ixANVL 13.2] Designated port transmits unexpected BPDU (Proposal=1, Agreement=1) due to state contamination

[xl4-allan]

ixANVL RSTP Conformance Test No 13.2, sub-issue of Issue #39

Description

Verify that when a port receives a superior BPDU carrying a Proposal flag, it properly executes recordProposal() to set its internal proposed flag, successfully triggering the RSTP synchronization mechanism that forces all other active ports to temporarily stop learning and forwarding.

References

• IEEE Std 802.1D-2004 S17.27 P173 Port Information state machine
• IEEE Std 802.1D- 2004 S17.21.11 P167 recordProposal()

Test Steps

1. ANVL injects a RST BPDU on Port 1 with a Designated Port role with a Superior Bridge ID.
2. ANVL injects a RST BPDU on Port 2 with a Root Port role for an inferior Bridge ID.
3. ANVL Waits for an RST BPDU from DUT on Port 2 for up to 2x HelloTime.
4. ANVL verify that RST BPDU from DUT has Learning and Forwarding flags set to TRUE (establishing the baseline active state).
5. ANVL wait for 3x HelloTime to allow the state machine to completely stabilize.
6. ANVL injects a new, Superior RST BPDU on Port 1 announcing a better Root Bridge, with the Proposal flag set to TRUE and the Port Role set to Designated.
7. ANVL waits for an RST BPDU from DUT on Port 2 for up to 2x HelloTime.

Expected behavior

DUT transmits a RST BPDU with both Learning and Forwarding flag set to FALSE.

Actual behavior

The DUT seems to successfully drops to Discarding to sync as it was able to transmits an RST BPDU with the following Flags:

• Proposal: TRUE
• Learning: FALSE
• Forwarding: FALSE
• Agreement: TRUE

Initial Observation/Analysis

Although both Learning and Forwarding are correctly set to False, we notice that both the Proposal and Agreement flags are set to True simultaneously.

Normally, under standard RSTP state machine transitions, a port preparing to sync enters the DESIGNATED_PROPOSE state, where the Forwarding flag is FALSE and the Proposal flag is TRUE. The Agreement flag is generally associated with the DESIGNATED_AGREE state, where a port has synchronized and the Forwarding flag transitions to TRUE.

Our working hypothesis is that mstp-lib might be carrying over stale internal state variables (such as agree or agreed) from previous tests. Consequently, when it drops the port to Discarding and generates a Proposal BPDU, it inadvertently leaves the Agreement bit flipped on.

Furthermore, we suspect this anomalous BPDU (Proposal=TRUE, Agreement=TRUE, Learning=FALSE, Forwarding=FALSE) is what confuses the ixANVL test harness. While we cannot see ixANVL's proprietary validation code, the fact that it throws the following error:

! Learning flag in the Flags field of the RST BPDU is
! incorrectly set to FALSE

! Forwarding flag in the Flags field of the RST BPDU is
! incorrectly set to FALSE

Suggests its parser might be reading the Agreement=TRUE flag, assuming the port must be in an active/forwarding state, and thus failing the test because it expects the Learning and Forwarding flags to also be TRUE.

Note: The test passes on a fresh boot but with both LearningandForwardingflags set toTRUE` but proposal was set to FALSE.

Attachments

RSTP-ConformanceTest-13.2-FAILED.log