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

[Alexander Arseniev]

Hello,

<quote>

indirect-next-hop being default on MPC but my understanding is this will 
not work for directly connected eBGP peers

</quote>

Not by default. You can make a directly-connected nexthop appear as 
"indirect" by using unnumbered interface with static /32 route pointing 
to the eBGP peer address.

Example config:

[AS65000]ae4.100{203.0.113.1/31}----{203.0.113.0/31}ae0.100[AS65001]

With usual interface-peering configuration, 203.0.113.0 is NOT seen as 
indirect NH on AS65000 side.

If You reconfigure the AS 65000 side as follows:

set interfaces ae4.100 family inet unnumbered-address lo0.0 
preferred-source-address 203.0.113.1

set interfaces lo0.0 family inet address 203.0.113.1/32

set routing-options static route 203.0.113.0/32 qualified-next-hop ae4.100

set protocols bgp group ebgp neighbor 203.0.113.0 multihop ttl 1

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

HTH

Thx

Alex


On 18/04/2017 17:50, Michael Hare wrote:
> 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.
>
> 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.
>
> Historically the AS I primarily manage has been default free (default pointing to reject), but I'm considering changing that to improve convergence (aware of the security considerations).  As for our "real" topology, adding up all the transit and peering we have our RIB is nearing 6M routes.  We are not doing internet in a VRF.  Our network has add-path 3 enabled.  In some cases our peers/upstreams are on unprotected transport that is longer than I'd like.  Providing a ring and placing the router closer would be nice but not necessarily in budget.
>
> I haven't yet approached our account team to ask about this.
>
> Thanks in advance for any suggestions or pointers for further reading.
>
> -Michael
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp