- dev - lists.frrouting.org

Multiple FRR installs and the damage done.
by Donald Sharp 18 Jul '18

18 Jul '18

All - Just wanted to document a little bit of a mis-config that I frequently self-inflict with and have just helped another person resolve. When you run one of the daemons, or run vtysh and get this type of message: root@dev:~/frr# vtysh vtysh: Symbol `frr_vtydir' has different size in shared object, consider re-linking Exiting: failed to connect to any daemons. root@dev:~/frr# This means that you have managed to install FRR into 2 different locations. How you say? I've seen it from 2 different methodologies: 1) I've run `./configure ..`, `make` and `make install` 2 times. With the first and second configure line being different. I am now fairly paranoid about this issue and double check my configure line. 2) I've installed FRR from packaging (a .deb or .rpm ) and then run `./configure ....` line that installs FRR into a different spot. How to clean this mess up? In the undesired set of paths you need to clean up the FRR install, this includes the lib directories. I do this with manual `find /path -name ... | xargs rm -rf`. I'm sure someone more clever than myself knows how to do this with `make` but I have not experimented with this. donald

6 7

Maintainers
by Donald Sharp 18 Jul '18

18 Jul '18

All - We've gone over the maintainers and have made a couple of changes. To whit we have added Paul Ziemba and Pascal Mathis to our maintainers and will be dropping Nicholas Dichtel. Bingen Eguzkitza Jafar Al-Gharaibeh Lou Berger Olivier Dugeon Christian Franke Philippe Guibert Vincent Jardin David Lamparter Pascal Mathis JR Rivers Donnie Savage Donald Sharp Daniel Walton Renato Westhphal Russ White Martin Winter Quentin Young Rafael Zalamena Paul Ziemba I'll be getting the website updated over the next couple of days to reflect the reality on the ground. Thanks donald

1 0

Open source routing @ ietf meetup
by Lou Berger 16 Jul '18

16 Jul '18

yikes - this isn't a bof or anything more than what we've done at the IETF since berlin... Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to Square Dorchester [1] at today's lunch break. There is no agenda or slides. Please feel free to bring a topic that you'd like to discuss or just come and listen. Lou [1] https://datatracker.ietf.org/meeting/102/floor-plan#2nd-floor-convention-fl… On 7/15/2018 1:48 PM, Alistair Woodman wrote: > All, > > An open invite to all interested in open source routing projects. > > We intend to meet Monday lunchtime. More details to follow... > > /a > > _______________________________________________ > 102attendees mailing list > 102attendees(a)ietf.org > https://www.ietf.org/mailman/listinfo/102attendees >

2 1

Open Source Routing at IETF
by Donald Sharp 16 Jul '18

16 Jul '18

All - A few of us are at IETF in Montreal, and if you are too, please feel free to come on down to `Square Dorchester` at noon for a quick get together. cya then! donalnd

1 0

question
by Daniel Guerri 03 Jul '18

03 Jul '18

Dears Im new in FRR routing tool set and Im trying to install it on my UBUNTU server machine. Can you provide me with a step by step to install it. Best Regards Daniel

4 3

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