BGP “protocol next hop” resolves to different next-hop address than the same IP using ISIS

Question

I have a BGP-learned prefix 130.130.0.0/24 with protocol next hop 10.0.2.5:

root@r2> show route 130.130.0.0 detail

inet.0: 60 destinations, 61 routes (57 active, 0 holddown, 4 hidden)
130.130.0.0/24 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Address: 0xd30c210
                Next-hop reference count: 6
                Source: 10.0.3.4
                Next hop type: Router, Next hop index: 0
                Next hop: 10.0.4.9 via ge-0/0/3.0, selected
                Session Id: 0x0
                Next hop: 10.0.4.1 via ge-0/0/6.0
                Session Id: 0x0
                Protocol next hop: 10.0.2.5
                Indirect next hop: 0xba9dd80 1048582 INH Session ID: 0x1aa
                State: <Active Int Ext>
                Local AS: 65001 Peer AS: 65001
                Age: 44:28      Metric2: 20
                Validation State: unverified
                ORR Generation-ID: 0
                Task: BGP_65001.10.0.3.4+179
                Announcement bits (2): 0-KRT 5-Resolve tree 4
                AS path: (65000) 65222 I
                Communities: 65412:200
                Accepted
                Localpref: 100
                Router ID: 10.0.3.4

root@r2>

As seen above, the 10.0.2.5 is resolved to next-hops 10.0.4.9(selected) and 10.0.4.1. However, the output of the show route 10.0.2.5 selects a 10.0.4.1 as a next-hop:

root@r2> show route 10.0.2.5

inet.0: 60 destinations, 61 routes (57 active, 0 holddown, 4 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.2.4/30        *[IS-IS/15] 1w5d 02:17:27, metric 20
                      to 10.0.4.9 via ge-0/0/3.0
                    > to 10.0.4.1 via ge-0/0/6.0

root@r2> show route forwarding-table matching 10.0.2.4/30 table default
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.0.2.4/30        user     0 10.0.4.1           ucst      595     5 ge-0/0/6.0

root@r2>

Why is the BGP protocol next hop using a different next-hop address than ISIS?

Answer 1

Why is the BGP protocol next hop using a different next-hop address than ISIS?

Because the BGP next-hop associated with 130.130.0.0/24 is 10.0.2.5. BGP has to resolve the next-hop for that route, which as you pointed out is the IS-IS route. This begs the question, how does IS-IS get to 10.0.2.5 and that is via the interface routes 10.0.4.9 and 10.0.4.1.

Jeff Wheeler is correct in why you're not seeing both routes in the FIB. Assuming this is the RIB:

jhead@r3# run show route 1.1.1.1/32 detail

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
1.1.1.1/32 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Next hop type: Indirect, Next hop index: 0
                Address: 0xce31930
                Next-hop reference count: 2
                Source: 10.10.10.10
                Next hop type: Router, Next hop index: 0
                Next hop: 172.16.0.14 via ge-0/0/0.0, selected
                Session Id: 0x0
                Next hop: 172.16.0.18 via ge-0/0/1.0
                Session Id: 0x0
                Protocol next hop: 10.10.10.10
                Indirect next hop: 0xba3e680 1048575 INH Session ID: 0x142
                State: <Active Int Ext>
                Local AS: 65000 Peer AS: 65000
                Age: 13:48  Metric2: 2
                Validation State: unverified
                Task: BGP_65000.10.10.10.10
                Announcement bits (2): 0-KRT 4-Resolve tree 1
                AS path: I
                Accepted
                Localpref: 100
                Router ID: 10.10.10.10

jhead@r3# run show route 10.10.10.10

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.10/32     *[OSPF/10] 00:14:53, metric 2
                    > to 172.16.0.14 via ge-0/0/0.0
                      to 172.16.0.18 via ge-0/0/1.0

Without Load Balancing Policy:

jhead@r3# run show route forwarding-table destination 10.10.10.10
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.10.10.10/32     user     1 172.16.0.14        ucst      583     8 ge-0/0/0.0

With Load Balancing Policy:

jhead@r3# run show route forwarding-table destination 10.10.10.10
Routing table: default.inet
Internet:
Enabled protocols: Bridging,
Destination        Type RtRef Next hop           Type Index    NhRef Netif
10.10.10.10/32     user     1                    ulst  1048574     4
                              172.16.0.14        ucst      583     6 ge-0/0/0.0
                              172.16.0.18        ucst      584     6 ge-0/0/1.0