Found that zebra_rnh_apply_nht_rmap would set the
NEXTHOP_FLAG_ACTIVE if not blocked by the route-map, even
if the flag was not active prior to the check. This fix
changes the flag used to denote the nexthop is filtered so
that proper active state can be retained. Additionally,
found two cases where we would send invalid nexthops via
send_client, which would also cause this crash. All three
fixed in this commit.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Add a bit of code to allow us to look at specified S,G for
the upstream available to us.
If one item is listed we assume Group, if both we assume Source
then Group.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add a bit of code to allow us to look at specified S,G for
the upstreams available to us.
If one item is listed we assume Group, if both we assume Source then
Group.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Update the nexthop flag output for the route entry dump to
include all possible flag states be output.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We currently run nexthop_active_check multiple times. Make the
code run once and figure out state from that.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The nexthop_active_update command looks at each individual
nexthop and decides if it has changed. If any nexthop
has changed we will set the re->status to ROUTE_ENTRY_CHANGED
and ROUTE_ENTRY_NEXTHOPS_CHANGED.
Additionally the test for old_nh_num != curr_active
makes no sense because suppose we have several events
we are processing at the same time and a total ecmp
of 16 but 14 are active at the start and 14 are active
at the end but different interfaces are up or down.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The NEXTHOP_FLAG_FILTERED went away when we started treating
static routes like every other route in the system. This was
a special case for handling static route code that just didn't
get finished cleaning up.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
We are effectively calling nexthop_active_update() on every
route entry being processed for installation at least 2 times.
This is a bit ridiculous. We need to resolve the nexthops
when we know a route has changed in some manner, so do so.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The tests are not coming up consistently on my test box. Add a bit of wait
time to test to allow normal bgp when the first attempt doesn't come up.
Especially since bgp timeouts are 120 seconds with non datacenter compiles.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This subdirectory is outdated in all possible ways. Remove it.
FRR already has a FreeBSD port and it's maintained separately.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Certain operations, like removing non-presence containers or
modifying list keys, are not considered to be valid from the
perspective of the northbound layer. This is because we want to
implement a minimum set of northbound configuration callbacks and
use them to process all possible configuration changes.
The removal of a np-container [1], for example, can be processed by
calling the "delete" callback of all of its child nodes (recursion
is used for np-container child nodes). Similarly, the modification
of a list key can be processed as if the corresponding list entry
was removed and readded with updated key values. This strategy saves
us the burden of implementing lots of extra configuration callbacks.
That said, the nb_operation_is_valid() function shouldn't be used
for anything other than checking which callbacks are valid for
which YANG nodes. Using it in the nb_candidate_edit() function
is inappropriate as we want as much flexibility as possible when
editing a candidate configuration. We should allow CLI commands,
for example, to remove np-containers (the northbound layer will then
figure out which callbacks need to be called when this candidate
is committed). Remove the check.
[1] We can't do the same for presence containers since they have a
"create" callback associated with them.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
flog() is a small wrapper around zlog() that can be useful in a
few places to reduce code duplication.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
zlog() should be part of the public logging API as it's useful in
the cases where the logging priority isn't known at compile time
(i.e. it depends on a variable).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
EVPN routes (type-2/type-5) are imported from
default bgp instance (where they are learnt) to
non-default vrf instance.
When a bgp instance (default) is deleted,
unimport evpn routes from vrfs.
In absence of unimport, the imported routes in vrf
has parent path info points to default instance's path
info which is no longer valid (if instance is deleted).
When accessing parent path info leads to a crash
in non-default vrf instance.
The bgp instance is not cleaned up when
'no router bgp ASN' is performed, the instance's
reference count remains for evpn imported routes.
Ticket:CM-24484
Reviewed By:
Testing Done:
Validated via learning EVPN type-2/type-5 routes in symmetric
routing scenario.
The routes are imported to VRFs based on corresponding
L3VNI. When the default instance is removed, the evpn routes
are cleaned up from the VRF instance.
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
Network Next Hop Metric LocPrf Weight Path
*> 70.1.0.0/16 0.0.0.0 32768 i
s 70.1.1.24/32 110.0.0.2 0 65100 65002 i
s> 110.0.0.2 0 65100 65002 i
s 70.1.1.43/32 110.0.0.4 0 65100 65004 i
s> 110.0.0.4 0 65100 65004 i
TURTLE(config)# no router bgp 65050
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
No BGP prefixes displayed, 0 exist
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Move call to nb_db_init() from nb_init() to frr_init() so that only
the FRR daemons will initialize the northbound database. This should
fix a few warnings when running some unit tests.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
