# RSTP Testing Analysis and Discussion

# Abstract

This experiment looks at the Advantech EKI-7710G switches. The article is split into three parts, each explaining a different network setup and situation to show how RSTP works. It also introduces the basics of RSTP so you can understand what’s happening.

# Basic Knowledge

Before we dive into the behavior research, it’s important that you’re familiar with the basic structure of an RSTP packet. Here’s a quick rundown of what it looks like: Take a look at the table I’ve attached below.

| **Field** | **Length** | **Description** |
| --- | --- | --- |
| DMAC | 6 Bytes | The MAC address this frame is sent to (always the STP multicast address) |
| SMAC | 6 Bytes | The originating device's MAC address |
| Length | 2 Bytes | Number of bytes in the following BPDU payload (excluding the final 4‑byte FCS) |
| Protocol Identifier | 2 Bytes | Always set to 0x0000—identifies the payload as a spanning tree message |
| Protocol Version Identifier | 1 Bytes | Indicates which protocol version is used: 0 = STP, 2 = RSTP, 3 = MSTP |
| BPDU Type | 1 Bytes | 0x00 = STP Configuration BPDU, 0x80 = TCN BPDU, 0x02 = RSTP or MSTP Configuration BPDU |
| Flags | 1 Bytes | Various control bits. In RSTP/MSTP: TCA, Agreement, Forwarding, Learning, Port Role (2 bits), Proposal, Topology Change |
| Root Identifier | 8 Bytes | Priority + MAC address of the bridge considered the root |
| Root Path Cost | 4 Bytes | Total path cost to reach the root bridge. In MSTP, this is the external (inter-region) cost |
| Bridge Identifier | 8 Bytes | Sender’s bridge priority + MAC |
| Port Identifier | 2 Bytes | Identifier of the port sending the BPDU. |
| Message Age | 2 Bytes | Time (in seconds) since the BPDU originated from the root |
| Max Age | 2 Bytes | Lifetime threshold of the BPDU. If exceeded, paths toward root are considered invalid |
| Hello Time | 2 Bytes | Interval between consecutive BPDU transmissions by the root on designated ports |
| Forward Delay | 2 Bytes | Duration (in seconds) for port states Listening and Learning during topology change |

Check out the table above. The Flags field is super important when you’re changing the topology of an RSTP network. Each bit in the Flags byte has a specific meaning that affects how switches talk to each other and react when the network is coming together. Understanding these flag bits is crucial for figuring out how the protocol works in different situations.

Here’s a breakdown of what each bit means in the Flags field of a packet format.

| **Flag Bit** | Length | **Description** |
| --- | --- | --- |
| Topology Change (TC) | 1 Bit | Indicates a topology change has been detected, and notify to all switches in the RSTP network |
| Proposal | 1 Bit | Used in the negotiation process when a port wants to be a designated port |
| Port Role | 2 Bits | Indicates port role: b00=Unknown, b01=Alternate/Backup, b10=Root, b11=Designated |
| Learning | 1 Bit | Indicates the port is in Learning state |
| Forwarding | 1 Bit | Indicates the port is in Forwarding state |
| Agreement | 1 Bit | Response to a Proposal, confirming the port role negotiation |
| Topology Change Acknowledgment (TCA) | 1 Bit | Acknowledges receipt of a Topology Change notification |

<aside>
📒

The information I am about to share is based on my own experiments, official documentation, and observations in the network. I will disclose that some of these explanations are derived from my testing rather than directly from the specifications.

</aside>

# Experiments

This test is based on a link-up scenario, so the link-down process will be slightly different from what’s described here. But you can still refer to this experiment to get a basic idea of how negotiation works.

## Single Ring Test Architecture


### Test Scenario 1: Creating a Loop with Root Bridge

- Environment: SW1 GE1 and SW2 GE8 were originally disconnected, other connections unchanged
- Scenario: Connect SW1 GE1 to SW2 GE8
- Expected Behavior (From Advantech and Cisco Documents):
- SW2 GE8 and SW1 GE1 would first Block
- SW2 would begin Proposal exchange with SW1
- SW2 would change non-edge designated ports to Blocking state, while confirming RP or DP
- SW2 would send Agreement to SW1 after blocking each non-edge designated port, and vice versa
- SW2, SW3 & SW4 would begin Convergence (using Proposal/Agreement to confirm DP)
- Final result: SW4 GE8 would change to Blocking (Discarding)
- Actual Test Behavior:
- Initial stable state of SW2 packets:
- Input from SW4: Learn, Forward, Agreement
- Output to SW3: Learn, Forward, Agreement (Sometimes → Learn, Forward)
- SW2 GE8 received empty BPDU from SW1 [At this point SW2 GE8 should be in Blocking state]
- SW2 received Proposal packets from SW1
- SW2 only performed Blocking with SW4 (shown on console port)
- SW2 only performed Convergence with SW4 (using Proposal/Agreement to confirm DP) → Only SW2 and SW4, without direct SW1 intervention
- SW2 → SW4: Proposal, Agreement
- SW4 → SW2: Learn, Forward, Agreement
- After SW2 and SW4 handshake completion,
- SW2 reply Agreement to SW1
- SW2 sent TC to every Port, repeated twice
- SW1 would repeat Proposal to SW2, but SW2 will ignore it.
- After SW1 and SW2 handshake completion, SW1 also sent TC twice to SW2, and SW2 forwarded each to SW3 and SW4
- Final stable state of SW2 packets:
- Input from SW1: Learn, Forward, Agreement
- Output to SW3: Learn, Forward, Agreement (Sometimes → Learn, Forward)
- Output to SW4: Learn, Forward, Agreement

