Nexus 7K vPC + spanning-tree topology changes

[m.o.andersson_2]

Hi everyone,

hoping to get some help regarding an issue that for me is very strange. I can't seem to wrap my head around it... Ill start describe the enviroment.

We currently run two Nexus 7706 as a collapsed core/dist where we connect access switches for Datacenter and Client-network through vPC. Everything works great, no issue reported from customers or other departments and no errors found in either vPC configuration or spanning-tree design, all best practice from Cisco. 

So, what is the problem? I noticed alot of "topology changes" on the secondary root-bridge. When i run the command: "show spanning-tree detail" i get on about 20 vlans ALOT of topology changes and the timer seem to only hit 30-40 sec before a new change occur. So this is still ok i think in a big enviroment, changes occur often or that a portfast port is misconfigured for a client. BUT this is when i get confused, because all changes seem to come from interface Po1 which is connected to the other Nexus 7K which is the root-bridge. There is no topology changes, at all, on those vlans that are frequently changing on the secondary root-bridge. How come this is? Am i missing something or do i simply not understand STP? :) Is there a guideline how many topology changes are acceptable in an network?

If anyone have any idea what this might be or just calm me down and say this is normal i would be thankful. I can provide config and command output if needed.

Cheers!

[scott.samra]

Do you have your VLAN priority configured on each Nexus?  

Can you attach the output from "show spanning-tree summary" and "show spanning-tree detail | inc topology"

[m.o.andersson_2]

Yes i have set the priority correct. In the output attached you will see that the root-bridge is ok, the secondary-root is getting topology updates all the time on various vlans. För example on vlan 11 from command "show spanning-tree-detail":

Root-bridge:

 VLAN0011 is executing the rstp compatible Spanning Tree protocol
  Bridge Identifier has priority 0, sysid 11, address 002a.6a5c.5a41
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag not set, detected flag not set
  Number of topology changes 40 last change occurred 356:48:55 ago
          from port-channel1
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 0, notification 0

Secondary root-bridge:

 VLAN0011 is executing the rstp compatible Spanning Tree protocol
  Bridge Identifier has priority 4096, sysid 11, address 002a.6a5c.49c1
  Configured hello time 2, max age 20, forward delay 15
  Current root has priority 11, address 002a.6a5c.5a41
  Root port is 4096 (port-channel1), cost of root path is 1
  Topology change flag set, detected flag not set
  Number of topology changes 35702 last change occurred 0:00:20 ago
          from port-channel1
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15
  Timers: hello 0, topology change 13, notification 0

Notice also that the latest update came from interface Po1 from both routers, which is the vPC peer link interface. So this is where im totally lost... Im unable to trace what is causing the topology changes and it does not make sense that the secondary root-bridge gets 30K updates, while the root-bridge have a total of 40?

[m.o.andersson_2]

Actually, i think i found a bug!

Resolved Caveats—Cisco NX-OS Release 6.2(6b)

• CSCuo80937

Symptom : Spanning-Tree Protocol (STP) TC Bridge protocol Data Units (BPDUs) are sent every 2 seconds for a long period of time after approximately 100 days of active supervisor uptime.

Conditions : You might see this symptom if there are topology changes (TCs) after you upgrade to Cisco NX-OS Release 6.2(6), 6.2(6a) or 6.2(8) on your Cisco Nexus 7000 or 7700 Series switches.

Workaround : This issue is resolved. In order to circumvent this issue until an upgrade to 6.2(8a) can be performed, execute the appropriate workaround, depending on whether you have a dual-supervisor or single-supervisor configuration, before each 90 days of uptime.

Use to show system uptime command to display the number of running days for the active supervisor.

Switch# show system uptime

System start time: Fri Oct 25 09:40:58 2013

System uptime: 236 days, 8 hours, 56 minutes, 59 seconds

Kernel uptime: 110 days, 23 hours, 7 minutes, 49 seconds

Active supervisor uptime: 110 days, 23 hours, 2 minutes, 23 seconds

For a dual-supervisor configuration:

1. Reload the standby supervisor.

2. Use the show module command to confirm that the standby supervisor is up and in the HA-standby mode.

3. Use the system switchover command to switch to the standby supervisor.

For a single-supervisor configuration:

1. Upgrade to Cisco NX-OS 6.2(6b).

2. Reload the switch.

[sshamsi78]

it should be applied to both Nexus switches
 

[Boyan Sotirov]

That's cool. Thank you Mattias, this has just solved my problem :) Kudos for that!