Re: QoS quiz

From: Alexei Monastyrnyi <alexeim73_at_gmail.com>
Date: Mon, 20 Jun 2011 18:23:28 +1000

Carlos
I don't think this is the case.

In case of shaping buffer not empty the packet which is about to egress
would go into scheduler and based on its marking it would be placed into
the right queue, in you case in either LLQ or the class-default one. Now
if it is a voice packet scheduled for LLQ it will egress as soon as it
can regardless of class-default queue being full or not (well, up to the
priority XYZ value, where it will be policed, and we are not taking
serialization into account here as all is happening at FE speed).

So I reckon your voice traffic should be just fine. I may be missing
something so please correct me if I am wring.

Cheers
A.

On 6/18/2011 8:35 AM, Carlos G Mendioroz wrote:
> The problem with this configuration, which AFAIK is "by the book",
> is that it does not protect the Voip stream.
>
> If you have a data stream that is going over your shape rate,
> the shape buffer will be full and your voip traffic has to cross it!
> (Read, you will have jitter at best, lost packets more than likely)
>
> -Carlos
>
> David Prall @ 17/06/2011 18:49 -0300 dixit:
>> Carlos,
>> So I would do:
>> Class-map match-all voice
>> Match protocol rtp
>> Match dscp ef
>> Policy-map child
>> Class voice
>> Priority percent 25
>> Class class-default
>> Bandwidth remaining percent 100
>> Set dscp 0
>>
>> David
>>
>> --
>> http://dcp.dcptech.com
>>
>>
>>> -----Original Message-----
>>> From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar]
>>> Sent: Friday, June 17, 2011 5:40 PM
>>> To: David Prall
>>> Cc: 'Cisco certification'
>>> Subject: Re: QoS quiz
>>>
>>> Right.
>>> This is *one* thing I left out. All traffic should be marked.
>>> -Carlos
>>>
>>> David Prall @ 17/06/2011 18:31 -0300 dixit:
>>>> You are matching on RTP, is all RTP already marked EF? You are using
>>> shape
>>>> average to provide artificial back-pressure at 2Mbps. You have
>>> provided for
>>>> 500Kbps within the 2Mbps so you will be fine as long as the carrier
>>> is
>>>> providing priority for the RTP traffic, if they are providing
>>> priority for
>>>> EF then you need to confirm that the application is setting EF or
>>> remark the
>>>> traffic on your own to EF. You also need to confirm that the traffic
>>> that is
>>>> not RTP, is not marked EF, otherwise the SP will put it into their EF
>>> queue
>>>> along with your RTP EF traffic, so remarking the class-default to 0
>>> may help
>>>> here.
>>>>
>>>> David
>>>>
>>>> --
>>>> http://dcp.dcptech.com
>>>>
>>>>> -----Original Message-----
>>>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf
>>> Of
>>>>> Carlos G Mendioroz
>>>>> Sent: Friday, June 17, 2011 5:05 PM
>>>>> To: Cisco certification
>>>>> Subject: QoS quiz
>>>>>
>>>>> Easy one, I would think.
>>>>>
>>>>> Say you have a wan link provided over metro (i.e. access rate is
>>> well
>>>>> over your contracted BW) and you want to apply QoS to protect your
>>>>> Voip.
>>>>>
>>>>> You have 2Mbps contract, 25% limit on EF marked traffic.
>>>>>
>>>>> Will this config do the right thing (i.e. protect your voip traffic
>>>>> from jitter caused by your data) ?
>>>>>
>>>>> class-map voice
>>>>> match protocol rtp
>>>>>
>>>>> policy-map child
>>>>> class voice
>>>>> priority 500
>>>>> class class-default
>>>>> bandwidth remaining percent 100
>>>>>
>>>>> policy-map parent
>>>>> class class-default
>>>>> shape average 2000000
>>>>> service-policy child
>>>>>
>>>>> inferface fastEthernet0/0
>>>>> service-policy output parent
>>>>>
>>>>> --
>>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>>
>>>>>
>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>
>>>>>
>>> _______________________________________________________________________
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina

Blogs and organic groups at http://www.ccie.net
Received on Mon Jun 20 2011 - 18:23:28 ART

This archive was generated by hypermail 2.2.0 : Fri Jul 01 2011 - 06:24:28 ART