Show Policy-Map Interface X/X output question

[michaelcoffey]

Hi Everyone,

I am troubleshooting a situation with a customer where they are getting voice quality issues over their WAN.  When I look at the policy-map applied to the WAN facing interface I see the following output:

    Class-map: REALTIME (match-any)
      5934775 packets, 547271148 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp ef (46)
        1811301 packets, 128310242 bytes
        5 minute rate 0 bps
      Match: ip dscp af41 (34)
        167441 packets, 28756344 bytes
        5 minute rate 0 bps
      Match: access-group name AVAYAVOIP
        3956033 packets, 390204562 bytes
        5 minute rate 0 bps
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 30 (%)
        Bandwidth 926 (kbps) Burst 23150 (Bytes)
        (pkts matched/bytes matched) 912864/77181333
        (total drops/bytes drops) 856/1206256

    Class-map: CRITICAL (match-any)
      3837968 packets, 225767347 bytes
      5 minute offered rate 1000 bps, drop rate 0 bps
      Match: ip dscp af31 (26)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: ip dscp cs6 (48)
        3837968 packets, 225767347 bytes
        5 minute rate 1000 bps
      Queueing
        Output Queue: Conversation 265
        Bandwidth 20 (%)
        Bandwidth 617 (kbps)
        (pkts matched/bytes matched) 3105906/180974193
        (depth/total drops/no-buffer drops) 0/0/0
         exponential weight: 9
         mean queue depth: 0

   dscp    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
   af11       0/0               0/0              0/0           32      40  1/10
   af12       0/0               0/0              0/0           28      40  1/10
   af13       0/0               0/0              0/0           24      40  1/10
   af21       0/0               0/0              0/0           32      40  1/10
   af22       0/0               0/0              0/0           28      40  1/10
   af23       0/0               0/0              0/0           24      40  1/10
   af31       0/0               0/0              0/0           32      40  1/10
   af32       0/0               0/0              0/0           28      40  1/10
   af33       0/0               0/0              0/0           24      40  1/10
   af41       0/0               0/0              0/0           32      40  1/10
   af42       0/0               0/0              0/0           28      40  1/10
   af43       0/0               0/0              0/0           24      40  1/10
    cs1       0/0               0/0              0/0           22      40  1/10
    cs2       0/0               0/0              0/0           24      40  1/10
    cs3       0/0               0/0              0/0           26      40  1/10
    cs4       0/0               0/0              0/0           28      40  1/10
    cs5       0/0               0/0              0/0           30      40  1/10
    cs6 3837968/225767347       0/0              0/0           32      40  1/10
    cs7       0/0               0/0              0/0           34      40  1/10
     ef       0/0               0/0              0/0           36      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10
default       0/0               0/0              0/0           20      40  1/10

It looks like the policy-map is matching on the EF needed for real-time traffic but what I do not know is why down toward the bottom of the output ,where everything is broken down by DSCP value , I am not seeing transmitted packets under ef  but rather all going cs6. I am unsure about this command and thought I would post here.  I am assuming that it has something to do with the strict priority queue just sending all traffic immediately but it seems as though you could confirm that all traffic with an EF tag is actually being sent first.    ,

Any insight would be much appreciated!!!

[mlund · Accepted solution]

Hi Michael

The service-policy counts packets that matches the different classes, but it doesn't kick in until there is conquestions on the outgoing interface.

For a service-policy to kick in, there must be conquestions on the output interface. That means that if there are enough room in the tx-buffers (hardware buffers), a packet will be put to the tx-queue imediatly. However if the tx-buffers fill up, the router starts to use software-buffers, and at this point the service-policy is kicked-in.

Breaking Your output down in small peaces.

Class-map REALTIME matches on EF (1811301 packets) it also matches on af41 (167441 packets) and access-group AVAYAVOIP (3956033 packets) that makes a total of 5934775 for the hole class-map REALTIME.

Most of the time there has been no conquestion, but at some point (it can be more than one) there has been conquestions and the policy-map kicks in. At this point there has been 912864 packets that have been put in the priorityqueue to be served first, but 856 of them have been dropped because the total bandwidth for the priorityqueue has been higher than 926kb at some point

For class-map CRITICAL wich matches dscp af31 (0 packets) and dscp cs6 (3837968 packets) 3105906 of them have been put in the softwarequeue under the time when there was conquestion, and none of them have been dropped.

All the dscp values at the bottom is just related to the class-map critical and has nothing to do with the class-map REALTIME

For Your last sentense, yes, the priority queue will be served first if there is conquestions, but it will at that moment also be policed to the configured rate (30%) in your case.

If there are no conquetions the priority traffic can be higher than 30%. Because the policy-map only kicks in if interface is conquested.

/Mikael