[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