Re: Shaping vs. Policing

chris.notley · ‎09-23-2012

police rate 400000

exceed-action drop

Hi there,

I have been trying to configure shaping with minimal success on a router with a ADSL/dialer interface. I am trying to reserve a certain amount of bandwidth for certain traffic types (defined by an ACL). I initially started using policing as per below (the 100Kbps was initially just used for testing):

class-map match-any CLASS-HIGH

match access-group 2000

!

policy-map QOS-DEFAULT

class CLASS-HIGH

priority 150

class class-default

police rate 100000

exceed-action drop

!

interface Dialer10

service-policy output QOS-DEFAULT

!

This worked - traffic other than that defined in ACL 2000 was capped at 100kbps. I then tried changing the class-default configuration from police to shape as follows:

policy-map QOS-DEFAULT

class CLASS-HIGH

priority 150

class class-default

shape average 100000

This appeared not to buffer any traffic - running the command 'show policy-map interface dialer 10' after 10-15 minutes showed the following:

Dialer10

Service-policy output: QOS-DEFAULT

queue stats for all priority classes:

queue limit 64 packets

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

(pkts output/bytes output) 0/0

Class-map: CLASS-HIGH (match-any)

191 packets, 25612 bytes

5 minute offered rate 1000 bps, drop rate 0 bps

Match: access-group 2000

191 packets, 25612 bytes

5 minute rate 1000 bps

Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0

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

20639 packets, 29885658 bytes

5 minute offered rate 557000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 packets

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

(pkts output/bytes output) 0/0

shape (average) cir 100000, bc 2500, be 2500

target shape rate 100000

I am sure I am just missing really obvious - having looked through various cisco articles and posts here, I thought I could use shaping to restrict the rate of an interface...

Any feedback would be appreciated.

Regards,

Chris

Joseph W. Doherty · ‎09-23-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I believe the "offered rate" is the ingress rate seen by the class, not the same as the egress rate.

What your corresponding stats look like for overall egress rate on the physical interface?

chris.notley · ‎09-23-2012

Hi both,

Thanks for your responses. I've now switched back to policing and didn't gather the atm stats before. I will kick it off again shortly and respond here.

In regard to Olivier's statement regarding 'traffic to the dialer before the shaping'; this makes sense, but given that the rate is significantly higher than the targeted shaped rate, would I not expect to see some indication of queuing? I kicked off an rsync job each time I amended the configuration, which is not matched by ACL 2000, hence it should be being shaped?

On the one hand, I know the policing is working, I'm just a little bugged as to why shaping just doesn't seem to happen at all.

Regards,

Chris

zheng.olivier · ‎09-23-2012

load-interval 30 on the dialer 10.

