[c-nsp] ASR1004 and NAT limitation?

[Pete Lumbis]

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 <simon at slimey.org> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>