October 2018 - dev - lists.frrouting.org

Regarding support for rsvp-te support in free routing
by Rhene Kavi 20 Feb '20

20 Feb '20

Hi All, Do we have any plans to support rsvp-te Thanks in advance KaviRhene

4 3

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

Reminder/Warning: weekly call might be earlier/later in some timezones due to DST
by David Lamparter 30 Oct '18

30 Oct '18

Hi all, just a heads-up/reminder/warning: since some countries move out/in to daylight savings time, and the date and direction differs between countries. So, the weekly meeting might be at a different local time for some of us. (e.g.: it's an hour earlier this week for everyone in the EU.) For today: it's in 20 minutes! Cheers, -David

1 0

Debian packaging Python2 deprecation
by David Lamparter 27 Oct '18

27 Oct '18

Hi all, as I'm currently cleaning up the Debian packaging and trying to get it shipped, I've been asked (on Debian channels) about the python2 dependencies that we still have in the package. First of all, I've converted all of them to "python2 | python3" dependencies. Since PR#3074 [https://github.com/FRRouting/frr/pull/3074 "frr-reload.py: Python3 compatibility"], frr-reload.py should also be working correctly on Py3. However, even this is rather unwelcome in Debian, especially for "new" packages. Since all of our supported Debian-based targets (i.e. starting at Debian 8/jessie and Ubuntu 14.04) have python3, I don't see a good reason to retain python2 in our Debian packaging. If you see any such reasons, please voice them now. NB(1): this is only about the DEBIAN PACKAGING. Everything in FRR, including clippy, works with either python2 or python3 and will continue to do so. However, the Debian packages will just list python3 as a dependency. NB(2): as far as I know, Debian will stop shipping python2 in 2019. I don't know what exactly that implies (you can probably still install it somehow.) NB(3): https://python3statement.org/ NB(4): Python2 will be EOL on January 1st, 2020 [https://www.python.org/dev/peps/pep-0373/] NB(5): the "frr-pythontools" package / frr-reload.py cannot ship with a "2 or 3" dependency. It needs to choose between python2 and python3 to get the #! shebang correct. This will absolutely be Python3; that's the only viable choice from an integration perspective. Cheers, -David

1 0

Multicast Protocol
by Tamar Cohen 25 Oct '18

25 Oct '18

Hi all, My name is Tamar and I have the release 5.0.1 of the FRRouting, it is an excellent IP routing protocol suite! I try to use frr in multicast traffic. 1) Is frr support multicast traffic? (I ask because I tried without success) I write this commands: ip multicast ip pim rp IP ADDR inteface INTERFACE ip pim sm\\ in all interfaces Also I add an ospf: router ospf 1 network 0.0.0.0 0.0.0.0 area 0 my setup include tow PC and one additional router (VM of cisco) [cid:image004.jpg@01D46B90.20365000] This setup does not foreword a multicast traffic unfortunately ... 2) I try to debug the traffic in the frr with the "debug" commands but it does not print to the screen anything. In the manual [cid:image006.jpg@01D46B90.20365000] When I wrote the command I got [cid:image007.png@01D46B8F.489CADB0] Why? 3) Is the frr support pim protocol? It is written in the manual but not work in my setup I would be very grateful if you could help me with this. Thank you! Tamar [cid:image002.jpg@01D26F1D.BF96EE00] Tamar Cohen NFV SW Engineer T: +972-73-270-7625 F: +972-08-6436791 | tamar_c(a)rad.com<mailto:tamar_c@rad.com> www.rad.com<http://www.rad.com/> | Follow RAD on LinkedIn<http://www.linkedin.com/company/7369/> | Facebook<http://www.facebook.com/pages/RAD-Data-Communications/72479223117> | Twitter<http://twitter.com/raddatacomms> | YouTube<http://www.youtube.com/user/radwebmaster#g/u>

2 5

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

23 Oct '18

