Introduce a hash table to keep track of user pointers associated
to configuration entries. The previous strategy was to embed
the user pointers inside libyang data nodes, but this solution
incurred a substantial performance overhead. The user pointers
embedded in candidate configurations could be lost while the
configuration was being edited, so they needed to be regenerated
before the candidate could be committed. This was done by the
nb_candidate_restore_priv_pointers() function, which was extremely
expensive for large configurations. The new hash table solves this
performance problem.
The yang_dnode_[gs]et_entry() functions were renamed and moved from
yang.[ch] to northbound.[ch], which is a more appropriate place
for them. This patch also introduces the nb_running_unset_entry()
function, the counterpart of nb_running_set_entry() (unsetting
user pointers was done automatically before, now it needs to be
done manually).
As a consequence of these changes, we shouldn't need support for
libyang private pointers anymore (-DENABLE_LYD_PRIV=ON). But it's
probably a good idea to keep requiring this feature as we might
need it in the future for other things (e.g. disable configuration
settings without removing them).
Fixes#4136.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
if bfd comes back up, and a bgp reconnection is in progress, theorically
it should be necessary to wait for the end of the reconnection process.
however, since that reconnection process may take some time, update the
fsm by cancelling the connect timer. This done, one just have to call
the start timer.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Bgp periodically tries to reconnect, while the connection
is down. When bfd event comes up, BGP is not aware that bfd connection
is up, then BGP can not adapt its reconnection timer. The modification
is here to force BGP to restart, when BFD event comes up, and BGP has
not yet established.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Manually tested rather extensively in addition to included unit tests,
should work as intended.
NB: The OpenBSD futex() code is "future"; it's not actually in OpenBSD
(yet?) and thus untested.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
when a remote daemon wants to get rid of a session, a request is sent,
but the deletion of the bfd session was not done. The flush is done,
provided that there is not someone else that is using that session.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
there are cases where bfd sessions are created from remote daemons. in
that case, the bfd daemon were appearing in both operational and
configuration contexts of bfd. Change that by only keeping operational
contexts.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
After exceeding the max retry number for a thread,
we were passing the data rather than the work_queue_item
struct.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
The order of ECMP nexthops currently depends on whatever order the
pqueue code returns the vertices in, which is essentially random since
they compare as equal. While this shouldn't cause issues normally, it
is nondeterministic and causes the ldp-topo1 test to fail when the
ordering comes up different. Also, nondeterministic behaviour is not a
nice thing to have here in general.
Just sort by nexthop address; realistic numbers of ECMP nexthops should
hopefully not make this a performance issue. (Also, nexthops should be
hot in the caches here.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The ospf6_route_get_first_nh_index function call calls
listhead which returns a (listnode *) but we are casting
it to a (struct ospf6_nexthop *) and away we go.
Fixes: #4142
Found By: Kwind
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Co-authored-by: Donald Sharp <sharpd@cumulusnetworks.com>
Co-authored-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
MD5 auth on TCP is supported for prefixes in recent versions of Linux;
add complementary support for FRR.
This is a reworked version of Donald's commit to keep library
compatibility and obviate the need for changes in daemons that don't
need to support this themselves.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
libyang defaults CMAKE_BUILD_TYPE to "Debug", which disables compiler
optimizations. We should instruct our users to build libyang in the
"Release" mode so that compiler optimizations are enabled and they
can benefit from the associated performance improvements.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Move down the "circuit-type" leaf in the isisd YANG module so that
"ip[v6] router isis" will be the first commands displayed in the
running configuration.
Fixes#4028.
Signed-off-by: Dmitrii Turlupov <dturlupov@factor-ts.ru>
Split the "debug northbound" command into the following commands:
* debug northbound callbacks configuration
* debug northbound callbacks state
* debug northbound callbacks rpc
* debug northbound notifications
* debug northbound events
* debug northbound client confd
* debug northbound client sysrepo
If "debug northbound" is entered alone, all of its suboptions
are enabled.
This commit also adds code to debug state/rpc callbacks and
notifications (only configuration callbacks were logged before).
Use the debugging infrastructure from "lib/debug.h" in order to
benefit from its facilities (e.g. MT-safe debugging) and avoid
code duplication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
- Change MPLS-TE from global to per Area
- Add new mpls_te_area structure to area in replacement of global variable
isisMPLS_TE
- Move mpls-te frmo global to instance in frr-isisd.yang
- Change code in isis_te.c, isis_northbound.c, isis_cli.c, isis_pdu.c,
isis_lsp.c and isis_zebra.c accordingly
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
L3VNI configured in a specific VRF is allowed to unconfigure from any
VRF, including default (global) VRF. This results L3VNI delete notification
to BGP and subsequent type-5 route uninstall from the VRF the L3VNI belong to.
This also resulted in the inconsistent running configuration.
The deleted L3VNI still shows up in its original VRF. The VRF in which the
"no vni <x>" was executed doesn't display its own L3VNI.
Added a VRF check in zebra to prevent this.
Signed-off-by: Kishore Aramalla <karamalla@vmware.com>
