Christian Hopps [Sun, 24 Nov 2024 08:06:05 +0000 (03:06 -0500)]
tests: enable failure and fix broken tests
This test was not actually failing when the results didn't match. Fail
now. Also fix the tests that are now found to be failing incorrectly
(wrong expected result).
anlan_cs [Sat, 21 Dec 2024 11:29:32 +0000 (19:29 +0800)]
mgmtd: fix compile error
Compile error with `--disable-ripd`:
```
mgmtd/mgmt_be_adapter.c:86:5: error: "HAVE_RIPD" is not defined, evaluates to 0 [-Werror=undef]
86 | #if HAVE_RIPD
| ^~~~~~~~~
```
I have searched the code, there is only three places need to be fixed.
Donatas Abraitis [Thu, 19 Dec 2024 14:59:47 +0000 (16:59 +0200)]
bgpd: Show applied route-map attributes for `neighbor X advertised-routes detail`
If we have a route-map that sets some attributes e.g. community or large-community,
and the route-map is applied for outgoing direction, everything is fine, but
we missed the point that `advertised-routes detail` was not using the applied
attributes to display and instead it uses what is received from the peer (original).
Let's fix this, and use what's already applied (advertise attributes), and
we can now see:
```
route-map r3 permit 10
match ip address prefix-list p1
set community 65001:65002
set extcommunity bandwidth 100
set large-community 65001:65002:65003
exit
!
...
address-family ipv4 unicast
neighbor 192.168.2.3 route-map r3 out
exit-address-family
...
```
The output:
```
r2# show bgp ipv4 neighbors 192.168.2.3 advertised-routes detail
BGP table version is 1, local router ID is 192.168.2.2, vrf id 0
Default local pref 100, local AS 65002
BGP routing table entry for 10.10.10.1/32, version 1
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.1.1 192.168.2.3
65001
0.0.0.0 from 192.168.1.1 (192.168.1.1)
Origin IGP, valid, external, best (First path received)
Community: 65001:65002
Extended Community: LB:65002:12500000 (100.000 Mbps)
Large Community: 65001:65002:65003
Last update: Thu Dec 19 17:00:40 2024
```
Rajasekar Raja [Wed, 4 Oct 2023 16:20:35 +0000 (09:20 -0700)]
lib: Fix to optimize the time taken while batching huge configs
Issue: When the incoming config has say 30K entries of a prefix-lists,
current implementation is to schedule the configs to be batched and
only after batching the entire config, the processing of the configs
take place. As part of batching this config, we perform string
concatenation to save all the configs in the buffer which over time
results in taking longer time.
Ex: Imagine each line of config is 50 chars. With a delimiter of ‘- ‘ we end
up adding 52 chars to buffer for each command i.e. 52*30000 = 156K of chars.
Strlcat is an expensive operation and every time we strlcat, we have to
traverse at end of string to append new char.
Because of this, we end up adding extra 6-8 secs for accepting the config.
Fix: The idea here is to bring back something similar to the backoff
count implemented as part of 20e9a402 (lib: introduce configuration
back-off timer for YANG-modeled commands).
Essentially we keep a cap of 5000 per batch. So once 5000k config
commands are batched, we process them, clear the buffer, set the count
to 0 and then continue processing the rest of the config.
option1 file has 30K entries of prefix-list
Without Fix:
root@mlx-3700-20:mgmt:/var/log/raja/frr# time sudo vtysh -f option1
<SNIP>..............
Waiting for children to finish applying config...
[25191|staticd] done
[25189|watchfrr] done
[25178|ospfd] done
[25190|pbrd] done
[25181|bgpd] done
[25175|zebra] done
real 0m20.123s
user 0m9.384s
sys 0m2.403s
With Fix:
root@mlx-3700-20:mgmt:/var/log/raja/frr# time sudo vtysh -f option1
<SNIP>..............
Waiting for children to finish applying config...
[19887|staticd] done
[19885|watchfrr] done
[19886|pbrd] done
[19874|ospfd] done
[19877|bgpd] done
[19871|zebra] done
Philippe Guibert [Wed, 18 Dec 2024 15:53:48 +0000 (16:53 +0100)]
bgpd: fix memory leak when reconfiguring a route distinguisher
A memory leak happens when reconfiguring an already configured route
distinguisher on an L3VPN BGP instance. Fix this by freeing the previous
route distinguisher.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This commit introduces meta queue to the BGP process_queue which is
helpful in having a priority of lists where some routes can be processed
earlier than 'other' routes. This is similar to how meta queue is
present in zebra.
After Fix:
---------
For testing, note that all 100.x routes are marked as Early routes which
got enqueued and dequeued first before Other routes in every batch of
updates. Also, the items are dequeued in FIFO order.
switch# cat /var/log/frr/bgpd.log | grep sub-queue
2024/12/06 19:19:42.788014 BGP: [V64FH-G6883] 88.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:42.856127 BGP: [V64FH-G6883] 100.90.9.186/32 queued into sub-queue Early Route
2024/12/06 19:19:42.856138 BGP: [V64FH-G6883] 100.90.9.187/32 queued into sub-queue Early Route
2024/12/06 19:19:42.886715 BGP: [V64FH-G6883] 66.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.022835 BGP: [V64FH-G6883] 33.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.058842 BGP: [V64FH-G6883] 44.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.092365 BGP: [V64FH-G6883] 55.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.540770 BGP: [ZAPXS-9754G] 100.90.9.186/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.541233 BGP: [ZAPXS-9754G] 100.90.9.187/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.541523 BGP: [ZAPXS-9754G] 88.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:43.602094 BGP: [V64FH-G6883] 88.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.649083 BGP: [V64FH-G6883] 100.90.9.186/32 queued into sub-queue Early Route
2024/12/06 19:19:43.649092 BGP: [V64FH-G6883] 100.90.9.187/32 queued into sub-queue Early Route
2024/12/06 19:19:43.649148 BGP: [V64FH-G6883] 77.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.712282 BGP: [V64FH-G6883] 100.90.9.138/32 queued into sub-queue Early Route
2024/12/06 19:19:43.712314 BGP: [V64FH-G6883] 100.90.9.139/32 queued into sub-queue Early Route
2024/12/06 19:19:43.817194 BGP: [V64FH-G6883] 100.90.8.58/32 queued into sub-queue Early Route
2024/12/06 19:19:43.817205 BGP: [V64FH-G6883] 100.90.8.59/32 queued into sub-queue Early Route
2024/12/06 19:19:43.942464 BGP: [ZAPXS-9754G] 100.90.9.186/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942530 BGP: [ZAPXS-9754G] 100.90.9.187/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942550 BGP: [ZAPXS-9754G] 100.90.9.138/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942738 BGP: [ZAPXS-9754G] 100.90.9.139/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942763 BGP: [ZAPXS-9754G] 100.90.8.58/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942788 BGP: [ZAPXS-9754G] 100.90.8.59/32 dequeued from sub-queue Early Route
2024/12/06 19:19:44.558611 BGP: [ZAPXS-9754G] 66.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:44.893541 BGP: [ZAPXS-9754G] 33.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.171794 BGP: [ZAPXS-9754G] 44.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.453137 BGP: [ZAPXS-9754G] 55.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.685269 BGP: [ZAPXS-9754G] 88.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.764752 BGP: [ZAPXS-9754G] 77.0.0.9/32 dequeued from sub-queue Other Route
With 'update-delay' feature (EOIU marker):
------------------------------------------
anlan_cs [Sat, 30 Nov 2024 13:11:04 +0000 (21:11 +0800)]
zebra: fix wrong nexthop check
The kernel routes are wrongly selected even the nexthop interface is linkdown.
Use `ip link set dev <interface> down` on the other box to set the box's
nexthop interface linkdown. The kernel routes will be kept as `linkdown`,
but are still with active nexthop in `zebra`.
Add three changes/commits for kernel routes in this PR:
1) The active nexthop should be the operative interface.
2) Don't uninstall the kernel routes from `zebra` even no active nexthops.
(It doesn't affect the kernel routes' deletion from kernel netlink messages.)
3) Update the kernel routes when the nexthop interface becomes up.
Before: (during nexthop interface is linkdown)
```
K>* 3.3.3.3/32 [0/0] via 88.88.88.1, enp2s0, weight 1, 00:00:14
```
After: (during nexthop interface is linkdown, with all three changes)
```
K 3.3.3.3/32 [0/0] via 88.88.88.1, enp2s0 inactive, weight 1, 00:00:07
```
This commit is 1st change:
Improve the judgment for "active" nexthop to be more accurate, the active
nexthop should be the operative interface.
varuntumbe [Thu, 12 Dec 2024 12:27:02 +0000 (17:57 +0530)]
bgpd: Releasing the label in bgp_delete flow
Releasing the vpn label from label pool chunk using bgp_lp_release routine whenever vpn session is removed.
bgp_lp_release will clear corresponding bit in the allocated map of the label pool chunk and increases nfree by 1
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Christian Hopps [Mon, 16 Dec 2024 02:37:41 +0000 (21:37 -0500)]
lib: darr: fix bug with nested macro use
- WHen declaring macro scoped variables, can run into problem if the macro
variable passed in has the same name as the new variable introduced in the inner
scope. We don't get a warning and the uses will be wrong.
e.g.,
```
{
int __len = 10;
foo(__len); // => 10 and not 15 as we wanted.
}
```
Christian Hopps [Mon, 16 Dec 2024 03:00:01 +0000 (22:00 -0500)]
lib: mgmtd: use less common macro scoped variable names
- ran into problem with darr macros and nested macros using the same name
variables as passed in variables in an out scope. Make these macro scoped
variables more unique as well.
Nathan Bahr [Wed, 23 Oct 2024 19:00:57 +0000 (19:00 +0000)]
pimd: Clean up pim RPF/NHT show commands
Moved `show ip rpf A.B.C.D` command here from zebra, deprecated and aliased
to `show ip pim nexthop-lookup`.
Allow group to be optional in the lookup command. Only validate group if
source is ANY. Documented setting source via RP if not provided.
Added new output if ANY source + group lookup is performed and no
RP is found for the group. Updated output to include souce and
group for lookup.
Nathan Bahr [Wed, 23 Oct 2024 19:00:31 +0000 (19:00 +0000)]
pimd: Refactor pim NHT
Refactor the next hop tracking in PIM to fully support the configured RPF lookup mode.
Moved many NHT related functions to pim_nht.h/c
NHT now tracks both MRIB and URIB tables and makes nexthop decisions based on the configured lookup mode.
Nathan Bahr [Wed, 23 Oct 2024 18:48:57 +0000 (18:48 +0000)]
pimd: Refactor synchronous nexthop lookup
Add prefix length in nexthop response.
Apply lookup mode to the sychronous lookups, where we may lookup
the MRIB, URIB, or both and make a decision based on the nexthop.
Donald Sharp [Fri, 13 Dec 2024 16:21:26 +0000 (11:21 -0500)]
zebra: Give a bit more data about zclient connection on errors
When debugging a crash I noticed that sometimes we talked about
a zclient connection in relation to the fd associated with it
and sometimes we did not. Let's just always give the data
associated with the fd. It will make it a bit easier for me
to follow the transitions.
Donald Sharp [Thu, 12 Dec 2024 20:08:35 +0000 (15:08 -0500)]
bgpd: When calling bgp_process, prevent infinite loop
If we have this construct:
for (pi = bgp_dest_get_bgp_path_info(dest); pi; pi = pi->next) {
...
bgp_process();
}
This can induce an infinite loop. This happens because bgp_process
will move the unsorted items to the top of the list for handling,
as such it is necessary to hold the next pointer to the side
to actually look at each possible bgp_path_info.
Remove use of `ip multicast rpf-lookup-mode` from unrelated tests.
Looks like this test was just unlucky enough to pick that command as an
example for use here. Just changed it to something less likely to be
removed in the future.
Update route table output to include AFI SAFI output.
Nathan Bahr [Tue, 29 Oct 2024 19:30:00 +0000 (19:30 +0000)]
zebra: Improve multicast safi route show commands
Add `mrib` flag to existing "show ip route" commands which then use
the multicast safi rather than the unicast safi. Updated the vty output
to include the AFI and SAFI string when printing the table.
Deprecate `show ip rpf` command, aliased to `show ip route mrib`.
Removed `show ip rpf A.B.C.D`.
zebra,yang: Completely remove multicast mode from zebra
Multicast mode belongs in PIM, so removing it completely from zebra.
Modified `show (ip|ipv6) rpf ADDRESS` to always lookup from SAFI_MULTICAST.
This means this command is now specific to the multicast table and does
not necessarily reflect the PIM RPF lookup, but that should be implemented
in PIM instead.
Modified ZEBRA_NEXTHOP_LOOKUP_MRIB to include the SAFI from which to do the lookup.
This generalizes the API away from MRIB specifically and allows the user to decide how it should do lookups.
Rename ZEBRA_NEXTHOP_LOOKUP_MRIB to ZEBRA_NEXTHOP_LOOKUP now that it is more generalized.
This change is in preperation to remove multicast lookup mode completely from zebra.
projects / mirror / frr.git / log