QoS not all packets matched

[Alexey Dmitriev]

Hello!

I have a problem with configuratons QoS for 1811 and 2811 routers. Not all packets are matched by service-policy. Config from 1811:

class-map match-all Conference
 match access-group 120

policy-map Conference
 class Conference
  priority 8000
 class class-default
  fair-queue

 interface FastEthernet0
 description Channel SPb-Moscow
 bandwidth 10000
 ip address 192.168.200.254 255.255.255.0
 speed auto
 full-duplex
 traffic-shape group 130 10000000 10000000 10000000 1000
 crypto map TETRA
 max-reserved-bandwidth 100
 service-policy output Conference

access-list 120 permit ip host 172.16.0.152 host 172.16.1.152
access-list 130 permit ip any any

#show policy-map interface fastEthernet 0
 FastEthernet0

  Service-policy output: Conference

    Class-map: Conference (match-all)
      956459 packets, 1004630763 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 120
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 8000 (kbps) Burst 200000 (Bytes)
        (pkts matched/bytes matched) 5887/4741334
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      55431733 packets, 34766716729 bytes
      5 minute offered rate 3273000 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 256
        (total queued/total drops/no-buffer drops) 0/224/0

I'm trying to reduce tx-ring-limit to 3 and to 1, and the number of matched packets increased. But still didn't equal  all packets from class-map. Why it can be so? Because of that QoS don't work correct. There is no prioritet for host ACL 120 traffic. No drops

Shape use because of proviser limit 10 Mbps

[Joseph W. Doherty]

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 wha2tsoever (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

Given that the second number increased when you decreased tx-ring-limit, I would suspect the first value is a count of packets that matched that class while the second value counts packets that were queued.

BTW, I'm unsure how an interface shaper interacts with a service-policy.  The preferred solution would be to shape in a parent policy and manage congestion in a child-policy. E.g:

policy-map SampleParent

class class-default

shape average 10000000

service-policy Conference

You remove the interface shaper and replace the interface policy with the above.

NB: Ah, I see you're using an ACL, well you can amend the above to have a parent class match using the same ACL.

[Alexey Dmitriev]

As I understand, the first counter is all packets that processed by service-policy (ACL) L3 and L2 without L3 queue. The second is all packets that processed L3 queue and qos. Then I decreased tx, more packets processed L3 layer. But not all. In GNS then I decreased tx = 3, both counters became equal, and qos works fine. But on real hardware not. How it can be? I can try shape in the policy, but not sure it helps for the main problem with qos

[mlund]

Hi Alexey

Joseph has given the right answer. I just want to comment about the tx-ring.

The tx-ring is the hardware queue, while the policy-map is working with software queue.

So for example, if a packet arrives to the router and is directed to the interface, the router checks if there is free space in the tx-ring, if so it is copied to the tx-ring. The packet counter is incremented, but the match counter is not incremented because the packet was not queued in the software buffers.

The packet in the tx-ring is no clocked out from the interface, what happens if there is 2 more packkets ariving that should be transferred out this interface. The router checks the tx-ring, it founds there is still room for 2 packets, and it puts these 2 packets into place 2 and 3 in the-tx-ring, and also increments the counter with 2.

Now the router has delivered the first packet, and packet number 2 is started to be clocked out, if there is again 2 packets arriving, the router checks to see if there is room for these in the hardware queue.  Yes packet 4 can be placed int the tx-ring, but packet 5 cannot, because packet 2,3 and 4 is occupying the 3 available space in tx-ring, so packet 5 has to be software queued. And now the counters i incremented by 2, and the match counter is incremented by 1. 

/Mikael