time-range BUSINESSHOURS
 periodic daily 8:00 to 17:00
!
ip access-list extended PINGS
 permit icmp any any time-range BUSINESSHOURS
!
class-map match-all PINGS
 match access-group name PINGS
!
policy-map PM-F0/0-OUT
 class PINGS

First, I set the router’s time to outside of the time range and sent some pings over.

R1#sh clock
00:01:13.107 UTC Wed Apr 28 2010
R1#sh access-lists
Extended IP access list PINGS
    10 permit icmp any any time-range BUSINESSHOURS (inactive)
R1#sh policy-map int f0/0
 FastEthernet0/0

  Service-policy output: PM-F0/0-OUT

    Class-map: PINGS (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: access-group name PINGS

    Class-map: class-default (match-any)
      11 packets, 1140 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Alright, that’s expected. Now let’s set the clock to within the time range and repeat.

R1#sh clock
13:00:12.887 UTC Wed Apr 28 2010
R1#sh access-lists
Extended IP access list PINGS
    10 permit icmp any any time-range BUSINESSHOURS (active) (10 matches)
R1#sh policy-map int f0/0
 FastEthernet0/0

  Service-policy output: PM-F0/0-OUT

    Class-map: PINGS (match-all)
      10 packets, 980 bytes
      5 minute offered rate 0 bps
      Match: access-group name PINGS

    Class-map: class-default (match-any)
      20 packets, 1970 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

How about that?  Time-based ACLs seems to work with policy-maps.  I didn’t know that.

Part of the lab was to identify HTTP traffic coming into F0/0 and mark it as CS3.  That’s pretty easy, right?  Of course, the lab I made up was a little more complicated, but the point comes clear with a simpler example.

class-map match-all HTTP
 match protocol http
!
policy-map PM-F0/0-IN
 class HTTP
  set dscp cs3
!
interface FastEthernet0/0
 service-policy input PM-F0/0-IN

I fired off a small script on TestHost1 to repeatedly do NMap scans on TCP/80 of TestHost2 to generate some traffic. 

root@bt:~#while ( true ) do nmap -sT -p 80 -v -n 172.16.2.101; done

I let that run for a while and checked out the service policy on F0/0; there were absolutely no matches on that class.

R1#sh policy-map int f0/0 input class HTTP
 FastEthernet0/0

  Service-policy input: PM-F0/0-IN

    Class-map: HTTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http
      QoS Set
        dscp cs3
          Packets marked 0

I thought that was strange, so I kept the script running and captured the traffic coming out of S1/0.  Looking at the packets in Wireshark showed that none of the HTTP packets were showing up as being marked as CS3; they’re all set to the default DSCP value.

No matter how many NMap scans cycled through, the class never incremented a bit.  I let it run for two full minutes and generated a few hundred HTTP packets, but there was still nothing.

On a whim, I enabled NBAR protocol discovery on F0/0 to see if that would shed any light on my mess.  Guess what I found.  That’s right; there were no HTTP matches to NBAR, either.  That makes sense since the class-map I defined uses the NBAR protocol.  Alright, so it seems that it’s NBAR that doesn’t see the packets as HTTP, but why?

Looking through the packet captures again, I noticed that there was no real data in the streams.  I saw the 3-way TCP handshake (a.k.a., my signature wrestling move) and then a RST,ACK.  I only told NMap to check if the port was open, so I changed the while loop a bit and enabled version detection with the “-sV” flag.  This time when I can the script, NMap was actually getting the HTTP banner.  It was much traffic, but it was an actual HTTP conversation, so I checked NBAR again.  Success!  The same for the class, too. 

For craps and smiles, I created a class-map that matched SIP, added it to the same policy-map, and set NMap after TCP/5060 without version detection.  Without having a real SIP conversation, the class counters incremented as long as I was sending packets.  That would seem unexpected until you realize that NBAR has some advanced knowledge of HTTP; you can actually match on URLs, hostnames, and MIME-types.  I guess that means it also know when a real HTTP conversation is taking place.

To finish out the testing, I added an ACL to the router that matched any-any-eq-80.  I made the class-map into a match-any and added the ACL.  Since the ACL just matches the destination port and doesn’t care what the content is, every packet sent matched the class as expected.  I remember reading several places and seeing a couple videos that said that you can use NBAR matching and ACLs interchangeably.  That may not really be true when it comes to HTTP.

Send any Cisco learning credits questions my way.

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.

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.

class-map ICMP
 match protocol icmp
!
policy-map PM-S1/0-OUT
 class ICMP
!
interface S1/0
 service-policy output PM-S1/0-OUT
!
interface tunnel 0
 qos pre-classify

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.

R1#sh policy-map int s1/0
 Serial1/0

  Service-policy output: PM-S1/0-OUT

    Class-map: ICMP (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: protocol icmp
        0 packets, 0 bytes
        5 minute rate 0 bps

    Class-map: class-default (match-any)
      467 packets, 39832 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

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.

class-map match-any TUNNEL
 match protocol gre
!
policy-map PM-S1/0-OUT
 class TUNNEL
 class ICMP

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.

R1#sh policy-map int s1/0
 Serial1/0

  Service-policy output: PM-S1/0-OUT

    Class-map: TUNNEL (match-any)
      441 packets, 49392 bytes
      5 minute offered rate 2000 bps
      Match: protocol gre
        441 packets, 49392 bytes
        5 minute rate 2000 bps

    Class-map: ICMP (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: access-group name ICMP
        0 packets, 0 bytes
        5 minute rate 0 bps

    Class-map: class-default (match-any)
      467 packets, 39832 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

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. 

R1#sh policy-map int s1/0
 Serial1/0

  Service-policy output: PM-S1/0-OUT

    Class-map: ICMP (match-any)
      252 packets, 28224 bytes
      5 minute offered rate 0 bps
      Match: access-group name ICMP
        252 packets, 28224 bytes
        5 minute rate 0 bps

    Class-map: TUNNEL (match-any)
      5 packets, 440 bytes
      5 minute offered rate 0 bps
      Match: protocol gre
        5 packets, 440 bytes
        5 minute rate 0 bps

    Class-map: SSH (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: access-group name SSH
        0 packets, 0 bytes
        5 minute rate 0 bps

    Class-map: class-default (match-any)
      547 packets, 46588 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

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.