NDB Kernel not sending RTM_DELROUTE

[svenauhagen]

If a route is using neighbours as gateway and the neighbour is deleted, the kernel does not send a RTM_DELROUTE and therefore the NDB cache is incorrect. How to reproduce:

run ip monitor and in a second window do:

ip a a 172.16.1.1/24 dev veth1 ip nexthop add id 100 via 172.16.1.2 dev veth1 ip route add 172.16.101.0/24 nhid 100 ip nexthop del id 100

replace IP and dev with your local settings. The kernel will send a RTM_DELNEXTHOP but no RTM_DELROUTE.

For IPv6 the behaviour can be controlled with a sysctl skip_notify_on_dev_down but not in IPv4. I guess we would need to listen for RTM_DELNEXTHOP remove them from the neighbourhood table and if it is the last entry for a route also delete that route.

What do you think?

Best Sven

[crosser]

That's right, you need to subscribe to RTMGRP_LINK and remove all routes with oif matching the disappearing link. At least, that's what we are doing, and it seems to work.

[svenauhagen]

@crosser thank you for that, that makes sense. There is another case though I am running into. When the interface ipaddress is deleted any neighbours that can not be reached are also deleted.

So to get back to my example:

ip a a 172.16.1.1/24 dev veth1 ip nexthop add id 100 via 172.16.1.2 dev veth1 ip route add 172.16.101.0/24 nhid 100 ip a d 172.16.1.1/24 dev veth1

this will also trigger a RTM_DELNEXTHOP but no RTM_DELROUTE. Do you have that covered by any chance?

[crosser]

We did not run into this use case (yet?), and not handling it.

[crosser]

@svenauhagen your test case looks odd to me. The last command is ip r d 172.16.1.1/24 dev veth1, should it be ip a d 172.16.1.1/24 dev veth1?

[svenauhagen]

@crosser you are correct, that is a copy and paste error. I will fix it above in my post

[svenauhagen]

I pushed a PR for the case that the last address is removed from an interface with multipath routes