QoS Configuration - police cir - netflow - problem

fabiogarcia · ‎03-04-2013

Dears,

I have this configuration at my router, can anybody do a suggestion ?

Sorry the long post... tried to simplify as much as I could.

ip access-list extended SHAPE_TRAFEGO_SRC_172.17.196.12

permit ip host 172.17.196.12 any

permit ip any host 172.17.196.12

class-map match-any SHAPE_TRAFEGO_SRC_172.17.196.12

match access-group name SHAPE_TRAFEGO_SRC_172.17.196.12

policy-map qos_new

...

class SHAPE_TRAFEGO_SRC_172.17.196.12

police cir 8000

conform-action transmit

exceed-action drop

violate-action drop

...

class class-default

fair-queue

policy-map PARENT_qos_new

class class-default

shape average 2000000

service-policy qos_new

**** Thats a Frame relay interface ******

interface Serial0/1/1

description XXXXXX

no ip address

encapsulation frame-relay IETF

invert txclock

!

interface Serial0/1/1.777 point-to-point

description XXXXXXX

bandwidth 2048

ip address 172.26.0.65 255.255.255.252

ip nbar protocol-discovery

ip flow ingress

ip flow egress

frame-relay interface-dlci 777

service-policy output PARENT_qos_new

That should be policing all that traffic to 8kbps... but in my NETFLOW tool, I see traffic going above that limit.. a lot of times... below an example

We can see easily that traffic goes at 300Kbps limit...

I see that traffic is using that police as well... but not really policed...

router#sh ip access-lists SHAPE_TRAFEGO_SRC_172.17.196.12

Extended IP access list SHAPE_TRAFEGO_SRC_172.17.196.12

10 permit ip host 172.17.196.12 any

20 permit ip any host 172.17.196.12 (2067609 matches) <<<<<<<< increasing all the time

Any suggestion ?

Terry Cheema · ‎03-04-2013

Was the link congested at that time? QoS would only kick in when your link experiences congestion.

policy-map PARENT_qos_new

class class-default

shape average 2000000 <<< You are shaping at close to 2Mb

service-policy qos_new

Unless your link is overflowing more than 2Mb - whatever traffic comes in goes out without any policing queuing. When the 2Mb mark is reached then your traffic would start getting the defined behavior. Then it would police at 8kbps. Which is the correct behavior.

The possibilty is your link was not congested during that periods.

milan.kulik · ‎03-05-2013

Hi,

IMHO, the policer should work all the time, no matter if the line is congested or not..

But it's restricting traffic from/to a single host 172.17.196.12.

While the NetFlow example is showing traffic from another host which is not matching the ACL.

HTH,

Milan

Terry Cheema · ‎03-05-2013

Milan - You could be right - but I beleive since the parent policy is shaping and then the child policy is applied under it has the policer defined, its not active all the time. I am typing from phone so cant exactly copy paste - but I think if policer was applied directly under the Parent policy first, before any other policy, then it would by pass Shaping and would police all the time...

But at the moment parent policy is shaping traffic at 2 Mbps, child policy has other treatment along with policer, thats why I think unless parent policy signals bandwidth congestion, the child policy will not kick in..

Interesting, Lets seek some more comments .....

Thanks for replying buddy.

Terry

Sent from Cisco Technical Support iPhone App

milan.kulik · ‎03-05-2013

Hi Terry,

I still believe the policer should work all the time.

It would be interesting to repeat

show policy-map interface Serial0/1/1.777 out

command several times and check if the policer counters are showing any drops increasing.

BR,

Milan

Terry Cheema · ‎03-05-2013

Interesting - Anyone else, would like to share views?

Terry

Giuseppe Larosa · ‎03-06-2013

Hello Terry,

I agree with Milan.

the nested QoS policy applies policing only to two distinct traffic flows having IP source or IP destination a specific host.

However, nothing in the configuration blocks other traffic just there is a shaper to 2Mbps in the parent policy map.

So seeing traffic peaks on the interface of up to 300 Kbps < 2 Mbps is not a sign of a problem.

As suggested by Milan the show polcy-map interface counters can answer to the question and they should show policing in effect.

Hope to help

Giuseppe

Terry Cheema · ‎03-06-2013

Giuseppe,

Thanks for taking the time to reply and clearing this up +5 to you and Milan(all posts) - cant do more than that . It means explicit policer is always ON even if its in a Child Policy and is bypassing the Parent shaper. Congestion or no congestion, Hierarchical or not - explicit policer is always ON.

Fabio,

This one from Giuseppe is for your clarity:

So seeing traffic peaks on the interface of up to 300 Kbps < 2 Mbps is not a sign of a problem.

As suggested by Milan the show polcy-map interface counters can answer to the question and they should show policing in effect.

Terry

fabiogarcia · ‎03-11-2013

Dears

First of all THANKS FOR EVERYONE whos trying to help me.....

