QoS question

Unanswered Question

I've set up some QoS for voip on one of our routers and I'm trying to figure out if it's working well or not. When I do a sh policy-map int fa0/1 (fa0/1 is our wan interface) I get this:


FastEthernet0/1


Service-policy output: VOIP


Class-map: VOIP (match-any)

5874312 packets, 1117621866 bytes

30 second offered rate 21000 bps, drop rate 0 bps

Match: ip precedence 6

98126 packets, 7294839 bytes

30 second rate 0 bps

Match: access-group 105

5749717 packets, 1104816650 bytes

30 second rate 21000 bps

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 240 (kbps) Burst 6000 (Bytes)

(pkts matched/bytes matched) 119803/24766098

(total drops/bytes drops) 0/0


Class-map: class-default (match-any)

76560769 packets, 16724285480 bytes

30 second offered rate 2571000 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 0/0/0


no drops or anything like that....it's a 3MB line though so the 30 sec offered rate for class-default is very close to the max which is fine. When I do a sh int fa 0/1 I get this:


Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 501451


which is showing output drops. Why would it show output drops when I do a sh int but when I do sh policy-map it doesn't show any drops?


here is the relevant configs:

access-list 105 permit ip any 10.13.6.0 0.0.0.255


class-map match-any VOIP

match ip precedence 6

match access-group 105


policy-map VOIP

class VOIP

priority 240

class class-default

fair-queue



interface FastEthernet0/1

bandwidth 3000

ip address 172.16.14.162 255.255.255.252

ip nbar protocol-discovery

rate-limit output access-group 110 200000 15000 18000 conform-action transmit e

xceed-action drop

ip route-cache flow

load-interval 30

speed 100

full-duplex

service-policy output VOIP

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joseph W. Doherty Tue, 04/01/2008 - 17:37
User Badges:
  • Super Bronze, 10000 points or more

You really don't want to use a rate limiter with your service policy. Try something like this:


(pseudo config)

policy-map parentShaper

class class-default

shape 3 (Mbps - I forget whether value is kbps or bps)

service-policy VOIP


interface FastEthernet0/1

bandwidth 3000

ip address 172.16.14.162 255.255.255.252

ip nbar protocol-discovery

ip route-cache flow

load-interval 30

speed 100

full-duplex

service-policy output parentShaper


The reason I have a rate limit in there is because there's an app that they run once in a while that eats up all the bandwidth for a few minutes, so I'm rate limiting that app to 200k so it doesn't interfere with everything else too much. Do you still think I should remove that limiter?


For shaping it's bps...so would it be something like this?


policy-map parentShaper

class class-default

shape peak 3000000

service-policy VOIP


or would it be shape average 3000000 ?

Joseph W. Doherty Tue, 04/01/2008 - 19:06
User Badges:
  • Super Bronze, 10000 points or more

I would use shape average.


For the app you're concerned about, you could try allowing it to fall into the FQ you have defined within your VOIP's class-default. FQ might manage it, if not, provide it its own class, also in the VOIP policy, and give it 1% bandwidth. That will allow it all excess bandwidth, but not impact (much) other traffic.

Ok I changed the config to look like this:


policy-map VOIP

class VOIP

priority 240

class hungryapp

bandwidth 200

class class-default

fair-queue

policy-map parentShaper

class class-default

shape average 2750000

service-policy VOIP



interface FastEthernet0/1

description 14-Wall-Yipes

bandwidth 3000

ip address 172.16.14.162 255.255.255.252

ip nbar protocol-discovery

ip route-cache flow

load-interval 30

speed 100

full-duplex

service-policy output parentShaper



Here is the output of sh policy-map int fa0/1:


FastEthernet0/1


Service-policy output: parentShaper


Class-map: class-default (match-any)

2392277 packets, 635036078 bytes

30 second offered rate 2700000 bps, drop rate 31000 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

2750000/2750000 16500 66000 66000 24 8250


Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 9 2377148 630705393 945044 333410957 yes


Service-policy : VOIP


Class-map: VOIP (match-any)

234285 packets, 48958171 bytes

30 second offered rate 192000 bps, drop rate 7000 bps

Match: access-group 105

234041 packets, 48940475 bytes

30 second rate 192000 bps

Match: ip precedence 5

0 packets, 0 bytes

30 second rate 0 bps

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 240 (kbps) Burst 6000 (Bytes)

(pkts matched/bytes matched) 91207/19044059

(total drops/bytes drops) 2469/524556


