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. adam
From: NANOG [mailto:nanog-bounces@nanog.org] 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 10.10.4.0/22 has the same next hop as 10.10.7.0/24, the latter can be left out of TCAM (assuming there's not a 10.10.6.0/23 with a different next hop).
Optimization #2 -- concatenation of adjacent routes when they have the same next hop
Example: If 10.10.12.0/15 and 10.10.14.0/15 have the same next hop, leave them both out of TCAM and install 10.10.14.0/14
Optimization #3 -- elimination of routes that have more specifics for their entire range.
Example: Don't program 10.10.4.0/22 in TCAM is 10.10.4.0/23, 10.10.6.0/24 an 10.10.7.0/24 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