[c-nsp] Whats happens when TCAM is full on 7600/RSP720RSP-3CXL?

[Łukasz Bromirski]

Hi,

> On 18 Sep 2020, at 11:50, Rolf Hanßen <nsp at rhanssen.de> wrote:
> 
> Hi,
> 
> at least for Sup720-3B(XL) and Sup-2T it results in number 1 for the
> family that hit the limit.
> 
> So in most cases it will look that way:
> #show mls cef exception status
> Current IPv4 FIB exception state = TRUE
> Current IPv6 FIB exception state = FALSE
> Current MPLS FIB exception state = FALSE
> 
> And yes, the box will drop down to a few MBit of Traffic.

Performance will depend on where the traffic is going. If it’s
going to unaffected prefixes, it will be still hardware forwarded.

For traffic going to prefixes that failed to be installed in HW,
resulting performance will be similar to what you can get on those
pretty small, non-x86 CPUs. 

There’s no easy way to clean up HW after failure to program it and
then somehow “split” prefixes between hardware only and software
only. With Sup2T and newer we have an option to check if ACL/QoS
and other policies will fit before even trying to program them
(so called ‘atomic’ commit), but that’s not the case for FIB.
The only way going forward is to reload the box after making sure
it won’t get into the same time after re-establishing routing
protocol adjacencies and getting prefixes again.

Set up 'maximum-prefixes' on your eBGP sessions to sensible value
depending on PFC/DFC models and you should be fine. Also, there’s
whole guide how to adjust MLS CEF scale numbers on 6500/7600:
https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html

-- 
Łukasz Bromirski
CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A