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

[Alexander Arseniev]

Actually, You don't need the unnumbered interface at all.

Just 1 line triggers/enables the INH on directly-connected eBGP peers:

set protocols bgp group ebgp neighbor 203.0.113.0 multihop

You may want to set the local-address and TTL for other reasons but it 
is not necessary for INH enablement in this case.

HTH

Thx

Alex


On 19/04/2017 11:51, Alexander Arseniev wrote:
>
> 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 listjuniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>