June 2018 - dev - lists.frrouting.org

FRR on NRL CORE (fyi)
by Phil Wiggins 22 Aug '19

22 Aug '19

If anyone is interested in running FRR in the NRL CORE emulation environment, I have some build scripts for FRR on CORE that I posted at the first link below. Normally CORE runs Quagga, so this script was a hack to shoehorn FRR as a Quagga replacement. These scripts are not part of CORE yet, so are unsupported. People on this list may want to use CORE for FRR experimentation and testing, so you can customize these scripts to suit your own needs. It's best to run this stuff in a VM with no internet connection (after installation) since CORE runs lots of processes as root - a well-known security issue. https://github.com/coreemu/core/issues/170 ( install_frr_for_core.sh) FRR on NRL CORE build script - assumes Ubuntu 16.04.4 clean installation in a VM or physical host: https://gist.github.com/apwiggins/44f3592a61965783372aea5881ed9f7a (core_misc_frr.py ) used by the install script above to install at ./core/misc/frr.py https://gist.github.com/apwiggins/d610c2794c8c0a12a45bfc093fd2e949 (core_services_frr.py) used by the install script above to install at ./core/services/frr.py https://gist.github.com/apwiggins/747a9a14feff2ce3a3b8760406b825a7 https://www.nrl.navy.mil/itd/ncs/products/core The Common Open Research Emulator (CORE) is a tool for emulating networks on one or more machines. You can connect these emulated networks to live networks. CORE consists of a GUI for drawing topologies of lightweight virtual machines, and Python modules for scripting network emulation. Cheers, Phil

3 6

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

no soft bgp clear is triggered on modification to prefixlist / routemap
by François 02 Aug '18

02 Aug '18

Hello, This issue has been discussed here : https://github.com/FRRouting/frr/issues/126 To sum up, when a route-map is modified (tried 2 things: adding a new entry and modifying prefix-list involved), no soft bgp clear is performed, so it looks like other peers never get new results (the "show advertised route" output is correct). Looks like "no route-map ... " and "route-map ..." again does the trick. My question is: do someone has an idea on how to fix that? I can give a shot, but I would appreciate some inputs ;) Ps: I use version 2 of FRR (because Vincent Jardin told that version 3 was not production ready at FRNog 29 ;)) Thanks! -- François

3 6

Fwd: FW: FRRouting - RIP VRF Support.
by Amit Tiwari 26 Jul '18

26 Jul '18

Hi Kunihiro, I have compiled FRRouting master branch and deployed it on my router, bgp and ospf are working fine with vrf. Whereas, in case of RIP, vrf doesn't seems to be working, there is no vrf support even at CLI level. May we know, when are you guys releasing frrouting with full vrf support in RIP. Regards, Amit Kumar Tiwari 9953769181

3 2

Current Maintainers
by Donald Sharp 01 Jul '18

01 Jul '18

