]> git.puffer.fish Git - matthieu/frr.git/commit
Revert "bgpd: Handle Addpath capability using dynamic capabilities"
authorDonatas Abraitis <donatas@opensourcerouting.org>
Sat, 25 Jan 2025 18:28:26 +0000 (20:28 +0200)
committerDonatas Abraitis <donatas@opensourcerouting.org>
Tue, 28 Jan 2025 09:13:59 +0000 (11:13 +0200)
commit3110597de5d3d4073f198e8c881bd82bb29f363a
treeeccfcebe4048fc5e045c23bdedd266eab8aef1e7
parent273dc49b7390d9aa02ed6341caa43b128e08c6b2
Revert "bgpd: Handle Addpath capability using dynamic capabilities"

This reverts commit 05cf9d03b345393b8d63ffe9345c42debd8362b6.

TL;DR; Handling BGP AddPath capability is not trivial (possible) dynamically.

When the sender is AddPath-capable and sends NLRIs encoded with AddPath ID,
and at the same time the receiver sends AddPath capability "disable-addpath-rx"
(flag update) via dynamic capabilities, both peers are out of sync about the
AddPath state. The receiver thinks already he's not AddPath-capable anymore,
hence it tries to parse NLRIs as non-AddPath, while they are actually encoded
as AddPath.

AddPath capability itself does not provide (in RFC) any mechanism on backward
compatible way to handle NLRIs if they come mixed (AddPath + non-AddPath).

This explains why we have failures in our CI periodically.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
bgpd/bgp_addpath.c
bgpd/bgp_addpath.h
bgpd/bgp_packet.c
bgpd/bgp_vty.c
bgpd/bgpd.c
tests/topotests/bgp_dynamic_capability/r2/frr.conf
tests/topotests/bgp_dynamic_capability/test_bgp_dynamic_capability_addpath.py [deleted file]
tests/topotests/bgp_dynamic_capability/test_bgp_dynamic_capability_path_limit.py [new file with mode: 0644]