Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

voice quality and 45xx QOS dbl feature ???


Anyone ever had problems with voice quality on VoIP with 4500 series switches and the qos dbl feature (which gets enabled by the auto qos feature)?? I have had a couple of customer complaining about voice quality and our voice team spent a lot of time investigating; I had ruled out the network infrastructure because it was all QOS enabled. The voip people came up against a blank so I looked at the network once more and disbaled dbl with hope more than anything else. Mysteriously the voice quality issues the customer was having have now disappeared.

Not sure whether a coincidence (though I have done this on two customers now) or something to with with dbl. There is nothing on this on cco.

Any ideas?

Thanks, Steve

Super Bronze

Re: voice quality and 45xx QOS dbl feature ???


The published QoS recommendations include using DBL - can you post the config you're using?

You should have the queue your voice traffic goes in marked as the priority queue, in which case the queue should be services at such a rate that DBL doesn't drop any packets...



Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
New Member

voice quality and 45xx QOS dbl feature ???

Just dont enable the DBL in the class where you put your voice traffic.

DBL tracks the queue length for each traffic flow in the switch. When the queue length of a flow exceeds its limit, DBL drop packets or sets the Explicit Congestion Notification (ECN) bits in the packet headers. The ECN bits are normaly set by the service provider, so your changing them makes no sence. On the other hand - enabling DBL in a class makes it susceptible to a packets being dropped (something like WRED, although not exactly).

Here´s how we have it in out network:

policy-map 1P7Q1T




bandwidth remaining percent 5


bandwidth remaining percent 30


bandwidth remaining percent 20


bandwidth remaining percent 10



bandwidth remaining percent 5


bandwidth remaining percent 20


class class-default

bandwidth remaining percent 10


Super Bronze

Re: voice quality and 45xx QOS dbl feature ???


The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.


Although you noted your network is AutoQoS enabled, this alone doesn't confirm it's correctly configured for your network or that your network traffic will work well with AutoQoS.  For example, is AutoQoS configuring a PQ for real-time traffic like VoIP?  (Likely it is.)  Is the selection for PQ based on L2 CoS or L3 ToS?  Is your VoIP bearer traffic marked with the correct L2 Cos or L3 ToS, that AutoQoS is using?  Are other network resources (e.g. bandwidth, buffering) what's need to adequately support your properly marked VoIP within the AutoQoS framework?  (BTW, did you know AutoQoS can generate different QoS based on its "vintage"?)

DBL is not a feature that should be needed nor used for VoIP traffic, especially bearer traffic.  I wouldn't expect any version of AutoQoS to enable it for real-time traffic (but I'm sometimes surprised).

4500 QoS features are "interesting".  They also vary based on sup and line cards combinations.

All the foregoing is just a long way of saying, AutoQoS isn't a panacea.  You many need to carefully review your end-to-end QoS requirements and make some revisions.