Re: Loopguard Issue

ChristopherCraddock66504 · ‎01-04-2022

Dear Community,

We have been experiencing an issue where every once in a while our core stack will place a couple of VLANs into Loop Inconsistent state. This of course kills the phones and the data for our users. The issue is I cant seem to figure out why this is happening. What would cause a Designated port to go into loop inconsistent state? I thought loop guard was only for Blocking ports that are trying to go into forwarding when they stop receiving BPDU's. I have attached the topology diagram for the network this is occurring on. Is something bridging the 2 Meraki stacks together, causing a loop? At first I was thinking maybe a VoIP phone might be connected to both stacks, but I am not sure.

What would cause a designated port to go into Loop Inconsistent State?

Stack A: Meraki MS350 switch stack. Switch A1 Port 52 and Switch A5 Port 52 make up Po7

Stack B: Meraki MS350 switch stack. Switch B1 Port 52 and Switch B5 Port 52 make up Po6

Core Stack: Catalyst 3850 Stack

Vlan 1041: Data

Vlan 1051: Voice

Core3850#show spanning-tree int po7

Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0001 Desg FWD 1 128.2321 P2p
VLAN0007 Desg FWD 1 128.2321 P2p
VLAN0025 Desg FWD 1 128.2321 P2p
VLAN0666 Desg FWD 1 128.2321 P2p
VLAN1041 Desg BKN*1 128.2321 P2p *LOOP_Inc
VLAN1043 Desg FWD 1 128.2321 P2p
VLAN1044 Desg FWD 1 128.2321 P2p
VLAN1045 Desg FWD 1 128.2321 P2p
VLAN1051 Desg BKN*1 128.2321 P2p *LOOP_Inc
VLAN2224 Desg FWD 1 128.2321 P2p
Core3850#

Logs from Core:

Jan 3 14:04:47.087 EST: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Port-channel7 on VLAN1041.
Jan 3 14:21:01.229 EST: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port Port-channel7 on VLAN1041.
Jan 3 14:21:21.814 EST: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Port-channel7 on VLAN1051.
Jan 3 14:21:23.226 EST: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Port-channel7 on VLAN1041.

Reza Sharifi · ‎01-04-2022

Hi,

Do the interfaces on the 3850 show any error messages or they are clean? For testing, what happens if you shut down one of the links in each PO?

Here is a link with a similar issue but no PO.

https://community.cisco.com/t5/switching/loop-inconsistent/td-p/2807677

HTH

ChristopherCraddock66504 · ‎01-04-2022

Reza,

Core3850#show int te1/1/1
TenGigabitEthernet1/1/1 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 94d4.694a.9fb5 (bia 94d4.694a.9fb5)
Description: Meraki Uplink to NPT-SW-A1 Port 52
MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 10Gb/s, link type is auto, media type is SFP-10GBase-SR
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 633000 bits/sec, 327 packets/sec
5 minute output rate 3490000 bits/sec, 489 packets/sec
3774323093 packets input, 1376628993983 bytes, 0 no buffer
Received 52125850 broadcasts (19762606 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 19762606 multicast, 0 pause input
0 input packets with dribble condition detected
5982060257 packets output, 5553624821557 bytes, 0 underruns
0 output errors, 0 collisions, 100 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

Core3850#show int te2/1/1
TenGigabitEthernet2/1/1 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 94d4.694a.a135 (bia 94d4.694a.a135)
Description: Meraki Uplink to NPT-SW-A5 Port 52
MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 10Gb/s, link type is auto, media type is SFP-10GBase-SR
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 125836377
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1010000 bits/sec, 545 packets/sec
5 minute output rate 1732000 bits/sec, 421 packets/sec
7862462888 packets input, 2956042514958 bytes, 0 no buffer
Received 87445876 broadcasts (44239469 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 44239469 multicast, 0 pause input
0 input packets with dribble condition detected
17384819754 packets output, 16403049040016 bytes, 0 underruns
125836377 output errors, 0 collisions, 94 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

Core3850#show int po7
Port-channel7 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 94d4.694a.a135 (bia 94d4.694a.a135)
MTU 1500 bytes, BW 20000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 10Gb/s, link type is auto, media type is
input flow-control is off, output flow-control is unsupported
Members in this channel: Te1/1/1 Te2/1/1
ARP type: ARPA, ARP Timeout 04:00:00
Last input 18:48:43, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1667000 bits/sec, 879 packets/sec
5 minute output rate 5187000 bits/sec, 911 packets/sec
11636807807 packets input, 4332678042188 bytes, 0 no buffer
Received 139571873 broadcasts (64002115 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 64002115 multicast, 0 pause input
0 input packets with dribble condition detected
23366907261 packets output, 21956690928495 bytes, 0 underruns
125836377 output errors, 0 collisions, 97 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

So far things look clean here. We have not tried shutting down one of the links in the port channel. May I ask what the line of reasoning is for doing that?

I for the life of me cant understand how a Designated port that is in forwarding can trigger loop guard. Im no expert, but everything I've ever seen or read about loopguard is that it is only invoked when a blocking port tries to go to forwarding after not receiving BPDU's. I cant think of a way it would be triggered on a port that is already forwarding. Is it possible that the port channel is going into blocking for the affected VLANs first and then when the BPDU loop goes away it triggers loopguard?

The core switch is configured with the spanning-tree loopguard default command.

Thanks for your help.

Reza Sharifi · ‎01-04-2022

0 output errors, 0 collisions, 100 interface resets (1/1/1)

125836377 output errors, 0 collisions, 94 interface resets (2/1/1)

125836377 output errors, 0 collisions, 97 interface resets (PO)

Seems as Interface te2/1/1 may be the issue here. I think if you shut it down for a period of time for testing, it would be helpful in troubleshooting the issue.

HTH

ChristopherCraddock66504 · ‎01-04-2022

Reza,

Thank you for the feedback. Do you think the interface resets may be contributing to the issue by causing transitory loops?

Thank you.

Reza Sharifi · ‎01-04-2022

Do you think the interface resets may be contributing to the issue by causing transitory loops?

I think so. Even though this is PO and should not matter if one interface goes down but that interface may be a contributing factor.

Can you make sure that the core 3850 stack is the root bridge for all VLANs?

HTH

balaji.bandi · ‎01-04-2022

Meraki holding only 2 VLAN ? 1041 and 1051 ?

can you share the configuration of physical interface config and also port-channel config (both meraki and 3850)

i would suggested Root bridge to be Cisco 3850 and test it.

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

ChristopherCraddock66504 · ‎01-04-2022

Balaji,

!
interface TenGigabitEthernet1/1/1
description Meraki Uplink to NPT-SW-A1 Port 52
switchport mode trunk
channel-group 7 mode active
end
!
interface TenGigabitEthernet2/1/1
description Meraki Uplink to NPT-SW-A5 Port 52
switchport mode trunk
channel-group 7 mode active
end

!

interface Port-channel7
switchport mode trunk

The 3850 itself is not the RB; however, its Uplink to the Meraki switches are in the Designated role and the uplinks from the Meraki to the 3850 are in the Root role.