Jump to content
Sadikhov IT Certification forums
Sign in to follow this  

[tip] Mls Cef Error Action (undocumented Command)

Recommended Posts

Hi @all.


Ever checked the commands entered by default into the configuration ?


I tried to check the dubious looking 'mls cef error action freeze' command but found no documentation thereof.


TAC yielded the following information:


mls cef error action

Command To specify the action to be taken in the event of a FIB fatal error.


Options: mls cef error action {freeze recover reset}


freeze - Allows each protocol to freeze the FIB error. This captures the info and helpful in event of Cisco TAC troubleshooting during system problem.


recover - Allows each protocol to recover from the generic FIB error or a protocol-specific FIB fatal error.


reset - Allows each protocol to clear the data structures and reload the FIB.


Use the mls cef error action freeze command to allow each protocol to freeze the update of the FIB and to debug the condition. Use the mls cef error action recover command to set up the registries to inform the protocol of the error condition and coordinate with the protocols to clearup the data structures and reload the FIB. Use the mls cef error action reset command to clear the data structures and reload the FIB when a FIB error is detected.


Sounds like the command will stall FIB updates after a CEF error occured - and by that possibly kill your routing ...


recover seems to be the much more useful action ... at least the machine should be back after reestablishing the FIB.





Edited by mgerdon

Share this post

Link to post
Share on other sites

I had an issue on an 7609 router, two weeks ago.


Here's a partially config:


interface GigabitEthernet3/1

description Management_class

ip address

no ip unreachables

no ip proxy-arp

ip accounting output-packets



interface GigabitEthernet3/1.101

description Our_company

encapsulation dot1Q 101

ip address BGP_subclass_A.1


interface GigabitEthernet3/1.219

description ISP_1

encapsulation dot1Q 219

ip address ISP_1_IP

no ip redirects


interface GigabitEthernet3/1.401

description ISP_2

encapsulation dot1Q 401

ip address ISP_2_IP

no ip redirects



On this I applied a basic NAT configuration, for one of the equipments connected on Vlan 1. I added:

interface GigabitEthernet3/1

ip nat inside


interface GigabitEthernet3/1.219

description ISP_1

ip nat outside


access-list 10 permit

ip nat inside source list 10 interface interface GigabitEthernet3/1.219 overload


It all worked, then I wanted to remove the NAT config; each time I was entering:

no ip nat inside source list 10 interface interface GigabitEthernet3/1.219 overload


interface GigabitEthernet3/1.219

no ip nat outside


the router freezed for about 1 minute, and the config could not be removed.


Was it caused by this command? (mls cef error action reset)

Share this post

Link to post
Share on other sites

Hi all,


laf_c your problem has nothing to do with mls freeze, but it is due to something else (I don't know what but for sure not related to mls freeze).


About "mls cef error action" the topic is quite interesting as there have been quite some changes in the past 4-5 years.


First of all they all have to do with catalyst 6500 and cisco 7600 which "load" the CEF n hardware (in the FIB TCAM).


Historically in case of hardware issue (faulty hardware, TCAM full etc) the default action was to freeze the TCAM.


That means that no more entries are added or deleted to or from the TCAM and the system keeps forwarding in hardware if the TCAM contains the information. If not the traffic is punted to the CPU and forwarded in software (via software CEF or process switching in the worst scenario).


The other 2 actions were recover and reset. The last is pretty straighforward when the hardware detects an exception (a mls cef error therefore) it reloads the box automatically (or the DFC card if the exception was on a LC with a DFC and not on the PFC).


Recover was pretty awkward and in reality never worked properly.


The default was to freeze the table, that is not so bad after all. If you don't have a FIB that gets modified too often it will still contain the vast majority of prefixes conained in the CEF table, so only some traffic will be software switched. However if you have a BGP session carrying the full internet table flapping you are basically dead... Freeze is useful to troubleshoot the root cause of the mls error as after a reload no info will be available (or little info).


Following CSCek68800 "mls error action freeze default to change from freeze to reset" the defaul action is reset and recover action is removed altogether.

SXF7 and following will have the new default value - this is for the 6500.


For the 7600 CSCsg16956 took care of it, and the new behaviour is available for all SRx trains already.


However in both cases a reset is needed to restore the normal behaviour of the device as there is no way to recover it from an exception.


A third option "reconciliation" maybe will become available sooner or later, that is to reconciliate the discrepancy between the CEF and FIB TCAM tables. However I would not count on it too much as it was requested a few years ago already and it never came true.







Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this