- dev - lists.frrouting.org

Notice: Telco call for 16:00 CET; 07:00 PT (tomorrow) Wednesday 5th is canceled
by Alistair Woodman 05 Aug '20

05 Aug '20

due to vacation time. (As discussed on the FRR weekly today) /a

1 0

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

04 Aug '20

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 1496595: Memory - illegal accesses (USE_AFTER_FREE) ________________________________________________________________________________________________________ *** CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) /zebra/zebra_rib.c: 2162 in rib_process_dplane_notify() 2156 2157 done: 2158 if (rn) 2159 route_unlock_node(rn); 2160 2161 /* Return context to dataplane module */ >>> CID 1496595: Memory - illegal accesses (USE_AFTER_FREE) >>> Calling "dplane_ctx_fini" dereferences freed pointer "ctx". 2162 dplane_ctx_fini(&ctx); 2163 } 2164 2165 static void process_subq_nhg(struct listnode *lnode) 2166 { 2167 struct nhg_ctx *ctx = NULL; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Pottential bugs RPKI States at FRR 7.3.1 (debian packages)
by Dewangga Alam 04 Aug '20

04 Aug '20

Hello! I am new at FRR, and trying to found a reference that indicated (bugs?) or miss configuration at version 7.3.1 using debian buster packages from deb.frrouting.org (http://deb.frrouting.org) Here’s our configuration: https://pastebin.com/xKE3AJij Already adjusted bgpd using rpki options, and when I restart frr service, the tagging was not working. > vtysh > sh bgp ipv4 103.241.24.0 BGP routing table entry for 103.241.24.0/24 Paths: (3 available, best #3, table default) Not advertised to any peer 38515 58820 103.28.75.36 from 103.28.75.0 (103.28.75.0) Origin IGP, localpref 5100, valid, internal Last update: Sat Aug 1 10:54:34 2020 38515 58820 103.28.75.36 from 103.28.74.255 (103.28.74.255) Origin IGP, localpref 5100, valid, internal Last update: Sat Aug 1 10:54:34 2020 38515 58820 103.28.75.36 from 103.28.74.129 (103.28.74.127) Origin IGP, localpref 5100, valid, internal, best (Router ID) Community: 38515:58820 Last update: Sat Aug 1 10:54:34 2020 The rpki states aren’t show, and when I paste the route-map configuration into vtysh, the loc-pref tag are valids and working. The full command pasted here: https://pastebin.com/n3VY4gNm Any hints to fix this issue ? Any helps are appreciated. Thanks in advance! Many thanks. -- Sent from Canary (https://canarymail.io)

2 1

zebra nexthop-tracking/reachability questions
by Mark Stapp 03 Aug '20

03 Aug '20

I've got a couple of questions about nexthop-tracking in zebra - these are a bit down in the details, but I thought I'd ask if any of the folks on the list have some insight... 1. the nht code makes a copy (mostly) of the route_entry that satisfies some client registration. the code copies all of the nexthops - even the recursive ones, even ones that are not ACTIVE. the code that sends nexthops to the nht client(s) has an rnh_nexthop_valid() function that is pretty strict about what will actually be sent. would it be reasonable to have the nht code capture only a list of the nexthops that are actually valid, that actually will be sent to the clients? 2. the show command for nht, ‘sho ip nht’, only shows the top-level nexthops - not the actual installed nexthops that, again, will be sent to the clients. would it be ok to change that, to try to have the show command show what will actually be sent to clients? 3. the route-map filtering in there also operates only on the top-level nexthops, not the exact ones that are "valid" and will be sent to clients. is that intentional, or should the route-map get a shot at the nexthops that the nht code would try to send? Thanks, Mark

1 0

Northbound meeting today is canceled
by Santosh P K 31 Jul '20

31 Jul '20

Hello All, I have a conflict today and hence will not be able to run northbound meeting today. Today’s meeting will be canceled. Thanks Santosh P K

1 0

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

28 Jul '20

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. 4 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 2 of 2 defect(s) ** CID 1496495: Error handling issues (CHECKED_RETURN) /zebra/zebra_dplane.c: 2539 in dplane_route_notif_update() ________________________________________________________________________________________________________ *** CID 1496495: Error handling issues (CHECKED_RETURN) /zebra/zebra_dplane.c: 2539 in dplane_route_notif_update() 2533 } 2534 2535 /* Capture info about the source of the notification, in 'ctx' */ 2536 dplane_ctx_set_notif_provider(new_ctx, 2537 dplane_ctx_get_notif_provider(ctx)); 2538 >>> CID 1496495: Error handling issues (CHECKED_RETURN) >>> Calling "dplane_update_enqueue" without checking return value (as is done elsewhere 9 out of 10 times). 2539 dplane_update_enqueue(new_ctx); 2540 2541 ret = ZEBRA_DPLANE_REQUEST_QUEUED; 2542 2543 done: 2544 return ret; ** CID 1496494: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_nb_config.c: 1221 in lib_vrf_zebra_l3vni_id_modify() ________________________________________________________________________________________________________ *** CID 1496494: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_nb_config.c: 1221 in lib_vrf_zebra_l3vni_id_modify() 1215 * if zebra vrf already mapped to different vni id. 1216 */ 1217 pn_dnode = yang_dnode_get_parent(args->dnode, "vrf"); 1218 if (pn_dnode) { 1219 vrfname = yang_dnode_get_string(pn_dnode, "./name"); 1220 vrf = vrf_lookup_by_name(vrfname); >>> CID 1496494: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "vrf", which is known to be "NULL". 1221 zvrf = zebra_vrf_lookup_by_id(vrf->vrf_id); 1222 if (zvrf->l3vni && zvrf->l3vni != vni) { 1223 zlog_debug( 1224 "vni %u cannot be configured as vni %u is already configured under the vrf", 1225 vni, zvrf->l3vni); 1226 return NB_ERR_VALIDATION; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Telco meeting status
by olivier.dugeon＠orange.com 24 Jul '20

24 Jul '20

Dear all, Following the last Telco meeting, I updated the Wiki page to reflect our new usage of GitHub Project management facilities: https://github.com/FRRouting/frr/wiki/FRR-Telco-SP-projects Regarding BGP-LS, there is already a #Telco channel on Slack with very few discussions. So, I propose to use this #Telco channel to discuss on-going development around BGP-LS. Cristain (in Cc:) started its internship within Orange one month ago. He'll join Slack soon. Cristian started to backport our old BGP-LS code to FRR. Please, interact with him through Slack to discuss how to organise the work and progress. As mentioned, I'll start 3 weeks vacations this evening. So, fill free to maintain or cancel the next Telco meeting in 2 weeks. Allistair will manage it. Finally, I'll push a preview of Link State PR as WIP. Look at the doxygen doc within link_state.h for details and usage. Enjoy your summer. Regards Olivier

1 0

BGP Link State code
by olivier.dugeon＠orange.com 17 Jul '20

17 Jul '20

Dear all, Many of you are interested by our very old code about BGP Link State. So, I decided to publish it, but ***AS IS*** more as a proof of concept rather than a running code. It is based on a old version of Quagga. I don't know if it compiles, if it runs ... As the code was unfortunately not versioned, I try to patch what seems the Quagga version from which the code was written to produce the git commit. But, I have not the time to check if the result compiles and if it is running. *Please, d**on't ask me for that*. As an old code, it is using old style. So, only new files are following FRR style. The repo is here: https://github.com/Orange-OpenSource/Quagga-TE/tree/BGP-LS The implementation is made of new files: - BGP-LS TLV definition: bgpd/bgp_ls.h - New Link State NLRI: bgpd/bgp_bgpls_nlri.c - Parser/Serializer: bgpd/bgp_ls_bgpls.c - BGP-LS Database: bgpd/bgp_lsdb.[c,h] - BGP API for OSPF-API: bgpd/bgp_api.[c,h], bgpd/bgp_ls_ospf.h - BGP Link State transcodage: bgpd/bgp_transcode.c - BGP to OSPF-API connection: bgpd/bgp_zbusclient.[c,h] At least the NLRI, TLV definition, parser / serializer and LSDB could be re-use easily. Of course all interaction with OSPF through OSPF API must be replaced by the new ZAPI Opaque message. And following files have been patched for integration: - bgpd/bgp_advertise.c, bgpd/bgp_aspath.c, bgpd/bgp_attr.|c,h], bgpd/bgp_btoa.c, bgpd/bgp_clist.c, bgpd/bgp_community.[c,h], bgpd/bgp_dump.c, bgpd/bgp_fsm.c, bgpd/bgp_main.c, bgpd/bgp_mplsvpn.c, bgpd/bgp_nexthop.c, bgpd/bgp_open.c, bgpd/bgp_packet.c, bgpd/bgp_route.c, bgpd/bgp_routemap.c, bgpd/bgp_table.c, bgpd/bgp_vty.c, bgpd/bgp_zebra.c, bgpd/bgpd.c, bgpd/bgpd.h Where takes place the huge part of difficulties in order to merge them into FRR. King regards Olivier _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

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

16 Jul '20

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 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 3 of 3 defect(s) ** CID 1496376: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_rib.c: 1948 in rib_count_installed_nh() ________________________________________________________________________________________________________ *** CID 1496376: Null pointer dereferences (NULL_RETURNS) /zebra/zebra_rib.c: 1948 in rib_count_installed_nh() 1942 } else { 1943 if (CHECK_FLAG(nexthop->flags, NEXTHOP_FLAG_ACTIVE)) 1944 count++; 1945 } 1946 } 1947 >>> CID 1496376: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing "rib_get_fib_backup_nhg(re)", which is known to be "NULL". 1948 for (ALL_NEXTHOPS_PTR(rib_get_fib_backup_nhg(re), nexthop)) { 1949 if (CHECK_FLAG(nexthop->flags, NEXTHOP_FLAG_FIB)) 1950 count++; 1951 } 1952 1953 return count; ** CID 1496375: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1496375: Memory - corruptions (OVERRUN) /zebra/zebra_mpls.c: 3408 in mpls_lsp_uninstall() 3402 nhlfe = nhlfe_find(&lsp->nhlfe_list, type, gtype, gate, 3403 ifindex); 3404 if (!nhlfe) 3405 return 0; 3406 3407 if (IS_ZEBRA_DEBUG_MPLS) { >>> CID 1496375: Memory - corruptions (OVERRUN) >>> Overrunning array "buf" of 76 bytes by passing it to a function which accesses it at byte offset 8191 using argument "8192". 3408 nhlfe2str(nhlfe, buf, BUFSIZ); 3409 zlog_debug("Del LSP in-label %u type %d nexthop %s flags 0x%x", 3410 in_label, type, buf, nhlfe->flags); 3411 } 3412 3413 if (CHECK_FLAG(lsp->flags, LSP_FLAG_INSTALLED) || ** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1190 in send_client() ________________________________________________________________________________________________________ *** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1190 in send_client() 1184 nhg = NULL; 1185 1186 if (nhg) { 1187 for (ALL_NEXTHOPS_PTR(nhg, nh)) 1188 if (rnh_nexthop_valid(re, nh)) { 1189 zapi_nexthop_from_nexthop(&znh, nh); >>> CID 1495424: Error handling issues (CHECKED_RETURN) >>> Calling "zapi_nexthop_encode" without checking return value (as is done elsewhere 5 out of 6 times). 1190 zapi_nexthop_encode(s, &znh, 1191 0 /* flags */); 1192 num++; 1193 } 1194 } 1195 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Reg: Questions about FRR APIs
by Thilak T 14 Jul '20

14 Jul '20

Hello, community, I am reasonably new to the FRR space and trying to find resources to manage the FRR instance via code. Programmatically access protocol states ( for example, show ip bgp summary) or apply configuration like changing the route-map applied to neighbors, etc. I went through the FRR docs, and I see the VTYSH session touching upon this topic in the context of the shell. How do I get started with an API ( golang, python ) to do what we can do via the vtysh? Thank you in advance for pointing me in the right direction Thanks, Thilak

1 0