I think you mean what is best described here: http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt --Aris
Suresh Ramasubramanian <mailto:ops.lists@gmail.com> Thursday, August 14, 2014 04:59 Swisscom or some other European SP has / used to have a limit where they would not accept more specific routes than say a /22 from provider x, so if you wanted to take a /24 and announce it you were SOL sending packets to them from that /24 over provider y.
Still, for elderly and capacity limited routers, that might work.
On Thursday, August 14, 2014, Brett Frankenberger <rbf+nanog@panix.com>
Brett Frankenberger <mailto:rbf+nanog@panix.com> Thursday, August 14, 2014 04:49
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 Patrick W. Gilmore <mailto:patrick@ianai.net> Thursday, August 14, 2014 01:53 On Aug 13, 2014, at 16:42 , Randy Bush <randy@psg.com> wrote:
half the routing table is deagg crap. filter it.
We disagree.
Just because you don't like all more specifics doesn't mean they are useless.
Not everything is about minimizing FIB size. (And RIB size hasn't been relevant for years.) People pay an ass-ton of money to save a few ms off their RTT, if a more specific will allow packets to travel LHR->FRA directly instead of packets going from LHR -> SFO -> FRA, they are useful even if there is a covering prefix.
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.
Randy Bush <mailto:randy@psg.com> Wednesday, August 13, 2014 22:42 half the routing table is deagg crap. filter it.
you mean your vendor won't give you the knobs to do it smartly ([j]tac tickets open for five years)? wonder why.
randy Suresh Ramasubramanian <mailto:ops.lists@gmail.com> Tuesday, August 12, 2014 18:10 512K routes, here we come. Lots of TCAM based routers suddenly become really expensive doorstops.
Maybe time to revisit this old 2007 nanog thread?
http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=99870;pa...
FYI nanog - https://puck.nether.net/pipermail/outages/2014-August/007091.html
[outages] Major outages today, not much info at this time
Teun Vink teun at teun.tv Tue Aug 12 11:42:05 EDT 2014
Hi,
Some routing tables hit 512K routes today. Some old hardware and software can't handle that and either crash or ignore newly learned routes. So this may cause some disturbances in the force.
HTH, Teun
-----------------