[c-nsp] %FIB-3-NOMEM: Malloc Failure, disabling CEF (Jon Lewis)

Juan C. Crespo R. jcposeidon at cantv.net
Fri Mar 16 10:14:39 EST 2007


Question... is your router getting full BGP table from one ISP? if it 
does, the NPE 300 have no enough memory for both ip tables (MPLS, BGP, 
CEF), try

   1. Create a Prefix List permitting /23
   2. Create a prefix denying 0.0.0.0/0 le 32 but first be sure if your
      ISP is originating one default route  to you, if it dont create
      one static ip route to the interface again the ISP.


Regards :)

cisco-nsp-request at puck.nether.net escribió:
> Send cisco-nsp mailing list submissions to
> 	cisco-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://puck.nether.net/mailman/listinfo/cisco-nsp
> or, via email, send a message with subject or body 'help' to
> 	cisco-nsp-request at puck.nether.net
>
> You can reach the person managing the list at
> 	cisco-nsp-owner at puck.nether.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cisco-nsp digest..."
>
>
> Today's Topics:
>
>    1. %FIB-3-NOMEM: Malloc Failure, disabling CEF (Jon Lewis)
>    2. Re: %FIB-3-NOMEM: Malloc Failure, disabling CEF (Joe Maimon)
>    3. Re: %FIB-3-NOMEM: Malloc Failure, disabling CEF (Jon Lewis)
>    4. Re: TCAM refresher (Florian Weimer)
>    5. Re: TCAM refresher (Tony Li)
>    6. Re: TCAM refresher (Florian Weimer)
>    7. Re: TCAM refresher (Chris Griffin)
>    8. Re: TCAM refresher (Lars Fenneberg)
>    9. Re: TCAM refresher (Tony Li)
>   10. Re: Partial VPN Overlapping IPSec, GRE or what????
>       (Hay Kan Sugeng)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Mar 2007 12:55:41 -0500 (EST)
> From: Jon Lewis <jlewis at lewis.org>
> Subject: [c-nsp] %FIB-3-NOMEM: Malloc Failure, disabling CEF
> To: cisco-nsp at puck.nether.net
> Message-ID: <Pine.LNX.4.61.0703141246340.2752 at soloth.lewis.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> I got paged this morning because one of our routers did this (apparently 
> due to either a memory leak, fragmentation, or both).  Since the router 
> in question does tag-switching to support MPLS VPNs, the result of 
> automatically disabling CEF was pretty undesirable.  I don't suppose 
> there's a config command that would tell the router to do something else 
> (like reboot) when usable memory has been exhausted?
>
> I suspect this is something many with NPE300's and lower can look forward 
> to in the coming months / year or two.
>
> ----------------------------------------------------------------------
>   Jon Lewis                   |  I route
>   Senior Network Engineer     |  therefore you are
>   Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 Mar 2007 14:19:43 -0400
> From: Joe Maimon <jmaimon at ttec.com>
> Subject: Re: [c-nsp] %FIB-3-NOMEM: Malloc Failure, disabling CEF
> To: Jon Lewis <jlewis at lewis.org>
> Cc: cisco-nsp at puck.nether.net
> Message-ID: <45F83CBF.3070509 at ttec.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
>
> Jon Lewis wrote:
>
>   
>> I got paged this morning because one of our routers did this (apparently 
>> due to either a memory leak, fragmentation, or both).  Since the router 
>> in question does tag-switching to support MPLS VPNs, the result of 
>> automatically disabling CEF was pretty undesirable.  I don't suppose 
>> there's a config command that would tell the router to do something else 
>> (like reboot) when usable memory has been exhausted?
>>     
>
> try
>
> exception memory ?
>
>   
>> I suspect this is something many with NPE300's and lower can look forward 
>> to in the coming months / year or two.
>>     
>
> Seen it already quite a few times. Also a product of IOS bugs....
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 14 Mar 2007 13:35:04 -0500 (EST)
> From: Jon Lewis <jlewis at lewis.org>
> Subject: Re: [c-nsp] %FIB-3-NOMEM: Malloc Failure, disabling CEF
> To: Joe Maimon <jmaimon at ttec.com>
> Cc: cisco-nsp at puck.nether.net
> Message-ID: <Pine.LNX.4.61.0703141327320.2752 at soloth.lewis.org>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Wed, 14 Mar 2007, Joe Maimon wrote:
>
>   
>> exception memory ?
>>     
>
> Cool
>
> (config)#exception memory ?
>    fragment  Crash if we can't allocate contiguous memory above limit
>    minimum   Crash if free memory pool shrinks below limit
>
> (config)#exception memory fragment ?
>    <1-4294967294>  bytes
>    io              IO memory
>    processor       Processor memory
>
> (config)#exception memory fragment processor ?
>    <1-4294967294>  bytes
>
> Hmm...so I have to decide where the cutoff is and tell the router to crash 
> (reload) if memory gets low enough (and again for fragmented enough) that 
> some threshold I set is reached.
>
>   
>>> I suspect this is something many with NPE300's and lower can look forward 
>>> to in the coming months / year or two.
>>>       
>> Seen it already quite a few times. Also a product of IOS bugs....
>>     
>
> Yeah, but as all the 256mb routers reach the point where full routes and 
> modern IOS just don't fit, I have a feeling this is going to be seen quite 
> a bit more frequently and widely.
>
> ----------------------------------------------------------------------
>   Jon Lewis                   |  I route
>   Senior Network Engineer     |  therefore you are
>   Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 14 Mar 2007 21:25:50 +0100
> From: Florian Weimer <fw at deneb.enyo.de>
> Subject: Re: [c-nsp] TCAM refresher
> To: "Brian Turnbow" <b.turnbow at twt.it>
> Cc: cisco-nsp at puck.nether.net
> Message-ID: <874pono9m9.fsf at mid.deneb.enyo.de>
> Content-Type: text/plain; charset=us-ascii
>
> * Brian Turnbow:
>
>   
>> The fib is used to populate the tcam.  So yes all 600K routes will
>> not go in , but besides bgp all your local routes will.
>>     
>
> And your ARP table entries.  Of course, Cisco could fix that by
> aggregating entries before they end up in the TCAM: If both
> 192.0.2.8/30 and 192.0.2.12/30 have the same adjacency, you can do
> with a route for 192.0.2.8/29 instead.  But there are probably reasons
> for not doing it this way in the first place, so it's unlikely that
> such a change will arrive in time.
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 14 Mar 2007 14:08:35 -0700
> From: Tony Li <tli at cisco.com>
> Subject: Re: [c-nsp] TCAM refresher
> To: Florian Weimer <fw at deneb.enyo.de>
> Cc: cisco-nsp at puck.nether.net
> Message-ID: <CC5D6199-346F-481F-B805-E092C0E829D6 at cisco.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On Mar 14, 2007, at 1:25 PM, Florian Weimer wrote:
>
>   
>> * Brian Turnbow:
>>
>>     
>>> The fib is used to populate the tcam.  So yes all 600K routes will
>>> not go in , but besides bgp all your local routes will.
>>>       
>> And your ARP table entries.  Of course, Cisco could fix that by
>> aggregating entries before they end up in the TCAM: If both
>> 192.0.2.8/30 and 192.0.2.12/30 have the same adjacency, you can do
>> with a route for 192.0.2.8/29 instead.  But there are probably reasons
>> for not doing it this way in the first place, so it's unlikely that
>> such a change will arrive in time.
>>     
>
>
> Such a change is computationally intensive and would frequently cause  
> problems with processor overload.
>
> Tony
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 14 Mar 2007 22:28:12 +0100
> From: Florian Weimer <fw at deneb.enyo.de>
> Subject: Re: [c-nsp] TCAM refresher
> To: Tony Li <tli at cisco.com>
> Cc: cisco-nsp at puck.nether.net
> Message-ID: <87slc7ms5v.fsf at mid.deneb.enyo.de>
> Content-Type: text/plain; charset=us-ascii
>
> * Tony Li:
>
>   
>>> And your ARP table entries.  Of course, Cisco could fix that by
>>> aggregating entries before they end up in the TCAM: If both
>>> 192.0.2.8/30 and 192.0.2.12/30 have the same adjacency, you can do
>>> with a route for 192.0.2.8/29 instead.  But there are probably reasons
>>> for not doing it this way in the first place, so it's unlikely that
>>> such a change will arrive in time.
>>>       
>
>   
>> Such a change is computationally intensive and would frequently cause
>> problems with processor overload.
>>     
>
> Just out of curiosity, have actually you benchmarked this?
>
> (But I admit, the necessary code changes before you could do this look
> pretty significant.)
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 14 Mar 2007 17:33:58 -0400
> From: Chris Griffin <cgriffin at ufl.edu>
> Subject: Re: [c-nsp] TCAM refresher
> To: Tony Li <tli at cisco.com>
> Cc: cisco-nsp at puck.nether.net
> Message-ID: <45F86A46.5020104 at ufl.edu>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> How about unnecessary specifics in the presence of a valid covering 
> route?  I imagine the concern would be the potential CPU increase if 
> that covering route went away and you had to install a ton of specifics 
> into the FIB, but it might be a good optional feature.
>
> Chris
>
> Tony Li wrote:
>   
>> On Mar 14, 2007, at 1:25 PM, Florian Weimer wrote:
>>
>>     
>>> * Brian Turnbow:
>>>
>>>       
>>>> The fib is used to populate the tcam.  So yes all 600K routes will
>>>> not go in , but besides bgp all your local routes will.
>>>>         
>>> And your ARP table entries.  Of course, Cisco could fix that by
>>> aggregating entries before they end up in the TCAM: If both
>>> 192.0.2.8/30 and 192.0.2.12/30 have the same adjacency, you can do
>>> with a route for 192.0.2.8/29 instead.  But there are probably reasons
>>> for not doing it this way in the first place, so it's unlikely that
>>> such a change will arrive in time.
>>>       
>> Such a change is computationally intensive and would frequently cause  
>> problems with processor overload.
>>
>> Tony
>> _______________________________________________
>> 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/
>>     
>
>   


More information about the cisco-nsp mailing list