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

[adamv0025 at netconsultings.com]

Wow, hold on a sec, we’re starting to mix things here,

Sorry maybe my bad, cause I’ve been using Cisco terminology,

 

Let me use juniper terminology:

I’d recommend using Juniper’s “Provider Edge Link Protection for BGP” (Cisco’s BGP PIC Edge). –which in Junos for some reason was supported only for eBGP session in routing-instance –that changes since 15.1. 

-that’s what me and OP is talking about (at least I think that’s what OP is talking about)

Cmd:

set routing-instances radium protocols bgp group toCE2 family inet unicast protection

 

 

What you mentioned below is  Juniper’s “BGP PIC Edge” (Cisco’s BGP PIC Core). 

Cmd:

[edit routing-instances routing-instance-name routing-options]

user at host# set protect core

 

 

adam

 

netconsultings.com

::carrier-class solutions for the telecommunications industry::

 

From: Alexander Arseniev [mailto:arseniev at btinternet.com] 
Sent: Wednesday, April 19, 2017 1:28 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,

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 <mailto: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 <mailto:adamv0025 at netconsultings.com> ; 'Michael Hare'; juniper-nsp at puck.nether.net <mailto: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::