(you're looking stats over last 5 min)

zheng.olivier · ‎09-23-2012

the offered rate is the data rate in input of the policy map. In your case, there are 557kbps traffic to the dialer before the shapping.

Sent from Cisco Technical Support iPad App

chris.notley · ‎09-24-2012

Hi again,

So I've re-applied the shaping policy and added the load interval as suggested. I've pasted below the relevant section (as well as including the details of the high priority ACL for reference) below:

class-map match-any CLASS-HIGH

match access-group 2000

!

policy-map QOS-DEFAULT

class CLASS-HIGH

priority 150

class class-default

shape average 100000

!

access-list 2000 remark *** VOIP TRAFFIC ***

access-list 2000 permit udp host 1.2.3.4 any eq 4569

access-list 2000 permit udp host 1.2.3.4 any eq 5060

access-list 2000 permit udp host 1.2.3.4 range 18000 18999 any

!

interface Dialer10

load-interval 30

service-policy output QOS-DEFAULT

!

I then kicked off an rsync session (uploading traffic through the dialer interface) and after approx five minutes ran the command 'show policy-map interface dialer 10', the output of which is below:

Dialer10

Service-policy output: QOS-DEFAULT

queue stats for all priority classes:

queue limit 64 packets

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

(pkts output/bytes output) 0/0

Class-map: CLASS-HIGH (match-any)

228 packets, 28806 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group 2000

228 packets, 28806 bytes

30 second rate 0 bps

Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0

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

14047 packets, 19312173 bytes

30 second offered rate 862000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 packets

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

(pkts output/bytes output) 0/0

shape (average) cir 100000, bc 2500, be 2500

target shape rate 100000

Immeditately afterwards I ran the command 'show interface atm 0/0/0', the output of which is pasted below:

ATM0/0/0 is up, line protocol is up

Hardware is HWIC-DSLSAR (with Alcatel ADSL Module), address is 0026.9957.4514 (bia 0026.9957.4514)

MTU 4470 bytes, sub MTU 4470, BW 956 Kbit/sec, DLY 530 usec,

reliability 255/255, txload 227/255, rxload 6/255

Encapsulation ATM, loopback not set

Keepalive not supported

Encapsulation(s): AAL5

23 maximum active VCs, 256 VCs per VP, 1 current VCCs

VC Auto Creation Disabled.

VC idle disconnect time: 300 seconds

Last input never, output 00:00:00, output hang never

Last clearing of "show interface" counters never

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

Queueing strategy: Per VC Queueing

30 second input rate 23000 bits/sec, 46 packets/sec

30 second output rate 854000 bits/sec, 75 packets/sec

32530116 packets input, 1280223521 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 7808 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

34688778 packets output, 366613440 bytes, 0 underruns

3 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

This seemed to confirm my feeling that the shaping was not taking effect, but to verify I then reverted to a policing from shaping, as per the following:

policy-map QOS-DEFAULT

class CLASS-HIGH

priority 150

class class-default

police rate 100000

exceed-action drop

I then kicked off the same rsync session again and after a few minutes ran the command 'show policy-map interface dialer 10', the output of which is below:

Dialer10

Service-policy output: QOS-DEFAULT

queue stats for all priority classes:

queue limit 64 packets

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

(pkts output/bytes output) 0/0

Class-map: CLASS-HIGH (match-any)

341 packets, 42030 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group 2000

341 packets, 42030 bytes

30 second rate 0 bps

Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0

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

4473 packets, 5150577 bytes

30 second offered rate 210000 bps, drop rate 134000 bps

Match: any

queue limit 64 packets

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

(pkts output/bytes output) 0/0

police:

rate 100000 bps, burst 3125 bytes

conformed 2255 packets, 1916405 bytes; actions:

transmit

exceeded 2213 packets, 3233948 bytes; actions:

drop

conformed 75000 bps, exceed 134000 bps

The output of 'show interface atm 0/0/0' gave the following:

ATM0/0/0 is up, line protocol is up

Hardware is HWIC-DSLSAR (with Alcatel ADSL Module), address is 0026.9957.4514 (bia 0026.9957.4514)

MTU 4470 bytes, sub MTU 4470, BW 956 Kbit/sec, DLY 530 usec,

reliability 255/255, txload 21/255, rxload 1/255

Encapsulation ATM, loopback not set

Keepalive not supported

Encapsulation(s): AAL5

23 maximum active VCs, 256 VCs per VP, 1 current VCCs

VC Auto Creation Disabled.

VC idle disconnect time: 300 seconds

Last input never, output 00:00:00, output hang never

Last clearing of "show interface" counters never

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

Queueing strategy: Per VC Queueing

30 second input rate 5000 bits/sec, 8 packets/sec

30 second output rate 79000 bits/sec, 8 packets/sec

32567786 packets input, 1283867072 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 7808 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

34746716 packets output, 444394311 bytes, 0 underruns

3 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

Thanks again for your help!!

Chris

Joseph W. Doherty · ‎09-24-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

From you stats, it does appear the shaper isn't engaging.

If you have maintenance, you might open a case with TAC.

zheng.olivier · ‎09-24-2012

Apply your policy map directly to the ATM 0/0/0 interface :

interface atm 0/0/0

..

pvc ...

service output QOS-DEFAULT

chris.notley · ‎09-24-2012

Hi Olivier,

Thanks again for the quick response!

I initially applied the policy under the PVC as you suggested - config as below:

policy-map QOS-DEFAULT

class CLASS-HIGH

priority 150

class class-default

shape average 100000

!

interface ATM0/0/0

load-interval 30

pvc 0/38

dialer pool-member 10

service-policy out QOS-DEFAULT

!

I then kicked off the rsync again and saw the following interface stats after approx 5 minutes:

ATM0/0/0 is up, line protocol is up

Hardware is HWIC-DSLSAR (with Alcatel ADSL Module), address is 0026.9957.4514 (bia 0026.9957.4514)

MTU 4470 bytes, sub MTU 4470, BW 956 Kbit/sec, DLY 530 usec,

reliability 255/255, txload 227/255, rxload 11/255

Encapsulation ATM, loopback not set

Keepalive not supported

Encapsulation(s): AAL5

23 maximum active VCs, 256 VCs per VP, 1 current VCCs

VC Auto Creation Disabled.

VC idle disconnect time: 300 seconds

Last input never, output 00:00:00, output hang never

Last clearing of "show interface" counters never

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

Queueing strategy: Per VC Queueing

30 second input rate 43000 bits/sec, 56 packets/sec

30 second output rate 852000 bits/sec, 78 packets/sec

32770209 packets input, 1298909685 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 7809 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

34970345 packets output, 754963270 bytes, 0 underruns

3 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

One interesting anomoly is that I noticed the 'service-policy out QOS-DEFAULT' dissapeared from the pvc instance after a few minutes. I'm able to repeat this consistently (add the service policy, verify it's set and then see it dissapear shortly afterwards).

