5bb99ccad2 ("bgpd: reset ipv6 invalid link-local nexthop") now resets
the link-local when originating and destination peers are not on the
same network segment. However, it does not work all the time.
The fix compares the 'from' and 'peer' global IPv6 address. However,
'peer' refers to one of the peers of subgroup. The subgroup may contain
peers located on different network segment.
Split nexthop-local unchanged peer subgroup by network segment.
Fixes: 5bb99ccad2 ("bgpd: reset ipv6 invalid link-local nexthop")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Unset enforce-first-as on r3 of bgp_route_server_client to enable the
reception of routes on this router.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Rework bgp_route_server_client in a more standard form in order to
facilitate the next commut changes. Cosmetic change.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
They are managed under `frr-route-map`, not under `frr-bgp-route-map`.
Fixes: https://github.com/FRRouting/frr/issues/17055
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If e.g. BGP neighbor is using a route-map at the boot, that is not yet created,
then the log is spammed with `The route-map 'X' does not exist`.
Processing earlier, should do the trick.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This command did not allow the operator to display neighbor information
related to graceful-restart when used inside of a vrf.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If the "nexthop-local unchanged" setting is enabled, it preserves the
IPv6 link-local nexthop from the originating peer. However, if the
originating and destination peers are not on the same network segment,
the originating peer's IPv6 link-local address will be unreachable from
the destination peer.
In such cases, reset the IPv6 link-local nexthop, even if "nexthop-local
unchanged" is set on the destination peer.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Do not add an IPv6 link-local nexthop if the originating peer does not
provide one and the nexthop-local unchanged setting is enabled.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When LSP fragments age, isis_dynhn_remove() is also called to remove the corresponding dyhn_cache entries.
Signed-off-by: baozhen-H3C <bao.zhen@h3c.com>
The following ASAN issue has been observed:
> ERROR: AddressSanitizer: heap-use-after-free on address 0x6160000acba4 at pc 0x55910c5694d0 bp 0x7ffe3a8ac850 sp 0x7ffe3a8ac840
> READ of size 4 at 0x6160000acba4 thread T0
> #0 0x55910c5694cf in ctx_info_from_zns zebra/zebra_dplane.c:3315
> #1 0x55910c569696 in dplane_ctx_ns_init zebra/zebra_dplane.c:3331
> #2 0x55910c56bf61 in dplane_ctx_nexthop_init zebra/zebra_dplane.c:3680
> #3 0x55910c5711ca in dplane_nexthop_update_internal zebra/zebra_dplane.c:4490
> #4 0x55910c571c5c in dplane_nexthop_delete zebra/zebra_dplane.c:4717
> #5 0x55910c61e90e in zebra_nhg_uninstall_kernel zebra/zebra_nhg.c:3413
> #6 0x55910c615d8a in zebra_nhg_decrement_ref zebra/zebra_nhg.c:1919
> #7 0x55910c6404db in route_entry_update_nhe zebra/zebra_rib.c:454
> #8 0x55910c64c904 in rib_re_nhg_free zebra/zebra_rib.c:2822
> #9 0x55910c655be2 in rib_unlink zebra/zebra_rib.c:4212
> #10 0x55910c6430f9 in zebra_rtable_node_cleanup zebra/zebra_rib.c:968
> #11 0x7f26f275b8a9 in route_node_free lib/table.c:75
> #12 0x7f26f275bae4 in route_table_free lib/table.c:111
> #13 0x7f26f275b749 in route_table_finish lib/table.c:46
> #14 0x55910c65db17 in zebra_router_free_table zebra/zebra_router.c:191
> #15 0x55910c65dfb5 in zebra_router_terminate zebra/zebra_router.c:244
> #16 0x55910c4f40db in zebra_finalize zebra/main.c:249
> #17 0x7f26f2777108 in event_call lib/event.c:2011
> #18 0x7f26f264180e in frr_run lib/libfrr.c:1212
> #19 0x55910c4f49cb in main zebra/main.c:531
> #20 0x7f26f2029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
> #21 0x7f26f2029e3f in __libc_start_main_impl ../csu/libc-start.c:392
> #22 0x55910c4b0114 in _start (/usr/lib/frr/zebra+0x1ae114)
It happens with FRR using the kernel. During shutdown, the
namespace identifier is attempted to be obtained by zebra, in an
attempt to prepare zebra dataplane nexthop messages.
Fix this by accessing the ns structure.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Currently FRR is limiting the nexthop count to a uint8_t not a
uint16_t. This leads to issues when the nexthop count is 256
which results in the count to overflow to 0 causing problems
in the code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The minimum and maximum values for BFD timers and multiplier settings
have been updated to align with RFC 5880 requirements.
Since the values inputted via VTY are in milliseconds, the maximum
permissible value on the VTY interface is 4,294,967 milliseconds.
For the multiplier setting, the minimum value is now restricted to be
greater than zero, as zero is not allowed.
The minimum transmit interval has been set to 10 milliseconds to ensure
reliable service performance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Currently the zebra pw code has setup a retry to install the
pw after 30 seconds when it is decided that reachability to
the pw is gone. This causes a failure mode where the
pw code just goes and re-installs the pw after 30 seconds
in the non-reachability case. Instead it should just be
reinstalling after reachability is restored.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the pw code sets the status of the pw for install
and uninstall immediately when notifying the dplane. This
is incorrect in that we do not actually know the status at
this point in time. When we get the result is when to set
the status.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
