What actually happens when a portfast configured port receives a BPDU actually depends on the configuration.
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
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
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.
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.
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?
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.
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.
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?
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!
Hi,
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 ?
Thanks
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?
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.
Is a good practice to enable portfast no only in STP, but also in RSTP ?
i’ve replicated this lab, and also changed sw1 & sw2 to RSTP mode, a i’ve verified when i do the no shut to lift the access port, its still send TCN, and also it tried the proposal,agreement RSTP msgs through this port… When i enabled Portfast it stopped sending TCN and also didn’t send any proposal, agreement msg and goes to FW state inmediatly
Sure, it’s good practice to enable portfast when using RSTP. You will see that when using RSTP, if you don’t configure portfast, the port still comes up quite quickly when you plug in a host like a PC. The advantage of portfast when using RSTP is that it avoids the whole negotiation process and the TCN which is an unnecessary use of device resources. So although portfast with RSTP doesn’t make the port go to forwarding state faster, it does improve on the efficiency of the operation of RSTP.
Take a look at this lesson, which includes an explanation of what portfast does to the operation of RSTP:
How should a trunk port connected to an Access Point be treated? Would a TCN only be generated if the Access Point itself were to disconnect or would users disconnecting fronm the AP cause them?
First of all, you should never have a trunk port connected to an access port. An access port is a port to which you would connect an end device like a PC, an IP camera, or a printer. If you connect an access port of one switch to a trunk port of another switch, you will have some undesirable and unpredictable behavior. Indeed, if you hardwire the ports as Access and Trunk, you will have limited connectivity. More info on this found in the table at the bottom of this lesson:
Now having said that, if you don’t configure portfast on your access ports, then every time the interface itself goes down (i.e. you turn off your computer, or you unplug it from the network) a TCN will be sent. The TCN is generated whenever the switch detects that the access port goes down. A port can go down either because you shut it down manually, you’ve unplugged the cable, or the device connected to the port has been powered down, or has malfunctioned. Does that make sense?
Hi @lagapidis thanks for the response. I think there was a misunderstanding. I am asking about an Access Point not port. Like a Wireless AP to connect users. When that is connected to a switch