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
description Channel SPb-Moscow
ip address 192.168.200.254 255.255.255.0
traffic-shape group 130 10000000 10000000 10000000 1000
crypto map TETRA
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
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
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
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
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.
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.
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:
shape average 10000000
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.
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
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.