August 2018 - frog - lists.frrouting.org

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

received-routes.. doesn't work?
by Mark Kamichoff 01 Sep '18

01 Sep '18

Hi - I'm running various 3.1-dev versions of FRR and noticed that the "show ip bgp nei <peer> received-routes" doesn't seem to work as expected on any of them. Here's an example of the relevant parts of the configuration: ! router bgp 395460 neighbor 169.254.169.254 remote-as 64515 neighbor 169.254.169.254 password <snip> neighbor 169.254.169.254 ebgp-multihop 2 address-family ipv4 unicast neighbor 169.254.169.254 soft-reconfiguration inbound neighbor 169.254.169.254 route-map DENY_ALL in neighbor 169.254.169.254 route-map DENY_ALL out exit-address-family ! route-map DENY_ALL deny 65535 ! orca# show ip bgp neighbors 169.254.169.254 routes orca# show ip bgp neighbors 169.254.169.254 received-routes BGP table version is 0, local router ID is 10.3.4.36 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path orca# >From tcpdump and other t-shooting I know that there is an IPv4 DFZ being received, but received-routes doesn't show any of the routes that should be in the adj-rib-in. Oddly, if I remove the inbound route-map I see expected prefixes using the "routes" /and/ "received-routes" command. If I put it back, the "received-routes" shows nothing once again. It would almost seem like soft-reconfiguration isn't really enabled, but received-routes should give me an error if it wasn't and the neighbor information confirms that it is: orca# show ip bgp neighbors 169.254.169.254 <snip> For address family: IPv4 Unicast Update group 5, subgroup 5 Packet Queue length 0 Inbound soft reconfiguration allowed <----- <snip> This isn't limited to the IPv4 AF, either. I've got IPv6 peers that echibit the same behavior. Have I found a bug or am I doing something wrong? I'm happy to file a bug report. More info., if it helps: orca# show version FRRouting 3.1-dev (). Copyright 1996-2005 Kunihiro Ishiguro, et al. configured with: '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libexecdir=${prefix}/lib/frr' '--disable-maintainer-mode' '--disable-dependency-tracking' '--enable-exampledir=/usr/share/doc/frr/examples/' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--enable-ospfapi=yes' '--enable-vtysh=yes' '--enable-isisd=yes' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--enable-werror' '--enable-gcc-rdynamic' '--with-libpam' '--enable-systemd=yes' '--enable-poll=yes' '--enable-cumulus=yes' '--enable-pimd=yes' '--enable-dependency-tracking' '--enable-bgp-vnc=no' 'build_alias=x86_64-linux-gnu' orca# (orca:20:08:PDT)% uname -a Linux orca 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 (2017-05-02) x86_64 GNU/Linux (the build is from August 26th) Thanks! - Mark -- Mark Kamichoff prox(a)prolixium.com https://www.prolixium.com/

1 1

A route-map scaling improvement that has just gone in.
by Donald Sharp 22 Aug '18

22 Aug '18

All - This morning, PR #2818 (https://github.com/FRRouting/frr/pulls/2818) was merged into the FRR master code base. This fixes Issue #2493(https://github.com/FRRouting/frr/issues/2493), where zebra was causing significant processing for route-map changes being made to the system in both BGP and Zebra. Here are some timings: Pre-route-map #2818 improvements for ZEBRA: ZEBRA: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 12 22568.749 121924 185 160855 162 414190 RWTEX TOTAL BGP: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 10 31159.647 121679 256 117558 220 117713 RWTEX TOTAL Create a Unused route-map: robot# conf t robot(config)# route-map BLAR permit 10 robot(config-route-map)# end ZEBRA: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 12 40671.587 136545 297 214461 226 414190 RWTEX TOTAL BGP: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 10 32043.610 122392 261 117558 227 117713 RWTEX TOTAL This is aproximately 19 cpu seconds split between BGP and zebra to handle a full BGP feed for a route-map change that no-process is currently using. After-route-map (#2818) improvements for ZEBRA: ZEBRA: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 11 11592.894 1216075 9 152939 5 120621 RWTEX TOTAL BGP: Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 9 8306.451 40216 206 116589 193 116801 RWTEX TOTAL Create a Unused route-map: robot# conf t robot(config)# route-map BLAR permit 10 robot(config-route-map)# end Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 11 11596.799 1216183 9 152939 5 120621 RWTEX TOTAL Total thread statistics ------------------------- CPU (user+system): Real (wall-clock): Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread 9 8320.976 40365 206 116589 193 116801 RWTEX TOTAL This adds up to negligible amounts of cpu time. This is a wonderful improvement in processing of route-map changes for zebra( and consequentially for bgp ). I'd like to thank Soman for doing this work. thanks! donald

1 0

OSPF Fast Convergence (RFC6976)?
by Timo Schöler 15 Aug '18

15 Aug '18

