If we have already scheduled a node to be on the meta_queue, there is no
need to schedule it up again.
On startup we are calling rib_update() multiple times per connected route.
Due to the multiple ways we can get callbacks for adding a connected route
I decided it was best to just improve meta_queue performance as opposed
to trying to figure out all the different ways across all the platforms
that we can decide that a connected route has changed. This appears
to solve the issue with a very large # of interfaces coming up
at the same time on startup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we receive or generate new versions of fragments which are
curently pending for age out, we need to ensure that they are correctly
linked to their lsp0.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
isis_spf_schedule gets called in states where an immediate spf run
will lead to crashes, e.g. from lsp_destroy. Delay the spf execution
until the event calling isis_spf_schedule has run to completion to
avoid this.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
There is no point in building a multipath route via one neighbor
if there is only one link to the neighbor, but the neighbor has
multiple IPs on that link. So only create one nexthop per link.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
If pim/igmp is not enabled on an interface, the ->info pointer will be
null. Need to check that before dereferencing it.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Standard IS-IS only supports up to 256 fragments per router. Recognize
when the information we want to advertise exceeds 256 fragments and
print a warning in this case instead of overflowing the fragment counter
and overwriting existing LSP fragments.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
SPF maintains a datastructure which is never actually read. I think
we can spend CPU more sensibly.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
This is a fallout from PR #1022 (zapi consolidation). In the early days,
the client daemons would allocate enough memory to send all nexthops
to zebra. Then zebra would add all nexthops to the RIB and respect
MULTIPATH_NUM only when installing the routes in the kernel. Now things
are different and the client daemons can send at most MULTIPATH_NUM
nexthops to zebra, and failure to respect that will result in a buffer
overflow. The MULTIPATH_NUM limit in the new zebra API is a small price
we pay to avoid allocating memory for each route sent to zebra.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
On shutdown we were deleting the linked list that
kept the zclient connections, but we were not
freeing the data pointed at by the link list.
This modification allows the normal cleanup of the
linked list to cleanup the zclient data structure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The previous code assumed that all nexthops of an ECMP route were of
the same address-family. This is not always the case.
Reported-by: Don Slice <dslice@cumulusnetworks.com>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Static routes were not keeping track of uptime appopriately and
as such we were not properly displaying uptime.
Fixes: #1196
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Presently CLI entered for daemons which are not running is accepted
quietly, which can be confusing for users. This patch warns about it
when possible.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
If you cut-n-paste an existing "ip igmp join 233.200.0.0 0.0.0.0"
command under an interface we should not return an error.
This fixes the broken indentation of several foreach loops throughout
the code.
From clang's documentation[1]:
ForEachMacros: A vector of macros that should be interpreted as foreach
loops instead of as function calls.
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When unsupported EVPN route types are are received / displayed with a
show command we print an uninitialized stack buffer.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
With the change to allow bgp_evpn.c to support 2,3 and 5 evpn routes
the output of the route type is being done by bgp_evpn_encode_prefix
instead of the individual route encoder functions.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com.
