01-01-2014 02:35 PM - edited 03-10-2019 12:25 PM
Hello,
In a STP converged network, what swtich will do if it receives a superior BPDU (of same root) on a designated port? Will it instantly put its root port into blocking mode and transitions the designated port from listening, learning to forwarding?
Thanks
01-01-2014 04:05 PM
Hi,
According to the spanning tree doc:
after the switch receives a superior BPDU. Root guard puts the port in the root-inconsistent STP state. No traffic passes through the port in this state. After device D ceases to send superior BPDUs, the port is unblocked again. Via STP, the port goes from the listening state to the learning state, and eventually transitions to the forwarding state. Recovery is automatic; no human intervention is necessary.
Link:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800ae96b.shtml#feature
HTH
01-01-2014 04:11 PM
Hi Reza,
Thanks for quick reply. What if i dont have root guard enabled?
01-01-2014 06:39 PM
Hi Zafar,
In that case if the switch receives a superior BPDU, which usually means that switch has a lower bridge id and so it can cause the STP topology to reconverge.
HTH
01-01-2014 09:45 PM
Hi Reza,
What about if same root's BPDU but better cost is received on Desginated port?
01-02-2014 12:57 AM
First a demonstration with PVST+ with the following topology:
SW2 has E0/0 as as root port towards SW1. The cost of links has been modified to make it easy to change the forwarding path.
SW2#sh span
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 16385
Address aabb.cc00.0100
Cost 1000
Port 1 (Ethernet0/0)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address aabb.cc00.0200
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0 Root FWD 1000 128.1 P2p
Et0/1 Desg FWD 1000 128.2 P2p
Now to remove the cost on the E0/0 interface of SW3 and E0/1 interface of SW2. This should make SW3 send a better BPDU making SW2 change its root port.
SW2(config)#int e0/1
SW2(config-if)#no span cost 1000
SW3(config)#int e0/0
SW3(config-if)#no span cost 1000
SW2 immediately changes port E0/1 to root and blocks on the alternate port.
Jan 2 08:32:43.840: STP: VLAN0001 new root port Et0/1, cost 200
Jan 2 08:32:43.840: STP: VLAN0001 sent Topology Change Notice on Et0/1
Jan 2 08:32:43.840: STP[1]: Generating TC trap for port Ethernet0/0
Jan 2 08:32:43.840: STP: VLAN0001 Et0/0 -> blocking
Because SW3 is now designated on E0/1 it has to bring it through listening -> learning -> forwarding.
Jan 2 08:32:42.011: STP: VLAN0001 Et0/1 -> listening
Jan 2 08:32:43.840: STP: VLAN0001 Topology Change rcvd on Et0/1
Jan 2 08:32:43.840: STP: VLAN0001 sent Topology Change Notice on Et0/0
Jan 2 08:32:57.016: STP: VLAN0001 Et0/1 -> learning
Jan 2 08:33:12.020: STP[1]: Generating TC trap for port Ethernet0/1
Jan 2 08:33:12.020: STP: VLAN0001 sent Topology Change Notice on Et0/0
Jan 2 08:33:12.020: STP: VLAN0001 Et0/1 -> forwarding
This took roughly 30 seconds in total because the forward delay timer is 15 seconds so it spends 15 seconds in listening and 15 seconds in learning before moving to forwarding.
This is what 802.1D-1998 says:
8.3.4 Changing Port State
Since there are propagation delays in passing protocol information throughout a Bridged LAN, there cannot
be a sharp transition from one active topology to another. Topology changes may take place at different
times in different parts of the Bridged LAN and to move a Bridge Port directly from nonparticipation in the
active topology to the Forwarding State would be to risk having temporary data loops and the duplication
and misordering of frames. It is also desirable to allow other Bridges time to reply to inferior protocol information
before starting to forward frames.
Bridge Ports must therefore wait for new topology information to propagate throughout the Bridged LAN,
and for the frame lifetime of any frames forwarded using the old active topology to expire, before forwarding
frames.
During this time it is also desirable to time out station location information in the Filtering Database that
may no longer be true and, during the latter part of this interval, to learn new station location information in
order to minimize the effect of initial flooding of frames when the Port enters a Forwarding State. When the
algorithm decides that a Port should be put into the Forwarding State, it is, therefore, first put into a Listening
State where it waits for protocol information that suggests it should return to the Blocking State, and for
the expiry of a protocol timer that would move it into a Learning State. In the Learning State, it still blocks
the forwarding of frames, but learned station location information is included by the Learning Process in the
Filtering Database. Finally the expiry of a protocol timer moves it into the Forwarding State where both forwarding
of relayed frames and learning of station location information are enabled.
Figure 8-3 shows the transitions between the Port States.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
So only ports that move to forwarding must go through listening and learning.
8.3.5 Notifying topology changes
In normal stable operation, station location information in the Filtering Database need only change as a consequence
of the physical relocation of stations. It may, therefore, be desirable to employ a long ageing time
for entries in the Filtering Database, especially as many end stations transmit frames following power-up
after relocation, which would cause station location information to be relearned.
However, when the active topology of a Bridged LAN reconfigures, end stations may appear to move from
the point of view of a Bridge in the network. This is true even if the states of the Ports on that Bridge have
not changed. It is necessary for station location to be relearned following a change in the active topology,
even if only part of the Bridged LAN has reconfigured.
The Spanning Tree Algorithm and Protocol provide procedures for a Bridge that detects a change in active
topology to notify the Root of the change reliably, and for the Root subsequently to communicate the change
to all the Bridges. The Bridges then use a short value to age out dynamic entries in the Fitering Database for
a period.
----------------------------------------------------------------------------------------------------------------------------------------------------------
Topology change was sent out the root port and reaching the root. This section of the standard describes how to make a port forwarding or blocking:
8.6.12 Make forwarding
8.6.12.1 Purpose
To permit a Port to participate in frame relay, following a suitable interval to ensure that temporary loops in
the Bridged LAN do not cause duplication of frames.
8.6.12.2 Use
As part of the Port State Selection procedure (8.6.11).
8.6.12.3 Procedure
If the Port State is Blocking, then
a) The Port State is set to Listening, and
b) The Forward Delay Timer for the Port is started.
8.6.13 Make blocking
8.6.13.1 Purpose
To terminate the participation of a Port in frame relay.
8.6.13.2 Use
As part of the Port State Selection procedure (8.6.11).
8.6.13.3 Procedure
If the Port is not in the Disabled or the Blocking State, then
a) If the Port is in the Forwarding or Learning State and the Change Detection Enabled parameter for
the Port is set, the Topology Change Detection procedure (8.6.14) is invoked;
b) The Port State for the Port is set to Blocking;
c) The Forward Delay Timer for the Port is stopped.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
So ports that are forwarding can go to blocking immediately. Ports that are blocking must go through listening, learning before moving to forwarding. SW2 could change the role of its port from designated to root, the port was already in forwarding so it just changed the role, it didn't have to go through the different port phases.
SW3 had to change its E0/1 from blocking to designated so it had to go through all the phases first. This is how standard PVST+ works, if moving a port to forwarding it takes about 30 seconds before the network is converged.
For RPVST+ it's another story. It uses a synchronization process. Immediately after receiving superior BPDU it can act on the information and synchronize the topology.
SW2#sh span
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 16385
Address aabb.cc00.0100
Cost 1000
Port 1 (Ethernet0/0)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address aabb.cc00.0200
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0 Root FWD 1000 128.1 P2p
Et0/1 Desg FWD 1000 128.2 P2p
SW2(config)#int e0/1
SW2(config-if)#no span cost 1000
SW3(config)#int e0/0
SW3(config-if)#no span cost 1000
SW2:
Jan 2 08:53:41.445: RSTP(1): updt roles, received superior bpdu on Et0/1
Jan 2 08:53:41.445: RSTP(1): Et0/1 is now alternate
Jan 2 08:53:41.952: RSTP(1): updt roles, non-tracked event
Jan 2 08:53:41.952: RSTP(1): Et0/1 is now root port
Jan 2 08:53:41.952: RSTP(1): Et0/0 blocked by re-root
Jan 2 08:53:41.952: RSTP(1): Et0/0 is now alternate
Jan 2 08:53:41.957: STP[1]: Generating TC trap for port Ethernet0/1
SW3:
Jan 2 08:53:41.441: RSTP(1): updt roles, non-tracked event
Jan 2 08:53:41.441: RSTP(1): Et0/1 is now designated
Jan 2 08:53:41.445: RSTP(1): transmitting a proposal on Et0/1
Jan 2 08:53:41.445: RSTP(1): received an agreement on Et0/1
Jan 2 08:53:41.445: STP[1]: Generating TC trap for port Ethernet0/1
SW3 port towards SW2 became designated so it sent a proposal out that port and SW2 agreed on it changing its root port towards SW3.
I haven't synchronized the time but as you can see from the logs it took only half a second to synchronize the topology and reacting to change compared to 30 seconds with PVST+.
Daniel Dib
CCIE #37149
Please rate helpful posts.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: