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.

Portfast is definitely enabled. Are any BPDUs going out?

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 is now running STP:

So now we should be receiving BPDUs on SW1.

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

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.

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:             

7 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
  • 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 *

%d bloggers like this: