stp backbonefast , uplinkfast and instant forwarding of blocked port

[sarahr202]

Hi everybody.

Backbonefast eliminates max -age times( default is 20 sec),while uplinkfast eliminates listening and learning times( default is 30 sec).

If we have an access switch as

rest of switched network-----------f1/1 blockedport SW f1/1 Rootport-------------------rootswitch

Let say our network is configured with backbonefast feature and we enable uplinkfast on sw1,;sw1 receives an inferior bpdu on its blocked port ,will sw1  instantly transition the f1/1 to forwarding states because backbonefast eliminates max age timer and uplinkfast eliminates listening and learning times ?

thanks and have a great weekend

[Vivek Ganapathi · Accepted solution]

Hello Sarah,

Unable to understand your topology exactly. Please provide an appropriate topology & will work on it further.

Thanks

Vivek

[sarahr202]

Thanks Vivek .

Please disregard my question because it is not possible.  Let me elaborate on it.

Suppose we have an access switch configured with uplinkfast and backbonefast features with one blockedport and one root port.

If this access switch receives a inferior bpdu  on its blocked port, Will such port be put in forarding state rightaway? ( backbonefast eliminates max-age time and uplinkfast eliminates times in listening and learning states?

I just realised it is not possible because backbonefast feature kicks in when a switch receives inferior bpdu and uplinkfast kicks in when superior bpdu is received. Since in our example above switch receives an inferior bpdu so backbone feature kicks in and eliminates 20 sec . But switch still put its blocked port through listening and learning states.Uplink feature though configured on switch does not kick in because switch did not receive a superior bpdu.

Have a great weekend.

[Reza Sharifi · Accepted solution]

Hi Sarah,

Since Backbone fast covers a wider range of switches and it can detect a link that is not directly connected to the local switch, the convergence can take up to 50 seconds.  Backbone fast reduces 50  to 20 seconds.  Uplink fast reduces the convergence time from 30 seconds to about 14 seconds.  Keep in mined that Backbone fast and uplink fast were design to speed the convergence before RSTP (802.1w) was released. 802.1w already had these capacities and no need for these protocols.

Here are a couple good doc for reference:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094641.shtml

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800c2548.shtml

Have a nice weekend

HTH

[sarahr202]

Thanks Reza

With regard to Backbonefast, Does RLQ request look like as:

o.     Time        Source                Destination           Protocol Length Info

    123 226.204000  c0:02:0f:d8:f1:05     Spanning-tree-(for-bridges)_00 LLC      60     U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0108

Frame 123: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)

IEEE 802.3 Ethernet

    Destination: Spanning-tree-(for-bridges)_00 (01:80:c2:00:00:00)

    Source: c0:02:0f:d8:f1:05 (c0:02:0f:d8:f1:05)

    Length: 43

    Trailer: 000000

Logical-Link Control

Data (35 bytes)

0000  00 00 00 00 00 80 00 c0 00 0f d8 00 00 00 00 00   ................

0010  13 80 00 c0 02 0f d8 00 00 80 2e 02 00 14 00 02   ................

0020  00 0f 00                                          ...

===========================

Does RLQ reply look like as:

o.     Time        Source                Destination           Protocol Length Info

    124 226.266000  c0:00:0f:d8:f1:03     Spanning-tree-(for-bridges)_00 LLC      60     U, func=UI; SNAP, OUI 0x00000C (Cisco), PID 0x0109

Frame 124: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)

IEEE 802.3 Ethernet

    Destination: Spanning-tree-(for-bridges)_00 (01:80:c2:00:00:00)

    Source: c0:00:0f:d8:f1:03 (c0:00:0f:d8:f1:03)

    Length: 43

    Trailer: 000000

Logical-Link Control

Data (35 bytes)

0000  00 00 00 00 00 80 00 c0 00 0f d8 00 00 00 00 00   ................

0010  00 80 00 c0 02 0f d8 00 00 80 2c 00 00 14 00 02   ..........,.....

0020  00 0f 00                                          ...

================================

Thanks for the links.

.

[krahmani323 · Accepted solution]

Hello Sarah,

Yes they are.

From the second link Reza provided (http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800c2548.shtml) it corresponds to the RLQ PDU format that you have captured.

Moreover PID 0x0108 (RLQ Request) and 0x0109 (RLQ reply) that we can see in your capture correspond to one of those Cisco Protocol IDs for SNAP encapsulated data. 

RLQ SNAP PIDs are not listed on the link below :

http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00801b49a4.shtml#pre4

But they are at the last slide of :

http://www.michaelanderson.ca/12W-NET3011-010/Wk03-Reference-EthernetFrames.pdf

Regards.

Karim