Ahh.. good point. I didn't think about the problem from the machine's standpoint. It would need a target / hard number of prefixes or the table would be the exact same.
Thanks for the response! On Oct 25, 2011, at 11:56 AM, Stefan Fouant wrote: > You can use aggregate > /generated routes which require more specific contributing routes to become > active, and then only advertise the protocol aggregate routes to your > downstream nodes that have smaller tables, however you still need to create > the aggregates which is a manual process. > > You can get pretty creative however, in your definition of aggregates, so > that they can encompass a large number of specifics - for example, if your > downstream node only supported a FIB of a few routes, you could create 2 > aggregates on the upstream node, perhaps 0/1 and 128/1. This is an extreme > example, but you get the idea. > > As far as I know, there are no ways to automatically summarize along the > lines of what you are getting at because routers aren't intelligent enough to > determine what prefix masks to use for summarization without user input. > > What you would need to accomplish what you are describing is some way to tell > the device that you want to summarize all the routing information into x > number of prefixes, and then have the router automatically compute the best > summaries where routing information overlaps and can be consolidated into a > single prefix/mask combination. > > Stefan Fouant > JNCIE-SEC, JNCIE-SP, JNCIE-ER, JNCI > Technical Trainer, Juniper Networks > > Follow us on Twitter @JuniperEducate > > Sent from my iPad > > On Oct 25, 2011, at 12:21 PM, Brad Fleming <bdfle...@gmail.com> 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. >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
