September 2018 - frog - lists.frrouting.org

v6 Route Replace semantics
by Donald Sharp 09 Apr '20

09 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 11 Apr '19

11 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

Any CentOS/RedHat 6 FRR users out there?
by Martin Winter 02 Oct '18

02 Oct '18

I’m trying to see how common the (old) CentOS 6 / RedHat 6 is as it becomes increasingly difficult to support. If you or anyone you know still uses CentOS 6 or RedHat 6 with FRR, then please speak up. Regards, Martin Winter PS: CentOS / RedHat 7 is not affected - Just version 6.x

7 11

Restart OSPFD without restarting other daemons
by Horace 01 Oct '18

01 Oct '18

Dear all, How can I restart OSPFD without restarting other daemons? Couldn't find it on the web, I've to vtysh, 'no router ospf' and reload the config. Anyone got other suggestion? Thanks in advance. Regards, Horace Ng

3 4

Re: [FROG] Source specific Multicast Support on FRR PIM implementation
by Jonas Dibbie 20 Sep '18

20 Sep '18

2 1

Re: [FROG] Source specific Multicast Support on FRR PIM implementation
by Jonas Dibbie 20 Sep '18

20 Sep '18

Hi Donald, > on colo2: > int eth0 > no ip pim sm > ip pim sm I did these changes on colo2. Now i can see the mroute, but I'm still not receiving the MC Data. Are you using non-integrated configs? This sure looks like a bug I fixed the other day https://github.com/FRRouting/frr/commit/59752d4ea5fc500db2f659f85f2e8c68045… Yes, we have sperated configs per Daemon. Colo1 has been migrated from Quagga to FRR 5.0.1 Colo2 has been migrated from FRR 2.x to 5.0.1 greetings, Jonas

2 2

Source specific Multicast Support on FRR PIM implementation
by Jonas Dibbie 20 Sep '18

20 Sep '18

2 1

OpenFabric now included in FRR
by Christian Franke 17 Sep '18

17 Sep '18

All - I'm glad to announce the merging of OpenFabric (PR #2875 https://github.com/FRRouting/frr/pull/2875) into master. OpenFabric (https://tools.ietf.org/html/draft-white-openfabric-06) is one of the solutions provided for the currently ongoing effort in the IETF to develop routing protocols which cope well with densely connected topologies like spine-leaf and clos. For those topologies, established routing protocols often run into scaling issues because of large fan-out and the high degree of interconnection. OpenFabric is based on IS-IS. To improve the scaling properties, it uses a more optimized flooding algorithm which reduces the number of LSPs exchanged in the network to the minimum required to update all nodes. To to test FRR's implementation of OpenFabric, just build and run fabricd with a configuration as following: > ! > interface lo > ip address 100.0.1.1/32 > ip router openfabric 1 > ipv6 address 2001:db8:64::1:1/128 > ipv6 router openfabric 1 > openfabric passive > ! > interface eth0 > ip router openfabric 1 > ipv6 router openfabric 1 > ! > [...] > ! > interface ethX > ip router openfabric 1 > ipv6 router openfabric 1 > ! > router openfabric 1 > net 49.0001.0001.0001.00 > ! All Best, Chris

1 0

question from a noob at networking and routing
by o1bigtenor 04 Sep '18

04 Sep '18

Greetings I had occasion to experiment with canonical's lxd which forced me to use snapd. In the process of this education I found that canonical forced dialy upgrades/updates (not sure which is the correct term). In trying to tame this insistence of ET's on calling home I got to a solution, suggested on the snapd forum which seemed to work. The result was that every month (the new updating frequency) my system would shut itself down because I had refused to let it connect to the snapd and lxd mother ships. Your FRRouting, that I have just found, looks like quite interesting stuff but I'm seeing where installing from snapcraft is considered an option. As I have had quite some pain from snapcraft/snapd I am curious as to why something that forced daily upgrades/updates is being used to install software that 'just needs to work'? If this kind of question is considered 'not nice' I will apologize in advance but I still would like to understand the logic behind choosing this method of installation. Regards Dee

4 3

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

02 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