All - This is the current list of maintainers: - Jafar Al-Gharaibeh - [@jafarl](https://github.com/jafaral) - Lou Berger - [@louberger](https://github.com/louberger) - Nicolas Dichtel [@nicolasdichtel](https://github.com/nicolasdichtel) - Olivier Dugeon - [@odd22](https://github.com/odd22) - Bingen Eguzkitza - [@bingen](https://github.com/bingen) - Christian Franke - [@cfra](https://github.com/cfra) - Philippe Guibert - [@pguibert6WIND](https://github.com/pguibert6WIND) - Vincent Jardin - [@vjardin6WIND](https://github.com/vjardin6WIND) - David Lamparter - [@eqvinox](https://github.com/eqvinox) - JR Rivers - [@jrrivers](https://github.com/jrrivers) - Donnie Savage - [@diivious](https://github.com/diivious) - Donald Sharp - [@donaldsharp](https://github.com/donaldsharp) - Daniel Walton [@dwalton76](https://github.com/dwalton76) - Renato Westphal - [@rwestphal](https://github.com/rwestphal) - Russ White - [@riw777](https://github.com/riw777) - Martin Winter - [@mwinter-osr](https://github.com/mwinter-osr) - Quentin Young - [@qlyoung](https://github.com/qlyoung) - Rafael Zalamena - [@rzalamena](https://github.com/rzalamena) If you would like to nominate yourself or someone else, please do so. I would like to discuss this at the next technical meeting. thanks! donald

2 2

FRR vrf, multi-instance
by Jia Chen 29 Jun '18

29 Jun '18

Hi All, A question about FRR way of supporting vrf, multi-instance, or logical router. A. OSPF/IS-IS multi-instance is a control plane concept, not forwarding B. VRF is both routing and forwarding, for example, L3vpn and EVPN, which uses RT, RD in BGP updates C. Virtual router is a non-VPN instance, which does not require RT, RD Both B and C, has a one-to-one interface to routing instance mapping. Are A, B, C all supported by FRR? Juniper has a logical system (or router), which divided physical router into logical sub-routers. Each logical router has dedicated interface, routing protocols, routing and forwarding table. Are there equivalent in FRR? Thanks, Jay On 6/28/18, 9:31 AM, "dev on behalf of Donald Sharp" <dev-bounces(a)lists.frrouting.org on behalf of sharpd(a)cumulusnetworks.com> wrote: Mark - Great idea, We'll start the meeting off with your talk. thanks! donald On Thu, Jun 28, 2018 at 11:58 AM, Mark Stapp <mjs(a)voltanet.io> wrote: > Hi, > I've been doing some work on the dataplane side of zebra, and I'd like to > talk a bit about the approach and outline some of the possible next-steps. > Could I have a few minutes at next week's dev meeting to introduce the > topic? The broad goals are sort of: > > * to harden the interface that zebra has with the dataplane or -planes that > are in use, > * to improve support for remote dataplanes, > * to allow dataplane/kernel updates to be moved to a dedicated pthread, > * to improve integration of FPM, and to include more events > > I've been working at first just to support asynchronous route/fib updates, > just to start exploring the possible approaches and to raise some questions. > > Thanks, > Mark > > _______________________________________________ > dev mailing list > dev(a)lists.frrouting.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_li… > _______________________________________________ dev mailing list dev(a)lists.frrouting.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_li…

3 5

intro asynch zebra work
by Mark Stapp 28 Jun '18

28 Jun '18

Hi, I've been doing some work on the dataplane side of zebra, and I'd like to talk a bit about the approach and outline some of the possible next-steps. Could I have a few minutes at next week's dev meeting to introduce the topic? The broad goals are sort of: * to harden the interface that zebra has with the dataplane or -planes that are in use, * to improve support for remote dataplanes, * to allow dataplane/kernel updates to be moved to a dedicated pthread, * to improve integration of FPM, and to include more events I've been working at first just to support asynchronous route/fib updates, just to start exploring the possible approaches and to raise some questions. Thanks, Mark

2 1

Recursive lookup through BGP-LU route
by Carl Baldwin 26 Jun '18

26 Jun '18

Hi, We're experimenting with BGP-LU and frr in our lab. We have two host machines running frr. Each is connected to two TOR switches through their eth0 and eth1 links (four TORs total). Those are connected through another pair of switches. We have configured BGP-LU to distribute MPLS labels over ebpg throughout. Connectivity between loopback addresses on the two hosts works well at this point. Then, I created some namespaces in the hosts and gave them addresses. We use BGP to announce those addresses as /32 routes with the loopback address as the next hop. The route between namespaces on the two machines is recursively resolved so that they push the same MPLS label as the path to the other loopback. This all works well to start off with and we did some iperf runs that showed pretty good results. ECMP was working because the bandwidth was higher than any single link. After some link state changes, we seemed to lose the connection. However, pings between the loopback addresses still worked. After some time, we noticed that the MPLS labels in the routes to the namespace addresses (/32s) were different than the label in the route to the loopback. Since the former routes are resolved recursively using the latter, the labels should always be the same. Could this be a bug in FRR? Shouldn't the routes to the namespaces be invalidated or updated as soon as the route it was based on changed? The traffic between namespaces is getting dropped because the switch doesn't know about the label being pushed by the host. Any insight would be very helpful. Thanks! Carl Baldwin Here are /32 routes received. 10.112.128.1 is the loopback on the other host. The four routes are to four namespaces on the other host. lab1r2u05# show ip bgp neighbor 10.112.97.1 received-routes BGP table version is 0, local router ID is 10.112.128.2 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.224.12.10/32 10.112.128.1 0 4206900001 4206909998 i *> 10.224.12.15/32 10.112.128.1 0 4206900001 4206909998 i *> 10.224.12.70/32 10.112.128.1 0 4206900001 4206909998 i *> 10.224.12.75/32 10.112.128.1 0 4206900001 4206909998 i Total number of prefixes 4 Below is the routing table as it looked when we lost connectivity. Notice that the mpls label for the loopback route is 306592 via eth1 but the label for the four namespace addresses is 306576. root@lab1r2u05:~/ovs-droplets# ip route default via 10.112.2.132 dev eth2 10.112.2.128/25 dev eth2 proto kernel scope link src 10.112.2.145 10.112.128.1 encap mpls 306592 via 10.112.129.9 dev eth1 proto 186 metric 20 10.112.129.8/30 dev eth1 proto kernel scope link src 10.112.129.10 10.112.129.12/30 dev eth0 proto kernel scope link src 10.112.129.14 10.224.12.10 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.15 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.70 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.75 encap mpls 306576 via 10.112.129.9 dev eth1 proto 186 metric 20 10.224.12.20 dev br0 scope link 10.224.12.25 dev br0 scope link 10.224.12.80 dev br0 scope link 10.224.12.85 dev br0 scope link

2 3

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

22 Jun '18

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. 28 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 1470150: Null pointer dereferences (NULL_RETURNS) /lib/command.c: 2474 in command_setup_early_logging() ________________________________________________________________________________________________________ *** CID 1470150: Null pointer dereferences (NULL_RETURNS) /lib/command.c: 2474 in command_setup_early_logging() 2468 if (strcmp(dest, "syslog") == 0) { 2469 zlog_set_level(ZLOG_DEST_SYSLOG, zlog_default->default_lvl); 2470 return; 2471 } 2472 2473 token = strstr(dest, ":"); >>> CID 1470150: Null pointer dereferences (NULL_RETURNS) >>> Incrementing a pointer which might be null: "token". 2474 token++; 2475 2476 set_log_file(NULL, token, zlog_default->default_lvl); 2477 } 2478 2479 DEFUN (config_log_file, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

NetDev0x12 conference
by Donald Sharp 21 Jun '18

21 Jun '18

All - Just wanted to let everyone know that there is an upcoming NetDev conference in mid July: https://netdevconf.org/0x12/accepted-sessions.html I'll be presenting there and there will be a lot of people from the linux networking community at this conference. If you are interested check it out! donald

2 1