Hi, Please find the latest report on new defect(s) introduced to freerangerouting/frr found with Coverity Scan. 3 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 3 of 3 defect(s) ** CID 1475200: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1475200: Null pointer dereferences (FORWARD_NULL) /sharpd/sharp_vty_clippy.c: 235 in vrf_label() 229 } 230 #if 1 /* anything that can fail? */ 231 if (_failcnt) 232 return CMD_WARNING; 233 #endif 234 #endif >>> CID 1475200: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "name" to "vrf_label_magic", which dereferences it. 235 return vrf_label_magic(self, vty, argc, argv, ipv4, ipv6, name, label, label_str); 236 } 237 238 /* remove_routes => "sharp remove routes A.B.C.D$start (1-1000000)$routes [instance (0-255)$instance]" */ 239 DEFUN_CMD_FUNC_DECL(remove_routes) 240 #define funcdecl_remove_routes static int remove_routes_magic(\ ** CID 1475199: Error handling issues (CHECKED_RETURN) /pbrd/pbr_zebra.c: 364 in pbr_zebra_nexthop_update() ________________________________________________________________________________________________________ *** CID 1475199: Error handling issues (CHECKED_RETURN) /pbrd/pbr_zebra.c: 364 in pbr_zebra_nexthop_update() 358 zebra_size_t length, vrf_id_t vrf_id) 359 { 360 struct zapi_route nhr; 361 char buf[PREFIX2STR_BUFFER]; 362 uint32_t i; 363 >>> CID 1475199: Error handling issues (CHECKED_RETURN) >>> Calling "zapi_nexthop_update_decode" without checking return value (as is done elsewhere 4 out of 5 times). 364 zapi_nexthop_update_decode(zclient->ibuf, &nhr); 365 366 if (DEBUG_MODE_CHECK(&pbr_dbg_zebra, DEBUG_MODE_ALL)) { 367 368 DEBUGD(&pbr_dbg_zebra, "%s: Received Nexthop update: %s", 369 __PRETTY_FUNCTION__, ** CID 1475198: Error handling issues (CHECKED_RETURN) /sharpd/sharp_zebra.c: 226 in sharp_zebra_nexthop_watch() ________________________________________________________________________________________________________ *** CID 1475198: Error handling issues (CHECKED_RETURN) /sharpd/sharp_zebra.c: 226 in sharp_zebra_nexthop_watch() 220 { 221 int command = ZEBRA_NEXTHOP_REGISTER; 222 223 if (!watch) 224 command = ZEBRA_NEXTHOP_UNREGISTER; 225 >>> CID 1475198: Error handling issues (CHECKED_RETURN) >>> Calling "zclient_send_rnh" without checking return value (as is done elsewhere 4 out of 5 times). 226 zclient_send_rnh(zclient, command, p, true, VRF_DEFAULT); 227 } 228 229 static int sharp_nexthop_update(int command, struct zclient *zclient, 230 zebra_size_t length, vrf_id_t vrf_id) 231 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

TSC Election Results...
by Alistair Woodman 23 Oct '18

23 Oct '18

All, The following individuals were nominated by the community to stand for the 6 slots on the TSC David Lamparter Donald Sharp Martin Winter Philippe Guibert Quentin Young Russ White Because the nominees also numbered 6, their election was 'unopposed' and as such, I announce them to be the dually elected TSC Congratulations. /a

1 0

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

19 Oct '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 1474548: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1474548: Null pointer dereferences (FORWARD_NULL) /bgpd/bgp_route.c: 5795 in bgp_aggregate_route() 5789 lcommunity = lcommunity_dup( 5790 pinew->attr->lcommunity); 5791 } 5792 } 5793 } 5794 >>> CID 1474548: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "lcommunity" to "bgp_aggregate_install", which dereferences it. 5795 bgp_aggregate_install(bgp, afi, safi, p, origin, aspath, community, 5796 ecommunity, lcommunity, atomic_aggregate, 5797 aggregate); 5798 5799 if (aggregate->count == 0) { 5800 if (aspath) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

RFC 8212
by Christoffer Hansen (Lists) 18 Oct '18

18 Oct '18

dev.lists.frrouting.org, Am I correct to assume FRRouting does not yet support RFC 8212[0][1]? """ Internet Engineering Task Force (IETF) J. Mauch Request for Comments: 8212 Akamai Updates: 4271 J. Snijders Category: Standards Track NTT ISSN: 2070-1721 G. Hankins Nokia July 2017 Default External BGP (EBGP) Route Propagation Behavior without Policies """ -Christoffer [0]: https://tools.ietf.org/html/rfc8212 [1]: https://ripe77.ripe.net/presentations/59-RIPE77_Snijders_Routing_Policy_Arc…, slide 31/32

2 1

FRRouting Docker Hub Account
by Christian Franke 18 Oct '18

18 Oct '18

Hello, apparently, in April 2017 somebody has created an FRRouting account on Dockerhub. This account appears unused, at least there are no public images. Is there anybody here with control over this account? I would like to discuss publishing images there. Also, I think it would be useful to manage that namespace not with a single account but with an organization, similar to the way it is structured at github. All Best, Chris

2 1