* Call rip_clean() only when RIP is configured, this way we can
remove one indentation level from this function.
* rip_redistribute_clean() is only called on shutdown, so there's
no need to call rip_redistribute_withdraw() there since the RIP
table is already cleaned up elsewhere.
* There's no need to clean up the "rip->neighbor" nodes manually before
calling route_table_finish().
* Deallocate the rip structure only at the end of the function. This
prepares the ground for the next commits where all global variables
will be moved to the rip structure.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fixes the following warning when running ripngd with valgrind:
==38== Syscall param sendmsg(msg.msg_control) points to uninitialised
byte(s)
==38== at 0x5EA1E47: sendmsg (sendmsg.c:28)
==38== by 0x118C48: ripng_send_packet (ripngd.c:226)
==38== by 0x11D1D6: ripng_request (ripngd.c:1924)
==38== by 0x120BD8: ripng_interface_wakeup (ripng_interface.c:666)
==38== by 0x4ECB4B4: thread_call (thread.c:1601)
==38== by 0x4E8D9CE: frr_run (libfrr.c:1011)
==38== by 0x1121C8: main (ripng_main.c:180)
==38== Address 0xffefffc34 is on thread 1's stack
==38== in frame #1, created by ripng_send_packet (ripngd.c:172)
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We were sending ZEBRA_INTERFACE_LINK_PARAMS messages under the
following circumstances:
* New interface was created (via kernel or config);
* Interface went from down to up;
* Update in the link-params configuration.
Now also send ZEBRA_INTERFACE_LINK_PARAMS messages whenever a zclient
connects and sends a ZEBRA_INTERFACE_ADD request. Without this fix,
the client daemons don't receive interface link parameters if they
are configured in the zebra startup configuration.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In these two functions, we were using VRF_DEFAULT instead of the
VRF ID passed as a parameter when checking if the given client
subscribed to receive default routes or not. This prevented the
"default-originate" command from ospfd/isisd from working correctly
under specific circumstances.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
client->ifinfo is a VRF bitmap, hence we need to use
vrf_bitmap_check() to check if a client is subscribed to receive
interface information for a particular VRF. Just checking if
the client->ifinfo value is set will always succeed since it's
a pointer initialized by zserv_client_create(). With this fix,
we'll stop sending interface messages from all VRFs to all clients,
even those that didn't subscribe to it.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
the command was not checking
correctly in all cases whether the virtual link existed. This caused
bugs in some corner cases, e.g. when two virtual links were created,
one of them was deleted, and the second one was reset with no
authentication - this would instead create a new virtual link with
the area in decimal format.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
strlen is the same as sizeof when the memory is dynamically allocated
but it is not the same when the memory being looked at is an array.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The modules.rst documents how to create a module, let's update
it a bit to reflect what an end user needs to do a bit more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
default-information originate does not work
if config is removed and re-added.
Ticket:CM-20026
Testing Done:
Validate default-information originate config
removed and re-added, check ospf lsa database, and peer
route cache entry for default route.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Unfortunately the first version of the FreeBSD libyang port contained
a bug in which the libyang pkginfo file wasn't being installed
correctly in the system, and this prevented the FRR build system from
detecting the library. This bug was already fixed months ago but some
FreeBSD package repositories still have the old bugged version of the
port. This means we can't suggest people to install libyang using
"pkg install" since this causes problems for most people. In this
case, suggest FreeBSD users to build and install libyang manually
as we suggest for other BSD platforms.
This commit should be reverted once all FreeBSD package repositories
are updated with the new version of the libyang port.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Since commit 3a11599c, the FRR YANG modules are embedded inside the
binaries and no longer need to be loaded from the file system. This
way, it's impossible for the FRR binaries and YANG modules to be out
of sync anymore. As such, update the suggestions of the northbound
error codes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Instead of aborting when an incomplete xpath is given to the
nb_oper_data_iterate() function, just return an error so that the
callers have a chance to treat this error. Aborting based on invalid
user input is never the right thing to do.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When FRR is built without the --enable-config-rollbacks option,
the nb_db_transaction_save() function does nothing and the
"transaction_id" output parameter is left uninitialized. For
this reason, all northbound clients should initialize the
"transaction_id" argument before calling nb_candidate_commit() or
nb_candidate_commit_apply() (except when a NULL pointer is given,
which is the case of the confd and sysrepo plugins).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
We are already handling all possible four cases from the "nb_event"
enumeration, so this problem can't happen in practice. Initialize the
"ref" variable to zero to silence the warning.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Routes without nexthops don't make any sense, so we need to reject
them otherwise weird things can happen.
NOTE: blackhole routes aren't nexthop-less, they do have a single
nexthop of type NEXTHOP_TYPE_BLACKHOLE.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Some daemons like ospfd and isisd have the ability to advertise a
default route to their peers only if one exists in the RIB. This
is what the "default-information originate" commands do when used
without the "always" parameter.
For that to work, these daemons use the ZEBRA_REDISTRIBUTE_DEFAULT_ADD
message to request default route information to zebra. The problem
is that this message didn't have an AFI parameter, so a default route
from any address-family would satisfy the requests from both daemons
(e.g. ::/0 would trigger ospfd to advertise a default route to its
peers, and 0.0.0.0/0 would trigger isisd to advertise a default route
to its IPv6 peers).
Fix this by adding an AFI parameter to the
ZEBRA_REDISTRIBUTE_DEFAULT_{ADD,DELETE} messages and making the
corresponding code changes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The timer2str function thought 24 minutes was an hour and had a
couple of other issues that needed to be corrected.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Future commits are going to introduce more rigor in
state setting in the case of received results from
the data plane. So let us move the DPLANE_OP_ROUTE_DELETE
state check to the same spot as the rest of the code that
is handling a particular operation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the status flag from 8 bits to 32 bits and to add
a few new flags that will be used in future commits.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the meta_queue insertion such that we only enqueue
the route_node into one meta_queue instead of several.
Suppose we have multiple route_entries associated with
a particular node from rip, bgp, staticd. If we receive a
route update from rip, we would enqueue the route_node into
the 1, 2, 3 meta-nodes. Which means that we would run
the entire process of figuring out a route 3 times, while
nothing would change the second two times.
Modify the code to choose the lowest meta-queue and
install it into that one for processing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Not sure why this wasn't caught by our CI system. I thought it
would. My screw up this should have been right from the start.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
When a dataplane provider/plugin registers, return the new
handle/object - that's needed to use some provider apis
later on.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
