BPDU Guard

[Abdul salaam]

Hi

when we do enable port fast on access ports, it is recommended to enable BPDU guard and never connect portfast with other switch it causes ethernet loop.

How loop occurs ?

Thank you 

[MHM Cisco World]

temporally loop not permanent loop, 
loop happened because the port immediate for to FWD status instead of enter into STP elect process, 
but it temporally because after port (with portfast) detect BPDU it enter into STP elect process.  

[balaji.bandi]

when we do enable port fast on access ports  - this is always end device like PC / Phones example.

it is recommended to enable BPDU guard and never connect portfast with other switch it causes ethernet loop.  - sure this is suggested method for best practice.

How loop occurs ?  - Loop occurs may way , Like Loop in the network - example  2 have 2 outlet - if the user by mistake connect patch cable outlet 1 to outlet 2 - this cause loops.

[David Ruess · Accepted solution]

Hello,

Because port fast only transitions the port to forwarding immediately. It doesn't protect itself against BPDUs that could be sent on the port if connected to another switch.

-David

[TotallyTodd]

A loop could totally occur without bpdu guard enabled on a portfast enabled switch by skipping the convergence process and immediately sending a bpdu onto the network without spanning tree having enough time to negotiate the topology to account for the newly added switch meaning that there will be no ports transitioned to a blocking or alternate state on the newly added switch and this can cause a loop if more than one cable were connected to this device , especially something like a cheaper switch or hub totally.  Another risk mitigated by bpdu guard is the possibility of the network negotiating the newly added device as the root if the priority or bridge id were the same or lower by default which can cause sub-optimal traffic flow.  This security measure seems to be necessary to prevent changes for the network from others who aren't a part of the IT team, i guess people have totally brought devices from home and tried to plug them up or others who are more technologically inclined may have malicious intent.  Totally hope this helps! 

[Joseph W. Doherty · Accepted solution]

". . . recommended to enable BPDU guard . . ."

BPDU isn't as much for loop prevention, but to avoid an unexpected/unauthorized switch, doing something like taking over as your root switch for your L2 topology.  Since portfast is generally enabled only for access ports, where we don't expect there to be a connecting switch, we also wouldn't expect to see BPDUs such ports, but if you choose to not use portfast, you might still enable BPDU guard on edge ports.

". . . never connect portfast with other switch it causes ethernet loop."

Connecting a portfast configured port to another switch, doesn't alone, cause an Ethernet loop.  If fact, there's a portfast option for trunk ports.

"How loop occurs ?"

Within a L2 domain, you've somehow created a circular path.  I.e. starting/beginning with any switch, can you find a path that brings you back to the same (starting/beginning) switch?

For example, if you start with sw1<>sw2<>sw3<>sw4 and you interconnect sw1, ALSO, to sw1 (same device loop), sw2 (2nd time), or sw3 or sw4, you've created a loop.  You can create loops starting with the other switches too.

[Joseph W. Doherty]

Addendum:

"How loop occurs ?"

BTW, L2 loops can be intentional, to provide redundancy.  In prior example, sw1<>sw2<>sw3<>sw4, if we interconnect sw1 and sw4, we've created a loop and, for redundancy, a ring topology.  I.e. every switch has dual connections.

Problem is, Ethernet is not designed for rings (or loops).

This is where STP comes into play.  With it active, every time a port comes on-line, STP will FIRST determine if that port will create a loop.  If it does, STP, logically, precludes the loop.  I.e. in my example of sw1<>sw2<>sw3<>sw4, and connecting sw1 and sw4 together, one of the "ring's" links will not be used for data traffic.  It might be the newly added sw1<>sw4 connection, but perhaps one of the other connections will be logically broken by STP, and the new sw1<>sw4 connection used instead.  However, if one of the actively/logically used links actually breaks, STP will unblock the blocked link, restoring network connectivity!

The problem with STP, it takes some time to determine if a port coming on-line should be allowed.  As, in theory, edge ports, will not create loops, the portfast option bypasses this delay, so that the port comes on-line fast, hence the name, portfast.  The danger, though, is since STP analysis has been skipped, you risk creating an actual L2 loop.

As @MHM Cisco World mentions in his posting, if portfast "sees" BPDU, it will then start the full STP analysis, and, ideally, break any newly created L2 loop.  There's still a risk, because a L2 loop, in this situation, can overload switches so quickly, the newly formed loop is not broken by STP.  Here's where BPDU guard helps, if a BPDU is "seen", the port is disabled!  I.e. we're hoping, in this case, BPDU guard will break a newly created loop ASAP.  I believe, it reacts even faster than portfast/STP, but believe it too doesn't 100% guarantee a loop won't cause a problem.

These problems are why "best practices" encompass more than one recommendation for mitigation of possible problems.  Such as, current network designs lean more toward using L3, rather than massive L2 topologies.  I.e. if you bump into a L2 issue, it's (hopefully) bound to a smaller L2 topology that it impacts.

Also, although STP (preferable a rapid variant) is often recommended to keep enabled, for "just in case" ("accidental" loops), for intentional L2 redundancy, we might use Etherchannel, or REP, or something else.

[Abdul salaam]

Brilliant thank! I got it with some more details.