qos exceeding more that 100 percent

[Vinayaka Raman]

hello ,

I have a p2p interface interconnecting two sites and its bandwidth is 1536 kbps.

I have applied LLQ on both sides of the link with a shape average to 95 percentage of CIR.

I am still seeing the utilization exceeding more than 100 percentages in the graph.

This issue is not confined only to this point to point link.

In all other remote sites I have the same kind of policy applied. but the remote sites are interconnected by full mesh MPLS cloud.

We have a similar problem ( exceeding 100 percent) at that as well.

My initial assumption was that in the MPLS network: the remote site was running on 1 mbps and headend was running on 150 mbps.

There was no nested created on the headend that will share average depending on the remote sites bandwidth. Therefore, I thought this could be the problem why I was seeing traffic exceeding more than 100 percent.

But with the point to point link, I should be able to control better. Unfortunately it did now work that way. Please let me know if you need any additional information to suggest me. Attached the configuration of p2p routers on either end and util graph.

[John Peek]

What do you have the link bandwidth set to in the netflow analyzer? I've usually had this problem with netflow when the analyzer thinks the connection is smaller than it really is.

[Vinayaka Raman]

on the netflow analyzer, i see the correct bandwidth is reflected on either sides..

here is an example i have attached..I am seeing the traffic to 100.6.4.223 is exceeding more than 100 percent though i have a shaper configured and it is pushed to best-effort queue.

[Edison Ortiz]

Vinayaka,

Taken from the ACR1 log you posted:

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

      5630730 packets, 6131472542 bytes

      30 second offered rate 73000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

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

      (pkts output/bytes output) 5676769/6189080777

      shape (average) cir 1459200, bc 14592, be 14592

      target shape rate 1459200

        lower bound cir 0,  adapt to fecn 0

The algorithm is using 10ms measurement interval and you are allowing for excess burst hence the reason why you see flows going over the limit.

Did you enter the bc and be manually or you let IOS do the formula for you? IOS will default to 4ms measurement interval and IIRC it won't allow for excess burst.

[Vinayaka Raman]

Edison,

Thanks for the note..

I have not configured excess burst and normal burst manually..it should be IOS default..

Interestingly I see both sides have the same CIR but different be and bc values..

Do you recommend hard coding it ?

how to calculate the measuring interval and selcting an optimum one? What is IIRC?

[Edison Ortiz]

IIRC = If I Recall Correctly.

Yes, I suggest you configure the bc and be manually. Ideally, you should have 4ms instead of 10ms if you are carrying voip.

Set your bc to 5837 and your be to 0 if you want to strictly send 5837 bits every 4ms.

The formula is CIR = Bc/(Tc/1000)

[Vinayaka Raman]

thank you..

Looks like be = 0 is not allowed..

Is there any other way of doing this?

CR1(config-pmap-c)#shape average percent ?
  <1-100>  percentage

CR1(config-pmap-c)#shape average percent 95 ?
  <10-2000>  sustained burst in milliseconds. Recommend not to configure it,
             the algorithm will find out the best value
 

CR1(config-pmap-c)#shape average percent 95 ?
  <10-2000>  sustained burst in milliseconds. Recommend not to configure it,
             the algorithm will find out the best value
 

CR1(config-pmap-c)#shape average percent 95 10 ms ?
  <10-2000>  excess burst in milliseconds. Recommend not to configure it, the
             algorithm will find out the best value
 

CR1(config-pmap-c)#shape average percent 95 10 ms

[Vinayaka Raman]

Also, can you please advise me if i should apply the service policy on physical or sub-interface?

[Edison Ortiz]

On the main interface, it will affect all subinterfaces.

On the subinterface, it will only affect the specified subinterface.

Your design, your choice.

[Edison Ortiz]

Do not use the percentage keyword.

policy-map CISCO

class class-default

  shape average 1459200 5837 0

R1#show policy-map interface

FastEthernet0/1

  Service-policy output: CISCO

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

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

      Traffic Shaping

           Target/Average   Byte   Sustain   Excess    Interval  Increment

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

          1459200/1459200   729    5837      0         4         729     

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping

        Active Depth                         Delayed   Delayed   Active

        -      0         0         0         0         0         no