]> git.puffer.fish Git - mirror/frr.git/commit
Revert "bgpd: Handle Addpath capability using dynamic capabilities" 17940/head
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:23:37 +0000 (11:23 +0200)
commit513d333ca8cbbb8094962c46deb2904f53871cbd
tree1f1d7996e1a2e1e4830b86d6404dc3f6c6bc0584
parent689b455c47de1d014bdfe728abed19c15c89cc15
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/test_bgp_dynamic_capability_addpath.py [deleted file]