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-boun...@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