- frog - lists.frrouting.org

FRR 6.0.2 lost routes after Ubuntu 18.04.2 LTS update/upgrade
by Sim 05 Apr '19

05 Apr '19

After apt-get upgrade / upgrade FRR lost all routes. Reboot or restart the server is the solution to resolve the issue. I'm new with FRR, but this is not happened with Quagga in the last 10/15 years. Is it a "FRR issue" or about Ubuntu 18.04 LTS version? # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: libnss-systemd libpam-systemd libpci3 libsystemd0 libudev1 pciutils systemd systemd-sysv udev 9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 4,765 kB of archives. After this operation, 56.3 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libnss-systemd amd64 237-3ubuntu10.13 [105 kB] Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libsystemd0 amd64 237-3ubuntu10.13 [205 kB] Get:3 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libpam-systemd amd64 237-3ubuntu10.13 [108 kB] Get:4 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 systemd amd64 237-3ubuntu10.13 [2,899 kB] Get:5 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 udev amd64 237-3ubuntu10.13 [1,101 kB] Get:6 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libudev1 amd64 237-3ubuntu10.13 [54.1 kB] Get:7 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 systemd-sysv amd64 237-3ubuntu10.13 [12.0 kB] Get:8 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 pciutils amd64 1:3.5.2-1ubuntu1.1 [257 kB] Get:9 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libpci3 amd64 1:3.5.2-1ubuntu1.1 [24.1 kB] Fetched 4,765 kB in 8s (575 kB/s) (Reading database ... 67479 files and directories currently installed.) Preparing to unpack .../libnss-systemd_237-3ubuntu10.13_amd64.deb ... Unpacking libnss-systemd:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../libsystemd0_237-3ubuntu10.13_amd64.deb ... Unpacking libsystemd0:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Setting up libsystemd0:amd64 (237-3ubuntu10.13) ... (Reading database ... 67479 files and directories currently installed.) Preparing to unpack .../libpam-systemd_237-3ubuntu10.13_amd64.deb ... Unpacking libpam-systemd:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../systemd_237-3ubuntu10.13_amd64.deb ... Unpacking systemd (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../udev_237-3ubuntu10.13_amd64.deb ... Unpacking udev (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../libudev1_237-3ubuntu10.13_amd64.deb ... Unpacking libudev1:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Setting up libudev1:amd64 (237-3ubuntu10.13) ... Setting up systemd (237-3ubuntu10.13) ... (Reading database ... 67479 files and directories currently installed.) Preparing to unpack .../systemd-sysv_237-3ubuntu10.13_amd64.deb ... Unpacking systemd-sysv (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../pciutils_1%3a3.5.2-1ubuntu1.1_amd64.deb ... Unpacking pciutils (1:3.5.2-1ubuntu1.1) over (1:3.5.2-1ubuntu1) ... Preparing to unpack .../libpci3_1%3a3.5.2-1ubuntu1.1_amd64.deb ... Unpacking libpci3:amd64 (1:3.5.2-1ubuntu1.1) over (1:3.5.2-1ubuntu1) ... Setting up libnss-systemd:amd64 (237-3ubuntu10.13) ... Processing triggers for ureadahead (0.100.0-20) ... Setting up systemd-sysv (237-3ubuntu10.13) ... Processing triggers for libc-bin (2.27-3ubuntu1) ... Setting up udev (237-3ubuntu10.13) ... update-initramfs: deferring update (trigger activated) Processing triggers for man-db (2.8.3-2ubuntu0.1) ... Processing triggers for dbus (1.12.2-1ubuntu1) ... Setting up libpci3:amd64 (1:3.5.2-1ubuntu1.1) ... Setting up libpam-systemd:amd64 (237-3ubuntu10.13) ... Setting up pciutils (1:3.5.2-1ubuntu1.1) ... Processing triggers for initramfs-tools (0.130ubuntu3.6) ... update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic Processing triggers for libc-bin (2.27-3ubuntu1) ... # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # ps fax PID TTY STAT TIME COMMAND 955 ? S<s 0:45 /usr/lib/frr/watchfrr -d -r /usr/lib/frr/watchfrr.sh restart %s -s /usr/lib/frr/watchfrr.sh start %s -k /usr/lib/frr/watchfrr.sh stop %s zebra bgpd staticd 1006 ? S<sl 3:59 /usr/lib/frr/zebra -d -A 127.0.0.1 -s 90000000 1009 ? S<sl 7:22 /usr/lib/frr/bgpd -d -A 127.0.0.1 1016 ? S<s 0:05 /usr/lib/frr/staticd -d -A 127.0.0.1 # vtysh Hello, this is FRRouting (version 6.0.2). Copyright 1996-2005 Kunihiro Ishiguro, et al. xxx# sh ip bgp summary IPv4 Unicast Summary: BGP router identifier x.x.32.34, local AS number xxxxxx vrf-id 0 BGP table version 6693928 RIB entries 6, using 960 bytes of memory Peers 2, using 41 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd x.x.118.244 4 xxxx 915579 27779 0 0 0 00:03:45 Active x.x.32.33 4 xxxxxx 843680 352816 0 0 0 00:05:16 Active # ip add 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet x.x.32.34/32 scope global lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:ba:53:46 brd ff:ff:ff:ff:ff:ff inet x.x.32.29/28 brd x.x.32.31 scope global ens160 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feba:5346/64 scope link valid_lft forever preferred_lft forever 3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:ba:af:9d brd ff:ff:ff:ff:ff:ff inet x.x.32.3/28 brd x.x.32.15 scope global ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feba:af9d/64 scope link valid_lft forever preferred_lft forever # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface x.x.32.0 0.0.0.0 255.255.255.240 U 0 0 0 ens192 x.x.32.16 0.0.0.0 255.255.255.240 U 0 0 0 ens160 Regards Sim

