September 2018 - dev - lists.frrouting.org

Fwd: [NetDev-People] Announcing Netdev 0x13 conference
by Donald Sharp 18 Sep '18

18 Sep '18

All - The next netdev conference is in Prague in late march of 2019, placed right before the next IETF. I am currently planning on attending/presenting at this conference and hope to see some of you there. This conference would be an excellent place to spend some face to face time with your fellow FRRouting developers as well as linux kernel developers. I also think that we would be well served if presentations from the FRR community were submitted at this conference as well. thanks! donald ---------- Forwarded message ---------- From: Jamal Hadi Salim via people <people(a)lists.netdevconf.org> Date: Tue, Sep 18, 2018 at 8:11 AM Subject: [NetDev-People] Announcing Netdev 0x13 conference To: people <people(a)netdevconf.org> Cc: lwn(a)lwn.net, "netdev(a)vger.kernel.org" <netdev(a)vger.kernel.org>, linux-wireless <linux-wireless(a)vger.kernel.org>, netfilter-devel(a)vger.kernel.org On behalf of the NetDev Society, this is a formal announcement that Netdev 0x13 conference will be held in Prague, Czech Republic. Tentative dates are March 20-22, 2019. We had a very successful 0x12 meeting. The summaries are posted here: https://lwn.net/Articles/763627/rss For more details, all the slides, papers and videos are now up. Visit: https://www.netdevconf.org/0x12/accepted-sessions.html At 0x12 we tried a new format where the first day constitutes developer working sessions via workshops and educational sessions via tutorials. We have received feedback which we are in the process of evaluating and we will be notifying you of any format changes. The window for suggestions is still open - please send email to people(a)netdevconf.org. We hope to announce the CFP much earlier than usual to give folks ample time to submit. For more frequent announcements join the people@netdevconf mailing list. If tweeter is your thing we also do announce @netdev01 The official 0x13 website is at: https://www.netdevconf.org/0x13 cheers, jamal _______________________________________________ people mailing list people(a)netdevconf.org https://lists.netdevconf.org/cgi-bin/mailman/listinfo/people

1 0

OpenFabric now included in FRR
by Christian Franke 17 Sep '18

17 Sep '18

All - I'm glad to announce the merging of OpenFabric (PR #2875 https://github.com/FRRouting/frr/pull/2875) into master. OpenFabric (https://tools.ietf.org/html/draft-white-openfabric-06) is one of the solutions provided for the currently ongoing effort in the IETF to develop routing protocols which cope well with densely connected topologies like spine-leaf and clos. For those topologies, established routing protocols often run into scaling issues because of large fan-out and the high degree of interconnection. OpenFabric is based on IS-IS. To improve the scaling properties, it uses a more optimized flooding algorithm which reduces the number of LSPs exchanged in the network to the minimum required to update all nodes. To to test FRR's implementation of OpenFabric, just build and run fabricd with a configuration as following: > ! > interface lo > ip address 100.0.1.1/32 > ip router openfabric 1 > ipv6 address 2001:db8:64::1:1/128 > ipv6 router openfabric 1 > openfabric passive > ! > interface eth0 > ip router openfabric 1 > ipv6 router openfabric 1 > ! > [...] > ! > interface ethX > ip router openfabric 1 > ipv6 router openfabric 1 > ! > router openfabric 1 > net 49.0001.0001.0001.00 > ! All Best, Chris

1 0

Nominate a couple people to be maintainers
by Donald Sharp 12 Sep '18

12 Sep '18

All - I would like to nominate both Sri Mohana and Mark Stapp to be maintainers to the FRR project. Both these individuals have contributed code as well as time spent reviewing new code coming in. thanks! donald

1 0

Slack invitation request
by Srinivas K 12 Sep '18

12 Sep '18

Hello, Can I please request an invitation to the public FRR Slack Channel? Kind Regards Srini

2 1

