Cisco Portfast Configuration

Thanks Andrew. Now i can understand completely. I misunderstood that portfast will not send BPDU’s.

Hi Rene,

What happen if the port enables portfast is to be part of the loop ?
The port is going to be blocked or not?

Thank you

PortFast does not stop the port from sending BPDUs. Therefore, if a port that became part of a loop had PortFast enabled would detect this, and the port would lose its PortFast state and return to normal spanning-tree operations. This assumes the other end of the connection cause the loop does not have BPDU Filtering enabled, which would block that side from sending BPDUs.

Hi Rene,

It means Portfast enabled interface still sends and recevies BPDU.
what happens when We configure BPDU filter ?

There are actually two modes of BPDU Filter: Per port (dangerous) and globally.

In the port mode, the switch will not send or receive BPDUs (which essentially disables the STP process) on the port in question. Configuring BPDU Filtering in port mode would prevent the switch from detecting a loop involving the port where it is enabled. This is why this option is considered dangerous and is generally avoided.

In global mode, this command is paired with portfast as follows:

switch(config)#spanning-tree portfast bpdufilter default
switch(config)#spanning-tree portfast default

This prevents interfaces in portfast mode from sending BPDUs. However, if a BPDU is received on such an interface, the interface will lose its PortFast state, and outgoing BPDU filtering is disabled.

As on different threads and post see that Don’t enable portfast on an interface to another hub or switch. If you enable Port Fast on a port connected to a switch (a network port), you might create a temporary bridging loop…
My question is how bridging loops will be created as when port on which portfast is enabled receives the bpdu, then that port losses its portfast status and start working like a normal port. then how loops are going to create.

My second questions is that can we enable portfast on the trunks.?

and also, does portfast enabled port immediately transition to blocking state if they receive the superior BPDU.?

If, I understand correctly then portfast enabled port towards the host sends only BPDUs and do not receive BPDUS and if we enable Portfast on the interface or port that is connected to another switch then that port will receive the BPDUs from the root switch and when that port receives the BPDUs, the port immediately losses its port fast status and become normal port. Please let me know if this statement is correct about portfast.

Hello Rene,

If one port on switch is configured as portfast, and accidentally someone connected another switch on that port …what will happen… what will be impact? … because I think it is recommended that portfast enbaled ports must be connected to host devices.
Please reply.


Hello Tejpal

