python3 does not support execfile implementation.
replace it with open and exec api that are available in both python 2
and 3 implementations.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When allocating memory for the `struct ospf_metric` we
were using `uint32_t` instead of the actual size of this
structure. When we wrote to it we would be writing
into other people's memory.
Found-by: Amol Lad
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We are using data after it has been freed and handed back to the
OS.
Address Sanitizer output:
error 23-Nov-2020 18:53:57 ERROR: AddressSanitizer: heap-use-after-free on address 0x631000024838 at pc 0x55f825998f58 bp 0x7fffa5b0f5b0 sp 0x7fffa5b0f5a0
error 23-Nov-2020 18:53:57 READ of size 4 at 0x631000024838 thread T0
error 23-Nov-2020 18:53:57 #0 0x55f825998f57 in lde_imsg_compose_parent_sync ldpd/lde.c:226
error 23-Nov-2020 18:53:57 #1 0x55f8259ca9ed in vlog ldpd/log.c:48
error 23-Nov-2020 18:53:57 #2 0x55f8259cb1c8 in log_info ldpd/log.c:102
error 23-Nov-2020 18:53:57 #3 0x55f82599e841 in lde_shutdown ldpd/lde.c:208
error 23-Nov-2020 18:53:57 #4 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error 23-Nov-2020 18:53:57 #5 0x55f825ac3815 in thread_call lib/thread.c:1681
error 23-Nov-2020 18:53:57 #6 0x55f825998d5e in lde ldpd/lde.c:160
error 23-Nov-2020 18:53:57 #7 0x55f82598a289 in main ldpd/ldpd.c:320
error 23-Nov-2020 18:53:57 #8 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error 23-Nov-2020 18:53:57 #9 0x55f825982579 in _start (/usr/lib/frr/ldpd+0xb3579)
error 23-Nov-2020 18:53:57
error 23-Nov-2020 18:53:57 0x631000024838 is located 65592 bytes inside of 65632-byte region [0x631000014800,0x631000024860)
error 23-Nov-2020 18:53:57 freed by thread T0 here:
error 23-Nov-2020 18:53:57 #0 0x7fe3f8a4d7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8)
error 23-Nov-2020 18:53:57 #1 0x55f82599e830 in lde_shutdown ldpd/lde.c:206
error 23-Nov-2020 18:53:57 #2 0x55f8259a2703 in lde_dispatch_parent ldpd/lde.c:666
error 23-Nov-2020 18:53:57 #3 0x55f825ac3815 in thread_call lib/thread.c:1681
error 23-Nov-2020 18:53:57 #4 0x55f825998d5e in lde ldpd/lde.c:160
error 23-Nov-2020 18:53:57 #5 0x55f82598a289 in main ldpd/ldpd.c:320
error 23-Nov-2020 18:53:57 #6 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error 23-Nov-2020 18:53:57
error 23-Nov-2020 18:53:57 previously allocated by thread T0 here:
error 23-Nov-2020 18:53:57 #0 0x7fe3f8a4dd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
error 23-Nov-2020 18:53:57 #1 0x55f825998cb7 in lde ldpd/lde.c:151
error 23-Nov-2020 18:53:57 #2 0x55f82598a289 in main ldpd/ldpd.c:320
error 23-Nov-2020 18:53:57 #3 0x7fe3f749db96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
error 23-Nov-2020 18:53:57
The fix is to put this in global space.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This new topotest comprises of 13 testing steps and tests essentially
all implemented LFA knobs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
These unit tests check the basic LFA loop-free condition on a
variety of different network topologies. None of the implemented
LFA tie-breakers are tested here.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
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>
Two L3 next groups are installed per-VRF per-ES for v4 and v6. These
NHGs are used as an indirect destination for symmetric IRB host routes.
Using L3NHGs allows for efficient failover of an ES (similar to the
use of L2NHGs) i.e. when an ES goes down the number of dataplane
updates are limited to 2xN (where N is the number of tenant VRFs
associated with the ES) instead of updating all host-routes behind the
ES.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Dataplane/kernel prints the NHG and NH ids as decimal. Zebra
was printing it as hex (to display type vs. val). This became a
debugging hassle hence normalizing the format.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Host routes imported into the VRF can have a destination ES (per-VRF)
which is set up as a L3NHG for efficient failover.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
1. MAC-IP routes in the VPN routing table are linked to the
destination ES for efficient handling for remote ES link flaps.
2. Only MAC-IP paths whose nexthops are active (added via EAD-ES)
are imported into the VRF routing table.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
ES-VRF entries are maintained for the purpose of L3-NHG creation -
1. Each ES-EVI entry is associated with a tenant VRF. This associaton
triggers the creation of an ES-VRF entry.
2. Type-2/MAC-IP routes are imported into a tenant VRF and programmed as
a /32 or host route entry in the dataplane. If the destination of
the host route is a remote-ES the route is programmed with the
corresponding (keyed in by {vrf,ES-id}) L3-NHG.
3. The reason for this indirection (route->L3-NHG, L3-NHG->list-of-VTEPs)
is to avoid route updates to the dplane when a remote-ES link flaps i.e.
instead of updating all the dependent routes the NHG's contents are
updated. This reduces the amount of dataplane updates (fewer nhg updates vs.
route updates) allowing for a faster failover.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Local attached hosts are routed via the access ports using the neigh and
fdb/MAC dplane entries.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
DAD is not supported currently with EVPN-MH so we turn it off internally
when the first ES config is detected.
PS: Note that when all local ESs are deleted DAD will stay off and
will need to be cleared via a daemon restart.
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Don't reset interface/vrf pointer everytime a session is disabled
instead only do it when it was explicitly removed.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Show BFD sessions updated counters by asking the data plane for this
information and show data plane statistics.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Add hooks in the correct places so the BFD daemon uses the data plane
instead of the software packet sending implementation to monitor the
session.
This code also adds some handlers to support fallback to FRR BFD session
handling, however since this complicates the code it won't work at the
moment (the BFD sockets are disabled by default when using data plane).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The current distributed BFD implementantion doesn't support falling back
to software implementation in FRR, so to keep the code simple lets give
the data plane full control of the BFD packet handling (helps running a
software data plane for testing too otherwise it would fail with 'address
in use' error).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Distributed BFD is a term used for BFD implementations that do not run
on the routing engine, instead it is run on a data plane (software or
hardware based).
The current code implements the basic communication between FRR BFD
daemon with an external BFD data plane and defines the protocol format
in the file `bfddp_packet.h`.
To enable/use data plane you need to start BFD daemon with the command
line `--dplaneaddr <type>:<address>`, then a socket will be opened to
listen for incoming data plane connections.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The BFD data plane header has definitions for the data plane
communication protocol that will be used to implement the distributed
BFD feature.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The function was originally implemented for zebra data plane FPM plugin,
but another code places could use it.
Signed-off-by: Rafael Zalamena <rzalamena@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>
