An MX router running BGP and ISIS-SR with OSPF (or LDP):
set protocols bgp group i1 neighbor 2.2.2.2
set protocols bgp group internal6 type internal
set protocols bgp group internal6 local-address 2001::1
set protocols bgp group internal6 mtu-discovery
set protocols bgp group internal6 family inet6 unicast
set protocols bgp group internal6 peer-as 65001
set protocols bgp group internal6 multipath
set protocols bgp group internal6 neighbor 2001::2
set protocols isis interface xe-1/0/0:0.0 point-to-point
set protocols isis interface lo0.0 passive
set protocols isis source-packet-routing srgb start-label 100000
set protocols isis source-packet-routing srgb index-range 36000
set protocols isis source-packet-routing node-segment ipv4-index 10001
set protocols isis source-packet-routing node-segment ipv6-index 11001
set protocols isis level 1 wide-metrics-only
set protocols isis level 2 wide-metrics-only
set protocols ospf3 area 0.0.0.0 interface lo0.0 passive
set protocols ospf3 area 0.0.0.0 interface xe-1/0/0:0.0 interface-type p2p
set protocols ospf3 area 0.0.0.0 interface xe-1/0/0:0.0 metric 200
Is seeing an issue with the next-hops chosen by BGP. The BGP peer, 2001::2, is sending a route to 123::1:
labroot@squirtle-re0> show route receive-protocol bgp 2001::2
inet.0: 12 destinations, 16 routes (12 active, 0 holddown, 0 hidden)
inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
mpls.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
inet6.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 123::1/128 2001::3 100 I
inet6.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
With a next-hop of 2001::3. The route to that next-hop has multiple protocol paths, OSPF and L-ISIS:
labroot@squirtle-re0> show route 2001::3
+ = Active Route, - = Last Active, * = Both
2001::3/128 *[OSPF3/10] 1d 23:14:23, metric 400
> to fe80::1a2a:d3ff:fecf:780f via xe-1/0/0:0.0
[IS-IS/15] 1d 23:22:52, metric 20
2001::3/128 *[L-ISIS/14] 1d 06:34:32, metric 20
> to fe80::1a2a:d3ff:fecf:780f via xe-1/0/0:0.0, Push 111003
With the OSPF path chosen over L-ISIS:
labroot@squirtle-re0> show route 123::1
123::1/128 *[BGP/170] 00:02:05, localpref 100, from 2001::2
AS path: I, validation-state: unverified
labroot@squirtle-re0> show route 2001::2
2001::2/128 *[OSPF3/10] 1d 23:13:36, metric 200
[IS-IS/15] 1d 23:21:42, metric 10
2001::2/128 *[L-ISIS/14] 1d 06:33:22, metric 10
How can the L-ISIS path be made to be the active next-hop?
In this case, OSPF3 has a lower administrative distance or preference to L-ISIS (10 vs 14) so it wins the tie breaker:
There are a few ways to change this. The first would be to adjust the L-ISIS distance to be lower than OSPF3. This is done via the following configuration:
set protocols isis level 1 labeled-preference 9
set protocols isis level 2 labeled-preference 9
When set, the L-ISIS path is chosen:
123::1/128 *[BGP/170] 00:00:21, localpref 100, from 2001::2
Alternatively, the resolution rib can be set to inet6.3 as a priority with the following:
set routing-options resolution rib inet6.0 resolution-ribs inet6.3
Which tells the route resolution to look in inet6.3:
123::1/128 *[BGP/170] 00:00:05, localpref 100, from 2001::2
Resolution Documentation:
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/resolution-ribs-edit-routing-options.html