Add Validation functions BGP BFD for FRR/EOS by snuffy22 · Pull Request #3534 · ipspace/netlab

snuffy22 · 2026-06-28T02:07:13Z

Made the validation plugin be able to take BFD information similar to the OSPF one.

Works with both EOS and FRR.

Not entirely sure if is correct how I made change to the DUT with enabling BFD in the topology.

(py3-snuff) netlab@netlab:~/snuffy-netlab/tests/integration/bgp.session$ netlab validate
[WARNING] Topology source file(s) have changed since the lab has started
[INFO]    Reading validation tests from /home/netlab/snuffy-netlab/tests/integration/bgp.session/13-bfd.yml
[session_v4] Check IPv4 EBGP sessions with DUT [ node(s): x1 ]
[PASS]       x1: Neighbor 10.1.0.1 (dut) is in state Established
[PASS]       Test succeeded in 0.1 seconds

[bgp_bfd_v4] Check IPv4 EBGP sessions with DUT [ node(s): x1 ]
[PASS]       x1: All specified BGP neighbor parameters have the expected values
[PASS]       Test succeeded in 0.1 seconds

[bfd_v4]     Check BFD peer on X1 [ node(s): x1 ]
[PASS]       Validation succeeded on x1
[PASS]       Test succeeded in 0.1 seconds

[bfd_v4_dut] Check BFD peer on DUT [ node(s): dut ]
[PASS]       Validation succeeded on dut
[PASS]       Test succeeded in 0.2 seconds

[SUCCESS]    Tests passed: 4

ipspace

While I'm perfectly fine with checking BFD status with a plugin, I'm wondering whether we need this as the integration test checks whether the tested device starts BFD, so we cannot configure BFD-for-BGP, so we won't get BFD info in the BGP neighbor anyway.

Having said that, it would be nice to have BFD-with-BGP checking functionality, but I think the parameter has to be be three-state: None (not interested in BFD), False (BFD must NOT be running) and True (BFD MUST be running).

ipspace · 2026-06-28T12:22:24Z


  return f'Neighbor {n_addr} ({n_id}) is in state {data[n_addr].peerState}'

+def show_bgp_neighbor_details(ngb: list, n_id: str, af: str='ipv4', *, activate: str = '', bfd: bool = False, **kwargs: typing.Any) -> str:


No need to specify BFD parameter in the "show" call which only generates the command to execute. kwargs will take care of that.

ipspace · 2026-06-28T12:23:49Z

+
+  result = f'The neighbor {n_addr} ({n_id}){act_err} is in BFD state {found.bfdState}'
+  if not found.bfdState == 3:
+      raise Exception(f'{result} ( expected 3 - Up )')


Nit: no need for spaces within brackets ;)

ipspace · 2026-06-28T12:24:18Z

  return f'Neighbor {n_addr} ({n_id}) is in state {data[n_addr].state}'

-def show_bgp_neighbor_details(ngb: list, n_id: str, af: str = 'ipv4', **kwargs: typing.Any) -> str:
+def show_bgp_neighbor_details(ngb: list, n_id: str, af: str = 'ipv4', bfd: bool = False, **kwargs: typing.Any) -> str:


As before, no need for bfd parameter; kwargs will take it.

ipspace · 2026-06-28T12:25:31Z

+      if data.peerBfdInfo.status != "Up":
+        raise Exception(f'{k} expected value UP actual {data.peerBfdInfo.status}')
+    else:
+      raise Exception(f'Neighbor data structure does not contain attribute peerBfdInfo')


I would reword this along the lines of "No BFD information for BGP peer {n_id}"

ipspace · 2026-06-28T12:26:39Z

 nodes:
  dut:
    bgp.as: 65000
+    bgp.bfd: True


Wrong. You see, the point is that DUT runs BFD with one peer but not the other.

There is only 1 peer in the bgp.session version of this BFD test topology currently...

ipspace · 2026-06-28T12:27:43Z

 groups:
  probes:
-    device: eos
+    device: frr


We probably need EOS here. See below...

ipspace · 2026-06-28T12:28:51Z

  x1:
    bgp.as: 65100
-    config: [ static_bfd ]
+    bgp.bfd: True


IIRC, the reason for this tweak (we could easily configure BFD on X1) is to ensure that X1 is willing to run BFD with DUT (it has a BFD neighbor configured), but will not try to initiate it (so we know DUT has to actively run BFD for BGP neighbors).

ipspace · 2026-06-28T13:21:02Z

+      frr: >-
+        result[0].status == "up"
+
+  bfd_v4_dut:


You cannot check anything on the tested device. It can be any one of the 20 or so platforms we support.

No problems, the test from the DUT was left over, as i wanted to test both at once rather than having re up/down the environment to swap.

Cover the FRR default-timer regression by forcing BFD down and documenting how to reproduce it with FRR 10.5.1. Co-authored-by: Cursor <cursoragent@cursor.com>

jbemmel · 2026-06-29T15:21:39Z

Took the liberty to add a test for FRRouting/frr#22097

Add BFD checks for BGP to validation plugin FRR/EOS

c3ec869

ipspace requested changes Jun 28, 2026

View reviewed changes

Test BGP teardown after BFD failure.

c963989

Cover the FRR default-timer regression by forcing BFD down and documenting how to reproduce it with FRR 10.5.1. Co-authored-by: Cursor <cursoragent@cursor.com>


		return f'Neighbor {n_addr} ({n_id}) is in state {data[n_addr].peerState}'

		def show_bgp_neighbor_details(ngb: list, n_id: str, af: str='ipv4', , activate: str = '', bfd: bool = False, *kwargs: typing.Any) -> str:

Conversation

snuffy22 commented Jun 28, 2026

Uh oh!

ipspace left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jbemmel commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants