Bpduguard not working for 'hardware' loops on the 4506E platform

[marce1000]

Platform : CAT4506E - Version 03.04.04.SG - (Sup 7L-E 10GE)

  - Is there any way to make bpduguard work on this platform, in case of hardware loops; (meaning connecting 2 ports to one another) - module platform WS-X4648-RJ45-E.

Although bpduguard is used in the IOS config, it does not work in this case, leaving to large impact on other switches when a network loop is made on this platform.

We have seen that bpduguard does work, on other platforms.

M.

[Leo Laohoo]

There are only two instances when BPDU Guard "did not" work.  And in both cases, the causes were "self-inflicted".  

By default, if you enable BPDU Guard (and ONLY enable BPDU Guard) it will work.  The only times I have seen it totally failed were the following: 

1.  Someone enables error-disable recovery on BPDU Guard errors. 

2.  Someone enables BPDU filter.  

Importance of BPDU Guard and BPDU Filter !!

[marce1000]

 >Someone enables error-disable recovery on BPDU Guard errors. 

Can I assume that if errdisable recovery is ued; the port will be immediately disabled
again after a recovery event AND the loop-condition is still there ?

M.

[Leo Laohoo]

When you enable error-disable recovery, the default timer is 300 seconds and the lowest timer you can set is 30 seconds. 

So if some numpty enabled this feature and set the recovery timer to 30 seconds ... you'll have a loop triggered one every 30 seconds.  

This is the main reason why I am really, really against error-disable recovery for BPDU and UDLD.   This is a recipe for disaster for some people who really don't know what they are doing.

[marce1000]

 Perhaps not if you use  errdisable recovery as a fallback mechanism  and use 'large timers' only. In our case we had 'to walk' to switches far away to 'reset' them after the loop was corrected.

M.

[Leo Laohoo]

No, I disagree. 

Error-disable recovery has a place.  In a lab, maybe.  But I will never use this method in full-scale production.  Why?  Because you could potentially bring your network down.  Let me explain ... 

A few months ago, we had a brand-spanking-new 6800 chugging away.  Then one early morning (4 am), a fibre link between two core links went down due to UDLD.  Being two core switches, we had BGP running.  So when one (of the two links) went down, BGP convergence went all over the place.  But the switch remained intact.  Unfortunately, some inept person enabled error-disable recovery on UDLD faults.  After 300 seconds later, the links went up.  Guess what happened?  Because the links went up, BGP went into another "state" of convergence which eventually forced the chassis to its knees and crashed.  

Fortunately for me, this is not the first time I've seen a case like this.  This won't be the last time either.  

Error-disable of ports, let it be BPDU guard or UDLD, etc., is a FRIEND and not an enemy.  Treat your friend well and you'll be rewarded.  Treat "error-disable" like a plague and you'll be sorry.  

Peter, where are you?  Happy to hear your opinion.  :)