Network up-time is very important in real time networking; any breakdown in network services may cause a big loss. It is always the first priority of a Network Engineer to provide 100% up-time for network services, so if any breakdown occurs, it should be resolved quickly.
You can resolve network issues quickly only if you have enough knowledge to face network problems. In this article, we will learn about the most common issues with real time EIGRP so that you can easily rectify those problems in a very short time.
Enhanced Interior Gateway Routing Protocol (EIGRP) is a well-known advanced distance vector IGP routing protocol, with rapid convergence thanks to Dual Algorithm. EIGRP uses IP protocol 88 and uses a multicast address of 126.96.36.199 for hellos and routing updates.
Troubleshooting EIGRP is not so complex if we know the most common causes of EIGRP issues.
Common Neighbor Stability Problems
Neighbor must be configured with same EIGRP Process-ID.
Primary Subnet must be same for EIGRP neighbors.
K-values must match on EIGRP neighbors.
Authentication must be properly implemented (if configured).
Physical Link Reachability
Hold time must be greater than Hello interval.
Misconfigured Route-Filtering Technologies (ACLs , Route-Maps , Prefix-Lists)
I have created a GNS3 topology for you as shown in Fig.1 so that you can get the GNS3 file from the Download Link posted here and start with the configuration described in this article.
In this GNS3 lab, you will begin by preloading configuration scripts on each of the routers. These scripts contain errors that will prevent end-to-end communication across the network. You will need to troubleshoot each router to determine the configuration errors, and then use the appropriate commands to correct the configurations. When you have corrected all of the configuration errors, all of the loopbacks on the network should be able to communicate with each other.
Upon completion of this lab, you will be able to troubleshoot and resolve:
- EIGRP split-horizon issues
- EIGRP authentication issues
- Redistribution issues with EIGRP
- EIGRP neighbor-ship flapping issue
- K-values mismatch issues with EIGRP
You should also be able to:
- Gather information about the misconfigured portion of the network along with any other errors.
- Analyse information to determine why communication is not possible.
- Implement solutions to resolve network errors.
Okay, let’s start. Open GNS3 Topology and turn on all the devices. If you go to Router HQ2, you will see that you have no reachability with HQ3’s loopback, i.e. 188.8.131.52, because 184.108.40.206 is missing from HQ2’s routing table as in Fig. 2 below:
Why are you not getting 220.127.116.11 in HQ2’s routing table even when you have active neighbor-ships between HQ1 – HQ2 and HQ1 – HQ3 as per the scenario? To check your neighbor-ship status, use “sh ip eigrp neighbors” on router HQ1. You will get the result shown in Fig. 3, which means EIGRP neighbor-ship is proper on HQ1 for HQ2 and HQ3, but R2 is not in neighbor table. We will consider the neighbor-ship problem between R2-HQ1 later on; first we will resolve the LAN EIGRP issue.
If you check EIGRP configuration on Routers HQ1-HQ2-HQ3 you will find everything is fine, so what is the problem? The problem is Split-Horizon. “Never advertise a route out of the interface through which you learned it” and you know very well split-horizon is enabled by default in EIGRP. So, disable split-horizon on interface f0/0 of Router HQ1 using the commands described below:
HQ1(config)#int f0/0 HQ1(config-if)#no ip split-horizon eigrp 100
Instantly, you will get following log messages for neighbor resynchronisation:
*Mar 1 02:03:02.843: %DUAL-5-NBRCHANGE: IP-EIGRP (0) 100: Neighbor 192.168.1.3 (FastEthernet0/0) is resync: split horizon changed *Mar 1 02:03:02.847: %DUAL-5-NBRCHANGE: IP-EIGRP (0) 100: Neighbor 192.168.1.2 (FastEthernet0/0) is resync: split horizon changed
Now check your routing database on Router HQ2 or HQ3. You will definitely get each other’s loopbacks and the reachability as shown in Fig. 4.
Now let’s move on the neighbor-ship problem between HQ1 – R2. If you go through the running configuration it seems fine. EIGRP authentication is configured and looks fine, so try the following debug command on HQ1 which results in mismatched authentication as shown in Fig. 5.
R2#debug eigrp packet
If there is authentication mismatch in log messages, it means the key id or key-string is not properly configured.
You can use “show key chain” on R2 & HQ1 as in Fig. 6.
Everything seems fine but if you examine the key-strings closely, they are not same. Change it to CC1E (CC “one” E) on R2 and you will get your neighbor-ship up.
Now, if you consider the routing database in Fig. 4, you will see that you are not getting any OSPF network, which means some problem with redistribution, so let’s check the configuration on R2 using “show run” command:
! router eigrp 100 redistribute ospf 1 /* metric is missing network 10.2.2.1 0.0.0.0 network 18.104.22.168 0.0.0.0 no auto-summary ! router ospf 1 log-adjacency-changes redistribute eigrp 100 subnets /* metric value is optional, here it will take 20 by default network 22.214.171.124 0.0.0.0 area 1 !
I know you got it: yes, under EIGRP 100, OSPF is not properly redistributed and metric values are missing. Configure metric values for proper redistribution like so:
R2(config)#router eigrp 100 R2(config-router)# redistribute ospf 1 metric 10000 1000 100 100 1500
After using the above configuration you will get all OSPF networks in the routing table of HQ2 as follows:
D EX 10.1.1.1 [170/2451456] via 192.168.1.1, 00:00:08, FastEthernet0/0 D EX 126.96.36.199 [170/2451456] via 192.168.1.1, 00:00:08, FastEthernet0/0
Now you have full reachability as per the requirement. To check, go to R1 and ping loopback ip of R2, HQ2 and HQ3.
Ok let’s consider some more causes for EIGRP neighbor-ship stability.
EIGRP Hold Interval Must be Greater than Hello I
By default, hello interval is 5 seconds and hold interval is 15 seconds for fast links, but for slow links, they are 60 seconds and 180 seconds, respectively. You can change EIGRP hello/hold timer on interface basis as follows:
HQ1(config)#int s0/0 HQ1(config-if)#ip hello-interval eigrp 100 <1-65535>seconds
To change hold-time in EIGRP, use the following commands:
HQ1(config)#int s0/0 HQ1(config-if)#ip hold-time eigrp 100 <1-65535>seconds
We will change the EIGRP hold timer on HQ1 for R2 because HQ1-R2 is connected with a serial link if you change the hold timer on HQ1’s S0/0 to any value less than the hello interval. Let’s take 4 seconds so we can get neighbor-ship flapping quickly.
HQ1(config)#int s0/0 HQ1(config-if)#ip hold-time eigrp 100 4
After configuring the above commands, you will get the following logs for neighbor-ship flapping:
*Mar 1 00:19:23.999: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 188.8.131.52 (Serial0/0) is down: Interface Goodbye received *Mar 1 00:19:24.339: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 184.108.40.206 (Serial0/0) is up: new adjacency *Mar 1 00:19:28.827: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 220.127.116.11 (Serial0/0) is down: Interface Goodbye received *Mar 1 00:19:29.091: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 18.104.22.168 (Serial0/0) is up: new adjacency *Mar 1 00:19:38.299: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 22.214.171.124 (Serial0/0) is down: Interface Goodbye received
Now you know that if the hold timer is less than the hello interval, EIGRP neighbor-ship starts flapping.
K-Values Must Match between EIGRP Neighbors
K-Values are 5 metric parameters that determine the best route to a destination.
K1 (Bandwidth), K2 (Load), K3 (Delay), K4 (Reliability), K5 (MTU)
By default, only bandwidth and delay participates in EIGRP metric calculation so K1 and K3 is enabled by default.
K1 = 1, K2 = 0, K3 = 1, K4 = 0, K5 = 0
*Each K-value can be configured between 0 to 255.
Using the following commands, you can change the K-values:
HQ1(config)# router eigrp 100 HQ1(config-router)# metric weights 0 1 1 1 0 0 (first zero is for TOS, only 0 is supported)
Fig. 7 displays the output result of “show ip protocols” where you can check K-Values.
If you configure the above commands to change K-values you will see the following log messages on HQ1 for K-value mismatch:
*Mar 1 00:56:25.963: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 126.96.36.199 (Serial0/0) is down: metric changed *Mar 1 00:56:25.983: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.3 (FastEthernet0/0) is down: metric changed *Mar 1 00:56:25.983: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.2 (FastEthernet0/0) is down: metric changed *Mar 1 00:56:29.139: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 188.8.131.52 (Serial0/0) is down: K-value mismatch *Mar 1 00:56:30.667: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.3 (FastEthernet0/0) is down: K-value mismatch *Mar 1 00:56:31.831: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.2 (FastEthernet0/0) is down: K-value mismatch
Useful Show Commands for EIGRP Troubleshooting
show ip eigrp neighbors
: Displays adjacent neighbors, IP addresses/interfaces and hold time of neighbors.
show ip eigrp topology : Displays Successor, Feasible Successor, Feasible Distance(FD), Reported Distance(RD) for each and every link advertised in EIGRP.
show ip protocol : Lets you check EIGRP process-id, status and networks that are being advertised and, most importantly, you can also check K-Values.
- show ip eigrp interfaces : Displays EIGRP enabled interfaces so you can check which interface is configured with EIGRP.
- show ip route eigrp : Displays EIGRP routes that are being received from neighbors and their administrative distances with Metric-Values.
Useful Debugging Commands for EIGRP Troubleshooting
- debug eigrp packet
- debug ip eigrp neighbors
- debug ip eigrp
- debug ip eigrp summary
Your feedback and comments are always welcome. If you like this article, please comment below and also share this article on your Facebook/Twitter to spread the knowledge.
Cisco Certified Internetwork Expert by Wendell Odom and others, Ciscopress.com
Routing TCP/IP Vol 1 by Jeff Doyle
CCNP- Route Quick reference by Denis Donohou, Ciscopress.com
Cisco Certified Internetwork Expert by Wendell Odom and others, Ciscopress.com
Cisco Certified Internetwork Expert Quick reference by Brad Ellis, Ciscopress.com