Valgrind reports:
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A090D: bgp_bfd_dest_update (bgp_bfd.c:416)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A093C: bgp_bfd_dest_update (bgp_bfd.c:421)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
On looking at bgp_bfd_dest_update the function call into bfd_get_peer_info
when it fails to lookup the ifindex ifp pointer just returns leaving
the dest and src prefix pointers pointing to whatever was passed in.
Let's do two things:
a) The src pointer was sometimes assumed to be passed in and sometimes not.
Forget that. Make it always be passed in
b) memset the src and dst pointers to be all zeros. Then when we look
at either of the pointers we are not making decisions based upon random
data in the pointers.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When adjacencies change state the attached-bits in LSPs in other areas
on the router may need to be modified.
1. If a router no longer has a L2 adjacency to another area the
attached-bit must no longer be sent in the LSP
2. If a new L2 adjacency comes up in a different area then the
attached-bit should be sent in the LSP
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Valgrind reports:
2172861-==2172861==
2172861-==2172861== Syscall param write(buf) points to uninitialised byte(s)
2172861:==2172861== at 0x49B4FB3: write (write.c:26)
2172861-==2172861== by 0x48A4EA0: buffer_write (buffer.c:475)
2172861-==2172861== by 0x4915AD9: zclient_send_message (zclient.c:298)
2172861-==2172861== by 0x12AE08: isis_ldp_sync_state_req_msg (isis_ldp_sync.c:152)
2172861-==2172861== by 0x12B74B: isis_ldp_sync_adj_state_change (isis_ldp_sync.c:305)
2172861-==2172861== by 0x16DE04: hook_call_isis_adj_state_change_hook.isra.0 (isis_adjacency.c:141)
2172861-==2172861== by 0x16EE27: isis_adj_state_change (isis_adjacency.c:371)
2172861-==2172861== by 0x16F1F3: isis_adj_process_threeway (isis_adjacency.c:242)
2172861-==2172861== by 0x13BCCA: process_p2p_hello (isis_pdu.c:283)
2172861-==2172861== by 0x13BCCA: process_hello (isis_pdu.c:781)
2172861-==2172861== by 0x13BCCA: isis_handle_pdu (isis_pdu.c:1700)
Sending of request includes uninited memory at the end of the interface
name string. Fix
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Looks like the #if 0 code in this place was for ESI support
on solaris. We do not support solaris anymore. So let's
remove with prejudice.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The purpose of the Attach-bit is to accomplish inter-area routing. In other
venders, the Attached-bit is automatically set when a router is configured
as a L1|L2 router and has two adjacencies. When a L1 router receives a LSP
with the Attached-bit set it is supposed to create a default route pointing
toward the neighbor to provide a default path out of the L1 area.
ISIS implementation has been fixed to support the above definition:
Setting the Attach-bit is now the default behavior and we allow the user to
turn it off.
We will only set the Default Attach-bit when creating a L1 LSP, if we are
a L1|L2 router and have a L2 adjacency up.
When a L1 router receives a LSP with the Attach-bit set, we will create a
default route pointing to the L1|L2 router as the nexthop.
The default route will be removed if the LSP is received with the Attach-bit
cleared.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Currently the transition metric style is redundant because isis will
always read both reachability TLVs regardless of the configured
metric style. Correct this by only considering TLVs matching our
configuration.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
These two debug messages are so verbose to a point they impact
performance when testing RLFA/TI-LFA on large-scale networks. Remove
them since they aren't really useful.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Always call vid2string() whenever necessary instead of trying to be
too clever and call it only once. The original assumption was that
"buf" only needed to be initialized when LFA debugging was enabled,
but we also need that buffer when logging one error message.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Remote LFA (RFC 7490) is an extension to the base LFA mechanism
that uses dynamically determined tunnels to extend the IP-FRR
protection coverage.
RLFA is similar to TI-LFA in that it computes a post-convergence
SPT (with the protected interface pruned from the network topology)
and the P/Q spaces based on that SPT. There are a few differences
however:
* RLFAs can push at most one label, so the P/Q spaces need to
intersect otherwise the destination can't be protected (the
protection coverage is topology dependent).
* isisd needs to interface with ldpd to obtain the labels it needs to
create a tunnel to the PQ node. That interaction needs to be done
asynchronously to prevent blocking the daemon for too long. With
TI-LFA all required labels are already available in the LSPDB.
RLFA and TI-LFA have more similarities than differences though,
and thanks to that both features share a lot of code.
Limitations:
* Only RLFA link protection is implemented. The algorithm used
to find node-protecting RLFAs (RFC 8102) is too CPU intensive and
doesn't always work. Most vendors implement RLFA link protection
only.
* RFC 7490 says it should be a local matter whether the repair path
selection policy favors LFA repairs over RLFA repairs. It might be
desirable, for instance, to prefer RLFAs that satisfy the downstream
condition over LFAs that don't. In this implementation, however,
RLFAs are only computed for destinations that can't be protected
by local LFAs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The "load-sharing" node is a boolean leaf that has a default
value. As such, it doesn't make sense to either create or delete
it. That node always exists in the configuration tree. Its value
should only be modified. Change the corresponding CLI wrapper
command to reflect that fact.
This commit doesn't introduce any change of behavior as the NB API
maps create/destroy edit operations to modify operations whenever
that makes sense. However it's better to not rely on that behavior
and always use the correct operations in the CLI commands.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When last area address is removed, resign if we were DR.
This fixes an issue where: when the ISIS area address is changed, ISIS fails
to elect a new DR.
Signed-off-by: Karen Schoener <karen@voltanet.io>
Removing the obsolete ldp-sync periodic 'hello' message.
When ldp-sync is configured, IGPs take action if the LDP process goes down.
The IGPs have been updated to use the zapi client close callback to detect
the LDP process going down.
Signed-off-by: Karen Schoener <karen@voltanet.io>
In some extraordinary circumstances an LSP might not have any
TLV. Add a null check to prevent a crash when that happens.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When ldp-sync is configured, IGPs take action if the LDP process goes down.
Currently, IGPs detect the LDP process is down if they do not receive a
periodic 'hello' message from LDP within 1 second.
Intermittently, this heartbeat mechanism causes false topotest failures.
When the failure occurs, LDP is busy receiving messages from zebra for a
few seconds. During this time, LDP does not send the expected periodic
message.
With this change, IGPs detect LDP down via zapi client close message.
Signed-off-by: Karen Schoener <karen@voltanet.io>
Instead of storing the LSP associated to pseudonodes only, store the
LSP associated to all SPF adjacencies instead.
The upcoming LFA work will need to have that piece of information
for all SPF adjacencies in order to know which ones have the overload
bit set or not. Other use cases might arise in the future.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Rename "debug isis ti-lfa" to "debug isis lfa". Having different
debug guards for different kinds of LFA (classic, remote and TI-LFA)
doesn't make sense since all LFA solutions share code to certain
extent.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Those constants are also useful in contexts other than LDP-IGP
Synchronization (e.g. the upcoming LFA work will need them). Move
them to a more general header to reflect that.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Do not attempt to install a TI-LFA backup nexthop if its number of
labels exceeds the locally configured MSD (Maximum Stack Depth). The
idea is to prevent forward-plane installation failures before they
happen. The MSD check should also allow the "show isis fast-reroute
summary" command (not implemented yet) to display the actual
protection coverage provided by TI-LFA, which might not be 100%
if the MSD isn't big enough.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Commit 4c75f7c773 fixed a bug in which the TI-LFA repair paths
weren't preserving the original Prefix-SID of the routes. That
commit, however, didn't update the zebra interface code to account
for backup nexthops that don't have a repair list but do have a
SR label. As a consequence, backup nexthops that didn't have any
repair label were not preserving the original Prefix-SID of the
corresponding routes. Fix this and update the TI-LFA topotest
accordingly.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
vertex->N is an union whose "id" and "ip" fields are only valid
depending on the vertex type (IS adjacency or IP reachability
information). As such, add a vertex type check before consulting
vertex->N.id in order to prevent unexpected behavior from happening.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The "ifp" variable returned by nb_running_get_entry() might be
NULL when using the transactional CLI mode. Make the required
modifications to avoid null pointer dereferences.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Once the remote end of a connected link is shut down (or lose
its address), isisd will remove the corresponding route from its
RIB after SPF runs. A new route for the same destination should
be computed based on the local LSP, and that route by definition
doesn't have any nexthop. The problem is that, when isisd tries
to replace the old route by the new one, it fails because routes
without nexthops can't be installed. That causes the old invalid
route to remain in the RIB when it shouldn't. To fix this problem,
change the zebra interface code to uninstall a route whenever it
can't be installed (because it lacks nexthops) instead of doing
nothing in that case.
This change should fix occasional failures of the test_isis_sr_topo1
topotest.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The `enum zclient_send_status` enum needs to be extended
throughout the code base to use the new states and
to fix up places where we tested against the return
value being non zero.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
On redistribution into isis we were creating a table for
handling the redistributed routes, but never cleaning them
up on shutdown properly. Do so.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When isis is being shutdown the area->spf_timer thread has
special data assigned to that was never being freed.
Free this data.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The route_map_object_t was being used to track what protocol we were
being called against. But each protocol was only ever calling itself.
So we had a variable that was only ever being passed in from route_map_apply
that had to be carried against and everyone was testing if that variable
was for their own stack.
Clean up this route_map_object_t from the entire system. We should
speed some stuff up. Yes I know not a bunch but this will add up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a second iteration of commit 10bdc68f0c. Some recent
commits introduced zlog calls in the northbound callbacks
inadvertently.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
isisd relies on its YANG module to prevent the same SID index
from being configured multiple times for different prefixes. It's
possible, however, to have different routers assigning the same SID
index for different prefixes. When that happens, we say we have a
Prefix-SID collision, which is ultimately a misconfiguration issue.
The problem with Prefix-SID collisions is that the Prefix-SID that
is processed later overwrites the previous ones. Then, once the
Prefix-SID collision is fixed in the configuration, the overwritten
Prefix-SID isn't reinstalled since it's already marked as installed
and it didn't change. To prevent such inconsistency from happening,
add a safeguard in the SPF code to detect Prefix-SID collisions and
handle them appropriately (i.e. log a warning + ignore the Prefix-SID
Sub-TLV since it's already in use by another prefix). That way,
once the configuration is fixed, no Prefix-SID label entry will be
missing in the LFIB.
Reported-by: Emanuele Di Pascale <emanuele@voltanet.io>
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
