Jump to content


[tip] Mls Cef Error Action (undocumented Command)


  • Please log in to reply
2 replies to this topic

#1 mgerdon

mgerdon

    Super Member

  • Veterans
  • PipPipPipPip
  • 981 posts
  • Location:Germany

Posted 23 September 2006 - 05:31 PM

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.

regards,

Marcus

Edited by mgerdon, 03 November 2006 - 04:33 AM.

  • 0

#2 laf_c

laf_c

    Firewalls&Routing specialist

  • Members
  • PipPipPipPipPip
  • 1787 posts
  • Gender:Male
  • Location:Romania
  • Interests:Networking, tenis and chess

Posted 26 June 2009 - 07:37 PM

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

Here's a partially config:

interface GigabitEthernet3/1
description Management_class
ip address 10.0.0.1 255.255.255.0
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 255.255.255.0
!
interface GigabitEthernet3/1.219
description ISP_1
encapsulation dot1Q 219
ip address ISP_1_IP 255.255.255.224
no ip redirects
!
interface GigabitEthernet3/1.401
description ISP_2
encapsulation dot1Q 401
ip address ISP_2_IP 255.255.255.252
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 10.0.0.0 0.0.0.255
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
or
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)
  • 0

#3 sabbione

sabbione

    Advanced Member

  • Members
  • PipPipPip
  • 217 posts
  • Gender:Male
  • Location:Belgium

Posted 26 June 2009 - 11:34 PM

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.

Sabbione




  • 0





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users