The `_once` loop variable will result in a `-Wshadow` warning when that
is turned on. Use `__COUNTER__` to give these variables distinct names,
like is already done with `_mtx_`.
(and because I touched it, clang-format wants it reformatted... ohwell.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Currently, when the locator block and sid block differs, staticd would
still go ahead and request zebra to allocate the SID which it does if
there is atleast one match (from any locators).
Only when staticd tries to install the route, it sees that the locator
block and sid block are different and avoids installing the route.
Fix:
Check if the locator block and sid block match before even requesting
Zebra to allocate one.
Signed-off-by: Rajasekar Raja <rajasekarr@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>
`"` was accidentally added, and random tests failures happening.
Fixes: a4f61b78dd ("tests: Check if routes are marked as stale and retained with N-bit for GR")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
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>
Coverity is complaining about use after free's in
clearing eigrp neighbors. Clean the code
up to not have the problem.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently EIGRP has built in yang code that expects only
1 ASN used per vrf. Let's just limit the operator from
putting themselves in a bad position by allowing something like
this:
router eigrp 33
....
!
router eigrp 99
...
!
no router eigrp 99 would crash because of assumptions
made in the yang processing.
Let's just hard code that assumption into the EIGRP yang
at the moment such that it will not allow you to enter
a `router eigrp 99` instance at all.
This is purely a software limitation to prevent the code
from violating it's current assumptions. I do not see
much need to support this at this point in time so I
fixed the problem this way instead of having to possibly
touch a bunch of code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>