I didnt understand some points on RSTP Negotiation process,
What are they "sync"in? If both sides are in forwarding it means synced? If one side is failed and is non designated, does it mean it is unsynced for RSTP point of view?
In which situations negotiation process is beginning? The moment we plug a switch to another switch for example, in that case they are starting to use negotiation process always, right?
what is The success criteria for sending Agreement BPDU to root switch ? Being in forwarding state of ports in SW2?
The term âsyncâ here is referring the negotiation process that is taking place between RSTP switches. It doesnât refer to a state of being âin syncâ when both sides are in a particular stage. The negotiation itself is called âsyncâ or âsynchronizingâ.
During this convergence process, the switches actually send each other what are known as âsyncâ message to prepare them for upcoming changes in the network topology.
The beginning of the negotiation process is indeed when the switches are first plugged in.
The successful negotiation results in a stable state or topology. After the sync, proposal, and agreement messages, when the switches and their ports obtain a particular role (forwarding or blocked) and it remains stable, the result is a successful RSTP reconvergence.
For more information, take a look at these NetworkLessons notes:
Quick question - on the topology with the two half-duplex, shared links to the hub from SW2 and from SW3, if there were only one half-duplex link on each side of the hub, what would the port roles be on SW2 and on SW3? Would it be designated on SW2 and alternate on SW3? Or would it be backup on SW2 and alternate on SW3?
I donât see a topology using a hub or links functioning in half-duplex mode in this lesson. Just to clarify, Rene stated in the lesson that IF you have a hub connected to the network, then the switches that connect to that hub will consider their ports connected to the hub as shared. If they are shared, they cannot and will not enter the forwarding state immediately.
Other than that, the functionality of RSTP remains unchanged.
Just a note, the term âhubâ used here refers to the network device, not the topology location. In other words, weâre not talking about the hub of a hub and spoke topology.
In this lesson rene used letters like AAA BBB CCC DDD instead of real mac addresses. If someone want to replay this lab in for example GNS3, the switches need to have real mac addresses. But when you build the lab in GNS3 you donât know in advance which switch will have the lowest mac address.
See screenshot. Itâs easy to predict that SW4 will become the Root.
But in the lesson SW1 is the root. Changing the priority of SW1 is not what you should do because all switches have the same priority.
What to do? Instead I changed the mac address of GI 0/0 of SW1 to make it the lowest mac address with the command :
SW1#config t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int
SW1(config)#interface gi
SW1(config)#interface gigabitEthernet 0/0
SW1(config-if)#mac-add
SW1(config-if)#mac-address 0c:11:ab:11:00:00
SW1(config-if)#mac-address 0c:11:ab:11:00:00
SW1(config-if)#
SW1(config-if)#
SW1(config-if)#do show int
SW1(config-if)#do show int gi
SW1(config-if)#do show int gig
SW1(config-if)#do show int gig 0/0
GigabitEthernet0/0 is up, line protocol is up (connected)
Hardware is iGbE, address is 0c11.ab11.0000 (bia 0ca5.a85e.0000)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
But when you give the command
SW1(config-if)#do show span
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0c11.ab12.0000
Cost 8
Port 1 (GigabitEthernet0/0)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0ca5.a85e.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
The mac address 0ca5.a85e.0000 is still there:
SW1#show span
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0c11.ab12.0000
Cost 8
Port 1 (GigabitEthernet0/0)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 0ca5.a85e.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/0 Root FWD 4 128.1 P2p
How can I make sure that the mac address persist after I change it.
Rene used AAA BBB and CCC for convenience in the lab. However, in a real-world environment, you would never modify the MAC addresses to conform to a particular behavior. You would use whatever MACs are set on the switches. For this reason, to simulate a real-world situation as much as possible, you should simply deal with the lab with whatever MACs your switches have.
When you use the mac-address command to change the MAC of an interface, RSTP still does not use these MAC addresses to operate. Take a look at this output:
SW(config-if)#mac-address AAAA.AAAA.AAAA
SW(config-if)#exit
SW(config)#exit
SW#show interfaces gig 0/0
GigabitEthernet0/0 is up, line protocol is up (connected)
Hardware is iGbE, address is aaaa.aaaa.aaaa (bia 5254.0000.49a8)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
!<---- Output Omitted ---->
Notice that the hardware address shown is indeed aaaa.aaaa.aaaa as configured, but the Burned In Address (BIA) is still the original MAC. RSTP will always use the BIA.
Now if you want to change which switch will become the root bridge, you should use the priority configurations as shown in the lesson.
After doing a bit of research, I have found that the TC while timer is a hardwired internal mechanism of STP and cannot be observed directly. It can be configured indirectly by adjusting the hello timer, since the TC while timer is 2x the hello timer.
You can also see if the TC while timer is currently non-zero by examining if the TC flag is set (as seen in the output of the show spanning-tree detail command).
Other than that, there is no way that I know of to directly observe the TC while timer.
You only use the TCA flag to acknowledge the reception of a TCN BPDU, correct?
Which doesnât exist in RSTP since it immediately sets the TC bit on its BPDUs.
In RSTP, if a designated port sends a proposal but does not receive a BPDU with the agreement bit set, the following actions can occur:
The designated port starts a proposal timer. This timer is intended to give the downstream switch (the one that should send the agreement) time to process the proposal and respond with an agreement BPDU.
Until the agreement is received, the port that sent the proposal will not transition to the forwarding state, ensuring that no loops are created during the topology change.
The designated port may periodically resend the proposal BPDU if it doesnât receive an agreement within the expected timeframe.
While waiting for the agreement, the port remains in the listening and learning states, during which it continues to receive and process BPDUs.
If the agreement is not received within a certain period, the switch may fall back to traditional STP behavior. This of course involves a longer convergence time as the port transitions through the usual STP states (blocking, listening, learning, and finally forwarding).
The key point here is that RSTPâs proposal and agreement mechanism is designed to rapidly transition ports to the forwarding state while maintaining loop-free topologies. The absence of an agreement BPDU means that the transition to forwarding is halted to prevent potential network loops, or the operation falls back to STP.
If i am correct, RSTP is unlike the classic STP timer based protocol. Rather, its a sync mechanism based protocol. Then how does the sync process rely on a timer?. Please clarify thisâŠ
If there is a proposal timer, please let me know the numbers
The BPDU you posted is indeed an RSTP BPDU. Note that a conventional 802.1D BPDU uses only bits 0 and 7 from the 1-byte flags field, and bits 2 to 6 are unused. Bit 0 is the TC while bit 7 is the TCA. For RSTP bit 0 is the TCA while bit 7 is the TC.
Now why does RSTP have a TCA flag since a TCN BPDU doesnât exist in RSTP? While itâs true that the TCA flag is used in STP to acknowledge the receipt of a TCN BPDU, in RSTP its usage is slightly different.
In RSTP, the TCA flag is set to acknowledge the receipt of a BPDU with the TC flag set. This is done to prevent unnecessary flooding of BPDUs in the network. So, while you might not commonly see it set to 1, itâs there for those cases when a BPDU with the TC flag is received.
Thank you for the reply. What do you mean by this?
This is done to prevent unnecessary flooding of BPDUs in the network. So, while you might not commonly see it set to 1, itâs there for those cases when a BPDU with the TC flag is received.
BPDUs will be generated every hello timer regardless of whether one of them was acknowledged or not, correct? So what effect will acknowledging something have on the flooding of BPDUs?
Traditional STP relies on timers (Hello, Forward Delay, listening, learning, and Max Age) to manage the convergence of the spanning tree. As you correctly insinuated, RSTP introduces a more dynamic approach to achieve faster convergence using its sync mechanism.
While this sync mechanism used by RSTP minimizes the reliance on traditional timers for convergence, it still uses a few timers for specific purposes. One of these is the proposal timer.
When a switch wants to initiate a change in the STP topology (for example, when a new switch is added or a topology change is detected), it sends a Proposal BPDU to its neighboring switches. The Proposal Timer helps manage this process by:
Timing the Response: The Proposal Timer sets a limit on how long a switch should wait for an Agreement BPDU from its neighbors after it sends out a Proposal BPDU.
Avoiding Loops: By using this timer, RSTP ensures that switches do not immediately transition their ports to the forwarding state, which could potentially create temporary loops in the network. Instead, they wait for an explicit agreement from their neighbors.
The proposal timer in this case is not used like the listening, learning, and forward delay timers in traditional STP, where they must elapse before the topology is functional. It is a timeout timer that is used as part of the sync mechanism. Does that make sense?
Youâre correct in saying that BPDUs are generated every hello timer, regardless of whether they are acknowledged or not. However, the point here is not about acknowledging the BPDUs but about the TC flag that can be set in a BPDU.
When a switch receives a BPDU with the TC flag set, it means there has been a change in the network topology. In response to this, the switch will start to send out its own BPDUs with the TC flag set, to inform other switches about the change. This can lead to a large number of BPDUs being sent across the network which can result in unnecessary flooding of BPDUs.
The TC flag is cleared (reset to 0) after a certain amount of time to prevent this flooding from continuing indefinitely. However, when a switch receives a BPDU with the TC flag set, it can send an acknowledgment back to the originating switch to let it know that it has received the message about the topology change. This can help to reduce the number of BPDUs being sent out, as once a switch has been acknowledged, it knows it can stop sending BPDUs with the TC flag set.
