- frog - lists.frrouting.org

Babeld Question
by Oguzhan Kayhan 19 Oct '18

19 Oct '18

Hello all, Newbie on FRR and also Babel I made a test setup as 2 frr routers They have 2 interfaces in common subnet.. and a 3rd interface which only belongs to each router seperately.. First i tried the config with ospfd The 3rd interface routing appeared correctly and 1st router was able to ping 3rd interface of the other router (and vice versa) Then i wanted to test babel.. Disabled ospfd Made an example config for babel ! ! interface eth0 babel hello-interval 100 ! interface eth2 babel wired babel hello-interval 100 ! interface eth1 babel hello-interval 100 ! ! router babel network eth0 network eth1 network eth2 redistribute ipv4 connected When starting FRR i am getting the following errors Starting Frr daemons (prio:10):. zebra2018/10/18 17:59:30 warnings: ZEBRA: [EC 4043309104] Disabling MPLS support (no kernel support) . babeldThere is same network configuration eth0 There is same network configuration eth1 There is same network configuration eth2 eth0 : common interface 10.1.1.231-10.1.1.232 eth1: seperate interface 192.168.20.1 / 192.168.21.1 eth2: common interface 192.168.30.1 / 192.168.30.2 Here is the routing : 0.0.0.0 10.1.1.1 0.0.0.0 UG 0 0 0 eth0 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.30.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 after a second 0.0.0.0 10.1.1.1 0.0.0.0 UG 0 0 0 eth0 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.21.0 10.1.1.232 255.255.255.0 UG 0 0 0 eth0 192.168.30.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 As you see routing seem ok after a second.. but on next second it dissapears. So do ping.. PING 192.168.21.1 (192.168.21.1) 56(84) bytes of data. ping: sendmsg: Network is unreachable 64 bytes from 192.168.21.1: icmp_seq=4 ttl=64 time=1.58 ms 64 bytes from 192.168.21.1: icmp_seq=6 ttl=64 time=0.751 ms ping: sendmsg: Network is unreachable 64 bytes from 192.168.21.1: icmp_seq=8 ttl=64 time=0.868 ms Here is the output of babel interface ospfd-3# sh babel route 10.1.1.0/24 metric 65535 refmetric 0 id f2:e7:01:ff:fe:4e:47:eb seqno 52317 age 2 via eth1 neigh fe80::986c:adff:fef9:5113 nexthop 192.168.21.1 (feasible) 10.1.1.0/24 metric 65535 refmetric 0 id f2:e7:01:ff:fe:4e:47:eb seqno 52318 age 1 via eth2 neigh fe80::9885:8cff:fe66:8028 nexthop 192.168.30.2 (feasible) 192.168.21.0/24 metric 65535 refmetric 0 id f2:e7:01:ff:fe:4e:47:eb seqno 52318 age 1 via eth1 neigh fe80::986c:adff:fef9:5113 nexthop 192.168.21.1 (installed) 192.168.21.0/24 metric 65535 refmetric 0 id f2:e7:01:ff:fe:4e:47:eb seqno 52318 age 1 via eth2 neigh fe80::9885:8cff:fe66:8028 nexthop 192.168.30.2 (feasible) 192.168.30.0/24 metric 65535 refmetric 0 id f2:e7:01:ff:fe:4e:47:eb seqno 52317 age 2 via eth1 neigh fe80::986c:adff:fef9:5113 nexthop 192.168.21.1 (feasible) 192.168.30.0/24 metric 65535 refmetric 0 id f2:e7:01:ff:fe:4e:47:eb seqno 52318 age 1 via eth2 neigh fe80::9885:8cff:fe66:8028 nexthop 192.168.30.2 (feasible) 10.1.1.0/24 metric 0 (exported) 192.168.20.0/24 metric 0 (exported) 192.168.30.0/24 metric 0 (exported)

1 1

6.0 release
by Donald Sharp 19 Oct '18

19 Oct '18

