I'll make a note to add a publicly facing note for CSCtz33305, but the short of it is that the way the ASR1k installs NAT pools into TCAM is not very efficient when a "deny" statement exists in the ACL. I don't remember the exact numbers but a single deny ACL entry can expand out 3x or more (depending on the exact configuration) in TCAM. So you might think that you could fit 1000 lines, but might only get like 250. I can't find a clear answer to this, but it sounds like a deny in the PBR policy could have the same impact (i.e., route-map blah deny 10/permit 20). The bug CSCtz33305 is for development to track work on improving the way they deal with deny entries, but it sounds like the work is very difficult and won't happen overnight.
CSCtz71208 is about the ability to recover from the TCAM exception condition. Before the fix for CSCtz71208 it sounds like deleting the NAT/route-map/ACLs it won't recover from the TCAM exception state. After the fix it sounds like deleting those entries will recover from the exception state. My guess is the NAT configuration is actually exceeding TCAM on the ESP that is installed. You can take a look at "show platform hardware qfp active tcam resource-manager" to see the TCAM utilization. It should be noted that TCAM is shared with interface ACLs, QoS and PBR. If you have a lab box I would expect your configuration could be copy/pasted into it to see the same problem and you could try to test config changes there. I would start by seeing if removing the deny in the NAT route-map makes a difference. Regards, Your friendly neighborhood TAC engineer On Fri, Mar 22, 2013 at 8:00 AM, Simon Lockhart <[email protected]> wrote: > All, > > I'm running an ASR1004 as a centralised CGNAT router. I've got various > pools > defined for different customers, and use a NAT route-map to stop private > IPs > being NAT'd when trying to reach our internal services (where we'd want to > see > the private IPs still). Typical config per customer is: > > ip nat pool cust1-pool-1 xxx.yyy.153.64 xxx.yyy.153.95 prefix-length 27 > ip nat inside source route-map cust1-nat pool cust1-pool-1 overload > ! > ip access-list extended on-net > permit ip any aaa.xxx.128.0 0.0.15.255 > permit ip any bbb.yyy.128.0 0.0.31.255 > permit ip any ccc.zzz.128.0 0.0.127.255 > !| > ip access-list extended cust1 > permit ip 100.65.162.0 0.0.0.255 any > permit ip 100.65.160.0 0.0.1.255 any > ! > route-map cust1-nat deny 10 > match ip address on-net > route-map cust1-nat permit 20 > match ip address cust1 > > After adding another set of this config, I've hit this log message: > > *Mar 22 06:37:54.476 UTC: %CPP_FM-3-CPP_FM_TCAM_ERROR: F0: cpp_sp: TCAM > limit exceeded: Class group nat-cg:1001 could not be successfully attached. > Please remove the class group from the interface. > > On this page > http://www.cisco.com/en/US/docs/routers/asr1000/release/notes/asr1k_caveats_38s.html > > It says: > > - CSCtz71208 > > Symptom: On a Cisco ASR1000 series router, once the error, > CPP_FM-3-CPP_FM_TCAM_ERROR is seen, the only way to recover TCAM is to > reload > the ASR. Removing the config leading to the TCAM exhaustion is not > enough. > > Conditions: This is seen after something leads to the TCAM being exhausted. > This bug only relates to the recovery from the exhaustion, not the > exhaustion > itself. For that, please see bug: CSCtz33305 Deny Statements could > exhaust the > TCAM entries. > > Workaround: Reload the device. > > Looks like this is what I'm hitting, but does anyone know more about this > bug? > I can't seem to see CSCtz33305, but it'd be good to know if there's any > workaround to avoid hitting this issue... > > Many thanks, > > Simon > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
