Why shouldn't I activate portfast on a trunking port for a Cisco switch?

I do understand that it could cause a loop on the the network, but I still cant wrap my head around the concept.

  • 1
    The warning message was compiled to warn people about portfast on trunks between network devices. You can still set portfast for hosts connected via trunk.
    – user36472
    Commented Apr 11, 2019 at 15:00
  • So if switches only foward packets, what packets may cause a loop ? BPDU packets?
    – sgt
    Commented Apr 11, 2019 at 15:32
  • Switches forward frames, routers forward packets. The packets have a TTL that will expire if you hit a routing loop. Frames have nothing like a TTL. When switches receive broadcasts, they flood them to every interface, and if there is a loop, they continue to do that forever amplifying the broadcasts on each loop, eventually crashing the network with too much traffic for the switches to handle.
    – Ron Maupin
    Commented Apr 12, 2019 at 1:30

2 Answers 2


Having portfast on a inter-switch link is not the best of ideas, indeed.

Switches and Bridges should take the time needed (going through listening/learning phases) to converge to a loop free L2 topology. Rapid-Spanning-Tree, Rapid-PVST (Cisco), and MST are there to speed that process up from the classic 30sec of Spanning-Tree down to like 2-5 seconds.

On the other hand, not having portfast on a (non-bridging) end device's port is practically never a good idea - no matter if that port is "access" or "trunk".

Routers (not necessarily restricted the "on a stick" scenario) often run 802.1q tagged (sub)interfaces, and hypervisors such as VMware have trunk ports too.

And these devices are (more often than not) very unhappy with the 30seconds of black-hole situation after they see the line protocol go "up", just as a DCHP client on an access port is not happy with having to retry after more than 30 seconds.

VMware ESXi for example, when a link comes up, wants to send out a burst of RARP messages (at least one for each VM, with the VM's MAC address as source) through the link that has just come "up" (a feature called "notify switches" somewhere deep in the vSwitch's configuration). This helps the switches involved to immediately update their MAC address tables for the given VLANs. ESXi does this within a fraction of a second after it detects the "line protocol up" event.

A non-portfast trunk port going through LIS/LRN phases of STP (or the LRN of Rapid-PVST) will just break the "notify switches" feature. Users and admins will be quite unhappy, because their VMs might remain unreachable for even longer than these 30seconds, until the VM sees fit to send its first frame and the switches re-learn the VM's MAC address.

Even Cisco's DTP (Dynamic Trunking Protocol) interferes with "notify switches", as it keeps the port blocking for something less than 1 second before aborting negotiation. switchport nonegotiate becomes your friend in these situations.

Pretty much the same thing can be said for routers and their dynamic routing protocols. As soon as they detect "line protocol up", they want to launch their hello and discovery mechanisms. Blackholeing them with non-portfast ports for 30seconds is just extending network reconvergence time, ruining the router admin's own efforts to optimize to sub-10-seconds reconvergence. They'll be standing at your desk, tapping their feet.

Be sure to know the difference between spanning-tree portfast and spanning-tree portfast trunk for classic IOS switches, respectively spanning-tree port type edge and spanning-tree port type edge trunk for more recent IOS and NX-OS (syntax may vary in details, check your documentation), and apply them correctly.

Without the trunk keyword, the portfast setting is only active if the port is in 'access' mode. If you configure switchport mode trunk for an edge device, you have to include the trunk keyword in the portfast command, too.

Yes, a portfast enabled port skips the LIS/LRN phases of spanning-tree.

That's why you should always add bpduguard to portfast ports. Some Cisco switching platforms support the spanning-tree portfast bpduguard default global command, so you get bpduguard implicitely on every portfast enabled port, and you cannot forget it.

Yes, I've been running switched networks in quite a range of sizes with portfast trunk and bpduguard for the end devices for years.

And now for the question about the warning: The warning about (temporary) loops - to some degree - might be a leftover from the days when trunks were primarily a thing for inter switch links, bpduguard was not widely deployed and DTP was still a thing. If one connected a switch to another switch without setting the port modes explicitely, DTP might've negotiated an inter-switch trunk, and these should never be "portfast". Hence Cisco probably decided to let spanning-tree portfast be without effect for trunk ports. But that's more speculation than actual knowlegde.

Suggested reading: Any of the many Cisco documents titled "Configuring Optional Spanning-Tree Features", usually part of the collection of Configuration Guides.

Pick one that fits the given platform and software generation. One example: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/15-2_4_e/configurationguide/b_1524e_consolidated_3750x_3560x_cg/b_1524e_consolidated_3750x_3560x_cg_chapter_01000001.html


You can use PortFast to connect a single end station or a switch port to a switch port. If you enable PortFast on a port that is connected to another Layer 2 device, such as a switch, you might create network loops. But you can enable portfast with router on stick case.where you have switch with trunk configured with router interface.

  • So if switches only foward packets, what packets may cause a loop ? BPDU packets?
    – sgt
    Commented Apr 11, 2019 at 15:32
  • @ Alexandre it is a broad topic, please refer this link. you will understand. Any clarification, just put a comment en.wikipedia.org/wiki/Switching_loop
    – infra
    Commented Apr 11, 2019 at 15:42

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.