July 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 11 Sep '18

11 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

[PATCH] bgpd: fix show ip bgp summary json command for dynamicPeers
by Dongling Duan 27 Jul '18

27 Jul '18

Signed-off-by: Dongling Duan <dlduan(a)amazon.com> --- bgpd/bgp_vty.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bgpd/bgp_vty.c b/bgpd/bgp_vty.c index 2acf39a..27d4f7a 100644 --- a/bgpd/bgp_vty.c +++ b/bgpd/bgp_vty.c @@ -7909,9 +7909,11 @@ static int bgp_show_summary(struct vty *vty, struct bgp *bgp, int afi, int safi, if (use_json) { json_peer = json_object_new_object(); - if (peer_dynamic_neighbor(peer)) + if (peer_dynamic_neighbor(peer)) { + dn_count++; json_object_boolean_true_add(json_peer, "dynamicPeer"); + } if (peer->hostname) json_object_string_add(json_peer, "hostname", -- 2.7.3.AMZN

1 0

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

27 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

[PATCH] bgpd: fix show ip bgp summary json command for dynamicPeers
by Dongling Duan 27 Jul '18

27 Jul '18

Signed-off-by: Dongling Duan <dlduan(a)amazon.com> --- bgpd/bgp_vty.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/bgpd/bgp_vty.c b/bgpd/bgp_vty.c index 2acf39a..27d4f7a 100644 --- a/bgpd/bgp_vty.c +++ b/bgpd/bgp_vty.c @@ -7909,9 +7909,11 @@ static int bgp_show_summary(struct vty *vty, struct bgp *bgp, int afi, int safi, if (use_json) { json_peer = json_object_new_object(); - if (peer_dynamic_neighbor(peer)) + if (peer_dynamic_neighbor(peer)) { + dn_count++; json_object_boolean_true_add(json_peer, "dynamicPeer"); + } if (peer->hostname) json_object_string_add(json_peer, "hostname", -- 2.7.3.AMZN

1 0

Error trying to install frrouting on Ubuntu14
by Fabio Zaccantte 26 Jul '18

26 Jul '18

Hi there, I'm trying to install frrouting on Ubuntu12 and Ubuntu14 through https://github.com/FRRouting/frr.git and i always end up with the error below. ubuntu@ubuntu-vm:~/git/frr/vtysh$ sudo /etc/init.d/frr start Loading capability module if not yet done. Starting Frr daemons (prio:10):.1024 zebra (binary does not exist).1024 bgpd (binary does not exist).1024 ripd (binary does not exist).1024 ripngd (binary does not exist).1024 ospfd (binary does not exist).1024 ospf6d (binary does not exist).1024 isisd (binary does not exist). Starting Frr monitor daemon:1024 watchfrr/sbin/start-stop-daemon: unable to stat /usr/lib/frr/watchfrr (No such file or directory) ubuntu@ubuntu-vm:~/git/frr/vtysh$ Could someone please help me. Regards, Fabio

2 3

MPLS SWAP and POP configuration issue
by Vijayalakshmi 23 Jul '18

23 Jul '18

Hello, We are currently working with simulating a PE router in MPLS architecture. We run zebra and ldp with below configuration and facing issues in swapping and popping of label in zebra. In my MPLS table I have the following entries, zebra_2# show mpls table Inbound Outbound Label Type Nexthop Label -------- ------- --------------- -------- 16 LDP 192.168.100.2 3 17 Static 192.168.100.2 18 But still zebra is not swapping the label and also not forwarding the received traffic (inbound label 16/17) to the respective nexthop. Is there any special command to activate mpls configuration ? Can someone help us in a configuring zebra MPLS to pop label and swap label? Thanks, Vijayalakshmi

3 6

Re: [dev] [102attendees] Open source routing @ ietf meetup
by Paulo Mendes 19 Jul '18

19 Jul '18

Dear Lou, Although I cannot attend IETF102 in Montreal, I would like to bring to your attention the implementation that we have been doing at COPELABS of DABBER, an information-centric networking routing for opportunistic wireless networks. DABBER was presented at the ICNRG meeting in IETF101 London, based on the draft draft-mendes-icnrg-dabber-00: https://tools.ietf.org/html/draft-mendes-icnrg-dabber-00 <https://tools.ietf.org/html/draft-mendes-icnrg-dabber-00> First version of DABBER is already available for Android. It was implemented based on a new branch of Named-Data Networking for Android, called NDN-OPP (also developed at COPELABS). You can find the open source code in GitHub: - DABBER: https://github.com/COPELABS-SITI/ndn-opp/tree/dabber <https://github.com/COPELABS-SITI/ndn-opp/tree/dabber> - NDN-OPP: https://github.com/COPELABS-SITI/ndn-opp <https://github.com/COPELABS-SITI/ndn-opp> NDN-OPP (with Dabber) is also available on Google Play: https://play.google.com/store/apps/details?id=pt.ulusofona.copelabs.ndn <https://play.google.com/store/apps/details?id=pt.ulusofona.copelabs.ndn> This work was already presented in ACM Mobisys 2018 and ACM ICN 2017: - Miguel Tavares, Omar Aponte, Paulo Mendes, "Named-data Emergency Network Services", in ACM MOBISYS, Munich, Germany, June 2018. - Seweryn Dynerowicz, Paulo Mendes, "Named-Data Networking in Opportunistic Networks", in ACM ICN, Berlin, Germany, September 2017. Although I cannot join the planned gathering at Montreal, I’m available to answer any questions that may pop up about DABBER. Melhores Cumprimentos / Best Regards / Mit freundlichen Grüßen ------------------------------------------------ Paulo Mendes, Ph.D Coordinator SITI group @ COPELABS (http://siti.ulusofona.pt) Director of NEMPS PhD program (http://nemps.ulusofona.pt <http://nemps.ulusofona.pt/>) Associated Professor at University Lusofona, Portugal http://www.paulomilheiromendes.com <http://www.paulomilheiromendes.com/> Tel: +351 217 50 50 22 > -------- Forwarded Message -------- > Subject: [102attendees] Open source routing @ ietf meetup > Date: Mon, 16 Jul 2018 07:51:17 -0400 > From: Lou Berger <lberger(a)labn.net> <mailto:lberger@labn.net> > To: quagga-dev(a)lists.quagga.net <mailto:quagga-dev@lists.quagga.net> <quagga-dev(a)lists.quagga.net> <mailto:quagga-dev@lists.quagga.net>, 102attendees(a)ietf.org <mailto:102attendees@ietf.org>, FRRouting-Dev<dev(a)lists.frrouting.org> <mailto:dev@lists.frrouting.org>, quagga-users <quagga-users(a)lists.quagga.net> <mailto:quagga-users@lists.quagga.net>, bird-users(a)network.cz <mailto:bird-users@network.cz>, sonicproject(a)googlegroups.com <mailto:sonicproject@googlegroups.com> > > 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-flo <https://datatracker.ietf.org/meeting/102/floor-plan#2nd-flo>or-convention-floor-2 <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 <mailto:102attendees@ietf.org> > > https://www.ietf.org/mailman/listinfo/102attendees <https://www.ietf.org/mailman/listinfo/102attendees> > > > > _______________________________________________ > 102attendees mailing list > 102attendees(a)ietf.org <mailto:102attendees@ietf.org> > https://www.ietf.org/mailman/listinfo/102attendees <https://www.ietf.org/mailman/listinfo/102attendees>

1 1

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

19 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