summaryrefslogtreecommitdiffstats
path: root/configure.ac (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-06-12build: FRR 10.2 development versionfrr-10.2-devJafar Al-Gharaibeh1-1/+1
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
2024-06-11doc: Add reloading script into Python dependency sectionAlexander Trotsenko1-1/+6
Signed-off-by: Alexander Trotsenko <trotsenko93@mail.ru>
2024-06-11bgpd: Check against extended community unit size for link bandwidthDonatas Abraitis1-4/+16
If we receive a malformed packets, this could lead ptr_get_be64() reading the packets more than needed (heap overflow). ``` Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". 0 0xaaaaaadf86ec in __asan_memcpy (/home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/.libs/bgpd+0x3586ec) (BuildId: 78123cd26ada92b8b59fc0d74d292ba70c9d2e01) 1 0xaaaaaaeb60fc in ptr_get_be64 /home/ubuntu/frr-public/frr_public_private-libfuzzer/./lib/stream.h:377:2 2 0xaaaaaaeb5b90 in ecommunity_linkbw_present /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_ecommunity.c:1895:10 3 0xaaaaaae50f30 in bgp_attr_ext_communities /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_attr.c:2639:8 4 0xaaaaaae49d58 in bgp_attr_parse /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_attr.c:3776:10 5 0xaaaaab063260 in bgp_update_receive /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:2371:20 6 0xaaaaab05df00 in bgp_process_packet /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_packet.c:4063:11 7 0xaaaaaae36110 in LLVMFuzzerTestOneInput /home/ubuntu/frr-public/frr_public_private-libfuzzer/bgpd/bgp_main.c:582:3 ``` This is triggered when receiving such a packet (malformed): ``` (gdb) bt 0 ecommunity_linkbw_present (ecom=0x555556287990, bw=bw@entry=0x7fffffffda68) at bgpd/bgp_ecommunity.c:1802 1 0x000055555564fcac in bgp_attr_ext_communities (args=0x7fffffffd840) at bgpd/bgp_attr.c:2619 2 bgp_attr_parse (peer=peer@entry=0x55555628cdf0, attr=attr@entry=0x7fffffffd960, size=size@entry=20, mp_update=mp_update@entry=0x7fffffffd940, mp_withdraw=mp_withdraw@entry=0x7fffffffd950) at bgpd/bgp_attr.c:3755 3 0x00005555556aa655 in bgp_update_receive (connection=connection@entry=0x5555562aa030, peer=peer@entry=0x55555628cdf0, size=size@entry=41) at bgpd/bgp_packet.c:2324 4 0x00005555556afab7 in bgp_process_packet (thread=<optimized out>) at bgpd/bgp_packet.c:3897 5 0x00007ffff7ac2f73 in event_call (thread=thread@entry=0x7fffffffdc70) at lib/event.c:2011 6 0x00007ffff7a6fb90 in frr_run (master=0x555555bc7c90) at lib/libfrr.c:1212 7 0x00005555556457e1 in main (argc=<optimized out>, argv=<optimized out>) at bgpd/bgp_main.c:543 (gdb) p *ecom $1 = {refcnt = 1, unit_size = 8 '\b', disable_ieee_floating = false, size = 2, val = 0x555556282150 "", str = 0x5555562a9c30 "UNK:0, 255 UNK:2, 6"} ``` Reported-by: Iggy Frankovic <iggyfran@amazon.com> Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-06-10tests: introduce method to update reference data in isis_tilfa_topo1Renato Westphal305-9936/+42189
The isis_tilfa_topo1 topotest is comprehensive and contains a large amount of reference data. One problem is that, when changes occur, updating this reference data can be difficult. To address this problem, this commit introduces a method to automatically regenerate the reference data by setting the `REGEN_DATA` environment variable. Usage: $ REGEN_DATA=true python3 ./test_isis_tilfa_topo1.py When `REGEN_DATA` is set, the topotest regenerates reference data from the current run instead of comparing against existing reference data. Note that regenerated data must be manually verified for correctness. This commit also simplifies the reference data by replacing all diff files with complete JSON snapshots. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2024-06-10tests: rework isis_tilfa_topo1 to fix timing issuesRenato Westphal64-1699/+1665
In this topotest, steps 10-15 were added to test the IS-IS switchover functionality. In short, two cases were tested: switchover after a link down event and switchover after a BFD down event. Both cases were tested in sequence on the same router, rt6. This involved the following steps: - Setting the SPF delay timer to 15 seconds - Shutting down the eth-rt5 interface from the switch side - Testing the post-switchover RIB and LIB (triggered by the link down event) - Testing the post-SPF RIB and LIB - Bringing the eth-rt5 interface back up - Configuring a BFD session between rt6 and rt5 - Shutting down the eth-rt5 interface from the switch side once again - Testing the post-switchover RIB and LIB (triggered by the BFD down event) - Testing the post-SPF RIB and LIB Since the time window to test the post-switchover RIB and LIB was too narrow (10 seconds), these tests were having sporadic failures. To resolve this problem, we can simplify the switchover test as follows: - Setting the SPF delay timer to 60 seconds (not 15) - Disabling "link-detect" on rt6's eth-rt5 interface - Shutting down the eth-rt5 interface from the switch side - On rt6, testing the post-switchover RIB and LIB (triggered by the BFD down event) - On rt5, testing the post-switchover RIB and LIB (triggered by the link down event) Notice how we can test both post-link-down and post-BFD-down switchover cases simultaneously by having different "link-detect" configurations on rt5 and rt6. Additionally, by using a larger SPF delay timer, the time window to test the post-switchover RIB and LIB is much larger and less prone to sporadic failures. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
2024-06-10lib: fix copy srte_color from zapi_nexthop structurePhilippe Guibert1-0/+1
When switching from nexthop to zapi_nexthop, the srte color is copied. Do the same in reverse. Fixes: 31f937fb43f4 ("lib, zebra: Add SR-TE policy infrastructure to zebra") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-06-08ci: do apt-get update before installing required modulesChristian Hopps1-4/+6
- Use `uname -r` to also install specific module versions since with github runners the running kernel can become out-dated with the deployed packages. Signed-off-by: Christian Hopps <chopps@labn.net>
2024-06-07doc: add some text on native message API and notif xpath arrayChristian Hopps2-8/+76
Signed-off-by: Christian Hopps <chopps@labn.net>
2024-06-07mgmtd: add empty notif xpath map for completenessChristian Hopps1-0/+11
New back-end clients may need to add notification static allocations so we should have it available for those users, rather than requiring the new user delve into the mgmtd infra and modify it themselves. Signed-off-by: Christian Hopps <chopps@labn.net>
2024-06-07tests: check show route vrf all json outputLouis Scalbert1-0/+15
Check that "show ip route vrf XXX json" and the JSON at key "XXX" of "show ip route vrf all json" gives the same output. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-07zebra: fix show route memory consumptionLouis Scalbert1-10/+5
When displaying a route table in JSON, a table JSON object is storing all the prefix JSON objects containing the prefix information. This results in excessive memory allocation for JSON objects, potentially leading to an out-of-memory error on the machine with large routing tables. To Fix the memory consumption issue for the "show ip[v6] route [vrf XX] json" command, display the prefixes one by one and free the memory of each JSON object after it has been displayed. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-07zebra: fix show route vrf all memory consumptionLouis Scalbert1-1/+6
0e2fc3d67f ("vtysh, zebra: Fix malformed json output for multiple vrfs in command 'show ip route vrf all json'") has been reverted in the previous commit. Although the fix was correct, it was consuming too muca memory when displaying large route tables. A root JSON object was storing all the JSON objects containing the route tables, each containing their respective prefixes in JSON objects. This resulted in excessive memory allocation for JSON objects, potentially leading to an out-of-memory error on the machine. To Fix the memory consumption issue for the "show ip[v6] route vrf all json" command, display the tables one by one and free the memory of each JSON object after it has been displayed. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-07lib: add helpers to print json keysLouis Scalbert2-0/+17
Add helpers to print json keys in order to prepare the next commits. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-07Revert "vtysh, zebra: Fix malformed json output for multiple vrfs in command ↵Louis Scalbert1-52/+29
'show ip route vrf all json'" This reverts commit 0e2fc3d67f1d358896a764373f41cb59c095eda9. This fix was correct but not optimal for memory consumption at scale. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-06ospf6d: Handling Topo Change in GR-HELPER mode for max-age lsasRajesh Girada1-3/+1
Description: OSPF6 GR HELPER router should consider as TOPOCHANGE when it receives lsas with max age and should exit from Helper. But, it is not exiting from helper because this max age lsa is considered as duplicated lsa since the sender uses same seq number for max age lsa from the previous lsa update. Currently, topo change is not considered for duplicated lsas. So removed the duplicated check when validating TOPOCHNAGE. Signed-off-by: Rajesh Girada <rgirada@vmware.com>
2024-06-06tests: munet: update to version 0.14.9Christian Hopps13-116/+322
Topotest relevant changes: - add support for `timeout` arg to `cmd_*()` - handle invalid regexp in CLI commands - fix long interface name support Full munet changelog: munet: 0.14.9: add support for `timeout` arg to `cmd_*()` munet: 0.14.8: cleanup the cleanup (kill) on launch options munet: 0.14.7: allow multiple extra commands for shell console init munet: 0.14.6: - qemu: gather gcda files where munet can find them - handle invalid regexp in CLI commands munet: 0.14.5: - (podman) pull missing images for containers - fix long interface name support - add another router example munet: 0.14.4: mutest: add color to PASS/FAIL indicators on tty consoles munet: 0.14.3: Add hostnet node that runs it's commands in the host network namespace. munet: 0.14.2: - always fail mutest tests on bad json inputs - improve ssh-remote for common use-case of connecting to host connected devices - fix ready-cmd for python v3.11+ munet: 0.14.1: Improved host interface support. Signed-off-by: Christian Hopps <chopps@labn.net>
2024-06-05zebra: fix incoming FPM message length validationMark Stapp1-8/+8
Validate incoming message length against correct (struct rtmsg) len, not top-level netlink message header size. Signed-off-by: Mark Stapp <mjs@cisco.com>
2024-06-05nhrpd: cleans up shortcut cache entries on terminationDave LeRoy2-6/+10
nhrp_shortcut_terminate() previously was just freeing the associated AFI shortcut RIBs and not addressing existing shortcut cache entries. This cause a use after free issue in vrf_terminate() later in the terminate sequence NHRP: Received signal 7 at 1717516286 (si_addr 0x1955d, PC 0x7098786912c0); aborting... NHRP: zlog_signal+0xf5 709878ad1255 7fff3d992eb0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: core_handler+0xb5 709878b0db85 7fff3d992ff0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: __sigaction+0x50 709878642520 7fff3d993140 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000) NHRP: ---- signal ---- NHRP: __lll_lock_wait_private+0x90 7098786912c0 7fff3d9936d8 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000) NHRP: pthread_mutex_lock+0x112 709878698002 7fff3d9936e0 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000) NHRP: _event_add_read_write+0x63 709878b1f423 7fff3d993700 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: zclient_send_message+0xd4 709878b37614 7fff3d993770 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: nhrp_route_announce+0x1ad 5ab34d63d39d 7fff3d993790 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) NHRP: nhrp_shortcut_cache_notify+0xd8 5ab34d63e758 7fff3d99d4e0 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) NHRP: nhrp_cache_free+0x165 5ab34d632f25 7fff3d99d510 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) NHRP: hash_iterate+0x4d 709878ab949d 7fff3d99d540 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: nhrp_cache_interface_del+0x37 5ab34d633eb7 7fff3d99d580 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) NHRP: nhrp_if_delete_hook+0x26 5ab34d6350d6 7fff3d99d5a0 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) NHRP: if_delete_retain+0x3d 709878abcd1d 7fff3d99d5c0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: if_delete+0x4c 709878abd87c 7fff3d99d600 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: if_terminate+0x53 709878abda83 7fff3d99d630 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: vrf_terminate_single+0x24 709878b23c74 7fff3d99d670 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: nhrp_request_stop+0x34 5ab34d636844 7fff3d99d690 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) NHRP: frr_sigevent_process+0x53 709878b0df53 7fff3d99d6a0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: event_fetch+0x6c5 709878b20405 7fff3d99d6c0 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: frr_run+0xd3 709878ac8163 7fff3d99d840 /usr/lib/frr/libfrr.so.0 (mapped at 0x709878a00000) NHRP: main+0x195 5ab34d631915 7fff3d99d960 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) NHRP: __libc_init_first+0x90 709878629d90 7fff3d99d980 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000) NHRP: __libc_start_main+0x80 709878629e40 7fff3d99da20 /lib/x86_64-linux-gnu/libc.so.6 (mapped at 0x709878600000) NHRP: _start+0x25 5ab34d631b65 7fff3d99da70 /usr/lib/frr/nhrpd (mapped at 0x5ab34d621000) Signed-off-by: Dave LeRoy <dleroy@labn.net>
2024-06-05bgpd: fix label in adj-rib-outPhilippe Guibert2-1/+12
After modifying the "label vpn export value", the vpn label information of the VRF is not updated to the peers. For example, the 192.168.0.0/24 prefix is announced to the peer with a label value of 222. > router bgp 65500 > [..] > neighbor 192.0.2.2 remote-as 65501 > address-family ipv4-vpn > neighbor 192.0.2.2 activate > exit-address-family > exit > router bgp 65500 vrf vrf2 > address-family ipv4 unicast > network 192.168.0.0/24 > label vpn export 222 > rd vpn export 444:444 > rt vpn both 53:100 > export vpn > import vpn > exit-address-family Changing the label with "label vpn export" does not update the label value to the peer unless the BGP sessions is re-established. No labels are stored are stored struct bgp_adj_out so that it is impossible to compare the current value with the previous value in adj-RIB-out. Reference the bgp_labels pointer in struct bgp_adj_out and compare the values when updating adj-RIB-out. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: fix labels in adj-rib-inPhilippe Guibert3-5/+15
In a BGP L3VPN context using ADJ-RIB-IN (ie. enabled with 'soft-reconfiguration inbound'), after applying a deny route-map and removing it, the remote MPLS label information is lost. As a result, BGP is unable to re-install the related routes in the RIB. For example, > router bgp 65500 > [..] > neighbor 192.0.2.2 remote-as 65501 > address-family ipv4 vpn > neighbor 192.0.2.2 activate > neighbor 192.0.2.2 soft-reconfiguration inbound The 192.168.0.0/24 prefix has a remote label value of 102 in the BGP RIB. > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 > Remote label: 102 A route-map now filter all incoming BGP updates: > route-map rmap deny 1 > router bgp 65500 > address-family ipv4 vpn > neighbor 192.0.2.2 route-map rmap in The prefix is now filtered: > # show bgp ipv4 vpn 192.168.0.0/24 > # The route-map is detached: > router bgp 65500 > address-family ipv4 vpn > no neighbor 192.168.0.1 route-map rmap in The BGP RIB entry is present but the remote label is lost: > # show bgp ipv4 vpn 192.168.0.0/24 > BGP routing table entry for 444:1:192.168.0.0/24, version 2 > [..] > 192.168.0.0 from 192.0.2.2 > Origin incomplete, metric 0, valid, external, best (First path received) > Extended Community: RT:52:100 The reason for the loose is that labels are stored within struct attr -> struct extra -> struct bgp_labels but not in the struct bgp_adj_in. Reference the bgp_labels pointer in struct bgp_adj_in and use its values when doing a soft reconfiguration of the BGP table. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: get rid of has_valid_label in bgp_update()Louis Scalbert1-32/+15
Get rid of has_valid_label in bgp_update() to prepare the next commits. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: move labels from extra to extra->labelsLouis Scalbert18-142/+185
Move labels from extra to extra->labels. Labels are now stored in a hash list. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_labels hashLouis Scalbert8-0/+146
Add bgp_labels type and hash list. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05topotests: add bgp test to check the ADJ-RIB-IN label valuePhilippe Guibert1-0/+86
The test is done on r2. A BGP update is received on r2, and is filtered on r2. The RIB of r2 does not have the BGP update stored, but the ADJ-RIB-IN is yet present. To demonstrate this, if the inbound route-map is removed, then the BGP update should be copied from the the ADJ-RIB-IN and added to the RIB with the label value. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05topotests: add bgp test to check the ADJ-RIB-OUT label valuePhilippe Guibert2-0/+84
This test ensures that when r1 changes the label value, then the new value is automatically propagated to remote peer. This demonstrates that the ADJ-RIB-OUT to r2 has been correctly updated. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05topotests: clarify bgp_vpnv4_ebgpLouis Scalbert1-10/+38
Clarify bgp_vpnv4_ebgp Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: store number of labels with 8 bitsLouis Scalbert16-45/+44
8 bits are sufficient to store the number of labels because the current maximum is 2. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: fix too leading tabs in vnc_import_bgpLouis Scalbert1-56/+73
Small rework to fix the following checkpatch warning: > < WARNING: Too many leading tabs - consider code refactoring > < #2142: FILE: /tmp/f1-1616988/vnc_import_bgp.c:2142: Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_num_labels()Louis Scalbert15-80/+77
Add bgp_path_info_num_labels() to get the number of labels stored in a path_info structure. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: rework vni printing in route_vty_out_detail()Louis Scalbert1-19/+13
In route_vty_out_detail(), tag_buf stores a string representation of the VNI label. Rename tag_buf to vni_buf for clarity and rework the code a little bit to prepare the following commits. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: num_labels cannot be greater than BGP_MAX_LABELSLouis Scalbert1-2/+0
num_labels cannot be greater than BGP_MAX_LABELS by design. Remove the check and the override. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_labels_same()Louis Scalbert3-23/+19
Add bgp_path_info_labels_same() to compare labels with labels from path_info. Remove labels_same() that was used for mplsvpn only. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: optimize label copy for new path_infoLouis Scalbert1-6/+2
In bgp_update(), path_info *new has just been created and has void labels. bgp_labels_same() is always false. Do not compare previous labels before setting them. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: do not init labels in extraLouis Scalbert1-2/+0
No need to init labels at extra allocation. num_labels is the number of set labels in label[] and is initialized to 0 by default. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: add bgp_path_info_has_valid_label()Louis Scalbert3-12/+18
Add bgp_path_has_valid_label to check that a path_info has a valid label. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05bgpd: check and set extra num_labelsLouis Scalbert9-63/+89
The handling of MPLS labels in BGP faces an issue due to the way labels are stored in memory. They are stored in bgp_path_info but not in bgp_adj_in and bgp_adj_out structures. As a consequence, some configuration changes result in losing labels or even a bgpd crash. For example, when retrieving routes from the Adj-RIB-in table ("soft-reconfiguration inbound" enabled), labels are missing. bgp_path_info stores the MPLS labels, as shown below: > struct bgp_path_info { > struct bgp_path_info_extra *extra; > [...] > struct bgp_path_info_extra { > mpls_label_t label[BGP_MAX_LABELS]; > uint32_t num_labels; > [...] To solve those issues, a solution would be to set label data to the bgp_adj_in and bgp_adj_out structures in addition to the bgp_path_info_extra structure. The idea is to reference a common label pointer in all these three structures. And to store the data in a hash list in order to save memory. However, an issue in the code prevents us from setting clean data without a rework. The extra->num_labels field, which is intended to indicate the number of labels in extra->label[], is not reliably checked or set. The code often incorrectly assumes that if the extra pointer is present, then a label must also be present, leading to direct access to extra->label[] without verifying extra->num_labels. This assumption usually works because extra->label[0] is set to MPLS_INVALID_LABEL when a new bgp_path_info_extra is created, but it is technically incorrect. Cleanup the label code by setting num_labels each time values are set in extra->label[] and checking extra->num_labels before accessing the labels. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2024-06-05doc: Add missing `clear bgp ASNUM` commandDonatas Abraitis1-0/+4
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-06-04 ospf6d: OSPFv3 manual key authentication neglects checking the SA ID.Acee Lindem2-36/+104
Also, add topotest variation to verify checking. This corrects https://github.com/FRRouting/frr/issues/16100. Signed-off-by: Acee Lindem <acee@lindem.com>
2024-06-04bgpd: Ignore auto created VRF BGP instancesDonatas Abraitis1-1/+4
Configuration: ``` vtysh <<EOF configure vrf vrf100 vni 10100 exit-vrf router bgp 50 address-family l2vpn evpn advertise-all-vni exit-address-family exit router bgp 100 vrf vrf100 exit EOF ``` TL;DR; When we configure `advertise-all-vni` (in this case), a new BGP instance is created with the name vrf100, and ASN 50. Next, when we create `router bgp 100 vrf vrf100`, we look for the BGP instance with the same name and we found it, but ASNs are different 50 vs. 100. Every such a new auto created instance is flagged with BGP_VRF_AUTO. After the fix: ``` router bgp 50 ! address-family l2vpn evpn advertise-all-vni exit-address-family exit ! router bgp 100 vrf vrf100 exit ! end donatas.net(config)# router bgp 51 BGP is already running; AS is 50 donatas.net(config)# router bgp 50 donatas.net(config-router)# router bgp 101 vrf vrf100 BGP is already running; AS is 100 donatas.net(config)# router bgp 100 vrf vrf100 donatas.net(config-router)# ``` Fixes: https://github.com/FRRouting/frr/issues/16152 Fixes: https://github.com/FRRouting/frr/issues/9537 Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-06-04Revert "isisd: When the metric-type is configured as "wide", the IS-IS ↵Donatas Abraitis2-97/+81
generates incorrect metric values for IPv4 directly connected routes." This broke these topotests: test_isis_lsp_bits_topo1 test_isis_sr_topo1 test_isis_srv6_topo1 test_isis_tilfa_topo1 test_isis_topo1 test_isis_topo1_vrf test_ldp_snmp_topo1 test_ldp_sync_isis_topo1 This reverts commit 39e27b840e5ddc2087c0b20cfcf379745b3baa79.
2024-06-04zebra: fix compilation with GCC14Georgi Valkov1-6/+9
Fixes: zebra/zebra_netns_notify.c: In function 'zebra_ns_ready_read': zebra/zebra_netns_notify.c:266:40: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration] 266 | if (strmatch(VRF_DEFAULT_NAME, basename(netnspath))) { | ^~~~~~~~ Fixed by including libgen.h, then since basename may modify its parameter, allocate a copy on the stack, using strdupa, and pass the temporary string to basename. According to the man page for basename: With glibc, one gets the POSIX version of basename() when <libgen.h> is included, and the GNU version otherwise. The POSIX version of basename may modify the contents of path, so we should to pass a copy when calling this function. [1] https://man7.org/linux/man-pages/man3/basename.3.html Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
2024-06-04docker: fix chmod issues when running debian containerÇağatay Erem1-1/+1
I had problem by running container after build. It gave the error below in container, [FATAL tini (7)] exec /usr/lib/frr/docker-start failed: Permission denied So I have fixed the permission issues after building images. Signed-off-by: Çağatay Erem <cagatayerem@gmail.com>
2024-06-04zebra: display srv6 encapsulation source-address when configuredPhilippe Guibert1-1/+11
The 'show running-config' does not display the ipv6 source address when a locator is not configured. Fix this by systematically displaying the ipv6 source address. Fixes: 6a0956169b31 ("zebra: Add encap source address to SRv6 config write function") Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-06-04lib: comments about public vs private message apisChristian Hopps1-9/+18
Signed-off-by: Christian Hopps <chopps@labn.net>
2024-06-02ci: only run conflict check on pull-requestsChristian Hopps1-2/+1
This change will stop this action from running on forked repos. Previously whenever one pushed a change to one's development branch the action would "run but skip" which still generated an email notifications and thus was very annoying. :) Signed-off-by: Christian Hopps <chopps@labn.net>
2024-06-02bgpd: Adjust terminology related to DSCPDavid Ward5-18/+18
The default DSCP used for BGP connections is CS6. The DSCP value is not part of the TCP header. When setting the IP_TOS or IPV6_TCLASS socket options, the argument is not the 6-bit DSCP value, but an 8-bit value for the former IPv4 Type of Service field or IPv6 Traffic Class field, respectively. Fixes: 425bd64be847 ("bgpd: Allow bgp to control the DSCP session TOS value") Signed-off-by: David Ward <david.ward@ll.mit.edu>