Add routines to walk the LSP table and generate FPM updates for all
entries. A walk of the LSP table is triggered when (re-)connecting
to an FPM.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
Commit: 1d376ff539 removed
the code to find nexthops for the POINTOMULTIPOINT and
replaced it with a generic bit of code that was
supposed to handle both POINTOPOINT and POINTOMULTIPOINT
the problem is that the ospf rfc states that the
network mask on point to multipoint should be /32
which will not allow you to properly do a prefix match
on it against the network.
Restore original behavior as much as possible and leave
the new POINTOPOINT code alone.
Fixes: #7624
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Export netlink_lsp_msg_encoder() and use it to encode and send netlink
messages concerning LSP updates to connected FPMs.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
This is the opposite of TOPOTEST_AUTOLOAD: Instead of automatically loading
missing modules, TOPOTEST_NOLOAD prevents module loading and supresses
questions about it.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
in the rare situation where we allocate the ES during the path link
we fail to check/store the allocated ES pointer thus leading to a
NULL dereference later in the function.
Signed-off-by: Pat Ruddy <pat@voltanet.io>
the topolog importation folder must be precised. otherwise following
error message appears:
root@dut-vm:~/topotests/bgp_flowspec# python3 test_bgp_flowspec_topo.py
Traceback (most recent call last):
File "test_bgp_flowspec_topo.py", line 96, in <module>
from lib.lutil import lUtil
File "/root/topotests/bgp_flowspec/../lib/lutil.py", line 25, in <module>
from topolog import logger
ImportError: No module named 'topolog'
root@dut-vm:~/topotests/bgp_flowspec#
The same error occurs with lutil and bgprib which are 2 libraries
located under lib/ folder. Some precisions are added too.
PR=71290
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
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>
The tests work with the default settings of BFD meaning that bfdd
is able to recognize a 'down' link after ~900ms so a route
recovery should be visible in the RIB after 1 second.
The following topology is used:
+---------+
| |
eth-rt2 (.1) | RT1 | eth-rt3 (.1)
+----------+ 1.1.1.1 +----------+
| | | |
| +---------+ |
| |
| 10.0.2.0/24 |
| |
| eth-rt1 | (.2)
| 10.0.1.0/24 +----+----+
| | |
| | RT3 |
| | 3.3.3.3 |
| | |
(.2) | eth-rt1 +----+----+
+----+----+ eth-rt4 | (.1)
| | |
| RT2 | |
| 2.2.2.2 | 10.0.4.0/24 |
| | |
+----+----+ |
(.1) | eth-rt5 eth-rt3 | (.2)
| +----+----+
| | |
| | RT4 |
| | 4.4.4.4 |
| | |
| +----+----+
| 10.0.3.0/24 eth-rt5 | (.1)
| |
| |
| 10.0.5.0/24 |
| |
| +---------+ |
| | | |
+----------+ RT5 +----------+
eth-rt2 (.2) | 5.5.5.5 | eth-rt4 (.2)
| |
+---------+
Route recovery is tested on RT1. The focus here lies on the two
different routes to RT5. Link failures are generated by taking
down interfaces via the mininet Python interface on RT2 and RT3.
Hence routes are supposed to be adjusted to use RT3 when a link
failure happens on RT2 or vice versa.
Note that only failure recognition and recovery is "fast". BFD
does not monitor a link becoming available again.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
