In May 2013, Cisco opened its proprietary EIGRP protocol and released an informational RFC 7868 - Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP). It gives other vendors an opportunity to implement EIGRP protocol into their devices. A group students led by an assistant professor and Cisco CCIE Peter Paluch who used to be an instructor trainer at the Faculty of Management Science and Informatics, University of Zilina, Slovakia implemented EIGRP support into Quagga routing software.
The goal of this tutorial is to provide a VMware vmdk disk with installed Linux Core and Quagga which supports Cisco EIGRP protocol. The image can be used to test compatibility between EIGRP configured on native Cisco devices and an implementation of EIGRP daemon in Quagga . I also share my findings about issues that I have noticed during my tests.
You can download Linux Core VMDK disk with installed Quagga 0.99.24 with EIGRP support.
How did I create Quagga Qemu Image with EIGRP Support
I installed Linux Core 7.2 to Qemu virtual machine and remastered Core for sending output to a serial port according to this article. I download Quagga version which supports EIGRP from github and I installed it from source. Afterwards I created Linux Core Quagga extension. I did not submit Quagga extension to Tinycore repository for following reasons. Firstly, EIGRP daemon has not been yet merged to the main branch of Quagga. A current Quagga version with EIGRP support on released on github is based on the old Quagga version 0.99.24-rc1. Secondly, Zebra daemon responsible for putting routes into Linux routing table occasionally does not install received routes although routes are presented in EIGRP topology table.
Finally I installed Core extensions such as tcpdump, ipv6, netfilter etc. and enabled forwarding IPv4 and IPv6 packets between interfaces. The list of installed extensions can be checked with the command:
$ ls /mnt/sda1/tce/optional/
Routing daemons are started during the boot of Core Linux. They are placed in a start-up file /opt/boot/bootlocal.sh. Comment a line for a particular routing daemon if you do not need it. The list of running daemons and ports are shown in the file below.
root@box:/home/tc# netstat -atpn | grep 0.0.0.0 > ports.txt
Testing Topology Description
The are three routers are running inside GNS3 project. A router eigrp-core-1 x86-64 is Linux Core 7.2 with Quagga compiled for EIGRP support. Routers vIOS-1 and v-IOS-2 are Cisco Virtual IOS L3 routers. The Qemu emulator is used as a hypervisor for all routers.
Picture 1 - Network Topology
The list of used software is available here.
Configuration
To configure EIGRP, telnet to eigrp daemon running on port 2609. Password configured in the EIGRP configuration file /usr/local/etc/quagga/eigrpd.conf is set to quagga.
tc@box:~$ telnet localhost 2609
Configuration files for router are eigrp-core-1.txt, vIOS-1, vIOS-2.txt.
To save Quagga and vIOS routers' configuration, type the write command from privileged exec mode. Each routing daemon has it own file.
/usr/local/etc/quagga/eigrpd.conf
/usr/local/etc/quagga/zebra.conf
To save configuration change stored inside a configuration file own by a particular routing daemon, run a script below. The script is responsible for saving all files located in a directory /usr/local/etc/quagga. This is a requirement of Linux Core .
tc@box:~$ /usr/bin/filetool.sh -b
Note: To save an another file or a directory, simply add the path to a file /opt/.filetool.lst and run the command /usr/bin/filetool.sh -b.
Issues
1. EIGRP configuration is not correctly implemented in Quagga Vtysh shell
Even the command router eigrp is presented in the configuration mode of Quagga vtysh, the EIGRP daemon configuration is not properly implemented in vtysh. Here is the prove.
2. Zebra does not install received routes
Sometimes Zebra does not install received routes into a Core Linux routing table. However routes are presented in EIGRP Topology Table.
Picture 2 - Missing Received Routes in Linux Routing Table
The picture below proves that routes are presented in EIGRP Topology Table.
Picture 3 - Routes are Presented in EIGRP Topology Table
I noticed this issue is always happening when EIGRP daemon is started right after Zebra daemon during the Core boot. As a workaround I postponed starting EIGRP daemon about 20 seconds in /opt/bootlocal.sh. But sometimes routes are not inserted to a Linux routing table. Below are EIGRP debugs captured on vIOS-1 router and captured EIGRP traffic on Linux Core. The router vIOS-2 is switched off but a network 10.10.2.0/24 is presented in a routing table of vIOS-1 as interface Gi0/1 is up/up state due to using an Qemu emulator.
a) EIGRP debugs on vIOS-1 when routes are installed into Linux routing table
In this case, Zebra successfully installs received routes in to to Core Linux routing table. Notice that once EIGRP neighbor adjacency between Quagga (10.10.1.1) and vIOS-1 (10.10.1.2) is established, Quagga restart EIGRP neighbor adjacency for unknown reason. After restart, adjacency is again established between EIGRP peers. I made about 20 tests and I realized that routes are inserted to Linux routing table only when Quagga restarts EIGRP neighbor adjacency.
Click on the command to show captured debug on vIOS-1 when received routes are installed in a Linux Core routing table.
vIOS-1# debug ip eigrp
vIOS-1# debug ip eigrp notifications
vIOS-1# debug ip eigrp neigbour
b) EIGRP debugs on vIOS-1 when routes are not installed into Linux routing table
vIOS-1# debug ip eigrp unsuccesfull
vIOS-1# debug ip eigrp notifications
vIOS-1# debug ip eigrp neighbour
Conlusion
EIGRP support in Quagga routing software is still in development. They are some the bugs presented but they will be resolved in the future. Thanks to great effort of Slovak students, EIGRP in Linux have become a reality.
Thanks for the blog entry. I stumbled across this entry while testing the EIGRP support in the Quagga recently.
I too have run into the same issues ... although starting the EIGRP daemon even 1 minute later than the zebra daemon did not help - i.e. some of the routes are not installed into the kernel routing table.
There are also a few commands which are not implemented - i.e. left as skeleton entries returning success (which might fool the user into believing that that they worked). Not sure if the code is actively maintained anymore - some more reliability testing would not hurt, but I understand if this is left "as is" (since it seemed to have been a university project).
Is egrp working in frr? i tired with the latest code base trying to run in a mininet environment and could not get the hosts to ping although the neighbor entries looked good.
Can anyone give the latest update on this?