If you only have one link between two switches and the entire spanning tree domain consists of just these two switches and the link is an access link, then enabling portfast really makes no difference at all. Since there is only the one link, it will always be in a forwarding state.
If you have multiple access links between two switches and you configure portfast on them, the likelihood of a loop developing are pretty high since all of them will immediately enter the forwarding state.
Uplinkfast is certainly your best bet here if you want to have separate logical links between the device.
However, the best option here is to configure an Etherchannel between them, of course :-)
Big rules like "you should never configure portfast on a trunk" are meant to be simple and safe. It is however not very precise, and are not really useful when the concept behind is really simple, as it is in this case.
The only relevant question is whether the port you are connecting can introduce a bridging loop.
*If yes, then you'd rather leave STP run unmodified and don't configure portfast. Note that, as it was mentioned in this thread, a port connected to bridge that is not introducing any redundancy in the network could in theory be configured with portfast. I would personally not recommend it because the advantage is not worth the potential trouble. That's however a decision (and a risk) you could perfectly take as an advanced user.
*If the device cannot introduce a bridging loop, then you can configure portfast. With RSTP and MST, if you want to benefit from the fast convergence introduced by those protocols, you *should* configure portfast. Layer 3 devices (routers, hosts) are safe and can be configured for portfast.
The port that you configure with portfast is an edge port in the IEEE terminology. Edge vs non-edge makes much more sense than trunk vs access. Cisco's terminology is actually not appropriate at all. It comes from the days when the only trunking technology was Cisco's ISL and that a trunk port was necessarily going to a Cisco switch (thus non-edge) while hosts (that did not understand ISL) were necessarily connected to an access port.
Edge = access vs trunk = non-edge is not valid any more (and was in fact never valid). 802.1Q being an IEEE standard, any PC can be trunking nowadays. Routers can have trunk interfaces to a switch. A PC and a router are edge devices. You should configure portfast on them (the command has been introduced under "portfast trunk" as a fix to this wrong terminology). On the other hand, as it was also mentioned in the thread, you can perfectly connect two switches using an access link and create a bridging loop in your network.
So forget trunk and access, just think about edge and non-edge.
Uplinkfast and backbonefast are not relevant to RSTP or MST, that have the equivalent functionality built-in. Again, if you run Rapid-PVST or MST, make sure you correctly identify edge port and configure portfast on them.
Enabling bpduguard by default on portfast port would not be a good idea for at least the two following reasons:
-1-Bpduguard is a proprietary feature and was introduced after portfast. We just could not change portfast's behavior by enabling it by default as of a certain release. Note that you can configure "spanning-tree portfast default" in the global configuration mode to achieve this if you wanted.
-2-Bpduguard does not prevent a temporary loop that would be the result of a misconfiguration of portfast.
When you configure portfast on a port, you don't disable STP, you just make this port moving to forwarding immediately. If you made this misconfiguration on both ends of a redundant link, you will effectively end up with a temporary bridging loop until a single bpdu is exchanged between the two ports. As soon as STP detects the loop, it blocks one port. If you configure bpduguard, the exact same temporary bridging loop would occur, the only difference is that when the loop is detected, the port is shut down. That's just a different policy you apply as a result of receiving a BPDU. BTW, bpduguard is not very subtle because it will shut down the port if it receives a bpdu, even if the link is not introducing a loop in the network. For instance, if you connect two switches with a single link and configure portfast on both end of this link, nothing bad happens (as it was mentioned in the thread). If you configured bpduguard, the link goes down, which is relatively bad in one way (but gives you a warning on the other hand).
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...