Why does Junos find multiple next hops only for the active prefix in case BGP multipath is enabled?

Question

I have a Juniper router named r3 with one established eBGP session to router t1(172.16.0.14) and with second established eBGP session to router t2(172.16.0.18). BGP configuration of r3 can be seen below:

root@r3> show configuration protocols bgp group t1-t2    
type external;
peer-as 65222;
multipath;
neighbor 172.16.0.14;
neighbor 172.16.0.18;

root@r3> 

r3 receives the 1.1.1.1/32 prefix over both sessions:

root@r3> show route receive-protocol bgp 172.16.0.14 1.1.1.1/32    

inet.0: 71 destinations, 84 routes (60 active, 0 holddown, 11 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 1.1.1.1/32              172.16.0.14                             65222 I

root@r3> show route receive-protocol bgp 172.16.0.18 1.1.1.1/32    

inet.0: 71 destinations, 84 routes (60 active, 0 holddown, 11 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  1.1.1.1/32              172.16.0.18                             65222 I

root@r3> 

Thanks to multipath configuration option both the 172.16.0.14 and 172.16.0.18 are next-hops for the 1.1.1.1/32 prefix in case of the active route announced by the t1(172.16.0.14) which has the lower RID than the t2. However, only the active route has two next hops calculated:

root@r3> show route 1.1.1.1 detail 

inet.0: 71 destinations, 84 routes (60 active, 0 holddown, 11 hidden)
1.1.1.1/32 (2 entries, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 0
                Address: 0xb634310
                Next-hop reference count: 10
                Source: 172.16.0.14
                Next hop: 172.16.0.14 via ge-0/0/4.0, selected
                Session Id: 0x0
                Next hop: 172.16.0.18 via ge-0/0/7.0
                Session Id: 0x0
                State: <Active Ext>
                Local AS: 65000 Peer AS: 65222
                Age: 2:42 
                Validation State: unverified 
                Task: BGP_65222.172.16.0.14+40876
                Announcement bits (4): 0-KRT 4-BGP_RT_Background 5-Resolve tree 1 7-BGP_RT_Background 
                AS path: 65222 I 
                Accepted Multipath
                Localpref: 100
                Router ID: 4.4.4.4
         BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 0
                Address: 0xd2ecab0
                Next-hop reference count: 9
                Source: 172.16.0.18
                Next hop: 172.16.0.18 via ge-0/0/7.0, selected
                Session Id: 0x0
                State: <NotBest Ext>
                Inactive reason: Not Best in its group - Active preferred
                Local AS: 65000 Peer AS: 65222
                Age: 6:54 
                Validation State: unverified 
                Task: BGP_65222.172.16.0.18+58923
                AS path: 65222 I 
                Accepted MultipathContrib
                Localpref: 100
                Router ID: 5.5.5.5

root@r3> 

Forwarding table if both sessions are established:

root@r3> show route forwarding-table destination 1.1.1.1/32 table default
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.1.1/32         user     0                    ulst  1048580     3
                              172.16.0.14        ucst      601     4 ge-0/0/4.0
                              172.16.0.18        ucst      602     5 ge-0/0/7.0

root@r3>

FIB if only 172.16.0.14 is established:

root@r3> show route forwarding-table destination 1.1.1.1/32 table default
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.1.1/32         user     0 172.16.0.14        ucst      601     5 ge-0/0/4.0

root@r3>

FIB if only 172.16.0.18 is established:

root@r3> show route forwarding-table destination 1.1.1.1/32 table default
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
1.1.1.1/32         user     0 172.16.0.18        ucst      602     7 ge-0/0/7.0

root@r3>

Is this some sort of optimization in Junos that the recursive next hops are found only for the active route?

Answer 1

First, let's clear something up regarding protocol next-hops. Basically, protocol next-hops are the existing next-hop used to resolve the next-hop associated with a prefix in a BGP advertisement. So, if I receive 10.10.10.0/24 with a BGP next-hop of 2.2.2.2, I now have to resolve 2.2.2.2 in order to get there. Let's say 2.2.2.2 is an OSPF route (it can be any protocol for the most part) via int1 and int2, 2.2.2.2 is my protocol next-hop and now I know I can get there via int1 and int2.

However, in your case a protocol next-hop is not needed. EBGP sessions that use the directly connected interface IP's don't need an additional level of recursion, as they already have an ARP entry associated with the interface routes.

Let's look at how resolution would work in your scenario and a scenario where 172.16.0.14 and 172.16.0.18 both resolve via OSPF instead of directly connected interface. Note that drilling into more nuanced detail is probably another question in itself, so I'll abstract some of that away here just to keep it simple.

via OSPF

1.1.1.1 (BGP) ----> 172.16.0.14 (OSPF) ----> via ge-0/0/4.0 (Direct/ARP)
               |
               +--> 172.16.0.18 (OSPF) ----> via ge-0/0/7.0 (Direct/ARP)

via Directly Connected BGP Peers (your scenario)

1.1.1.1 (BGP) ----> 172.16.0.14 via ge-0/0/4.0 (Direct/ARP)
               |
               +--> 172.16.0.18 via ge-0/0/7.0 (Direct/ARP)

Notice that in your scenario, the additional recursion through OSPF isn't required, it can simply leverage the existing next-hops.

Is this some sort of optimization in Junos that the recursive next hops are found only for the active route?

In your scenario, not explicitly, no, but in other scenarios that use a protocol next-hops there are optimizations in place (as I said that's a whole other thing).

I digress, while 1.1.1.1/32 is the same prefix, each peer is still sending it's own copy of it and therefore must be considered for path selection. If you look at the documentation, you'll notice that the routes do indeed make it to the step where multipath routes are added (obviously).

A path is considered a BGP equal-cost path (and will be used for forwarding) if a tie-break is performed after the previous step. All paths with the same neighboring AS, learned by a multipath-enabled BGP neighbor, are considered.

In your case, the .14 copy is selected and installed into the RIB for the reason Jeff Tantsura mentioned (route age) and the FIB entries for .14 and .18 are also installed. If you think about the other BGP route not having both multipath routes active, you'll realize that there really isn't any benefit. Let's say the interface associated with the .18 BGP route dies, .14's copy stays active and the FIB entry for .18 goes away. If the interface associated with .14 dies, then the existing .18 BGP route will be installed and use .18s FIB entry (which is already in the FIB).

Answer 2

If you do show route 1.1.1.1/32 extensive you should see another field Junos calls protocol next-hop which may be less confusing. In the output you've pasted, it is listing all selected, adjacent next-hops, which are determined by resolving the next-hops to the protocol next-hop.

For example, if the protocol next-hop 198.51.100.100 is several layer-3 hops away, and the RIB contains two equal OSPF-learnt routes to 198.51.100.100, the type of display you've pasted would include those two OSPF-learnt next-hops in the active route stanza.

It would be better if Junos labeled these fields differently. We always have to keep in mind next-hop has a complex meaning in the context of BGP.

Answer 3

Few points: The show output above is actually showing multipathing, it is confusing indeed. You could see: Accepted Multipath and Accepted MultipathContrib for secondary (this has some further consequences in BGP processing) In order to validate, take a look at the forwarding table, e.g show route forwarding-table destination 1.1.1.1/32 (should show both next-hops)

The reasons .14 has been chosen as the primary is not because of RID but because it came up first (default Junos behaviour (aka oldest path)), could be changed with: set protocols bgp path-selection external-router-id

Let me know if anything is still unclear