@Cristian Matei wrote:
You always get the best out of myself and I say that in a good way.
Your best, is excellent. If fact, reading your posting reminds me much of reading Peter Paluch's postings.
To reiterate, to be concerned about how fast Portfast STP processing will kick in, with "seeing" a BPDU, or how fast BPDUGuard processing will kick in, again with "seeing" a BPDU (i.e. L2 loop duration), or which is faster, if either is faster, might be just an old networking "wife's tale", totally without merit. Further, if it was ever an issue, at all, it may not be an issue on modern hardware.
I known you're not keen on suppositions, but I'll relay what I understood was the "issue" of a temporary L2 loop and why it might not be an issue today.
My understanding was, the danger of Portfast allowing a L2 loop, the loop, itself, may flood switches' CPU, such that the "normal" STP process is unable to complete at all. I.e. the L2 loop is never broken.
Couldn't the same be true with BPDUGuard? Sure, although, in theory, possibly it has less to do. Remember, the new L2 loop, from a STP perspective, might actually be the new better path. Whereas with BPDUGuard, it only needs to concern itself with shutting down the port.
Later gen switches, besides likely having more powerful CPUs, now have usually CPU protections like CoPP. Or, as you mention, storm-control protections (which, I recall, were available before CoPP), but they have their own limitation too.
However, even with more powerful CPUs, and/or "circuit breakers", why isn't Portfast the standard. I mean, if we only need to worry about, maybe a very short duration L2 loop, which Portfast (or BPDUGuard) will break, why waste anytime at all coming on-line before joining a L2 domain, regardless of what's joining it?
So, for your network requirements, practically, it may not matter to you how fast Portfast or BPDUGuard break formation of a L2 loop, assuming they always can. However, other networks, may want to be preclude any such possibility, and might never want to depend on either of those configuration commands, without knowing what to expect. There might also be a third kind of network requirements, that's willing to gamble, if you can provide actual probabilities.
So, from my perspective, the way to go is having both features turned on (each of them having different scopes, not that one or the other break the loop faster) and implicitly having the loop broken in time.
That's fine, but implicitly, the only advantage of using BPDUGuard, in your analysis is, you want to (for administrative reasons only) shut the port. I mean, your analysis is STP alone will (practically) be all that's needed to deal with accidental formation of a L2 loop and it protect the network.
As an aside, I don't ever recall having to personally deal with a production L2 accidental loop. That's not to say, firms I worked at never had any, they very occasionally would have one, but I wasn't involved with troubleshooting it, fixing it, or determining the reason why it came to be. I recall though, the loop was generally limited to a single (logical) L2 edge switch and its "parent" distro L3 switch. Root cause, in hindsight, would have been interesting, as, by standard, all edge ports were portfast, running pvst or rapid-pvst, but without BPDUGuard. I vaguely recall, though, the physical cause was inadvertently looping two of the same VLAN ports on the single logical edge L2 switch. (Do note, this was, decades ago, sort of when the original 3560/3750 were newly released, or when the 6500 sup might still be a sup1 or sup2.)
