- dev - lists.frrouting.org

use VXLAN on OVS/VPP
by MohammadReza MollaSalehi 03 Jul '24

03 Jul '24

Hi everyone, I'm having an issue with FRR not detecting the VXLAN interface when I use VPP or OVS. Additionally, even when I use LCP on VPP to create a TAP device, FRR still doesn't detect it. Would anyone happen to have any ideas or suggestions? Thanks for your help! MReza MollaSalehi DevOps Engineer, system administrator, security researcher Site: https://mrsalehi.info/ Email: info(a)mrsalehi.info

1 0

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

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

19 Jun '24

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 5 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 5 of 5 defect(s) ** CID 1594016: Possible Control flow issues (DEADCODE) /zebra/zebra_srv6.c: 1871 in release_srv6_sid_func_explicit() ________________________________________________________________________________________________________ *** CID 1594016: Possible Control flow issues (DEADCODE) /zebra/zebra_srv6.c: 1871 in release_srv6_sid_func_explicit() 1865 zlog_warn("%s: failed to release wide SID function %u, function is not allocated", 1866 __func__, sid_wide_func); 1867 return -1; 1868 } 1869 1870 /* Release the SID function from the EWLIB range */ >>> CID 1594016: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "listnode_delete(block->u.us...". 1871 listnode_delete(block->u.usid.wide_lib[sid_func] 1872 .func_allocated, 1873 sid_wide_func_ptr); 1874 zebra_srv6_sid_func_free(sid_wide_func_ptr); 1875 } else { 1876 zlog_warn("%s: function %u is outside ELIB [%u/%u] and EWLIB alloc ranges [%u/%u]", ** CID 1594015: (DEADCODE) /zebra/zebra_srv6.c: 1782 in get_srv6_sid() /zebra/zebra_srv6.c: 1781 in get_srv6_sid() ________________________________________________________________________________________________________ *** CID 1594015: (DEADCODE) /zebra/zebra_srv6.c: 1782 in get_srv6_sid() 1776 } 1777 1778 ret = get_srv6_sid_dynamic(sid, ctx, locator); 1779 1780 break; 1781 case SRV6_SID_ALLOC_MODE_MAX: >>> CID 1594015: (DEADCODE) >>> Execution cannot reach this statement: "case SRV6_SID_ALLOC_MODE_UN...". 1782 case SRV6_SID_ALLOC_MODE_UNSPEC: 1783 default: 1784 flog_err(EC_ZEBRA_SM_CANNOT_ASSIGN_SID, 1785 "%s: SRv6 Manager: Unrecognized alloc mode %u", 1786 __func__, alloc_mode); 1787 /* We should never arrive here */ /zebra/zebra_srv6.c: 1781 in get_srv6_sid() 1775 return -1; 1776 } 1777 1778 ret = get_srv6_sid_dynamic(sid, ctx, locator); 1779 1780 break; >>> CID 1594015: (DEADCODE) >>> Execution cannot reach this statement: "case SRV6_SID_ALLOC_MODE_MAX:". 1781 case SRV6_SID_ALLOC_MODE_MAX: 1782 case SRV6_SID_ALLOC_MODE_UNSPEC: 1783 default: 1784 flog_err(EC_ZEBRA_SM_CANNOT_ASSIGN_SID, 1785 "%s: SRv6 Manager: Unrecognized alloc mode %u", 1786 __func__, alloc_mode); ** CID 1594014: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_srv6.c: 1860 in release_srv6_sid_func_explicit() ________________________________________________________________________________________________________ *** CID 1594014: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_srv6.c: 1860 in release_srv6_sid_func_explicit() 1854 1855 /* Lookup SID function in the functions allocated list of EWLIB range */ 1856 for (ALL_LIST_ELEMENTS_RO(block->u.usid 1857 .wide_lib[sid_func] 1858 .func_allocated, 1859 node, sid_func_ptr)) >>> CID 1594014: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "sid_wide_func_ptr". 1860 if (*sid_wide_func_ptr == sid_wide_func) 1861 break; 1862 1863 /* Ensure that the SID function is allocated */ 1864 if (!sid_wide_func_ptr) { 1865 zlog_warn("%s: failed to release wide SID function %u, function is not allocated", ** CID 1594013: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_srv6.c: 961 in zebra_srv6_sid_compose() ________________________________________________________________________________________________________ *** CID 1594013: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_srv6.c: 961 in zebra_srv6_sid_compose() 955 struct srv6_locator *locator, 956 uint32_t sid_func) 957 { 958 uint8_t offset, func_len; 959 struct srv6_sid_format *format = locator->sid_format; 960 >>> CID 1594013: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "locator" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 961 if (!sid_value || !locator) 962 return false; 963 964 if (format) { 965 offset = format->block_len + format->node_len; 966 func_len = format->function_len; ** CID 1594012: (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1594012: (TAINTED_SCALAR) /nhrpd/nhrp_peer.c: 1139 in nhrp_packet_send_error() 1133 /* Don`t add extension according to RFC */ 1134 zbuf_put(zb, pp->hdr, sizeof(*pp->hdr)); 1135 zbuf_put(zb, sockunion_get_addr(&pp->src_nbma), 1136 hdr->src_nbma_address_len); 1137 zbuf_put(zb, sockunion_get_addr(&pp->src_proto), 1138 hdr->src_protocol_address_len); >>> CID 1594012: (TAINTED_SCALAR) >>> Passing tainted expression "hdr->dst_protocol_address_len" to "zbuf_put", which uses it as an offset. 1139 zbuf_put(zb, sockunion_get_addr(&pp->dst_proto), 1140 hdr->dst_protocol_address_len); 1141 nhrp_packet_complete_auth(zb, hdr, pp->ifp, false); 1142 1143 nhrp_peer_send(pp->peer, zb); 1144 zbuf_free(zb); /nhrpd/nhrp_peer.c: 1135 in nhrp_packet_send_error() 1129 hdr->flags = pp->hdr->flags; 1130 hdr->hop_count = 0; /* XXX: cisco returns 255 */ 1131 1132 /* Payload is the packet causing error */ 1133 /* Don`t add extension according to RFC */ 1134 zbuf_put(zb, pp->hdr, sizeof(*pp->hdr)); >>> CID 1594012: (TAINTED_SCALAR) >>> Passing tainted expression "hdr->src_nbma_address_len" to "zbuf_put", which uses it as an offset. 1135 zbuf_put(zb, sockunion_get_addr(&pp->src_nbma), 1136 hdr->src_nbma_address_len); 1137 zbuf_put(zb, sockunion_get_addr(&pp->src_proto), 1138 hdr->src_protocol_address_len); 1139 zbuf_put(zb, sockunion_get_addr(&pp->dst_proto), 1140 hdr->dst_protocol_address_len); /nhrpd/nhrp_peer.c: 1137 in nhrp_packet_send_error() 1131 1132 /* Payload is the packet causing error */ 1133 /* Don`t add extension according to RFC */ 1134 zbuf_put(zb, pp->hdr, sizeof(*pp->hdr)); 1135 zbuf_put(zb, sockunion_get_addr(&pp->src_nbma), 1136 hdr->src_nbma_address_len); >>> CID 1594012: (TAINTED_SCALAR) >>> Passing tainted expression "hdr->src_protocol_address_len" to "zbuf_put", which uses it as an offset. 1137 zbuf_put(zb, sockunion_get_addr(&pp->src_proto), 1138 hdr->src_protocol_address_len); 1139 zbuf_put(zb, sockunion_get_addr(&pp->dst_proto), 1140 hdr->dst_protocol_address_len); 1141 nhrp_packet_complete_auth(zb, hdr, pp->ifp, false); 1142 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

BMP Issue in FRR 10.0
by Boris Hassanov 17 Jun '24

17 Jun '24

Hi all, During the testing I found strange BMP issue. RFC 7854 describes several types of BMP messages, one of them is Stats Report (https://www.rfc-editor.org/rfc/rfc7854#page-13) The FRR documentation (.https://docs.frrouting.org/en/latest/bmp.html#bmp-session-configuration ) explicitly says:" - the following statistics codes are implemented: - 0: count of prefixes rejected - 2: count of duplicate prefix withdrawals - 3: count of prefixes with loop in cluster id - 4: count of prefixes with loop in AS-path - 5: count of prefixes with loop in originator - 7: count of routes in adj-rib-in - 8: count of routes in Loc-RIB - 11: count of updates subjected to RFC 7607 “treat as withdrawal” handling due to errors - 65531: experimental count of prefixes rejected due to invalid next-hop Note that stat items 3, 4 and 5 are specified to count updates, but FRR implements them as prefix-based counters. "The issue is that I do not see Stats Types 7 and 8 in the BMP message from FRR towards BMP collector (goBMP in my test setup): There are only 7 statistic types and no statistic codes 7 and 8. Is this a bug or I missed something in BMP config ? Here is the BMP config oof the FRR for the reference: bmp targets ubuntu-BMP bmp stats interval 300 bmp monitor ipv4 unicast pre-policy bmp monitor ipv4 unicast loc-rib bmp connect 10.30.131.101 port 5050 min-retry 30000 max-retry 3000 source-interface eth2 exit FRR1# sh ver FRRouting 10.0_git (FRR1) on Linux(5.15.0-102-generic). Thank you in advance for the clarification. SY,Boris

1 0

Proposal: Adding setorder Keyword for Ordered IP Configuration
by Gadi denny Agussy Krupa Raju 04 Jun '24

04 Jun '24

Feature URL <https://github.com/FRRouting/frr/issues/15464> Hi everyone, We'd like to propose the addition of a new keyword, "setorder", to the IP address configuration command. This keyword would allow users to specify the order in which IP addresses are applied to an interface, ensuring consistent behavior regardless of the order they are entered. *Motivation* Currently, the order in which IP addresses are configured on an interface can potentially impact functionality in some scenarios. With setorder, users can define a clear and predictable order for IP usage, eliminating this potential source of inconsistency. *Proposed Solution* The setorder keyword would be added as an optional parameter to the IP address configuration command. It would accept an integer value representing the desired order for that specific IP address. Lower values indicate a higher priority. *Example Configuration* R1# interface eth3 R1# ip address 89.A.B.2/32 setorder 5 R1# ip address 10.100.2.1/32 setorder 6 R1# ip address 16.16.2.1/32 setorder 3 R1# ip address 83.83.2.6/32 R1# ip address 63.63.2.6/32 In this example, the IP addresses would be applied in the following order (ascending setorder value): 16.16.2.1/32 (setorder 3) 89.A.B.2/32 (setorder 5) 10.100.2.1/32 (setorder 6) The remaining two IP addresses (without setorder) would retain their current behavior. *Expected Output (After FRR Reload)* interface eth3 ip address 16.16.2.1/32 setorder 3 ip address 89.A.B.2/32 setorder 5 ip address 10.100.2.1/32 setorder 6 ip address 83.83.2.6/32 ip address 63.63.2.6/32 Is the proposed setorder solution acceptable for achieving predictable IP address order on interfaces? If not, please provide details on any concerns or alternative approaches you may have. Thanks Denny Agussy -- ****** 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

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

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

26 Apr '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 1586018: Control flow issues (DEADCODE) /bgpd/bgp_ecommunity.c: 1402 in ecommunity_ecom2str() ________________________________________________________________________________________________________ *** CID 1586018: Control flow issues (DEADCODE) /bgpd/bgp_ecommunity.c: 1402 in ecommunity_ecom2str() 1396 if (sub_type == ECOMMUNITY_LINK_BANDWIDTH) 1397 ecommunity_lb_str(encbuf, sizeof(encbuf), pnt, 1398 ecom->disable_ieee_floating); 1399 else 1400 unk_ecom = 1; 1401 } else if (type == ECOMMUNITY_ENCODE_AS_NON_TRANS) { >>> CID 1586018: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "sub_type = *pnt++;". 1402 sub_type = *pnt++; 1403 if (sub_type == ECOMMUNITY_EXTENDED_LINK_BANDWIDTH) 1404 ipv6_ecommunity_lb_str(encbuf, sizeof(encbuf), 1405 pnt); 1406 else 1407 unk_ecom = 1; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

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

15 Apr '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. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1585206: Error handling issues (CHECKED_RETURN) /bgpd/bgp_fsm.c: 1804 in bgp_connect_in_progress_update_connection() ________________________________________________________________________________________________________ *** CID 1585206: Error handling issues (CHECKED_RETURN) /bgpd/bgp_fsm.c: 1804 in bgp_connect_in_progress_update_connection() 1798 1799 /* after connect is called(), getpeername is able to return 1800 * port and address on non established streams 1801 */ 1802 static void bgp_connect_in_progress_update_connection(struct peer *peer) 1803 { >>> CID 1585206: Error handling issues (CHECKED_RETURN) >>> Calling "bgp_getsockname" without checking return value (as is done elsewhere 5 out of 6 times). 1804 bgp_getsockname(peer); 1805 if (!peer->su_remote && !BGP_CONNECTION_SU_UNSPEC(peer->connection)) { 1806 /* if connect initiated, then dest port and dest addresses are well known */ 1807 peer->su_remote = sockunion_dup(&peer->connection->su); 1808 if (sockunion_family(peer->su_remote) == AF_INET) 1809 peer->su_remote->sin.sin_port = htons(peer->port); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

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

11 Apr '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 1585094: (FORWARD_NULL) /bgpd/bgp_zebra.c: 1789 in bgp_handle_route_announcements_to_zebra() /bgpd/bgp_zebra.c: 1804 in bgp_handle_route_announcements_to_zebra() ________________________________________________________________________________________________________ *** CID 1585094: (FORWARD_NULL) /bgpd/bgp_zebra.c: 1789 in bgp_handle_route_announcements_to_zebra() 1783 table = bgp_dest_table(dest); 1784 install = CHECK_FLAG(dest->flags, BGP_NODE_SCHEDULE_FOR_INSTALL); 1785 if (table && table->afi == AFI_L2VPN && table->safi == SAFI_EVPN) 1786 is_evpn = true; 1787 1788 if (BGP_DEBUG(zebra, ZEBRA)) >>> CID 1585094: (FORWARD_NULL) >>> Dereferencing null pointer "table". 1789 zlog_debug("BGP %s route %pBD(%s) with dest %p and flags 0x%x to zebra", 1790 install ? "announcing" : "withdrawing", dest, 1791 table->bgp->name_pretty, dest, dest->flags); 1792 1793 if (install) { 1794 if (is_evpn) /bgpd/bgp_zebra.c: 1804 in bgp_handle_route_announcements_to_zebra() 1798 (const struct prefix_evpn 1799 *) 1800 bgp_dest_get_prefix( 1801 dest), 1802 dest->za_bgp_pi); 1803 else >>> CID 1585094: (FORWARD_NULL) >>> Dereferencing null pointer "table". 1804 status = bgp_zebra_announce_actual(dest, 1805 dest->za_bgp_pi, 1806 table->bgp); 1807 UNSET_FLAG(dest->flags, BGP_NODE_SCHEDULE_FOR_INSTALL); 1808 } else { 1809 if (is_evpn) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0