Hi all, I came across ``Framework for Loop-Free Convergence – Using the Ordered Forwarding Information Base (oFIB) Approach'' [0] which may be a phantastic remedy to a problem that occurs from time to time in a network I maintain: Even restarting a single OSPF process (on a group of about 20 routers in that area) causes trouble in forwarding/routing of 60.000+ TCP streams that traverse that area. (EIGRP is said to be immune against that because of explicit termination of the diffusing computations.) AFAICS it's not implemented yet in any free routing suite – are there any plans of doing so (in FRR)? Best regards, Timo [0] – https://tools.ietf.org/html/rfc6976

3 3

BFD daemon is now part of master
by Rafael Zalamena 14 Aug '18

14 Aug '18

Hi all, Today the BFD daemon (`bfdd`) got merged into master. It implements the Bidirectional Forwarding Detection protocol and its main purpose is to detect link failures to notify services. The daemon is automatically built on standard distribution on all platforms. Currently the following FRR daemons support BFD: * bgpd; * ospfd; * ospf6d; * pimd; --- Background: The BFD daemon was implemented re-using some Cumulus implementation, but it was extracted from another service ( https://github.com/CumulusNetworks/ptm/blob/master/src/ptm_bfd.c ). The code went through the following changes: * it became a stand alone daemon; * added new configuration interfaces: vtysh and control socket (using JSON); * replaced uthash.h with FRR's hash implementation; * added compatibility code to run on *BSDs; * changed event manager with FRR's; * minor code/protocol fixes; Related RFCs: * RFC 5880 (protocol description); * RFC 5881 (single hop IPv4/IPv6 implementation); * RFC 5883 (multi hop implementation); --- For those who want to try out, here is the BFD manual: http://docs.frrouting.org/en/latest/bfd.html Thanks to everyone that helped reviewing and testing the code! Rafael

1 0

FRR not starting at boot - Debian testing (10)
by Brandon Applegate 11 Aug '18

11 Aug '18

So yes - I know I’ve done this to myself to some extent by running a “testing” OS. But hear me out… I’m cloning these boxes in vmware and configuring with ansible. So they are very consistent. FRR is 5.0.1. On one configuration - FRR starts as expected. On another box - FRR will not start automatically. There’s nothing in logs - it doesn’t even seem like it tries. But if I log in and manually “sudo systemctl restart frr” it comes right up. I don’t claim to be a systemd expert - but I did play around a bit in the unit file trying to add an ExecStartPre with a sleep - no dice. I also thought it might similar to: https://github.com/FRRouting/frr/issues/1340 However, I see that watchfrr gets ran anyway (I don’t have this in the daemons file). That’s fine, but it doesn’t jive with the issue 1340 above. So I don’t think that’s my issue at play here. I can tell you the main difference in the two boxes (working vs. not) is the frr config itself (daemons are the same) and IP addresses/interfaces. On the working box I have about 30 lines of frr.conf. I have maybe ~10 total ips, split between ipv4/6. frr.conf is ospf and ospfv6. On the boxes where it won’t start at boot - I have about 60 lines of FRR conf. I have about 20 total ips, split between ip4/6. About 20 BGP peers (again split between ipv4/ipv6 - so 10 each). Anyone have any idea what I can look at next ? I can put some ansible in to log back into the problem boxes and manually start frr - but that’s a hacky and cheap method. I’d rather understand what’s going on and fix it properly. Thanks. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."

2 1

Issues with EVPN Type-5 Routes
by Mohan Singamsetty 10 Aug '18

10 Aug '18

Hi all, I have simple two node setup with below configuration on each node. I am trying to verify functionality related to EVPN Type-5 routes and observing few issues as listed below. Node A ------------------ Node B Most of the configuration is from source: https://docs.cumulusnetworks.com/display/DOCS/Ethernet+Virtual+Private+Netw… Node A router bgp 65000 bgp router-id 203.0.113.1 no bgp default ipv4-unicast neighbor fabric peer-group neighbor fabric remote-as 65001 neighbor fabric capability extended-nexthop neighbor 203.0.113.2 peer-group fabric ! address-family ipv4 unicast network 44.44.44.0/24 exit-address-family ! address-family l2vpn evpn neighbor fabric activate advertise-all-vni advertise ipv4 unicast exit-address-family ! router bgp 65000 vrf Sri bgp router-id 203.0.113.1 ! address-family ipv4 unicast network 45.45.45.0/24 exit-address-family ! address-family l2vpn evpn advertise-all-vni advertise ipv4 unicast exit-address-family ! line vty ! Node B router bgp 65001 bgp router-id 203.0.113.2 no bgp default ipv4-unicast neighbor fabric peer-group neighbor fabric remote-as 65000 neighbor fabric capability extended-nexthop neighbor 203.0.113.1 peer-group fabric ! address-family ipv4 unicast network 54.54.54.0/24 exit-address-family ! address-family l2vpn evpn neighbor fabric activate advertise-all-vni advertise ipv4 unicast exit-address-family ! router bgp 65001 vrf Sri bgp router-id 203.0.113.2 ! address-family ipv4 unicast network 55.55.55.0/24 exit-address-family ! address-family l2vpn evpn advertise-all-vni advertise ipv4 unicast exit-address-family ! line vty ! * When I had this configuration in frr.conf and rebooted both the nodes, no Type-5 routes were advertised and the only routes I see are Type-3 and Type-2 routes and the output is as below. Node_A# show bgp evpn route BGP table version is 2, local router ID is 203.0.113.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:3 *> [2]:[0]:[48]:[00:50:56:b5:b4:53] 203.0.113.1 32768 i *> [3]:[0]:[32]:[203.0.113.1] 203.0.113.1 32768 i Route Distinguisher: 203.0.113.1:4 *> [3]:[0]:[32]:[203.0.113.1] 203.0.113.1 32768 i Route Distinguisher: 203.0.113.2:3 *> [3]:[0]:[32]:[203.0.113.2] 203.0.113.2 0 65001 i Route Distinguisher: 203.0.113.2:4 *> [3]:[0]:[32]:[203.0.113.2] 203.0.113.2 0 65001 i Displayed 5 prefixes (5 paths) dev# I remember about an issue that was discussed by Donald and others earlier, where VRF configuration sequence does matter for Type-5 Routes. The mail thread that talks about this issue is @ https://lists.frrouting.org/pipermail/frog/2018-July/000205.html * So I removed the bgp configuration from both the nodes as below Node_A# conf t Node_A (config)# no router bgp 65000 Node_A (config)# no router bgp 65000 vrf Sri Node_A (config)# Node_B# conf t Node_B (config)# no router bgp 65001 Node_B (config)# no router bgp 65001 vrf Sri Node_B (config)# * Configured bgp and associated VRF again on the two nodes (vrf Sri configuration was not removed so honoring the sequence requirements from the above thread). After this the bgp evpn routes on each node are as below. Node A Node_A# show bgp evpn route BGP table version is 1, local router ID is 203.0.113.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:5 *> [5]:[0]:[24]:[45.45.45.0] 0.0.0.0 0 32768 i Displayed 1 prefixes (1 paths) Node B Node_B# show bgp evpn route BGP table version is 1, local router ID is 203.0.113.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP] EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP] EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP] EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP] Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 203.0.113.1:5 *> [5]:[0]:[24]:[45.45.45.0] 203.0.113.1 0 0 65000 i Displayed 1 prefixes (1 paths) EdgeRouter-2# Some of the observations: 1. When the two nodes were brought for the first time, no Type-5 routes were advertised initially. Only Type-3 and Type-2. 2. Once I unconfigure BGP and configure again, neither Type-3 nor Type-2 routes were showing up. 3. After this, It looks like Node-A is advertising Type-5 route for one of the prefix that was added through network command and this indeed received by Node-B. But this is not happening from Node B to Node A. 4. IP-Prefix from VRF Sri was advertised by Node A, but this is not happening for the IP-Prefix that was available at global level. I am trying to understand the reason for above behavior. Can you help me to identify if I am missing anything in configuration ? If not what am I missing here ? Unfortunately, not many log messages were available in this part of the code and I am trying to add more and debug, but any quick help on this would be really useful. This is latest FRR (may be a month old). I do have the log files for both the nodes with all necessary BGP debugs enabled. Let me know if you need any more details on this. Thanks, Mohan

1 0

FRR deletes default route upon installation
by Brandon Applegate 09 Aug '18

09 Aug '18

I’m having quite the day today :/ This is Ubuntu 18.04. I have a static IP and default route configured. I’m using Ansible to provision these machines. I logged into the console on the box and ran ‘watch “ip route show”’ - to keep an eye on the routing table. As soon as ansible installed FRR - my default route was gone. I see this in the logs on the box: Aug 9 16:24:41 ubuntu frr[2186]: Removing all routes made by FRR. Technically the default route was there before FRR. So if that is what is removing it - color me confused. Once this happens - ansible gets stuck (my ansible is running from a box on a different subnet and therefore needs the default route to stay stable). Can someone explain this behavior to me ? Is there something I can do ? Put a temp static route in for my ansible host ? Add a route in a manner that FRR won’t touch it yet ? Would it help to have FRR config in place beforehand (I can do this in ansible easy enough) ? Many thanks in advance on this. I’m so so close on this project I’m working on. Just need to get over this bump. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."

2 1

Ubuntu 18.04 dependency - libjson-c2/c3
by Brandon Applegate 09 Aug '18

09 Aug '18

Hello, I’m trying to get frr_5.0.1-1.ubuntu18.04.1_amd64.deb installed on an Ubuntu 18.04 box. I could have sworn I had this working on 18.04 recently. Perhaps Ubuntu kicked from c2 to c3 in a recent update ? --- TASK [Install FR Routing package - routers] ************************************************************************************************************************************** fatal: [10.255.1.1]: FAILED! => {"changed": false, "msg": "Dependency is not satisfiable: libjson-c2 (>= 0.10)\n”} — Looks like there was the same issue for the Debian package: https://github.com/FRRouting/frr/issues/1328 Should I open a github issue for this ? Or is something else at play here ? Thanks in advance. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."

3 4