forked from Mirror/frr
4338e21aa2
This reverts commit 05cf9d03b3.
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>
39 lines
988 B
Plaintext
39 lines
988 B
Plaintext
!
|
|
!debug bgp neighbor
|
|
!
|
|
int lo
|
|
ip address 10.10.10.10/32
|
|
ip address 10.10.10.20/32
|
|
!
|
|
int r2-eth0
|
|
ip address 192.168.1.2/24
|
|
ipv6 address 2001:db8::2/64
|
|
!
|
|
router bgp 65002
|
|
bgp graceful-restart
|
|
bgp long-lived stale-time 20
|
|
no bgp ebgp-requires-policy
|
|
neighbor 192.168.1.1 remote-as external
|
|
neighbor 192.168.1.1 timers 1 3
|
|
neighbor 192.168.1.1 timers connect 1
|
|
neighbor 192.168.1.1 capability dynamic
|
|
neighbor 192.168.1.1 capability extended-nexthop
|
|
neighbor 2001:db8::1 remote-as external
|
|
neighbor 2001:db8::1 timers 1 3
|
|
neighbor 2001:db8::1 timers connect 1
|
|
neighbor 2001:db8::1 capability dynamic
|
|
neighbor 2001:db8::1 capability extended-nexthop
|
|
!
|
|
address-family ipv4 unicast
|
|
redistribute connected
|
|
neighbor 192.168.1.1 addpath-tx-all-paths
|
|
neighbor 192.168.1.1 disable-addpath-rx
|
|
neighbor 192.168.1.1 addpath-rx-paths-limit 20
|
|
exit-address-family
|
|
!
|
|
address-family ipv6 unicast
|
|
redistribute connected
|
|
neighbor 2001:db8::1 activate
|
|
exit-address-family
|
|
!
|