Re: [dev] [FRRouting/frr] Static blackhole route does not honor distance attribute (#2230)
by Jia Chen 11 Sep '18

11 Sep '18

Just a question, Should configured distance be considered by Zebra/RTM stage rather than inside of BGP best path selection. If BGP best path selection need to be influenced, why using weight, local preference etc not enough? In another note, the deterministic behavior, are we talking about ordered/prioritized FIB downloading depending on route types? Thanks, Jay Configured distance From: dev <dev-bounces(a)lists.frrouting.org> on behalf of Mohan Singamsetty <msingamsetty(a)vmware.com> Date: Monday, September 10, 2018 at 9:40 AM To: Donald Sharp <sharpd(a)cumulusnetworks.com>, "ntriantafillis(a)gmail.com" <ntriantafillis(a)gmail.com>, FRRouting-Dev <dev(a)lists.frrouting.org>, Don Slice <dslice(a)cumulusnetworks.com>, Russ White <russ(a)riw.us> Subject: Re: [dev] [FRRouting/frr] Static blackhole route does not honor distance attribute (#2230) We had this meeting to discuss issue #2230 and conclude on the fix. Date: 09-05-2018 Attendees: Donald, Nikos, Don, Mohan, Soman. Minutes: 1. Two issues were discussed. * FRR stack not being deterministic in downloading routes to RIB/FIB and the routes downloaded to RIB/FIB depends on sequence of commands executed or sequence of network events happened. Ideally the routes in RIB/FIB should be deterministic and consistent at a given time after executing set of same commands. * FRR stack not honoring the admin distance configured for routes and downloading routes with higher admin distance (higher in numerical value). Ideally routes with lower admin distances should be considered as best routes and should get downloaded to RIB/FIB. 2. Two Proposals were considered. * Consider admin distance configured for each route in BGP best bath algorithm to make FRR stack behave more deterministic and consistent with respect to downloading routes to RIB/FIB. * Use route maps to control the routes to be downloaded to RIB/FIB depending on the requirement and use case. Conclusion: 1. It was concluded that the FRR stack behavior should be deterministic even without using any route maps (without any additional configuration from user). 2. Team agreed to use proposal #1 (Using the admin distance of route/protocol inside the BGP best path algorithm to determine the best route) to move forward and address the above issues mentioned. 3. Admin distance will be the first thing to compare in FRR best bath path algorithm. This is in addition to the other 13 checks that FRR stack currently has. 4. There will be a #def to control the default behavior from build time. i.e. either to have the old behavior where admin distance of each route is not used inside the BGP best path algorithm or to have new behavior where admin distance is used inside BGP best path algorithm to fix the above issue. User can use this #def to build the FRR stack and get the default behavior that is needed. 5. There will be a CLI command also to control the default behavior as explained above. We will publish the design and start implementing this soon. Guys, please add more if I missed to add anything here. Thanks, Mohan From: Mohan Singamsetty <msingamsetty(a)vmware.com> Date: Tuesday, September 4, 2018 at 10:15 AM To: Donald Sharp <sharpd(a)cumulusnetworks.com>, "ntriantafillis(a)gmail.com" <ntriantafillis(a)gmail.com>, FRRouting-Dev <dev(a)lists.frrouting.org> Subject: Re: [FRRouting/frr] Static blackhole route does not honor distance attribute (#2230) I am setting up a meeting to discuss this further on Wednesday (5th September) at 8 AM PST. Link for the bug and comments https://github.com/FRRouting/frr/issues/2230<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FRRouting_f…> Donald, Nikos, Russ, Please let me know if this time works for you. If anyone else is interested to join, please let me know and I will add you to the meeting. Thanks, Mohan From: David Lamparter <notifications(a)github.com> Reply-To: FRRouting/frr <reply+009b114fa2e0109bec00750471786212a516d3548fe6032192cf0000000117a665b892a169ce133f1a52(a)reply.github.com> Date: Tuesday, September 4, 2018 at 8:24 AM To: FRRouting/frr <frr(a)noreply.github.com> Cc: Mohan Singamsetty <msingamsetty(a)vmware.com>, Comment <comment(a)noreply.github.com> Subject: Re: [FRRouting/frr] Static blackhole route does not honor distance attribute (#2230) => meeting this week => rough consensus on call is that deterministic behaviour is desired — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protect…>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protect…>.

2 1

Re: [dev] Dataplane API
by Donald Sharp 10 Sep '18

10 Sep '18

I actually agree with both Vincent and Lou :) The current paradigm is a kernel based infrastructure and will be so for the foreseeable future. So if you are doing development *now* I would highly recommend working towards this paradigm. So Vincent is correct. Having said that, we are looking towards more formally defining the DataPlane API so that it becomes possible to allow a fully implemented dataplane api that if someone wanted to implement non-kernel based interfaces they could. So Lou is correct too! There is a lot of work here though, mainly of a infrastructure updates. I've currently (slowly) started trying to define this api( See https://github.com/FRRouting/frr/pull/2292 ). The current api line for the dataplane is fuzzy at best and lots of assumptions are made about behavior and how data structures are created. This line must be wedged apart as a first step. If you are unsure where to start here, please ask and we'll have suggestions. We also have additional goals for zebra such as true pthreads and nexthop-group route entry indirection to name a few. Please note we are not doing this work specifically to allow a full dataplane outside of a kernel, it should fall out if I do the work correctly for what I am interested in. I am doing this work because I think this work will allow me to do some work with route-aggregation as well as more efficiently pass data to the kernel for route installs. I'm sure other people have their own reasons, just as long as we keep those in mind and work together. thanks! donald On Tue, May 29, 2018 at 3:04 PM, Jay Chen <jchen1(a)paloaltonetworks.com> wrote: > A quick question about FRR interfaces. The Zebra get interface information/status from Kernel. > > In our platform, it is almost impossible to put interface into kernel (due to history reasons people object to do so). Is there anyone else facing the same situation and any suggestions for a work around? Or anything similarly to FPM existing for interface to bypass kernel (from interface manager to Zebra instead)? > > Thanks, > Jay > >

5 12

Re: [dev] [FRRouting/frr] Static blackhole route does not honor distance attribute (#2230)
by Mohan Singamsetty 10 Sep '18

10 Sep '18

I am setting up a meeting to discuss this further on Wednesday (5th September) at 8 AM PST. Link for the bug and comments https://github.com/FRRouting/frr/issues/2230 Donald, Nikos, Russ, Please let me know if this time works for you. If anyone else is interested to join, please let me know and I will add you to the meeting. Thanks, Mohan From: David Lamparter <notifications(a)github.com> Reply-To: FRRouting/frr <reply+009b114fa2e0109bec00750471786212a516d3548fe6032192cf0000000117a665b892a169ce133f1a52(a)reply.github.com> Date: Tuesday, September 4, 2018 at 8:24 AM To: FRRouting/frr <frr(a)noreply.github.com> Cc: Mohan Singamsetty <msingamsetty(a)vmware.com>, Comment <comment(a)noreply.github.com> Subject: Re: [FRRouting/frr] Static blackhole route does not honor distance attribute (#2230) => meeting this week => rough consensus on call is that deterministic behaviour is desired — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>.

2 2

master git history rewound by 1 commit
by David Lamparter 10 Sep '18

10 Sep '18

Hi all, due to a mistaken merge yesterday evening EDT (about 15 hours ago), we've rewound the history to plop that one topmost commit off. We're currently waiting to see whether this causes nontrivial problems for anyone, so if you have any issues please send an e-mail or speak up on Slack. If it does cause issues, we'll re-push the ill-fated merge commit and do the revert on top of that. Apologies for any inconveniences caused, -David

1 0

New Defects reported by Coverity Scan for freerangerouting/frr
by scan-admin＠coverity.com 09 Sep '18

09 Sep '18

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. 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 2 of 2 defect(s) ** CID 1473286: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 1473286: Memory - corruptions (OVERRUN) /isisd/isis_spf.c: 1070 in isis_spf_loop() 1064 add_to_paths(spftree, vertex); 1065 if (!VTYPE_IS(vertex->type)) 1066 continue; 1067 1068 lsp = lsp_for_vertex(spftree, vertex); 1069 if (!lsp) { >>> CID 1473286: Memory - corruptions (OVERRUN) >>> Overrunning array "vertex->N.id" of 7 bytes by passing it to a function which accesses it at byte offset 7. 1070 zlog_warn("ISIS-Spf: No LSP found for %s", 1071 rawlspid_print(vertex->N.id)); /* FIXME */ 1072 continue; 1073 } 1074 1075 isis_spf_process_lsp(spftree, lsp, vertex->d_N, vertex->depth, ** CID 1473285: Null pointer dereferences (FORWARD_NULL) /isisd/isis_lsp.c: 1909 in lsp_tick() ________________________________________________________________________________________________________ *** CID 1473285: Null pointer dereferences (FORWARD_NULL) /isisd/isis_lsp.c: 1909 in lsp_tick() 1903 lsp = NULL; 1904 dict_delete_free(area->lspdb[level], 1905 dnode); 1906 } 1907 1908 if (fabricd_init_c) { >>> CID 1473285: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "lsp". 1909 fabricd_sync_incomplete |= 1910 ISIS_CHECK_FLAG(lsp->SSNflags, 1911 fabricd_init_c); 1912 } 1913 } 1914 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

BGP Views
by Donald Sharp 07 Sep '18

07 Sep '18

In today's technical meeting we discussed removing the ability to have views as an option in bgp. Before we do any such thing we decided to poll the community to see if anyone is using views and if so what is the use case that they are using them under. So if you have any insight into this we would love to hear from you! Thanks! donald

4 5