bgp: option "graceful-restart" causes frr-reload.py to return non zero exit code

[c-po]

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.

• Did you check if this is a duplicate issue?
• Did you test it on the latest FRRouting/frr master branch?

To Reproduce

1.txt

!
frr version 7.5.1-20210401-04-g3d506af6a
frr defaults traditional
hostname LR1.wue3
log syslog
log facility local7
agentx
service integrated-vtysh-config
!
router bgp 100
 no bgp ebgp-requires-policy
 bgp graceful-restart
 no bgp network import-check
 neighbor DAL13 peer-group
 neighbor DAL13 remote-as 200
 neighbor DAL13 ebgp-multihop 2
 neighbor DAL13 update-source dum0
 neighbor 192.168.253.6 peer-group DAL13
 !
 address-family ipv4 unicast
  neighbor DAL13 soft-reconfiguration inbound
 exit-address-family
!
line vty
!
end

2.txt

!
frr version 7.5.1-20210401-04-g3d506af6a
frr defaults traditional
hostname LR1.wue3
log syslog
log facility local7
agentx
service integrated-vtysh-config
!
line vty
!
end

Now you can toggle between 1.txt and 2.txt, while loading 1.txt triggers the error

root@vyos:/home/vyos# /usr/lib/frr/frr-reload.py --reload --debug --daemon bgpd --stdout 1.txt
root@vyos:/home/vyos# echo $?
1

root@vyos:/home/vyos# /usr/lib/frr/frr-reload.py --reload --debug --daemon bgpd --stdout 2.txt
root@vyos:/home/vyos# echo $?
0

Even when frr-reload exists 1, the configuration is applied.

vyos@vyos:~$ vtysh -c "show run"
Building configuration...

Current configuration:
!
frr version 7.5.1-20210401-04-g3d506af6a
frr defaults traditional
hostname LR1.wue3
log syslog
log facility local7
agentx
service integrated-vtysh-config
!
router bgp 100
 no bgp ebgp-requires-policy
 bgp graceful-restart
 no bgp network import-check
 neighbor DAL13 peer-group
 neighbor DAL13 remote-as 200
 neighbor DAL13 ebgp-multihop 2
 neighbor DAL13 update-source dum0
 neighbor 192.168.253.6 peer-group DAL13
 !
 address-family ipv4 unicast
  neighbor DAL13 soft-reconfiguration inbound
 exit-address-family
!
line vty
!
end

Expected behavior

• do not return a non zero exit code
• do not apply the configuration if 1 is returned
  I would like to go with option 1, as it feels the rc=1 is triggered by Graceful restart configuration changed, reset all peers to take effect - so this is something the user should do afterwards

Screenshots

Versions

• OS Version: Debian 10

• Kernel: 5.10.27

• FRR Version: 7.5.1-20210401-04-g3d506af6a

Additional context

[c-po]

The issue also appears when configuriong graceful-restart options on the peer level.

[c-po]

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

[c-po]

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