All - We have released 6.0 of FRROUTING: Changes of 6.0 over 5.0: Staticd: New daemon responsible for management of static routes ISISd: Implement dst-src routing as per draft-ietf-isis-ipv6-dst-src-routing BFDd: new daemon for BFD (Bidrectional Forwarding Detection). Responsible for notifying link changes to make routing protocols converge faster. Ubuntu 12.04 is no longer supported (FRR 5.x is last supported version for it) various bug fixes The release images can be found here, with additional documentation: https://github.com/FRRouting/frr/releases I'd like to thank everyone involved in the effort over the last 4 months in getting this released. thanks! donald

2 1

EIGRP authentication issues
by Heikki Lavaste 18 Oct '18

18 Oct '18

Hi, If I try to enable authentication for EIGRP, --> FRR-1(config-if)# ip authentication key-chain eigrp 100 test, │ I get the following error: " Key chain with specified name not found" Running config: hostname FRR-1 service integrated-vtysh-config ! key chain test key 1 key-string testing ! interface eth2 ip address 192.168.2.1/24 ! interface eth4 ip address 192.168.200.2/24 ! router eigrp 100 network 100.100.100.0/24 network 192.168.2.0/24 rpm -qa | grep frr │ frr-pythontools-6.0-001.el7.centos.x86_64 │ frr-6.0-001.el7.centos.x86_64 CentOS Linux release 7.5.1804 (Core) The command seems to be there, even though not mentioned in the Docs, ( only for RIP). Should this work? Kind Regards Heikki Lavaste

3 2

Oddity with BGP and v6 multipath in 5.0.1
by Nigel Kukard 17 Oct '18

17 Oct '18

