- dev - lists.frrouting.org

Request for nominations for candidates for the 2024 FRR TSC election.
by Alistair Woodman 08 Oct '24

08 Oct '24

All, This is the first request for nominations for candidates for the 2024 TSC election. Please contact / unicast me with nominations or questions. 1) Self-nominations are welcome. 2) All nominees must be active FRR maintainers in order to stand. 3) Present TSC members must opt-out of being auto-nominated. 4) If you plan to nominate someone else, please get their approval first. /a (your friendly FRR community elections officer)

1 0

Nominate people to be maintainers
by Philippe Guibert 03 Oct '24

03 Oct '24

All - I would like to nominate Carmine Scarpitta to be maintainer to the FRR project. He has contributed in the FRR code, especially the SRv6 code, and already made a great job until now. thanks!

1 0

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

03 Oct '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 1600055: Control flow issues (UNREACHABLE) /bgpd/bgp_mpath.c: 495 in bgp_path_info_mpath_update() ________________________________________________________________________________________________________ *** CID 1600055: Control flow issues (UNREACHABLE) /bgpd/bgp_mpath.c: 495 in bgp_path_info_mpath_update() 489 UNSET_FLAG(cur_iterator->flags, BGP_PATH_MULTIPATH_NEW); 490 491 cur_iterator = cur_iterator->next; 492 } 493 break; 494 >>> CID 1600055: Control flow issues (UNREACHABLE) >>> This code cannot be reached: "if (debug) do { stat...". 495 if (debug) 496 zlog_debug("%pBD(%s): Mpath count %u is equal to maximum paths allowed, finished comparision for MPATHS", 497 dest, bgp->name_pretty, mpath_count); 498 } 499 500 if (debug) ________________________________________________________________________________________________________ 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 25 Sep '24

25 Sep '24

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 6 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1599962: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_intra.c: 775 in ospf6_intra_prefix_lsa_get_prefix_str() ________________________________________________________________________________________________________ *** CID 1599962: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_intra.c: 775 in ospf6_intra_prefix_lsa_get_prefix_str() 769 { 770 struct ospf6_prefix *prefix = nth_prefix(lsa->header, pos); 771 struct in6_addr in6 = { 0 }; 772 char tbuf[16]; 773 774 /* ensure buflen >= INET6_ADDRSTRLEN + '/128\0' */ >>> CID 1599962: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "lsa" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 775 if (!lsa || !prefix || !buf || buflen < (5 + INET6_ADDRSTRLEN)) 776 return NULL; 777 778 memcpy(&in6, OSPF6_PREFIX_BODY(prefix), 779 OSPF6_PREFIX_SPACE(prefix->prefix_length)); 780 inet_ntop(AF_INET6, &in6, buf, buflen); ** CID 1599961: Null pointer dereferences (FORWARD_NULL) /pimd/pim_nb_config.c: 3770 in lib_interface_gmp_address_family_proxy_modify() ________________________________________________________________________________________________________ *** CID 1599961: Null pointer dereferences (FORWARD_NULL) /pimd/pim_nb_config.c: 3770 in lib_interface_gmp_address_family_proxy_modify() 3764 ifp = nb_running_get_entry(args->dnode, NULL, true); 3765 pim_ifp = ifp->info; 3766 if (pim_ifp) 3767 pim_ifp->gm_proxy = yang_dnode_get_bool(args->dnode, 3768 NULL); 3769 >>> CID 1599961: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "pim_ifp". 3770 if (pim_ifp->gm_proxy) 3771 pim_if_gm_proxy_init(pim_ifp->pim, ifp); 3772 else 3773 pim_if_gm_proxy_finis(pim_ifp->pim, ifp); 3774 } 3775 return NB_OK; ** CID 1599960: Error handling issues (CHECKED_RETURN) /pimd/pim_autorp.c: 560 in autorp_send_announcement() ________________________________________________________________________________________________________ *** CID 1599960: Error handling issues (CHECKED_RETURN) /pimd/pim_autorp.c: 560 in autorp_send_announcement() 554 !pim_ifp->pim_passive_enable && 555 !pim_addr_is_any(pim_ifp->primary_address)) { 556 setsockopt(autorp->sock, IPPROTO_IP, 557 IP_MULTICAST_IF, 558 &(pim_ifp->primary_address), 559 sizeof(pim_ifp->primary_address)); >>> CID 1599960: Error handling issues (CHECKED_RETURN) >>> Calling "sendto(autorp->sock, autorp->annouce_pkt, autorp->annouce_pkt_sz, 0, __CONST_SOCKADDR_ARG({.__sockaddr__ = (struct sockaddr *)&announceGrp}), 16U)" without checking return value. This library function may fail and return an error code. 560 sendto(autorp->sock, autorp->annouce_pkt, 561 autorp->annouce_pkt_sz, 0, 562 (struct sockaddr *)&announceGrp, 563 sizeof(announceGrp)); 564 } 565 } ** CID 1599959: Control flow issues (DEADCODE) /bgpd/bgp_vty.c: 10614 in bgp_imexport_vrf_magic() ________________________________________________________________________________________________________ *** CID 1599959: Control flow issues (DEADCODE) /bgpd/bgp_vty.c: 10614 in bgp_imexport_vrf_magic() 10608 * restart where VRF instance has default VRF's ASN. 10609 */ 10610 SET_FLAG(vrf_bgp->vrf_flags, BGP_VRF_AUTO); 10611 } 10612 10613 if (ret) { >>> CID 1599959: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, "VRF %s is not...". 10614 vty_out(vty, 10615 "VRF %s is not configured as a bgp instance\n", 10616 import_name); 10617 return CMD_WARNING; 10618 } 10619 } ** CID 1599958: (CHECKED_RETURN) /pimd/pim_autorp.c: 556 in autorp_send_announcement() /pimd/pim_autorp.c: 543 in autorp_send_announcement() ________________________________________________________________________________________________________ *** CID 1599958: (CHECKED_RETURN) /pimd/pim_autorp.c: 556 in autorp_send_announcement() 550 * and have a primary address set. 551 */ 552 if (CHECK_FLAG(ifp->status, ZEBRA_INTERFACE_ACTIVE) && 553 pim_ifp && pim_ifp->pim_enable && 554 !pim_ifp->pim_passive_enable && 555 !pim_addr_is_any(pim_ifp->primary_address)) { >>> CID 1599958: (CHECKED_RETURN) >>> Calling "setsockopt(autorp->sock, IPPROTO_IP, 32, &pim_ifp->primary_address, 4U)" without checking return value. This library function may fail and return an error code. 556 setsockopt(autorp->sock, IPPROTO_IP, 557 IP_MULTICAST_IF, 558 &(pim_ifp->primary_address), 559 sizeof(pim_ifp->primary_address)); 560 sendto(autorp->sock, autorp->annouce_pkt, 561 autorp->annouce_pkt_sz, 0, /pimd/pim_autorp.c: 543 in autorp_send_announcement() 537 538 announceGrp.sin_family = AF_INET; 539 announceGrp.sin_port = htons(PIM_AUTORP_PORT); 540 inet_pton(PIM_AF, PIM_AUTORP_ANNOUNCEMENT_GRP, &announceGrp.sin_addr); 541 542 if (autorp->annouce_pkt_sz >= MIN_AUTORP_PKT_SZ) { >>> CID 1599958: (CHECKED_RETURN) >>> Calling "setsockopt(autorp->sock, IPPROTO_IP, 33, &autorp->announce_scope, 1U)" without checking return value. This library function may fail and return an error code. 543 setsockopt(autorp->sock, IPPROTO_IP, IP_MULTICAST_TTL, 544 &(autorp->announce_scope), 545 sizeof(autorp->announce_scope)); 546 547 FOR_ALL_INTERFACES (autorp->pim->vrf, ifp) { 548 pim_ifp = ifp->info; ** CID 1599957: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_intra.c: 581 in ospf6_link_lsa_get_prefix_str() ________________________________________________________________________________________________________ *** CID 1599957: Null pointer dereferences (REVERSE_INULL) /ospf6d/ospf6_intra.c: 581 in ospf6_link_lsa_get_prefix_str() 575 int buflen, int pos) 576 { 577 struct ospf6_link_lsa *link_lsa = lsa_after_header(lsa->header); 578 struct ospf6_prefix *prefix = nth_prefix(lsa->header, pos); 579 struct in6_addr in6 = { 0 }; 580 >>> CID 1599957: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "lsa" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 581 if (!lsa || !prefix || !buf || buflen < (1 + INET6_ADDRSTRLEN)) 582 return NULL; 583 584 /* position zero is used for the lladdr in the body of the LSA */ 585 if (pos == 0) { 586 inet_ntop(AF_INET6, &link_lsa->linklocal_addr, buf, buflen); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

FRR EVPN MH Query
by Atul Chowdhry 21 Sep '24

21 Sep '24

Hi Guys, I am looking at the given below function zebra_evpn_mac_is_static in zebra/zebra_evpn_mac.h file. */* if the mac has been added of a mac-route from the peer* * * or if it is being referenced by a neigh added by the * peer we cannot let it age out i.e. we set the static bit * in the dataplane */* *static inline bool zebra_evpn_mac_is_static(struct zebra_mac *mac){ return ((mac->flags & ZEBRA_MAC_ALL_PEER_FLAGS) || mac->sync_neigh_cnt);}* Is the use of ZEBRA_MAC_ALL_PEER_FLAGS correct here ? The current code is leading to creation of static mac on mac originating peer also since it will have the ZEBRA_MAC_ES_PEER_PROXY flag set. With this logic, mac is installed as static on all peers members of MH LAG. How will the mac then age out ? Rgds Atul

1 0

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

29 Aug '24

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 4 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 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 4 of 4 defect(s) ** CID 1599394: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 82 in bgp_reads_on() ________________________________________________________________________________________________________ *** CID 1599394: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 82 in bgp_reads_on() 76 void bgp_reads_on(struct peer_connection *connection) 77 { 78 struct frr_pthread *fpt = bgp_pth_io; 79 assert(fpt->running); 80 81 assert(connection->status != Deleted); >>> CID 1599394: Concurrent data access violations (MISSING_LOCK) >>> Accessing "connection->ibuf" without holding lock "peer_connection.io_mtx". Elsewhere, "peer_connection.ibuf" is written to with "peer_connection.io_mtx" held 5 out of 5 times. 82 assert(connection->ibuf); 83 assert(connection->fd); 84 assert(connection->ibuf_work); 85 assert(connection->obuf); 86 assert(!connection->t_connect_check_r); 87 assert(!connection->t_connect_check_w); ** CID 1599393: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 53 in bgp_writes_on() ________________________________________________________________________________________________________ *** CID 1599393: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_io.c: 53 in bgp_writes_on() 47 struct frr_pthread *fpt = bgp_pth_io; 48 49 assert(fpt->running); 50 51 assert(connection->status != Deleted); 52 assert(connection->obuf); >>> CID 1599393: Concurrent data access violations (MISSING_LOCK) >>> Accessing "connection->ibuf" without holding lock "peer_connection.io_mtx". Elsewhere, "peer_connection.ibuf" is written to with "peer_connection.io_mtx" held 5 out of 5 times. 53 assert(connection->ibuf); 54 assert(connection->ibuf_work); 55 assert(!connection->t_connect_check_r); 56 assert(!connection->t_connect_check_w); 57 assert(connection->fd); 58 ** CID 1599392: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_fsm.c: 524 in bgp_holdtime_timer() ________________________________________________________________________________________________________ *** CID 1599392: Concurrent data access violations (MISSING_LOCK) /bgpd/bgp_fsm.c: 524 in bgp_holdtime_timer() 518 * events on the peer. If we have incoming 519 * data on the peers inq, let's give the system a chance 520 * to handle that data. This can be especially true 521 * for systems where we are heavily loaded for one 522 * reason or another. 523 */ >>> CID 1599392: Concurrent data access violations (MISSING_LOCK) >>> Accessing "connection->ibuf" without holding lock "peer_connection.io_mtx". Elsewhere, "peer_connection.ibuf" is written to with "peer_connection.io_mtx" held 5 out of 5 times. 524 inq_count = atomic_load_explicit(&connection->ibuf->count, 525 memory_order_relaxed); 526 if (inq_count) 527 BGP_TIMER_ON(connection->t_holdtime, bgp_holdtime_timer, 528 peer->v_holdtime); 529 ** CID 1599391: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_rib.c: 4416 in rib_add_multipath() ________________________________________________________________________________________________________ *** CID 1599391: Null pointer dereferences (FORWARD_NULL) /zebra/zebra_rib.c: 4416 in rib_add_multipath() 4410 ZEBRA_IFA_NOPREFIXROUTE)) { 4411 zebra_nhg_free(n); 4412 zebra_rib_route_entry_free(re); 4413 return -1; 4414 } 4415 >>> CID 1599391: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "ng". 4416 if (ifp->ifindex == ng->nexthop->ifindex) 4417 re->type = ZEBRA_ROUTE_CONNECT; 4418 } 4419 } 4420 4421 ret = rib_add_multipath_nhe(afi, safi, p, src_p, re, n, startup); ________________________________________________________________________________________________________ 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 28 Aug '24

28 Aug '24

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 2 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1599385: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_routemap.c: 1084 in route_match_vni() ________________________________________________________________________________________________________ *** CID 1599385: Null pointer dereferences (REVERSE_INULL) /bgpd/bgp_routemap.c: 1084 in route_match_vni() 1078 && (evp->prefix.route_type != BGP_EVPN_AD_ROUTE 1079 && evp->prefix.route_type != BGP_EVPN_MAC_IP_ROUTE 1080 && evp->prefix.route_type != BGP_EVPN_IP_PREFIX_ROUTE)) 1081 return RMAP_NOOP; 1082 1083 for (label_cnt = 0; label_cnt < BGP_MAX_LABELS && >>> CID 1599385: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "path" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1084 label_cnt < BGP_PATH_INFO_NUM_LABELS(path); 1085 label_cnt++) { 1086 if (vni == label2vni(&path->extra->labels->label[label_cnt])) 1087 return RMAP_MATCH; 1088 } 1089 ** CID 1599384: (USE_AFTER_FREE) /bgpd/bgp_route.c: 4883 in bgp_update() /bgpd/bgp_route.c: 4965 in bgp_update() /bgpd/bgp_route.c: 4937 in bgp_update() /bgpd/bgp_route.c: 4909 in bgp_update() /bgpd/bgp_route.c: 5389 in bgp_update() ________________________________________________________________________________________________________ *** CID 1599384: (USE_AFTER_FREE) /bgpd/bgp_route.c: 4883 in bgp_update() 4877 bgp_path_info_labels_same(pi, bgp_labels.label, 4878 bgp_labels.num_labels))) { 4879 if (get_active_bdc_from_pi(pi, afi, safi) && 4880 peer->sort == BGP_PEER_EBGP && 4881 CHECK_FLAG(pi->flags, BGP_PATH_HISTORY)) { 4882 if (bgp_debug_update(peer, p, NULL, 1)) { >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4883 bgp_debug_rdpfxpath2str( 4884 afi, safi, prd, p, label, 4885 num_labels, addpath_id ? 1 : 0, 4886 addpath_id, evpn, pfx_buf, 4887 sizeof(pfx_buf)); 4888 zlog_debug("%pBP rcvd %s", peer, /bgpd/bgp_route.c: 4965 in bgp_update() 4959 */ 4960 bgp_aggregate_decrement(bgp, p, pi, afi, safi); 4961 } 4962 4963 /* Received Logging. */ 4964 if (bgp_debug_update(peer, p, NULL, 1)) { >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4965 bgp_debug_rdpfxpath2str(afi, safi, prd, p, label, 4966 num_labels, addpath_id ? 1 : 0, 4967 addpath_id, evpn, pfx_buf, 4968 sizeof(pfx_buf)); 4969 zlog_debug("%pBP rcvd %s", peer, pfx_buf); 4970 } /bgpd/bgp_route.c: 4937 in bgp_update() 4931 return; 4932 } 4933 4934 /* Withdraw/Announce before we fully processed the withdraw */ 4935 if (CHECK_FLAG(pi->flags, BGP_PATH_REMOVED)) { 4936 if (bgp_debug_update(peer, p, NULL, 1)) { >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4937 bgp_debug_rdpfxpath2str( 4938 afi, safi, prd, p, label, num_labels, 4939 addpath_id ? 1 : 0, addpath_id, evpn, 4940 pfx_buf, sizeof(pfx_buf)); 4941 zlog_debug( 4942 "%pBP rcvd %s, flapped quicker than processing", /bgpd/bgp_route.c: 4909 in bgp_update() 4903 "%pBP rcvd UPDATE w/ attr: %s", 4904 peer, 4905 peer->rcvd_attr_str); 4906 peer->rcvd_attr_printed = 1; 4907 } 4908 >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 4909 bgp_debug_rdpfxpath2str( 4910 afi, safi, prd, p, label, 4911 num_labels, addpath_id ? 1 : 0, 4912 addpath_id, evpn, pfx_buf, 4913 sizeof(pfx_buf)); 4914 zlog_debug( /bgpd/bgp_route.c: 5389 in bgp_update() 5383 if (!peer->rcvd_attr_printed) { 5384 zlog_debug("%pBP rcvd UPDATE w/ attr: %s", peer, 5385 peer->rcvd_attr_str); 5386 peer->rcvd_attr_printed = 1; 5387 } 5388 >>> CID 1599384: (USE_AFTER_FREE) >>> Passing freed pointer "evpn" as an argument to "bgp_debug_rdpfxpath2str". 5389 bgp_debug_rdpfxpath2str(afi, safi, prd, p, label, num_labels, 5390 addpath_id ? 1 : 0, addpath_id, evpn, 5391 pfx_buf, sizeof(pfx_buf)); 5392 zlog_debug("%pBP rcvd UPDATE about %s -- DENIED due to: %s", 5393 peer, pfx_buf, reason); 5394 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=u001.AxU2LYlgjL6eX23u9ErQy-2…

1 0

EVPN Query
by Atul Chowdhry 27 Aug '24

27 Aug '24

Hi Guys, I am looking at the given below function zebra_evpn_mac_is_static in zebra/zebra_evpn_mac.h file. /* if the mac has been added of a mac-route from the peer * or if it is being referenced by a neigh added by the * peer we cannot let it age out i.e. we set the static bit * in the dataplane */ static inline bool zebra_evpn_mac_is_static(struct zebra_mac *mac) { return ((mac->flags & ZEBRA_MAC_ALL_PEER_FLAGS) || mac->sync_neigh_cnt); } Is the use of ZEBRA_MAC_ALL_PEER_FLAGS correct here ? I feel that it should be ZEBRA_MAC_ES_PEER_ACTIVE instead. The current code is leading to creation of static mac on mac originating peer also since it will have the ZEBRA_MAC_ES_PEER_PROXY flag set. Rgds Atul

1 0

FRR Release 10.1
by Jafar Al-Gharaibeh 08 Aug '24

08 Aug '24

Dear FRR Community, We are pleased to announce FRR release 10.1. Release notes are available at: https://frrouting.org/release https://github.com/FRRouting/frr/releases Please let us know if you see any issues. Cheers, The FRR Development Team!

1 0

Re: [dev] BMP Issue in FRR 10.0
by Donatas Abraitis 07 Aug '24

07 Aug '24

You are checking the master branch (development) documentation. You should use https://docs.frrouting.org/en/stable-10.0/bmp.html. On Tue, Jul 23, 2024 at 3:08 PM Boris Hassanov via dev < dev(a)lists.frrouting.org> wrote: > > > > ---------- Forwarded message ---------- > From: Boris Hassanov <bhassanov(a)yahoo.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Mon, 17 Jun 2024 17:12:18 +0000 (UTC) > Subject: BMP Issue in FRR 10.0 > 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 > <https://datatracker.ietf.org/doc/html/rfc7607.html> “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): > > [image: Inline image] > > > 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 > > > > > > > > > ---------- Forwarded message ---------- > From: Boris Hassanov via dev <dev(a)lists.frrouting.org> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Mon, 17 Jun 2024 17:12:18 +0000 (UTC) > Subject: [dev] BMP Issue in FRR 10.0 > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > -- Donatas

2 1