%SPANTREE-2-LOOPGUARD_BLOCK on copper

[neteng_ams]

[SW1]G1/1----------------G1/0/1[SW2]

I have two switches trunked with a cat5e cable. I am seeing loopguard blocking on SW2 every few minutes which is interrupting user connections because the port goes into inconsistent state for a few seconds. It seems to affect all VLANs. SW1 is root and never shows anything out of the ordinary and downstream ports appear as designated. I need to schedule maintenance window to replace the cable, but Cisco doc says "Copper ports are normally not susceptible to this type of issue, as they use Ethernet link pulses to monitor the link." What are other possible causes?

%SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/1 on VLAN0995.
%SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/1 on VLAN0992.
%SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/1 on VLAN0992.
%SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/1 on VLAN0999.
%SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/1 on VLAN0995.
%SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/1 on VLAN0999.
%SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/1 on VLAN0415.
%SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/1 on VLAN0412.
%SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/1 on VLAN0409.
%SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/1 on VLAN0420.

[Reza Sharifi]

What happens when you delete the looguard config from sw2?

[neteng_ams]

Edit: spoke too soon, I still lose connectivity briefly but without the loopguard errors in the log. The spanning tree convergence for different VLANS:

  Number of topology changes 48339 last change occurred 00:00:08 ago
  Number of topology changes 48915 last change occurred 00:15:31 ago
  Number of topology changes 49799 last change occurred 00:15:44 ago
  Number of topology changes 50440 last change occurred 00:15:40 ago
  Number of topology changes 51611 last change occurred 00:15:27 ago
  Number of topology changes 109829 last change occurred 00:15:33 ago
  Number of topology changes 52248 last change occurred 00:13:56 ago
  Number of topology changes 54287 last change occurred 00:13:56 ago
  Number of topology changes 55410 last change occurred 00:13:34 ago
  Number of topology changes 56794 last change occurred 00:00:06 ago
  Number of topology changes 58062 last change occurred 00:00:06 ago
  Number of topology changes 59338 last change occurred 00:13:53 ago
  Number of topology changes 60348 last change occurred 00:13:36 ago
  Number of topology changes 61195 last change occurred 00:13:45 ago
  Number of topology changes 62291 last change occurred 00:13:33 ago

[Rolf Fischer]

This are really huge numbers of topology changes. You should determine where they are comming from:

show spanning-tree detail | include exec|occur|from

Could you elaborate a bit on what your bridge domain looks like: How many switches, all Cisco or third-party as well, topology, what spanning-tree version(s), how many VLANs, VTP mode, Port-Cannels (mode?) etc.

What about the recommended STP-stabilisation features like

• portfast on edge-ports
• bpduguard on edge-ports
• UDLD on fiber-links?

Best regards

Rolf

[neteng_ams]

Diagram of this portion of bridge domain attached. About 170 VLANs in domainX, transparent portion in domainY has limited subset of about 10 VLANs. I've heard of problems if transparent VTP bridges are between two server/clients, but it doesn't seem to be the case here.

Also noticed similar loopguard errors reported on SW4 for its uplink to SW3.

SW2 config: bpduguard and bpdufilter on the access ports, no portfast

Topology changes from the upstream towards core:

 VLAN0400 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 106410 last change occurred 00:05:19 ago
          from GigabitEthernet1/0/1
 VLAN0401 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 108931 last change occurred 00:05:19 ago
          from GigabitEthernet1/0/1
 VLAN0403 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 118702 last change occurred 00:03:41 ago
          from GigabitEthernet1/0/1
 VLAN0405 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 119593 last change occurred 00:03:41 ago
          from GigabitEthernet1/0/1
 VLAN0406 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 120896 last change occurred 00:03:41 ago
          from GigabitEthernet1/0/1
 VLAN0407 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 120785 last change occurred 00:03:41 ago
          from GigabitEthernet1/0/1
 VLAN0408 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 122154 last change occurred 00:04:46 ago
          from GigabitEthernet1/0/1
 VLAN0409 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 122913 last change occurred 00:04:46 ago
          from GigabitEthernet1/0/1
 VLAN0410 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 124544 last change occurred 00:03:41 ago
          from GigabitEthernet1/0/1
 VLAN0411 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 124860 last change occurred 00:03:45 ago
          from GigabitEthernet1/0/1
 VLAN0412 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 125240 last change occurred 00:04:46 ago
          from GigabitEthernet1/0/1
 VLAN0413 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 126023 last change occurred 00:04:46 ago
          from GigabitEthernet1/0/1
 VLAN0414 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 126853 last change occurred 00:03:41 ago
          from GigabitEthernet1/0/1
 VLAN0415 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 127880 last change occurred 00:03:29 ago
          from GigabitEthernet1/0/1
 VLAN0416 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 128241 last change occurred 00:03:29 ago
          from GigabitEthernet1/0/1
 VLAN0417 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 129324 last change occurred 00:03:53 ago
          from GigabitEthernet1/0/1
 VLAN0418 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 130164 last change occurred 00:03:29 ago
          from GigabitEthernet1/0/1
 VLAN0419 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 131662 last change occurred 00:03:29 ago
          from GigabitEthernet1/0/1
 VLAN0420 is executing the rstp compatible Spanning Tree protocol
  Number of topology changes 131534 last change occurred 00:03:15 ago
          from GigabitEthernet1/0/1

[Jon Marshall]

You need to enable portfast on all your ports that connect to end devices as Rolf suggested -

"spanning-tree portfast"

If you don't then every time a client device reboots for examples or you simply disconnect then connect it generates an STP TCN which is why you are seeing so many STP topology changes.

You enable portfast on all ports connecting to PCs/laptops/printers/server/routers/firewalls ie. not other switches.

If you are connecting to a router with a switch module and you connect to a port on the switch module don't enable it.

Also if you have servers, for example, that are trunking then use -

"spanning-tree portfast trunk"

The one place you definitely don't apply either version of the command is switch to switch interconnections.

Jon

[Rolf Fischer]

I can only reemphasize what Jon stated about portfast. 

Some additional thoughts:

You have about 170 VLANs in domainX, remember that 2k/3k Catalyst platforms support only 128 spanning-tree instances, some legacy platforms even only 64. I suppose you manually prune VLANs by allow-list on inter-switch-trunks of (especially) VTP clients and server?

You have a mix of Rapid-(PV)STP and PVSTP. Aside from convergence, there are some differences, e.g. what events trigger a topology change and how TC are handled. I guess some of your switches do not support Rapid-STP?

STP topology changes are not a bad thing, they simply inform all switches about a change so that they can flush their CAM-tables in order to re-learn the appropriate ports to forward frames to non-directly connected devices. But, like Jon already mentioned, you don't want this to happend each time an edge-device is conneced or disconneced.

I'm not jet sure what caused the loopguard error / loss of connectivity. Loopguard sets a non-designated port in an inconsistent state when it stops receiving BPDUs. Several posible reasons for that, so I'd start with some STP stability imporvements.

HTH

Rolf

[neteng_ams]

I have changed spanning tree mode to rapid-pvst for all switches and spanning tree portfast for ports connecting to end devices, but I am still seeing the same problem. SW1 is a Cat 6500 and so it should be able to handle the numebr of spanning tree instances. SW2 is a 2960S and "show spanning-tree" shows 128 VLANs while SW1 shows 170, so you may be right that it's maxed out. Would it cause the problems I'm experiencing?

In "show interface trunk" most VLANs are in forwarding state and not pruned even though I only need about 10 of those VLANs in this portion of the network. Should I perform manual pruning on the trunk link of SW1 to SW2 using "switchport trunk allowed vlan xxx" or should I issue "no spanning tree vlan xxx" for each VLAN that's not needed in this portion of the network?

[Jon Marshall · Accepted solution]

Limit the vlans to only those that are needed on the trunk links using the "switchport trunk allowed vlan ..." command as you say.

Make sure the allowed list matches on both ends of the trunk link.

Then delete the vlans you don't need on the switches.

Doing the above will mean that if a switch does not have that vlan it won't need to run an STP instance for it.

Don't disable STP for the vlans as you are already experiencing issues and that really won't help.

Jon