Hi guys, Maybe I'm missing something here, but this looks a bit odd... -- check these v6 bgp entries, they're right ... --- xx-01-xx.xx.xx.net# show bgp ipv6 2001:nn:5600:2600::700 BGP routing table entry for 2001:nn::/32 Paths: (6 available,*best #1*, table Default-IP-Routing-Table) 6939 20860 2001:mm:1f1::108 from 2001:mm:1f1::108 (xx.252.112) (fe80::da84:66ff:feeb:6419) (*used*) Origin IGP, *localpref 700*, valid, external, *multipath*, *best* Large Community: 328112:1:710 328112:2:11 328112:2:111 328112:3:3 AddPath ID: RX 0, TX 79328233 Advertised to: 2c0f:mm:0:2::2 2c0f:mm:10:2::1 Last update: Tue Oct 16 21:52:29 2018 6939 20860 2001:mm:6d1::165 from 2001:mm:6d1::165 (xx.252.112) (fe80::da84:66ff:feeb:6415) (*used*) Origin IGP, *localpref 700*, valid, external, *multipath* Large Community: 328112:1:710 328112:2:10 328112:2:101 328112:3:3 AddPath ID: RX 0, TX 79328194 Last update: Tue Oct 16 21:52:29 2018 6939 20860 2c0f:zz:0:2::2 from 2c0f:zz:0:2::2 (xx.60.1) Origin IGP, localpref 300, valid, internal Large Community: 328112:1:710 328112:2:10 328112:2:102 328112:3:3 328112:100:21 AddPath ID: RX 0, TX 45344833 Last update: Mon Oct 15 13:28:45 2018 6939 20860 2c0f:zz:10:2::1 from 2c0f:zz:10:2::1 (xx.60.1) Origin IGP, localpref 300, valid, internal Large Community: 328112:1:710 328112:2:10 328112:2:102 328112:3:3 328112:100:21 AddPath ID: RX 0, TX 45344474 Last update: Mon Oct 15 13:28:45 2018 [2 more entries removed] -- from vtysh the routes look right too ... -- xx-01-xx.xx.xx.net# show ip route 2001:nn:5600:2600::700 Routing entry for 2001:nn::/32 Known via "bgp", distance 20, metric 0, best Last update 10:55:53 ago * fe80::da84:66ff:feeb:6419, via e2p0v0 * fe80::da84:66ff:feeb:6415, via e1p0v0 -- check these routes ... for some odd reason, the above vtysh commands picked /32 , but thats not the entire issue -- nkukard@xx-01-xx:~# ip -6 route | grep 2001:nn *2001:nn:3333::/48 *via 2c0f:zz:0:2::2 dev e1p1v0.400 proto 186 metric 20 pref medium *2001:nn:3333::/48* via 2c0f:zz:10:2::1 dev e2p1v0.401 proto 186 metric 20 pref medium *2001:nn:3333::/48 *via fe80::da84:66ff:feeb:6415 dev e1p0v0 proto 186 metric 20 pref medium *2001:nn:3333::/48* via fe80::da84:66ff:feeb:6419 dev e2p0v0 proto 186 metric 20 pref medium 2001:nn::/32 via fe80::da84:66ff:feeb:6419 dev e2p0v0 proto 186 metric 20 pref medium 2001:nn::/32 via fe80::da84:66ff:feeb:6415 dev e1p0v0 proto 186 metric 20 pref medium The routes are not being created as multi-path, and routes which should not be active are added. Possibly a mismatch between the add and remove? -N For interest sake, here is the output of the /48 ... -- here is the output for /48 -- xx-01-xx.xx.xx.net# show bgp ipv6 2001:nn:3333::/48 BGP routing table entry for 2001:nn:3333::/48 Paths: (6 available, *best #2*, table Default-IP-Routing-Table) 6939 3356 2001:mm:1f1::108 from 2001:mm:1f1::108 (xx.252.112) (fe80::da84:66ff:feeb:6419) (*used*) Origin IGP, localpref 700, valid, external, *multipath* Large Community: 328112:1:710 328112:2:11 328112:2:111 328112:3:3 AddPath ID: RX 0, TX 79816612 Last update: Tue Oct 16 22:07:13 2018 6939 3356 2001:mm:6d1::165 from 2001:mm:6d1::165 (xx.252.112) (fe80::da84:66ff:feeb:6415) (*used*) Origin IGP, localpref 700, valid, external, *multipath*, *best* Large Community: 328112:1:710 328112:2:10 328112:2:101 328112:3:3 AddPath ID: RX 0, TX 79816391 Advertised to: 2c0f:f3c8:0:2::2 2c0f:f3c8:10:2::1 Last update: Tue Oct 16 22:07:13 2018 6939 3356 2c0f:zz:10:2::1 from 2c0f:zz:10:2::1 (xx.60.1) Origin IGP, localpref 300, valid, internal Large Community: 328112:1:710 328112:2:11 328112:2:112 328112:3:3 328112:100:21 AddPath ID: RX 0, TX 5886849 Last update: Mon Oct 15 13:28:50 2018 37271 3356 2c0f:mm:200:2:2::22 from 2c0f:mm:200:2:2::22 (xx.189.115) (fe80::b2aa:77ff:fe32:40bf) (used) Origin IGP, metric 401, localpref 50, valid, external Community: 3356:2 3356:22 3356:123 3356:500 3356:601 3356:2064 37271:5002 37271:5100 37271:5101 Large Community: 328112:1:710 328112:3:4 328112:3:403 328112:3:4031 AddPath ID: RX 0, TX 549813 Last update: Thu Sep 20 04:13:21 2018 6939 3356 2c0f:zz:0:2::2 from 2c0f:zz:0:2::2 (xx.60.1) Origin IGP, localpref 300, valid, internal Large Community: 328112:1:710 328112:2:11 328112:2:112 328112:3:3 328112:100:21 AddPath ID: RX 0, TX 172320 Last update: Mon Oct 15 13:28:50 2018 37100 37100 3356 2c0f:mm:c:2::b5 from 2c0f:mm:c:2::b5 (xx.0.151) (fe80::86b5:9c07:e2fd:cc80) (used) Origin IGP, localpref 50, valid, external Community: 37100:1 37100:13 Large Community: 328112:1:710 328112:3:4 328112:3:401 328112:3:4011 AddPath ID: RX 0, TX 14726 Last update: Tue Sep 18 22:20:34 2018 -- lets see what the routes look like from vtysh ... looks good ... --- xx-01-xx.xx.xx.net# show ip route 2001:nn:3333::/48 Routing entry for 2001:nn:3333::/48 Known via "bgp", distance 20, metric 0, best Last update 10:51:35 ago * fe80::da84:66ff:feeb:6415, via e1p0v0 * fe80::da84:66ff:feeb:6419, via e2p0v0

1 0

/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 04 Oct '18

04 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