Currently the Wait for Install code ( bgp_suppress_fib ) does
not properly handle two states from zebra: ROUTE_INSTALL_FAILED
and BETTER_ADMIN_DISTANCE_WON. Pre this change the WFI code
would just never notify our peers about a route install failure
but more is needed. In the ROUTE_INSTALL_FAILED and the
BETTER_ADMIN_DISTANCE_WON we need to notify our peers with
a withdrawal about the route, else we will continue to
draw traffic to us when we cannot legally do so.
Why is this needed? In either case imagine that we've already
received a bgp route, installed it and sent to our peers.
In the Better admin distance won case, say a static route is installed
at this point in time we must stop advertising the route through
us since we are not installed. As such a withdrawal must be sent.
In the ROUTE_INSTALL_FAILED case, the code was not properly handling
the situation where we have Route A, it was successfully installed
and then we received a update to Route A that was attempted to be
installed but failed. In this case we also need to send a withdrawal
Finally update the bgp_suppress_fib topotest to test both of these
situations.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
subprocess.check_call needs to be called with shell=True, else it will
interpret the string as a single path to execute instead of a command
with arguments:
Fixes the following error:
$ /usr/lib/frr/generate_support_bundle.py
Making backup of /var/log/frr/bgp_support_bundle.log
Traceback (most recent call last):
File "/usr/lib/frr/generate_support_bundle.py", line 89, in <module>
main()
File "/usr/lib/frr/generate_support_bundle.py", line 80, in main
stdout=open_with_backup(ofn),
File "/usr/lib/frr/generate_support_bundle.py", line 32, in open_with_backup
subprocess.check_call("mv {0} {0}.prev".format(path))
File "/usr/lib/python3.8/subprocess.py", line 359, in check_call
retcode = call(*popenargs, **kwargs)
File "/usr/lib/python3.8/subprocess.py", line 340, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib/python3.8/subprocess.py", line 858, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/usr/lib/python3.8/subprocess.py", line 1704, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'mv /var/log/frr/bgp_support_bundle.log /var/log/frr/bgp_support_bundle.log.prev'
Fixes: 5417cc2de ("tests: collect support bundle data in parallel, fix bugs")
Signed-off-by: Jonas Gorski <jonas.gorski@bisdn.de>
If we're exiting before we finished initializing, we can end up trying
to shut down a NULL vrf here.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
New `FRR_NO_SPLIT_CONFIG` flag for newly added daemons where we're just
rolling without split config and always expect configs to be loaded via
vtysh/integrated config.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Pointers to the adjacency must be cleared only when the adjacency is
deleted. Otherwise, when the ISIS router is deleted later, the adjacency
is not deleted and a crash happens because of UAF.
Fixes#10209.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There still existed chances that best path consideration
has not taken place for both bgp_l3vpn_to_bgp_vrf and
bgp_instance_del_test ( since they both used the same
check_routes.py scripting ). Add some more checks
to ensure that we have all the data. Prior to this
change I could see one of these two tests failing
every 2-3 runs on my test system. I am not seeing
this anymore after ~5 complete test runs.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
OSPF when converging will choose a DR / Backup DR based upon
who has already come up. Irrelevant of priority. As such if
under system load OSPF comes up first and elects a DR that under
normal circumstances not be the elected one due to priority
OSPF does not go back through and re-elect to keep the system
stable in this case. Tests are experiencing this:
unet> r0 show ip ospf neigh
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
100.1.1.1 99 Full/Backup 4m14s 3.780s 10.0.1.2 r0-s1-eth0:10.0.1.1 0 0 0
100.1.1.2 0 Full/DROther 4m14s 3.848s 10.0.1.3 r0-s1-eth0:10.0.1.1 0 0 0
100.1.1.3 0 Full/DROther 4m14s 3.912s 10.0.1.4 r0-s1-eth0:10.0.1.1 0 0 0
unet> r1 show ip ospf neigh
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
100.1.1.0 98 Full/DR 4m15s 3.011s 10.0.1.1 r1-s1-eth1:10.0.1.2 0 0 0
100.1.1.2 0 Full/DROther 4m19s 3.124s 10.0.1.3 r1-s1-eth1:10.0.1.2 0 0 0
100.1.1.3 0 Full/DROther 4m19s 3.188s 10.0.1.4 r1-s1-eth1:10.0.1.2 0 0 0
unet> r2 show ip ospf neigh
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
100.1.1.0 98 Full/DR 4m27s 3.483s 10.0.1.1 r2-s1-eth0:10.0.1.3 0 0 0
100.1.1.1 99 Full/Backup 4m32s 3.527s 10.0.1.2 r2-s1-eth0:10.0.1.3 0 0 0
100.1.1.3 0 2-Way/DROther 4m32s 3.660s 10.0.1.4 r2-s1-eth0:10.0.1.3 0 0 0
unet> r3 show ip ospf neigh
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
100.1.1.0 98 Full/DR 4m55s 3.786s 10.0.1.1 r3-s1-eth1:10.0.1.4 0 0 0
100.1.1.1 99 Full/Backup 4m55s 3.829s 10.0.1.2 r3-s1-eth1:10.0.1.4 0 0 0
100.1.1.2 0 2-Way/DROther 4m54s 3.897s 10.0.1.3 r3-s1-eth1:10.0.1.4 0 0 0
Modify the test to do a clear to enforce the order we are specifically looking for.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
frr-reload triggers restart of service in case
it fails to parse new config file and conjunction with
running config contains 'router bgp' (default bgp instnace).
When frr-reload fails to parse new config file, it fails
to build newconfig context (empty object).
Instead of bailing out it compares against the running config
context. If the running config contains default bgp instance
it thinks new config is removing default bgp instance so it
triggers frr restart.
Fix is to to bail out reload script when it fails to parse
config file.
Ticket:#2861989
Reviewed By: MR-83
Testing Done:
router bgp 102 vrf RED
bgp router-id 2.2.2.2
neighbor underlay peer-group
neighbor underlay remote-as <---- Partial config
Before fix:
2021-12-02 02:43:16,987 ERROR: vtysh failed to process new
configuration: vtysh (mark file) exited with status 4:
b'line 79: % Command incomplete: neighbor underlay remote-as\n\n'
2021-12-02 02:43:17,145 INFO: Loading Config object from vtysh show
running
2021-12-02 02:43:17,362 INFO: "frr version 7.5+cl5.0.0u0" cannot be
removed
2021-12-02 02:43:17,362 INFO: "frr defaults datacenter" cannot be
removed
2021-12-02 02:43:17,362 INFO: "service integrated-vtysh-config" cannot
be removed
2021-12-02 02:43:17,363 INFO: "line vty" cannot be removed
2021-12-02 02:43:17,522 INFO: EVPN is enabled and default instance del
needed
2021-12-02 02:43:17,522 INFO: Restarting FRR <---- Restart frr
After fix:
Just throw Error and abort the script.
root@TORS1:mgmt:/home/cumulus# /usr/lib/frr/frr-reload.py --debug
--reload --stdout /etc/frr/frr.conf
2021-12-02 04:00:56,519 INFO: Called via "Namespace(bindir='/usr/bin',
confdir='/etc/frr', daemon='', debug=True, filename='/etc/frr/$
rr.conf', input=None, overwrite=False, pathspace=None, reload=True,
rundir='/var/run/frr', stdout=True, test=False, vty_socket=None)"
2021-12-02 04:00:56,520 INFO: Loading Config object from file
/etc/frr/frr.conf
2021-12-02 04:00:56,679 ERROR: vtysh failed to process new
configuration: vtysh (mark file) exited with status 4:
b'line 79: % Command incomplete: neighbor underlay remote-as\n\n'
root@TORS1:mgmt:/home/cumulus#
Signed-off-by: Chirag Shah <chirag@nvidia.com>
This utility script helps in generated formatted and consistent
change log including:
1- group logs per daemon
2- standarize daemon names (lowercase, end with d)
3- capitalize all log lines
4- no merge commits
caveat: comments are assumed to be in the form
daemon-name : message
Sample Output:
```
sharpd
Follow the practice on cli design for json output
Install route supports nexthop-seg6 (step3)
Install_routes_helper support zapi_route flags (step1)
snapcraft
Add missing dependency
Add pathd to frr snap daemons
Change base to ubuntu 18.04 and libyang 2.0.7
staticd
Convert typedef to enum
Fix distance processing
Fix late initialization of blackhole type
Output config using nb callbacks instead of operational data
```
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
When the detection time expires, we put the session down and restart the
timer. As the comment in the code says, it's needed to zero the remote
discriminator after the second expiration.
But the RFC clearly says that this must be done on the first expiration:
bfd.RemoteDiscr
The remote discriminator for this BFD session. This is the
discriminator chosen by the remote system, and is totally opaque
to the local system. This MUST be initialized to zero. If a
period of a Detection Time passes without the receipt of a valid,
authenticated BFD packet from the remote system, this variable
MUST be set to zero.
And we actually already do it in `ptm_bfd_sess_dn`, so there's no need
to reset the timer and wait for it twice.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Remove neighbor <> remote-as <> config line,
if the neighbor is part of the peer-group and
peer-group contains remote-as config.
Neighbors which are part of the peer-group
cannot override remote-as.
Fix:
Frr-reload needs to remote 'neighbor <> remote-as <>'
from lines_to_add if its already part of peer-group
and peer-group has remote-as config.
Testing Done:
Before:
Config snippet:
neighbor PEERS peer-group
neighbor PEERS remote-as external
neighbor PEERS timers 3 9
neighbor 10.2.1.1 remote-as external
neighbor 10.2.1.1 peer-group PEERS
neighbor 10.2.1.1 timers 3 9
neighbor 10.2.1.2 remote-as external
neighbor 10.2.1.2 peer-group PEERS
Frr-reload failure:
line 179: Failure to communicate[13] to bgpd, line: neighbor 10.2.1.1
remote-as external
% Peer-group member cannot override remote-as of peer-group
line 179: Failure to communicate[13] to bgpd, line: neighbor 10.2.1.2
remote-as external
% Peer-group member cannot override remote-as of peer-group
After:
frr-reload apply the config successfully.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Modifying name of struct igmp_sock to struct gm_sock, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Modifying name of struct igmp_group to struct gm_group, which is to be used
by both IPv4 and IPv6(for both MLD and IGMP).
Co-authored-by: Mobashshera Rasool <mrasool@vmware.com>
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
