Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Receiving BPDU on a designated port (STP)

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        

5 REPLIES
VIP Super Bronze

Receiving BPDU on a designated port (STP)

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

New Member

Receiving BPDU on a designated port (STP)

Hi Reza,

Thanks for quick reply. What if i dont have root guard enabled?

VIP Super Bronze

Re: Receiving BPDU on a designated port (STP)

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

New Member

Receiving BPDU on a designated port (STP)

Hi Reza,

What about if same root's BPDU but better cost is received on Desginated port?

Silver

Receiving BPDU on a designated port (STP)

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.

Daniel Dib CCIE #37149 Please rate helpful posts.
814
Views
0
Helpful
5
Replies
CreatePlease login to create content