June 2020 - dev - lists.frrouting.org

EIGRP
by FREIVALD, JOSEPH A 12 Jun '20

12 Jun '20

Hello, The last couple years I have been working on a side project to implement a fully functional and tested version of EIGRP based on FRR release 5.0. That work is largely complete and I would like to share with the community but it will likely require significant grooming to match the coding style requirements and stage the multiple merge requests required integrate it with the dev code-base. Unfortunately I don't have time to do that. This implementation behaves very well in complex Cisco-based networks with only one 'on-the-wire' deviation from Cisco's behavior (sending individual REPLY messages for each prefix in a bulk QUERY instead of bundling them, which only results in slightly more traffic and processor usage and doesn't affect network the topology). The latest version includes clean Stuck-in-active behavior as well. Current work is adding BFD to EIGRP using the 5.0 OSPF BFD implementation as a pony. I have two questions: 1. Are there any defects in the 5.0 implementation of BFD that I should be aware of and/or backport BFD fixes from 7.2? 2. Is there any interest in including EIGRP in the full FRR feature set? Thanks, Joseph A. T. Freivald Core Technical Architect Global Business - Public Sector Solutions AT&T 3033 Chain Bridge Road, Oakton, VA 22124-2542 m 703.853.7272 | jf1578(a)att.com<mailto:jf1578@att.com> MOBILIZING YOUR WORLD "This e-mail and any files transmitted with it are AT&T property, are confidential, and are intended solely for the use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to believe that you have received this message in error, please notify the sender and delete this message immediately from your computer. Any other uses, retention, dissemination, forwarding, printing, or copying of this email is strictly prohibited."

2 1

Meeting to discuss EVPN-MH PR #6515
by Donald Sharp 11 Jun '20

11 Jun '20

All - During today's Tech meeting we decided that we needed to review this rather large PR a bit more closely as a group in separate meetings. I would like to call a meeting at 1pm EDT on June 15. If you are interested in attending please send me a note that you would like to attend the meeting and I will get you an invite. My expectations is that people attending the meeting should have scanned the PR and come ready with concerns/questions/suggestions PR: https://github.com/FRRouting/frr/pull/6515 Doc commit: https://github.com/FRRouting/frr/pull/6515/commits/8bb4a4ace113675788153cc0… If you would like to attend the meeting please let me know and I will get you an invite. thanks! donald

1 1

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

10 Jun '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. 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 1 of 1 defect(s) ** CID 1495641: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_rnh.c: 1072 in send_client() ________________________________________________________________________________________________________ *** CID 1495641: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_rnh.c: 1072 in send_client() 1066 1067 client->nh_last_upd_time = monotime(NULL); 1068 client->last_write_cmd = cmd; 1069 return zserv_send_message(client, s); 1070 1071 failure: >>> CID 1495641: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "s" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1072 if (s) 1073 stream_free(s); 1074 return -1; 1075 } 1076 1077 static void print_nh(struct nexthop *nexthop, struct vty *vty) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0

nexthop-tracking questions
by Mark Stapp 10 Jun '20

10 Jun '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 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 discussion
by Santosh P K 06 Jun '20

06 Jun '20

Extending for 2 months.

1 0

Canceled: Northbound Weekly meeting
by Santosh P K 06 Jun '20

06 Jun '20

Extending for 2 more months.

1 0

Northbound meeting starting now
by Lou Berger 05 Jun '20

05 Jun '20

Northbound discussion Location: https://bluejeans.com/9192742159 When: Occurs every Friday

1 0

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

05 Jun '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. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1495426: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_mpls.c: 1354 in nhlfe_backup_add() ________________________________________________________________________________________________________ *** CID 1495426: Null pointer dereferences (REVERSE_INULL) /zebra/zebra_mpls.c: 1354 in nhlfe_backup_add() 1348 nhlfe = nhlfe_alloc(lsp, lsp_type, gtype, gate, ifindex, num_labels, 1349 labels); 1350 1351 SET_FLAG(nhlfe->flags, NHLFE_FLAG_IS_BACKUP); 1352 1353 /* Enqueue to LSP, at tail of list. */ >>> CID 1495426: Null pointer dereferences (REVERSE_INULL) >>> Null-checking "nhlfe" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. 1354 if (nhlfe) 1355 nhlfe_list_add_tail(&lsp->backup_nhlfe_list, nhlfe); 1356 1357 return nhlfe; 1358 } 1359 ** CID 1495425: Memory - corruptions (OVERRUN) /zebra/zebra_mpls.c: 1570 in nhlfe_print() ________________________________________________________________________________________________________ *** CID 1495425: Memory - corruptions (OVERRUN) /zebra/zebra_mpls.c: 1570 in nhlfe_print() 1564 vty_out(vty, " dev %s", 1565 ifindex2ifname(nexthop->ifindex, 1566 nexthop->vrf_id)); 1567 break; 1568 case NEXTHOP_TYPE_IPV6: 1569 case NEXTHOP_TYPE_IPV6_IFINDEX: >>> CID 1495425: Memory - corruptions (OVERRUN) >>> Overrunning array "buf" of 1024 bytes by passing it to a function which accesses it at byte offset 8191 using argument "8192U". 1570 vty_out(vty, " via %s", 1571 inet_ntop(AF_INET6, &nexthop->gate.ipv6, buf, BUFSIZ)); 1572 if (nexthop->ifindex) 1573 vty_out(vty, " dev %s", 1574 ifindex2ifname(nexthop->ifindex, 1575 nexthop->vrf_id)); ** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1050 in send_client() ________________________________________________________________________________________________________ *** CID 1495424: Error handling issues (CHECKED_RETURN) /zebra/zebra_rnh.c: 1050 in send_client() 1044 num = 0; 1045 nump = stream_get_endp(s); 1046 stream_putc(s, 0); 1047 for (ALL_NEXTHOPS(re->nhe->nhg, nh)) 1048 if (rnh_nexthop_valid(re, nh)) { 1049 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 4 out of 5 times). 1050 zapi_nexthop_encode(s, &znh, 0 /* flags */); 1051 num++; 1052 } 1053 stream_putc_at(s, nump, num); 1054 } else { 1055 stream_putc(s, 0); // type ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

1 0