When a client disconnects, we need to check & remove NHT entries for
other SAFIs too. Otherwise we crash later trying to access stale data.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Small simplification for evpn RT commands, i.e. both per-VRF
and per-VNI - `bgp_evpn_vrf_rt_cmd` and `bgp_evpn_vni_rt_cmd`.
Just extract the duplicated code as a common code, there are
no functional changes.
Additionally correct one comment for `ecommunity_free()`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
When babeld was switched over to the zapi
interface up/down callbacks the interface up
event was not properly put back in.
Fixes: #10893
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
These 3 values:
ONE_DAY_SECOND
ONE_WEEK_SECOND
ONE_YEAR_SECOND
Are defined based upon the number of seconds. Unfortunately doing math
on these values say something like:
days = t->tv_sec / ONE_DAY_SECOND;
Once you go over about a day causes the order of operations to cause the multiplication
to get messed up:
204 if (!t)
(gdb) n
207 w = d = h = m = ms = 0;
(gdb) set t->tv_sec = ONE_DAY_SECOND + 30
(gdb) n
208 memset(buf, 0, size);
(gdb)
210 us = t->tv_usec;
(gdb)
211 if (us >= 1000) {
(gdb)
212 ms = us / 1000;
(gdb)
213 us %= 1000;
(gdb)
217 if (ms >= 1000) {
(gdb)
222 if (t->tv_sec > ONE_WEEK_SECOND) {
(gdb)
227 if (t->tv_sec > ONE_DAY_SECOND) {
(gdb)
228 d = t->tv_sec / ONE_DAY_SECOND;
(gdb) n
229 t->tv_sec -= d * ONE_DAY_SECOND;
(gdb) n
232 if (t->tv_sec >= HOUR_IN_SECONDS) {
(gdb) p d
$6 = 2073600
(gdb) p t->tv_sec
$7 = -179158953570
(gdb)
Converting to adding paranthesis around around the ONE_DAY_SECOND causes
the order of operations to work as expected.
Fixes: #10880
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
spine1-debian-11(config-router)# bmp targets ?
BMPTARGETS Name of the BMP target group
ok test1
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The file m4/ax_lua.m4 needs to be a part of distribution, but it is not
inluded in the git repository by default becuase .gitignore file has a
wildcard for all *.m4 files, while individual files that must _not_ be
ignored are listed one by one as exceptions. ax_lua.m4 needs to be added
to this list of exceptions too.
One failure scenario is when you put a snapshot of the source tree in a
new git repository (e.g. the one used for a local CI/CD), this file is
not included in the repository, and subsequently build fails.
This commit adds the exception into m4/.gitignore file
Signed-off-by: Eugene Crosser <crosser@average.org>
`is_vni_param_configured()` is used to check whether RD/RT
configured for specific evpn vni.
There seems to be no need for this mixed check. No caller for
about 5 years, just remove it.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
There exists code paths in the linux kernel where a dump command
will be interrupted( I am not sure I understand what this really
means ) and the data sent back from the kernel is wrong or incomplete.
At this point in time I am not 100% certain what should be done, but
let's start noticing that this has happened so we can formulate a plan
or allow the end operator to know bad stuff is a foot at the circle K.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
That commit aim is to fix an invalid behavior when
default-information is activated on ospf router without always option.
Consider an ASBR with:
-one default route coming from ospf,
-and another default route coming from another deaemon (such BGP or static).
When the daemon bgp stops advertising its default route,
-ospf continues to advertise its previous default route (with aging 0),
-this may create default routing loops.
Expected behavior: is to update the removed external default route with
MAXAGING value.
Updating with MAXAGING value will notify the fact the route is currently
invalid. A later removal from ospf external LSA database will be made.
Analysis: all default routes have their type overwritten by a
DEFAULT_ROUTE type. Thus all default routes whatever its origin (ospf,
bgp, static...) is treated in a same way. But this is not pertinent for
ospf originated default routes.
Fix: avoid overwiting of route type when default route is ospf type.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Problem:
PIM assert is not triggered even after receiving WRONGVIF notification because of Could_assert flag not set.
CouldAssert(S,G,I) =
SPTbit(S,G)==TRUE
AND (RPF_interface(S) != I)
AND (I in ( ( joins(*,G) (-) prunes(S,G,rpt) )
(+) ( pim_include(*,G) (-) pim_exclude(S,G) )
(-) lost_assert(*,G)
(+) joins(S,G) (+) pim_include(S,G) ) )
Once SPTbit is set, Could_assert has to be reevaluated
Signed-off-by: plsaranya <Saranya_Panjarathina@dell.com>
The following configuration:
router ospf
segment-routing global-block 16000 23999 local-block 1000 2000
!
appears in the 'show running-config' like below:
router ospf
local-block 1000 2000
!
When there are custom Adjacencies, display the SRGB even if SRGB
has the default settings.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
There is no need to have an interface available to configure
SRGB. Conversely, it should be possible to remove the SRGB
when no interfaces are available.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When reading the BGP_PREFIX_SID_SRV6_L3_SERVICE_SID_STRUCTURE
it is possible that the length read in the packet is insufficiently
large enough to read a BGP_PREFIX_SID_SRV6_L3_SERVICE_SID_STRUCTURE.
Let's ensure that it is.
Fixes: #10860
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
IPV6_HDRINCL is a TX-only option (unlike IP_HDRINCL), so on RX there
never are IPv6 headers to be looked at / skipped over.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When `all` is specified BGP pointer is always NULL, we need to iterate over
all instances separately.
```
Received signal 11 at 1648199394 (si_addr 0x30, PC 0x562e96597090); aborting...
/usr/local/lib/libfrr.so.0(zlog_backtrace_sigsafe+0x5e) [0x7f378a57ff6e]
/usr/local/lib/libfrr.so.0(zlog_signal+0xe6) [0x7f378a580146]
/usr/local/lib/libfrr.so.0(+0xcd4c2) [0x7f378a5aa4c2]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x14140) [0x7f378a33e140]
/usr/lib/frr/bgpd(bgp_afi_safi_peer_exists+0) [0x562e96597090]
/usr/lib/frr/bgpd(+0x15c3b8) [0x562e9654a3b8]
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In the FreeBSD code if you delete the interface
and it has no configuration, the ifp pointer will
be deleted from the system *but* zebra continues
to dereference the just freed pointer.
==58624== Invalid read of size 1
==58624== at 0x48539F3: strlcpy (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==58624== by 0x2B0565: ifreq_set_name (ioctl.c:48)
==58624== by 0x2B0565: if_get_flags (ioctl.c:416)
==58624== by 0x2B2D9E: ifan_read (kernel_socket.c:455)
==58624== by 0x2B2D9E: kernel_read (kernel_socket.c:1403)
==58624== by 0x499F46E: thread_call (thread.c:2002)
==58624== by 0x495D2B7: frr_run (libfrr.c:1196)
==58624== by 0x2B40B8: main (main.c:471)
==58624== Address 0x6baa7f0 is 64 bytes inside a block of size 432 free'd
==58624== at 0x484ECDC: free (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==58624== by 0x4953A64: if_delete (if.c:283)
==58624== by 0x2A93C1: if_delete_update (interface.c:874)
==58624== by 0x2B2DF3: ifan_read (kernel_socket.c:453)
==58624== by 0x2B2DF3: kernel_read (kernel_socket.c:1403)
==58624== by 0x499F46E: thread_call (thread.c:2002)
==58624== by 0x495D2B7: frr_run (libfrr.c:1196)
==58624== by 0x2B40B8: main (main.c:471)
==58624== Block was alloc'd at
==58624== at 0x4851381: calloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==58624== by 0x496A022: qcalloc (memory.c:116)
==58624== by 0x49546BC: if_new (if.c:164)
==58624== by 0x49546BC: if_create_name (if.c:218)
==58624== by 0x49546BC: if_get_by_name (if.c:603)
==58624== by 0x2B1295: ifm_read (kernel_socket.c:628)
==58624== by 0x2A7FB6: interface_list (if_sysctl.c:129)
==58624== by 0x2E99C8: zebra_ns_enable (zebra_ns.c:127)
==58624== by 0x2E99C8: zebra_ns_init (zebra_ns.c:214)
==58624== by 0x2B3FF2: main (main.c:401)
==58624==
Zebra needs to pass back whether or not the ifp pointer
was freed when if_delete_update is called and it should
then check in ifan_read as well as ifm_read that the
ifp pointer is still valid for use.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When using zlog_backtrace I am seeing this:
==66286== Syscall param write(buf) points to uninitialised byte(s)
==66286== at 0x4CDF48A: syscall (in /lib/libc.so.7)
==66286== by 0x4A0D409: ??? (in /usr/local/lib/libunwind.so.8.0.1)
==66286== by 0x4A0D694: ??? (in /usr/local/lib/libunwind.so.8.0.1)
==66286== by 0x4A0E2F4: _ULx86_64_step (in /usr/local/lib/libunwind.so.8.0.1)
==66286== by 0x49662DB: zlog_backtrace (log.c:250)
==66286== by 0x2AFFA6: if_get_mtu (ioctl.c:163)
==66286== by 0x2B2D9D: ifan_read (kernel_socket.c:457)
==66286== by 0x2B2D9D: kernel_read (kernel_socket.c:1406)
==66286== by 0x499F46E: thread_call (thread.c:2002)
==66286== by 0x495D2B7: frr_run (libfrr.c:1196)
==66286== by 0x2B4098: main (main.c:471)
==66286== Address 0x7fc000000 is on thread 1's stack
==66286== in frame #4, created by zlog_backtrace (log.c:239)
==66286==
Let's initialize some data
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
