Re: QOS for VOICE

I would say that depends on other variables, the default precedence value for voice traffic is 5, so if you are trusting and mapping default values, than that would work just fine. It would be the same situation if you classified using the DSCP EF bit.

There really isn't enough information to say "this is the best way to do this".

--- On Fri, 7/24/09, Rameez Khan <rameezk1999_at_gmail.com> wrote:

> From: Rameez Khan <rameezk1999_at_gmail.com>
> Subject: Re: QOS for VOICE
> To: "Divin Mathew John" <divinjohn_at_gmail.com>
> Cc: "Craig Miller" <ripperthejack2001_at_yahoo.com>, "Ryan West" <rwest_at_zyedge.com>, "Molomo" <letjedilakopa_at_gmail.com>, "Cisco certification" <ccielab_at_groupstudy.com>
> Date: Friday, July 24, 2009, 10:21 AM
> 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 - 10:28:22 ART