Re: QOS for VOICE

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 - 13:38:17 ART