QoS Pre-classify and Class-map Order

I’m still studying for the ONT test, so I did some labs tonight.  One of them was to demonstrate the qos pre-classify command for tunnel interfaces.  When you have a packet sent over a GRE tunnel, the ToS field gets copied to the GRE packet, but there’s no way to see the original packet’s higher-level headers on the way out the interface.  This can be a problem if your service policy needs to see protocol, port, IPs, etc.  The fix for that is to enable qos pre-classify on the tunnel interface and cyrpto map; doing so will provide a copy of the original packet to the physical interface to classify the packet thoroughly.

Here’s the lab.  I was testing from TestHost1 to TestHost2 and configuring R1 to do the pre-classification.  Both R1 and R2 are 3640s running IOS 12.4(25b) and have a GRE tunnel between them.

qospre1

I created a policy map that simply acknowledges the existence of ICMP packets; the router doesn’t do anything except match them in a class-map and smile at them on the way through.  Here’s the snippet.

Not much going on there.  We match ICMP using NBAR’s built-in protocols and do absolutely nothing.  I did a few pings and noticed that there were no matches to the ICMP class and that all the packets were classified as class-default .  I thought that the pre-classify wasn’t working, so I cursed for a while after making no progress at all.  I had no idea what was wrong.

I need to stop here so people don’t get confused.  The configuration that you see is correct; the problem was actually with the NBAR protocols in the class-map.  As Jeremy Stretch notes at the bottom of this article, there’s some issue with matching NBAR protocols.  I later used an extended ACL to match ICMP which worked.  The same is true for the SSH stuff later.  Back to the show.

Here’s what I wound up with after cursing a lot and making random configuration changes to get the blasted thing to work.  Notice the order of the classes.

I know that order is going to be important, but these are matching two totally different things, so it shouldn’t matter, right?  I checked out the policy-map again and saw that every packet was matching the TUNNEL class-map, and none were matching the ICMP class-map.

I finally went downstairs, talked it over with my wife who is my rubber duck, and finally figured it wouldn’t hurt to change the order of the classes.  Once I put ICMP before TUNNEL, it started matching.  I thought that was odd, so I left ICMP and added an SSH class and put it after the TUNNEL class.  I saw the ICMP match and the tunnel match, but I didn’t see a single match on SSH even though I was SSHed through (not to) the router. 

When I moved SSH above TUNNEL, it started incrementing as it should.  The best that I can tell is that both the original packet and the GRE packet are being evaluated when pre-classification is enabled.  Since all the packets in the lab are going over a GRE tunnel, GRE will always be matched if you assess before everything else.

For the record, I did this lab twice – once with the GRE tunnel encrypted and once without encryption.  The results of the pre-classification were the same in both attempts; GRE matches every time.

Send any ROUTE class vouchers questions my way.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. If you have any questions, the best way to contact me is through Twitter at @aconaway.

More Posts

Follow Me:
Twitter

Leave a Reply

Your email address will not be published. Required fields are marked *