I then tried applying the service policy above the pvc as follows:

interface ATM0/0/0

load-interval 30

service-policy out QOS-DEFAULT

pvc 0/38

Again, after kicking off the rsync and waiting a few minutes I saw the following interface stats:

ATM0/0/0 is up, line protocol is up

Hardware is HWIC-DSLSAR (with Alcatel ADSL Module), address is 0026.9957.4514 (bia 0026.9957.4514)

MTU 4470 bytes, sub MTU 4470, BW 956 Kbit/sec, DLY 530 usec,

reliability 255/255, txload 149/255, rxload 8/255

Encapsulation ATM, loopback not set

Keepalive not supported

Encapsulation(s): AAL5

23 maximum active VCs, 256 VCs per VP, 1 current VCCs

VC Auto Creation Disabled.

VC idle disconnect time: 300 seconds

Last input never, output 00:00:00, output hang never

Last clearing of "show interface" counters never

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

Queueing strategy: Per VC Queueing

30 second input rate 31000 bits/sec, 37 packets/sec

30 second output rate 562000 bits/sec, 60 packets/sec

32897715 packets input, 1400723976 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 7843 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

35097602 packets output, 828523368 bytes, 0 underruns

3 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

And the following after running 'show policy-map interface atm 0/0/0':

ATM0/0/0

Service-policy output: QOS-DEFAULT

queue stats for all priority classes:

queue limit 64 packets

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

(pkts output/bytes output) 0/0

Class-map: CLASS-HIGH (match-any)

1410 packets, 205532 bytes

30 second offered rate 5000 bps, drop rate 0 bps

Match: access-group 2000

1410 packets, 205532 bytes

30 second rate 5000 bps

Priority: 150 kbps, burst bytes 4470, b/w exceed drops: 0

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

75547 packets, 20414726 bytes

30 second offered rate 891000 bps, drop rate 0 bps

Match: any

Queueing

queue limit 64 packets

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

(pkts output/bytes output) 0/0

shape (average) cir 100000, bc 2500, be 2500

target shape rate 100000

Cheers,

Chris

zheng.olivier · ‎09-24-2012

Sorry for the late answer this time (in production, you can have time to post and 5 min after, there is a rush).

"However, the same policy is accepted on an ATM VC since the VC supports native ATM-layer shaping via the vbr-nrt, vbr-rt, cbr or abrcommands.

7200-16(config)#int atm 5/0.20 
7200-16(config-subif)#pvc 1/50 
7200-16(config-if-atm-vc)#vbr-nrt 100 100 94 
7200-16(config-if-atm-vc)#service-policy output queuenoshape 
7200-16(config-if-atm-vc)#end 
7200-16#show policy-map int atm 5/0.20
 ATM5/0.20: VC 1/50 -

"

chris.notley · ‎09-24-2012

Thanks again Olivier!

I've not used native ATM-layer shaping before - maybe I'm misreading this, but won't this affect all traffic passing through the interface? My goal here is to stop general traffic bursting up to the maximum.

Have I misunderstood?

Chris

zheng.olivier · ‎09-24-2012

It will affect all the traffic, but it'll use the service policy output to shape. So if you have defined the traffic class CLASS-HIGH, the priority reserved for that is still there.

Ex: you have a 2M link, you want to shape to 2M, but with 150k for AF41 class:

- you put the vbr nrt with the values corresponding to 2M.

- in the output policy, you set your AF41 class, and you set the class-default with remaining bandwidth

Tell me if we're lost in translation.

chris.notley · ‎09-25-2012

Hi Olivier,

Thanks again - I will give it a try!

Chris