Class-map: hungryapp (match-any)

0 packets, 0 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group 105

0 packets, 0 bytes

30 second rate 0 bps

Weighted Fair Queueing

Output Queue: Conversation 137

Bandwidth 200 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 0/0

(depth/total drops/no-buffer drops) 0/0/0


Class-map: class-default (match-any)

2157992 packets, 586077907 bytes

30 second offered rate 2509000 bps, drop rate 26000 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 128

(total queued/total drops/no-buffer drops) 0/12659/0


According to this output the VoiP traffic has a good amount of drops which I'm trying to avoid. The line right now does look pretty saturated...but does that look right? Should I increase the bandwidth for on the VOIP class?

Joseph W. Doherty Wed, 04/02/2008 - 09:41
User Badges:
  • Super Bronze, 10000 points or more

Yes, increase the VOIP priority bandwidth allocation to avoid drops. Doesn't hurt (much) to be overly generous, bandwidth not used by voice available to other traffic.


If voice drops eliminated and if you bump into any voice quality issues, you might need to adjust the parent shaper's burst size (to reduce the measured time interval).

Ok...another question, hopefully the last!:)


FastEthernet0/1


Service-policy output: parentShaper


Class-map: class-default (match-any)

615571 packets, 143218775 bytes

30 second offered rate 1135000 bps, drop rate 47000 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

2750000/2750000 16500 66000 66000 24 8250


Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 573648 135529959 91406 51652873 no


Service-policy : VOIP


Class-map: VOIP (match-any)

15458 packets, 2975430 bytes

30 second offered rate 80000 bps, drop rate 0 bps

Match: access-group 105

15458 packets, 2975430 bytes

30 second rate 80000 bps

Match: ip precedence 5

0 packets, 0 bytes

30 second rate 0 bps

Weighted Fair Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 340 (kbps) Burst 8500 (Bytes)

(pkts matched/bytes matched) 2614/507521

(total drops/bytes drops) 0/0


Class-map: ssgbroadcast (match-any)

32989 packets, 47763234 bytes

30 second offered rate 421000 bps, drop rate 0 bps

Match: access-group 110

32989 packets, 47763234 bytes

30 second rate 421000 bps

Weighted Fair Queueing

Output Queue: Conversation 137

Bandwidth 200 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 27831/41740267

(depth/total drops/no-buffer drops) 0/11/0


Class-map: class-default (match-any)

567124 packets, 92480111 bytes

30 second offered rate 639000 bps, drop rate 47000 bps

Match: any

Weighted Fair Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 128

(total queued/total drops/no-buffer drops) 0/42043/0


class-map match-any VOIP

match access-group 105

match ip precedence 5

class-map match-any ssgbroadcast

match access-group 110

!

!

policy-map VOIP

class VOIP

priority 340

class ssgbroadcast

bandwidth 200

class class-default

fair-queue

policy-map parentShaper

class class-default

shape average 2750000

service-policy VOIP


Why does the class-default show so many more drops then the class ssgbroadcast? It shows ssgbroadcast using 421000bps, and the configured for 200k, so unless I'm wrong it should be dropping alot more from that class then the class-default class (which is only getting about 630k).

Joseph W. Doherty Wed, 04/02/2008 - 14:34
User Badges:
  • Super Bronze, 10000 points or more

Service-policy output: parentShaper


Class-map: class-default (match-any)

615571 packets, 143218775 bytes

30 second offered rate 1135000 bps, drop rate 47000 bps


Since your overall rate appears well under the shaper's value, it's curious there are active drops in child's class-default, unless some traffic is very bursty. Hard to tell what might help without seeing the traffic queued up. Try a peak shaper instead of the average shaper and/or try queue-limit 96 or 128 in the child's class-default, see if either makes a difference. (You might also try no fair-queue in the parent's class-default.)


On the question of ssgbroadcast vs. class-default drop ratios, two things to keep in mind, your ssgbroadcast isn't restricted to 200K it's provided a minimum of 200K. Second, what's the bandwidth allocation for class-default? These two factors can unexpectedly allow ssgbroadcast to grab bandwidth from class-default.


Some options for ssgbroadcast:


Don't provide ssgbroadcast its own class (if few flows in ssgbroadcast, allow FQ to sort them out in class-default)

Reduce ssgbroadcast bandwidth guarantee (even down to the minimum)

Add a policer or shaper to ssgbroadcast's class (e.g. provide minimum of 200K and shape to 200K)

Actions

This Discussion