So Philip Smith / Geoff Huston's CIDR report becomes worth a good hard look today

Vitkovsk√Ĺ Adam adam.vitkovsky at
Fri Aug 15 08:10:35 UTC 2014

It looks great though I would not want to troubleshoot the RIB to FIB programing errors unless there's a note somewhere saying what abbreviation to search for in FIB.
The other think that comes to mind is that the more specifics could have different backup next-hops programed. 

> From: NANOG [mailto:nanog-bounces at] On Behalf Of Brett
> Frankenberger
> Sent: Thursday, August 14, 2014 4:50 AM
> On Wed, Aug 13, 2014 at 07:53:45PM -0400, Patrick W. Gilmore wrote:
> > > you mean your vendor won't give you the knobs to do it smartly
> > > ([j]tac tickets open for five years)?  wonder why.
> >
> > Might be useful if you mentioned what you considered a "smart" way to
> > trim the fib. But then you couldn't bitch and moan about people not
> > understanding you, which is the real reason you post to NANOG.
> Optimization #1 -- elimination of more specifics where there's a less specific
> that has the same next hop (obviously only in cases where the less specific is
> the one that would be used if the more specific were left out).
> Example: if has the same next hop as, the latter can
> be left out of TCAM (assuming there's not a with a different
> next hop).
> Optimization #2 -- concatenation of adjacent routes when they have the
> same next hop
> Example: If and have the same next hop, leave
> them both out of TCAM and install
> Optimization #3 -- elimination of routes that have more specifics for their
> entire range.
> Example: Don't program in TCAM is,
> an all exist
> Some additional points:
> -- This isn't that hard to implement.  Once you have a FIB and primitives for
> manipulating it, it's not especially difficult to extend them to also maintain a
> minimal-size-FIB.
> -- The key is that aggregation need not be limited to identical routes.
> Any two routes *that have the same next hop from the perspective of the
> router doing the aggregating* can be aggregated in TCAM.  DFZ routers have
> half a million routes, but comparatively few direct adjacencies.
> So lots of opportunity to aggregate.
> -- What I've described above gives forwarding behavior *identical* to
> unaggregated forwarding behavior, but with fewer TCAM entries.
> Obviously, you can get further reductions if you're willing to accept different
> behavior (for example, igoring more specifics when there's a less specific,
> even if the less specific has a different next hop).
> (This might or might not be what Randy was talking about.  Maybe he's
> looking for knobs to allow some routes to be excluded from TCAM at the
> expense of changing forwarding behavior.  But even without any such things,
> there's still opportunity to meaningfully reduce usage just by handling the
> cases where forwarding behavior will not change.)
>      -- Brett

More information about the NANOG mailing list