May 2024 - dev - lists.frrouting.org

FRR 10.0 Release
by Jafar Al-Gharaibeh 01 Jul '24

01 Jul '24

Dear FRR Community, We are pleased to announce FRR 10.0 major release. For release notes please visit: https://frrouting.org/release/10.0/ https://github.com/FRRouting/frr/releases/tag/frr-10.0 In this release, we are deprecating a couple of features. Make sure to go over "Breaking Changes" in the release notes. Cheers, The FRR Development Team!

1 1

Proposal to Feature request: interface ip addresses order #15464
by Santhosh Muruganantham 22 May '24

22 May '24

Dear FRR Development Community, I am writing to propose a solution for an issue regarding the order of IP addresses on interfaces when using FRR, specifically when configuring loopback interfaces. Issue Description Currently, when IP addresses are assigned to an interface using vtysh, they are installed in the order specified. However, once the configuration is saved, the order of IP addresses in the configuration file is rearranged in ascending order. This reordering can be problematic in scenarios where a specific IP address order is necessary. For example, a loopback interface might have both public and private IP addresses, and it is desirable for the public IP to be the first in order to facilitate standard system operations such as updates. Proposed Solution To address this issue, I propose adding a new command to the FRR CLI that allows users to set the order of IP addresses explicitly. This command, set_order position(int), would enable users to specify the desired position of each IP address on an interface. Implementation Details 1. *New CLI Command:* - set_order position(int): This command will allow users to specify the position of an IP address on an interface. 2. *Usage Example:* 2. interface lo ip address 192.0.2.1/32 ip address 198.51.100.1/32 set_order 198.51.100.1/32 1 In the example above, the IP address 198.51.100.1/32 is set to be the first IP address on the loopback interface lo. 3. *Behavior:* - When the set_order command is used, the specified IP address will be positioned accordingly in the running configuration. - Upon saving the configuration, the order specified by the user will be preserved. 4. *Benefits:* - This feature provides users with greater control over the IP address configuration on their interfaces. - It avoids the complications associated with reordering IP addresses, particularly for systems relying on a specific address being primary. Conclusion I believe this enhancement will significantly benefit users who need precise control over IP address order on interfaces, particularly for loopback interfaces with multiple IP addresses. I am willing to contribute to the development and testing of this feature and would appreciate the community's feedback and support. Thank you for considering this proposal. I look forward to your feedback and am happy to discuss this further. SANTHOSH M Software Engineer MSys Technologies smuruganantham(a)msystechnologies.com <XXXXXX(a)msystechnologies.com> +91 9361040479 www.msystechnologies.com <https://www.google.com/url?q=https://www.msystechnologies.com/&source=gmail…> Power Your Software Development With <https://www.google.com/url?q=https://www.msystechnologies.com/&source=gmail…> <https://www.google.com/url?q=https://in.linkedin.com/company/msys-technolog…> -- ****** DISCLAIMER - MSysTechnologies LLC ****** This email message, contents and its attachments may contain confidential, proprietary or legally privileged information and is intended solely for the use of the individual or entity to whom it is actually intended. If you have erroneously received this message, please permanently delete it immediately and notify the sender. If you are not the intended recipient of the email message,you are notified strictly not to disseminate,distribute or copy this e-mail.E-mail transmission cannot be guaranteed to be secure or error-free as Information could be intercepted, corrupted, lost, destroyed, incomplete or contain viruses and MSysTechnologies LLC accepts no liability for the contents and integrity of this mail or for any damage caused by the limitations of the e-mail transmission.

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 13 May '24

13 May '24

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 1 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1587866: Insecure data handling (TAINTED_SCALAR) /zebra/fpm_listener.c: 719 in parse_netlink_msg() ________________________________________________________________________________________________________ *** CID 1587866: Insecure data handling (TAINTED_SCALAR) /zebra/fpm_listener.c: 719 in parse_netlink_msg() 713 ctx->rtmsg->rtm_protocol > RTPROT_STATIC) { 714 printf(" Route %s(%u) reflecting back\n", 715 netlink_prot_to_s( 716 ctx->rtmsg->rtm_protocol), 717 ctx->rtmsg->rtm_protocol); 718 ctx->rtmsg->rtm_flags |= RTM_F_OFFLOAD; >>> CID 1587866: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted expression "fpm_msg_len(fpm)" to "write", which uses it as an offset. 719 write(glob->sock, fpm, fpm_msg_len(fpm)); 720 } 721 break; 722 723 default: 724 fprintf(stdout, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0