The interface parameters deletion must be called before
`route_table_finish` due to the usage of the route data structures to
search neighbors in the same interface. If the route info is removed
before that we get the following crash:
```
6 0x00007f5c6ed50394 in core_handler at lib/sigevent.c:255
7 <signal handler called>
8 ospf_interface_bfd_apply (ifp=<optimized out>) at ospfd/ospf_bfd.c:130
9 0x000055d4c306d076 in ospf_interface_disable_bfd at ospfd/ospf_bfd.c:159
10 0x000055d4c3071781 in ospf_del_if_params at ospfd/ospf_interface.c:553
11 0x000055d4c3071900 in ospf_if_delete_hook at ospfd/ospf_interface.c:704
12 0x00007f5c6ed17935 in hook_call_if_del at lib/if.c:59
13 if_delete_retain at lib/if.c:290
14 0x00007f5c6ed19bc5 in if_delete at lib/if.c:313
15 0x00007f5c6ed19d88 in if_terminate at lib/if.c:1067
16 0x00007f5c6ed63a04 in vrf_delete at lib/vrf.c:297
17 0x00007f5c6ed76784 in zclient_vrf_delete at lib/zclient.c:1974
18 zclient_read at lib/zclient.c:3686
19 0x00007f5c6ed60f85 in thread_call at lib/thread.c:1815
20 0x00007f5c6ed20228 in frr_run at lib/libfrr.c:1149
21 0x000055d4c306bc70 in main at ospfd/ospf_main.c:233
```
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Just another round of trying to add pytest.mark.bgpd. Not finished yet just
what I could stand doing for a few minutes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Current behavior has an EVPN_ENABLED check for both standard and 'no'
forms of 'advertise-svi-ip' and 'advertise-default-gw'. This prevents a
user from removing either command from running config if
'advertise-all-vni' is not present.
This commit removes/adjusts the EVPN_ENABLED checks to always allow the
'no' command so config doesn't get stuck.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
This was mistakenly using the host platform's pointer size rather than
the ELF file's. Only noticeable when cross compiling...
Signed-off-by: David Lamparter <equinox@diac24.net>
Fixes:
/usr/lib/python3.9/site-packages/_pytest/config/__init__.py:1463: in getoption
val = getattr(self.option, name)
E AttributeError: 'Namespace' object has no attribute 'topology_only'
The above exception was the direct cause of the following exception:
/usr/lib/python3.9/site-packages/pluggy/manager.py:127: in register
hook._maybe_apply_history(hookimpl)
/usr/lib/python3.9/site-packages/pluggy/hooks.py:333: in _maybe_apply_history
res = self._hookexec(self, [method], kwargs)
/usr/lib/python3.9/site-packages/pluggy/manager.py:93: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3.9/site-packages/pluggy/manager.py:84: in <lambda>
self._inner_hookexec = lambda hook, methods, kwargs: hook.multicall(
tests/topotests/conftest.py:62: in pytest_configure
if config.getoption("--topology-only"):
/usr/lib/python3.9/site-packages/_pytest/config/__init__.py:1474: in getoption
raise ValueError(f"no option named {name!r}") from e
E ValueError: no option named 'topology_only'
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Description:
Route leaking from default vrf to non-default vrf stops after frr restart.
If the interface comes up after route leaking is configured,
in the case of vpn router id update, we delete the ecommunity value
and never reconfigure the rtlist.
This results in skipping route leak to non-default vrfs (vpn to vrf).
Router-id change that is not explicitly configured
(a change from zebra, frr restart) should not replace a configured vpn RD/RT.
Added few helpful debugs as well.
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Problem:
Stale routes are seen in the bgp table(ipv4 and ipv6)
RCA:
Scenario1:
Interface down and withdraw is in-progress.
Router bgp config leading to re-leaking.
Now, withdraw-in-progress routes,
are again leaked to bgp vrf instance(s) importing routes.
Whenever we see an interface down
and corresponding address delete,
while withdrawal of exported routes is in-progress,
routes are marked as being removed and put into work queue.
‘router bgp’ config is updated, which triggers
bgp_vpn_leak_export; which exports routes from configured bgp vrf to VPN.
So withdraw-in-progress routes,
are again leaked to bgp vrf instance(s) importing routes; leading to stale routes.
Scenario2:
- 'no import vrf non-default-vrf’ [in the default vrf]
- bgp update from the peer withdrawing prefix [non-default vrf]
- 'import vrf non-default-vrf’ [configured in the default vrf]
While withdrawal of exported routes is in-progress,
routes are marked as being removed and put into work queue,
In the meantime, if import vrf is configured,
which exports routes from configured bgp vrf to VPN.
So withdraw-in-progress new routes,
are again leaked to bgp vrf instance(s) importing routes; leading to stale routes.
Fix:
Whenever leaking routes (leak_update),
for already existing routes,
skip the routes with bgp_path_info
marked as being removed.
Also added the log message for the return.
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Description:
After FRR restart, routes are not getting redistributed;
when routes added first and then 'redistribute static' cmd is issued.
During the frr restart, vrf_id will be unknown,
so irrespective of redistribution, we set the redistribute vrf bitmap.
Later, when we add a route and then issue 'redistribute' cmd,
we check the redistribute vrf bitmap and return CMD_WARNING;
zebra_redistribute_add also checks the redistribute vrf bitmap and returns.
Instead of checking the redistribute vrf bitmap, always set it anyways.
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Description:
Imported/leak-from routes do not get withdrawn/removed
even if the source VRF is deleted.
Deleting and re-adding a tenant vrf, does not refresh the RIB.
Whenever VRF is deleted (bgp_vrf_disable),
currently we are withdrawing leak-from-vrf and
leak-to-vrf routes from vpn table for the vrf,
which is deleted.
But we are currently not withdrawing routes from leak-to vrfs.
We should also withdraw leak-to routes
from leak-to vrfs (calling vpn_leak_to_vrf_withdraw).
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
Description:
FRR doesn't re-install the routes, imported from a tenant VRF,
when bgp instance for source vrf is deleted and re-added again.
When bgp instance is removed and re-added, when import statement is already there,
then route leaking stops between two VRFs.
Every 'router bgp' command should trigger re-export of all the routes
to the importing bgp vrf instances.
When a router bgp is configured, there could be bgp vrf instance(s) importing routes from
this newly configured bgp vrf instance.
We need to export routes from configured bgp vrf to VPN.
This can impact performance, whenever we are testing scale from vrf route-leaking perspective.
We should not trigger re-export for already existing bgp vrf instances.
Co-authored-by: Santosh P K <sapk@vmware.com>
Co-authored-by: Kantesh Mundaragi <kmundaragi@vmware.com>
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
We should delete the access-list when the last entry and remark is
deleted. This is already done for prefix-lists.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
We delete the prefix-list when its last entry is deleted, but the check
is missed when we delete the description.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
CLI must never use operational data, because this won't work in
transactional mode. Rework search for prefix-list/access-list entries
using only candidate config.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Allow over-write of message-digest-key interface config. Most
attributes handle multi-instance by ... ignoring instances,
and tolerating repeated config: do the same for md5 auth.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
For some reason the usage of tabs in a string snuck in as well
as using a sockunion2str instead of %pSU. Fix.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When you set OSPF hello-interval for an interface and dead-interval is
not set for this interface, dead-interval will be calculated and set
automatically. "show running-config" will contain an invalid command:
test(config)# interface vpp1
test(config-if)# ip ospf area 0
test(config-if)# ip ospf hello-interval 1
test(config-if)# exit
test(config)#
test(config)# do show running-config
...
interface if1
ip ospf area 0
ip ospf dead-interval minimal hello-multiplier 0
ip ospf hello-interval 1
!
...
It causes frr-reload.py to fail because of this:
# vtysh -c "show running-config no-header" | vtysh -m -f -
line 9: % Unknown command: ip ospf dead-interval minimal hello-multiplier 0
...
With this change, output "ip ospf dead-interval" only if it has value
configured explicitly.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
