FRRouting Software with EIGRP Support

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.