I think you mean what is best described here: http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt
--Aris > Suresh Ramasubramanian <mailto:ops.li...@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+na...@panix.com> > > > Brett Frankenberger <mailto:rbf+na...@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:patr...@ianai.net> > Thursday, August 14, 2014 01:53 > On Aug 13, 2014, at 16:42 , Randy Bush <ra...@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:ra...@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.li...@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;page=1;sb=post_latest_reply;so=ASC;mh=25;list=nanog > > 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 > > -----------------
