Show FIFO in interface even though configured CBWFQ with policy-map

[nyein chan tun]

Hi all experts,

I already configured policy map queuing and shaping with class-map. And also applied on the WAN interface for those policies. Actually, the interface's queueing method should be Class-based queueing instead of default queuing. But I saw on " sh interfaces  " that queueing method are still " FIFO ( for ethernet ) and " Weighte-fair  ( for serial ). So I checked on some routers which is higher IOS and once I applied policy-map on interface, it's showing class-based queueing. And also I facing some intermittent packet drops in router which is work with default queue method.

Please help me to get the answer for following:

1) Is any Impact to be more packet drop if the interface hardware   queue is FIFO even though configured CBWFQ?

2) In sh interface WAN ( see in below ), I'm not clear that total oupt drops are coming from LAN to WAN or coming from WAN to LAN, please explain me.

Last clearing of "show interface"   counters 4d21h

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

please see in attach for  the qos  configuration and IOS version.

This is summary for IOS:

c2800nm-spservicesk9-mz.124-21a : This IOS can show only FIFO in interface

c2800nm-spservicesk9-mz.124-24.T1 : This IOS can show with Class based queueing after configured.

   

c2800nm-spservicesk9-mz.124-21a

[Giuseppe Larosa · Accepted solution]

Hello Nyein,

I may be wrong but your issue may be only "cosmetic", the show policy-map interface g0/0 that you have reported in the attached file shows that the CB queueing is present outbound  because per class-map counters are reported and non-zero and we see drops in some specific class ( most of drops are in class Gold)

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

  Queueing strategy: fifo

and then

Class-map: Gold (match-any)

[output omitted ]

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

with total packets in Gold class that is very high

sum of per class drops is less then total output drops at interface level and this looks like correct.

The output drops are on the WAN interface and means that there might some bursts that violate the logical pipe of 16 Mbps that you have built with hierarchical QoS with the Shaper parent policy.

The logical pipe is then divided in queues as configured in the child queueing policy.

if we examine the show policy-map int gi0/0 for the class Gold we see the following lines:

Class-map: Gold (match-any)

          71150009 packets, 24317788134 bytes

          30 second offered rate 288000 bps, drop rate 0 bps

          Match: ip dscp af21 (18)

            71150009 packets, 24317788134 bytes

            30 second rate 288000 bps

          Queueing

            Output Queue: Conversation 267

            Bandwidth 4096 (kbps)Max Threshold 4096 (packets)

            (pkts matched/bytes matched) 4766006/5705182061

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

Current traffic in this class is 288 kbps, the total number of packets in the class is

71150009.

Notice that queueing is probably triggered only when the parent shaper is triggered so the total number of packets CB queued is less is only

4766006.

So you had 3173 drops over

71150009 packets

And what is more important only 4766006 packets of 71150009  (6,6 %) have been queued over the CB WFQ queue for class Gold.

At the moment you took the output the total rate was only 521 kbps and shaping was not in effect and we can say also child CBWFQ policy is not in effect  (shaping Active = No  at the beginning of the Shaping section in show policy-map interface)

This might explain why the queueing is declared as FIFO at interface level during low level traffic.

The show interface should show CB WFQ when the shaper is active, the 16 Mbps logical pipe is in effect and the CBWFQ is also active.

This is also a confirmation that CBWFQ is triggered "during congestion" only when the parent shaper is active and in low traffic conditions all the hierarchical QoS is bypassed and FIFO is used.

1) you have a few drops in comparison to total traffic  that have no impact

2) the output drops are in outbound direction on the WAN interface gi0/0 where hierarchical QoS is applied

The other IOS version 12.4.24T1 implements the new Hierarchical QoS framework introduced in 12.4(20)T, so the show interface output may be different as the HQOS implementation is different.

I think that this the root cause of the differences you see between routers with the two different IOS versions.

Edit:

a link to configuration guide for new HQF

http://www.cisco.com/en/US/docs/ios-xml/ios/qos_hrhqf/configuration/12-4t/qos-hrhqf.html#GUID-1E026A87-177F-4F0C-86F2-7A920CEEEF59

Hope to help

Giuseppe

[nyein chan tun]

Hi Giuseppe,

          Thanks alot  for your detial explanation and suggestions.

Please advise me your recommendtion for the following in this case:

1) Should I increase the total bandwidth for WAN link or should I increase only the bandwidth for class Gold by decreasing bandwidth from other class?

2) Should I upgrade IOS from 124.21a to 124.24T ?

3) Is there any effect for CPU & Memory usage if we are using queue-limit 4096 ?

4) As per your explanation, my understanding is Parent shaper policy is only active  in " during congestion " and CBWFQ will show in interface when 16Mbps logical pipe is in effect. At that time, output total rate is 521kbps and parent shaper is not active, so when the parent shaper should be active? until reach to 16Mbps or other rate ?

5) When I checked in R2 which has IOS 12.4 24T and it's shown that queue strategery is CBWFQ and the class-map Gold is shown below:( please see in attach for more detail )

Class-map: Gold (match-any)

          52675738 packets, 17760697081 bytes

          30 second offered rate 300000 bps, drop rate 0 bps

          Match: ip dscp af21 (18)

            52675738 packets, 17760697081 bytes

            30 second rate 300000 bps

          Queueing

          queue limit 2048 packets

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

          (pkts output/bytes output) 52675738/17760855955

          bandwidth 3072 kbps

  Service-policy output: SHAPING

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

      83639988 packets, 31188470871 bytes

      30 second offered rate 596000 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) 83649157/31169792822

      shape (average) cir 10240000, bc 40960, be 40960

      target shape rate 10240000

52675738 / 52675738 ( 100% ) have been queued over the CB WFQ queue for class Gold. So can we say that Parent shaper  is active even though total output rate is still 596Kbps?

Thanks a lot for your help.

[Giuseppe Larosa · Accepted solution]

Hello Nyein,

thanks for your feedback I have found this thread to be very interesting.

1)  I don't think you need to perform any change as the number of packet drops in class Gold in comparison with total packets in class Gold is not a problem.

2) On the long term you will have to perform IOS upgrade for security patches or other reasons. Using the same IOS image in similar devices is more practical to manage, as for the example the issue we are discussing is caused by different implementation of HQoS on the two images. At the moment you can decide to go on with this difference or you can plan an upgrade campaign to 12.4(24)T.

3) No real effects on cpu and for memory means that you allocate memory for 4096 packets, so a little more memory is in use

4) and 5)  the counters that you are reporting for R2 that has 12.4(24)T confirm that behaviour has changed and new implementation has CB WFQ always applied as we can see with the counters. This is reflected in show interface that reports CB Queueing instead of FIFO. About the parent shaper we can notice that the show policy-map interface output has changed with new implementation, but I'm not able to tell more at the moment.

Hope to help

Giuseppe

[nyein chan tun]

Hi Giuseppe,

          Thanks a lot for your guide line and explanation. I really apprecitated. I will try to plan and review for upgrading IOS to be standarized.

Thanks & best regard,

Nyein Chan