Troubleshooting Neighbor Relationships

It is important to understand that simply enabling EIGRP between two or more routers does not guarantee that a neighbor relationship will be established. In addition to certain parameters matching, addition factors can also result in a failure of EIGRP neighbor relationship establishment. The EIGRP neighbor relationship may not establish due to any of the following:

1. The neighbor routers are not on a common subnet
2. Mismatched primary and secondary subnets
3. Mismatched K Values
4. Mismatched AS Number
5. Access Control Lists are filtering EIGRP packets
6. Physical Layer Issues
7. Data Link Layer Issues
8. Mismatched Authentication Parameters

Uncommon subnet issues are one of the most common problems experienced when attempting to establish EIGRP neighbor relationships. When EIGRP cannot establish a neighbor relationship because of an uncommon subnet, the following error message will be printed on the console or will be logged by the router or switch:

The most common reason for the neighbor routers being on an uncommon subnet is due to a misconfiguration issue. It may be that the router interfaces have accidentally been configured on two different subnets. However, if the neighbors are connected via a VLAN, it is possible that Multicast packets could be leaking between VLANs, resulting in this error. The first troubleshooting step, however, would simply be to verify the interface configuration on the devices. Following this, additional troubleshooting steps, such as VLAN troubleshooting (if applicable) could be undertaken to isolate and resolve the issue.

Another common reason for this error message is using secondary addresses when attempting to establish EIGRP neighbor relationships. Again, the simplest way to troubleshoot such issues is to verify the router or switch configurations. For example, assume the error message above was being printed on the console of the local router. The first troubleshooting step would be to validate the IP addresses configured on the interface as follows:

Next, validate the configuration is the same on the device with the IP address 150.1.1.2:

From the output above, we can see that the primary subnet on R1 is the secondary subnet on the local router. EIGRP will not establish neighbor relationships using a secondary address. The resolution for this issue would simply be to correct the IP addressing configuration under the FastEthernet0/0 interface of R2 as follows:

EIGRP K values are constants that are used to distribute weight to different path aspects, which may be included in the composite EIGRP metric. The default values for the K values are K1 = K3 = 1 and K2 = K4 = K5 = 0. If changed on one router or switch, these values must be adjusted for all other routers or switches within the autonomous system. The default EIGRP K values can be viewed using the show ip protocols command as illustrated below:

When K values are reset on a router, all neighbor relationships for the local router will be reset. If the values are not consistent on all routers following the reset, the following error message will be printed on the console and the EIGRP neighbor relationship(s) will not be established:

NOTE: While EIGRP K values can be adjusted using the metric-weights command, this is not recommended without assistance from seasoned network engineers or the TAC.

Unlike OSPF, which uses a locally significant process ID, EIGRP requires the same autonomous system number (amongst other variables) when establishing neighbor relationships with other routers. Troubleshoot such issues by comparing devices configurations and ensuring that the autonomous system number (amongst other variables) is consistent between routers that should establish neighbor relationships. A good indicator that neighbors are in a different autonomous system would be a lack of bi-directional Hellos even in the presence of basic IP connectivity between the routers. This can be validated using the show ip eigrp trafficcommand, the output of which is illustrated in the section that follows.

ACLs and other filters are also common causes for routers failing to establish EIGRP neighbor relationships. Check router configurations and as well those of intermediate devices to ensure that EIGRP or Multicast packets are not filtered. A very useful troubleshooting command to use is the show ip eigrp traffic command. This command provides statistics on all EIGRP packets. Assume, for example, that you have verified basic connectivity and configurations between two devices, but the EIGRP neighbor relationship is still not up. In that case, you could use this command to check to see if the routers are exchanging Hello packets, before enabling debugging on the local device as illustrated below:

In the output above, notice that the local router has not received any Hello packets, although it has sent out 144 Hellos. Assuming that you have verified IP connectivity between the two devices, as well as the configuration, you could also check ACL configurations on the local routers, as well as intermediate devices (if applicable) to ensure that EIGRP or Multicast traffic is not being filtered. For example, you might find an ACL that is configured to deny Class D and Class E traffic while allowing all other traffic, such as the following ACL:

Physical and Data Link layer issues and how these can affect routing protocols and other traffic have been described in detail in previous chapters. You can troubleshoot these issues using theshow interfaces, show interfaces counters, show vlan, and show spanning-treecommands amongst the other described in those chapters. To avoid being redundant, we will not restate the Physical and Data Link layer troubleshooting steps.

And finally, common authentication configuration mistakes include using different key IDs when configuring key chains, and specifying different or mismatched passwords. When authentication is enabled under an interface, the EIGRP neighbor relationships are reset and reinitialized. If previously established neighbor relationships do not come up following authentication implementation, verify the authentication configuration parameters by looking at the running configuration or using the show key chain and show ip eigrp interfaces detail [name]commands on the router. Following is a sample output of the information that is printed by theshow key chain command:

Following is a sample output of the information that is printed by the show ip eigrp interfaces detail [name] command:

When troubleshooting in general, it is recommended that you use show commands in Cisco IOS software instead of enabling debug commands. While debugging provides real-time information, it is very processor intensive and could result in high CPU utilization of the device and in some cases, even crash the device. In addition to show commands, you should also pay attention to the various error messages that are printed by the software, as these provide useful information that can be used to troubleshoot and isolate the root cause of the problem.