February 2019 - frog - lists.frrouting.org

Yocto Recipe for FRR
by Amol Lad 10 Aug '21

10 Aug '21

Hi, Please advise if there is any Yocto recipe for FRRouting? If not, how to go about creating one for FRR? Yocto Recipe for FRR will hugely simplify integrating FRR in Yocto based embedded linux distributions. So please advise if there are any plans to develop this recipe? Thanks Amol ________________________________ The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

4 10

v6 Route Replace semantics
by Donald Sharp 08 Apr '20

08 Apr '20

All - We recently introduced, into master, a new cli switch for zebra on linux `--v6-rr-semantics`. This was allow zebra to take advantage of the linux kernel getting v6 route replace semantics that is coming soon in the 4.18 linux kernel. So if you are on the bleeding edge of linux kernels and FRR you can start to take advantage of this new feature. What are Route Replace semantics you ask? Suppose we have a v6 route with 2 nexthops: S>* 4:6:7::/64 [1/0] via 1:2:3::4, enp0s3, 00:00:02 via 1:2:8::8, enp0s8, 00:00:02 Now suppose we remove a nexthop: robot# conf t robot(config)# no ipv6 route 5:7:9::/78 1:2:8::9 robot(config)# end robot# show ipv6 route [snip] S>* 5:7:9::/78 [1/0] via 1:2:3::4, enp0s3, 00:01:04 Let's look at the netlink notifications for this event: [ROUTE]5:7:9::/78 proto static metric 20 <----------- From creation of the 2x ecmp for 5:7:9::/78 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]Deleted 5:7:9::/78 proto static metric 20 <---- We delete the route nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium <----- We add it back in. In order to get the routes right in the kernel we had to delete the route first and then add it back in. Exposing a small window of packets being dropped while the route is fixed in the fib. Route Replace semantics tells the linux kernel to just replace the nexthops for the route. New packets coming in would immediately start using the new ecmp nexthop group path: [ROUTE]5:7:9::/78 proto static metric 20 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium thanks! donald

2 1

FRR on NRL CORE (fyi)
by Phil Wiggins 10 Apr '19

10 Apr '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

2 3

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 5.0.2, remove-private-AS and ebgp multihop
by Chris Malton 28 Feb '19

28 Feb '19

Hi all, Weird one here: In my config I have an eBGP Multihop peer, and for some reason, despite the config looking like this: router bgp 65001 neighbor w.x.y.z remote-as nnnnn neighbor w.x.y.z local-as 205804 neighbor w.x.y.z description Upstream - Peering Router - b neighbor w.x.y.z ebgp-multihop 2 neighbor w.x.y.z disable-connected-check neighbor w.x.y.z update-source 81.187.56.158 address-family ipv4 unicast neighbor w.x.y.z remove-private-AS all replace-AS nnnnn is the correct peer ASN. The resulting PCAP in wireshark shows: Path Attribute - AS_PATH: 205804 65001 Flags: 0x50, Transitive, Extended-Length, Well-known, Complete Type Code: AS_PATH (2) Length: 10 AS Path segment: 205804 65001 Segment type: AS_SEQUENCE (2) Segment length (number of ASN): 2 AS4: 205804 AS4: 65001 I am convinced I have done something wrong, as I expected FRR to strip 65001 from the sequence. I'm running frr 5.0.2 on a pfSense (so alas, upgrading to 6 isn't an option at the moment). Any hints what I've done wrong - or is this a known bug? Regards, Chris Malton -- Delta V Technologies Limited 03333 402 402 www.deltav-tech.co.uk Office: 17 Elm Close, Southampton, SO16 7DT Company No. 11006104 Registered in England and Wales

2 2

RFC 4364 configuration example
by Mark Tees 26 Feb '19

26 Feb '19

Hi there, Does anyone have a full MPLS layer 3 VPN example I can test out? Also, which version I should try with. I have tried with FRR 6.0 and can see routes under the VRF like below: ord-b457489f5df65f1f# show bgp vrf vrf2 ipv4 </snip> Network Next Hop Metric LocPrf Weight Path *> 5.5.5.1/32 0.0.0.0 0 32768 ? *> 10.13.12.0/30 0.0.0.0 0 32768 ? However I can't see them in the main vpn table or sent to vpn peers. ord-b457489f5df65f1f# show bgp ipv4 vpn No BGP prefixes displayed, 0 exist Have tried with rt/rd/label config under vrf-policy in 'router bgp xxxx' and also under 'router xxxx vrf vrf2'. redistribute connected redistribute static label vpn export 34712 rd vpn export 10.12.12.1:100 nexthop vpn export 10.12.12.1 rt vpn both 45437:100 I followed the Linux VRF instructions for setting up VRF and that appears ok. Any ideas are welcome. Cheers, Mark

2 2

BABEL Problem on DEBIAN9 FRR
by akÿfffffdn ak 25 Feb '19

25 Feb '19

