Re: QOS for VOICE

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 Thu Jul 23 2009 - 09:27:25 ART