I understand the basics of how spanning tree works and why you would want to use portfast on user access ports.

When dealing with a topology with a large number of dumb switches under desks and other undocumented locations do you really want to enable this on all "supposedly" access switches?

Apart from trying to track down these unmanaged switches what is best practice? Why?

5 Answers 5


You should run 'port-fast' (in standard terms edge port) in every port not part of your switch core. Even if it is switch.

You should NOT have L2 loop through customer switches.

You should run BPDUGuard and BUM policers all interfaces, customer facing interfaces should be 1/5th or less of core facing limits. Unfortunately limiting unknown unicast often is not supported.

Why running 'port-fast' or edge is crucial is performance of RSTP (and by extension MST) rely on it. How RSTP works is it asks downstream if it can go to forwarding mode, and downstream asks its downstreams until there are no more ports to ask frmo, then the permission propagates back up. Port-fast or edge port is implicit permission from RSTP point-of-view, if you remove this implicit permission, explicit permission must be gotten otherwise it'll fall back to classic STP timers. Which means even one non-portfast port will kill your subsecond RSTP converge.

  • 5
    As full disclosure I got one down vote on this. If I've stated something incorrect, I would much appreciate being corrected, thanks.
    – ytti
    May 25, 2013 at 6:11
  • I'm curious as to what the difference between 'switch core' and 'switch' is? Is this in the context of an ISP, or an enterprise network?
    – cpt_fink
    Nov 21, 2014 at 5:55

In addition to spanning-tree portfast, you should also use spanning-tree bpduguard enable so that if someone creates a loop by plugging in things where they should not then the switch port will go into error disabled mode when it sees a BPDU rather than creating a loop and potentially bringing down the network.

As well, if your goal is to track down the unmanaged switches you should enable

 switchport port-security maximum 1  ! or whatever number is appropriate
 switchport port-security violation shutdown
 switchport port-security

This will put any port into error disable that sees more than 1 mac address connected. Either via traps or waiting until they call for help will allow you to identify where those unmanaged devices are connected.

More info on port security

  • 4
    For Cisco (based on config above), I recommend you configure spanning-tree portfast bpduguard default on all switches. This enables bpduguard on any interface with portfast enabled. You may want to also configure errdisable recovery for bpduguard.
    – YLearn
    May 24, 2013 at 18:11

When dealing with a topology with a large number of dumb switches under desks and other undocumented locations do you really want to enable this [portfast] on all "supposedly" access switches?

The official and pedantic answer is "no, do not enable portfast on switch to switch link"... There is a relevant discussion about this on Cisco's support forum.

The author of that thread makes a fair point though, the network police will not arrest you for enabling portfast facing a downstream switch... It is possible to hack around the risks of temporary broadcast storms that you take when you enable portfast on a link to another switch.


If you enable portfast on a link to a smart or dumb switch, be sure to enable bpduguard (control-plane protection), and broadcast storm-control (data plane protection) on that port... these two features give you some leverage in case unexpected things happen:

  • someone filters the BPDUs that would normally cause bpduguard to disable the port, resulting in a broadcast storm. Storm-control limits the damage from a broadcast storm
  • bpduguard has obvious advantages mentioned in the other answers.

Applying port specific commands in your configuration will reduce port initialization time in the event that the switch or the connected device power cycle, reboot or reload. They may also prevent misapplied configuration settings in the event the port does not properly negotiate.

As the default for Cisco switches is switchport mode dynamic desirable (Cisco Stackwise capable switches are the exception) every port attempts to negotiate its intended purpose. This negotiation process has four major phases and may take a full minute to complete. - Spanning Tree Protocol (STP) initialization – the port goes through the five phases of STP: blocking, listening, learning, forwarding, and disabled. - Testing for Ether Channel configuration – port uses the Port Aggregation Protocol (PAgP), bonding together of switch ports to create larger aggregate Ethernet connections. - Testing for trunk configuration – ports uses Dynamic Trunk Protocol (DTP) to negotiate/validate a trunk link. - Switch port speed and duplex – port uses Fast Link Pulses (FLP) to set speed and duplex. Failure to negotiate duplex Cisco switches use a default duplex setting of half duplex (HDX) (for 10-Mbps and 100-Mbps interfaces) or full duplex (FDX) (for 1000-Mbps interfaces).

Configuring switchport mode access will prevent the port from going through trunk negotiation.

Configuring spanning-tree portfast will prevent the port from going through STP negotiation.

Configuring switchport host will configure both access and portfast..

Of course the caveat from Cisco - Caution: Never use the PortFast feature on switch ports that connect to other switches, hubs, or routers. These connections can cause physical loops, and spanning tree must go through the full initialization procedure in these situations. A spanning tree loop can bring your network down. If you turn on PortFast for a port that is part of a physical loop, there can be a window of time when packets are continuously forwarded (and can even multiply) in such a way that the network cannot recover.


I know most people say don't do it -- hard rule, for hard people. :-)

If they're dumb switches (eg. don't run any STP), then it doesn't make much difference. Speaking from Cisco experience, it'll catch the loop almost immediately in any event. In the world of VMs, even an "edge port" can be a loop. (Our developers have learned that the hard way.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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