cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3853
Views
5
Helpful
7
Replies

RSTP Not So Rapid

mmedwid
Level 3
Level 3

When I plug in a workstation to 3750 switch - it seems to take about 35 seconds before that workstation (hard coded IP) can ping the switch. You can see the console messages below. I configured RSTP and set this switch to root:

spanning-tree mode rapid-pvst

spanning-tree extend system-id

spanning-tree vlan 22,33,44 priority 8192

..and set the switchport to access and in the correct vlan:

interface GigabitEthernet1/0/1

switchport access vlan 22

switchport mode access

Shouldn't RSTP figure out start forwarding packets in like 10 or 15 seconds? Have I missed a configuration step? Thanks.

6d21h: setting bridge id (which=3) prio 8214 prio cfg 8192 sysid 22 (on) id 2016.0023.0540.xxxx

6d21h: RSTP(22): initializing port Gi1/0/5

6d21h: RSTP(22): Gi1/0/5 is now designated

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/5, changed state to up

6d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/5, changed state to up

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): Gi1/0/5 fdwhile Expired

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): transmitting a proposal on Gi1/0/5

6d21h: RSTP(22): Gi1/0/5 fdwhile Expired

6d21h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan22, changed state to up

2 Accepted Solutions

Accepted Solutions

RSTP will be a lot faster than 802.1d, way quicker then 35 seconds. In fact according to Cisco design docs you can get it down to milliseconds.

But one of the key things with RSTP is the port type and portfast is very important in this. RSTP needs to know that you have connected an edge device and portfast is how you tell it this.

See this link for a detailed explanation of RSTP if you haven't already seen it -

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

Jon

View solution in original post

Exactly, unless you tell RSTP with portfast then it cannot make any assumptions about that port.

The real test is on a link between switches - 802.1d will be about 45 seconds, RSTP will be about 3 seconds without any tuning.

One other thing. You need to make sure that all switches run RSTP. So if you have 3 switches all with the same vlans but only 2 run RSTP and the other 802.1d then RSTP will have to fall back to 802.1d timers.

Jon

View solution in original post

7 Replies 7

Jon Marshall
Hall of Fame
Hall of Fame

If it is a host you should turn on portfast and then it will move to forwarding immediately

interface GigabitEthernet1/0/1

spanning-tree portfast

Jon

That's a good point. I'm aware of portfast. But my hope for RSTP was that it would work fast enough to not need to use portfast. I think at 35 seconds it is somewhat faster than 802.1d. I'll run a test with good old 802.1d for comparision.

RSTP will be a lot faster than 802.1d, way quicker then 35 seconds. In fact according to Cisco design docs you can get it down to milliseconds.

But one of the key things with RSTP is the port type and portfast is very important in this. RSTP needs to know that you have connected an edge device and portfast is how you tell it this.

See this link for a detailed explanation of RSTP if you haven't already seen it -

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

Jon

Ahh - ok. So the edge port role has to be defined rather than discovered it sounds like.

Edge Ports

The edge port concept is already well known to Cisco spanning tree users, as it basically corresponds to the PortFast feature. All ports directly connected to end stations cannot create bridging loops in the network. Therefore, the edge port directly transitions to the forwarding state, and skips the listening and learning stages. Neither edge ports or PortFast enabled ports generate topology changes when the link toggles. Unlike PortFast, an edge port that receives a BPDU immediately loses edge port status and becomes a normal spanning tree port. At this point, there is a user-configured value and an operational value for the edge port state. The Cisco implementation maintains that the PortFast keyword be used for edge port configuration. This makes the transition to RSTP simpler.

Exactly, unless you tell RSTP with portfast then it cannot make any assumptions about that port.

The real test is on a link between switches - 802.1d will be about 45 seconds, RSTP will be about 3 seconds without any tuning.

One other thing. You need to make sure that all switches run RSTP. So if you have 3 switches all with the same vlans but only 2 run RSTP and the other 802.1d then RSTP will have to fall back to 802.1d timers.

Jon

AND THE WINNER IS...802.1D! It was just by a nose but in my test - removing RSTP in favor of good ol' 802.1D (no portfast either case). With RSTP the port was fully functional in 32 seconds 802.1D 29 seconds.

I'm shocked, dismayed - oh the humanity!

6d22h: setting bridge id (which=3) prio 8214 prio cfg 8192 sysid 22 (on) id 2016.0023.0540.xxxx

6d22h: set portid: VLAN0022 Gi1/0/12: new port id 800C

6d22h: STP: VLAN0022 Gi1/0/12 -> listening

6d22h: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/12, changed state to up

6d22h: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/12, changed state to up

6d22h: STP: VLAN0022 Gi1/0/12 -> learning

6d22h: STP: VLAN0022 Gi1/0/12 -> forwarding

6d22h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan22, changed state to up

So have you fix this issue yet  ?

what's your final configuration . I had same issues like your one .

Thanks

Justin

Review Cisco Networking products for a $25 gift card