Commit 594a4917b7 for frr

commit 594a4917b71e5ff537bba6f0a967f683aa514bef
Author: Abdul Wasey <w453y.me@gmail.com>
Date:   Mon Sep 14 09:17:00 2026 +0000

    tests: keep the key fixture within what every build accepts

    Two things in the fixture made the router come up with no session at all,
    since a refused line fails the candidate configuration as a whole and the
    `bfd peer` block goes with it.

    `hmac-sha-1` needs `--with-crypto=openssl`, which is not the default:
    under `CRYPTO_INTERNAL`, `keychain_get_algo_id_by_name` does not recognise
    the name and the northbound validation refuses it. `has_crypto_openssl`
    cannot guard a startup configuration, so use cleartext. Nothing here
    asserts on the authentication type, a key carries its lifetimes the same
    either way, and both crypto backends recognise it.

    `send-lifetime` and `accept-lifetime` take years only up to 2035, and
    dates out there would eventually close anyway: a key whose accept period
    has ended is not offloaded, and the test would then fail on the wall clock
    alone. The accept periods therefore end with a duration, which is computed
    from the start and never written down. The send periods keep their dates,
    since they have to close before the next key opens and so are bounded by
    each other rather than by the calendar. Every assertion compares the
    lifetimes against one another, so none of them moves.

    Signed-off-by: Abdul Wasey <w453y.me@gmail.com>

diff --git a/tests/topotests/bfd_dplane_auth_topo1/r1/frr.conf b/tests/topotests/bfd_dplane_auth_topo1/r1/frr.conf
index 2b54fbf4f8..ee8fd29c90 100644
--- a/tests/topotests/bfd_dplane_auth_topo1/r1/frr.conf
+++ b/tests/topotests/bfd_dplane_auth_topo1/r1/frr.conf
@@ -6,19 +6,19 @@ interface r1-eth0
 key chain rollover
  key 1
   key-string firstkey00000001
-  cryptographic-algorithm hmac-sha-1
-  send-lifetime 00:00:00 1 January 2040 23:59:59 30 June 2040
-  accept-lifetime 00:00:00 1 January 2040 23:59:59 31 July 2040
+  cryptographic-algorithm cleartext
+  send-lifetime 00:00:00 1 January 2035 23:59:59 30 June 2035
+  accept-lifetime 00:00:00 1 January 2035 duration 63072000
  exit
  key 2
   key-string secondkey0000002
-  cryptographic-algorithm hmac-sha-1
-  send-lifetime 00:00:00 1 July 2040 23:59:59 31 December 2040
-  accept-lifetime 00:00:00 1 June 2040 23:59:59 31 December 2040
+  cryptographic-algorithm cleartext
+  send-lifetime 00:00:00 1 July 2035 23:59:59 31 December 2035
+  accept-lifetime 00:00:00 1 June 2035 duration 63072000
  exit
  key 3
   key-string thirdkey00000003
-  cryptographic-algorithm hmac-sha-1
+  cryptographic-algorithm cleartext
  exit
 exit
 !
diff --git a/tests/topotests/bfd_dplane_auth_topo1/test_bfd_dplane_auth_topo1.py b/tests/topotests/bfd_dplane_auth_topo1/test_bfd_dplane_auth_topo1.py
index a65909cf16..a96ce8b972 100644
--- a/tests/topotests/bfd_dplane_auth_topo1/test_bfd_dplane_auth_topo1.py
+++ b/tests/topotests/bfd_dplane_auth_topo1/test_bfd_dplane_auth_topo1.py
@@ -39,6 +39,16 @@ DPLANE_PORT = 50700
 # Three keys are configured: two carrying lifetimes and one without.
 KEY_COUNT = 3

+# The chain uses cleartext rather than hmac-sha-1 on purpose. hmac-sha-1
+# needs --with-crypto=openssl, and `keychain_get_algo_id_by_name` does not
+# even recognise the name without it, so the algorithm fails validation and
+# takes the whole candidate configuration with it, `bfd peer` block
+# included. Guarding with `has_crypto_openssl` the way
+# bfd_authentication_topo1 does would not help, because the damage is done
+# at startup before any test runs. Nothing here asserts on the
+# authentication type, and a key carries its lifetimes the same either way,
+# so cleartext lets the module run everywhere instead of skipping.
+

 def setup_module(mod):
     topodef = {"s1": ("r1",)}
@@ -127,10 +137,18 @@ def _keys(dump):
     from a local time, so nothing here compares them against a fixed
     value. What matters is how they sit relative to one another.

-    The chain itself is dated well into the future on purpose: a key whose
+    The chain itself is dated into the future on purpose: a key whose
     accept period has closed is not offloaded, so a fixture written around
     the date it was authored would quietly lose a key and take the overlap
     it demonstrates with it.
+
+    The accept periods end with a duration rather than a date, because the
+    CLI takes years only up to 2035 and a fixed end date is therefore a
+    date this test starts failing on. A duration is added to the start, so
+    the end is never written down and the ceiling does not apply to it.
+    The send periods keep their dates: they have to close before the next
+    key opens, which is the overlap being demonstrated, and they are
+    bounded by that rather than by the calendar.
     """
     out = []
     pattern = re.compile(
@@ -243,7 +261,7 @@ def test_a_new_key_is_pushed():
         key chain rollover
         key 4
         key-string fourthkey0000004
-        cryptographic-algorithm hmac-sha-1
+        cryptographic-algorithm cleartext
         end
         """
     )
@@ -277,7 +295,7 @@ def test_a_lifetime_edit_is_pushed():
         configure terminal
         key chain rollover
         key {}
-        accept-lifetime 00:00:00 Jan 1 2020 23:59:59 Dec 31 2037
+        accept-lifetime 00:00:00 1 January 2030 23:59:59 31 December 2035
         end
         """.format(target)
     )