How does ISIS find a next hop address for a prefix learned by ISIS?

Question

I have two Juniper routers connected like this:

r1[ge-0/0/2] <-> [ge-0/0/3]r2

Both ge-0/0/2 in r1 and ge-0/0/3 in r2 do not have a family inet configured:

root@r1> show interfaces ge-0/0/2 terse
Interface               Admin Link Proto    Local                 Remote
ge-0/0/2                up    up
ge-0/0/2.0              up    up   iso
                                   multiservice

root@r1>

root@r2> show interfaces ge-0/0/3 terse
Interface               Admin Link Proto    Local                 Remote
ge-0/0/3                up    up
ge-0/0/3.0              up    up   iso
                                   multiservice

root@r2>

However, the ISIS adjacency between the two routers is still established. This is expected. r1 advertises routes 192.168.1.1/32 and 172.18.1.0/24 to r2:

Those are not installed to RIB in r2:

root@r2> show route protocol isis

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

root@r2>

I guess this is because there is no next-hop IP address for those two routes? If yes, then how does ISIS find a next hop address for a prefix learned by ISIS when the IP addresses are configured? For example, 172.26.1.1/30 to ge-0/0/2.0 in r1 and 172.26.1.2/30 to ge-0/0/3.0 in r2. Is there a separate TLV for next-hop IP address?

Answer 1

I guess this is because there is no next-hop IP address for those two routes?

Correct, but let's be clear, it's not that one is there and the router can't find it, it's because no next-hop IP address exists. Just because you're advertising and receiving IP TLVs (which Juniper does by default) on a valid adjacency doesn't mean that the underlying reachability mechanism (IP) doesn't have to be there.

For example, if you had valid IPv4 reachability, but were advertising IPv6 TLVs on interfaces without family inet6, you'd see similar behavior.

If yes, then how does ISIS find a next hop address for a prefix learned by ISIS when the IP addresses are configured?

There's nothing special going on, it's derived from SPF computation results. Remember, it's the same algorithm as OSPF.

Is there a separate TLV for next-hop IP address?

No, not explicitly. IS-IS "packets" are actually exchanged over L2. TLV 132 carries interface IP addresses in both IIH and LSPs, based on that the router will ARP for interface IP address to resolve the L2 next-hop. SPF will run against the prefixes being advertised by the adjacent router and the results will be resolved via the interface IP address from TLV 132 that we just resolved via ARP.

...
15:56:55.826054  In 50:00:00:04:00:02 > 09:00:2b:00:00:05, 802.3, length 125: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): L2 LSP, lsp-id 0001.0001.0002.00-00, seq 0x00000002, lifetime  1198s, length 57
15:56:55.826709 Out 50:00:00:03:00:02 > 09:00:2b:00:00:05, 802.3, length 125: LLC, dsap OSI (0xfe) Individual, ssap OSI (0xfe) Command, ctrl 0x03: OSI NLPID IS-IS (0x83): L2 LSP, lsp-id 0001.0001.0001.00-00, seq 0x00000003, lifetime  1198s, length 57
15:56:56.009717 Out 50:00:00:03:00:02 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 20.0.0.1 tell 20.0.0.0
15:56:56.033784  In 50:00:00:04:00:02 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 20.0.0.0 tell 20.0.0.1
...