[cisco-voip] QoS help

[Erick Wellnitz]

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/7b1f3496/attachment.html>