- frog - lists.frrouting.org

/31s, scope link and FRR BGP
by Chris Malton (Delta V) 14 Oct '18

14 Oct '18

Hi all, I have /31s from an upstream provider on v4. If I specify "scope link" in /etc/network/interfaces for these, FRR seemingly doesn't allow the address to be used for update-source. Minimal reproduction example (taken from one of my core routers): /e/n/i config: auto lo iface lo inet loopback up ip addr add 195.246.200.2/32 scope global dev lo auto ens4 iface ens4 inet static address 192.168.1.3/31 scope link FRR config: router bgp 65000 neighbor 192.168.1.2 remote-as 65001 neighbor 192.168.1.2 interface ens4 neighbor 192.168.1.2 update-source 192.168.1.3 What happens in this case, is that FRR sends updates from 172.16.0.2 instead of 192.168.1.3 (despite being explicitly told otherwise!). Have I found a bug, or have I done something stupid? Thanks in advance. 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 3

FRR getting started
by Heikki Lavaste 04 Oct '18

04 Oct '18

Hi, I'm just getting started with FRR in EVE-NG. I have a couple of questions: 1. If I use vtysh to connect, I have access to all routing protocols I have enabled in the daemons file. If I do the same with telnet to localhost 2601, I don't have the protocols. If I understand correctly, I each protocol runs with a different port number and I can connect to OSPF with 2604, etc. Is there a way to "telnet in" and have access to all protocols? 2. Is there a way to get rid of the APIPA kernel routes? frr(config)# do show ip route 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 B>* 150.1.10.10/32 [20/0] via 155.1.108.10, eth0.108, 00:21:59 E 155.1.58.0/24 [90/0] is directly connected, eth0.58, 00:27:09 C>* 155.1.58.0/24 is directly connected, eth0.58, 00:27:09 E 155.1.108.0/24 [90/0] is directly connected, eth0.108, 00:26:51 C>* 155.1.108.0/24 is directly connected, eth0.108, 00:26:51 K * 169.254.0.0/16 [0/1007] is directly connected, eth0.58, 00:27:48 K * 169.254.0.0/16 [0/1006] is directly connected, eth0.108, 00:27:48 K>* 169.254.0.0/16 [0/1002] is directly connected, eth0, 00:27:48 They are just cosmetic, as long as I don't use the range for any hosts in the lab, but I would like to clean up the routing table. Knd Regards Heikki Lavaste

3 2

Any FreeBSD 9.x users still out there? Thinking about stopping support for it...
by Martin Winter 03 Oct '18

03 Oct '18

We seem to have issues getting libyang on FreeBSD 9.x working FreeBSD 9.x is EOL since End of December 2016 So here is a last call: —> If you are using FreeBSD 9.x with FRR, then please speak up. Otherwise FRR 6.0 might be the last version of FRR for it. Regards, Martin Winter (FreeBSD 10.x and 11.x are not affected - ONLY FreeBSD 9.x) Sidenote: CentOS 6 issue as mentioned before was resolved and we can continue to support it (for now). But it is one of the challenging OLD OLD platforms, so we have no idea on how much longer we can support it.

1 0

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 03 Sep '18

03 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