isisd does not correctly handle the removal/addition of ip addresses on an interface

[edipascale]

(put "x" in "[ ]" if you already tried following) [x] Did you check if this is a duplicate issue? [x] Did you test it on the latest FRRouting/frr master branch?

Describe the bug Imagine a simple topology with 2 isisd nodes n connected via a p2p link, where the link interfaces are on the same subnet (say using address 12.0.0.n/24 for node n). The loopbacks are also IS-IS configured and given an IPv4 address (say 7.0.0.n/32). The adjacency is established and routes are exchanged; on node 1 we might see the following:

volta1# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

C>* 7.0.0.1/32 is directly connected, lo, 00:01:35
I>* 7.0.0.2/32 [115/20] via 12.0.0.2, 1-xge2.0, 00:00:27
I   12.0.0.0/24 [115/20] via 12.0.0.2, 1-xge2.0 inactive, 00:00:27
C>* 12.0.0.0/24 is directly connected, 1-xge2.0, 00:01:35

In the kernel you'll see the following:

$ ip route
7.0.0.2 via 12.0.0.2 dev 1-xge2.0 proto 187 metric 20
12.0.0.0/24 dev 1-xge2.0 proto kernel scope link src 12.0.0.1
$

You then go and remove the subnet address from 1-xge2.0 through vtysh.

volta1# configure
volta1(config)# interface 1-xge2.0
volta1(config-if)# no ip address 12.0.0.1/24
volta1(config-if)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

C>* 7.0.0.1/32 is directly connected, lo, 00:03:00
I>* 7.0.0.2/32 [115/20] via 12.0.0.2, 1-xge2.0, 00:01:52
I>  12.0.0.0/24 [115/20] via 12.0.0.2, 1-xge2.0 inactive, 00:01:52

Here we have a couple of issues: firstly isisd doesn't understand that it cannot reach 12.0.0.0/24 though interface 1-xge2.0, and tries to install it; this is not great, but Zebra realizes the issue and prevents the route from being installed. However isisd also doesn't realize that the route to 7.0.0.2/32 is no longer valid, and so it doesn't send any update to zebra about it. The route remains installed in vtysh, but the linux kernel is smarter than that and will have removed it from its table; ip route will not return anything.

If we later add the ip address back, in vtysh it looks like everything is fine, but once again zebra will receive no update from isisd regarding 7.0.0.2/32, and the route will not be installed back in the kernel.

$ ip route
12.0.0.0/24 dev 1-xge2.0 proto kernel scope link src 12.0.0.1
$

Expected behavior isisd should not try to install routes that are only reachable through an invalid nexthop; the kernel rib and zebra's rib should stay in sync.

Versions

• OS Kernel: Linux 4.15.0-88-generic
• FRR Version master (commit 5cb1323)

[edipascale]

A few clarifications:

• If the circuit is only configured for IPv4 and not IPv6, removing the address will make the circuit "unusable" for IPv4 and eventually the adjacency will expire. However if IPv6 is enabled that will never happen, as we will always have a link-local address that makes it IPv6-usable, and hellos are only rejected if we cannot support neither IPv4 nor IPv6. In any case it might take a while for the adjacency to expire this way, and in the meanwhile we are black-holing traffic.

• The commit referenced above tries to address this issue by disabling IPv4/IPv6 on a circuit when the last address for that AF is removed, and re-enabling it (if configured) when the first valid IP address is added. This however doesn't solve the problem if we have multiple IP addresses configured on an interface and only some of them are valid to L3 connect to our neighbor. It also doesn't take into account the possibility that the interface is un-numbered.

• https://tools.ietf.org/html/rfc3787#section-10 has some hints on what we could be doing to properly fix this: only form an adjacency with a peer if either the interface for that circuit is un-numbered or we have a matching IP subnet. I had a look at the code but it looks to me that the information we'd need is all over the place, and I'm struggling to figure out where exactly this check should be implemented. If anyone can point me in the right direction it'd be greatly appreciated.