And SORRY for my reply... I was out of office doing other jobs these days... please find below the output requested...

The output below shows all results for all classes (not only the class I am concerning about)

router#show policy-map interface Serial0/1/1.777 out

Serial0/1/1.777

Service-policy output: PARENT_qos_new

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

61465416 packets, 13711229376 bytes

5 minute offered rate 259000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

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

2000000/2000000 12500 50000 50000 25 6250

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 55807037 2742354205 347175 400791112 no

Service-policy : qos_new

Class-map: voip (match-any)

750758 packets, 144475769 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: ip dscp ef (46)

0 packets, 0 bytes

5 minute rate 0 bps

Match: ip dscp cs5 (40)

0 packets, 0 bytes

5 minute rate 0 bps

Match: ip dscp cs6 (48)

71955 packets, 4219931 bytes

5 minute rate 0 bps

Match: dscp ef (46)

0 packets, 0 bytes

5 minute rate 0 bps

Match: dscp cs5 (40)

0 packets, 0 bytes

5 minute rate 0 bps

Match: dscp cs6 (48)

0 packets, 0 bytes

5 minute rate 0 bps

Match: ip precedence 5

0 packets, 0 bytes

5 minute rate 0 bps

Match: precedence 5

0 packets, 0 bytes

5 minute rate 0 bps

Match: protocol skinny

55964 packets, 27501612 bytes

5 minute rate 0 bps

Match: protocol rtp audio

622840 packets, 112754430 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 72

Bandwidth 10 (%)

Bandwidth 200 (kbps) Burst 5000 (Bytes)

(pkts matched/bytes matched) 1319/765920

(total drops/bytes drops) 44/63394

Class-map: PRIOR_SHIVA_THRU_ATT (match-any)

994676 packets, 119261474 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name PRIOR_SHIVA_THRU_ATT

994676 packets, 119261474 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 72

Bandwidth 5 (%)

Bandwidth 100 (kbps) Burst 2500 (Bytes)

(pkts matched/bytes matched) 1288/252691

(total drops/bytes drops) 31/46624

Class-map: SHAPE_TRAFEGO_SRC_172.17.196.12 (match-any)

13753357 packets, 3086579457 bytes

5 minute offered rate 62000 bps, drop rate 55000 bps

Match: access-group name SHAPE_TRAFEGO_SRC_172.17.196.12

13753356 packets, 3086579457 bytes

5 minute rate 62000 bps

police:

cir 8000 bps, bc 1500 bytes, be 1500 bytes

conformed 8123233 packets, 731084041 bytes; actions:

transmit

exceeded 4002688 packets, 409236337 bytes; actions:

drop

violated 1627496 packets, 1946298475 bytes; actions:

drop

conformed 7000 bps, exceed 0 bps, violate 55000 bps

...

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

31175903 packets, 8285525763 bytes

5 minute offered rate 120000 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/428/0

router#

Do you guys suggest another value for my MAIN policy ... ?

policy-map PARENT_qos_new

class class-default

shape average 2000000 <<<<<<<<<<<<<<<<<<< (???)

service-policy qos_new

Thanks in advance!!!!

Giuseppe Larosa · ‎03-11-2013

Hello Fabio,

as suggested by Milan the show policy-map interface output shows that policing is active in the child policy map and that traffic in excess of the policing rate is actually dropped. This applies only to specific traffic flows as noted in previous posts in this thread.

The shaping rate in the parent policy applies to ALL traffic that is sent out on the link and should be less equal of access link rate.

If it is so, you are fine with this rate. If the actual speed of the link is lower then 2000000 bps then you should lower it.

Edit:

and also the shaping rate has to be less equal then the contracted rate ( CIR) agreed with the SP for which your company/client is paying for.

Hope to help

Giuseppe

milan.kulik · ‎03-11-2013

Hi,

I agree wit Giuseppe.

As you can see in your output:

router#show policy-map interface Serial0/1/1.777 out

Serial0/1/1.777

Service-policy output: PARENT_qos_new

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

61465416 packets, 13711229376 bytes

5 minute offered rate 259000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

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

2000000/2000000 12500 50000 50000 25 6250

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 55807037 2742354205 347175 400791112 no

So the whole traffic to sent out from the interface is coming with 259 kbps speed - far not reaching the 2 Mbps shaping target.

That's why the shaping is NOT active at the moment.

On the other side:

Class-map: SHAPE_TRAFEGO_SRC_172.17.196.12 (match-any)

13753357 packets, 3086579457 bytes

5 minute offered rate 62000 bps, drop rate 55000 bps

Match: access-group name SHAPE_TRAFEGO_SRC_172.17.196.12

13753356 packets, 3086579457 bytes

5 minute rate 62000 bps

police:

cir 8000 bps, bc 1500 bytes, be 1500 bytes

conformed 8123233 packets, 731084041 bytes; actions:

transmit

exceeded 4002688 packets, 409236337 bytes; actions:

drop