4 10

FRR
by Azadeh Shahabi 05 Apr '19

05 Apr '19

Hello, I found different approaches regarding the usage of GPL'ed libraries; so I would like to specifically ask regarding the usage of FRR binary. Can I link FRR binary as is with no modification to it nor its source codes to proprietary codes/binary and then sale the commercial product to customer while FRR is embedded in that product as well, or do I need to open source the product or binary that FRR is used on that. Appreciate if you may assist me with this case. Best regards, Azadeh

2 1

Link Scope IPs
by Chris Malton (Delta V) 30 Mar '19

30 Mar '19

Hi all, I'm sure this must have been asked before, but is it possible to set "scope link" on an IP address in FRR? I use private link addresses heavily because of the exhaustion of v4, and therefore everything is using RFC1918 internally. While I'm deploying v6 and we don't have issues there, I don't want RFC1918 addresses to show up (or, indeed, fail to show up) for v4 traceroutes. All of my routers have loopback addresses, and I'd like Linux to use them in preference to the RFC1918s on the interface. The normal way of me doing this is to set "scope link" on all of them. Alas, such an option doesn't seem to exist in FRR. Am I missing something? Regards, Chris Malton -- Delta V Technologies Limited 03333 402 406 www.deltav-tech.co.uk Office: 17 Elm Close, Southampton, SO16 7DT Company No. 11006104 Registered in England and Wales

2 2

Slack invite
by Martijn Reening 28 Mar '19

28 Mar '19

Hello, I'd like to request an invite for the FRR Slack -- Kind regards, Martijn Reening ETH2 Networks

2 1

slack channel invite
by David Teach 28 Mar '19

28 Mar '19

Hi There, Could I get an invite to the slack channel? Thanks, - David

2 1

Re: [FROG] FRR Installation on Debian9
by Quentin Young 25 Mar '19

25 Mar '19

