Portfast was originally conceived to resolve issues with legacy 802.1d STP and Cisco’s PVST+. With RSTP and MST, the concept of Portfast is redefined as an Edge port, however for backwards compatibility it is still enabled through the portfast command.
Portfast should only be used on host ports, i.e. ports that connect to only a single host. On these ports there is no need for BPDUs, simply because BPDUs are only used by switches to detect layer 2 loops. A host computer will not understand or originate BPDUs, and consequently there is no need for a port to go through the standard Listening, and Learning states. Instead the port can transition immediately to the forwarding state.
In an Enterprise environment then, the concept for portfast is very important as most connected devices will be hosts.
If you remember legacy 802.1d goes through the following states changes before deciding whether to forward data frames:
Listening state: As soon as you plug a cable into a switch, it enters the listening state. No data frames are allowed to pass in this state. During this state the port will send and receive BPDUs to determine the state of the topology. The switch stays in this state for 15 seconds, to ensure the topology is stable.
Learning state: During this state, the port will have determined the topology and will start to populate the MAC address table of the switch by processing the source MAC addresses of frames received on the port. It will remain in this state for 15 seconds.
Forwarding state: After the Listening and Learning states have concluded, the port will start to forward data frames. This mean a port will take 30 seconds in total to get to this point.
Clearly this is a long time to wait in a modern network. Worst still, this delay may result, for example, in a host timing out whilst trying to obtain an IP address from a DHCP server, or whilst trying to connect to a domain controller. The remedy to this is to enable Portfast. Instead of waiting, the port will immediately transition to forwarding. Caution needs to be exercised however, only host devices should be connected in order to avoid potential loops.
“But hold on a second. I heard a port can take up to 50 seconds before forwarding data frames?”
Yes that is correct, but only for a port that is already connected and already in the blocking state. This would be in a switched environment where a physical loop exists, and a port has to be blocked in order to ensure a layer 2 loop does not occur. If the physical topology changed, and a physical loop no longer existed, then the blocked port may need to start forwarding frames again, however before entering the Listening state, the port will remain in the blocked state for 20 seconds to ensure the topology is stable. In this case the port will take 50 seconds in total before forwarding data frames:
Below is a table summarising the port states and default timers:
Configuring Portfast
Portfast can be configured in either global configuration mode, or interface mode.
switch(config)#spanning-tree portfast default ? <cr> switch(config-if)#spanning-tree portfast ? disable Disable portfast for this interface trunk Enable portfast on the interface even in trunk mode <cr>
In global configuration mode all ports in the switch are enabled, it therefore makes sense to disable portfast on any interfaces connected to other switches. To do this use the spanning-tree portfast disable command in interface mode.
In interface mode ports can be enabled, disable, or enable for trunk ports. Be advised that enabling portfast should only be enabled on trunk ports where the trunk terminates on a server or router, not another switch.
The Traceroute Blog 