Routing Protocol Security
Enhanced interior gateway routing protocol (EIGRP) is one of the most used routing
protocols in enterprise networks. It is a Cisco proprietary protocol, with the good and the bad
that comes with it.
The above articles provide in-depth information about EIGRP operation and they help you to
understand better how EIGRP is working. Also, some of the above articles show you how to
configure EIGRP features. However, due to the packet tracer limitations, they show how only
a few are supposed to be configured.
This article continues, if you like, the packet tracer lab and doesn’t repeat the information
presented there.
The topology used for this article and for simulation is below:
The purpose of the lab is that the EIGRP should be configured in a way that follows the
design constraints and allows the hosts to reach other.
These are the constraints:
• Both routers should use only bandwidth as the metric when the cost for the best route
is calculated.
• R1 should reach 10.10.2.0/24 through F2/0 interface. In case F2/0 is down, then R1
should failover to F1/0 automatically.
• R2 should reach 10.10.1.0/24 through F0/0 interface. In case F0/0 is down, then R2
should failover to F2/0 automatically.
• The link over 10.10.12.0/24 network should be authenticated.
If you decide to download the files used for this article, then please adapt the path to the
router’s configuration file in the GNS3 topology file.
Once the topology is loaded and all the devices are powered on, the next step would be
configure the two hosts (PC_1 and PC_2) with IP addresses and default gateway.
Before you can configure the hosts, you should know that they are emulated using a
lightweight version of Linux. You can download it from here:
http://sourceforge.net/projects/gns-3/files/Qemu%20Appliances/linux-microcore-3.8.2.img.
Once you downloaded it, you need to configure GNS3. Go to Edit – Preferences – Qemu.
You should have something similar to the figure below. Keep in mind that the path location
might be different, depending on where you decided to store the Linux image.
Once you start the hosts, since the configuration doesn’t survive any device power-off, you
will need to configure the IP address on eth0 of each host and the default gateway pointing to
the router to which they are connected as shown on the diagram.
Keep in mind that using “tc” as username when you access the hosts using the console will
log you in directly to shell without asking for any password.
This is needed on PC_2 to change the hostname, to add the right IP address on eth0, and add
the default route pointing to R1. Do the similar configuration on PC_1.
For the purpose of this lab, you should just paste this configuration on R1 and R2; I will
explain what the configuration is doing and how to check the operation of EIGRP.
On R1:
R1#show running-config | section router
router eigrp 100
passive-interface FastEthernet0/0
network 10.10.1.1 0.0.0.0
network 10.10.12.1 0.0.0.0
network 10.10.21.1 0.0.0.0
metric weights 0 1 0 0 0 0
no auto-summary
R1#
R1#show running interface F1/0
Building configuration...
Current configuration : 190 bytes
!
interface FastEthernet1/0
bandwidth 10
ip address 10.10.21.1 255.255.255.0
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 KEY
duplex auto
speed auto
end
R1#
R1#show running-config | section key
key chain KEY
key 1
key-string cisco-eigrp
ip authentication key-chain eigrp 100 KEY
R1#\
On R2:
R2#show running-config | section router
router eigrp 100
passive-interface FastEthernet1/0
network 10.10.2.1 0.0.0.0
network 10.10.12.2 0.0.0.0
network 10.10.21.2 0.0.0.0
metric weights 0 1 0 0 0 0
no auto-summary
R2#
R2#show running interface F0/0
Building configuration...
Current configuration : 176 bytes
!
interface FastEthernet0/0
ip address 10.10.21.2 255.255.255.0
ip authentication mode eigrp 100 md5
ip authentication key-chain eigrp 100 KEY
duplex auto
speed auto
end
R2#
R2#show running-config | section key
key chain KEY
key 1
key-string cisco-eigrp
ip authentication key-chain eigrp 100 KEY
R2#
After this is configured, it’s time to check the EIGRP operation.
We need to make sure that R1 and R2 are neighbors twice, once for each of the two links
between them:
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.10.21.2 Fa1/0 10 01:07:21 28 5000 0 52
0 10.10.12.2 Fa2/0 14 01:16:38 105 630 0 51
R1#
The first constraint was to have EIGRP DUAL algorithm choose one link over the other one.
Let’s check and confirm that R1 prefers the route learned via F2/0 towards PC_1:
R1#show ip route 10.10.2.0
Routing entry for 10.10.2.0/24
Known via "eigrp 100", distance 90, metric 25600, type internal
Redistributing via eigrp 100
Last update from 10.10.12.2 on FastEthernet2/0, 00:00:22 ago
Routing Descriptor Blocks:
* 10.10.12.2, from 10.10.12.2, 00:00:22 ago, via FastEthernet2/0
Route metric is 25600, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R1#
Similar, we should see that R2 prefers the F0/0 interface towards PC_1:
R2#show ip route 10.10.1.0 | i FastEthernet0/0
Last update from 10.10.21.1 on FastEthernet0/0, 00:02:57 ago
* 10.10.21.1, from 10.10.21.1, 00:02:57 ago, via FastEthernet0/0
R2#
How is this possible?
Well, it’s because on the interface that we want to keep as a backup (F1/0 in the case of R1),
we configured the bandwidth of 10Kb, which is less preferable that the default value of
100000Kb that F2/0 has):
R1#show interfaces F1/0 | i BW
MTU 1500 bytes, BW 10 Kbit, DLY 100 usec,
R1#show interfaces F2/0 | i BW
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
R1#
Let’s shutdown the interface F2/0 on R1 and confirm that the route towards PC_2 is still
present in the routing table:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface FastEthernet2/0
R1(config-if)#shut
R1(config-if)#
*Mar 1 00:17:30.223: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
10.10.12.2 (FastEthernet2/0) is down: interface down
R1(config-if)#end
R1#
*Mar 1 00:17:32.139: %LINK-5-CHANGED: Interface FastEthernet2/0, changed
state to administratively down
*Mar 1 00:17:32.691: %SYS-5-CONFIG_I: Configured from console by console
*Mar 1 00:17:33.139: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet2/0, changed state to down
R1#show ip route 10.10.2.0 | i FastEthernet1/0
Last update from 10.10.21.2 on FastEthernet1/0, 00:00:38 ago
* 10.10.21.2, from 10.10.21.2, 00:00:38 ago, via FastEthernet1/0
R1#
When the failover happens, in this particular case, there is no route recalculation because the
feasibility condition is met and EIGRP keeps in its topology table the second successor
(which in this case is the same router, but on another link). As you can see on R1, we have
both routes in the topology table, but because the route with next-hop of 10.10.21.2 has a
higher metric than the route with the next-hop of 10.10.12.2, only the first next-hop is placed
in the routing table:
R1#show ip eigrp topology 10.10.2.0/24
IP-EIGRP (AS 100): Topology entry for 10.10.2.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 25600
Routing Descriptor Blocks:
10.10.12.2 (FastEthernet2/0), from 10.10.12.2, Send flag is 0x0
Composite metric is (25600/25600), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.10.21.2 (FastEthernet1/0), from 10.10.21.2, Send flag is 0x0
Composite metric is (256000000/25600), Route is Internal
Vector metric:
Minimum bandwidth is 10 Kbit
Total delay is 200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
R1#
If we deleted the bandwidth knob from either of the routers, we would see that the route will
point to two next-hops/interfaces:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#interface FastEthernet1/0
R1(config-if)#no bandwidth 10
R1(config-if)#end
R1#
*Mar 1 00:49:13.099: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip route 10.10.2.0 | i FastEthernet
Last update from 10.10.21.2 on FastEthernet1/0, 00:00:14 ago
10.10.21.2, from 10.10.21.2, 00:00:14 ago, via FastEthernet1/0
* 10.10.12.2, from 10.10.12.2, 00:00:14 ago, via FastEthernet2/0
R1#
One other constraint was that only bandwidth could be used in the route cost calculation. By
default, bandwidth and delay are used. You should already know how to check which metrics
are used for route cost calculation. This is the default:
R1#show ip protocols | i weight
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
R1#
Under EIGRP protocol configuration, you have this statement: “metric weights 0 1 0 0 0 0.”
This means that only bandwidth metric will be used:
R1#show ip protocols | i weight
EIGRP metric weight K1=1, K2=0, K3=0, K4=0, K5=0
R1#
Keep in mind that the change affects EIGRP in general and these values must be the same on
all routers on the link. Otherwise, you will see these messages. Fortunately, these messages
speak for themselves, so you shouldn’t have a problem figuring out how to quickly fix an
EIGRP adjacency that doesn’t come up when you have these messages.
*Mar 1 00:47:54.323: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
10.10.21.2 (FastEthernet1/0) is down: Interface Goodbye received
R1(config-router)#
*Mar 1 00:47:56.567: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor
10.10.12.2 (FastEthernet2/0) is down: K-value mismatch
EIGRP supports only MD5 authentication and it’s configured under the interface over which
you want to protect the EIGRP and reference a key chain.
This will show you if any of the interfaces where EIGRP is running is configured with MD5
authentication and what is the key-chain configuration:
R2#show ip eigrp interfaces detail
IP-EIGRP interfaces for process 100
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa2/0 0 0/0 0 64/2432 3912 0
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/3 Un/reliable ucasts: 3/3
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 2
Retransmissions sent: 0 Out-of-sequence rcvd: 0
Authentication mode is not set
Use multicast
Fa0/0 1 0/0 176 0/1 680 0
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/3 Un/reliable ucasts: 6/5
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 1
Authentication mode is md5, key-chain is "KEY"
Use multicast
R2#show key chain KEY
Key-chain KEY:
key 1 -- text "cisco-eigrp"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
R2#
Here are a few reasons why EIGRP adjacencies will not be established:
• Wrong AS number
• Mismatch of K values
• Mismatch in authentication keys
I hope you have found this article interesting and I advise you to repeat the lab to get familiar
with the feature presented here.
After all, repetition is the mother of all learning
References
1. EIGRP Commands
(http://www.cisco.com/c/en/us/td/docs/ios/12_2/iproute/command/reference/fiprrp_r/
1rfeigrp.html#wp1017884)
