summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-23bgpd: fix evpn attributes being dropped on inputmergify/bp/stable/10.3/pr-18378Tuetuopay
All assignments of the EVPN attributes (ESI and Gateway IP) are gated behind the peer being set up for inbound soft-reconfiguration. There are no actual reasons for this limitation, so let's perform the EVPN attribute assignment no matter what when soft reconfiguration is not enabled. Fixes: 6e076ba5231 ("bgpd: Fix for ain->attr corruption during path update") Signed-off-by: Tuetuopay <tuetuopay@me.com> (cherry picked from commit 7320659f78cbe86dd983d5101831120fc14583d7)
2025-03-23tests: add route-map evpn set gateway-ip topotestTuetuopay
This test does not actually look at the route since the gateway-ip is not exposed in vtysh output. However, this ensures such a route-map does not crash bgpd. Signed-off-by: Tuetuopay <tuetuopay@me.com> (cherry picked from commit 05a74323b9d440590074f22be11c34a605da69ad)
2025-03-23bgpd: fix `set evpn gateway-ip ipv[46]` route-mapTuetuopay
The `route_set_evpn_gateway_ip` function copies `gw_ip->ip.addr` in the route's gateway ip. In a nutshell, this skips the `ipa_type` field, writing the actual IP in the IP type. This later rightfully trips asserts about unknown IP types. The following route-map... ``` route-map test permit 10 set evpn gateway-ip ipv4 1.1.1.1 ``` ...will make the following gateway IP in the route: ``` (gdb) p/x a1->evpn_overlay->gw_ip $11 = {ipa_type = 0x1010101, ip = {addr = 0x0, addrbytes = { 0x0 <repeats 16 times>}, _v4_addr = {s_addr = 0x0}, _v6_addr = { __in6_u = {__u6_addr8 = {0x0 <repeats 16 times>}, __u6_addr16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0x0, 0x0, 0x0, 0x0}}}}} ``` We do indeed see the IP Address in the `ipa_type` field. Fix by starting the memcpy at the root of `struct ipaddr` instead of skipping the `ipa_type` field. Fixes: d0a4ee6010a ("bgpd: Add "set evpn gateway-ip" clause for route-map") Signed-off-by: Tuetuopay <tuetuopay@me.com> (cherry picked from commit 0b0e7015971a788c14dd1dc9b5bac8cb66175c29)
2025-03-22Merge pull request #18455 from FRRouting/mergify/bp/stable/10.3/pr-18108Donald Sharp
zebra: Do not flush an existing vni configuration trying to remove wrong vni (backport #18108)
2025-03-22zebra: Do not flush an existing vni configuration trying to remove wrong vnimergify/bp/stable/10.3/pr-18108Donatas Abraitis
Before: ``` pc.donatas.net(config)# do sh run | include vni vni 1 pc.donatas.net(config)# no vni 2 pc.donatas.net(config)# do sh run | include vni pc.donatas.net(config)# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> (cherry picked from commit 44fe3981ee388f7c60ab2635309bce34774116e1)
2025-03-20Merge pull request #18437 from FRRouting/mergify/bp/stable/10.3/pr-18435Donald Sharp
bgpd: Fix leaked memory when showing some bgp routes (backport #18435)
2025-03-20Merge pull request #18439 from Jafaral/rpm-fixDonald Sharp
Fix rpm packaging for 10.3 (manual backport #18426)
2025-03-20redhat: Make sure zeromq is always disabledMartin Winter
Fix issue where zeromq is getting enabled if build system has the libs installed. For RPMs, we want it always based on intended config options. (and currently the zeromq is not part of the packages) Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
2025-03-20redhat: Make docs and rpki optional for RPM package buildMartin Winter
Adding options to disable docs and rpki during the build. By default they are always built. RPKI sub-package will not be built (and not available) if built without the RPKI support. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
2025-03-20Revert "redhat: Add option to build pkg without docs and rpki support, allow ↵Martin Winter
for different system environments by including all built .so files" This reverts commit d89f21fc0602761f5adb0dd82b8c6e24a5636a20. Reverting original change from PR 17793. This commit breaks RPKI and SNMP sub-packages Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
2025-03-20bgpd: Fix leaked memory when showing some bgp routesDonald Sharp
The two memory leaks: ==387155== 744 (48 direct, 696 indirect) bytes in 1 blocks are definitely lost in loss record 222 of 262 ==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0) ==387155== by 0x2E4146: peer_adj_routes (bgp_route.c:15245) ==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549) ==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722) ==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003) ==387155== by 0x4915FE8: cmd_execute_command (command.c:1062) ==387155== by 0x4916598: cmd_execute (command.c:1228) ==387155== by 0x49EB858: vty_command (vty.c:626) ==387155== by 0x49ED77C: vty_execute (vty.c:1389) ==387155== by 0x49EFFA7: vtysh_read (vty.c:2408) ==387155== by 0x49E4156: event_call (event.c:2019) ==387155== by 0x4958ABD: frr_run (libfrr.c:1247) ==387155== by 0x206A68: main (bgp_main.c:557) ==387155== ==387155== 2,976 (192 direct, 2,784 indirect) bytes in 4 blocks are definitely lost in loss record 240 of 262 ==387155== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==387155== by 0x4C1B982: json_object_new_object (in /usr/lib/x86_64-linux-gnu/libjson-c.so.5.1.0) ==387155== by 0x2E45CA: peer_adj_routes (bgp_route.c:15325) ==387155== by 0x2E4F1A: show_ip_bgp_instance_neighbor_advertised_route_magic (bgp_route.c:15549) ==387155== by 0x2B982B: show_ip_bgp_instance_neighbor_advertised_route (bgp_route_clippy.c:722) ==387155== by 0x4915E6F: cmd_execute_command_real (command.c:1003) ==387155== by 0x4915FE8: cmd_execute_command (command.c:1062) ==387155== by 0x4916598: cmd_execute (command.c:1228) ==387155== by 0x49EB858: vty_command (vty.c:626) ==387155== by 0x49ED77C: vty_execute (vty.c:1389) ==387155== by 0x49EFFA7: vtysh_read (vty.c:2408) ==387155== by 0x49E4156: event_call (event.c:2019) ==387155== by 0x4958ABD: frr_run (libfrr.c:1247) ==387155== by 0x206A68: main (bgp_main.c:557) For the 1st one, if the operator issues a advertised-routes command, the json_ar variable was never being freed. For the 2nd one, if the operator issued a command where the output_count_per_rd is 0, we need to free the json_routes value. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 9651b159ccd18c81450251dbd3bae9c493b7a866)
2025-03-19Merge pull request #18433 from FRRouting/mergify/bp/stable/10.3/pr-18430Donald Sharp
lib: Create VRF if needed (backport #18430)
2025-03-19lib: Create VRF if neededmergify/bp/stable/10.3/pr-18430Nathan Bahr
When creating a control plane protocol through NB, create the vrf if needed instead of only looking up and asserting if it doesn't exist yet. Fixes 18429. Signed-off-by: Nathan Bahr <nbahr@atcorp.com> (cherry picked from commit b6ae01f907c071be6cd197df0f3ca6fe9baa631a)
2025-03-19Merge pull request #18422 from FRRouting/mergify/bp/stable/10.3/pr-18393Jafar Al-Gharaibeh
ospf6d: Disable and delete OSPFv3 areas that no longer have interfaces or configuration. (backport #18393)
2025-03-19 ospf6d: Disable and delete OSPFv3 areas that no longer have interfaces or ↵Acee Lindem
configuration. This fix will delete an OSPFv3 area when all the interfaces and configuration (ranges, NSSA ranges, stub area, NSSA area, filter-list, import-list and export-list) have been removed. The changes provides a general solution to https://github.com/FRRouting/frr/issues/18324. Signed-off-by: Acee Lindem <acee@lindem.com> (cherry picked from commit 04994891fe164b4d5a2819d3bc90e5346f94dc53)
2025-03-17Merge pull request #18402 from FRRouting/mergify/bp/stable/10.3/pr-18387Donald Sharp
bgpd: Fixed crash upon bgp network import-check command (backport #18387)
2025-03-15bgpd: Fixed crash upon bgp network import-check commandManpreet Kaur
BT: ``` 3 <signal handler called> 4 0x00005616837546fc in bgp_static_update (bgp=bgp@entry=0x5616865eac50, p=0x561686639e40, bgp_static=0x561686639f50, afi=afi@entry=AFI_IP6, safi=safi@entry=SAFI_UNICAST) at ../bgpd/bgp_route.c:7232 5 0x0000561683754ad0 in bgp_static_add (bgp=0x5616865eac50) at ../bgpd/bgp_table.h:413 6 0x0000561683785e2e in no_bgp_network_import_check (self=<optimized out>, vty=0x5616865e04c0, argc=<optimized out>, argv=<optimized out>) at ../bgpd/bgp_vty.c:4609 7 0x00007fdbcc294820 in cmd_execute_command_real (vline=vline@entry=0x561686663000, ``` The program encountered a SEG FAULT when attempting to access pi->extra->vrfleak->bgp_orig because pi->extra->vrfleak was NULL. ``` (gdb) p pi->extra->vrfleak $1 = (struct bgp_path_info_extra_vrfleak *) 0x0 (gdb) p pi->extra->vrfleak->bgp_orig Cannot access memory at address 0x8 ``` Added NOT NULL check on pi->extra->vrfleak before accessing pi->extra->vrfleak->bgp_orig to prevent the segmentation fault. Signed-off-by: Manpreet Kaur <manpreetk@nvidia.com> (cherry picked from commit bc1008b970541c090e36fc1d50c720df822fcb99)
2025-03-15Merge pull request #18391 from FRRouting/mergify/bp/stable/10.3/pr-18360Donatas Abraitis
zebra: ensure proper return for failure for Sid allocation (backport #18360)
2025-03-14zebra: ensure proper return for failure for Sid allocationRajasekar Raja
The functions alloc_srv6_sid_func_explicit/dynamic expect to return bool but we have places where we return a -1 or NULL which the caller is assuming as a True/Valid and ending up allocating Sid Without Fix: 2025/03/10 21:44:04.295350 ZEBRA: [XWV20-TGK70] alloc_srv6_sid_func_explicit: trying to allocate explicit SID function 65088 from block fcbb:bbbb::/32 2025/03/10 21:44:04.295351 ZEBRA: [MM61M-TQZNP] alloc_srv6_sid_func_explicit: elib s 10000 e 20000 wlib s 1000 ewlib s 30000 e 1000 SID_FUNC 65088 2025/03/10 21:44:04.295352 ZEBRA: [QGHMB-SWNFW] alloc_srv6_sid_func_explicit: function 65088 is outside ELIB [10000/20000] and EWLIB alloc ranges [30000/1000] 2025/03/10 21:44:04.295367 ZEBRA: [H0GZA-NNSWJ] get_srv6_sid_explicit: allocated explicit SRv6 SID fcbb:bbbb:1:fe40:: for context End.X nh6 2001::2 2025/03/10 21:44:04.295368 ZEBRA: [XBBYD-T1Q7P] srv6_manager_get_sid_internal: got new SRv6 SID for ctx End.X nh6 2001::2: sid_value=fcbb:bbbb:1:fe40:: (func=65088) (proto=4, instance=0, sessionId=0), notifying all clients With Fix: 2025/03/10 22:04:25.052235 ZEBRA: [MM61M-TQZNP] alloc_srv6_sid_func_explicit: elib s 30000 e 31000 wlib s 31000 ewlib s 30000 e 31000 SID_FUNC 65056 2025/03/10 22:04:25.052236 ZEBRA: [YHMRC-EMYNX] alloc_srv6_sid_func_explicit: function 65056 is outside ELIB [30000/31000] and EWLIB alloc ranges [30000/31000] 2025/03/10 22:04:25.052254 ZEBRA: [XSG8X-Q2XJX] get_srv6_sid_explicit: invalid SM request arguments: failed to allocate SID function 65056 from block fcbb:bbbb::/32 2025/03/10 22:04:25.052257 ZEBRA: [YC52T-427SJ] srv6_manager_get_sid_internal: not got SRv6 SID for ctx End.DT6 vrf_id 4, sid_value=fcbb:bbbb:1:fe20::, locator_name=MAIN root@rajasekarr:/tmp/topotests/static_srv6_sids.test_static_srv6_sids/r1# Ticket :# Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com> (cherry picked from commit 5a63cf4c0d1e7b84f59003877599c6575ba08a25)
2025-03-09FRR Release 10.3frr-10.3docker/10.3.0rc/10.3Jafar Al-Gharaibeh
- Major highlights: - Lua 5.4 support - Fixed CVE-2024-55553 - New match community-count BGP command to limit communities count - New set metric igp|aigp BGP command to inject IGP metric as MED into BGP - New bgp ipv6-auto-ra BGP command - Optimize BGP EVPN L2VNI/L3VIN remote routes processing - Respect non-transitive BGP extended communities between direct peers - Drop deprecated bgp network import-check exact command - Handle BGP ENHE (Extended Next Hop Encoding) capability via dynamic capability - Implement BGP connect backoff retry - Implement an ability to import BMP information from a separate BGP instance - Add support of BGP color extended community color-only types - Implement SBFD - Add support for SRv6 static SIDs - Implement embedded-rp for PIMv6 - Implement AutoRP mapping-agent for PIM - Implement MSDP peer SA limiting Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
2025-03-09debian, redhat: updating changelog for new releaseJafar Al-Gharaibeh
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
2025-03-09Merge pull request #18353 from FRRouting/mergify/bp/dev/10.3/pr-18348Jafar Al-Gharaibeh
Topotest startup order (backport #18348)
2025-03-09Merge pull request #18352 from FRRouting/mergify/bp/dev/10.3/pr-18338Jafar Al-Gharaibeh
Documentation typesafe (backport #18338)
2025-03-09tests: Have zebra startup look for the zserv.api socketDonald Sharp
Ensure that the zserv.api socket is actually up and running before moving onto other daemons after zebra. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 009f42dd5bd02eb5ee0bd9852704357c6bc7aaa1)
2025-03-09tests: Allow mgmtd and zebra to fully come up before other daemonsDonald Sharp
Currently the topotest infrastructure is starting up daemons in mgmtd,zebra, staticd then everything else. The problem that is happening, under heavy load, is that zebra may not be fully started and when a daemon attempts to connect to it, it will not be able to connect. Some of the daemons do not have great retry mechanisms at all. In addition our normal systemctl startup scripts actually wait a small amount of time for zebra to be ready before moving onto the other daemons. Let's make topotests startup a tiny bit more nuanced and have mgmtd fully up before starting up zebra. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit dd609bc069857a38ff3577b76d0b9ef708b8d2aa)
2025-03-09doc: The sbfd documentation was not being includedDonald Sharp
Add the sbfd documentation, such as it is, to the developer documentation so that it can be read by people. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit f1c75deb8e6581b0c3eb2129a61c017ca1d9be99)
2025-03-09doc: Developer documentation missing some build instructionsDonald Sharp
The building-frr-for-ubuntu2404 and building-doc were missing from the compilation of developer documents. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 4738cb51d2019e8852887e97e9a0363ec29728a4)
2025-03-09doc: Add typesafe conversion examplesDonald Sharp
Try to give some good examples of various lists being converted over to the typesafe way of doing things. Signed-off-by: Donald Sharp <sharpd@nvidia.com> (cherry picked from commit 39909f9fb9459ce210cb44a10291a053d4fbb272)
2025-03-06Merge pull request #18331 from FRRouting/mergify/bp/dev/10.3/pr-18214Donald Sharp
zebra: Bring up 514 BGP neighbor sessions (backport #18214)
2025-03-06Merge pull request #18332 from FRRouting/mergify/bp/dev/10.3/pr-18315Donald Sharp
pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo) (backport #18315)
2025-03-06pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo)Martin Buck
When receiving MLD messages, prefer pktinfo over msghdr.msg_name for determining the source interface. The latter is just the VRF master interface in case of VRF and we need the true interface the packet was received on instead. Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org> (cherry picked from commit 374c8dc4dbc8a560036fecdfb3213f690099b869)
2025-03-06tests: add support for 514 unnumbered/v4/v6 BGP sessionsSoumya Roy
Signed-off-by: Soumya Roy <souroy@nvidia.com> (cherry picked from commit 10ff0d5e4cf08dacf2bf82b2350dac403633e380)
2025-03-06tests: add support for bringimg up 514 BGP neighborsSoumya Roy
Signed-off-by: Soumya Roy <souroy@nvidia.com> (cherry picked from commit fd80124ccab4afed32c09437986ad1347440fc81)
2025-03-06zebra: Bring up 514 BGP neighbor sessionsSoumya Roy
Issue: When 514 inerfaces/neighbors are configured, it creates socket error, "Cannot allocate memory", when back to back V6 RA messages are tried to be sent over the socket. This prevents interface, to know its peer's link local address. Socket error comes when 1) try to join ICMPv6 all router multicast group, back to back for all interfaces 2)send back to back RA for all interfaces Fix: 1)For ICMPv6 join case, we check if the interface has already joined all router group, if not try to join. On failure, retry joining after random amount of time determined 1 ms to ICMPV6_JOIN_TIMER_EXP_MS(100 ms) 2) For RA issue case, batch sending of RA mesages using wheel timer Testing: Monitor BGP session running sh bgp summary command Before fix: r1# sh bgp summary IPv4 Unicast Summary: BGP router identifier 192.168.1.1, local AS number 1001 VRF default vrf-id 0 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 515, using 12 MiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc r1-eth0 4 1002 89 90 0 0 0 00:07:10 0 0 N/A r1-eth1 4 1002 89 90 0 0 0 00:07:10 0 0 N/A r1-eth2 4 1002 89 90 0 0 0 00:07:10 0 0 N/A r1-eth3 4 1002 89 90 0 0 0 00:07:10 0 0 N/A r1-eth4 4 1002 89 90 0 0 0 00:07:10 0 0 N/A r1-eth5 4 1002 89 90 0 0 0 00:07:10 0 0 N/A …..<snip>... r1-eth252 4 1002 31 29 0 0 0 00:02:08 0 0 N/A r1-eth253 4 1002 31 29 0 0 0 00:02:08 0 0 N/A r1-eth254 4 1002 31 29 0 0 0 00:02:08 0 0 N/A r1-eth255 4 1002 31 29 0 0 0 00:02:08 0 0 N/A r1-eth256 4 0 0 0 0 0 0 never Idle 0 N/A r1-eth257 4 0 0 0 0 0 0 never Idle 0 N/A r1-eth258 4 0 0 0 0 0 0 never Idle 0 N/A r1-eth259 4 0 0 0 0 0 0 never Idle 0 N/A r1-eth260 4 0 0 0 0 0 0 never Idle 0 N/A ……..<snip>….. r1-eth511 4 0 0 0 0 0 0 never Idle 0 N/A r1-eth512 4 0 0 0 0 0 0 never Idle 0 N/A r1-eth513 4 0 0 0 0 0 0 never Idle 0 N/A r1-eth514 4 0 0 0 0 0 0 never Idle 0 N/A After fix: r1# show bgp summary IPv4 Unicast Summary: BGP router identifier 192.168.1.1, local AS number 1001 VRF default vrf-id 0 BGP table version 0 RIB entries 0, using 0 bytes of memory Peers 515, using 12 MiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc r1-eth0 4 1002 87 87 0 0 0 00:07:04 0 0 N/A r1-eth1 4 1002 87 87 0 0 0 00:07:04 0 0 N/A r1-eth2 4 1002 87 87 0 0 0 00:07:04 0 0 N/A r1-eth3 4 1002 64 67 0 0 0 00:05:09 0 0 N/A r1-eth4 4 1002 87 87 0 0 0 00:07:04 0 0 N/A r1-eth5 4 1002 87 87 0 0 0 00:07:04 0 0 N/A r1-eth6 4 1002 67 70 0 0 0 00:05:22 0 0 N/A r1-eth7 4 1002 87 87 0 0 0 00:07:04 0 0 N/A r1-eth8 4 1002 87 87 0 0 0 00:07:04 0 0 N/A .... r1-eth499 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth500 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth501 4 1002 19 22 0 0 0 00:01:21 0 0 N/A r1-eth502 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth503 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth504 4 1002 20 23 0 0 0 00:01:30 0 0 N/A r1-eth505 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth506 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth507 4 1002 22 25 0 0 0 00:01:39 0 0 N/A r1-eth508 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth509 4 1002 17 20 0 0 0 00:01:13 0 0 N/A r1-eth510 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth511 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth512 4 1002 19 22 0 0 0 00:01:22 0 0 N/A r1-eth513 4 1002 43 43 0 0 0 00:03:22 0 0 N/A r1-eth514 4 1002 43 43 0 0 0 00:03:22 0 0 N/A Signed-off-by: Soumya Roy <souroy@nvidia.com> (cherry picked from commit 6a75d33b5cb9f5a87d71d169e24c1ae15e1bd896)
2025-03-03Merge pull request #18302 from LabNConsulting/chopps/fix-nb-bugsJafar Al-Gharaibeh
Bring in 2 northbound bug-fixes from master to 10.3
2025-03-03lib: nb: fix bug with oper-state query on list dataChristian Hopps
The capacity of the xpath string was not guaranteed to be sufficient to hold all the key predicates and so would truncate. Calculate the required space and guarantee that it is available. Signed-off-by: Christian Hopps <chopps@labn.net>
2025-03-03lib: nb: fix bug with keyless list specific index lookupChristian Hopps
Signed-off-by: Christian Hopps <chopps@labn.net>
2025-03-03Merge pull request #18291 from FRRouting/mergify/bp/dev/10.3/pr-18290Donald Sharp
tools: Fix `frr-reload.py` error related to `static-sids` (backport #18290)
2025-03-03Merge pull request #18296 from FRRouting/mergify/bp/dev/10.3/pr-18294Donald Sharp
isisd: Correct edge insertion into TED (backport #18294)
2025-03-03Merge pull request #18292 from FRRouting/mergify/bp/dev/10.3/pr-18289Donald Sharp
staticd: Fix `no srv6` command (backport #18289)
2025-03-03isisd: Correct edge insertion into TEDOlivier Dugeon
Edges are not correctly linked to Vertices during LSP processing. In function lsp_to_edge_cb(), once edge created or updated from the LSP TLVs, the code try to link the edge to destination vertices. In case the revert edge is not found, the code try to found a destination vertex to link to. But, the sys_id used for this operation corresponds to the source vertex. As a result, the edge is attached as source and destination of the vertex. When Traffic Engineering is stopped, TED is deleted which result into a double free of the edge attributes. This cause a crash when attempt to free extended admin groupi the second time. This patch removed wrong code which link twice the edge to the source vertex. Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com> (cherry picked from commit 605fc1dd6404b6ed51691c647568939adde4962a)
2025-03-03tests: Add test case to verify that SIDs can be re-addedCarmine Scarpitta
Add a test case to verify that staticd is able to re-install all SIDs after disabling and re-enabling SRv6. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit 0e0eca6c5f287c936570a3be50dde120ade1b9b8)
2025-03-03tests: Add test case to verify `no srv6` commandCarmine Scarpitta
Add a test case to verify that staticd removes all SIDs when the `no srv6` command is executed. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit 58373a61d559036990b875bbf0afdc9e92174975)
2025-03-03staticd: Fix `no srv6` commandCarmine Scarpitta
A user can configure static SIDs as follows: [...] segment-routing srv6 static-sids sid fcbb:bbbb:1::/48 locator MAIN behavior uN sid fcbb:bbbb:1:fe00::/64 locator MAIN behavior uDT46 [...] When the user runs vtysh and executes the `no srv6` command, the expectation is that staticd will deallocate all SIDs. However, currently FRR does not behaves as expected. After the user executes `no srv6`, the SIDs are still present. The problem is that vtysh does not forward the `no srv6` command to mgmtd/staticd. The `no srv6` command is defined using the `DEFUN_YANG_NOSH` macro, which instructs `xref2vtysh.py` to skip the `no srv6` command during the generation of `vtysh_cmd.c`. As a result, vtysh is unaware that it should forward the `no srv6` command to mgmtd/staticd. This commit fixes the issue by replacing `DEFUN_YANG_NOSH` with `DEFUN_YANG`. This change ensures that `xref2vtysh.py` includes the `no srv6` command when generating `vtysh_cmd.c` and makes vtysh forward the `no srv6` command to mgmtd/staticd. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit b94be4a1c5ad6de7547a64d20a2f5124780fe4e7)
2025-03-03tools: Fix `frr-reload.py` error related to `static-sids`Carmine Scarpitta
``` [...] segment-routing srv6 static-sids sid fcbb:bbbb:1::/48 locator MAIN behavior uN sid fcbb:bbbb:1:fe10::/64 locator MAIN behavior uDT4 vrf Vrf10 sid fcbb:bbbb:1:fe20::/64 locator MAIN behavior uDT6 vrf Vrf20 sid fcbb:bbbb:1:fe30::/64 locator MAIN behavior uDT46 vrf Vrf30 sid fcbb:bbbb:1:fe40::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2 [...] ``` When the user has a configuration like the one above and runs the command `frr-reload.py --reload`, the following error occurs: ``` [1129654|mgmtd] sending configuration line 17: % Unknown command[76]: sid fcbb:bbbb:1::/48 locator MAIN behavior uN line 23: % Unknown command[76]: sid fcbb:bbbb:1:fe10::/64 locator MAIN behavior uDT4 vrf Vrf10 line 29: % Unknown command[76]: sid fcbb:bbbb:1:fe20::/64 locator MAIN behavior uDT6 vrf Vrf20 line 35: % Unknown command[76]: sid fcbb:bbbb:1:fe30::/64 locator MAIN behavior uDT46 vrf Vrf30 line 41: % Unknown command[76]: sid fcbb:bbbb:1:fe40::/64 locator MAIN behavior uA interface sr0 nexthop 2001::2 ``` The problem is that in `frr-reload-py` all commands that start a new multi-line context must be included in the `ctx_keyword` dictionary. However, the `static-sids` command is not part of the `ctx_keyword` dictionary. This commit fixes the problem by adding `static-sids` to `ctx_keyword`. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit a515de1c46f617ee3608ab55cdef5f2a262d387a)
2025-03-01Merge pull request #18265 from FRRouting/mergify/bp/dev/10.3/pr-18254Jafar Al-Gharaibeh
ospf6d: Fix use after free of router in OSPFv3 ABR route calculation. (backport #18254)
2025-02-28Merge pull request #18284 from FRRouting/mergify/bp/dev/10.3/pr-18263Jafar Al-Gharaibeh
staticd: Add `no` form for `static-sids` command (backport #18263)
2025-02-28tests: Add test case to verify that SIDs can be re-addedCarmine Scarpitta
Add a test case to verify that staticd is able to re-install all SIDs after deleting and re-adding them. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit 641f0c6deb483c78a5cf2d69ec5335e5d4e498a5)
2025-02-28tests: Add test case to verify `no static-sids` commandCarmine Scarpitta
Add a test case to verify that staticd removes all SIDs when the `no static-sids` command is executed. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit 303be67e6ab185954b05c16c499a6b258311d897)
2025-02-28vtysh: Add `no static-sids` commandCarmine Scarpitta
Previous commits introduced the `no` form for the `static-sids` command. This change allow users to remove all static SIDs at once. This commit makes the `no static-sids` command available in vtysh. ``` router# config router(config)# segment-routing router(sr)# srv6 router(srv6)# no static-sids ``` Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com> (cherry picked from commit 96134d196490c304b3b78487b06f0d34ce488651)