I have been working on implementing zone based firewalls for a large client for some time now. They have multiple WAN sites, and lots of network segregation. It took me a while to figure out how to properly design and implement, then I started cruising along making solid progress and seeing the types of results I wanted. Until...
When I got to the first site that had multiple network segments, i.e. multiple zones, with traffic needing to be specified between each zone, I ran into this error when applying one of my Policy-maps:
% No more than 1023 classmaps can be defined.
I certainly have a lot of class-maps on this router, but no way near 1023. I'm also using many of the class-maps multiple times, but I would still guess that the aggregate is a couple of hundred tops. So what is this error? What causes it? And most importantly, how do I make it go away so I can move forward?
I'm happy to provide a scrubbed config, etc to anybody that could help. But before I put in the effort, I want to see if anybody replies to me. On the whole big Internet, I only get a single match when Googling for this error which takes me to this forum where somebody posted the same problem last year, but never got a reply.
Cool post never seen this before.
Can you provide us the version you are running so I can start doing my work here
Seems like you are hitting this bug: CSCsv49421
Incorrect error message " No more than 1023 classmaps can be defined.".
The issue here seems to be more like a software limitation, some ZBF features create invisible internal
class-maps, about 5 class-maps per inspection rule, + the real # of class-maps you will most likely
get a total of more than 1023.
Looks like there is not a real solution to this problem at the moment, so the workaround is to re-design the ZBF to have less class-maps and inspection rules.
I hope this helps.
We really need to see the version you are running in order to help....
Here is a bug ID CSCsv49421 in case you are running :
Rate all the helpful posts, that is as important as a thanks,
Sorry for the delay, busy morning.
Cisco CISCO3925-CHASSIS (revision 1.0) with C3900-SPE100/K9 with 999424K/49152K bytes of memory.
Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.1(4)M2, RELEASE SOFTWARE (fc1)
I opened a TAC case last night as well. Got a reply that more or less says that you can't have more than 130 class-maps applied. Something about each class map creates 7 internal class maps. The solution: Delete class-maps. Thank you Cisco!
Correct, that's the bug I just sent you.
Please mark the question as answered so future users can learn from this.
We are having the same problem on Cisco 2901 ISR but we are only able to define 22 class maps! This bug needs to be fixed. 22 class maps are not adequate for this performance router. There is no mention of this severe limitation in the pre-sales product information.
Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.1(4)M4, RELEASE SOFTWARE (fc1)
Two EHWIC 4 port Gigabit L2 Switch Cards installed, two more available slots.
I have openned a TAC and will post the results.
Update: Jan 11, 2013 = TAC Results
The class-maps value with respect to the limitation can be calculated by counting the Actions defined in the ZBF policies. These Actions are identifiable as the following key words in the "show run" output; where these key words are on lines by themselves within the scope of policy definitions. The key words are: inspect, pass, drop, deny, log (and maybe some others)
The formula for calculating the class-maps value with respect to the limitation is:
(inspect Actions count)x10 + (others Actions counts)*1 = value that should be less than 1023
Note: The multiplier value 10 for the inspect Actions count was increased from the previous value 7 with the implementation of IPv6.
For example (not confirmed):
policy-map type inspect PM_LAN_DMZ
class type inspect CM_SERVER
class type inspect CM_TRUST
class type inspect CM_ICMP
policy-map type inspect PM_DMZ_LAN
class type inspect CM_SERVER
!! The Actions count result from the above 2 policies with respect to the class-maps limitation of 1023 is: (4 x 10) + 2 = 42
!! ( 4 inspects ) x 10 = 40
!! ( 2 drops [default Actions] ) x 1 = 2
From the above example, it is easy to see how this limitation is a constraint to deploying Zone Based Firewalls where there may be more than a few security zones. It is easy to see why my ZBF configuration fails when I try to define individual zone pair policies for 9 security zones + self zone.
Consider the formula: Zone-Pairs = Zones_Count * (Zones_Count - 1).
If only 1 inspect action is used per policy and each zone pair has its own separate policy, then
IF Actions_Value = (inspect*10 + default*1) x Zone-Pairs
AND Action_Value < 1023
THEN Zone-Pairs <= 1023 / 11 
The result is that when adding more than 1 inspect or more than 3 other class-map policy actions to a 9 zone (plus self) ZBF configuration will exceed the 1023 limit and break it. I haven't actually tested this. However, I experienced hitting the limitation a lot before learning about the methods for determining the value the limit relates to. The reference to "class-maps" is misleading. I hit the limitation with only 2 class-maps in my 9+1 ZBF configuration!
My conclusions for this TAC are:
1) The work around is to use as few class-maps in policies as possible and to extensively use ACLs within the class-map definitions.
2) The best practices to manage class-maps limitation is to calculate the value with respect to the limitation using the inspect(10x) + other(1x) formula.
3) The corrective action for this case appears to require Cisco to make modification to the IOS or even router firmware.
The result of the TAC with respect to corrective action is that this bug will be managed by bug ID CSCsv49421. The corrective action discussed in the TAC is that Cisco developers will try to reduce the value associated with the multiplier for inspect Actions.
My concerns regarding bug ID CSCsv49421 are:
1) It is given very low priority.
2) It is for an outdated version of the IOS
3) The work around is miss-leading and does not really work around the constraint
My advice as a small business Cisco customer is that this issue be escalated in priority, updated to reflect that the issue persists in the current IOS, and the limitation be either eliminated or at least increase the ZBF configuration capacity with respect to this limitation.