Closed c-po closed 3 years ago
The issue also appears when configuriong graceful-restart options on the peer level.
Turns out this issue is not frr-reload.py related but rather related to vtysh:
+ vtysh -c configure -c 'frr version 7.5.1-20210401-04-g3d506af6a'
+ echo 0
0
+ vtysh -c configure -c 'hostname LR1.wue3'
+ echo 0
0
+ vtysh -c configure -c 'frr version 7.5.1-20210401-04-g3d506af6a'
+ echo 0
0
+ vtysh -c configure -c 'hostname LR1.wue3'
+ echo 0
0
+ vtysh -c configure -c 'router bgp 100'
+ echo 0
0
+ vtysh -c configure -c 'router bgp 100' -c 'no bgp ebgp-requires-policy'
+ echo 0
0
+ vtysh -c configure -c 'router bgp 100' -c 'bgp graceful-restart'
Graceful restart configuration changed, reset all peers to take effect
% The Graceful Restart command used is not valid at this moment.
+ echo 1
1
+ vtysh -c configure -c 'router bgp 100' -c 'no bgp network import-check'
+ echo 0
0
Turns our, return code 1 is used for both informational messages like "hey joe, please reset your peers" but also on real errors like "BGP -> Specify remote-as or peer-group commands first"
root@vyos:/home/vyos# vtysh -c configure -c 'router bgp 100' -c 'neighbor 1.1.1.1 description foo'
% Specify remote-as or peer-group commands first
root@vyos:/home/vyos# echo $?
1
Describe the bug
When reloading the FRR configuration and
bgp graceful-restart
option is set, the/usr/lib/frr/frr-reload.py
script returns with 1 but the configuration is applied properly into FRR - this makes scripts processing the return code fail.To Reproduce
1.txt
2.txt
Now you can toggle between 1.txt and 2.txt, while loading 1.txt triggers the error
Even when frr-reload exists 1, the configuration is applied.
Expected behavior
Graceful restart configuration changed, reset all peers to take effect
- so this is something the user should do afterwardsScreenshots
Versions
Additional context