Cisco IOS Policy-Map stops working after Class-Map changes

Hi all,

Came accross this issue the other day and since i’m currently stuck on a train between London Euston and Manchester, with what could be called a passable excuse of an internet connection, I’ll take a moment to document it, hope it saves someone else some head-scratching.

Issue: If using a Policy-Map based service policy within IOS to filter traffic on an interface and the undelying class-map is edited with any ‘match protocol http <more>‘ statements, the policy-map stops processing traffic, effectivley turning itself off for that interface.

Consider the following, two interfaces;

Vlan 1: 192.168.0.1/24

Loopback 99: 192.168.100.1/24

We the create a simple class-map to match ICMP traffic and use this in a policy-map with a match action of ‘drop’.

Screenshot showing class-map and policy-map

We now assign this to the output of the loopback99 interface, with the following command;

conf t
interface loopback 99
service-policy output TEST_POLICY_1
exit
exit

This should now block ICMP traffic (such as an echo/ping) to the interface IP;

We can also see the policy-map status for the interface, showing packets flowing through the assigned service policy and that drops are occuring;

Here is the issue, when we add/change any match criteria in the class-map (TEST_CLASS_1) relating to HTTP, the policy map stops working.

I also I added a ‘match protocol smtp’  before this, but you’ll just have to trust me that the policy-map continued working after that, only the addition of HTTP inspection caused a failure.

 

And now our traffic fails to pass through the policy-map, allowing ICMP which should be dropped;

The only workaround I have found is to remove the service policy from the interface and then re-add it after a class-map change, this restores correct functionality;

The following further output (too large for a screenshot) shows that while ‘broken’, the traffic was not even hitting the policy-map (as can be seen through traffic counters);

APCI877#sh policy-map interface loopback99
Loopback99


Service-policy output: TEST_POLICY_1
Class-map: TEST_CLASS_1 (match-any)
20 packets, 2000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol icmp
20 packets, 2000 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol http host "bob.com"
0 packets, 0 bytes
5 minute rate 0 bps
drop


Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
APCI877#ping 192.168.100.1 source vlan 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
APCI877#ping 192.168.100.1 source vlan 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
APCI877#sh policy-map interface loopback99
Loopback99
Service-policy output: TEST_POLICY_1
Class-map: TEST_CLASS_1 (match-any)
20 packets, 2000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol icmp
20 packets, 2000 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol http host "bob.com"
0 packets, 0 bytes
5 minute rate 0 bps
drop

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

I have has a search via google and looked around the cisco bug toolkit, but couldnt see anything exactly matching this behaviour. I will be testing on the latest IOS 15.1 at some point (when i’m infront of a router that has a little more flash/ram).

Any suggestions, comments or blaringly obvious known cisco bugs i’ve missed are welcome on this one!

Matt