04-14-2009 05:48 PM - edited 03-04-2019 04:21 AM
Hi,
I have the following configured on an 1841 w/ 6Mb Eth wan connection - Existing acl is simply there to test qos.
class-map match-any PriorityTraffic
match access-group name VOIP-PORTS
!
!
policy-map PriorityTrafficPolicy
class PriorityTraffic
priority 512
class class-default
police rate 5632000
fair-queue
interface FastEthernet0/1/0
ip address 10.2.6.74 255.255.255.252
duplex auto
speed auto
service-policy output PriorityTrafficPolicy
ip access-list extended VOIP-PORTS
remark ICMP
permit icmp any any
acl is getting hits:
#sh access-lists VOIP-PORTS
Extended IP access list VOIP-PORTS
10 permit icmp any any (990 matches)
but we see no improvement in latency when the 6Mb eth is under load - We were hoping that the above would "reserve" 512K for icmp traffic, and restrict all other traffic to 5.5M - Is icmp a poor choice to confirm the above is going to do what we expected?
#sh policy-map interface
FastEthernet0/1/0
Service-policy output: PriorityTrafficPolicy
Class-map: PriorityTraffic (match-any)
228 packets, 26460 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name VOIP-PORTS
228 packets, 26460 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 512 (kbps) Burst 12800 (Bytes)
(pkts matched/bytes matched) 26/2776
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
98994 packets, 23863963 bytes
5 minute offered rate 264000 bps, drop rate 0 bps
Match: any
police:
rate 5632000 bps, burst 176000 bytes
conformed 98885 packets, 23810314 bytes; actions:
transmit
exceeded 46 packets, 46972 bytes; actions:
drop
conformed 297000 bps, exceed 0 bps
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
04-15-2009 04:07 AM
In theory, what you're doing should work. In practice, there are many reasons why you might not be seeing a difference. For starters, much depends what you mean by "under load". Your posted stats don't, I believe, show enough of a load that you might not see the effect.
Other issues could be your policer's Bc size, tx-ring size, and/or Ethernet L2 overhead.
Take note under your class stats for the LLQ, 26 of 228 packets matched. Which means only those 26 saw enough congestion to be LLQ'ed. Since you're trying to reserve enough bandwidth that LLQ won't be needed, it failed.
PS:
BTW, normally a hiearchal policy would be the method of choice. This would insure your total traffic is manage with regard to available bandwidth, yet not set aside bandwidth for something like VoIP that can't otherwise be used if it's available.
04-15-2009 02:17 PM
Thanks for the response - "Under load"...service is doing 5Mb+ (5 minute averages)
The actual goal is to run voip between 2 networks - 1 2Mb SHDSL, the other 6Mb eth
What is considered "best pratice" to reserve bandwidth for voip, to ensure it has adequate bandwidth to operate Optimally?
Will the config in place currently, allow the "class-default" traffic to utilise the entire 6Mb(If priority traffic is no seen), or should I remove the "police rate 5632000"?
Should I also apply the service-policy egress on LAN Int for inbound traffic from WAN?
Thanks
04-15-2009 02:41 PM
John,
You applied QOS to Fastethernet-100Mbps. It's not easy to make this interface to get congestion.
What about shaping?
!
ip access-list extended VOIP-PORTS
remark ICMP
permit icmp any any
!
!
policy-map PriorityTrafficPolicy
class PriorityTraffic
priority 512
class class-default
fair-q
!
policy-map Shape6M
class class-default
shape average 6000000
service-policy output PriorityTrafficPolicy
!
interface FastEthernet0/1/0
service-policy output Shape6M
!
Do you really want to test this by using ICMP? Well, Let's use bandwidth more than 6M first. Then use the show command to see.
Toshi
04-15-2009 02:41 PM
re: best practice
Something like:
policy-map 6mb
class class-default
shape average 5250000
service-policy childpolicy
policy-map childpolicy
class VoIP
priority percent 30
class class-default
fair-queue
interface FastEthernet x
service-policy output 6mb
Notes:
Shaper is set about 15% slower than nomimal link bandwidth to allow for L2 Ethernet overhead. It might be adjusted up/down depending on average frame size.
Shaper's Bc might need to be adjusted down. 10 ms is often a good value.
Adjust the proportion of LLQ bandwidth to handle your VoIP bearer traffic.
You may need to also treat VoIP signally special, but the FQ might suffice.
"Should I also apply the service-policy egress on LAN Int for inbound traffic from WAN? "
Usually offers little benefit for inbound WAN. What you do want, is QoS configured on other sides's WAN outbound.
04-15-2009 02:55 PM
It's not easy to see 2 posts at the exact same time. F.e. 3:41pm
Joseph, Your post gives us accurate information.
5P!
Toshi
04-15-2009 03:19 PM
Thanks very much!
This is what I now have(I added telnet to acl for testing also):
class-map match-any VOIP
match access-group name VOIP-PORTS
!
!
policy-map childpolicy
class VOIP
priority percent 30
class class-default
fair-queue
policy-map 6mb
class class-default
shape average 525000
service-policy childpolicy
ip access-list extended VOIP-PORTS
remark ICMP
permit icmp any any
remark TELNET
permit tcp any any eq telnet
interface FastEthernet0/1/0
service-policy output 6mb
(Will the above allow class-default to hit links capacity, if no "VOIP" traffic is seen?)
#sh policy-map interface
FastEthernet0/1/0
Service-policy output: 6mb
Class-map: class-default (match-any)
25438 packets, 4402010 bytes
5 minute offered rate 113000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
525000/525000 3150 12600 12600 24 1575
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 25438 4402010 7741 2630481 no
Service-policy : childpolicy
Class-map: VOIP (match-any)
88 packets, 9294 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group name VOIP-PORTS
88 packets, 9294 bytes
5 minute rate 1000 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 30 (%)
Bandwidth 157 (kbps) Burst 3925 (Bytes)
(pkts matched/bytes matched) 19/2235
(total drops/bytes drops) 0/0
Class-map: class-default (match-any)
25350 packets, 4392716 bytes
5 minute offered rate 112000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/0/0
I still see large fluctuations in latency (Link is only doing ~3-4Mb/sec):
(NB - This is to next hop - 7204 w/NPEG2 with 10% load)
#ping 10.2.6.73
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.6.73, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
#ping 10.2.6.73
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.6.73, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 168/177/184 ms
Perhaps the Eth suppliers 6Mb policer is extremely harsh?
Thanks again for your assistance, extremely helpful!
04-16-2009 03:50 AM
"(Will the above allow class-default to hit links capacity, if no "VOIP" traffic is seen?) "
Yes. (Actually, in this case, up to parent policy's shaped value.)
It looks like the shaper has defaulted to about 24 ms Tc, so you might adjust the next parameter to decrease the Bc size. (The very latest IOSs also allow, I believe, to define Tc directly in ms.)
As to the variable latency, what's the QoS for the other side? In other words, ping and/or telnet also likely need same priority for return packets. If not, the variable latency could be due to their delay.
You might also try "tx-ring-limit 2" on the outbound interface.
"Perhaps the Eth suppliers 6Mb policer is extremely harsh? "
I doubt they're using a policer (if they did, you would likely notice drops). Biggest concern should be QoS treatment for inbound packets (on other side's outbound), but there are many issues that can arise with WAN provider. (Such as they don't really deliver what they guarantee.)
PS:
BTW, on your class map, you can also use, I believe, "match protocol telnet" without needing to define a ACL. Don't recall whether SNMP is a known protocol too.
04-16-2009 07:50 PM
Thanks again for your detailed response - Most informative!
One last question - If wanting to apply service-policy such as this to DSL router, that utilises dialer Int, would I apply the "childpolicy" to dialer int(As attempting to apply the "6mb" policy results in "(config-if)#service-policy output 6mb
GTS : Not supported on this interface"
Thanks again.
04-17-2009 02:56 AM
For hierarchal polices, you apply the parent policy, not the child.
I haven't tried such a policy on a "dialer" interface, so it's possible it's not supported. (I also have very little experience working with dialer interfaces, and don't recall whether there's another underlying physical interface you might be able to apply the policy to.)
If the router refuses the policy, two options that come to mind are: going back to what you were trying origianlly with a policer or using a very recent 12.4T IOS. The latter, starting with 12.4(20)T provides many enhancements, some I recall deal with working on interface types that weren't previously supported.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: