August 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

FRR support for FPM
by Tiwari, Mayank (Contractor) 20 Sep '18

20 Sep '18

Hi, We are using quagga in our solution for FPM connection and Reverse FPM connection with ONOS. In order to support BFD feature I need to upgrade from quagga to FRR. For that I was patching the changes present in quagga to FRR. During that patching process the following patch is causing compilation issue: diff --git a/zebra/zebra_vty.c b/zebra/zebra_vty.c index 43d76a6..03c4a6b 100644 --- a/zebra/zebra_vty.c +++ b/zebra/zebra_vty.c @@ -20,6 +20,7 @@ #include <zebra.h> +#include "zebra_fpm.h" #include "memory.h" #include "zebra_memory.h" #include "if.h" + +/* function to write the fpm config info */ +static int config_write_fpm (struct vty *vty) +{ + return fpm_remote_srv_write (vty); +} + +/* Zebra node */ +static struct cmd_node zebra_node = +{ + ZEBRA_NODE, + "", + 1 +}; /* Route VTY. */ void zebra_vty_init(void) { /* Install configuration write function. */ install_node(&table_node, config_write_table); install_node(&forwarding_node, config_write_forwarding); + install_node (&zebra_node, config_write_fpm); install_element(VIEW_NODE, &show_ip_forwarding_cmd); install_element(CONFIG_NODE, &ip_forwarding_cmd); diff --git a/zebra/zebra_fpm.h b/zebra/zebra_fpm.h new file mode 100644 index 0000000..9291ffa --- /dev/null +++ b/zebra/zebra_fpm.h @@ -0,0 +1,35 @@ +/* + * Router ID for zebra daemon. + * + * Copyright (C) 2004 James R. Leu + * + * This file is part of Quagga routing suite. + * + * Quagga is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * Quagga is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; see the file COPYING; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _ZEBRA_VTY_H_ +#define _ZEBRA_VTY_H_ + +#include <zebra.h> +#include "memory.h" +#include "prefix.h" +#include "zclient.h" +#include "if.h" + + +static int fpm_remote_srv_write (struct vty *vty ); + +#endif The function 'fpm_remote_srv_write' is already defined in zebra_fpm.c file which I need to use zebra_vty.c file. I have created a header with name zebra_fpm.h and declared that function there and later included this header in zebra_vty.c. The compilation of zebra_vty.c fails as it is not able to find 'fpm_remote_srv_write' function This is the compilation error: CCLD zebra/zebra_irdp.la CC zebra/zebra_fpm.lo CC zebra/zebra_fpm_netlink.lo ..... ..... CC zebra/zebra_vty.o In file included from zebra/zebra_vty.c:23:0: zebra/zebra_fpm.h:33:12: warning: 'fpm_remote_srv_write' used but never defined static int fpm_remote_srv_write (struct vty *vty ); ^ CC zebra/zebra_vxlan.o CC zebra/zserv.o CC zebra/zebra_netns_id.o CC zebra/zebra_netns_notify.o CC zebra/table_manager.o CC zebra/zapi_msg.o CCLD zebra/zebra zebra/zebra_vty.o: In function `config_write_fpm': /frr/zebra/zebra_vty.c:3697: undefined reference to `fpm_remote_srv_write' collect2: error: ld returned 1 exit status make[2]: *** [zebra/zebra] Error 1 Makefile:3246: recipe for target 'zebra/zebra' failed make[2]: Leaving directory '/frr' Makefile:4421: recipe for target 'all-recursive' failed make[1]: Leaving directory '/frr' make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 I have observed that zebra_fpm.c is compiled as zebra_fpm.lo instead of zebra_fpm.o. I am not sure if that can cause this issue. Please suggest what I am missing here and what approach I need to take to fix this issue. Thanks and Regards, Mayank

3 3

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

duplicate frr in source tar name
by Michal Ruprich 31 Aug '18

31 Aug '18

Hi, is there any specific reason for naming every source file frr-frr-x.y.z? Why using the name frr twice? Regards, Michal Ruprich

2 3

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

30 Aug '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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1473090: Incorrect expression (NO_EFFECT) /lib/frr_pthread.c: 335 in fpt_run() ________________________________________________________________________________________________________ *** CID 1473090: Incorrect expression (NO_EFFECT) /lib/frr_pthread.c: 335 in fpt_run() 329 int sleeper[2]; 330 pipe(sleeper); 331 thread_add_read(fpt->master, &fpt_dummy, NULL, sleeper[0], NULL); 332 333 fpt->master->handle_signals = false; 334 >>> CID 1473090: Incorrect expression (NO_EFFECT) >>> Comparing an array to null is not useful: "fpt->os_name", since the test will always evaluate as true. 335 if (fpt->os_name) 336 frr_pthread_set_name(fpt, NULL, fpt->os_name); 337 338 frr_pthread_notify_running(fpt); 339 340 struct thread task; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

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