From source: http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-deb… <http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-deb…> From packages: https://deb.frrouting.org/ <https://deb.frrouting.org/> If you encounter any bugs please report them on the issue tracker (https://github.com/frrouting/frr/issues <https://github.com/frrouting/frr/issues>). Quentin > On Mar 25, 2019, at 3:00 AM, akÿfffffdn ak via frog <frog(a)lists.frrouting.org> wrote: > > > From: akÿfffffdn ak <akinengineer(a)yahoo.com> > Subject: Re: [FROG] FRR Installation on Debian9 > Date: March 25, 2019 at 2:59:55 AM EDT > To: Tim Bray <tim(a)provu.co.uk>, <frog(a)lists.frrouting.org> > > > I installed frr 7.1 on centos7 and watch installing process which is mentioned by Donald Sharp. It is useful. I could run eigrp between 2 frr node. There were 2 hops between ends. > > Sent from Yahoo Mail for iPhone <https://overview.mail.yahoo.com/?.src=iOS> > > On Perşembe, Şubat 21, 2019, 3:56 ÖS, Tim Bray via frog <frog(a)lists.frrouting.org> wrote: > > On 21/02/2019 12:33, akÿfffffdn ak via frog wrote: > > > > I have a problem for instaling FRR on Debian 9 that installed on VM. I > > need to install FRR installation steps on Debian9 > > > > What are you doing at the moment? > > https://github.com/FRRouting/frr/releases/download/frr-6.0.2/frr_6.0.2-0.de… <https://github.com/FRRouting/frr/releases/download/frr-6.0.2/frr_6.0.2-0.de…> > > download and dpkg -i > > should work > > > **** > > Your other option is to install or upgrde to debian 10 (buster), because > this includes an frr package. > > Either re-install. Or add buster lines in /etc/apt/sources.list > > > Then: > # apt install frr > > Info here, https://packages.debian.org/buster/frr <https://packages.debian.org/buster/frr> > > I'm not sure using debian 10 would be great for production, no security > support. But would be an easy way to test. > > > > > -- > Tim Bray > Technology Director, ProVu Communications Ltd, Huddersfield, UK. > http://www.provu.co.uk/ <http://www.provu.co.uk/> Phone: +44 1484 840048 <tel:+44%201484%20840048> > IP Telephones, Drop shipping, pre-configuration, XML orders > ***** If it is important, just phone ***** > > > > > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org <mailto:frog@lists.frrouting.org> > https://lists.frrouting.org/listinfo/frog <https://lists.frrouting.org/listinfo/frog> > > > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

1 0

Re: [FROG] FRR Installation on Debian9
by akÿfffffdn ak 25 Mar '19

25 Mar '19

I installed frr 7.1 on centos7 and watch installing process which is mentioned by Donald Sharp. It is useful. I could run eigrp between 2 frr node. There were 2 hops between ends. Sent from Yahoo Mail for iPhone On Perşembe, Şubat 21, 2019, 3:56 ÖS, Tim Bray via frog <frog(a)lists.frrouting.org> wrote: On 21/02/2019 12:33, akÿfffffdn ak via frog wrote: > I have a problem for instaling FRR on Debian 9 that installed on VM. I > need to install FRR installation steps on Debian9 What are you doing at the moment? https://github.com/FRRouting/frr/releases/download/frr-6.0.2/frr_6.0.2-0.de… download and dpkg -i should work **** Your other option is to install or upgrde to debian 10 (buster), because this includes an frr package. Either re-install. Or add buster lines in /etc/apt/sources.list Then: # apt install frr Info here, https://packages.debian.org/buster/frr I'm not sure using debian 10 would be great for production, no security support. But would be an easy way to test. -- Tim Bray Technology Director, ProVu Communications Ltd, Huddersfield, UK. http://www.provu.co.uk/ Phone: +44 1484 840048 IP Telephones, Drop shipping, pre-configuration, XML orders ***** If it is important, just phone ***** _______________________________________________ frog mailing list frog(a)lists.frrouting.org https://lists.frrouting.org/listinfo/frog

1 0

FIB routing compaction / compression
by Stefan Priebe - Profihost AG 18 Mar '19

18 Mar '19

Hello List, is there a fib routing compaction or compression plugin available? While having only a bunch of upstreams / peers 64k fib size of a standard switch would be enough for a full bgp table in rib. If not what‘s needed for frr? Greets, Stefan

4 5

OSPFv2 in a VRF, FRR 6.0.2 on Ubuntu 18.10
by Chuck Cox 15 Mar '19

15 Mar '19