violated 1627496 packets, 1946298475 bytes; actions:

drop

conformed 7000 bps, exceed 0 bps, violate 55000 bps

So the child policer is active, dropping the traffic exceeding the CIR configured.

As I said in the beginning:

If you want to restrict the traffic originated from other sources, you just need to add them to the ACL used in the child policer.

HTH,

Milan

fabiogarcia · ‎03-11-2013

Dears,

Again thanks everyone for all help and time spent with my problem!!!!

I can guarantee that during the first message I was facing cogestion... and from the router I see everything well... the traffic is being policed doesnt matter the total rate on the link... But the main problem is my netflow tool (from manage engine called "Netflow analyzer") ... When I check each flow with that IP I see that the traffic is pretty much above the police I used...

From the same policy-map I have another class which should be policed to 128K (output below is from a non congested time window)

Class-map: SHAPE_TRAFEGO_SYMANTEC_CORP (match-any)

15744681 packets, 2198483815 bytes

5 minute offered rate 35000 bps, drop rate 0 bps

Match: access-group name SHAPE_TRAFEGO_SYMANTEC_CORP

15744681 packets, 2198483771 bytes

5 minute rate 35000 bps

police:

cir 128000 bps, bc 4000 bytes, be 4000 bytes

conformed 15707067 packets, 2165838164 bytes; actions:

transmit

exceeded 30287 packets, 24900396 bytes; actions:

drop

violated 7498 packets, 7783805 bytes; actions:

drop

conformed 37000 bps, exceed 0 bps, violate 0 bps

This is the ACL

ip access-list extended SHAPE_TRAFEGO_SYMANTEC_CORP

permit ip host 172.21.252.223 any

permit ip any host 172.21.252.223

In other words, that class should never exceed 128K... right ?? (doesnt matter if the traffic is congested or not....)

But look my netflow.... I can easily see an unique flow exceeding and reaching 1.5Mbps during 1 hour time window...

Is it correct affirm that traffic should be policed to 128K all the time ?

Why we see an unique flow reaching 1.5Mbps ?

Thanks in advance!!!!!

milan.kulik · ‎03-11-2013

Hi,

interesting!

I understand you are running NetFlow on the same interface the policer is applied?

Could you provide the whole NetFlow configuration from your router?

I'm not sure what is the order of NetFlow/policer drop operations.

Possibly NetFlow collects the statistics before the policer drop is applied?

BR,

Milan

fabiogarcia · ‎03-13-2013

Hi

Thanks for your help..

Actually I did the netflow configuration following the vendor documentation

This is the configuration

router#sh run int Serial0/1/1.777

Building configuration...

Current configuration : 294 bytes

!

interface Serial0/1/1.777 point-to-point

description MPLS PRI AT&T XXXXXXXXXXXXXXX

bandwidth 2048

ip address 172.26.0.65 255.255.255.252

ip nbar protocol-discovery

ip flow ingress

ip flow egress

frame-relay interface-dlci 777

service-policy output PARENT_qos_new

end

Also we have

ip flow-cache timeout active 1

ip flow-export source FastEthernet0/0

ip flow-export version 5

ip flow-export destination X.X.39.139 2055

Also, exactly right now... I see that in my netflow (traffic from 172.21.252.223 is reaching 1.2 Mbps)

This is my policy map

Class-map: SHAPE_TRAFEGO_SYMANTEC_CORP (match-any)

20576508 packets, 3054240429 bytes

5 minute offered rate 96000 bps, drop rate 1000 bps

Match: access-group name SHAPE_TRAFEGO_SYMANTEC_CORP

20576507 packets, 3054240333 bytes

5 minute rate 96000 bps

police:

cir 128000 bps, bc 4000 bytes, be 4000 bytes

conformed 20500879 packets, 2983476986 bytes; actions:

transmit

exceeded 49242 packets, 42997686 bytes; actions:

drop

violated 26746 packets, 27797370 bytes; actions:

drop

conformed 96000 bps, exceed 2000 bps, violate 0 bps

This is the access-list (increasing the logs)

router#sh ip access-lists SHAPE_TRAFEGO_SYMANTEC_CORP

Extended IP access list SHAPE_TRAFEGO_SYMANTEC_CORP

10 permit ip host 172.21.252.223 any (16 matches)

20 permit ip any host 172.21.252.223 (20599387 matches) <<<<<<<<<<<<<<<<<<

Thats weird... In the netflow graphs I see a lot of traffic ... but in the router I see only traffic around 96Kbps (which is not reaching the limit of policy cir configured >> 128K)

Giuseppe Larosa · ‎03-13-2013

Hello Fabio,

I again agree with Milan

>> Possibly NetFlow collects the statistics before the policer drop is applied?

The order of operations may explain the mismatch in output results between what is seen in Netflow and the output of QoS shaper/policer.

If Netflow processes the packets before they are processed by QoS tools it may account for dropped traffic.

Hope to help

Giuseppe