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.
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.
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.