Qos pre-classify not classifying packets correctly.

msisf1msisf1 · ‎06-02-2006

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

drolemc · ‎06-08-2006

Try this link for more information on configuring QOS.

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_white_paper09186a00800d6b73.shtml

msisf1msisf1 · ‎06-08-2006

A good document, although a little out of date being 5 years old and all..

Anyway, we set up a config with DCSP tagging policy on the input of the inside interface and used that value for the data classes with pretty much the same result.

msisf1msisf1 · ‎06-08-2006

Additional:

When I said same result, I meant that the DCSP tagging inbound on the inside interface appears to be classifying packets correctly but the outbound policy on the outside interface (using DCSP) is still only correctly classifying a minuscule amount of packets.

We have used many similar configurations with higher end routers and it’s never been an issue.

I’m sure I’ve done something wrong or I’m missing something stupid that I just can’t see, this why I tried to post as close to the actual config as possible in the opening post.

shaferr · ‎07-15-2006

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

msisf1msisf1 · ‎08-07-2006

RS,

A good answer, many thanks. We have since resolved the issue by completely disabling the ?qos pre-classify? and we are now only using DSCP for packet marking on the ingress interface and shaping on the egress interface. The commands are just a little different in the 830 series as compared to larger models.

You are also correct that we don?t want the default 25% of bandwidth automatically reserved for ?any?. We simply feel this value is too high for very small bandwidth connections.

rgds,