June 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

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

20 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 18 Jun '24

18 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