Donatas Abraitis [Sun, 17 Nov 2024 09:16:05 +0000 (11:16 +0200)]
bgpd: Validate both nexthop information (NEXTHOP and NLRI)
If we receive an IPv6 prefix e.g.: 2001:db8:100::/64 with nextop: 0.0.0.0, and
mp_nexthop: fc00::2, we should not treat this with an invalid nexthop because
of 0.0.0.0. We MUST check for MP_REACH attribute also and decide later if we
have at least one a valid nexthop.
Rajasekar Raja [Thu, 14 Nov 2024 07:09:55 +0000 (23:09 -0800)]
bgpd : backpressure - Fix to pop items off zebra_announce FIFO for few EVPN triggers
In cases such as 'no advertise-all-vni' and L2 VNI DELETE, we need to
pop all the VPN routes present in the bgp_zebra_announce FIFO yet to
be processed regardless of VNI is configured or not.
NOTE: NO need to pop the VPN routes in two cases
1) In free_vni_entry
- Called by bgp_free()->bgp_evpn_cleanup().
- Since bgp_delete is called before bgp_free and we pop all the dest
pertaining to bgp under delete.
2) evpn_delete_vni() when user configures "no vni" since the withdraw
of all routes happen in normal cycle.
Krishnasamy R [Mon, 11 Nov 2024 09:59:31 +0000 (01:59 -0800)]
bgpd: fix resolvedPrefix in show nexthop json output
While populating the nexthop info for "show bgp nexthop json", resolvedPrefix
is added in parent json object instead of json_nexthop object.
This results in displaying wrong resolvedPrefix for nexthops.
Fixing the same by adding resolvedPrefix to json_nexthop object, so that
the proper resolvedPrefix would be displayed for the respective nexthop
Rajasekar Raja [Mon, 21 Oct 2024 17:53:27 +0000 (10:53 -0700)]
bgpd: Fix for match source-protocol in route-map for redistribute cmd
A redistribute cmd can have a route-map attached to it and adding the
match source-protocol to that route-map means BGP to filter which
protocol routes to accept among the bunch of routes zebra is sending.
Signed-off-by: Donald Sharp <sharpd@nvidia.com> Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
(cherry picked from commit 68358c0f928eafe50c9e73b0cb6a443c03f2a33f)
bgpd: Set LLGR stale routes for all the paths including addpath
Without this patch we set only the first path for the route (if multiple exist)
as LLGR stale and stop doing that for the rest of the paths, which is wrong.
anlan_cs [Thu, 31 Oct 2024 14:44:05 +0000 (22:44 +0800)]
zebra: fix missing kernel routes
The `rib_update_handle_kernel_route_down_possibility()` didn't consider
the kernel routes ( blackhole ) without interface. When some other
interfaces are down, these kernel routes will be wrongly removed.
Joshua Muthii [Tue, 29 Oct 2024 16:08:14 +0000 (12:08 -0400)]
nhrpd: Modify NHRP authentication feature logging
Modified nhrp_connection_authorized(). Initially, when writing debug
information about incoming NHRP packets with authentication enabled,
the nhrp_connection_authorized() function would print the
passphrase of the incoming packet as if it were a null terminated
string. This meant that if the passphrase on the incoming packet
had non ASCII-complient bytes in it, it would attempt to print those
bytes anyway. There was also no check that the size of the passphrase in
the incoming packet matched the size of the passphrase on the interface.
The changes in this commit log the passphrase on the incoming packet as
well as the passphrase on interface in HEX to avoid issues with ASCII.
It also performs a check that accounts for the sizes of the two different
passphrases
Moved CISCO_PASS_LENGTH_LEN from nhrp_vty.c to nhrp_protocol.h
for easier access to the macro in other files
Joshua Muthii [Tue, 29 Oct 2024 16:05:59 +0000 (12:05 -0400)]
nhrpd: Add topotest for retrying resolution request
Modified nhrp_topo topotest to test for newly added resolution
request retry feature. Changes to the topotest include adding a spoke to the
existing nhrp_topo topotest so that a topology with two spokes and hub
can be used to create shortcuts and test the sending/resending of
resolution requests and responses between spoke and hub. The resolution
request retry feature was tested by blocking incoming resolution requests on a
receiving nodes to stop the creation of a successful shortcut - which
then triggered the sending spoke to retry sending resolution requests
Donatas Abraitis [Thu, 31 Oct 2024 08:47:48 +0000 (10:47 +0200)]
zebra: Add missing new line for help string
```
-A, --asic-offload FRR is interacting with an asic underneath the linux kernel
--v6-with-v4-nexthops Underlying dataplane supports v6 routes with v4 nexthops -s, --nl-bufsize Set netlink receive buffer size
```
Fixes: 1f5611c06d1c243b42279748788f0627793ead9c ("zebra: Allow zebra cli to accept v6 routes with v4 nexthops") Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 25ae643996d338b8230fb15a9064843fe85de224)
Donatas Abraitis [Wed, 30 Oct 2024 12:15:36 +0000 (14:15 +0200)]
doc: Create html_context before setting READTHEDOCS
Traceback (most recent call last):
File "/home/docs/checkouts/readthedocs.org/user_builds/frrouting/envs/latest/lib/python3.11/site-packages/sphinx/config.py", line 529, in eval_config_file
exec(code, namespace) # NoQA: S102
^^^^^^^^^^^^^^^^^^^^^
File "/home/docs/checkouts/readthedocs.org/user_builds/frrouting/checkouts/latest/doc/user/conf.py", line 77, in <module>
html_context["READTHEDOCS"] = True
^^^^^^^^^^^^
NameError: name 'html_context' is not defined
Donald Sharp [Sat, 26 Oct 2024 01:56:14 +0000 (21:56 -0400)]
zebra: When installing a mroute, allow it to flow
Currently the mroute code was not allowing the mroute
to be sent to the dataplane. This leaves us with a
situation where the routes being installed where never
being set as installed and additionally nht against
the mrib would not work if the route came into existence
after the nexthop tracking was asked for.
Turns out all the pieces where there to let this work.
Modify the code to pass it to the dplane and to send
it back up as having worked.
Louis Scalbert [Fri, 25 Oct 2024 15:54:07 +0000 (17:54 +0200)]
bgpd: fix display of local label in show bgp
Fix the display of the local label in show bgp.
> r1# show bgp ipv4 labeled-unicast 172.16.2.2/32
> BGP routing table entry for 172.16.2.2/32, version 2
> Local label: 16 <---- MISSING
> Paths: (1 available, best #1, table default, vrf (null))
> Advertised to non peer-group peers:
> 192.168.1.2
> 65501
> 192.168.1.2 from 192.168.1.2 (172.16.2.2)
> Origin IGP, metric 0, valid, external, best (First path received)
> Remote label: 3
> Last update: Fri Oct 25 17:55:45 2024
Fixes: 67f67ba481 ("bgpd: Drop label_ntop/label_pton functions") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit e7b3276ace65d59edb4d614158d4f2959f12f868)
pimd: allow resolving bsr via directly connected secondary address
This only matters to single hop nodes that are adjacent to the bsr. More common
with IPv6 where LL address is used in PIM as the primary address. If the BSR IP
happens to be an address on the same interface, the receiving pim router
rejects the BSR address because it expects the BSR IP to resolve via the LL address
even if we have a connected route for the same BSR IP subnet. Effectively, we want to
allow rpf to be resolved via secondary IPs with connected routes on the same interface,
and not limit them to primary addresses.
Louis Scalbert [Tue, 22 Oct 2024 16:08:13 +0000 (18:08 +0200)]
bgpd: fix uninitialized labels
Fix uninitialized labels that cause multiple valgrind issues.
> ==3729602== Use of uninitialised value of size 8
> ==3729602== at 0x492B493: hash_get (hash.c:140)
> ==3729602== by 0x2629D2: bgp_labels_intern (bgp_label.c:98)
> ==3729602== by 0x2E6C92: bgp_adj_out_set_subgroup (bgp_updgrp_adv.c:622)
> ==3729602== by 0x2A6810: subgroup_process_announce_selected (bgp_route.c:3340)
> ==3729602== by 0x2E5FF6: group_announce_route_walkcb (bgp_updgrp_adv.c:260)
> ==3729602== by 0x2E3E28: update_group_walkcb (bgp_updgrp.c:1759)
> ==3729602== by 0x492B9A0: hash_walk (hash.c:270)
> ==3729602== by 0x2E498C: update_group_af_walk (bgp_updgrp.c:2090)
> ==3729602== by 0x2E7C0D: group_announce_route (bgp_updgrp_adv.c:1119)
> ==3729602== by 0x2A796E: bgp_process_main_one (bgp_route.c:3865)
> ==3729602== by 0x2A808A: bgp_process_wq (bgp_route.c:3991)
> ==3729602== by 0x49CC7CF: work_queue_run (workqueue.c:282)
> ==3729602== by 0x49BBF25: event_call (event.c:2019)
> ==3729602== by 0x49413CA: frr_run (libfrr.c:1238)
> ==3729602== by 0x1FD1D3: main (bgp_main.c:555)
> ==2604268== Use of uninitialised value of size 8
> ==2604268== at 0x4943016: hash_get (hash.c:159)
> ==2604268== by 0x26EFC1: bgp_labels_intern (bgp_label.c:97)
> ==2604268== by 0x28077B: leak_update (bgp_mplsvpn.c:1298)
> ==2604268== by 0x2824A3: vpn_leak_from_vrf_update (bgp_mplsvpn.c:1932)
> ==2604268== by 0x2C281C: bgp_static_update (bgp_route.c:6974)
> ==2604268== by 0x2C366F: bgp_static_set (bgp_route.c:7263)
> ==2604268== by 0x2C435B: bgp_network_magic (bgp_route.c:7556)
> ==2604268== by 0x2ACF09: bgp_network (bgp_route_clippy.c:86)
> ==2604268== by 0x4914EE7: cmd_execute_command_real (command.c:1003)
> ==2604268== by 0x4915060: cmd_execute_command (command.c:1062)
> ==2604268== by 0x4915610: cmd_execute (command.c:1228)
> ==2604268== by 0x49E7C32: vty_command (vty.c:625)
> ==2604268== by 0x49E9B56: vty_execute (vty.c:1388)
> ==2604268== by 0x49EC331: vtysh_read (vty.c:2400)
> ==2604268== by 0x49E06F1: event_call (event.c:2001)
> ==2604268== by 0x495AB8B: frr_run (libfrr.c:1238)
> ==2604268== by 0x200C4B: main (bgp_main.c:555)
Fixes: ddb5b4880b ("bgpd: vpn-vrf route leaking") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit 3225b778cafa46be8233f3512737d85872db67dd)
Enke Chen [Tue, 22 Oct 2024 01:03:08 +0000 (18:03 -0700)]
bgpd: fix AIGP calculation in route advertisement
Currently the AIGP is always incremented when a route with the
attribute is advertised. That is incorrect when the nexthop is
unchanged, as is commonly the case in route reflection.
Adjust the AIGP for propagation only when the nexthop is set
to ourselves.
Enke Chen [Tue, 22 Oct 2024 00:49:19 +0000 (17:49 -0700)]
tests: add a topotest bgp_aigp_rr
In this topotest, the route reflector advertises a route with the
aigp attribute to its client, some with the nexthop unchanged and
some with the nexthp changed. Different aigp values are sent to
the clients depending on the nexthop setting.
Enke Chen [Sun, 20 Oct 2024 19:25:46 +0000 (12:25 -0700)]
bgpd: allow value 0 in aigp-metric setting
The value of 0 is accepted from peers, and can also be set by the
route-map "set aigp-metric igp-metric". For coonsistency, it should
be allowed in "set aigp-metric <value>" as well.
Enke Chen [Wed, 16 Oct 2024 18:15:28 +0000 (11:15 -0700)]
bgpd: fix several issues in sourcing AIGP attribute
Fix several issues in sourcing AIGP attribute:
1) AIGP should not be set as default for a redistributed route or a
static network. It should be set by config instead.
2) AIGP sourced by "set aigp-metric igp-metric" in a route-map does
not set the correct value for a redistributed route.
3) When redistribute a connected route like loopback, the AGIP (with
value 0) is sourced by "set aigp-metric igp-metric", but the
attribute is not propagated as the attribute flag is not set.
> 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.
Donald Sharp [Mon, 14 Oct 2024 15:25:32 +0000 (11:25 -0400)]
zebra: Prevent a kernel route from being there when a connected should
There exists a series of events where a kernel route is learned
first( that happens to be exactly what a connected route should be )
and FRR ends up with both a kernel route and a connected route,
leaving us in a very strange spot. This code change just mirrors
the existing code of if there is a connected route drop the kernel
route. Here we just do the reverse, if we have a kernel route
already and a connected should be created, remove the kernel and
keep the connected.
Enke Chen [Tue, 15 Oct 2024 01:47:59 +0000 (18:47 -0700)]
tests: fix and adjust topotest/bgp_aigp
Fix and adjust the topotest post the fix for route selection with
AIGP.
When there are multiple IGP domains (OSPF in this case), the nexthop
for a BGP route with the AIGP attribute must be resolved in its own
IGP domain.
The changes in r2/bgpd.conf and r3/bgpd.conf are needed as incorrect
IGP metrics are received from NHT for the recursive nexthops. Once
the issue is resolved, the changes can be reverted.
When local ESI is flapped
torm-11:# ip neigh show 45.0.0.51
45.0.0.51 dev vlan1000 lladdr aa:aa:aa:00:00:01 REACHABLE proto zebra
Before fix:
(The imported route remained in tenant-vrf)
torm-11:# ip route show vrf vrf1 45.0.0.51
45.0.0.51 nhid 257 proto bgp metric 20
After fix:
torm-11# ip route show vrf vrf1 45.0.0.51
torm-11#
trace:
2024/10/11 18:19:29 BGP: [JMP3T-178G8] route [2]:[0]:[48]:[00:02:00:00:00:08]:[32]:[21.1.0.5]
is matched on local esi 03:00:00:00:77:01:04:00:00:0e, uninstall from VRF tenant1 route table
Louis Scalbert [Wed, 9 Oct 2024 15:08:44 +0000 (17:08 +0200)]
bgpd: reset ipv6 invalid link-local nexthop
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.
projects / mirror / frr.git / log