[j-nsp] Summarize Global Table

Jack Bates jbates at brightok.net
Wed Oct 26 12:59:48 EDT 2011


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


More information about the juniper-nsp mailing list