The tl;dr, in which scenario (switch-to-host, or switch-to-switch) do I use spanning-tree portfast or spanning-tree ...?

We had a catastrophic network outage today. My first question to my boss was "did someone plug a switch into another switch?". She wasn't aware of anyone doing that.

Some users moved their own equipment today though. More on that later.

My core switch is a Cisco 4507. Child devices from there are 3560s (Gb), 3550s (100 Mb), a couple 3524s, and some SG300s. The only redundant links are Etherchannels from the 4507 to four of the 3560s. All other links aren't redundant. There are no "grandchild" switches; all of the 35xx/SG300 switches connect directly to the 4507.

I noticed the 48 port Ethernet blade in the 4507 had a blinking amber LED. show module all reported it as faulty. I had a spare. I swapped it in and the 4507 showed it being okay. This didn't fix the outage.

We have four primary VLANs organized mostly by dept or job function. I noticed if I shut down two of the VLANs the pings from the 4507 to a directly connected 3560 went from nearly 2000ms (2s) (when it was successful), down to 5/5 (0% loss) double and three digit milliseconds min/avg/max. Not where it's supposed to be, but better than it was.

I ran show logging and saw variations on this message

%C4K_EBM-4-HOSTFLAPPING: Host 11:22:33:44:55:66 in vlan 10 is flapping between port Gi4/17 and port Gi4/22.

Most of the flapping was between the switches on Gi4/17 and Gi4/22. Flapping sounded like a loop to me. The older of the two devices - the one on Gi4/17 (we'll call it 17) - was powered down and nearly immediately network activity returned to normal. I had regular BMs (hehe, Bandwidth Measurements) and ping times were close to 4/4/4 min/avg/max.

We left the older switch powered down for the rest of the evening so production could finish. We powered on 17 with the uplink disconnected and then shut down (via console) all but the uplink interface. I connected the uplink, then I brought up Fa0/1 - Fa0/24 in groups of six with int range FastEthernet 0/x - y. There were no flapping errors reported though on the 4507.

My hypothesis is that whichever user(s) moved their own equipment today connected 17 and 61 by way of a patch cable at the RJ45 connections throughout the one depart. Further more, that department is largely vacated by 5pm, and some machines are shut down, and others (laptops) are taken home.

The hardware support vendor who dropped off the on-site spare replacement of the 48 port RJ45 blade asked about spanning-tree being enabled on the switches. I said most ints don't have it, but after checking 17, all the ints have spanning-tree portfast enabled. As stated, there are no grandchild switches from the 4507, so there are no switch-to-switch connections after the 4507. I read that using spanning-tree portfast can cause loops if misconfigured and someone un/knowingly creates a loop by connecting two ports.

Since there aren't any switch-to-switch connections after the 4507, do I need spanning-tree or spanning-tree portfast on the ints that connect workkstations or ip phones?

  • 1
    You could utilize the global command spanning-tree loopguard default in order to detect loops and let spanning-tree take action accordingly. If you want links to be reopened after it's been put into error disable state by loopguard you can use the command errdisable recovery cause all and errdisable recovery interval <seconds>. Everything will be logged so you can see which links are causing the problem. Also, if your 4507 is the primary root for all VLANs, you should use spanning-tree guard root on all uplinks and make sure VLANs are set with low priority.
    – user36472
    Dec 22, 2017 at 7:51

1 Answer 1


Spanning tree only runs between switches, never to standard end hosts.

Bear in mind that, under normal circumstances, a port supporting spanning tree will (when it first comes up) run through a sequence of first listening for BPDU's, then learning source addresses and then finally forwarding frames. This can take ~30 seconds, during which the connected device won't be passing traffic. If, for example, you've got an end host like a server or PC connected then this may cause a problem as the OS could boot and then fail to pull a DHCP address because the port isn't yet functional.

This is where portfast comes in. Enabling the portfast feature basically means that the port will skip listening for BPDU's and immediately begin forwarding. The win here is that we have immediate network connectivity. This fixes the end-host problem pretty neatly. The downside is that if you happen to have portfast turned on an inter-switch link that you could begin flooding traffic that creates a transitory loop (..which would likely destabilize the larger network).

It's also important to note that turning portfast on does not disable spanning tree. It's still very much running. This bring us to best-practice. It's generally considered a good idea to have portfast configured on anything facing end-hosts (servers, workstations, printers, standard access points, etc). Don't enable it between switches.

The next point is how to deal with the possibility of user-generated loops and rogue switches. This is where bpduguard comes in. This is a feature that looks for spanning tree BPDU's and, upon receipt, will shut down the receiving port (either temporarily or until an admin resets it). The idea here is that end hosts do not generate BPDU's and that the only way an edge port would ever see one is if someone either plugged in an STP-speaking switch or, alternately, mistakenly formed a loop (..by, say, plugging in two wall ports to an unmanaged switch). It's generally considered to be good practice to use bpduguard along with portfast for edge ports.

  • 1
    You summed it up nicely. A little word of caution regarding BPDUGuard: If someone configures a Windows PC to do Internet Connection Sharing or configures it as a network bridge, that PC will try to attempt to participate in Spanningtree and generate BPDU's. If you are not aware of that you can have a lot of fun trying to figure out why BPDUGuard comes into action. Windows can be told not to do that by changing a registry key (I forget which one), but the default is to generate BPDU .
    – Tonny
    Dec 22, 2017 at 11:57
  • Thank you for the concise description. I'll try that out. Thank you. Side question though, if STP is for redundant links, and I have none, should I even bother having it configured? I only use Etherchannels for redundancy, and those are configured as bonded links from one switch to another, never in an alternate path/mesh topography.
    – user208145
    Dec 22, 2017 at 23:07
  • Outside of some very specific use-cases STP should basically never be disabled. In a loop-free environment it will simply be a fail-safe to address both the unexpected (folks plugging the wrong ports into things) and frequently expected transient issues (...like those port-channels momentarily coming up in the wrong order).
    – rnxrx
    Dec 23, 2017 at 1:49

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.