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

[adamv0025 at netconsultings.com]

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::