[cisco-voip] QoS help

Erick Wellnitz ewellnitzvoip at gmail.com
Fri Mar 16 15:03:09 EDT 2012


This is unreal.  They tell me it's fixed and tested...but two hours later
we get more complaints.

These guys have me starting to doubt myself.  CM software MTP wouldn't be
causing QoS-like issues, would it?  What about if an SIP trunk with "MTP
required" checked and we run out of media resources?

On Fri, Mar 16, 2012 at 9:48 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>wrote:

> There was an incorrect QoS setting on a different switch on the remote
> end.  Problem solved.
>
> I'll save my gripes about groups not talking to each other for another
> day.  ;)
>
> On Thu, Mar 15, 2012 at 4:10 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>wrote:
>
>> I'm not a LAN/Ethernet QoS guru by any means.  Our network group has
>> control over QoS and I'm trying to get to the bottom of an issue we've seen
>> routing calls over a sip trunk to a location using a 1gig Ethernet
>> connection on a DWDM ring.  No firewall is present.  The configuration
>> doesn't seem quite right to me for some reason.
>>
>> Basically what we are doing is using an alternate PSTN gateway for toll
>> free traffic until we get additional capacity added to handle the calls.
>> Users report garbled audio and an 'underwater' quality of the audio.
>> Getting information from the phone on call quality (jitter, etc) may not
>> help because the calls complained about are to an external conference
>> bridge via tol lfree number.
>>
>> If this config checks out, I plan to ask the network team if they can
>> capture some data for this particular link.
>>
>>
>> Here is the local end QoS config:
>>
>>
>> mls ip cef load-sharing full
>>
>> mls netflow interface
>>
>> mls qos map cos-dscp 0 8 16 24 32 46 48 56
>>
>> mls qos
>>
>> mls cef error action reset
>>
>>
>>
>> interface GigabitEthernet3/43
>>
>> description GIG 3/43
>>
>> ip address X.X.X.X X.X.X.X
>>
>> ip flow ingress
>>
>> ip pim sparse-dense-mode
>>
>> ip summary-address eigrp 1 X.X.X  X X.X.X.X
>>
>> ip summary-address eigrp 1 X.X.X  X X.X.X.X
>>
>> ip summary-address eigrp 1 X.X.X  X X.X.X.X
>>
>> load-interval 30
>>
>> wrr-queue bandwidth 30 40 30
>>
>> wrr-queue queue-limit 40 30 15
>>
>> wrr-queue threshold 2 60 80 100 100 100 100 100 100
>>
>> wrr-queue threshold 3 60 80 100 100 100 100 100 100
>>
>> wrr-queue random-detect min-threshold 1 40 60 80 80 80 80 80 80
>>
>> wrr-queue random-detect max-threshold 1 70 80 100 100 100 100 100 100
>>
>> no wrr-queue random-detect 2
>>
>> no wrr-queue random-detect 3
>>
>> wrr-queue cos-map 1 3 0
>>
>> wrr-queue cos-map 2 1 1
>>
>> wrr-queue cos-map 2 2 2
>>
>> wrr-queue cos-map 2 3 4
>>
>> wrr-queue cos-map 3 2 3
>>
>> wrr-queue cos-map 3 3 6 7
>>
>> mls qos trust dscp
>>
>>
>>
>> Here is the remote end:
>>
>> interface GigabitEthernet1/36
>>
>> description GIGABIT E/NET 1/36
>>
>> ip address X.X.X.X  X.X.X.X
>>
>> ip flow ingress
>>
>> ip pim sparse-dense-mode
>>
>> load-interval 30
>>
>> no wrr-queue random-detect 2
>>
>> no wrr-queue random-detect 3
>>
>> wrr-queue cos-map 1 3 0
>>
>> wrr-queue cos-map 2 1 1
>>
>> wrr-queue cos-map 2 2 2
>>
>> wrr-queue cos-map 2 3 4
>>
>> wrr-queue cos-map 3 2 3
>>
>> wrr-queue cos-map 3 3 6 7
>>
>> mls qos trust dscp
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120316/83d8d8cd/attachment.html>


More information about the cisco-voip mailing list