[FROG] looking for expert opinion on whether this is normal

[Ian Veach]

Thanks Donald.  I ran ip monitor, and it showed the del/add’s, but not what was causing it.

I downgraded both frr and NetworkManager to no avail.  I downgraded NM again, and now the issue seems to not be occurring.  So I’m still not sure why, but thanks to you I know it’s not normal, and that the culprit lies somewhere in either NetworkManager, or in my configuration of it.  I’ll upgrade frr back to current, and then start investigating more.  I’d suspect it’s NM that’s doing this for reasons unknown (I’ll start a trace and/or open a ticket with RH)date

I don’t remember and have my notes in front of me of when I first set up frr, but I didn’t have a lot of resources to learn against when I did.  I fumbled through a bit of configs, and remember not being able to use loopback (like we did with quagga), and not being able to use frr without defining the IPs somewhere at the OS level (and since RHEL moved away from the network-scripts configs, NM was my only logical option).  I had read to use a dummy device, and add IPs to it (with method: manual).  That seemed to work, and similar to quagga (except the IPs were on lo0) in that both the OS and FRR seemed to want to define the IPs.

[root at redacted:~]# nmcli con
NAME      UUID                                  TYPE      DEVICE
ens192    8d7fe6b4-da89-4095-90d7-f2a7d72de5d2  ethernet  ens192
services  5de48daf-c2b0-401a-950a-94ce0d7a0b05  dummy     services
lo        610d9dba-d14d-430c-898b-8b1c7b84838c  loopback  lo

I guess the trick is to either find a bug in NM, or to somehow tell it to stop messing with that dummy interface…

Ian

From: Donald Sharp <donaldsharp72 at gmail.com>
Sent: Friday, July 5, 2024 4:30 PM
To: Ian Veach <iveach at nshe.nevada.edu>
Cc: frog at lists.frrouting.org
Subject: Re: [FROG] looking for expert opinion on whether this is normal


⚠ External Email:
Something is deleting and then re-adding back the ip address assigned to the interface that 10.10.205.4/32<http://10.10.205.4/32> is applied to.  You should be able to see that with a `ip monitor address`.  There is nothing in FRR that does this type of activity so I cannot guess as to what is causing this to happen.

donald

On Fri, Jul 5, 2024 at 3:37 PM Ian Veach <iveach at nshe.nevada.edu<mailto:iveach at nshe.nevada.edu>> wrote:

We’re tracking down something that might be an issue – we’re not sure.  We don’t normally run frr with all debug logging turned on, and don’t know if this behavior is normal or not (we don’t have much to compare it to).

Every 30 seconds, with logging on, we see this in the logs (for each interface with route):

2024 Jul  5 11:31:41 hostredacted [daemon.debug] ospfd[960266]: [JZFS1-TNQFD] Zebra: interface services address delete 10.10.205.4/32<http://10.10.205.4/32>
2024 Jul  5 11:31:41 hostredacted [daemon.debug] ospfd[960266]: [PH9HB-NQMHW] Zebra: interface services address add 10.10.205.4/32<http://10.10.205.4/32> vrf default id 0

It seems like this is flapping the interface to us, but maybe it’s a normal part of frr internals to do so?  Is this normal for frr to delete and add the interface every 30 seconds?

Functionally, OSPF and our anycast DNS seems to be running ok.  But our monitoring has missed some pings (which could be explained with the interface delete/add).

(this is on rhel9, frr-8.5.3-4, although I also get the same behavior when I downgrade to frr-8.3.1-11)

Thank you for any input!
PUBLIC RECORDS NOTICE: In accordance with NRS Chapter 239, this email and responses, unless otherwise made confidential by law, may be subject to the Nevada Public Records laws and may be disclosed to the public upon request.
_______________________________________________
frog mailing list
frog at lists.frrouting.org<mailto:frog at lists.frrouting.org>
https://lists.frrouting.org/listinfo/frog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/frog/attachments/20240705/dbaecf74/attachment-0001.htm>