- dev - lists.frrouting.org

About how the LSA of ospf6d is stored in an LSDB?
by yanhc519 29 Jun '20

29 Jun '20

1 0

ODL BGPCEP Magnesium Retrospective and Roadmap for Aluminium presentation
by olivier.dugeon＠orange.com 25 Jun '20

25 Jun '20

Dear all, As promise during the telco meeting, here it is the indication to join my talk on PCE during the LFN virtual Developer Day Forum event. I will present what has been develop and possible cooperation with FRR to automate OpenDayLight tests. Regards Olivier -- What: ODL BGPCEP Magnesium Retrospective and Roadmap for Aluminium When: Thu Jun 25 2020 from 14:00 to 15:00 (Time zone: Paris) Calendar: LFN Events > Virtual Developer & Testing Form > Cross-Community, LFN Events > Virtual Developer & Testing Form > OpenDaylight Who: Olivier Dugeon Meeting Link: https://zoom.us/j/96665493200 Minutes: https://wiki.opendaylight.org/x/IAsF Description: This retrospective will present a quick overview of PCE new functionalities introduced in Magnesium. In particular the Graph model and Path Computation Algorithms that enable full support of RFC5440. It will be followed by a short demo of new features. Then, roadmap to upcoming features for Aluminium release will be presented. Meeting ID: 966 6549 3200 Find your local number: https://zoom.us/u/acvVzQ7WiV Link: https://teamup.com/event/show/id/Kd9jTADTPqLnjLNoZnek7k2FT9NG61 Event exported from Teamup

1 0

Frr foe ubuntu 20.04
by Oliver O'Boyle 22 Jun '20

22 Jun '20

Hi, I've been keeping an eye out for an Ubutu 20.04 package but do not see one yet. I'm going to need it really soon. Any chance you can get one up there in the next week? Thanks, Oliver

1 0

Telco meeting agenda
by olivier.dugeon＠orange.com 17 Jun '20

17 Jun '20

Dear all, Next Telco meeting is tomorrow Wednesday 10th of June 16h - 17h Paris time. Here it is the agenda. Perhaps we'll not have time to go through all points, but we'll try to do our best. - Status on Segment Routing PR and next steps - Status on Traffic Engineering (TED) - Presentation of Backup Paths (PR 6530) by Mark - Discussion about the new project facilities on GitHub to follow Telco actions (similar to what northbound call do) - Discussion on Pathd & PCELib Regards Olivier

3 6

Ubuntu 20.04 LTS File..
by Kevin Morales 13 Jun '20

13 Jun '20

Hi, when do you are to add file for Ubuntu 20.04 LTS (focal) on your repository? [image: image.png] https://deb.frrouting.org/ Thanks! -- *Kevin Morales*

2 1

Fwd: EIGRP
by Rafael Zalamena 13 Jun '20

13 Jun '20

Re sending to list. ---------- Forwarded message --------- From: Rafael Zalamena <rzalamena(a)opensourcerouting.org> Date: Fri, Jun 12, 2020 at 1:58 PM Subject: Re: [dev] EIGRP To: Quentin Young <qlyoung(a)cumulusnetworks.com> Cc: FREIVALD, JOSEPH A <jf1578(a)att.com>, dev(a)lists.frrouting.org <dev(a)lists.frrouting.org> Hi all, On Fri, Jun 12, 2020 at 1:20 PM Quentin Young <qlyoung(a)cumulusnetworks.com> wrote: > > Hi Joseph - sounds like some cool work. > > Is this based on the EIGRP implementation we currently have, or is this implemented from scratch? > > >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? > > Rafael is likely the best person to answer that in specifics, but seeing as there's well over 7000 commits to FRR since 5.0, at least 224 of which are in BFD, the answer is almost certainly yes. > Any particular reason you chose to stay based on the 5.0 branch? I don't think BFD protocol integration has changed much (the `lib/bfd.h` part), if we are only talking about integration. Since 5.0 I can think of four big changes: - Added support for Control Plane Independent bit (by Philippe Guibert from 6Wind) - Added VRF support: allow a instance to create session in multiple VRFs (also from Phillipe) - Some daemons have BFD integration command using northbound (e.g. YANG models) - (not commited yet) a separated function to replace the old zebra talking function (see PR https://github.com/FRRouting/frr/pull/6437 ), the old one should still works ( see bfd_peer_sendmsg ) When you fast-forward to `master` you'll probably only need to adjust function call to include extra parameters (or change for the new function). The BFD daemon code itself otherwise has gone through heavy changes, but protocol integration has seen very little change since we keep compatibility with ptm-bfd (Cumulus External daemon). It will only be a problem if you want to modify BFD daemon code. I think the biggest challenge of implementing eigrp in FRR 5.0 is the lack of northbound support. We already have EIGRP YANG models and working CLI using northbound in newer versions. > > >Is there any interest in including EIGRP in the full FRR feature set? > > Yes, but we have an existing EIGRP implementation that is currently being worked on by others. Unfortunately, this development practice of creating whole features in private and then publishing them all at once has, time and again, proved very difficult to support for a collaborative free software project that moves as fast as we do :(. In any case we'd certainly be interested in the code to see what can be done. I agree... Maybe we should write some more literature educating people to slowly integrate required code before merging a big feature (avoid the all-or-nothing and rebase-hell problems). > > P.s. I suggest you join our public slack if you'd be interested in chatting with the other folks working on EIGRP in FRR. > https://frrouting.org/#participate > Regards, Rafael

1 0

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 12 Jun '20

12 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 11 Jun '20

11 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