These counters are accessible through BMP and may be useful to monitor
bgpd. A CLI to show them could also be added if people are interested.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
last_reset_cause_size is the length *used* in last_reset_cause[]. It's
straight up used wrong here; we're saving off a reset cause and need to
check against the *available* size in last_reset_cause[].
This could actually have led to (hopefully rare) crashes in the assert
there, since the assert condition might fail incorrectly.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The current directory is in the build tree while running clippy; find
ourselves so we can access headers from the source tree.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The shutdown of ospf was causing crashes because the shutdown
was calling a ALL_LIST_ELEMENTS_RO macro and modifying the
underlying data structures. Switch to using ALL_LIST_ELEMENTS.
This is caused by this change:
commit f9e1501aea5d429be2ecda1a3e2bde17e6ad5e4b
Author: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Wed Feb 27 15:08:29 2019 -0500
ospfd: Cleanup ospf->redist and ospf->external on shutdown
Effectively my original testing for this only had one external
route and as such we would not have a crash here. It only
showed up after multiple externals have been introduced.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the process pids to the output produced by 'show modules'.
At least in a development setting, where there may be multiple
instances of frr running, it can be handy to be able to id
the exact pids, for debugging e.g.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
bgp update messages were not correctly calculating the size
for a labeled-unicast prefix, as they were not accounting
for the label. If the update message was large enough to
overflow the maximum packet size (4096 bytes) this could
cause bgpd to send a malformed update packet.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
As part of PR 4458, when a client (bgpd) goes down,
zebra cleans up any evpn state including remotely learned
neighs, macs and vteps are suppose to be cleaned up,
uninstall from kernel tables.
Neighs (arps), macs and vteps (HREP entries) were not
removed from kernel tables as the uninstall flag as not set.
Clean up l3vni associated remote neighs, macs and vteps.
Ticket:CM-25468
Reviewed By:CCR-8889
Testing Done:
Validated in evpn symmetric routing topology where
remotely learned l2/l3 vnis neigh, macs and remote
vtep (hrep) entries are installed in kernel table,
perform systemctl stop frr.service and validated
all remotely learned entries cleaned up from kernel
tables.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When using the LYD_PATH_OPT_NOPARENTRET flag, lyd_new_path() returns
the path-referenced node instead of the first created node. This
flag wasn't available in libyang 0.16-r1 so we couldn't use it
before. Use it now to simplify the code where possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
not getting displayed.
Neighbour prefix-count is not getting displayed with IPV6 neighbours
and displays the o/p “ % No such neighbor or address family ”.
However, I observed it is working fine for IPV4 neighbour.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
After ~4 months of deprecation period [1], drop support for older
libyang versions that don't support embedded extensions.
In addition to support for embedded extensions, libyang 0.16-r3
contains several bug fixes and performance improvements compared
to libyang-0.16-r1. It was about time to update.
Fixes:
* Issue #3273
* Issue #3971
[1] See commit 68626e08.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
libyang-0.16-r3 doesn't allow the creation of data nodes if their
corresponding "when" statement (if any) resolves to false. This
change broke the "ip rip authentication" command.
This commit adapts this command so that it's not affected by the
new libyang stricter validation checks.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
libyang-0.16-r3 contains a commit[1] that changed the autodelete
behavior of subtrees when validating data. A few FRR commands were
affected by this change since they relied on the old autodelete
behavior.
To fix these commands, use the LYD_OPT_WHENAUTODEL flag when
validating data to restore the old autodelete behavior (which adds
a lot of convenience for us).
[1] https://github.com/CESNET/libyang/commit/bbc43b1b4
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Based on Cisco YANG model but simplified to look more like FRR's CLI
options and types.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Add a file that exposes functions which modify nexthop groups.
Nexthop groups are techincally immutable but there are a
few special cases where we need direct access to add/remove
nexthops after the group has been made. This file provides a
way to expose those functions in a way that makes it clear
this is a private/hidden api.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a nexthop_dup() api that both allocates and copies
a new nexthop from an old one. Still retain the old exposed
function nexthop_copy() so we can copy without allocation.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add nexthop_group_copy and nexthop_group_add_sorted functions.
nexthop_group_copy -> Copy src nexthop_group into dst nexthop_group
nexthop_group_add_sorted -> Adds a new nexthop to the nexthop group
in a sorted manner.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When using pam for authentication, the code just silently
fails and gives no indication to the end user what has gone
wrong. Try to increase messaging about what has gone wrong
by outputting some more data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When installing a table route into the kernel choose
RTPROT_ZEBRA as the installing/controlling protocol.
This way we can know we installed it as well as stop
the warnings about this special case of `ip import-table XX`
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are importing/removing the table entry from table X into the
default routing table we are not properly setting the table_id
of the route entry. This is causing the route to be pushed
into the wrong internal table and to not be found for deletion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The import table code assumes that they will only work
in the default vrf. This is ok, but we should push the
vrf_id and zvrf to be passed in instead of just using
VRF_DEFAULT.
This will allow us to fix a couple of things:
1) A bug in import where we are not creating the
route entry with the appropriate table so the imported
entry is showing up in the wrong spot.
2) In the future allow `ip import-table X` to become
vrf aware very easily.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The import-table code when looking up the table to use
for route-import was reversing the order of the table_id
and vrf_id causing us to never ever lookup a table
and we would cause the `ip|ipv6 import-table X` commands
to be just ignored.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Improve debugging when we cannot find a route to delete
that we have been told to delete.
New output:
2019/06/25 17:43:49 ZEBRA: default[0]:4.5.6.7/32 doesn't exist in rib
2019/06/25 17:43:49 ZEBRA: default[0]:4.5.6.8/32 doesn't exist in rib
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
