Trunking Loopguard block issues but only if across Ubiquiti RF links

[MARK CHRISTY]

This one has puzzled me and others for some time. It's not a show stopper in that it doesn't break the network (for long). I'll have to explain some topology here to differentiate clearly from where it does occurr, and where it does not occurr. See the attachment for the topology diagram.

Here's what happens. We have a VSS core and are using active VTP. The 2960 switches are all trunked to the VSS core. They are all trunked the same, with the same simple config as follows (including the Switch-1 to Switch-2 link via the M1-S1 Ubiquiti RF system).

Interface Gi1/0/XX

  switchport mode trunk

  switchport trunk native vlan 999

  switchport nonegotiate

  switchport trunk allowed vlan 5,10

Note: The allowed statement above is not shown in the topology picture but is there to limit the number of times this happens to just two vlans

On any "Other Cisco 2960S" switches, I never, ever see this occurr. However - across the Ubiquiti RF M1-S1 link, on Switch 2, the following occurs with regularity. It will occurr on any and every VLAN allowed across the trunk. Only on the Switch-2. Switch-2 has a single host connected to port 10 (on Vlan10). Vlan 5 is the management vlan. Those are the only two vlans allowed to cross the link.

Switch 2# show logging

!

006585: Nov 15 15:25:33 PST: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port GigabitEthernet1/0/48 on VLAN0005.

006586: Nov 15 15:25:33 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan5, changed state to down

006587: Nov 15 15:25:33 PST: %SPANTREE-2-LOOPGUARD_UNBLOCK: Loop guard unblocking port GigabitEthernet1/0/48 on VLAN0005.

006588: Nov 15 15:25:33 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan5, changed state to up  

!

The same thing will occur for VLAN10

Show trunk (on interface used in links):

Switch (1 or 2)

#show int gi1/0/48 trunk

Port        Mode             Encapsulation  Status        Native vlan
Gi1/0/48    on               802.1q         trunking      999

Port        Vlans allowed on trunk
Gi1/0/48    5,10

Port        Vlans allowed and active in management domain
Gi1/0/48    5,10

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/48    5,10

I have tried every thing I can think of to stop this behavior, to no avail... I hope someone has seen a fix for this as it does cause very short network interuptions...

Thanks

[Rolf Fischer · Accepted solution]

Hi Mark,

according to the attached topology, Switch2 doesn't have any physical redundancy, is that correct?

So the uplink Gi1/0/48 should normally be the root port.

Loopguard prevents non-designated ports (root ports, alternate ports and backup ports) from becoming designated.

In the case of Switch2 we can assume that it didn't receive BPDUs from the root bridge for 20 seconds (Max Age) until loopguard finally moves it into the inconsistent blocking state, in other words: It missed 10 consecutive BPDUs.

I suspect that this is related to RF system, perhaps it doesn't transmit BPDUs when congestion occures or there are outages in the radio connection?

It wouldnt solve the cause, but of course you could disable loopguard when there are no physical loops, in the absence of BPDUs the Switch then would declare itself to the root bridge until it receives better information.

HTH

Rolf

[MARK CHRISTY]

SW-2 in the topology doesn't have any redundant links. Because we are using VSS and VTP throughout, we only want redundancy that can be supplied by etherchannel links, as opposed to spanning tree topologies (current Cisco want). It is working without problems on other switches.

On SW-2, I installed the command: "no spanning-tree vlan 5,10,16"

This has stopped the errors being seen. What I am trying to understand is I see this error only when the link is RF, not cat5? That's got me spinning.

Simple reasoning says that the RF link is doing something evil like transmitting a BPDU into the virtual world of the trunk, or there is a loop on the far end (there isn't because turning off spanning tree on that side as above worked).

I'm going to let that cook for a while as in some instances it takes 10-20 minutes for the blocking to occur on the SW-2. It looks to me like the way to stop it. Once I'm sure of that - there is one more wonderful problem that I'll start a discussion on.

Thanks - any more ideas just yell!

[uvu3nvy]

We're having the same issue across our Ubiquiti RF links and Cisco switches.

Did you ever find the problem?