[c-nsp] ASR100x route tables sanity check

[Mack McBride]

The QFP is actually forwarding in software to begin with (although highly specialized and on a forwarding optimized processor).
Rather than saying software forwarding a better term is needed.

LR Mack McBride
Network Architect

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Lukasz Bromirski
Sent: Saturday, February 04, 2012 4:46 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASR100x route tables sanity check

On 2012-02-04 17:36, Gert Doering wrote:

> On Sat, Feb 04, 2012 at 03:16:18PM +0100, ?ukasz Bromirski wrote:
>> ESP5 on the other hand can store approx. 512k IPv4 routes *OR* 128k
>> IPv6 routes. For a mix of these, rule of thumb is pretty obvious - 
>> you take 4 IPv4 routes for each 1 IPv6 route installed. Please note 
>> however hardware specific checks like the one found on for example 
>> 6500/7600 units with carving of TCAM space are not present here - the 
>> mix will be dynamic.
> What happens if ESP runs out of FIB slots?

That's still a bit complicated issue. Generally, FIB uses the DRAM space in the ESP for storing FIB entries. You can check the state using 'show platform hardware qfp active infrastructure exmem statistics' and look for DRAM numbers. If the DRAM runs out of space, IRAM will be used, but that's "Instruction RAM" and from this point going forward, different bad things can happen, up to and including ESP crash.

As a side note, ASR1k has software forwarding path indeed, but it's "hardware" rate-limited by the QFP. You can check the current situation with punted traffic using following command:
"sh platform hardware qfp active infrastructure punt statistics type per-cause"


> On a 6500, the result is not pretty (falls over to software forwarding 
> for some prefixes, and will never recover if the number of routes in 
> the FIB falls under the threshold again).

That's more complex.

Historically, before the 6500/7600 split, the exception for FIB overflow was to forward *all* traffic using the RIB, so purely control-plane. That was usually killing the box. You could however use hidden 'mls cef exception action freeze|restart|clear' to somehow tune the behavior, but it was not officially supported.

On the 6500 after the split in the 12.2SX train, and after the CSCsq77464, the behavior changed somewhat - if indeed exception happens, system will autoconfigure mls rate-limiter to 'receive' path up to 10kpps, and use that to forward traffic using the RIB table. This is more bearable in real world, but still far from ideal.

On the 7600 however, in the 12.2SR traing and specifically from
12.2(33)SRB3 on, the system will program drop adjacency for the prefixes that can't fit into TCAM FIB.

HTH,
-- 
"There's no sense in being precise when |               Łukasz Bromirski
  you don't know what you're talking     |      jid:lbromirski at jabber.org
  about."               John von Neumann |    http://lukasz.bromirski.net
_______________________________________________
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/