If you have undefined behavior compilation checking gcc
starts to complain about a bunch of places that do not
have return's. When most of them actually do and we
have the assert's to prove it. I'm just doing this
to make the compiler happy for me, so I can continue
to do work.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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>
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>
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>
Support filtering extended communities with a callback. So that we can
strip multiple values in one pass.
Signed-off-by: Xiao Liang <shaw.leon@gmail.com>
Fix bgp_pbr_rule memory leak. Found by code review.
Fixes: 27e376d4e1 ("bgpd: an hash list of pbr iprule is created")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When attempting to check rpki status and the connection
has been turned off, let's check to see if we are connected
before we ask the rpki subsystem, else we will get a crash
in the rpki library.
Signed-off-by: Donald Sharp <donaldsharp72@gmail.com>
The 'acceptedPrefixCounter' is available in 'show bgp neighbor json', but
there is no equivalent when using the non json output. Add it.
> # show bgp neighbor
> [..]
> Community attribute sent to this neighbor(all)
> 0 accepted prefixes, 1 sent prefixes
Fixes: 856ca177c4 ("Added json formating support to show-...-neighbors-... bgp commands.")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Issue:
In a scaled setup, (where number of nets > BGP_CLEARING_BATCH_MAX_DESTS
for walk_batch_table_helper), when peer is shutdown, it is seen some
of the paths are not deleted, which are received from that peer.
Fix:
This is due to, in clear_batch_rib_helper, once walk_batch_table_helper
returns after BGP_CLEARING_BATCH_MAX_DESTS is reached, we just break
from inner loop for the afi/safi for loops. So during walk for next
afi/safi that 'ret' state is overwritten with new state. Also the
resume context is overwritten. This causes to lose the start point
for next walk, some nets are skipped forever. So they are not marked
for deletion anymore. To fix this, we immediately return from current
run. This will have resume state to be stored correctly, and next walk
will start from there.
Testing:
32 ecmp paths were received from the shutdown peer
Before fix:
show bgp ipv6 2052:52:1:167::/64
BGP routing table entry for 2052:52:1:167::/64, version 495
Paths: (246 available, best #127, table default)
Not advertised to any peer
<snip>
4200165500 4200165002
2021:21:51:101::2(spine-5) from spine-5(2021:21:51:101::2) (6.0.0.17)
(fe80::202:ff:fe00:55) (prefer-global)
Origin incomplete, valid, external, multipath
Last update: Fri Apr 4 17:25:05 2025
4200165500 4200165002
2021:21:11:116::2(spine-1) from spine-1(2021:21:11:116::2) (0.0.0.0)
(fe80::202:ff:fe00:3d) (prefer-global)<<<<path not deleted
Origin incomplete, valid, external
Last update: Fri Apr 4 17:25:05 2025
4200165500 4200165002
2021:21:11:115::2(spine-1) from spine-1(2021:21:11:115::2) (0.0.0.0)
(fe80::202:ff:fe00:3d) (prefer-global)<<<<path not deleted
Origin incomplete, valid, external
Last update: Fri Apr 4 17:25:05 2025
<snip>
32 paths are supposed to be withdrawn:
root@leaf-1:mgmt:# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
256
root@leaf-1:mgmt# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
246<<should be 224, but showing 246, which is wrong
After fix:
32 paths are supposed to be withdrawn:
root@leaf-1:mgmt:# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
256
root@leaf-1:mgmt:# vtysh -c "show bgp ipv6 2052:52:1:167::/64" | grep "prefer-global" | wc -l
224<<<shows correctly
Signed-off-by: Soumya Roy <souroy@nvidia.com>
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
0 0x7fdaf6cb83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7fdaf683a480 in qcalloc lib/memory.c:106
2 0x7fdaf68dd706 in route_table_init_with_delegate lib/table.c:38
3 0x5649b22c05b0 in bgp_table_init bgpd/bgp_table.c:139
4 0x5649b2273da0 in bgp_static_set bgpd/bgp_route.c:7779
5 0x5649b21eba58 in vpnv4_network bgpd/bgp_mplsvpn.c:3244
6 0x7fdaf67b6d61 in cmd_execute_command_real lib/command.c:1003
7 0x7fdaf67b7080 in cmd_execute_command lib/command.c:1062
8 0x7fdaf67b75ac in cmd_execute lib/command.c:1228
9 0x7fdaf68ffb20 in vty_command lib/vty.c:626
10 0x7fdaf6900073 in vty_execute lib/vty.c:1389
11 0x7fdaf6903e24 in vtysh_read lib/vty.c:2408
12 0x7fdaf68f0222 in event_call lib/event.c:2019
13 0x7fdaf681b3c6 in frr_run lib/libfrr.c:1247
14 0x5649b211c903 in main bgpd/bgp_main.c:565
15 0x7fdaf630c249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Table was being created but never deleted. Let's delete it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This commit fixes two types of problems:
a) Avoidance of cleaning up memory when a instance is
hidden, thus causing it never to be freed on shutdown
b) In some instances bgp_create is called 2 times
for some code. We are double allocating memory
and dropping it on the second allocation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Section 4.1 of RFC8955 defines how the length field of flowspec NLRIs is encoded.
The method use implies a maximum length of 4095 for a single flowspec NLRI.
However, in bgp_flowspec.c, we check the length attribute of the bgp_nlri structure against this maximum value, which actually is the *total* length of all NLRI included in the considered MP_REACH_NLRI path attribute.
Due to this confusion, frr would reject valid announces that contain many flowspec NLRIs, when their cummulative length exceeds 4095, and close the session.
The proposed change removes that check entirely. Indeed, there is no need to check the length field of each invidual NLRI because the method employed make it impossible to encode a length greater than 4095.
Signed-off-by: Stephane Poignant <stephane.poignant@proton.ch>
Issue:
"Processing EVPN MAC interface change on peer" log message is printed
even when the peer didnt have EVPN address family.
Fix:
Process only if the peer is in EVPN address family
Ticket: #17890
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
If we have `neighbor X bfd` and BFD status is DOWN and/or ADMIN_DOWN, and BGP
session is not yet established, we never allow the session to establish.
Let's fix this regression that was in 10.2.
Fixes: 1fb48f5 ("bgpd: Do not start BGP session if BFD profile is in shutdown state")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Previously bgpd needed to send a withdraw followed by an install
to update an EVPN prefix route. With refcount tracking in zebra
this is no longer needed
Signed-off-by: Christopher Dziomba <christopher.dziomba@telekom.de>
While here, also make "VPN SAFI clear" test wait for clear result
(tests/topotests/bgp_rfapi_basic_sanity{,_config2})
Original RFAPI code relied on the frr timer system to remember
various allocations that were supposed to be freed at future times
rather than manage a parallel database. However, if bgpd is terminated
before the times expire, those pending allocations are marked as
memory leaks, even though they wouldn't be leaks under normal operation.
This change adds some hash tables to track these outstanding
allocations that are associated with pending timers, and uses
those tables to free the allocations when bgpd exits.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
Fix this:
==3890443== 92 (48 direct, 44 indirect) bytes in 1 blocks are definitely lost in loss record 68 of 98
==3890443== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3890443== by 0x49737B3: qcalloc (memory.c:106)
==3890443== by 0x3EA63B: aspath_dup (bgp_aspath.c:703)
==3890443== by 0x2F5438: route_set_aspath_exclude (bgp_routemap.c:2604)
==3890443== by 0x49BC52A: route_map_apply_ext (routemap.c:2708)
==3890443== by 0x2C1069: bgp_input_modifier (bgp_route.c:1925)
==3890443== by 0x2C9F12: bgp_update (bgp_route.c:5205)
==3890443== by 0x2CF281: bgp_nlri_parse_ip (bgp_route.c:7271)
==3890443== by 0x2A28C7: bgp_nlri_parse (bgp_packet.c:338)
==3890443== by 0x2A7F5C: bgp_update_receive (bgp_packet.c:2448)
==3890443== by 0x2ACCA6: bgp_process_packet (bgp_packet.c:4046)
==3890443== by 0x49EB77C: event_call (event.c:2019)
==3890443== by 0x495FAD1: frr_run (libfrr.c:1247)
==3890443== by 0x208D6D: main (bgp_main.c:557)
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There are some tables not being freed upon shutdown. This
is happening because the table is being locked as dests
are being put on the metaQ. When in shutdown it was clearing
the MetaQ it was not unlocking the table
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Commit: e0ae285eb8
Modified the fsm state machine to attempt to not
clear routes on a peer that was not established.
The peer should be not a peer self. We do not want
to ever clear the peer self.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
