cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1389
Views
0
Helpful
2
Replies

BPDU Guard Errdisable Recovery and DBL Drops

Andrew Devine
Level 1
Level 1

Hi,

Had a strange issue where we had some Avaya IP Phones dropping off the network (losing DHCP IP) which I tracked down to an issue caused by an IP Phone causing an STP loop.

Often in meeting rooms uneducated users patch the IP Phone downlink cable back into spare network ports that are part of the meeting room which creates a loop due to the mini-switch that is part of the IP Phone.

BPDU Guard picks this up and disables the port, but I had also configured errdisable recovery so we don't end up with lots of dead ports.  During this period of recovery, which tempoariliy creates a loop until BPDU Guard disables the ports, I was seeing massive drops on the majority of interfaces on the 4500E switch.  These drops were predominantly Belligerent Flow Drops (Dbl-Drops-Queue-8) in the class-default class which has DBL applied (we are running AutoQos on the WS-X45-SUP7-E).

I guess QoS picks up this traffic and drops it as a safety mechanism for the voice traffic. 

Anybody seen this behavour before?

I have disabled errdisable recovery in the meantime which has stopped the drops, but means more manual work to re-enable dead ports after user patching errors.  Any other workarounds?

Cheers,

Andrew

2 Replies 2

pille1234
Level 3
Level 3

Hi Andrew,

I never thought this could become a problem at all. BPDU-Guard should disable the port within max 2 seconds, at least with RSTP. A weird solution would be to reduce the hello timer, however I have no experince with that and even Cisco states "Exercise care when using this command.", so I guess this could possibly create alot worse problems than a few dropped frames. How about disabling portfast on the VoIP-ports? This way BPDU-Guard should have disabled the port long before it transitions into forwarding mode, right?

Best Regards

Pille

Hi Pille,

Yes it's a strange one, but those couple of seconds seem to cause the QoS policy on the port to drop a lot of traffic.

The problem usually occurs in meeting rooms where the desk has a bank of ports built in, and perhaps an IP phone or two plugged in with some loose downlink cables.  The users then seem to like plugging these back into the desk port.  We don't really want to disable portfast on the ports designed for users laptops though...

Perhaps the answer is to remove the phone downlink cables, if we leave loose cables on the desk they usually get taken home though.

Andrew

Review Cisco Networking products for a $25 gift card