What actually happens when a portfast configured port receives a BPDU actually depends on the configuration.

  1. In simple STP (IEEE802.1D), a portfast port will be reset back to a normal port participating in STP if BDPUs arrive on the port. If a physical L2 loop is created on such a port, it will result in a temporary L2 loop until STP reconverges. This is why you will see this warning when configuring portfast (notice the word “temporary”:

     %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
  2. In simple STP (IEEE802.1D), if loopguard is enabled, a portfast port will be put into an inconsistent state until BDPUs stop arriving on the port

  3. When configured with BPDU Guard, the port will actually go into err-disabled state if it receives a BPDU.

Even a temprorary loop is undesirable, so always make sure to configure additional safeguards to avoid any such situation.

Port fast can indeed be enabled on trunks. It is not best practice to do so, but there are some situations where it is necessary. You can find out more about this at the following link:

Keep in mind that portfast does not mean that the port no longer takes part in STP. It does. It can send BPDUs and it can respond to BPDUs that are recieved. How it reacts to received BPDUs depends on the configuration as described above.

I hope this has been helpful!


1 Like

Hello Swapnil

If a situation like this happens, the port that is configured with portfast will receive a BPDU. What happens next depends on how the port is configured. Take a look at the previous post above to see more details.

In general it is best practice to enable portfast only on ports that have end devices connected to them and not other switches.

I hope this has been helpful!


After reading the article, I’m confused with the purpose of “spanning-tree portfast trunk” as portfast should be configured on access port which is connecting to the host. Under what scenario will this command be used on a trunk port?

Thank you

Hello Po

A general rule of thumb is to configure portfast only on access ports. However, there are some situations in which you would want to enable portfast on a trunk port. One such situation is if you have a server that is itself running 802.1Q on the NIC creating a trunk between the server and the switch. This may be the case if you are running virtual machines on a hypervisor and you require direct access to several VLANs and you are performing switching and routing within the virtual environment.

Another situation where you might want to enable it is on trunks that connect to wireless access points. If you routinely disconnect and connect WAPs in your environment, you may not want to wait the extra few seconds before the switchport moves to the forwarding state.

So I believe this rule of thumb should really be revised to say that porftast should only be enabled on ports that connect to single physical hosts, regardless of whether these ports are access ports or trunk ports. Although a trunk port rarely connects to a single host, there are situations in which it does happen, and this is why the feature exists.

In any case, portfast should be used carefully as it could cause unwanted network instability. If you can avoid it, and you can live with the extra few seconds of wait time before the port reaches forwarding state, then don’t enable it on trunks, even for trunk connections to servers or WAPs. It’s a small price to pay for ensured network stability.

I hope this has been helpful!


(1)"Don’t enable portfast on an interface to another hub or switch"

so we only use it on end clients , servers . does it include routers as well?

What about L3 switch ? wifi router or accesspoints. what about syslog server which gets info from cisco devices ?

Thank you

Hello Abdul

The idea is that portfast should not be enabled on any interface that connects to another device that is participating in STP. Routers, servers, PCs, IP cameras, IP phones, and other such devices don’t participate in STP, so these can be connected to ports on a switch configured with portfast.

Some access points may participate in STP, so if they do, don’t enable portfast on those ports. If you’re sure they are not configured to participate in STP, then you can enable portfast.

The idea is that any port that is configured with portfast should not expect to receive any BPDUs. If it does, it goes into the err-disabled state to avoid creating any layer 2 loops.

I hope this has been helpful!


Hello Rene, Am trying to understand some basics concepts of BPDU filter. If the BPDU filter is enabled on a global level, whenever a BPDU is received on an interface, the filtering capability will be disabled and the port will participate in spanning as just like a normal port. So, I fail to understand, what is the essence of having the BPDU filter in global level in the first place?

Hello Eugene

BPDUFilter functions differently when you configure it globally and when you configure it on a specific interface. Rene explains it like so in the Spanning-Tree BPDUFilter lesson:

If you enable BPDUfilter globally then any interface with portfast enabled will not send or receive any BPDUs. When you receive a BPDU on a portfast enabled interface then it will lose its portfast status, disables BPDU filtering and acts as a normal interface.

So when configured like this, the purpose of BPDU filter is to disable portfast on the affected interface. This is useful because if you disable portfast, the port is protected from forming layer 2 loops, because it goes through the listening, learning, and forwarding stages, and will go into blocking if a loop is detected. Otherwise, if portfast is not disabled, a layer 2 loop may occur, causing the network to fail.

Much more detailed information about BPDUfilter is found in the following lesson and should clarify most of your questions:

If you have any more questions, you know where to find us!

I hope this has been helpful!


Just wondering on the “newer” versions of ios there is portfast edge, network and normal.
I presume edge is same as before but what is network and normal ?
Also usually in the “older” ios versions I could enable portfast default in global config mode but there doesn’t seem to be this option with the newer commands so does this mean I have to go under the interface of each port and choose edge, network or normal mode ?

Hello Sean

Take a look at this post that deals with these issues:

I hope this has been helpful!


1 Like

Many thanks Lazaros, I understand it now.

1 Like

Hi Rene/Laz
If we have a server connected to two switch ports, configured in switch independent teaming mode, is there any problem with enabling STP portfast? Could a loop potentially exist at any stage, maybe when the server boots up if the team hasn’t sorted itself out?


Hello Phil

There would be no problem in such a configuration, and actually, that would be best practice. The server could not create a Layer 2 loop in such a situation since any frames that it receives will be processed by the server itself. There is no mechanism in the server to forward any frames it receives on one NIC out the other.

The only way this would create a problem is if you have purposefully simulated a switch on the server itself. You can do this easily on a Linux server by bridging the NIC interfaces. So unless you’re doing something like that, you shouldn’t have a problem.

I hope this has been helpful!