In the same LAB App I applied BABEL configuration on 4 FRR Node. When I ping to other end of the network. But packets cannot sent to destination.When I delete and then add default route of DEBIAN after that ping become successful.I have to do this frequently. (When ping unsuccessful FRR learn destination address from BABEL after adding the default route ping successful) Why could it be. > I installed FRR on debian 9 on 4 VM. > I have 4 node FRR. > All of them have eigrp configuration. > When I start ping test to 2 hop away FRR Router. > Ping test successful. > But when I shutdown the interface of 2 hop away FRR Router. > Ping packets drop down. > With no shut comand in destination interface. > Ping successful again. > But sometimes eigrpd daemon kill itself on FRR and I can not pinging again. > I have to restart frr service on VM. > But normally it should not work like that. > Why this happen it in this scenario. > I have to deliver packets to destination continuously. Inan

1 0

ospf6d LSA's disappearing, probably stuck MaxAge LSA
by Leon Meßner 24 Feb '19

24 Feb '19

Hi, we recently moved two OSPFv3 routers from quagga 0.99.23 to frr-6.0.2 and are now having two (perhaps unrelated) issues. Issue one is that link-states from one FRR (R1) do only appear very briefly in the databases of other routers. This issue is the pressing one. The other issue is that E1 routes from some routers stay in the ospf6d route table although they have been flushed from the area already. What i observe about issue one: Every LSRefreshTime, when restarting R1 or when "clear ipv6 ospf6 interface INTERFACE" is run, i see R1's LSA's appear very briefly in neighbors databases. I also see routes related to R1 appear in the ospf6d table. After a few seconds these disappear again. Looking at R1's "show ipv6 ospf6 database self-originated" everything is there all the time. What i see in debugging on some other Router (R2): OSPF6: LSUpdate received on bond0.84 OSPF6: src: fe80::3efd:feff:fea2:145a <-R1 OSPF6: dst: ff02::5 OSPF6: OSPFv3 Type:4 Len:108 Router-ID:192.109.82.2 <-R1 OSPF6: Area-ID:0.0.0.0 Cksum:452b Instance-ID:0 OSPF6: Number of LSA: 1 OSPF6: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Age: 1 SeqNum: 0x800002b4 Cksum: 2e43 Len: 88 OSPF6: ospf6_install_lsa Install LSA: [Router Id:0.0.0.0 Adv:192.109.82.2] age 1 seqnum 800002b4 in LSDB. ... flooding of that LSA ... OSPF6: LSUpdate received on tun0 OSPF6: src: fe80::f101:2 OSPF6: dst: fe80::f101:1 OSPF6: OSPFv3 Type:4 Len:108 Router-ID:192.109.82.24 OSPF6: Area-ID:0.0.0.0 Cksum:7bab Instance-ID:0 OSPF6: Number of LSA: 1 OSPF6: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Age: 3600 SeqNum: 0x8000040c Cksum: 580c Len: 88 OSPF6: ospf6_install_lsa Install LSA: [Router Id:0.0.0.0 Adv:192.109.82.2] age 268139 3600 seqnum 8000040c in LSDB. OSPF6: LSA disappearing: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Schedule SPF Calculation for 0.0.0.0 OSPF6: SPF: Scheduled in 0 msec OSPF6: LSA disappearing: [Router Id:0.0.0.0 Adv:192.109.82.2] ... flooding of that LSA ... So there is a MaxAge LSA that has a "higher" SequenceNumber. Probably from a prior boot. Should FRR on R1 raise its SequenceNumber for this LSA to 0x8000040d? Is this likely a problem on R1? I also noticed, that LSAcks for MaxAge LSAs are multicast to either ff02::6 or ff02::5 depending on DR status. Is this correct bahavior, or should they be unicast? I tried to reproduce issue one via FRRouting/topotests, but haven't succeeded until now. Probably because i didn't manage to get a stuck MaxAge LSA in my test instance. Any help would be really appreciated. If more information is needed, i'm happy to supply more logging and help with debugging. Regards, Leon

1 1

Frr init script 'reload' option
by Ron Hermsen 24 Feb '19

24 Feb '19

I'm using FRR 5.0.2 with Tinycorelinux (TCL-10.0) with the frr init script [1]. I have a question regarding the the 'reload' option. The usage message give its use as "reload applies only modifications from the running config to all daemons." not sure what to expect from this option. >From its behaviour I get it is a rollback from running config to startup config without a restart of the daemons. Is my understanding correct? [1] https://raw.githubusercontent.com/FRRouting/frr/frr-5.0.2/tools/frr

2 1

Hardware Requirements
by Steuer Heribert 23 Feb '19

23 Feb '19

Hello, for using FRR with VPP & underlying DPDK, is there any “working hardware” list which goes beyond “use Intel NICs”? I am aware of some white box lists provided by NOS vendors but was not able to find anything about native FRR. I´ve found some posts of cloudscale.ch where they mentioned appliances from a vendor named Lanner (which I never heard of before). Its not about advertising vendors but more kind of a “known-to-work-well” list. In addition it would be nice to chat on Slack, please invite 😊 Thanks, Heri

5 8