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

[James Bensley]

On 19 April 2017 at 17:20, Dragan Jovicic <draganj84 at gmail.com> wrote:
> What Cisco originally calls "PIC Core" is simply indirect-next-hop feature
> on routers, same on Juniper. On "flat" architectures without indirect
> next-hop, a failure of an uplink (a core link) on a PE router would require
> this PE to reprogram all BGP prefixes to new directly connected next-hop.
> Depending on your router and number of prefixes this very well may be an
> upward of several dozen of seconds, if not a few minutes. With
> indirect-next-hop feature, a PE router simply updates a pointer from BGP
> next-hop to new interface, making this almost an instantaneous excursion.
> On older routers without it, you may resort to using multiple equal-cost
> uplinks (or LAG interfaces) since in this case you already have a backup
> next-hop in your forwarding table.
>
> What Cisco originally calls "PIC Edge" is ability to install already
> present backup route from another BGP routers into the forwarding table.
> For this you need to:
>
> 1) already have backup route from control plane into RIB (using add path,
> iBGP, additional RR, advertise external, etc),
> 2) install these route into forwarding table ( this is main part as this
> FIB update is largest piece of convergence cake).
> On Juniper, the part of importing routes into FT is, for some reason,
> called "protect core" (and available for inet.0 table post-15.1), and
> 3) the PE router need to detect failure of upstream BGP router or its link.
> One of the ways is to passively include upstream link in IGP, but there are
> others.
>
> Note the difference - in first case BGP next-hop is unchanged, in the
> second, you have a new BGP next-hop altogether.
>
> What Juniper calls "BGP Edge Link Protection" is something different. It
> allows Edge ASBR router to reroute/tunnel traffic from failed CE link over
> core to another ASBR. For this to work the router must not look at IP
> packet (still pointing to failed PE-CE links), hence per-prefix labels are
> used. Juniper very well mentions this. Also this is available only for
> labeled inet/inet6 traffic, not family inet - at least I don't see it
> available in recent versions.
>
> There is also another technology called "Egress Protection", which is
> something different but quite cool.
>
> @OP, depending on how your topology looks like you may benefit from simple
> indirect-nh (aka PIC Core) as this might not need an upgrade. For link
> failure detection on ASBR, you might use BFD, smaller times, even
> scripting, if LOS is not a viable option. But this still means BGP
> convergence. LoS opens some cool options like using same bgp next-hop
> pointing over multiple rsvp tunnels ending on multiple routers.
>
> As for default route, if its installed in FT, I don't see why the router
> wouldn't use this entry in the absence of more specific (bearing all other
> issues with such setup).
> If you use labeled internet traffic you can resolve remote next-hop of
> static route to get a label for it.
>
> BR
>
> -Dragan
> ccie/jncie

Hi,

It might be worth pointing out that on Cisco you need to enable PIC
Core for PIC Edge to work at its best. PIC Core as already mentioned
is just enabling the hierarchical FIB. So for your IGP / global
routing table prefixes they will be covered by backup paths if they
exist (backup path computed and installed into hardware FIB).

For you VPNv4/VPNv6 stuff one must enable PIC Edge with advertise best
external or add path etc. However enabling PIC Edge without PIC Core
means that backup paths will be pre-computed but not programmed into
hardware. With PIC Core enabled, the FIB is arranged hierarchically to
support prefix indirection AND for your IGP (for example) which has
visibility of multiple paths without the need for any additional
features (unlike eBGP which only sees the best paths by default) a PE
can both calculate AND program the backup path into the FIB. With BGP
PIC Edge and no PIC Core eBGP backup paths can be received and
computed but the backup path is not pre-programmed into FIB. There is
still some speed up to this but really if using BGP PIC Edge, PIC Core
should be enabled too.

There are caveats in the Cisco world like 7600s support PIC Core but
to support PIC Edge they have to recirculate all packets so you half
you Pps rate for VPNv4/VPNv6 packets. ASR9000’s have the hierarchical
fib enabled by default and I don’t think if it can be disable.
ME3600/ME3800 don’t have the H-FIB enabled by default but it can be
enabled and it supports VPNv4/VPNv6 prefixes, and so on.

In Juniper land, does one need to activate indirect-next-hop before
you can provide PIC Edge for eBGP vpn4/vpn6 routes?

Is indirect-next-hop enabled by default on newer MX devices / Junos versions?

Cheers,
James.