On 10/26/2011 1:07 AM, Robert Raszuk wrote:
As described to Shane semantically this is identical in default behaviour as installing all prefixes into RIB and FIB. However I would argue that if you do it within the POP you can do much better savings that the default behavior. But this is perhaps out of scope of this thread ;-)
It still doesn't address the OP, for auto summarization. What you have described is just suppression of specific routes when they match the already advertised aggregate. Some savings, but a different layout.
Also, both mechanisms, while perhaps having the right view on the local router, do NOT necessary maintain the same forwarding path. Consider:
ASBR #1: 10.0.0.0/23 and 10.0.0.0/24 and 10.0.1.0/24 have same next-hops, so only 10.0.0.0/23 is sent on via IBGP ASBR #2: 10.0.0.0/23 and 10.0.0.0/24 have same next hop, but 10.0.1.0/24 is different next hop. 10.0.0.0/23 and 10.0.1.0/24 are sent on via IBGP.
Internal router will always use ASBR #2 for 10.0.1.0/24, even if ASBR #1 was originally better. The workaround, is if ASBR #1 see's the more specific from ASBR #2, he goes ahead and duplicates 10.0.1.0/24 even though it's more specific. This adds additional churn in the RIB when scaled. It also assumes that ASBR #1 will see everything ASBR #2 sees, which in today's traffic engineering world is not always the case. Finally, you end up in an interesting position, as now ASBR #2 see's the /24, so on route withdrawl of 10.0.1.0/24 from one of ASBR #2's peers, allowing 10.0.1.0/24 to be summarized, it cannot, as it still see's ASBR #1's more specific. Which isn't necessarily bad. It reduces effectiveness, but it also reduces churn in the RIB, which the workaround would already have a lot of.
Jack _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
