During vrf delete, the vxlan_info.work_list
linked list was deleted which is a global list
containing the SGs for all the VRFs.
If two vrfs are configured, vrf a and vrf b and
both has SGs assocaited with them which are
inserted in the vxlan_info.work_list. Now if
vrf a is deleted, it deletes the work_list also.
Due to this when any SG add or del comes for vrf b
it tries to access the work_list and crashes.
Fix
Delete the vxlan_info.work_list only when all the
VRFs are terminated and unset the vxlan_info.flags
so if new add cmd comes it re-allocates the work_list.
Signed-off-by: usrivastava-nvidia <usrivastava@nvidia.com>
Try to document the sub-node `line vty` and
what it can do. Call out the distinction
between vtysh and VTY.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Removal of IPv6 was already tested in bgp_evpn_rt5 topotest, however
IPv4 was not tested afterwards. This now removes IPv6 routes first,
then adds them back and removes IPv4 afterwards, waiting for
convergence everytime.
Signed-off-by: Christopher Dziomba <christopher.dziomba@telekom.de>
zebra rmac has a nh_list which tracks the assigned VTEP IPs to RMACs.
It can also receive IPv6 encoded IPv4 addresses as VTEPs. Changing/
Installing the RMAC into the Kernel is only important when the IPv4
address changes. However because nh_list is a nodup list used to
track usage or RMACs by VTEP IPs, both IP addresses (IPv4 and IPv6
encoded IPv4) should be written into it, as both could be removed
in l3vni_rmac_nh_list_nh_delete independently.
Signed-off-by: Christopher Dziomba <christopher.dziomba@telekom.de>
Found by the static analyzer Svace (ISP RAS): DEREF_AFTER_FREE -
Pointer '&bgp->vrf_id' is dereferenced after the referenced memory
was deallocated by passing as 1st parameter to function 'bgp_unlock'.
Signed-off-by: Petr Vaganov <petrvaganoff@gmail.com>
Also, only message interested backend clients about a path removal when last
supporting session is being removed from a given notification path.
Signed-off-by: Christian Hopps <chopps@labn.net>
Add macros to support searching for and finding (perhaps closest) matches
for a key in an array of strings.
Signed-off-by: Christian Hopps <chopps@labn.net>
- Missed insert mcaro when fixing the other macros.
- Also, actually use `MT` argument in the mt variant insert macros
Signed-off-by: Christian Hopps <chopps@labn.net>
The rib_sweep_route function when not doing graceful
restart does not attempt to save the event on the
t_rib_sweep pointer for shutdown. Prevent any
weird shenanigans by allowing shutdown to clean
up the rib_sweep_route event.
Signed-off-by: Donald Sharp <donaldsharp72@gmail.com>
The bgp_generate_updgrp_packet function will attempt to write
up to `write quanta 64` packets at one time. This is extremely
expensive at scale and is causing CPU_HOGS as well as STARVATION
messages. Check to see if we should yield the CPU to allow
something else in BGP to continue working.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In bgp_evpn_rt5, check if EVPN routes are correctly imported to VRF.
Note that EVPN and RT extended communities should have been stripped.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
According to draft-ietf-bess-evpn-ipvpn-interworking-13, strip
the following extended communities for VRF routes imported from EVPN.
a. BGP Encapsulation extended communities.
b. Route Target extended communities.
c. All the extended communities of type EVPN.
As the corresponding fields will not be always covered by extended
communities, add them to attr hash key directly.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
bgpd/bgpd.c:8975:5: error: "ENABLE_BGP_VNC" is not defined, evaluates to 0 [-Werror=undef]
8975 | #if ENABLE_BGP_VNC
Fixes: FRRouting#18546
Fixes: 1629c05924 ("bgpd: rfapi: track outstanding rib and import timers, free mem at exit")
Cc: G. Paul Ziemba <paulz@labn.net>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