Hi folks, I'm trying to set up a lab environment to test some OSPF stuff. I installed the FRR 6.0.2-0~ubuntu18.04.1 package on top of Ubuntu 18.10. I elected to leave my management interface (ens3) in the default VRF and put the others in a VRF called "WAN", shown as item #10 below: $ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:68:bb:72 brd ff:ff:ff:ff:ff:ff 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master WAN state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:ed:f8:ad brd ff:ff:ff:ff:ff:ff 4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master WAN state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:07:11:c7 brd ff:ff:ff:ff:ff:ff 5: ens11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master WAN state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:6e:51:76 brd ff:ff:ff:ff:ff:ff 6: ens12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master WAN state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:bf:5d:f3 brd ff:ff:ff:ff:ff:ff 7: ens13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master WAN state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:f5:24:55 brd ff:ff:ff:ff:ff:ff 8: ens14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master WAN state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:d3:1d:30 brd ff:ff:ff:ff:ff:ff 9: ens15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master WAN state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:e3:cf:dd brd ff:ff:ff:ff:ff:ff 10: WAN: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 06:6a:07:90:27:3a brd ff:ff:ff:ff:ff:ff "ip route" correctly shows only the connected subnet route for the management net and a default: $ ip route default via 192.168.42.1 dev ens3 proto static 192.168.42.0/24 dev ens3 proto kernel scope link src 192.168.42.153 And the other connected routes in the VRF: $ ip route show vrf WAN unreachable default metric 4278198272 172.16.1.0/24 dev ens9 proto kernel scope link src 172.16.1.1 172.17.1.0/24 dev ens14 proto kernel scope link src 172.17.1.1 192.0.2.0/24 dev ens10 proto kernel scope link src 192.0.2.1 198.51.100.0/24 dev ens11 proto kernel scope link src 198.51.100.1 203.0.113.0/24 dev ens12 proto kernel scope link src 203.0.113.1 What I see inside vtysh matches: $ ip route show vrf WAN unreachable default metric 4278198272 172.16.1.0/24 dev ens9 proto kernel scope link src 172.16.1.1 172.17.1.0/24 dev ens14 proto kernel scope link src 172.17.1.1 192.0.2.0/24 dev ens10 proto kernel scope link src 192.0.2.1 198.51.100.0/24 dev ens11 proto kernel scope link src 198.51.100.1 203.0.113.0/24 dev ens12 proto kernel scope link src 203.0.113.1 router# sho ip ro vrf WAN Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, > - selected route, * - FIB route VRF WAN: K * 0.0.0.0/0 [255/8192] unreachable (ICMP unreachable), 04:04:10 C>* 172.16.1.0/24 is directly connected, ens9, 04:04:10 C>* 172.17.1.0/24 is directly connected, ens14, 04:04:10 C>* 192.0.2.0/24 is directly connected, ens10, 04:04:10 C>* 198.51.100.0/24 is directly connected, ens11, 04:04:10 C>* 203.0.113.0/24 is directly connected, ens12, 04:04:10 So far so good. Now I enabled ospfd in /etc/frr/daemons and restarted FRR. The ospfd process is running: $ ps -ef|grep frr root 2045 1 0 13:31 ? 00:00:02 /usr/lib/frr/watchfrr -d -r /usr/lib/frr/watchfrr.sh restart %s -s /usr/lib/frr/watchfrr.sh start %s -k /usr/lib/frr/watchfrr.sh stop %s zebra ospfd staticd frr 2059 1 0 13:31 ? 00:00:00 /usr/lib/frr/zebra -d -A 127.0.0.1 -s 90000000 frr 2064 1 0 13:31 ? 00:00:01 /usr/lib/frr/ospfd -d -A 127.0.0.1 frr 2069 1 0 13:31 ? 00:00:00 /usr/lib/frr/staticd -d -A 127.0.0.1 Then I put in some seemingly basic OSPF config shown below. Yes, I really only want to speak OSPF on one of the interfaces (ens14) for now. router# sho run Building configuration... Current configuration: ! frr version 6.0.2 frr defaults traditional hostname router log syslog informational no ipv6 forwarding service integrated-vtysh-config ! interface ens3 description MGMT ! interface ens9 vrf WAN description ServerLAN ip address 172.16.1.1/24 ! interface ens10 vrf WAN description MPLS ip address 192.0.2.1/24 ! interface ens11 vrf WAN description PtP ip address 198.51.100.1/24 ! interface ens12 vrf WAN description Satellite ip address 203.0.113.1/24 ! interface ens13 vrf WAN description Inet ! interface ens14 vrf WAN description SD-WAN ip address 172.17.1.1/24 ! interface ens15 vrf WAN description XAXD-LAN ! router ospf 42 vrf WAN ospf router-id 172.17.1.1 redistribute connected passive-interface ens9 passive-interface ens10 passive-interface ens11 passive-interface ens12 passive-interface ens13 passive-interface ens15 area 0.0.0.0 range 10.0.0.0/8 area 0.0.0.0 range 172.16.0.0/20 area 0.0.0.0 range 192.0.2.0/24 area 0.0.0.0 range 192.168.0.0/16 area 0.0.0.0 range 198.51.100.0/24 area 0.0.0.0 range 203.0.113.0/24 default-information originate ! line vty ! end Now here's the problem: OSPF appears to be running but it's not doing anything and none of the show commands give any output, except "sho ip ospf vrf/vrfs": router# sho ip ospf vrf Name Id RouterId Default-IP-Routing-Table 0 0.0.0.0 WAN 10 172.17.1.1 Total number of OSPF VRFs: 2 router# sho ip ospf vrfs Name Id RouterId Default-IP-Routing-Table 0 0.0.0.0 WAN 10 172.17.1.1 Total number of OSPF VRFs: 2 router# sho ip ospf vrf WAN dat router# sho ip ospf vrf WAN int router# sho ip ospf vrf WAN nei router# sho ip ospf vrf WAN route router# sho ip ospf dat router# sho ip ospf int router# sho ip ospf nei router# sho ip ospf route Any suggestions? I've restarted FRR a couple of times and rebooted the box too, same results... Thanks, Chuck

