ripd: non-increasing sequence number after restart/reboot

[ffourcot]

Hello,

On Debian system, after upgrading from bullseye (frr 7.5.1) to bookworm (frr 8.4.4) we lost some RIP connections with Cisco/Juniper routers. ripd was still accepting routes and everything looks fine on Debian system, but RIP packets are dropped by remote routers. We are using MD5 authentication.

After debugging and git bisect, it looks that this commit introduced the issue for us: 1568e88

I cannot fully blame remote routers, since we can read in RFC 4822:

      SEQUENCE NUMBER
         An unsigned 32-bit sequence number.  The sequence number MUST
         be non-decreasing for all messages sent from a given source
         router with a given Key ID value.

So at each restart of ripd, we go back to use "1" as sequence number, and RIP packets are detected as replay attacks by remote routers.

I fully understand that using 32 bits for time is an issue, but can we perhaps find another solution (permanent storage ?) to avoid sequence number going backwards?

[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.