We have a team of network engineers from all different backgrounds including CCNA, CCNP and CCIE?s who are currently debating on a RSTP related issue.
I am hopeful that many will review and comment on this issue.
The end goal is high availability through redundancy with rapid reconvergenece.
An attempt to build another five-nine network. 99.999
Configuring RSTP consists of the following but not limited to:
Since I have started to work with Cisco products I have always been under the understanding that you never configure portfast on a trunk link as this can cause temporary loops. I still believe this.
We have read several procedures and documents released from Cisco running under Hybrid Code and Native IOS code that conflict with one another.
For example, several procedures contain portfast configured on a trunk interface.
We would like to bring closure to this question.
The question is, how does portfast apply when there is one access link (non trunking) between two switches.
Not that it?s relevant but we are working on 6509?s running Native IOS in transparent mode.
Thanks in advance for your help,
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).