Busting myths – Spanning tree portfast on the interface

I would like to bust a common myth. One that I’m probably guilty of preaching
before as well. We all know that when portfast is enabled the port will bypass
the listening and learning phase of STP. Portfast can be enabled globally for
all access ports or be configured directly under the interface.

The myth is as follows. When enabling portfast globally the port will lose its
portfast status when receiving BPDUs and go through the regular STP phases
but if BPDUs are received on interface where portfast was enabled specifically
it will continue to use portfast and bridging loops may appear.

Part of the myth is also that portfast enabled ports do not send BPDUs.

So we start out by busting the second part of the myth. To do this I will
simply enable portfast on a port and we will see the number of BPDUs
incrementing.

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#int fa0/1
SW1(config-if)#span portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface  when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION

%Portfast has been configured on FastEthernet0/1 but will only
 have effect when the interface is in a non-trunking mode.
SW1(config-if)#^Z
SW1#sh span int fa0/1 portfast
VLAN0001            enabled

Portfast is definitely enabled. Are any BPDUs going out?

SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 43, received 0
SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 46, received 0

So clearly that was easy to bust. BPDUs are still sent on portfast enabled ports.
Anyone claiming STP is disabled and that portfast enabled ports don’t send BPDUs
is clearly wrong. All it does is to bypass the listening and learning phase.

So what happens when BPDUs are received? I will enable IRB on a router to
start sending BPDUs. I will set the priority to something better than the
switch so that the router side will become designated.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#bridge irb
R1(config)#bridge 1 protocol ieee
R1(config)#bridge 1 priority 8192
R1(config)#int fa0/0
R1(config-if)#bridge-group 1

R1 is now running STP:

R1#sh span

 Bridge group 1 is executing the ieee compatible Spanning Tree protocol
  Bridge Identifier has priority 8192, address 000d.bc01.3400
  Configured hello time 2, max age 20, forward delay 15
  We are the root of the spanning tree
  Topology change flag set, detected flag set
  Number of topology changes 1 last change occurred 00:00:13 ago
          from FastEthernet0/0
  Times:  hold 1, topology change 35, notification 2
          hello 2, max age 20, forward delay 15 
  Timers: hello 0, topology change 24, notification 0, aging 15

 Port 4 (FastEthernet0/0) of Bridge group 1 is listening
   Port path cost 19, Port priority 128, Port Identifier 128.4.
   Designated root has priority 8192, address 000d.bc01.3400
   Designated bridge has priority 8192, address 000d.bc01.3400
   Designated port id is 128.4, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   BPDU: sent 3, received 3

So now we should be receiving BPDUs on SW1.

SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 221, received 41
SW1#sh span int fa0/1 det | i BPDU
   BPDU: sent 221, received 43

And we are. So what happened to portfast now that we are receiving BPDUs?

SW1#sh span int fa0/1 portfast
VLAN0001            disabled

It’s disabled! Myth busted! Even if portfast is enabled under the interface it
will still lose its portfast status if BPDUs are received. If we debug we
can see that the port did not have to go back through blocking -> listening
-> learning. It stayed in forwarding even though BPDUs were received.

STP CFG: found port cfg FastEthernet0/1 (2E9E1E0)
STP: VLAN0001 heard root  8192-000d.bc01.3400 on Fa0/1
    supersedes 32769-000c.3058.7c80
STP: VLAN0001 new root is 8192, 000d.bc01.3400 on port Fa0/1, cost 19
STP: VLAN0001 Fa0/16 -> listening
STP: VLAN0001 Fa0/17 -> listening
STP: VLAN0001 Fa0/18 -> listening

So bridging loops can form because the listening and learning phase is bypassed
if we enable portfast on Inter Switch Links. They would only be temporary though
because as I showed the ports would lose their portfast status when BPDUs are
received.

Assume that we have a topology like this:

Portfast has been enabled on all Inter Switch Links. Which ports keep their portfast
status and which would not? Give me suggestions in the comments section.