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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
