changing rstp pathcost from short to long

[geo555]

Hello,

we want to change the RSTP pathcost method from short to long

1. Should we expect any downtime?

2. Do we have to change first the root switch or the order doesn't matter?

Thanks,

George

[Julio E. Moisa]

Hi

You could have a little downtime, remember you are manipulating the flow, there are 2 ways to manipulate the traffic, configuring lowest cost on the root ports or configuring lowest priority value on the designated ports. 

Root port: represents the port (the best way) going from the non root switches to the root bridge.

Designated port: represents the port (the best way) from the root bridge to the non root switches. 

If you are going to begin from the root bridge you have to change the priority value. Now if you want to change the pathcost for a specific switch I recommend use cost value. My suggestion is do that after business hours and with an authorized maintenance window. 

Hope it is useful

:-)

[geo555]

Hi Julio and thanks for your reply.

We do not want to set any values manually.

Just change the spanning-tree pathcost method to long on all switches

and let the switch auto-configure the new costs.

do you think it's better to start from the access layer?

[Julio E. Moisa · Accepted solution]

Hi

Got it, if you are going to use 32 bits method, I suggest begin from the root bridge to the non root switches. As I remember it should not generate any impact because 16 bits method uses only 2 of 4 bytes so you will enable the other 2 bytes to have 4 bytes working, just remember all the switches must run this kind of method and the long method will run over Rapid PVST+.

Always do that after business hours. 

:-)

[Jeroen Huysmans]

Hi Julio,

I was actually performing the same changes without reading this post...

Although I initially planned to start from the root towards the edge switches I did change the approach.

The network is pretty basic:

- 1 root 6500 + 1 6500 which could become root (higher STP prio than active root but lower than default)

- Both 6500 are interconnected by a L2 link

- The edge is connected to both 6500's, 1 port is blocking.

I was not expecting any STP changes, but almost every time I changed the pathcost method on an edge switch I did notice TCN logging (we send snmp traps on TCN events).

I don't really understand why this would trigger a TCN...

A TCN should be generated:

When a port that was forwarding is going down (blocking for instance).

When a port transitions to forwarding and the bridge has a designated port. (This means that the bridge is not standalone.)

Now why would changing the pathcost suggest such a change?

Unfortunately I did not have the time to investigate any further...

On a given edge switch I checked the interface state on the edge switch (Root port, blocking port and cost).

After the change, the interface state was exactly the same (same root port, same blocking port but obviously the cost had increased).

any idea/suggestions?

regards,

Jeroen

[Jeroen Huysmans]

Hi Julio,

I was able to execute this change in a lab environment.

Setup was pretty basic: 1 edge switch (3750x) connected to 2x N7k's through vPC.

So very basic, only 1 interface (Po40) pointing to the root (N7k's).

LAB-TOR01(config)#spanning-tree pathcost method long
LAB-TOR01(config)#
Dec  4 2017 14:48:39.502: RSTP(20): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: %SPANTREE-5-ROOTCHANGE: Root Changed for vlan 20: New Root Port is Port-channel40. New Root Mac Address is 0023.04ee.bed6
Dec  4 2017 14:48:39.502: RSTP(21): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: RSTP(1420): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: RSTP(404): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: RSTP(444): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: RSTP(22): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: RSTP(30): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: RSTP(520): updt roles, non-tracked event
Dec  4 2017 14:48:39.502: RSTP(1500): updt roles, non-tracked event

it's funny the output mentions only a rootchange for vlan 20...

however, no TCN... I'm pretty sure I've seen the logging referring to TCN while changing the pathcost method in the production network (which is not vPC based, it's running on 6500's in core and 3750x on edge side).

Jeroen