2 2

7.0 release
by David Lamparter 13 Mar '19

13 Mar '19

Hi all, I'm very happy to announce we have released version 7.0 of FRRouting! [https://github.com/FRRouting/frr/releases] There are some major changes in this release, specifically libyang [https://github.com/CESNET/libyang] is now a hard requirement to build and run FRRouting. Here's the full list of major changes from 6.0.x to 7.0: - YANG data modeling & NETCONF support has arrived for the following daemons: - ripd - ripngd - isisd Note that this uses FRR-specific models and may still be subject to some changes. Feedback is strongly appreciated! - Error Codes / Categories are now added to log messages. They are printed as [EC 99999999999] on log messages and identify classes of errors. The library, bgpd, ospfd and zebra have been properly extended to categorize errors while the other daemons have somewhat more rudimentary cateogries. - "configure terminal" in the CLI is no longer an exclusive state on any daemon, i.e. multiple users can edit the configuration at the same time in all daemons. This was previously already the case for zebra and isisd. - BGP enhancements: - EVPN Duplicate Address Detection - EVPN route servers - EVPN extended mobility - Global IPv6 addresses can be used for RFC5549 (v4-over-v6) nexthops - Flowspec protocol support has been significantly extended. (Note that OS integration is still very incomplete.) - Add-Path IDs are now reused on transmission when possible - Aggregates now properly aggregate extended and large community attributes - IS-IS: - BFD support has been added - triggered hellos have been implemented - new daemon: OpenFabric (a datacenter variant of IS-IS - cf. https://datatracker.ietf.org/doc/draft-white-openfabric/) - Zebra's kernel/dataplane interface is undergoing a rewrite and parts have been moved into a separate thread with a more extensible architecture. Work on this project is ongoing. - staticd now supports onlink nexthops for static routes - sharpd now supports nexthop groups for route installs - many bugs were fixed, also including quite a few overdue documentation improvements. This also includes CVE-2017-3224 which is a low-severity low-impact OSPF vulnerability (as evident by the 2017 date.) Important packaging and build related changes: - libyang is now required to build and run FRRouting. Version 0.16.74 or newer (e.g. 0.16-r3 which is 0.16.105) is strongly recommended. Older versions will create additional hazards at both build and runtime because an extension module needs to be installed. Support for libyang versions before 0.16.74 will be removed in the next non-stable FRRouting version. - when using libyang before 0.16.74, make sure to specify the "--with-libyang-pluginsdir=/usr/lib/frr/libyang_plugins" option (change path to fit system) - Debian packaging has been completely overhauled (matches the changes in 6.0.2.) If you are creating derivative Debian packages, updates will be necessary. - RPKI and SNMP are now separate packages that can be installed additionally. There are no longer distinct "RPKI" and "no RPKI" versions of FRRouting on Debian. - Debian packages are now provided in a repository at: https://deb.frrouting.org/ - Snapcraft packaging has been updated to match. - There is a new "--enable-static-bin" option to link libfrr statically into FRR binaries. This is the only supported way of doing any static linking of FRR. ("--disable-shared" is NOT supported.) - all daemons now properly complete their startup before allowing their parent to exit when the -d daemonization option is used. This should remove the need for any "sleep" calls or start retrying in init scripts. - some minor non-reproducibility issues were fixed. FRRouting should now always build reproducibly. - the topotests system that was previously maintained separately is now shipped as part of the FRR source under tests/topotests. As you can see this is quite a changelog and I'd like to thank everyone who contributed to this release. It has been a very productive 6 months! Cheers, -David

1 0