Policy-Map priority traffic

Unanswered Question
Apr 14th, 2009

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (4 ratings)
Loading.
Joseph W. Doherty Wed, 04/15/2009 - 04:07

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.

johnelliot6 Wed, 04/15/2009 - 14:17

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

thotsaphon Wed, 04/15/2009 - 14:41

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

Joseph W. Doherty Wed, 04/15/2009 - 14:41

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.

thotsaphon Wed, 04/15/2009 - 14:55

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

johnelliot6 Wed, 04/15/2009 - 15:19

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!

Joseph W. Doherty Thu, 04/16/2009 - 03:50

"(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.

johnelliot6 Thu, 04/16/2009 - 19:50

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.

Joseph W. Doherty Fri, 04/17/2009 - 02:56

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.

Actions

This Discussion