Re: QOS for VOICE

Dear Divin,

class-map VOICE
match ip precedece 5

This will classify only packets already marked with precedence value of 5!

If the Incoming packets are un-marked then? and you need to classify voice
packets? i think "match ip rtp 16384 16383 or match protocol rtp audio" will
best fit in that scenario?

What do you say?

On Fri, Jul 24, 2009 at 11:08 AM, Divin Mathew John <divinjohn_at_gmail.com>wrote:

> Use MQC
>
> class-map VOICE
> match ip precedece 5
>
> policy-map ABC
> clas VOICE
> priority 30% -- PRIORITY Low LAtency
> class SQL
> bandwidth 15% CBWFQ
>
> Sent from Bangalore, KA, India
>
> On Thu, Jul 23, 2009 at 9:57 PM, Craig Miller <ripperthejack2001_at_yahoo.com
> > wrote:
>
>>
>> I'm a bit ocnfused as to what you just said. Are you saying you would run
>> PQ (Priority Queueing) IE: priority-list 1 <arguments> for voice then apply
>> a CBWFQ?
>>
>> I don't think I've ever tried to put a priority-group and service-policy
>> on an interface together... Does that work?
>>
>> I don't think you can assign two types of queues to an interface, but I
>> would be happy to see it work. Essentially you would be assigning the 4
>> queues from PQ, nd the 64 for CBWFQ.
>>
>> Or it might be a misunderstanding of what the "priority percent" command
>> does. It enables LLQ within an MQC (more specifically CBWFQ), which is used
>> for strict policing.
>>
>> Craig
>>
>> --- On Thu, 7/23/09, Divin Mathew John <divinjohn_at_gmail.com> wrote:
>>
>> > From: Divin Mathew John <divinjohn_at_gmail.com>
>> > Subject: Re: QOS for VOICE
>> > To: "Craig Miller" <ripperthejack2001_at_yahoo.com>
>> > Cc: "Ryan West" <rwest_at_zyedge.com>, "Molomo" <letjedilakopa_at_gmail.com>,
>> "Rameez Khan" <rameezk1999_at_gmail.com>, "Cisco certification" <
>> ccielab_at_groupstudy.com>
>> > Date: Thursday, July 23, 2009, 10:52 AM
>> > LLQ will be goo.! PQ for Voice and
>> > CBWFQ for other traffic~!
>> >
>> > On Thu, Jul 23, 2009 at 9:17 PM,
>> > Craig Miller <ripperthejack2001_at_yahoo.com>
>> > wrote:
>> >
>> >
>> > Also, if you match the RTP protocol
>> > data, make sure that cef is enabled.
>> >
>> >
>> >
>> > Alternatively, you can also match incoming DCSP EF bits as
>> > an option.
>> >
>> >
>> >
>> > And as Molomo suggested, change bandwidth to priority for
>> > strict policing / LLQ.
>> >
>> >
>> >
>> > Craig
>> >
>> >
>> >
>> > --- On Thu, 7/23/09, Molomo <letjedilakopa_at_gmail.com>
>> > wrote:
>> >
>> >
>> >
>> > > From: Molomo <letjedilakopa_at_gmail.com>
>> >
>> > > Subject: Re: QOS for VOICE
>> >
>> > > To: "Ryan West" <rwest_at_zyedge.com>
>> >
>> > > Cc: "Rameez Khan" <rameezk1999_at_gmail.com>,
>> > "Cisco certification" <ccielab_at_groupstudy.com>
>> >
>> > > Date: Thursday, July 23, 2009, 10:19 AM
>> >
>> > > Given the fact that
>> > this is voice, I
>> >
>> > > would gaurantee voice and also
>> >
>> > > strict police it, ie I would use priority percent 40
>> >
>> > >
>> >
>> > >
>> >
>> > >
>> >
>> > > On 7/23/09, Ryan West <rwest_at_zyedge.com>
>> >
>> > > wrote:
>> >
>> > > > Rameez,
>> >
>> > > >
>> >
>> > > > In the scope of the lab, your approach is not too
>> > far
>> >
>> > > off. Don't forget
>> >
>> > > > that an access will work just the same with a UDP
>> > port
>> >
>> > > range. The more
>> >
>> > > > sophisticated matching techniques that you listed
>> > are
>> >
>> > > just that, they aren't
>> >
>> > > > relying on ranges of ports, but the underlying
>> > payload
>> >
>> > > contained within a
>> >
>> > > > particular RTP packet, in your case payloads
>> >
>> > > 0-23. Also note that the port
>> >
>> > > > range of 16384 to 32767 is very Cisco centric,
>> > other
>> >
>> > > vendors may choose
>> >
>> > > > ranges lower or as high as 65535. With as much
>> >
>> > > focus as the R&S has on
>> >
>> > > > voice still (not very much), vendor workbooks
>> > don't
>> >
>> > > seem to concern
>> >
>> > > > themselves with the most common type of voice
>> > traffic,
>> >
>> > > trusted pre-marked
>> >
>> > > > packets from endpoints. So, in the real world
>> >
>> > > you would probably be queuing
>> >
>> > > > of DSCP 46 / CoS 5 (assuming your cos-dscp maps
>> > have
>> >
>> > > been properly
>> >
>> > > > configured) and providing a guaranteed bandwidth
>> > for
>> >
>> > > DSCP 26 / CoS 3.
>> >
>> > > >
>> >
>> > > > Signaling can take on many more forms than just
>> > H323
>> >
>> > > as well, so you would
>> >
>> > > > want to include SCCP and SIP as well, based on
>> > the
>> >
>> > > requirements of the task.
>> >
>> > > > You are correct on the retransmission aspects,
>> >
>> > > if a portion of a phone call
>> >
>> > > > is lost its lost. I hope I haven't
>> > complicated
>> >
>> > > the situation too much. I
>> >
>> > > > think the main focus is take in what they are
>> > asking
>> >
>> > > in the question and
>> >
>> > > > come up with best possible solution and there are
>> > a
>> >
>> > > ton of ways to configure
>> >
>> > > > QoS. Don't lock yourself into just ip rtp
>> > audio
>> >
>> > > or classification using
>> >
>> > > > nBAR, be vaguely familiar with them all.
>> >
>> > > >
>> >
>> > > > Here is the white paper I was referencing:
>> >
>> > > >
>> >
>> > > >
>> http://www.cisco.com/en/US/products/ps6616/products_white_paper09186a0080110040.shtml
>> >
>> > > >
>> >
>> > > > -ryan
>> >
>> > > >
>> >
>> > > > -----Original Message-----
>> >
>> > > > From: nobody_at_groupstudy.com
>> >
>> > > [mailto:nobody_at_groupstudy.com]
>> >
>> > > On Behalf Of
>> >
>> > > > Rameez Khan
>> >
>> > > > Sent: Thursday, July 23, 2009 6:24 AM
>> >
>> > > > To: Cisco certification
>> >
>> > > > Subject: QOS for VOICE
>> >
>> > > >
>> >
>> > > > I want to confirm my approach for QOS over
>> >
>> > > VOICE.
>> >
>> > > >
>> >
>> > > > If i come across a question in CCIE R/S lab exam
>> >
>> > > asking to Gaurantee 40% of
>> >
>> > > > banwidth for VOICE Traffic, i would use the
>> > following
>> >
>> > > solution :
>> >
>> > > >
>> >
>> > > > First, i will classify RTP VOICE payload packets
>> >
>> > > either by:
>> >
>> > > >
>> >
>> > > > match ip rtp 16384 16383 ----> This will match
>> > all
>> >
>> > > the EVEN UDP ports in
>> >
>> > > > the range 16384 - 32767 ( It does NOT classify
>> > RTCP
>> >
>> > > 1720)
>> >
>> > > >
>> >
>> > > > or
>> >
>> > > >
>> >
>> > > > match protocol rtp audio ----- > this
>> >
>> > > will serve the same funcionality as
>> >
>> > > > of "match ip rtp 16384 16383"
>> >
>> > > >
>> >
>> > > > Then, i will apply policy map to the VOICE
>> > class-map
>> >
>> > > by using "bandwidth
>> >
>> > > > percent 40"
>> >
>> > > >
>> >
>> > > > lastly, i will appy the Service Policy in the
>> >
>> > > appropriate directon.
>> >
>> > > >
>> >
>> > > > Please note that i am not classifying RTCP port
>> >
>> > > 1720(TCP Port) for VOICE as
>> >
>> > > > its a TCP port and it will get Reliable service
>> > by
>> >
>> > > Acknowledgment,
>> >
>> > > > Re-transmission in case if there is Drop.
>> >
>> > > >
>> >
>> > > > But the Voice Payload traffic is UDP, and there
>> > is no
>> >
>> > > benefit of
>> >
>> > > > retransmission for dropped packets. Thats the
>> > reason i
>> >
>> > > Classify and
>> >
>> > > > Gaurantee Bandwidth to VOICE Payload Packets.
>> >
>> > > >
>> >
>> > > > Please give me feedback if my approach is valid?
>> >
>> > > >
>> >
>> > > > Also, suggest if there is any need to classify
>> > and
>> >
>> > > gaurantee bandwitch to
>> >
>> > > > RTCP 1720 traffic??
>> >
>> > > >
>> >
>> > > >
>> >
>> > > > Blogs and organic groups at http://www.ccie.net
>> >
>> > > >
>> >
>> > > >
>> >
>> > >
>> > _______________________________________________________________________
>> >
>> > > > Subscription information may be found at:
>> >
>> > > > http://www.groupstudy.com/list/CCIELab.html
>> >
>> > > >
>> >
>> > > >
>> >
>> > > > Blogs and organic groups at http://www.ccie.net
>> >
>> > > >
>> >
>> > > >
>> >
>> > >
>> > _______________________________________________________________________
>> >
>> > > > Subscription information may be found at:
>> >
>> > > > http://www.groupstudy.com/list/CCIELab.html
>> >
>> > >
>> >
>> > >
>> >
>> > > Blogs and organic groups at http://www.ccie.net
>> >
>> > >
>> >
>> > >
>> > _______________________________________________________________________
>> >
>> > > Subscription information may be found at:
>> >
>> > > http://www.groupstudy.com/list/CCIELab.html
>> >
>> >
>> >
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> >
>> >
>> > _______________________________________________________________________
>> >
>> > Subscription information may be found at:
>> >
>> > http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Jul 24 2009 - 18:21:29 ART