Qos pre-classify not classifying packets correctly.

Question

This is a little 831 router (12.4.4T) with one private and one public interface connected to a 1000/256 ADSL circuit. There is a VPN to the Head Office with a GRE tunnel and EIGRP.
The Tunnels bandwidth is set to 1544 since there is a frame-relay backup and the service provider hasn’t configured their parameters correctly, but this shouldn’t affect the QoS.
What’s happening is that we can only see a very small amount of traffic being classified correctly and all other traffic seems to match the last (ip any any) access-list. The fact that the data is being classified seems to indicate that the qos pre-classify is working but we don’t know why it’s not matching the correct data classes.
Any ideas would be greatly appreciated...
router#sh policy-map int eth1
Ethernet1
Service-policy output: soho01-vpn-256
Class-map: AC-CLASS-G1 (match-any)
14110 packets, 2414498 bytes
5 minute offered rate 9000 bps, drop rate 0 bps
Match: access-group name AC-G1
14110 packets, 2414498 bytes
5 minute rate 9000 bps
Queueing
Output Queue: Conversation 73
Bandwidth 128 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 1/60
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G2 (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name AC-G2
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 74
Bandwidth 8 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G3 (match-any)
12 packets, 968 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name AC-G3
12 packets, 968 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 75
Bandwidth 32 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 9/558
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G4 (match-any)
1621 packets, 266028 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name AC-G4
1621 packets, 266028 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 76
Bandwidth 64 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 19/1240
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G5 (match-any)
9336 packets, 693246 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: access-group name AC-G5
9336 packets, 693246 bytes
5 minute rate 1000 bps
Queueing
Output Queue: Conversation 77
Bandwidth 16 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 8248/511990
(depth/total drops/no-buffer drops) 0/0/0
Class-map: AC-CLASS-G6 (match-any)
369616 packets, 79361172 bytes
5 minute offered rate 164000 bps, drop rate 0 bps
Match: access-group name AC-G6
369616 packets, 79361172 bytes
5 minute rate 164000 bps
Queueing
Output Queue: Conversation 78
Bandwidth 8 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 310/24424
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
4750 packets, 285000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Answer 1

Someone please correct me if I am wrong but if you add the 5 minute offered rate for all your classes you are classifying about 175K worth of traffic throughout your service policy. If I am reading correctly your circuit is 256 up 1M down.
From looking at your configuration it seems most of your traffic is matching the class named class AC-CLASS-G6. There is no access list defined for this class so essentially all traffic that hasn?t matched a previous class will match here. This explains why you?re not matching any traffic on the default class.
It is recommended to only assign queues for up to 75% of the available bandwidth. IOS determines what this 75% is based on the bandwidth statement. Right now you have queues defined for all but 2K of your available bandwidth which means traffic that doesn?t match any of your classes will be tail dropped during times of congestion. I assume you are intending to do this based on the max-reserved-bandwidth command and the missing access list.
When using qos-preclassify essentially what happens is the ToS bits are copied into the post gre or IPSEC IP header. In this case you are not matching based on DSCP marking you are matching on IP address so therefore when packets egress your E0 interface the post GRE or IPSEC IP header doesn?t have an address or type field that matches your class statements. If you were to mark traffic based on these classes with a DSCP marking (i.e. AF 31, 32, 33) at the inbound interface you could then copy these markings and provide the appropriate PHB on your egress interface E0.
HTH
RS