Question about QoS for VOIP

[LingaringBell]

I've been reading about your basic QoS setup for VOIP on cisco IOS and I have a question. In the examples I tend to find they say to use a method similar to this:



For SIP/IAX/IAX2:
!signaling traffic
access-list 101 permit udp any any eq 4569
access-list 101 permit udp any any eq 5036
access-list 101 permit udp any any eq 5060
!
!RTP traffic
access-list 102 permit udp any any range 16384 32767
!
class-map match-all voice-traffic
match access-group 102
!
class-map match-all voice-signaling
match access-group 101
!
policy-map qos-voice
class voice-traffic
priority 240
class voice-signaling
bandwidth 16
class class-defult
fair-queue
!
interface FastEthernet0/0
service-policy output qos-voice
!
interface Serial0/0
rate-limit input 1408000 8000 8000 conform-action transmit exceed-action drop



My question is, why don't we use service-policy on the input interface as well as the output? Thanks.
-Bell

 

[jeter]

From the manual: Some actions might not be supported in both the input and output direction. CBWFQ can be performed only on packets EXITING the interface.

So the answer is you can place them on the input and output. It is determine by what you are trying to accomplish.

Go Army!
Tek-TIP Member 19,650

 

[LingaringBell]

Thanks, which manual are you looking at? Ok, so now I have more questions. I have two buildings connected by a T1 PTP. Building A has the phone controller. I've been having users in Building B complain about calls dropping and low bandwidth messages on their phone. I look at the QoS configs on the routers in each building (the original setup was done by my predecessor) and I am confused by a few of his decisions.

Building A Router:

interface FastEthernet0
service-policy output qos-voice
!
interface Serial0
rate-limit input 1408000 8000 8000 conform-action transmit exceed-action drop
!


Building B Router:
interface FastEthernet0
service-policy output qos-voice
!
interface Serial0
rate-limit input 1408000 8000 8000 conform-action transmit exceed-action drop
!
!


First - Why use the rate-limit at all? Since these routers are connected to each other, why not just use this on both:

interface FastEthernet0
service-policy output qos-voice


Second - Why not use:

interface Serial0
service-policy output qos-voice

instead of:

interface FastEthernet0
service-policy output qos-voice

Is there a difference between the two commands?

 

[lerdalt]

From your first posting I've had that config on a network and found a problem. TFTP traffic can match your acl 102.

I think the rate-limit was probably more of what some might consider and old school qos method. I definitely wouldn't have done the rate-limiting on the inbound direction like Jeter mentioned. I like to think of as you want to adjust the rate of traffic flow that you are putting on the wire. Much better to drop packets as they are outbound.

 

[jeter]

Have you thought about AutoQos?

Check out this web site.

http://www.cisco.com/en/US/tech/tk543/tk759/technologies_white_paper09186a00801348bc.shtml

Go Army!
Tek-TIP Member 19,650

 

[Caspiansails]

Typically the answer is it depends on whether you are marking input packets on the LAN interface or prioritizing, classifying and limiting on the WAN interface or both. If you are marking then you would in most cases also be classifying on the egress interface if you do both in a CE router. If you are only classifying you would apply the policy on the egress interface. If you are doing both you would have two policies and apply them appropriately.

I agree you don't see much done with rate-limiting unless your ISP is going to drop traffic if you exceed the BW purchased. In any event you want your voice traffic in the Class A queue and signaling in your class B queue. Data traffic that you may need to prioritize for various reasons such as traffic that is sensitive to delay can be put in a third queue and then everything else in the default queue. Pretty common use of the queues. Of course this depends on the ISP and how many queues they offer for QOS and any price points associated with it. I would keep only the voice packets in the high priority queue and signaling in a second queue though. You can use BW in the class maps to allocate BW per class.

I have used auto qos with limited success. If you know what you are doing and what your parameters are you have more control using a manual config. If you really don't have a good understanding auto qos should get you up and running and you can tweak it later.

 

[auglan]

Queueing can only be done in the outbound direction where policing can be down inbound or outbound.