I`m do not understand clearly about new behavior of multihop and accept-remote-nexthop command on JUNOS 13.3 and before (9.3, 11.4 etc... ).
I fouund these explanations so I am not able to simplify any different, so I will default to allow someone else to give it ago. I know that Juniper can be difficult to understand and if one cannot find the correct words to use, then it can be hard to understand.
Overview
In some situations, it is necessary to configure a single-hop EBGP peer to accept a remote next hop with which it does not share a common subnet. The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded. The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses. Configuring the accept-remote-nexthop statement allows a single-hop EBGP peer to accept a remote next hop, which restores multipath functionality for routes that are resolved over these next-hop addresses.
"
Release Information
Statement introduced in Junos OS Release 8.5.
Statement introduced in Junos OS Release 9.0 for EX Series switches.
Statement introduced in Junos OS Release 11.3 for the QFX Series.
Description
Specify that a single-hop EBGP peer accepts a remote next hop with which it does not share a common subnet. Configure a separate import policy on the EBGP peer to specify the remote next hop. You cannot configure multihop and accept-remote-nexthop statements for the same EBGP peer.
For Junos OS Release 13.3 and later releases, specify that a multihop EBGP peer accepts a remote next hop with which it does not share a common subnet. This allows working around current resolver limitations to realize multipath forwarding in recursive next-hop resolution scenarios."
================================================================================
yes, it was hidden because it was indirect route, but you can saw on the next-slide, it was accepted when I configured
accept-remote-nexthop or multihop only.
It was hidden because "The default behavior is for any next-hop address received from a single-hop EBGP peer that is not recognized as sharing a common subnet to be discarded." Not becuase it was Indirect.
+++++===========================================================
If we configure multihop , it breaks multipath , right ? Yes
So on Junos 13.3, it doesn`t ? Yes, it still does break multipath.
The ability to have a single-hop EBGP peer accept a remote next hop to which it is not directly connected also prevents you from having to configure the single-hop EBGP neighbor as a multihop session. When you configure a multihop session in this situation, all next-hop routes learned through this EBGP peer are labeled indirect even when they do share a common subnet. This situation breaks multipath functionality for routes that are recursively resolved over routes that include these next-hop addresses.
BGP uses different tables to resolve protocol next-hop for different applications. In a normal BGP application like IPv4, the prefix is learned in the default table inet.0. BGP will try to resolve its protocol next-hop in the table inet.3 first; if fails, it will resolve in the table inet.0.
Understanding Indirect Next Hops
Junos OS supports the concept of an indirect next hop for all routing protocols that support indirectly connected next hops, also known as third-party next hops.
Because routing protocols such as internal BGP (IBGP) can send routing information about indirectly connected routes, Junos OS relies on routes from intra-AS routing protocols (OSPF, IS-IS, RIP, and static) to resolve the best directly connected next hop. The Routing Engine performs route resolution to determine the best directly connected next hop and installs the route to the Packet Forwarding Engine. By default, Junos OS does not maintain the route for indirect next hop to forwarding next-hop binding on the Packet Forwarding Engine forwarding table....so that is why special configuration is needed to accept those indirect nexthops.
I definitly follow this for a clear explanations from one of the experts maybe one who has service provider experience and training. I do not have it.