### Test Scenario 2: Connecting Two Non-root Bridges

- Environment: SW4 GE8 and SW5 GE7 were originally disconnected, other connections unchanged
- Scenario: Connect SW4 GE8 to SW5 GE7
- Actual Test Behavior:
- Initial stable state of SW4 packets:
- Input from SW2: Learn, Forward, Agreement
- SW4 GE8 received empty BPDU from SW5 [At this point SW4 GE8 should be in Blocking state]
- SW4 and SW5 exchanged Proposals
- SW4 determined GE8 must be Alternate, so Port Role changed to Alternate in the next packet (SW5 did not Block GE8)
- SW4 sent Agreement to SW5
- SW5 sent five more Proposals, and SW4 responded with Agreement each time
- SW5 sent TC twice to SW1 and SW4, and TC received by SW1 was forwarded through SW2 to SW4
- Final stable state of SW4 packets:
- Input from SW2: Learn, Forward, Agreement
- Input from SW5: Learn, Forward

## Tree Structure Test Architecture


### Test Scenario 1: Connecting Old Root to New Root

- Environment: SW1 GE1 and SW2 GE8 were originally disconnected, other connections unchanged
- Scenario: Connect SW1 GE1 to SW2 GE8
- Actual Test Behavior:
- Initial stable state of SW2 packets:
- Output to SW3: Learn, Forward
- Output to SW4: Learn, Forward
- SW2 GE8 received empty BPDU from SW1 [At this point SW2 GE8 should be in Blocking state]
- SW2 began Proposal exchange with SW1
- SW2 confirmed Root Bridge changed to SW1 and sent BPDU with this information to SW3, SW4
- SW2 and SW1 exchanged Agreements (SW2 did not Block any Non-edge Designated Port)
- SW2 sent TC twice to SW1, SW3, SW4, while SW1 continued sending Proposals to SW2
- SW1 sent TC twice to SW2, which forwarded them to SW3, SW4 (propagating down the tree)
- Final stable state of SW2 packets:
- Input from SW1: Learn, Forward, Agreement
- Output to SW3: Learn, Forward
- Output to SW4: Learn, Forward

## Linear Test Architecture


### Test Scenario 1: Non-direct Connection Negotiation Between Two Root Bridges

- Environment: SW4 GE8 and SW5 GE7 were originally disconnected, other connections unchanged
- Scenario: Connect SW4 GE8 to SW5 GE7
- Actual Test Behavior:
- Initial stable state of SW4 packets:
- Input from SW2: Learn, Forward, Agreement
- SW4 GE8 received BPDU from SW5 [At this point SW4 GE8 should be in Blocking state]
- SW4 began Proposal exchange with SW5
- SW4 identified: (1) Root Bridge needed to change, (2) Root Port needed to change
- SW4 Blocked GE7 and sent standard BPDU and Proposal to SW2 with new Root Bridge ID (but SW5 did not Block GE8)
- SW4 received Learn, Forward, **Agreement** from SW2 (with correct Root ID)
- SW4 returned Agreement to SW5 [At this point SW4 GE8 should change to Forwarding state]
- SW4 sent TC to SW2 and SW5, with Proposal attached to SW2's TC
- SW5 continuously sent five Proposals to SW4 (not forwarded from SW1 through SW5)
- SW5 sent TC twice to SW1 and SW4
- Final stable state of SW4 packets:
- Input from SW5: Learn, Forward
- Output to SW2: Learn, Forward, Agreement

# Conclusion

Due to the limited scope of the experiments, when organizing RSTP behaviors, I'll focus primarily on what happens when a link comes up, describing the main processes from the perspective of a single switch. Below is the flowchart I've prepared for your reference.


# Reference

1. Advantech IoT Academy: Understand the Implementation of L2 Networking Protocol in EKI-7000/9000 Managed Ethernet Switch, https://academy.advantech.com/learner/courseinfo/id:158