FRRouting / frr

The FRRouting Protocol Suite
https://frrouting.org/
Other
3.34k stars 1.25k forks source link

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

Open edipascale opened 4 years ago

edipascale commented 4 years ago

(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

edipascale commented 4 years ago

A few clarifications: