- dev - lists.frrouting.org

FRRouting to leverage AI/ML networking synergies
by David 'equinox' Lamparter 02 Apr '23

02 Apr '23

Hi all, as you are likely well aware, recent developments in Artificial Intelligence and Machine Learning have been consistently performing one quantum leap after another. To leverage the new possibilities and avenues enabled by these developments, and not get left behind, we must join up and integrate these new technologies as soon as possible. I would therefore like to present our plans for the immediate future: - all SPF calculation and BGP best-path decision logic is to be replaced by a GNN (Graph Neural Network). In preparation of this, significant effort has been made to train such a network to produce results exceeding those provided by the previous hard-coded logic. - all configuration interfacing is to be performed by Microsoft's Sydney LLM (Large Language Model) chatbot. Not only is this the obvious choice of vendor considering our SONiC integration, but we also believe Sydney to be superior in its capability to handle typical network engineers' outbursts of swearing and curses. In fact, we are confident that future networks may be configured by simply swearing at the hardware until it works. - monitoring and other OAM functions will be handled by clippy, as provided in the original version of Office 97. The rationale for this is to ease the production of the appropriate curses necessary to affect the configuration changes needed to fix the outage at hand. We understand some of you may be concerned about the reliability and availability of these new AIs. As an open source project, we will obviously not try to confine you to the use of our provided AIs. In fact, we will try our best to enable you to train up your own AI according to the needs of your particular network! (Cloud compute credits not included.) I am happy to invite you all to join our path to this bright future, -equi P.S.: Please note that, despite the obvious connection, YANG schemas and configuration data exceed the limits of swearing we were able to train Sydney for. I am unsure we will be able to achieve this particular feat, but it's not quite time to give up just yet.

3 2

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 25 Mar '23

25 Mar '23

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 1536876: Null pointer dereferences (NULL_RETURNS) /pimd/pim_zebra.c: 80 in pim_zebra_interface_vrf_update() ________________________________________________________________________________________________________ *** CID 1536876: Null pointer dereferences (NULL_RETURNS) /pimd/pim_zebra.c: 80 in pim_zebra_interface_vrf_update() 74 pim_ifp = ifp->info; 75 if (!pim_ifp) 76 return 0; 77 78 pim_ifp->pim->mcast_if_count--; 79 pim_ifp->pim = pim; >>> CID 1536876: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "pim_ifp->pim", which is known to be "NULL". 80 pim_ifp->pim->mcast_if_count++; 81 82 return 0; 83 } 84 85 #ifdef PIM_DEBUG_IFADDR_DUMP ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Re: [dev] SONIC FRR version @ https://github.com/sonic-net/sonic-frr (v7.0 & 8.2.2)
by Jafar Al-Gharaibeh 24 Mar '23

24 Mar '23

You should bring this up with the SONIC folks, we (FRR maintainers) have no control over their code/tags. --Jafar On 3/10/23 00:09, raja.2001--- via dev wrote: > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 23 Mar '23

23 Mar '23

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 1536832: Memory - corruptions (OVERLAPPING_COPY) /mgmtd/mgmt_history.c: 85 in mgmt_history_create_cmt_rec() ________________________________________________________________________________________________________ *** CID 1536832: Memory - corruptions (OVERLAPPING_COPY) /mgmtd/mgmt_history.c: 85 in mgmt_history_create_cmt_rec() 79 80 new = XCALLOC(MTYPE_MGMTD_CMT_INFO, sizeof(struct mgmt_cmt_info_t)); 81 gettimeofday(&cmt_recd_tv, NULL); 82 mgmt_realtime_to_string(&cmt_recd_tv, new->time_str, 83 sizeof(new->time_str)); 84 mgmt_history_hash(new->time_str, new->cmtid_str); >>> CID 1536832: Memory - corruptions (OVERLAPPING_COPY) >>> In the call to function "snprintf", the object pointed to by argument "new->cmtid_str" may overlap with the object pointed to by argument "new->cmt_json_file". 85 snprintf(new->cmt_json_file, sizeof(new->cmt_json_file), 86 MGMTD_COMMIT_FILE_PATH, new->cmtid_str); 87 88 if (mgmt_cmt_infos_count(&mm->cmts) == MGMTD_MAX_COMMIT_LIST) { 89 FOREACH_CMT_REC (mm, cmt_info) 90 last_cmt_info = cmt_info; ** CID 1536831: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_be_server.c: 123 in mgmt_be_server_start() ________________________________________________________________________________________________________ *** CID 1536831: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_be_server.c: 123 in mgmt_be_server_start() 117 118 MGMTD_BE_SRVR_DBG("Started MGMTD Backend Server!"); 119 return; 120 121 mgmt_be_server_start_failed: 122 if (sock) >>> CID 1536831: Error handling issues (NEGATIVE_RETURNS) >>> "sock" is passed to a parameter that cannot be negative. 123 close(sock); 124 125 mgmt_be_listen_fd = -1; 126 exit(-1); 127 } 128 ** CID 1536830: Resource leaks (RESOURCE_LEAK) /mgmtd/mgmt_history.c: 146 in mgmt_history_read_cmt_record_index() ________________________________________________________________________________________________________ *** CID 1536830: Resource leaks (RESOURCE_LEAK) /mgmtd/mgmt_history.c: 146 in mgmt_history_read_cmt_record_index() 140 sizeof(struct mgmt_cmt_info_t)); 141 memcpy(new, &cmt_info, sizeof(struct mgmt_cmt_info_t)); 142 mgmt_cmt_infos_add_tail(&mm->cmts, new); 143 } else { 144 zlog_err("More records found in index file %s", 145 MGMTD_COMMIT_INDEX_FILE_NAME); >>> CID 1536830: Resource leaks (RESOURCE_LEAK) >>> Variable "fp" going out of scope leaks the storage it points to. 146 return false; 147 } 148 149 cnt++; 150 } 151 ** CID 1536829: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_fe_server.c: 123 in mgmt_fe_server_start() ________________________________________________________________________________________________________ *** CID 1536829: Error handling issues (NEGATIVE_RETURNS) /mgmtd/mgmt_fe_server.c: 123 in mgmt_fe_server_start() 117 118 MGMTD_FE_SRVR_DBG("Started MGMTD Frontend Server!"); 119 return; 120 121 mgmt_fe_server_start_failed: 122 if (sock) >>> CID 1536829: Error handling issues (NEGATIVE_RETURNS) >>> "sock" is passed to a parameter that cannot be negative. 123 close(sock); 124 125 mgmt_fe_listen_fd = -1; 126 exit(-1); 127 } 128 ** CID 1536828: Possible Control flow issues (DEADCODE) /mgmtd/mgmt_txn.c: 1859 in mgmt_txn_get_config() ________________________________________________________________________________________________________ *** CID 1536828: Possible Control flow issues (DEADCODE) /mgmtd/mgmt_txn.c: 1859 in mgmt_txn_get_config() 1853 mgmt_txn_get_config_failed: 1854 1855 if (pending_list) { 1856 /* 1857 * Move the transaction to corresponding pending list. 1858 */ >>> CID 1536828: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "if (req_list) mgmt_txn_re...". 1859 if (req_list) 1860 mgmt_txn_reqs_del(req_list, txn_req); 1861 txn_req->pending_be_proc = true; 1862 mgmt_txn_reqs_add_tail(pending_list, txn_req); 1863 MGMTD_TXN_DBG( 1864 "Moved Req: %p for Txn: %p from Req-List to Pending-List", ** CID 1536827: Null pointer dereferences (NULL_RETURNS) /mgmtd/mgmt_ds.c: 526 in mgmt_ds_delete_data_nodes() ________________________________________________________________________________________________________ *** CID 1536827: Null pointer dereferences (NULL_RETURNS) /mgmtd/mgmt_ds.c: 526 in mgmt_ds_delete_data_nodes() 520 /* 521 * Return a special error code so the caller can choose 522 * whether to ignore it or not. 523 */ 524 return NB_ERR_NOT_FOUND; 525 /* destroy dependant */ >>> CID 1536827: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "nb_node", which is known to be "NULL". 526 if (nb_node->dep_cbs.get_dependant_xpath) { 527 nb_node->dep_cbs.get_dependant_xpath(dnode, dep_xpath); 528 529 dep_dnode = yang_dnode_get( 530 ds_ctx->config_ds ? ds_ctx->root.cfg_root->dnode 531 : ds_ctx->root.dnode_root, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Re: [dev] Need help to avoid ips getting published in LDP address message
by Renato Westphal 19 Mar '23

19 Mar '23

You can try one of the following commands under the LDP address family node: * *label local allocate for ACCESSLIST_NAME*: use an ACL to select which prefixes should have a local label allocated * *label local allocate host-routes*: allocate labels for host routes only (/32's and /128's) Em sex., 17 de mar. de 2023 às 08:59, Girish Patoliya via dev < dev(a)lists.frrouting.org> escreveu: > > > > ---------- Forwarded message ---------- > From: Girish Patoliya <girishkumar.patoliya(a)mavenir.com> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 17 Mar 2023 11:23:34 +0000 > Subject: Need help to avoid ips getting published in LDP address message > > Hi > > > > I am using FRR version 8.1 for OSPF, LDP & BGP. > I am enabling LDP on interface eth2, however once LDP is operational, it > shares Ips of eth0 & eth1 in address message with “IN USE” as NO. > > I want to completely avoid ips of eth0 & eth1 getting published via LSD > address message. > is there any way ? > > > > Thanks > > Girish > > > ------------------------------ > > This e-mail message may contain confidential or proprietary information of > Mavenir Systems, Inc. or its affiliates and is intended solely for the use > of the intended recipient(s). If you are not the intended recipient of this > message, you are hereby notified that any review, use or distribution of > this information is absolutely prohibited and we request that you delete > all copies in your control and contact us by e-mailing to > security(a)mavenir.com. This message contains the views of its author and > may not necessarily reflect the views of Mavenir Systems, Inc. or its > affiliates, who employ systems to monitor email messages, but make no > representation that such messages are authorized, secure, uncompromised, or > free from computer viruses, malware, or other defects. Thank You > > > > ---------- Forwarded message ---------- > From: Girish Patoliya via dev <dev(a)lists.frrouting.org> > To: "dev(a)lists.frrouting.org" <dev(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 17 Mar 2023 11:23:34 +0000 > Subject: [dev] Need help to avoid ips getting published in LDP address > message > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/dev > -- Renato Westphal

1 0

Need help to avoid ips getting published in LDP address message
by Girish Patoliya 17 Mar '23

17 Mar '23

Hi I am using FRR version 8.1 for OSPF, LDP & BGP. I am enabling LDP on interface eth2, however once LDP is operational, it shares Ips of eth0 & eth1 in address message with "IN USE" as NO. I want to completely avoid ips of eth0 & eth1 getting published via LSD address message. is there any way ? Thanks Girish ________________________________ This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You

1 0

Weekly FRR YANG Meeting
by Pushpasis Sarkar 13 Mar '23

13 Mar '23

Rescheduling this adjusting for daylight changes. Hi Resending the meeting invite for the weekly YANG meeting. Whoever are interested in the ongoing YANG related work in FRR community, are welcome to join this Bluejeans meeting. https://bluejeans.com/377688464 Thanks and regards, -Pushasis

1 0

SONIC FRR version @ https://github.com/sonic-net/sonic-frr (v7.0 & 8.2.2)
by raja.2001＠yahoo.com 10 Mar '23

10 Mar '23

Hi, We have a copy of FRR code for SONIC at https://github.com/sonic-net/sonic-frr which is dated back to May 2019 (7.0 FRR version) But the tags at https://github.com/sonic-net/sonic-frr/tags indicate 8.2.2 FRR version. Can someone please help clarify if the old copy of FRR code above in SONIC is no longer being used and 8.2.2 is the latest FRR version integrated with SONIC ? If FRR releases from https://github.com/FRRouting/frr/releases are being used for SONIC, it will help to delete the sonic-frr copy of the code to avoid confusion. Thank you Best Regards

1 1

Stop sorting routing table for static routes
by Alireza Arzehgar 07 Mar '23

07 Mar '23

After adding a new static route in the router via vtysh or some shells, FRR will add this route to its routing table. I think everythings stored on `struct route_table`. Using `show ip route` will display sorted routes. Even when we add a new route on configuration, It will store sorted. How can we stop sorting default routes on our router ?

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 28 Feb '23

28 Feb '23

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 1535272: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1535272: Null pointer dereferences (FORWARD_NULL) /pimd/pim6_mld.c: 2474 in gm_show_if_vrf() 2468 2469 if (js) { 2470 js_if = json_object_new_object(); 2471 json_object_object_add(js_vrf, ifp->name, js_if); 2472 } 2473 >>> CID 1535272: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "tt" to "gm_show_if_one", which dereferences it. 2474 gm_show_if_one(vty, ifp, js_if, tt); 2475 } 2476 2477 /* Dump the generated table. */ 2478 if (!js && !detail) { 2479 table = ttable_dump(tt, "\n"); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0