In September 2016 I wrote the article about EIGRP support in Quagga network routing suite. More than one year later, I am going to check the progress of development EIGRP in Linux again. To do so, I have installed a fork of Quagga - FRRouting (FRR) with EIGRP support on Linux Core. EIGRP routing daemon included inside FRR benefits from active development brought by Cumulus employees. For the purpose of FRR testing, I have created a minimalistic Linux Core Pure64 virtual machine with FRR suite compiled as frr extension. Meanwhile, I have submitted FRR extension so it will be available in the next few days in Tinycore repository.
Content of Disk - CorePure64-frr_3-1.vmdk:
- Linux Core Pure 64 version 8.2,kernel 4.8.17
- FRRouting 3.1dev
- OpenSSL 1.0.2l 25 May 2017
- OpenSSH_7.2p2
- GNU bash, 4.4.0(1)
- iproute2-ss140411
- iptables v1.4.21
- tcpdump 4.7.4
- Nmap 7.12
- mtr 0.86
- hping 3.0.0-alpha-1
- iperf 3.1b3
- D-ITG 2.8.1 (r1023)
Software:
- Host OS - Ubuntu 16.04.3 LTS x64
- GNS3 2.0.3
- QEMU x64 emulator version 2.8.0
Picture 1 - Network Topology
The FRR EIGRP instance with attached CorePure64-frr_3-1.vmdk disk is running inside GNS3 topology and it has assigned 512MB RAM. They are also two instances Cisco vIOS L3 in the network used for injecting routes towards FRR.
Note: I share my vmdk disk CorePure64-frr_3-1.vmdk (size 68MB). Login is tc and password is tc.
1. Basic Configuration
Initial configuration files for Cisco routers are: vIOS-I and vIOS-II. The configuration of FRR router will be shown later.
Note: Everytime you finish FRR configuration, issue the command below to keep the configuration changes after reboot.
$ /usr/bin/filetool.sh -b
Login with user tc and password tc.
Change the default hostname to FRR.
$ echo "hostname FRR" >> opt/bootlocal.sh
Delete previous configuration of all routing daemons using Linux Core Pure shell.
$ sudo su
# echo > /usr/local/etc/frr/zebra.conf
# echo > /usr/local/etc/frr/ripd.conf
# echo > /usr/local/etc/frr/ripngd.conf
# echo > /usr/local/etc/frr/ospfd.conf
# echo > /usr/local/etc/frr/ospf6d.conf
# echo > /usr/local/etc/frr/ldpd.conf
# echo > /usr/local/etc/frr/bgpd.conf
# echo > /usr/local/etc/frr/isisd.conf
# echo > /usr/local/etc/frr/pimd.conf
# echo > /usr/local/etc/frr/eigrpd.conf
# echo > /usr/local/etc/frr/babeld.conf
Save changes and reboot the box.
$ /usr/bin/filetool.sh -b
# reboot
After reboot, start FRR console and configure Ethernet interfaces and EIGRP daemon.
tc@box:~$ vtysh
Hello, this is FRRouting (version 3.1-dev).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
box# conf t
box(config)# hostname FRR
FRR(config)# interface eth0
FRR(config-if)# ip address 10.10.1.1/24
FRR(config-if)# no shutdown
FRR(config)# interface eth1
FRR(config-if)# ip address 192.168.1.1/24
FRR(config-if)# no shutdown
box(config)# router eigrp 1
box(config-router)# network 10.10.1.0/24
box(config-router)# network 192.168.1.0/24
FRR(config-router)# exit
Exit vtysh shell and save configuration.
$ /usr/bin/filetool.sh -b
Now inspect a routing table (RT) of FRR router. Notice that all the received EIGRP routes are presented in RT.
Picture 2 - FRR Routing Table
Similarly, the both Cisco routers vIOS-I and vIOS-II have installed the routes received from FRR.
Picture 3 - Routing Table of vIOS-II
In a next part, we slightly modify the configuration on all routers in order to check whether FRR reflects the configuration changes and discover possible bugs.
1. FRR Cannot Remove No Longer Advertised Routes from EIGRP Neighbor
Stop announcing the network 192.168.3.0/24 on the router vIOS-I router with the command below .
vIOS-I(config)# router eigrp 1
vIOS-I(config-router)# no network 192.168.3.0
The expected result is a removal of network 192.168.3.0/24 from FRR and vIOS-II routing tables. However, the route is deleted only from a RT of vIOS-II. The router FRR keeps it installed in its routing table forever. We can confirm that the routes are kept also in EIGRP topology table of FRR. This is the first bug we have discovered so far.
Picture 4 - EIGRP Table of FRR Router Keeps Route 192.168.3.0/24
2. Static Default Routes Redistribution Issues
First, we create a default static route on the vIOS-I router pointing toward the interface Gi0/3. Afterwards we will redistribute the static route in two different ways.
vIOS-I(config)# ip route 0.0.0.0 0.0.0.0 GigabitEthernet 0/3
Note: We use the static default route 0.0.0.0/0 in our test however our findings are valid for any static route.
2.1 Redistributing Static Route from vIOS-I Router with Network Command on Cisco Router
Notice that route 0.0.0.0/0 is installed as an internal route in the RT of the router vIOS-II.
Picture 5 - EIGRP Internal Route 0.0.0.0/0 Installed into RT of vIOS-II
The route is also installed in the RT of FRR router. It is not a surprise as the FRR previously installed the EIGRP internal routes (admin distance 90) successfully.
Picture 6 - Routing Table of FRR with Received Static Default Route 0.0.0.0/0
2.2 Redistributing Static Route from vIOS Router with Redistribute Command via EIGRP on Cisco Router
Firstly, we stop announcing the network 0.0.0.0/0 on VIOS-I router. We will redistribute the route with the command redistribute static instead.
vIOS-I(config)# router eigrp 1
vIOS-I(config-router)# no network 0.0.0.0
vIOS-I(config-router)# redistribute static
Inspect a routing table of vIOS-II again and display only the route 0.0.0.0/0.
Picture 7 - Routing Table of Router vIOS-II with Installed Route 0.0.0.0/0
The route 0.0.0.0/0 is installed in RT of vIOS-II but the admin distance for EIGRP route is changed to 170 (external route). However, the RT of FRR is being kept untouched as it is shown on the Picture 6. Knowing that FRR has issue with removing the EIGRP routes, we will reboot FRR and start vtysh shell again.
Picture 8 - Routing Table of FRR Instance After Reboot Without Route 0.0.0.0/0
Although FRR does not install the external EIGRP routes even after reboot of Core Linux, the route 192.168.3.0/24 has gone from RT at least. We have discovered a second bug showing that EIGRP daemon inside FRR cannot install EIGRP external routes.
2.3 FRR Cannot Redistribute Static Routes with Network Command via EIGRP
We are going to check whether FRR can redistribute a static default route pointing to the interface eth1 via EIGRP using the network command. Firstly, remove a static route redistribution command on vIOS-I router.
vIOS-I(config)# router eigrp 1
vIOS-I(config-router)# no redistribute static
Create a static default route 0.0.0.0/0 on FRR router and redistribute it with the network command.
FRR(config)# ip route 0.0.0.0/0 eth1
FRR(config)# router eigrp 1
FRR(config-router)# network 0.0.0.0/0
Picture 9 -Static Default Route Missing in Routing Table of vIOS-II
The static default route created on FRR and redistributed with network command is not presented in routing tables' of both Cisco routers. It is the third discovered bug and a prove that FRR cannot redistribute static routes via EIGRP.
2.4 FRR Cannot Redistributes Static Routes with Redistribute Command via EIGRP
In this test, we will try to redistribute a static default route created on FRR with redistribute static command.
FRR(config)# router eigrp 1
FRR(config-router)# no network 0.0.0.0/0
FRR(config-router)# redistribute static
Again, the route 0.0.0.0/0 is not presented in the EIGRP topology table on both Cisco routers. So far we have proved that EIGRP daemon cannot redistribute the static default route in any way.
Picture 10 - Static Default Route is Missing in EIGRP Table of Router vIOS-I
3. Routes Stays Forever in EIGRP Topology Table of FRR Even Peer is Down
Shutdown vIOS-I router. The router FRR loses EIGRP neighbor 10.10.1.2 (vIOS-I) however the routes received from the peer are kept in EIGRP topology table of FRR.
Picture 11 - FRR Keeps Routes from vIOS-I in EIGRP Table
Notice the unknown next hop IP address 144.80.20.1 in the output. The IP address changes every time the show command is entered.
Picture 12 - EIGRP Table of FRR with Strange Next Hop IP Address 96.79.20.1
4. Segmentation Fault Issues
FRR does not properly sanitize user's inputs. For instance, issue the command below under EIGRP configuration. As a result, you are kicked out from vty shell.
FRR(config-router)# network 0.0.0.0 ?
Picture 13 - FRR Segmentation Fault When User's Input is Not Sanitized
5. EIGRP Daemon Crash
The following command kill the EIGRP daemon process completely.
FRR(config)# interface eth0
FRR(config-if)# eigrp bandwidth 1000
Picture 14 - EIGRP Daemon Crash
Conclusion
EIGRP daemon inside FRRouting is partially operational but it is not ready for use in a real environment. The good news is that EIGRP is under active development thus existing bugs might be fixed in the next FRRrouting release.
Nice work.
Have you posted all those bugs on their github https://github.com/frrouting/frr/issues?
Nope but I sent en email to one developer with a reference to the article.
Hi Radovan,
Thanks for your article and submitting the frr extension to the TCL repo.
I'm trying to compile frr for x86 arch, but get stuck with configure with the following failure:
checking for perl module XML::LibXML... no
configure: error: XML::LibXML perl module not found and pregenerated ldp_vty_cmds.c missing
How did you get passed this?
Hi Radovan,
Managed to get passed this issue using:
http://search.cpan.org/CPAN/authors/id/S/SH/SHLOMIF/XML-LibXML-2.0132.tar.gz
Glad, that you've resolved the issue. Not really sure, but I guess I had to disable llldp to get through XML::LibXML dependency. Below is the list of all my dependencies in case anyone is interested. Thx for your input.
compiletc
readline
readline-dev
perl5
json-c-dev
python3.6-dev
c-ares-dev
ipv6-KERNEL.tcz
autoconf
automake
libtool
libtool-dev
Additional configure options:
* --prefix=/usr/local
* --enable-vtysh
* --enable-pimd
* --enable-multipath=18
* --sysconfdir=/usr/local/etc/frr
* --localstatedir=/usr/local/var/frr
* --enable-rtadv
* --enable-user=tc
* --enable-group=staff
* --enable-vty-group=staff
* --disable-docf
* --disable-ldpd
This is an excellent analysis with several well-defined use cases, and confirms my own results.
EIGRP on FRR simply does not work in the same full featured way one would expect. It is a proprietary protocol, so that might play a role.
If I could find a way to install a default route via EIGRP I would be 99% of the way to where I need to go.
Naturally, OSFP works fine, but I don't have an OSPF network.
Thanks for your hard work and great design of your proof of concept.