Not sure why it's here, but looks like it was since the beginning, let's see
if we can drop it.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There is no way that xpath can ever be anything but NULL
in the failure path with the goto's. Let's just remove
the goto's and return immediately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When the remote peer is neither EBGP nor confed, aspath is the
shadow copy of attr->aspath in bgp_packet_attribute(). Striping
AS4_PATH should not be done on the aspath directly, since
that would lead to bgpd core dump when unintern the attr.
Signed-off-by: Yuan Yuan <yyuanam@amazon.com>
Change timestamp parameter from int to time_t to avoid truncation.
Found by Coverity Scan (CID 1563226 and 1563222)
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The rn variable has its info attribute being replaced with a new ospf route before being freed properly.
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
In CI, CLANG static analyzer started complaining about possible null
dereferences of pre-existing fields. Let's make it happy and do a null
check.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Change CMD_WARNING -> CMD_WARNING_CONFIG_FAILED so that the rc is
non-zero and the caller can detect a failure.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Adds a generalized martian reimport function used for triggering a
relearn/reimport of EVPN routes that were previously filtered/deleted
as a result of a "self" check (either during import or by a martian
change handler). The MAC-VRF SoO is the first consumer of this function,
but can be expanded for use with Martian Tunnel-IPs, Interface-IPs,
Interface-MACs, and RMACs.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Currently we have a handler function that will walk the global EVPN
rib and unimport/remove routes matching a local IP/TIP. This generalizes
this function so that it can be re-used for other BGP Martian entry
types. Now this can be used to unimport routes when the MAC-VRF SoO is
reconfigured.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
For whatever reason, we were only updating tip_hash when we processed an
L2VNI add/del. This adds tip_hash updates to the L3VNI add/del codepaths
so that their VTEP-IPs are also used when when considering martian
addresses, e.g. bgp_nexthop_self().
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
All uses of struct bgp_addrv6 were removed in a prior commit that made
struct bgp_addr reusable for both v4 and v6. This cleans up the last
remnants of the old v6 struct.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Initial support for configuring an SoO for all MAC-VRFs (EVIs/L2VNIs).
This provides a topology-independent method of preventing EVPN routes
from one MAC-VRF "site" (an L2 domain) from being imported by other PEs
in the same MAC-VRF "site", similar to how SoO is traditionally used in
L3VPN to identify and break loops for an L3/IP-VRF "site".
One example of where a MAC-VRF SoO can be used to avoid an L2 control
plane loop is with Active/Active MLAG VTEPs. For a given L2 site only
one control plane should be active. SoO can be used to ID/ignore entries
originated from the local MAC-VRF site so that EVPN will not attempt to
manage entries that are already handled by MLAG.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
bgp_create() and bgp_free() already call EVPN-specific handlers,
so there's no need to XCALLOC/XFREE BGP_EVPN_INFO directly. Let's move
all the references to MTYPE_BGP_EVPN_INFO into the EVPN specific files.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
When processing an interface up/create event from zebra, we insert that
interface's MAC address into the self_mac_hash used for dropping EVPN
routes carrying a 'self mac' (RMAC ext-comm or MAC in Type-2 NLRI).
However, we were unconditionally triggering a "rescan" of the EVPN RIB
to ensure we handle routes that match the MAC - even if the MAC already
existed in self_mac_hash (i.e. the change wasn't actionable).
This adds logic to only kick off a "rescan" if the MAC learned from
zebra is not already in the self_mac_hash.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Problem:
Execute the below commands, pim6d core happens.
interface ens193
ip address 69.0.0.2/24
ipv6 address 8000::1/120
ipv6 mld
ipv6 pim
We see crash only if the interface is not configured, and
we are executing PIM/MLD commands.
RootCause:
Interface ens193 is not configured. So, it will have
ifindex = 0 and mroute_vif_index = -1.
Currently, we don't enable MLD on an interface if
mroute_vif_index < 0. So, pim_ifp->MLD = NULL.
In the API pim_if_membership_refresh(), we are accessing
pim_ifp->MLD NULL pointer which leads to crash.
Fix:
Added NULL check before accessing pim_ifp->MLD pointer in
the API pim_if_membership_refresh().
Issue: #13385
Signed-off-by: Sarita Patra <saritap@vmware.com>
This commit addresses a memory leak issue in the BGP Flowspec NLRI parsing function.
Previously when processing NLRI, dynamically allocated memory to `temp` was not being freed, leading to a memory leak.
The commit introduces the necessary code (XFREE) to properly free the temp memory after processing Flowspec NLRI.
The ASan leak log for reference:
```
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689:Direct leak of 56 byte(s) in 2 object(s) allocated from:
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #0 0x7fc9872b5037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #1 0x7fc986e5b1ee in qcalloc lib/memory.c:105
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #2 0x560421351bfe in bgp_nlri_parse_flowspec bgpd/bgp_flowspec.c:155
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #3 0x56042107d01c in bgp_nlri_parse bgpd/bgp_packet.c:350
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #4 0x560421086cf3 in bgp_update_receive bgpd/bgp_packet.c:2023
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #5 0x56042108deed in bgp_process_packet bgpd/bgp_packet.c:2933
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #6 0x7fc986f35bf7 in event_call lib/event.c:1995
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #7 0x7fc986e1e99d in frr_run lib/libfrr.c:1185
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #8 0x560420f3f59d in main bgpd/bgp_main.c:505
./bgp_flowspec.test_bgp_flowspec_topo/r1.bgpd.asan.687689- #9 0x7fc986805d09 in __libc_start_main ../csu/libc-start.c:308
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
On removal, ensure that the ifp->node is set to a null
pointer so that FRR does not use data after freed.
In addition ensure that the ifp->node exists before
attempting to free it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When entering some show commands that use json in pimd
when the interface cannot be found do not output non-json
format in that case.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
the bgp_default_originate test brings up the topology and
then immediately pings. Which sometimes fails. This is
of course possible since the first ping might actually fail
due to arp going on. So let's give it a second chance or two.
Especially since the test, at this point, is just installing
a default route.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
