We don't need to scan through all configured areas to find the circuit
associated with the interface. It is always stored in ifp->info.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
There are two APIs to control the expected number of hops for a BFD
session – `bfd_sess_set_mininum_ttl` and `bfd_sess_set_hop_count`.
The former is very confusing, as it takes an expected TTL in the
BFD packet which is actually a protocol internal value. The latter is
simple and straightforward – it takes an expected number of hops, which
is always 1 for single-hop and >1 for multi-hop.
As the former API is not used anywhere, just remove it to avoid any
confusion.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
`AC_PROG_LEX without either yywrap or noyywrap is obsolete`, says
autoconf 2.70. Sadly, there is no transition window for this, in 2.69
the macro takes no arguments.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
enum based switches should never use default. It makes
it very hard to fix and find issues when the enum is
changed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Issue #9983 explains what is wrong with the GR helper mode.
To unblock the CI that fails almost all the time on the ospf_gr_topo1
test, remove the commands and disable the test. Also add a reminder to
completely remove the helper mode if no one fixes the code in a month.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
It's strictly optional, but… the backtraces are really much better.
Specifically, `libunwind` is notably more capable in figuring out
function names compared to glibc/libexecinfo `backtrace_symbols()`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... need to ignore TLS sections, their address is effectively
meaningless but can overlap other sections we actually need to access.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
show/clear DEFUNs always require either peer label or IP address to be
specified, so if `label` is NULL then `peer_str` is definitely not NULL.
But Coverity doesn't know about that, so it complains about possible
NULL dereference of `peer_str`. This commit should make Coverity happy.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
`assert.h` -> `xref.h` -> `typesafe.h` -> `assert.h`
Might be possible to do this more cleanly some way, but that way is not
obvious, so here's the "simple & dumb" approach.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Looks much prettier if `libunwind` is available, but works with glibc or
libexecinfo's `backtrace()` too.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* Separate process into stages; stage 1 is preparation, stage 2 is
staging, stage 3 is publishing
* Reorder some steps
* Remove some steps
* Elaborate on some steps
* Add some steps
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
pim-vxlan uses periodic null registers to bootstrap a new (VTEP, mcast-grp).
These null registers were not being sent if the (S, G) was already present
and in a register-join state.
Ticket: #2848079
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
Description:
timerval datastructure is being used without initialization.
Using these uninitialized parameters can lead unexpected results
so initializing before using it.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Clarify process for editing changelog and updating the configure.ac
project version, as well as procedure for doing sanity testing prior to
creating the release tag.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Problem:
L2-VNI SVI down followed by L2-VNI's vxlan device
deletion leads to stale entry into L3VNI's
L2-VNI list.
Solution:
When L2-VNI associated SVI is down, default vrf
is the new tenant vrf.
Remove L2-VNI from L3VNI's l2vni list as
L3VNI/VRF is no longer valid in absence of associated
SVI.
When SVI is up re-add L2-VNI into associated VRF's
L3VNI.
The above remove/add from the L3VNI's L2VNI list is
already done when vxlan or L2-VNI is flaped, just need
to handle when SVI is flapped.
Ticket:#2817127
Reviewed By:
Testing Done:
After deleting SVI following by L2-VNI deletion,
L3VNI's L2-VNI list delets the L2-VNI. (no stale entry).
After adding back SVI/L2-VNI, L3VNI list adds back the
L2-VNI and it is associated right tenant VRF.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
frr-reload fails to recognize wildcard "*" for
member address in frr.conf/runing-config as cli
syntax expects in v4 address format.
Ticket: #2816923
Testing:
Without fix:
running config:
ip msdp mesh-group foo1 member *
Frr reoad failure log:
2021-11-02 11:05:04,317 INFO: Loading Config object from vtysh show running
line 5: % Unknown command: ip msdp mesh-group foo1 member *
Traceback (most recent call last):
File "/usr/lib/frr/frr-reload.py", line 1950, in <module>
With fix:
--------
running config displays:
ip msdp mesh-group foo1 member 0.0.0.0
Signed-off-by: Chirag Shah <chirag@nvidia.com>
... its only purpose was to serve as a footgun, and all such uses have
been eliminated now.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This can't really be run as part of CI, it's intended as a helper
instead, to use manually after poking around in the c-ares binding code.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
common_cli.c disables logging by default so stdio is usable as vty
without log messages getting strewn inbetween. This the right thing for
most tests, but not all; sometimes we do want log messages.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The `struct thread **ref` that the thread code takes is written to and
needs to stay valid over the lifetime of a thread. This does not hold
up if thread pointers are directly put in a `vector` since adding items
to a `vector` may reallocate the entire array. The thread code would
then write to a now-invalid `ref`, potentially corrupting entirely
unrelated data.
This should be extremely rare to trigger in practice since we only use
one c-ares channel, which will likely only ever use one fd, so the
vector is never resized. That said, c-ares using only one fd is just
plain fragile luck.
Either way, fix this by creating a resolver_fd tracking struct, and
clean up the code while we're at it.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
949aaea5 removed debugs from all topotests, but this test relies on the
debug logs so it constantly fails now.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
