summaryrefslogtreecommitdiffstats
path: root/lib/id_alloc.c (unfollow)
Commit message (Collapse)AuthorFilesLines
13 daystests: enable failure and fix broken testsChristian Hopps21-168/+614
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). Signed-off-by: Christian Hopps <chopps@labn.net>
2024-12-22zebra: Remove tests for `srv6_locator_alloc` failureCarmine Scarpitta1-4/+0
`srv6_locator_alloc` can never fail. Let's remove the tests for allocation failure. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-12-22bgpd: Replace 16 integer with IPV6_MAX_BYTELENCarmine Scarpitta1-1/+1
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-12-22bgpd: Replace 16 integer with IPV6_MAX_BYTELENCarmine Scarpitta1-4/+3
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-12-21tests: Check if enforce-first-as is working with peer-groupsDonatas Abraitis1-4/+6
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-21bgpd: Fix `enforce-first-as` per peer-group removalDonatas Abraitis2-3/+12
If we do `no neighbor PG enforce-first-as`, it wasn't working because the flag was inherited incorrectly for the members of the peer-group. Fixes: 322462920e2a2c8b73191c6eb5157d64cf4a593e ("bgpd: Enable enforce-first-as by default") Closes: https://github.com/FRRouting/frr/issues/17702 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-21mgmtd: fix compile erroranlan_cs1-3/+3
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. Signed-off-by: anlan_cs <anlan_cs@126.com>
2024-12-21doc: Show the valid range of SRv6 locator node-lenCarmine Scarpitta1-1/+1
The documentation should provide the valid range of SRv6 locator node-len parameter, rather than the default value. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-12-21doc: Show the valid range of SRv6 locator block-lenCarmine Scarpitta1-1/+1
The documentation should provide the valid range of SRv6 locator block-len parameter, rather than the default value. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-12-21doc: Fix the order of SRv6 locator parametersCarmine Scarpitta1-1/+1
Align the order of the SRv6 locator parameters with the actual implementation: ``` "prefix X:X::X:X/M$prefix [block-len (16-64)$block_bit_len] \ [node-len (16-64)$node_bit_len] [func-bits (0-64)$func_bit_len]" ``` Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
2024-12-20pathd: Replace ctime_r() with time_to_string()Donatas Abraitis1-2/+1
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-20bgpd: Drop timestamp_string()Donatas Abraitis2-12/+2
Replace with time_to_string(). Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-20bgpd: Replace ctime_r() to time_to_string[_json]() to handle JSON/non-JSONDonatas Abraitis5-12/+8
For JSON output we don't need newline to be printed. Before: ``` "lastUpdate":{"epoch":1734490463,"string":"Wed Dec 18 04:54:23 2024\n" ``` After: ``` "lastUpdate":{"epoch":1734678560,"string":"Fri Dec 20 09:09:20 2024" ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-20lib: Add a wrapper for time_to_string() to print time in JSON outputsDonatas Abraitis1-0/+16
newline is not expected to be printed in JSON outputs, e.g.: ``` "lastUpdate":{"epoch":1734490463,"string":"Wed Dec 18 04:54:23 2024\n" ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-20babel: Clean babel config on babel daemon stopYaroslav Kholod1-0/+6
When deactivating babel no router babel and later re-enabling it router babel the previous configuration is still in place. Steps to reproduce: - Enable babel - Configure babel - Disable babel with "no router babel" - Verify config Expected correct behavior: No config present Signed-off-by: Yaroslav Kholod <y.kholod@vyos.io>
2024-12-19tests: Ignore totalRoutes, totalPaths when checking strict outputDonatas Abraitis1-3/+13
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-19tests: Check if we received a DECENT amount of prefixes/pathsDonatas Abraitis1-49/+40
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-19bgpd: Print totalRoutes and totalPaths in JSON outputDonatas Abraitis1-1/+6
E.g.: ``` r1# sh bgp ipv4 unicast neighbors 192.168.1.2 routes json { "vrfId": 0, "vrfName": "default", "tableVersion": 2, "routerId": "192.168.1.1", "defaultLocPrf": 100, "localAS": 65001, "routes": { "172.16.16.254/32": [{"valid":true,"bestpath":true,"selectionReason":"Nothing left to compare","pathFrom":"external","prefix":"172.16.16.254","prefixLen":32,"network":"172.16.16.254\/32","version":2,"weight":0,"peerId":"192.168.1.2","path":"65002 65006","origin":"incomplete","nexthops":[{"ip":"192.168.1.2","hostname":"r2","afi":"ipv4","used":true}]},{"valid":true,"multipath":true,"pathFrom":"external","prefix":"172.16.16.254","prefixLen":32,"network":"172.16.16.254\/32","version":2,"weight":0,"peerId":"192.168.1.2","path":"65002 65005","origin":"incomplete","nexthops":[{"ip":"192.168.1.2","hostname":"r2","afi":"ipv4","used":true}]}] } , "totalRoutes": 1, "totalPaths": 2 } ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-19bgpd: add rpki json attributes to bgp pathPhilippe Guibert1-5/+10
Add missing json attribute to BGP path. Fixes: 82c298be7354 ("bgpd: Show RPKI short state in `show bgp <afi> <safi>`") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-12-19bgpd: Show applied route-map attributes for `neighbor X advertised-routes ↵Donatas Abraitis3-80/+66
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 ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-19test: fix label ordering on error diff reportChristian Hopps1-1/+1
Signed-off-by: Christian Hopps <chopps@labn.net>
2024-12-19bgpd: Fix memory leak when creating BMP connection with a source interfaceDonatas Abraitis1-1/+4
Testing done with: ``` for x in $(seq 1 100000); do vtysh -c 'conf' -c 'router bgp' -c 'bmp targets test' -c 'bmp connect localhost port 123 min-retry 100 max-retry 100 source-interface lo'; done ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-19tests: Check if we can see advertised routes with route-map appliedDonatas Abraitis5-0/+141
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-19pim: handle return code to fix a couple of coverity issuesJafar Al-Gharaibeh2-4/+14
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
2024-12-18lib: Fix to optimize the time taken while batching huge configsRajasekar Raja3-1/+16
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 real 0m12.168s user 0m7.511s sys 0m1.981s Issue: 3589101 Ticket# 3589101 Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-12-18tests: add a test case for static route propagationJafar Al-Gharaibeh3-0/+74
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
2024-12-18bgpd: fix memory leak when reconfiguring a route distinguisherPhilippe Guibert1-0/+2
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>
2024-12-17bgpd: add meta queue in bgpKarthikeya Venkat Muppalla5-85/+341
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): ------------------------------------------ switch# vtysh -c "show run bgp" | grep update-delay update-delay 40 switch# cat /var/log/frr/bgpd.log | grep sub-queue 2024/12/06 23:27:46.124461 BGP: [V64FH-G6883] 22.0.0.9/32 queued into sub-queue Other Route 2024/12/06 23:27:46.160224 BGP: [V64FH-G6883] 100.90.8.11/32 queued into sub-queue Early Route 2024/12/06 23:27:46.219663 BGP: [W9QTR-P4REP] EOIU Marker queued into sub-queue EOIU Marker 2024/12/06 23:27:46.269711 BGP: [ZAPXS-9754G] 100.90.8.11/32 dequeued from sub-queue Early Route 2024/12/06 23:27:46.270980 BGP: [ZAPXS-9754G] 22.0.0.9/32 dequeued from sub-queue Other Route 2024/12/06 23:27:46.404868 BGP: [RBX2V-K33CZ] EOIU Marker dequeued from sub-queue EOIU Markera Ticket: #4200787 Signed-off-by: Karthikeya Venkat Muppalla <kmuppalla@nvidia.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-17tests: add nexthop/interface's down/up topo for kernel routesanlan_cs3-0/+88
Signed-off-by: anlan_cs <anlan_cs@126.com>
2024-12-17zebra: check kernel routes when interface becomes upanlan_cs1-0/+2
Just like `link down`, check all kernel routes when interface become up. And, they maybe will be selected as the best one by zebra. Signed-off-by: anlan_cs <anlan_cs@126.com>
2024-12-17zebra: don't uninstall kernel routesanlan_cs1-1/+1
After the nexthop check is fixed, zebra will wrongly uninstall the kernel routes with inactive nexthop. This commit would skip the uninstallation for kernel routes. Signed-off-by: anlan_cs <anlan_cs@126.com>
2024-12-17zebra: fix wrong nexthop checkanlan_cs1-1/+1
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. Signed-off-by: anlan_cs <anlan_cs@126.com>
2024-12-16bgpd: remove unneeded printfrr reg for pRNMark Stapp1-1/+0
Remove a printfrr registration for pRN from bgpd. Signed-off-by: Mark Stapp <mjs@cisco.com>
2024-12-16bgpd: Releasing the label in bgp_delete flowvaruntumbe4-19/+35
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>
2024-12-16topotests: Adding a test to control release of BGP labelsvaruntumbe5-0/+428
Adding the topotest which verifies whether label beloning to corresponding chunk has been released properly or not once we remove the vpn session Signed-off-by: Varun Hegde <varuntumbe1@gmail.com>
2024-12-16lib: darr: fix bug with nested macro useChristian Hopps1-12/+12
- 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. } ``` Signed-off-by: Christian Hopps <chopps@labn.net>
2024-12-16lib: mgmtd: use less common macro scoped variable namesChristian Hopps1-8/+8
- 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. Signed-off-by: Christian Hopps <chopps@labn.net>
2024-12-16lib: darr: use the FRR printf formatterChristian Hopps1-1/+2
Signed-off-by: Christian Hopps <chopps@labn.net>
2024-12-16tools: add support for multiple YANG pathsChristian Hopps1-5/+10
Signed-off-by: Christian Hopps <chopps@labn.net>
2024-12-13doc: Clean up Multicast RIB documentationNathan Bahr3-124/+97
Moved it all to PIM section and updated docs for recent changes. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13tests: Add new pim mrib testsNathan Bahr6-0/+441
Test mrib overrides and rpf lookup mode changes. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13pimd: Clean up pim RPF/NHT show commandsNathan Bahr2-69/+89
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. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13pimd: Update nexthops when lookup mode changesNathan Bahr2-1/+9
Link up the RPF lookup mode changing to a force update to RP's and upstreams registered for nexthop lookup cache updates. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13pimd: Refactor pim NHTNathan Bahr20-824/+931
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. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13pimd: Refactor synchronous nexthop lookupNathan Bahr2-6/+91
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. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13pimd,yang: Reimplement RPF lookup vty in router pimNathan Bahr8-5/+130
Add rpf-lookup-mode MODE vty command under router pim block. Including NB piping and config write. Using the mode still pending. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
2024-12-13zebra: Give a bit more data about zclient connection on errorsDonald Sharp1-6/+5
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. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-13tools: Add rip support bundle commandsDonald Sharp1-3/+5
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-13pimd,pim6d: optimize multicast prefix generationRafael Zalamena5-49/+24
Fix Coverity Scan CID 1602463: make it impossible for the function to fail. Hardcode the multicast prefix generation instead of calling `str2prefix()` which caused unnecessary memory allocations and returned error values. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
2024-12-12bgpd: When calling bgp_process, prevent infinite loopDonald Sharp2-13/+17
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. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-06 04:54:43 +0100