cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
417
Views
10
Helpful
4
Replies

where to apply qos

tunemore1
Level 1
Level 1

We have this:

src/dst---ORtr1---100Mbps---SPRtr---512kbps---Ortr2---T1---Ortr2---src/dst

Where should we apply qos? We don't have access to SPRtr(service provider) and here is sample config on our router 1 (Ortr1):

!

interface FastEthernet0/0

service-policy output OUR-POLICY

!

Class-map voice-signaling

match access-group 102

class-map voice-traffic

match access-group 101

!

policy-map OUR-POLICY

class voice-traffic

priority 64

class voice-signaling

bandwidth 16

class class-default

fair-queue

!

access-list 101 permit udp any any range 16384 32767

access-list 102 permit tcp any eq 1720 any

access-list 102 permit tcp any any eq 1720

!

4 Replies 4

mheusinger
Level 10
Level 10

Hi,

Qos should be applied to ORtr1 FE, ORtr2 512k, ORtr3 (?) T1.

On ORtr2 and ORtr3 - connected through T1 - you can use f.e. your posted policy.

The tricky one is ORtr1 and your policy will not work. The underlying reason is: you are configuring queueing and it will only be involved IF the physical interface is overloaded. This means that there should be more than 100 Mbps traffic before your config is involved. Obviously the problem occurs already if there is more than 512k.

The solution to the problem is called "nested policy". It would look like this taking your initial policy:

interface FastEthernet0/0

service-policy output Shape512k

!

Class-map voice-signaling

match access-group 102

class-map voice-traffic

match access-group 101

!

policy-map OUR-POLICY

class voice-traffic

priority 64

class voice-signaling

bandwidth 16

class class-default

fair-queue

!

policy-map Shape512k

class class-default

shape 500

service-policy output OUR-POLICY

access-list 101 permit udp any any range 16384 32767

access-list 102 permit tcp any eq 1720 any

access-list 102 permit tcp any any eq 1720

!

The policy Shape512k will only allow 500 kbps to pass through the F0/0 interface. Once this SHAPER is overloaded you apply the policy OUR-POLICY to prioritize voip.

The idea is never overload your SPRtr interface. Thus you should not shape to 512k exactly to account for OSI layer2 overhead.

Hope this helps! Please rate all posts.

Regards, Martin

Martin,

Thank much!

As you know, I cannot touch SP routers and trying qos on the edges(on our routers). Could packets be rearranged on SP routers?

Is there any better options without touching SP routers?

Can I do qos over GRE?

If yes, will it be any different?

Thanks again,

Hi,

GRE would not make any difference.

The reason is, that QoS addresses resource problems. This can only be done, where the resources are, i.e. where interfaces are, which potentially can be overloaded.

So there are two options:

1) apply the appropriate QoS to the potentially overloaded interfaces

2) avoid overload situations

The second point is what is leading to the nested policy approach. Basically you shape all traffic down to a rate, which avoids overloading the 512k interface in the SP router.

LFI should not be needed on this link, as the jitter is below 20 ms and the other network components will not introduce a considerable amount (T1 should be about 5 ms). So overall you are below 30 ms with respect to jitter and this is ok.

SP routers will not/should not rearrange the packets in a flow.

So with the config above you should be fine.

A few notes though:

Consider to use NBAR (match protocol rtp audio) instead of ACLs, because it avoids sorting ANY UDP traffic in the specified port range into your VoIP classes. You might get unwanted surprises with UDP data traffic trashing your VoIP.

In general I would also recommend you to read the Enterprise QoS SRND Guide.

Hope this helps! Please rate all posts.

Regards, Martin

tgautam
Cisco Employee
Cisco Employee

QoS should be enabled on all intermediate nodes in a VoIP environment. For the 512kbps WAN link, LLQ with LFI must be enabled in order to to prioritize VoIP traffic and to take care of serialization delay caused by large data packets. Since the outbound link on RTR1 to SP router is 100mbps there is no need to set PQ to 64kbps and other bandwidth commands on rtr1, it would make more sense to mark you VOIP traffic with appropriate dscp/ip precedence values on RTR1 and make sure SP router has QoS enabled and treats VoIP traffic with priority. And, as i mentioned earlier, SP router should configure LLQ with LFI for 512kbps link. Similary, since 512kbps link is terminating on OTR2, it should be setup properly with LLQ with LFI.

hth,

Tapan