diff options
| author | Takayuki Shiroma <t.shiroma.oki@gmail.com> | 2026-09-27 17:51:49 +0900 |
|---|---|---|
| committer | Christian Breunig <christian@breunig.cc> | 2026-09-27 20:03:43 +0200 |
| commit | f6b3ee39751fef3f542b7f205f92405bba5a797c (patch) | |
| tree | fc313c086d10197a9bfdbc2fedbdff6c2ebb7e5f /src/migration-scripts | |
| parent | e7c3eae69237d3e07de7166024b57cf9e75ab573 (diff) | |
| download | vyos-1x-f6b3ee39751fef3f542b7f205f92405bba5a797c.tar.gz vyos-1x-f6b3ee39751fef3f542b7f205f92405bba5a797c.zip | |
bgp: T9360: render "orf prefix-list both" if send and receive are set
When both the ORF send and receive capability were enabled for a BGP
neighbor address-family, the FRR template emitted two individual
statements:
neighbor 192.0.2.1 capability orf prefix-list send
neighbor 192.0.2.1 capability orf prefix-list receive
FRR stores this combination as a single "both" directive, so its running
configuration never matched what VyOS generated. As a result every subsequent
commit, even one entirely unrelated to BGP, removed and re-added the ORF
capability.
Each of those cycles resets the established BGP session for about two seconds.
Cover all three combinations for both a plain neighbor and a peer-group:
* send only -> neighbor <peer> capability orf prefix-list send
* receive only -> neighbor <peer> capability orf prefix-list receive
* send + receive -> neighbor <peer> capability orf prefix-list both
The "both" case additionally verifies that the individual send and receive
statements are no longer rendered, as those are exactly what made FRR and
VyOS disagree about the running configuration.
Co-authored-by: Christian Breunig <christian@breunig.cc>
Diffstat (limited to 'src/migration-scripts')
0 files changed, 0 insertions, 0 deletions