Uninstall/Install routes after removing/adding latest IP address from/to the interface

[m-varasteh]

---

Describe the bug

the Linux kernel removes all routes when interface has no IP address. Normally zebra handles this situation for routes with provided NH, but routes for P2P interfaces that are directly connected are not handled correctly and are not removed upon deleting the last IP address set on the interface.

• Did you check if this is a duplicate issue?
• Did you test it on the latest FRRouting/frr master branch?

To Reproduce

create a dummy interface in linux:

ip link add dev temp0 type dummy

setup inteface and route in vtysh:

n1(config)# interface temp0 
n1(config-if)# ip address 4.1.1.1/32
n1(config-if)# no ip address 4.1.1.1/32
n1(config-if)# ip address 4.1.1.1/32
n1(config-if)# q
n1(config)# ip route 99.1.1.1/32 temp0 

remove ip address from temp0

n1(config-if)# no ip address 4.1.1.1/32

Checking Zebra's FIB indicates that the route is installed and is valid, but linux' FIB has no such entry.
Shutting down and waking up the interface installs the route in linux' FIB again.

Expected behavior

Remove all directly connected routes when the last IP address on the interface is gone and add them again when an IP address is set.

Versions

• OS Version: Ubuntu 20.04

• Kernel: Linux 5.13.0-52-generic

• FRR Version: 8.1

[riw777]

I wonder if this is related to the interface being a dummy ... does this happen with a "real" interface as well?

[donaldsharp]

Please try this on master it is probably fixed

[m-varasteh]

Sorry for the late response guys and thanks for the feedback.
@riw777 Real interfaces suffer from the same issue too.
@donaldsharp Right now i can't build from master branch. But I've tested against FRR 8.3 and it still happens. Interestingly, Enabling nexthop groups solves the issue( both in 8.1 and 8.3) but I can't move to using nexthop groups right now.

[riw777]

Then it's possible nexthop groups could have changed the way routes are removed ... I think we need to check on master, though ... :-(

[m-varasteh]

Sorry guys for this really late answer( I had a 2 week off because of a benign Covid infection and after returning, I totally forgot about this issue). I couldn't manage to test this issue with master, but since the future of FRRouting is based on Nexthop Groups and this problem does not occur with them, I suggest we can close this issue.

P.S: It still exists in latest FRR 8.4 Release

[github-actions]

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

[frrbot]

This issue will be automatically closed in the specified period unless there is further activity.