Collapse some apis where primary and backup nhlfe code
was very similar, generally using a single common api
and using a bool to distinguish between primary and
backup.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Add an init api (based on what had been a private/static api)
to allow a caller to init a context and use it to generate LSP
updates. This might be useful for testing, or from a dplane
plugin.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Include backup nexthops when examining routes that resolve
NHT requests. Include installed backups when sending nexthops
in zapi messages to client daemons.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
When handling a fib notification event that involves a route
with backup nexthops, be clearer about representing the
installed state of the backups: any installed backup will be
on a dedicated route_entry list.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Include backup nexthops in json output; function-ify the json
output for nexthops; revise the display of backup nexthops to
use the 'b' character.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Remove a special-case clause for static routes - it was the same
as the clause for other recursive routes. Have staticd just tell
zebra that recursion is allowed. Update topotest that was aware
of this 'internal' flag.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
1. It will generate support bundle/sump data on test failures
2. It used /usr/lib/frr/generate_support_bundle.py utility to dump the data
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
Add note blocks to the topotest and topotest-json dev docs to
emphasize the need for generous BGP retry/convergence timers.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Another short timeout for bgp - make the
verify_bgp_convergence_from_running_config() api use the same
generous timeout as verify_bgp_convergence()
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Default originate with route-map was broken. Routemap
was not getting applied for redistribute route but was
getting applied default route itself. No default route
was originated even when routemap was satisfied.
Signed-off-by: Santosh P K <sapk@vmware.com>
There exists the possiblity that the hello timer printed would
show a time to expiration in this format:
Hello due in 350 usecs
The tests are looking for:
Hello due in 5.430s
Just notice that we may have gotten usecs and act accordingly
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Route map entries are not getting a chance to call `description` string
deallocation on shutdown or when the parent entry is destroyed, so lets
add a code to handle this in the `route_map_index_delete` function.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
1. Added 7 test cases to verify bgp recursive nexthop and ebgp multi-hop functionality
2. Added framework support to automate these test cases
3. Total execution time is ~5 mins
Signed-off-by: Kuldeep Kashyap <kashyapk@vmware.com>
the code in isis_spf_add2tent was asserting in case the vertex
we were trying to add was already present in the path or tent
trees. This however CAN happen if the user accidentally configures
the system Id of the area to the same value of an estabished
neighbor. Handle this more gracefully by logging and returning,
to prevent crashes.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Check the LSP INSTALLED flag in delete apis, to ensure we
enqueue a delete operation for the lfib. Some apis were only
checking the nexthop/nhlfe INSTALLED flags, and those could be
unset if there's an in-flight dataplane update.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Use the right list of daemons to avoid trying to start zebra twice.
Change a zebra log message to INFO level to avoid stderr check
failure.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Add a few retries during router shutdown before killing a daemon. Also
work harder to start only a single instance of daemons, esp. zebra.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Unfortunately as the topotests show a fast recovery after failure
detection due to BFD is currently not possible because of the following
issue:
There are multiple scheduling mechanisms within isisd to prevent
overload situations. Regarding our problem these two are important:
* scheduler for regenerating ISIS Link State PDUs scheduler for managing
* consecutive SPF calculations
In fact both schedulers are coupled, the first one triggers the second
one, which again is triggered by isis_adj_state_change (which again is
triggered by a BFD 'down' message). The re-calculation of SPF paths
finally triggers updates in zebra for the RIB.
Both schedulers work as a throttle, e.g. they allow the regeneration of
Link State PDUs or a re-calculation for SPF paths only once within a
certain time interval which is configurable (and by default different!).
This means that a request can go through the first scheduler but might
still be 'stuck' at the second one for a while. Or a request can be
'stuck' at the first scheduler even though the second one is ready. This
also explains the 'random' behaviour one can observe testing since a
'fast' recovery is only possible if both schedulers are ready to process
this request.
Note that the solution in this commit is 'thread safe' in the sense that
both schedulers use the same thread master such that the introduced
flags are only used exactly one time (and one after another) for a
'fast' execution.
Further there are some irritating comments and logs which I partially
removed. They seems to be not valid anymore due to changes in thread
management (or they were never valid in the first place).
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
