[cisco-voip] QoS help

[Erick Wellnitz]

I've been able to track it down with CCM traces and doing some filtering
with translator x.

On Tue, Mar 20, 2012 at 12:26 PM, Wes Sisk <wsisk at cisco.com> wrote:

> the only way that comes to mind is checking the remote IP address. from
> the phone's perspective the remote IP would be the MTP if invoked.
> Otherwise it would be the gateway.
>
>  On Mar 20, 2012, at 10:38 AM, Erick Wellnitz wrote:
>
> I'm drawing a blank.  Am I able to tell what calls are hitting which MTP?
>
> On Mon, Mar 19, 2012 at 2:33 PM, Wes Sisk <wsisk at cisco.com> wrote:
>
>> so long as MRGL are correct and there is a capabilities match then yes.
>>
>>  On Mar 19, 2012, at 3:30 PM, Erick Wellnitz wrote:
>>
>> I'm going to eliminate our CM based software MTPs with n IOS software MTP.
>>
>> So, if I configure a trunk with the new MRGL, the trunk will use this to
>> allocate the MTP, correct?
>>
>> On Mon, Mar 19, 2012 at 1:20 PM, Wes Sisk <wsisk at cisco.com> wrote:
>>
>>> stated alternatively, does any phone colocated with ccm have any issues
>>> with vq when using software media resources such as MTP or CFB?  stream
>>> statistics from the phone (ii, ??, qrt, or cmr records) would help quantify
>>> any anomalies in the RTP stream.  If your CMR records show consistent poor
>>> audio at that remote site then you have a much stronger pointer to the
>>> culprit.
>>>
>>>
>>>  On Mar 19, 2012, at 11:56 AM, Erick Wellnitz wrote:
>>>
>>> CPU is bleow 20% on all nodes.  Network utilization isn't out of the
>>> ordinary either.
>>>
>>>
>>>
>>>
>>> On Mon, Mar 19, 2012 at 10:26 AM, Wes Sisk <wsisk at cisco.com> wrote:
>>>
>>>> generally you should deplete mtp resources before voice quality impact.
>>>> software MTP utilizes network I/O and CPU utilization. we've rarely seen VQ
>>>> issues caused by sw mtp/cfg but it's not unheard of. if you're using sw
>>>> media resources then verify the network interface for the CUCM server.
>>>>
>>>>  On Mar 16, 2012, at 3:03 PM, Erick Wellnitz wrote:
>>>>
>>>> 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
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120320/464b52a1/attachment.html>