10-04-2006 07:05 PM - edited 03-17-2019 08:49 PM
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
!
10-05-2006 03:13 AM
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
10-05-2006 05:04 PM
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,
10-06-2006 12:11 AM
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
10-05-2006 03:46 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide