On an OSPF restart the announcing of an existing loopback address stops

olivettiwetti commented 6 days ago

Description

In our LAB we observe the following: We configure a loopback address via frr.conf that is to be announced. When we "start" the system (after a reboot, or just start the first time the FRR), the announcing works fine and we see on a peer the ip address. With a restart of FRR this announcing fails and is to be reset manually, either by removing the IP via vty or via ip command, followed by re-applying the configuration.

Example configuration:

...
access-list localsite seq 10 permit 240.xxx.xxx.215/32

route-map lanroutes permit 10
  match ip address localsite

interface lo
  ! probing IP on loopback
  ip address 240.xxx.xxx.215/32 label lo:1
  ip ospf passive

ospf
  ...
  redistribute connected metric-type 1 route-map lanroutes
  redistribute static metric-type 1 route-map lanroutes

With a fresh start of the routing suite, the configuration is good:

[devuan-host1:~]# ip addr sh dev lo label lo:1
    inet 240.xxx.xxx.215/32 brd 240.xxx.xxx.215 scope global lo:1
       valid_lft forever preferred_lft forever

... and also learned by a peer:

[ospf-peer2:~]# vtysh -c 'sh ip route ospf' | grep 10.xxx.xxx.10
O>* 27.xxx.xxx.24/29 [110/70] via 10.xxx.xxx.10, eth4, weight 1, 00:02:40
O>* 192.xxx.xxx.0/24 [110/70] via 10.xxx.xxx.10, eth4, weight 1, 00:02:40
O>* 240.xxx.xxx.215/32 [110/70] via 10.xxx.xxx.10, eth4, weight 1, 00:02:40      # <- the route under discussion

After a restart of our routing suite, the route for 240.xxx.xxx.215/32 is missing, though still configured:

# restart FRR
[devuan-host1:~]# /etc/init.d/frr restart
# loopback still configured
[devuan-host1:~]# ip addr sh dev lo label lo:1
    inet 240.80.48.215/32 brd 240.80.48.215 scope global lo:1
       valid_lft forever preferred_lft forever

# but not announced
[ospf-peer2:~]# vtysh -c 'sh ip route ospf' | grep 10.xxx.xxx.10
O>* 27.xxx.xxx.24/29 [110/70] via 10.xxx.xxx.10, eth4, weight 1, 00:01:45
O>* 192.xxx.xxx.0/24 [110/70] via 10.xxx.xxx.10, eth4, weight 1, 00:01:45

Version

The version we run is a devuan system (Excalibur) with FRR v10.0-2:

[devuan-host1:~]# vtysh

Hello, this is FRRouting (version 10.0).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

devuan-host1# sh version
FRRouting 10.0 (devuan-host1) on Linux(6.8.12-amd64).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--sbindir=/usr/lib/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--disable-scripting' '--disable-pim6d' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'LIBS= -latomic' 'PYTHON=python3'
devuan-host1#



### How to reproduce

See description:
* configure a loopback address that is to be announced
* restart the routing suite on the system you announce the loopback address

### Expected behavior

Expected is to see that loopback address announced, as the other networks/addresses are announced.

### Actual behavior

After the restart of the suite, the configured loopback address is not announced anymore.

### Additional context

_No response_

### Checklist

- [X] I have searched the open issues for this bug.
- [X] I have not included sensitive information in this report.

aceelindem commented 2 days ago

I don't see how this worked prior to restart - the class E address is not accepted on the interface.

acee-ubuntu(config)# interface lo acee-ubuntu(config-if)# ip address 240.1.1.215/32 % Configuration failed.

invalid address 240.1.1.215/32

aceelindem commented 2 days ago

Please include on devuan-host1 before and after restart:

show ip ospf interface show ip ospf database router

FRRouting / frr

On an OSPF restart the announcing of an existing loopback address stops #16326

Description

Version