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

Alexander Arseniev arseniev at btinternet.com
Wed Apr 19 08:27:53 EDT 2017


Hi there,

BGP PIC for inet/inet6 is primarily for complete ASBR failure use case:

When the BGP Prefix Independent Convergence (PIC) feature is enabled on 
a router, BGP installs to the Packet Forwarding Engine the second best 
path in addition to the calculated best path to a destination. The 
router uses this backup path when an egress router fails in a network 
and drastically reduces the outage time. You can enable this feature to 
reduce the network downtime if the egress router fails.

https://www.juniper.net/techpubs/en_US/junos/topics/concept/use-case-for-bgp-pic-for-inet-inet6-lu.html 


The original topic was for eBGP peer failure use case.

I admit You could make BGP PIC to work for the original topic scenario 
if You don't do eBGP->iBGP NHS on ASBR and inject eBGP peer interface 
subnet into Your IGP and into LDP/RSVP (if LDP/RSVP are in use).

HTH

Thx
Alex


On 19/04/2017 13:21, adamv0025 at netconsultings.com wrote:
>
> I see, so it’s sort of a “half way through” solution, where the 
> convergence still needs to be done in CP and then when it comes to DP 
> programming –that’s going to be fast cause just one INH needs to be 
> reprogramed.
>
> Not sure I‘m convinced though, would rather recommend upgrading to 
> 15.1 to get PIC capability for inet0.
>
> adam
>
> netconsultings.com
>
> ::carrier-class solutions for the telecommunications industry::
>
> *From:*Alexander Arseniev [mailto:arseniev at btinternet.com]
> *Sent:* Wednesday, April 19, 2017 1:09 PM
> *To:* adamv0025 at netconsultings.com; 'Michael Hare'; 
> juniper-nsp at puck.nether.net
> *Subject:* Re: [j-nsp] improving global unicast convergence (with or 
> without BGP-PIC)
>
> Hi there,
>
> The benefit is that value of INH mapped to a 100,000s of prefixes can 
> be quickly rewritten into another value - for a different INH pointing 
> to another iBGP peer.
>
> Without INH, the forwarding NH value of EACH and EVERY prefix is 
> rewritten individually and for longer period of time.
>
> Your example of "correctly programmed INH" with LFA show 2 
> preprogrammed forwarding NHs which is orthogonal to the original topic 
> of this discussion.
>
> INH could be preprogrammed with one or multiple forwarding NHs, and to 
> achieve "multiple forwarding NHs" preprogramming, one uses ECMP, 
> (r)LFA, RSVP FRR, etc.
>
> HTH
>
> Thx
>
> Alex
>
> On 19/04/2017 12:51, adamv0025 at netconsultings.com 
> <mailto:adamv0025 at netconsultings.com> wrote:
>
>         Of Alexander Arseniev
>
>         Sent: Wednesday, April 19, 2017 11:51 AM
>
>         - then 203.0.113.0 will appear as "indirect" and You can have the usual
>
>     INH
>
>         benefits. Example from my lab:
>
>         show krt indirect-next-hop | find "203.0.113."
>
>         Indirect Nexthop:
>
>         Index: 1048592 Protocol next-hop address: 203.0.113.0
>
>             RIB Table: inet.0
>
>             Policy Version: 1                     References: 1
>
>             Locks: 3                              0x9e54f70
>
>             Flags: 0x2
>
>             INH Session ID: 0x185
>
>             INH Version ID: 0
>
>             Ref RIB Table: unknown
>
>                   Next hop: #0 0.0.0.0.0.0 via ae4.100
>
>                   Session Id: 0x182
>
>                 IGP FRR Interesting proto count : 1
>
>                 Chain IGP FRR Node Num          : 1
>
>                    IGP Resolver node(hex)       : 0xb892f54
>
>                    IGP Route handle(hex)        : 0x9dc8e14      IGP rt_entry
>
>         protocol        : Static
>
>                    IGP Actual Route handle(hex) : 0x0            IGP Actual
>
>         rt_entry protocol : Any
>
>         Disclaimer - I haven't tested the actual convergence with this setup.
>
>     But what good is an indirect next-hop if it's pointing to just a single
>
>     forwarding next-hop??
>
>     Example of correctly programed backup NHs for a BGP route:
>
>     ...
>
>     #Multipath Preference: 255
>
>     Next hop: ELNH Address 0x585e1440 weight 0x1, selected  <<<eBGP primary path
>
>     Next hop: ELNH Address 0x370c8698 weight 0x4000               <<< PIC backup
>
>     via iBGP
>
>        Indirect next hop: 9550000 1048589 INH Session ID: 0x605
>
>           Next hop: 10.0.20.1 via ae1.0 weight 0x1 <<< IGP primary path
>
>           Next hop: 10.0.10.1 via ae0.0 weight 0xf000 <<< LFA backup path
>
>     -I doubt you can get this with a static default route
>
>     For the above you need to allow for multiple NHs to be programed into FIB
>
>     using:
>
>     set policy-options policy-statement ECMP then load-balance per-packet
>
>     set routing-options forwarding-table export ECMP
>
>     adam
>
>     netconsultings.com
>
>     ::carrier-class solutions for the telecommunications industry::
>



More information about the juniper-nsp mailing list