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?
Best Answer
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.