From: Godswill Oletu (oletu@inbox.lv)
Date: Sun Jul 16 2006 - 10:41:03 ART
Lenny,
Queuing (any form of fair queue) voice traffic is a bad bad idea, voice is just intolerant of delay and putting it in a queue so that it can wait "patiently" for its shot at the transmit ring is asking for trouble. If priority queue is not allowed, though very strange, I will consider policing the voice traffic before thinking about queuing it.
With Policing, I will be banking on TCP (call setup) windowing to reduce sending rate & TCP retransmission to send another copy of the packet whenever my traffic is dropped. But once the traffic is queued, the sender will retransmit if it did not receive ACK from the receiver, now you have two duplicate packets waiting in the queue. The "longer" the queue the more the amount of extra duplicate packets waiting to leave and if/when all these extra packets gets accross, the receiver will be engaged for some time in dropping the extra packets. Though both policing & queuing voice traffic are evil twins, going with policing is kind of choosing the lesser evil.
However, this is the CCIE lab and every goes and anything is allowed.
If you have information about ip precedence & DSCP, it means classification & marking has been done for you already from some other part of the network. It might not be a good idea to assume that this has been done except where specifically stated.
So, if there is no information about ip precedence & DSCP, it is good to assume that, the task of doing classification (and marking if needed) rest squarely on your shoulders. For voice, it is good to match the H.225 call setup (TCP port 1720) and the RTP stream (UDP ports 16384 - 32767), so you will be looking at something like these to classify (and mark if needed):
class-map Voice
match access-group 101
match ip rtp 16384 16383
!
access-list 101 permit tcp host 1.1.1.1 any eq 1720
!
policy-map Voice
class Voice
set ip precedence 5
!
The last statement "set ip precedence 5" above is not needed, but it helps to mark the traffic and you can act on that marking on other routers without going through another lengthy classification.
The other alternative to using "match ip rtp 16384 16383" is to use an access list to match those udp ports. You can also use CAR, policing & PBR to mark your traffic.
Depending on the scenario, you can prioritize your voice traffic by using MQC legacy method or FRTS.
In a production network, I will assign the call setup to a different class and give it a lower priority, maybe a precedence of 3 is enough for the call setup protocol. The UDP RTP stream is more important, TCP have some inbuilt mechanism that equip it to survive congestion/packet dropping more than UDP.
HTH
Godswill Oletu
CCIE #16464
----- Original Message -----
From: "lenny lim" <lennylsl@yahoo.com>
To: <ccielab@groupstudy.com>
Sent: Sunday, July 16, 2006 3:09 AM
Subject: cbwfq with voice
> HI All,
>
> Sorry for asking this question as it may sound too simple for some of you but i still have to clear my doubts.
>
> If i am asked to do queuing for voice traffic, how should my class-map be configured? below are the options..
>
> 1) match ip dscp ef
> 2) match ip prec 5
> 3) match ip rtp 16384 16383'
> 3) match access-group name tcp1720 (acl with permit tcp any any eq 1720)
>
> I know that the first 2 options depend if the voice traffic is being classified somewhere else but that information is not given. So what would be the best way to match voice traffic.
>
> Appreciate all your help..
>
>
> ---------------------------------
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail Beta.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:47 ART