[j-nsp] improving global unicast convergence (with or without BGP-PIC)

[adamv0025 at netconsultings.com]

> Michael Hare
> Sent: Tuesday, April 18, 2017 5:51 PM
> 
> Hello,
> 
> Sorry if this is an easy question already covered.  Does anyone on list
have an
> understanding of what happens in the FIB in the following circumstance?
> 
> Simplified topology;
> * Router 1 RIB default points to reject
> * Router 1 RIB has default free feed from attached eBGP neighbor A
> * Router 1 RIB has default free feed from attached iBGP neighbor B (add-
> path)
> 
> I guess what I'm trying to understand, from the perspective of improving
> upstream convergence for outbound packets from our AS, if my default
> route pointed to a valid next hop of last resort am I likely to see an
> improvement (reduction) in blackholing on router 1 during topology
> changes?  The thought being that if Router 1 FIB invalidates next-hop A
> quickly (en masse) packets could match default route with valid next-hop
> while FIB is being re-programmed with more specifics via B?
> 
> I am aware of indirect-next-hop being default on MPC but my understanding
> is this will not work for directly connected eBGP peers?  So if session
with A
> drops (BFD, link, whatever) are routes with next hop to neighbor A
> deprogrammed nearly atomically due to some level of indirection or are
> routes considered one by one until all routes (~600K) have been processed?
> I suspect the latter but perhaps looking for verification.
> 
Hmm I'm not sure about the "indirect next-hops for everyone" proclaimed by
documentation and folks here, but I'd be glad to be proven otherwise. 
Just tried to configure static route with primary and backup(metric 100) NH
and I don't see the backup next hop flag or any indirect NHs (and using the
"show krt" cmd doesn't show anything). 
But even then how good is an indirect-NH if it's not pointing to primary and
backup forwarding-NHs. 
Using "show route extensive" or "show krt" I've always seen INHs only for
BGP routes or next-hops. 
So I think that having default route pointing to backup router won't help
with your convergence, cause the BGP NH and static route NH are not going to
be linked together in a primary-backup fashion.  

> I am aware of BGP PIC but not yet running 15.X [when internet is not in
VRF].
> I am willing to accept that if BGP PIC is the best approach to improving
this
> scenario an upgrade is the best path forward.  I'd be curious to hear from
> anyone who is on 15.1 [or newer] and using MPC4 in terms of perceived code
> quality and MPC4 heap utilization before/after.
> 
Yes BGP Edge Link Protection will definitely help (1M prefixes converged
under 500usec -yup not even a millisecond).  But be aware of one catch on
Junos. 
Since Junos iBGP and eBGP has the same protocol preference (how stupid is
that right?), just by enabling "protection" cmd you can end up in loops
(Juniper forgets to mention this), so in addition to enabling PIC edge you
have to improve protocol preference for eBGP routes (make them more
preferred on the backup node), or enable per-prefix/per-NH VPN labels to
avoid L3 lookup -not applicable in your case.    

Chained composite next-hops where mentioned. 
But this feature places another indirect next hop between VPN-Label and
NH-Label, so not applicable in your case. 
This feature can address a problem of too many VPN-Label to NH-Label pairs. 
So in other words whit this feature it doesn't matter how many VPNs (if per
VPN labels are used) or CEs (if per CE VPN-Labels are used) or prefixes (in
VRF if per prefix VPN-Labels are used) there are advertised by the
particular PE all of them will share just one indirect next hop -so in case
of a primary link failure only one indirect NH per PE needs to be updated
with a backup path NH-Label and that affects all the VPNs advertised by that
router, so it only matters now how many PEs a.k.a unique NH-Labels there are
in the network. 
>From documentation: 
On platforms containing only MPCs chained composite next hops are enabled by
default. 
With Junos OS Release 13.3, the support for chained composite next hops is
enhanced to automatically identify the underlying platform capability on
composite next hops at startup time, without relying on user configuration,
and to decide the next hop type (composite or indirect) to embed in the
Layer 3 VPN label. 


adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::