On Oct 27, 2011, at 3:38 PM, Tima Maryin wrote: > On 25.10.2011 20:21, Brad Fleming wrote: >> Are there any tricks to auto-summarize the contents of a RIB where the >> tributary routes are not originated locally? >> >> Example: >> Input routes: >> prefix: 1.0.0.0/16, next-hop: 5.5.5.5 >> prefix: 1.0.1.0/16, next-hop: 5.5.5.5 >> prefix: 1.0.2.0/16, next-hop: 4.4.4.4 >> prefix: 1.0.3.0/16, next-hop: 5.5.5.5 >> >> Consolidated, Installed routes: >> prefix: 1.0.0.0/14, next-hop: 5.5.5.5 >> prefix: 1.0.2.0/16, next-hop: 4.4.4.4 >> >> Basically a way to consolidate total number of prefixes entering the FIB. >> >> If such a thing existed we could feed non-Juniper, TCAM-based routers a >> smaller table but still maintain the advantages of best path, hot potato >> routing. > > > If you have got some peers/uplinks which are ISPs with full table there will > eventually be scenarios when you will be forced to hack some of you > aggregates with specifics again and again to avoid blackholing. Since > customers of those ISPs tends to use specifics to manipulate inbound traffic. > > > If you're not ISP does 0/0 looks like an option? :)
We're an ISP; just a charitable, not-for-profit one with budget crunch issues right now. :D I think we'll end up doing the aggregation approach and sacrificing the ability to offer BGP services from our aging CAM-based boxes. Fortunately we still have a reasonable amount of CAM; I'm just thinking what we can do before the 2015-2017 timeframe when the table growth will start to become an actual problem. I do very much appreciate all the discussion, links, etc in this thread; I've learned of multiple new draft RFCs and some new ideas on approaching the issue. Thanks! _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
