switch loop

I have enabled spanning-tree bpduguard on the Cisco 2960 but it seems like the unmanaged switch does not have spanning tree protocol. Any other configuration to prevent loop?

2 Answers 2


Spanning-tree is the protocol designed to detect and prevent loops. bpduguard is intended for access ports -- ports connected to end users/machines (a single node.) A port configured for bpduguard gets disabled upon receiving a bpdu -- any bpdu.[1][2] As such, enabling this feature on a port headed to a simple switch (aka "hub") is asking for trouble, the instant anyone connected to that "hub" sends a bpdu, the 2960 will disable the port leading to it -- cutting off the "hub" and everything connected to it.

The best option is to simply let spanning-tree on the 2960 work like normal. If you want the port to pass traffic immediately on link -- thus bypassing the normal stp discovery phase -- enable portfast. But otherwise, leave bpduguard off.

[1] https://supportforums.cisco.com/document/45136/importance-bpdu-guard-and-bpdu-filter
[2] http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10586-65.html

  • Yes, I expect that devices connected to the 2960 switch are all end devices, not switch. But I found someone plugged unmanaged switch to the 2960 switch. Of course no problem because all ports have default VLAN. That is why I have enabled the bpduguard.
    – Ron Vince
    Jan 22, 2015 at 5:00
  • 1
    bpduguard should err-disable one of those ports because the 2960 will see its own bpdu. Jan 22, 2015 at 5:11
  • Did you read those links? bpduguard is not "loop prevention"; the purpose is to safeguard one's spanning-tree topology from a rogue switch being introduced on the network: "by shutting the port down we prevent the rogue switch from affecting our spanning-tree topology"
    – Ricky
    Jan 22, 2015 at 7:59
  • And a L2 bridge that is BPDU-transparent acts as a rogue switch, which is why even if you turn on bpdufilter (not bpduguard) globally interfaces still emit 3 BPDU's.
    – cpt_fink
    Jan 23, 2015 at 2:57

To start, take note that BPDU Guard (and BPDU Filter) are only in effect on ports that also have portfast enabled if enabled globally. If portfast is not enabled, BPDU Guard will have no effect unless applied directly to the port.

In my experience, non-managed switches come in two flavors with regards to BPDUs.

  1. Switches that produce, relay, or forward BPDUs normally.
  2. Switches that drop or fail to relay BPDUs.

In the first case, BPDU guard will disable the port the instant it sees a spanning-tree BPDU, even if that BPDU isn't its own (thus a loop.) As drawn, BPDU guard will disable both ports since the 2960 will send a BPDU out both ports which will be reflected by the unmanaged switch into the opposite port.

In the second case, if the switch is not participating in STP itself, this will result in a L2 loop. Depending on your environment, there are a number of ways to mitigate a loop in this situation. Feel free to mix and match as you like.

  1. Storm Control - make sure you understand this feature before enabling as when misconfigured it can cause normal traffic to be dropped erroneously. This typically takes place in hardware and uses thresholds for multicast, broadcast, and unicast traffic to suppress traffic when it exceeds the threshold.
  2. Port Security - set a reasonable maximum value for the number of MAC addresses per port. Typically a loop will result in traffic for many hosts to be carried over the link resulting in the configured violation mode to take effect.
  3. DHCP Snooping - setting a appropriate DHCP snooping rate limit on the port will cause the port to err-disable if that limit is exceeded. This typically can be very low for an access port, although be warned that some features of security software can generate excess DHCP traffic (for example, at least one major security software vendor has a feature that allows it to "scan" the local network to look for compromised hosts).

There are other loop protection methods as well, such as loop guard, but these are the ones that I can think of that could help in the situation you describe.

  • bpduguard applies to any port where it is configured. portfast or not. There's a global config that switches it on for all portfast interfaces. (my 2960s) sw-R2-1(config-if)#spanning-tree ? -> bpduguard Don't accept BPDUs on this interface
    – Ricky
    Jan 22, 2015 at 8:02
  • bpduguard is not a "loop preventer". STP alone will do that. This feature kills the port if any bpdu is seen, not just the switch's own bpdu's.
    – Ricky
    Jan 22, 2015 at 8:07
  • Also, bdpuguard errdisables the interface, which requires administrative action (or configuration: errdisable recovery) to re-enable. (or an unplug-plug event) STP blocking will automatically transition to forwarding when it stops seeing its own bpdus. (i.e. the loop is broken.)
    – Ricky
    Jan 22, 2015 at 8:41
  • You are correct, when bpduguard is applied to the port directly it will apply whether portfast is enabled or not (bpdufilter will not and I had them lumped together in my mind). You are also correct that bpduguard is not a "loop preventer" and neither are any of the solutions I provided. While ideally STP would prevent all L2 loops, STP fails, bugs, or devices that don't adhere to the standards allow the introduction of L2 loops. In some of these cases, bpduguard can help to mitigate the effects of the loop on the network...
    – YLearn
    Jan 22, 2015 at 22:20
  • ...In addition, it also prevents unauthorized devices from participating in the authorized network's STP and prevents any problems that such an unauthorized device can introduce to the spanning tree domain.
    – YLearn
    Jan 22, 2015 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.