29 Aug '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. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1473088: Memory - corruptions (INTEGER_OVERFLOW) /lib/ferr.c: 151 in log_ref_display() ________________________________________________________________________________________________________ *** CID 1473088: Memory - corruptions (INTEGER_OVERFLOW) /lib/ferr.c: 151 in log_ref_display() 145 char pbuf[256]; 146 char ubuf[256]; 147 148 snprintf(pbuf, sizeof(pbuf), "\nError %"PRIu32" - %s", 149 ref->code, ref->title); 150 memset(ubuf, '=', strlen(pbuf)); >>> CID 1473088: Memory - corruptions (INTEGER_OVERFLOW) >>> Overflowed or truncated value (or a value computed from an overflowed or truncated value) "strlen(pbuf) - 1UL" used as array index. 151 ubuf[strlen(pbuf) - 1] = '\0'; 152 153 vty_out(vty, "%s\n%s\n", pbuf, ubuf); 154 vty_out(vty, "Description:\n%s\n\n", ref->description); 155 vty_out(vty, "Recommendation:\n%s\n", ref->suggestion); 156 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

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

26 Aug '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 10 new defect(s) introduced to freerangerouting/frr found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 10 of 10 defect(s) ** CID 1473047: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8683 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473047: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8683 in route_vty_out_detail_header() 8677 vty_out(vty, 8678 ", mark translated RTs for VPNv4 route filtering"); 8679 else if (route_filter_v4) 8680 vty_out(vty, 8681 ", attach RT as-is for VPNv4 route filtering"); 8682 else if (route_filter_translated_v6) >>> CID 1473047: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", mark transl...". 8683 vty_out(vty, 8684 ", mark translated RTs for VPNv6 route filtering"); 8685 else if (route_filter_v6) 8686 vty_out(vty, 8687 ", attach RT as-is for VPNv6 route filtering"); 8688 else if (llgr_stale) ** CID 1473046: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8677 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473046: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8677 in route_vty_out_detail_header() 8671 vty_out(vty, ", no best path"); 8672 8673 if (accept_own) 8674 vty_out(vty, 8675 ", accept own local route exported and imported in different VRF"); 8676 else if (route_filter_translated_v4) >>> CID 1473046: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", mark transl...". 8677 vty_out(vty, 8678 ", mark translated RTs for VPNv4 route filtering"); 8679 else if (route_filter_v4) 8680 vty_out(vty, 8681 ", attach RT as-is for VPNv4 route filtering"); 8682 else if (route_filter_translated_v6) ** CID 1473045: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8695 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473045: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8695 in route_vty_out_detail_header() 8689 vty_out(vty, 8690 ", mark routes to be retained for a longer time. Requeres support for Long-lived BGP Graceful Restart"); 8691 else if (no_llgr) 8692 vty_out(vty, 8693 ", mark routes to not be treated according to Long-lived BGP Graceful Restart operations"); 8694 else if (accept_own_nexthop) >>> CID 1473045: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", accept loca...". 8695 vty_out(vty, 8696 ", accept local nexthop"); 8697 else if (blackhole) 8698 vty_out(vty, ", inform peer to blackhole prefix"); 8699 else if (no_export) 8700 vty_out(vty, ", not advertised to EBGP peer"); ** CID 1473044: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8689 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473044: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8689 in route_vty_out_detail_header() 8683 vty_out(vty, 8684 ", mark translated RTs for VPNv6 route filtering"); 8685 else if (route_filter_v6) 8686 vty_out(vty, 8687 ", attach RT as-is for VPNv6 route filtering"); 8688 else if (llgr_stale) >>> CID 1473044: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", mark routes...". 8689 vty_out(vty, 8690 ", mark routes to be retained for a longer time. Requeres support for Long-lived BGP Graceful Restart"); 8691 else if (no_llgr) 8692 vty_out(vty, 8693 ", mark routes to not be treated according to Long-lived BGP Graceful Restart operations"); 8694 else if (accept_own_nexthop) ** CID 1473043: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8680 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473043: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8680 in route_vty_out_detail_header() 8674 vty_out(vty, 8675 ", accept own local route exported and imported in different VRF"); 8676 else if (route_filter_translated_v4) 8677 vty_out(vty, 8678 ", mark translated RTs for VPNv4 route filtering"); 8679 else if (route_filter_v4) >>> CID 1473043: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", attach RT a...". 8680 vty_out(vty, 8681 ", attach RT as-is for VPNv4 route filtering"); 8682 else if (route_filter_translated_v6) 8683 vty_out(vty, 8684 ", mark translated RTs for VPNv6 route filtering"); 8685 else if (route_filter_v6) ** CID 1473042: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8698 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473042: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8698 in route_vty_out_detail_header() 8692 vty_out(vty, 8693 ", mark routes to not be treated according to Long-lived BGP Graceful Restart operations"); 8694 else if (accept_own_nexthop) 8695 vty_out(vty, 8696 ", accept local nexthop"); 8697 else if (blackhole) >>> CID 1473042: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", inform peer...". 8698 vty_out(vty, ", inform peer to blackhole prefix"); 8699 else if (no_export) 8700 vty_out(vty, ", not advertised to EBGP peer"); 8701 else if (no_advertise) 8702 vty_out(vty, ", not advertised to any peer"); 8703 else if (local_as) ** CID 1473041: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8692 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473041: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8692 in route_vty_out_detail_header() 8686 vty_out(vty, 8687 ", attach RT as-is for VPNv6 route filtering"); 8688 else if (llgr_stale) 8689 vty_out(vty, 8690 ", mark routes to be retained for a longer time. Requeres support for Long-lived BGP Graceful Restart"); 8691 else if (no_llgr) >>> CID 1473041: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", mark routes...". 8692 vty_out(vty, 8693 ", mark routes to not be treated according to Long-lived BGP Graceful Restart operations"); 8694 else if (accept_own_nexthop) 8695 vty_out(vty, 8696 ", accept local nexthop"); 8697 else if (blackhole) ** CID 1473040: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8686 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473040: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8686 in route_vty_out_detail_header() 8680 vty_out(vty, 8681 ", attach RT as-is for VPNv4 route filtering"); 8682 else if (route_filter_translated_v6) 8683 vty_out(vty, 8684 ", mark translated RTs for VPNv6 route filtering"); 8685 else if (route_filter_v6) >>> CID 1473040: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", attach RT a...". 8686 vty_out(vty, 8687 ", attach RT as-is for VPNv6 route filtering"); 8688 else if (llgr_stale) 8689 vty_out(vty, 8690 ", mark routes to be retained for a longer time. Requeres support for Long-lived BGP Graceful Restart"); 8691 else if (no_llgr) ** CID 1473039: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8706 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473039: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8706 in route_vty_out_detail_header() 8700 vty_out(vty, ", not advertised to EBGP peer"); 8701 else if (no_advertise) 8702 vty_out(vty, ", not advertised to any peer"); 8703 else if (local_as) 8704 vty_out(vty, ", not advertised outside local AS"); 8705 else if (no_peer) >>> CID 1473039: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", inform EBGP...". 8706 vty_out(vty, 8707 ", inform EBGP peer not to advertise to their EBGP peers"); 8708 8709 if (suppress) 8710 vty_out(vty, 8711 ", Advertisements suppressed by an aggregate."); ** CID 1473038: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8674 in route_vty_out_detail_header() ________________________________________________________________________________________________________ *** CID 1473038: Possible Control flow issues (DEADCODE) /bgpd/bgp_route.c: 8674 in route_vty_out_detail_header() 8668 ? "Default-IP-Routing-Table" 8669 : bgp->name); 8670 } else 8671 vty_out(vty, ", no best path"); 8672 8673 if (accept_own) >>> CID 1473038: Possible Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "vty_out(vty, ", accept own ...". 8674 vty_out(vty, 8675 ", accept own local route exported and imported in different VRF"); 8676 else if (route_filter_translated_v4) 8677 vty_out(vty, 8678 ", mark translated RTs for VPNv4 route filtering"); 8679 else if (route_filter_v4) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

2 1

FYI - Regarding CPP_NOTICE firing today if building w/ --enable-dev-build=yes
by Donald Sharp 24 Aug '18

24 Aug '18

If you are building w/ --enable-dev-build=yes and are seeing CPP_NOTICE's: zapi_ipv4_route, zapi_ipv6_route, zapi_ipv4_route_ipv6_nexthop as well as the zapi_ipv4 and zapi_ipv6 data structures should be removed now Please do a git pull to retrieve PR # 2901: commit 9b8c3903bdf0f681df17a532286bc717e1f607ad Merge: 529089b 0477276 Author: David Lamparter <equinox(a)diac24.net> Date: Fri Aug 24 19:41:17 2018 +0200 Merge pull request #2901 from donaldsharp/remove_zapi_deprecated Remove zapi deprecated This will go away then. The next scheduled CONFDATE is in a few days btw: ospf6d/ospf6_top.c:#if CONFDATE > 20180828 We should have something ready to go in on that date as well. donald

1 0

Continued Discussion of Error Codes for FRR
by Donald Sharp 23 Aug '18

23 Aug '18

All - In today's technical meeting we spent quite a bit of time discussing David's error code PR: https://github.com/FRRouting/frr/pull/2841 Discussion centered around understanding out what it was and how we want FRR to work with error codes. Due to time constraints we decided to continue the discussion in a new meeting. This meeting will be held on Aug 22, 9:30 am EDT tomorrow. If you are interested please let me know and I'll add you to the meeting. donald

2 4

Next Release
by Donald Sharp 23 Aug '18

23 Aug '18

All - In today's dev meeting we discussed the October release of FRR (https://github.com/FRRouting/frr/blob/master/doc/developer/workflow.rst Releases subsection ). In order to meet this deadline we will need to pull the next branch. The current plan is to do this on Aug 28. At this time we are expecting to call this release 6.0. thanks! donald

1 1