Re: QOS for VOICE

If permitted then why not to use "permit udp any any range 16384 3276" and
use priority under policy-map.

On Fri, Jul 24, 2009 at 1:28 PM, Craig Miller
<ripperthejack2001_at_yahoo.com>wrote:

> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Jul 26 2009 - 14:03:56 ART