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

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.

Busting myths – Spanning tree portfast on the interface
Tagged on:             

8 thoughts on “Busting myths – Spanning tree portfast on the interface

  • August 4, 2013 at 4:07 pm
    Permalink

    Designated ports would keep their port fast status as they should be transmitting but not receiving BPDUs?

    Reply
      • October 7, 2021 at 11:29 am
        Permalink

        DP on sw3 right? DP ports SW1 will be sending and receiving right?

        Reply
  • August 5, 2013 at 10:22 am
    Permalink

    What happens if you reboot the switches? Say SW1 has the highest priority SW2 the next and then finally SW3. Bring up SW3 and then SW2 and finally SW1?

    Reply
    • August 8, 2013 at 3:15 pm
      Permalink

      I would assume that until SW3 hears better BPDU it is designated so it sends BPDU towards SW2. When SW2 comes online it will become designated and send BPDU towards SW1. Then SW1 comes on and starts sending BPDUs so doing it this way you might trigger all the interfaces depending on the timing I suppose.

      Reply
  • December 13, 2014 at 6:41 pm
    Permalink

    The misunderstanding may be caused or at least encouraged by the behavior of bpdufilter enabled globally on edge ports vs. directly on individual ports. This is of course an entirely different thing. “spanning-tree portfast bpdufilter default” only applies on ports with portfast status, and since portfast status is lost when a BPDU is received, the BPDU filtering is also gone from the port. The port will normally participate in the STP as described above. If the bpdufilter is enabled directly on the port, however, it has no relation to the status of the port, and will filter out all incoming / outgoing BPDUs and in effect disable STP from the port.

    Enabling bpdufilter globally for the portfast / edge ports seems to be a quite common configuration, which will prevent edge ports from sending out BPDUs while they maintain their status. This may also contribute to the second part of the myth, which states that portfast ports would not send BPDUs.

    Reply
  • August 27, 2015 at 11:43 pm
    Permalink

    Daniel,

    If two switches are connected to each other on portfast enabled access ports, only the root bridge will transmit BPDUs. The downstream switch’s designated port will send one BPDU and go silent.

    ROOTbridge#show span inter eth 0/0 detail
    Port 1 (Ethernet0/0) of VLAN0001 is designated forwarding
    Port path cost 100, Port priority 128, Port Identifier 128.1.
    Designated root has priority 32769, address aabb.cc00.0100
    Designated bridge has priority 32769, address aabb.cc00.0100
    Designated port id is 128.1, designated path cost 0
    Timers: message age 0, forward delay 0, hold 0
    Number of transitions to forwarding state: 1
    The port is in the portfast mode
    Link type is shared by default
    BPDU: sent 1586, received 1

    NON-ROOT#show span inter eth 0/0 detail
    Port 1 (Ethernet0/0) of VLAN0001 is root forwarding
    Port path cost 100, Port priority 128, Port Identifier 128.1.
    Designated root has priority 32769, address aabb.cc00.0100
    Designated bridge has priority 32769, address aabb.cc00.0100
    Designated port id is 128.1, designated path cost 0
    Timers: message age 1, forward delay 0, hold 0
    Number of transitions to forwarding state: 1
    The port is in the portfast mode
    Link type is shared by default
    BPDU: sent 1, received 1586

    Any thoughts on why a daisy-chained setup would lead to such results?

    Reply
  • December 21, 2016 at 8:44 am
    Permalink

    Thanks for the post. Have you tried setting portfast default globally and making sure there’s no interface-specific portfast configuration and repeat your tests? I bet you will see the port transitions through the stp states with only the global portfast option enabled. Perhaps the portfast disabled in your output is more of an IOS display glitch (wouldn’t be the first). The fact the port stayed in the forwarding state with interface-level portfast after receiving a bpdu seems to go with what popular belief is, even though the command says portfast was “disabled”, it clearly was not since it stayed in forwarding even with the reception of bpdus.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *