@paul driver wrote:
I agree the whole purpose of stp alone in an ideal network is to negate a loop but even when its being correctly used but just because its suppose to do it, doesn't mean it will do it or should i say have chance to do it.
what if the switch(s) are not capable of processing stp at that particular time or the design of the network is that convergence of stp is slow, Enough to an extent a loop can be formed to cause a disruption?
@paul driver , an excellent question, although using an "ideal network", using STP as intended, makes it much less likely for a L2 loop to be initially created, due to, a port coming on-line blocks all but BPDU traffic while it ascertains, whether it appears safe to unblock that port.
The risk of Portfast is, it immediately unblocks the port, without any dynamic analysis, whether it's safe to do so.
Big difference in approaches.
Standard STP, let's first hopefully determine if we're going to create a L2 loop before unblocking the port, vs. Portfast, let's possibly create a L2 loop first, hopefully we don't, and then, also hopefully, somehow, successfully close one we did create.
Admittedly, the standard STP analysis approach, can fail, and the STP recovery after the loop is inadvertently formed approach might succeed, but which would you suspect might have a better chance of not causing an issue?
As STP, in theory, can recover after inadvertent loop creation, in theory, for that purpose, alone, no need for BPDUGuard.
Or another way to say it, BPDUGuard, if used to break a loop that STP didn't, might be considered, what we used to call, a "belt and suspenders" solution. In theory, if either the belt or suspenders fails, your pants don't fall down. We now have failure redundancy.
However, if our belt was but a string, might it be more prone to failure? If so, if using that as a belt, alone, probability failure likely increases but offset by using suspenders.
So, let's consider Portfast a string belt.
Is this making any sense?
BTW, I'm not against using BPDUGuard, or against redundancy, but there's cost to redundancy, and various odds of different kinds of failure.
For example, one chassis might have redundant sups, power supplies and line cards, but the chassis, itself, remains a single point of failure. Chassis, though, generally, have a lower expectation of failure, than the active components. However, we might go with a two chassis setup, for something like the core. (In the latter, two chassis setup, one can then debate, should the two chassis have dual sups, dual line cards, dual power supplies.)
In one firm I worked at, they took redundancy very, very seriously, they even considered whether dual chassis should use totally different platforms, even perhaps different hardware vendors, hoping a bug on one wouldn't be on the other. For our WAN connections, even using different WAN providers, we tried to avoid those different vendor links running down the same trench or to the same pop.
I sometimes point out, the famous Titanic sinking, many died from an insufficient number of life boats, but not due to drowning, as some often assume! I believe, life jackets were available for everyone. Hundreds (337) were later recovered, most floating about in their life jackets, but having died from the freezing water.
So, after the Titanic, ships now are required to have sufficient life boats for all aboard. However, in the sinking of the Andrea Doria and Costa Concordia, both listed enough, half the life boats couldn't be used.
Oh, I'm not implying, ship life boats should be reduced, but even with redundancy, they might be suited for the more common failure probabilities rather than any possible failure. (Or consider, if you've flown commercially, where was your parachute?)
Such I think is this case, I believe, with STP, Portfast, BPPDGuard. Do your own analysis. Figure out what appears best for you.
Lastly, networks I've designed and/or maintained, almost always used Portfast on edge ports. But to mitigate L2 loop creation, we avoided having any STP intentional redundant L2 links; our redundancy was via L3, single logical device and/or Etherchannel.
