6 Common issue of EIGRP Neighbor.
1. No multicast transport.
Solution: Set/use unicast.
2. Mismatched AS number.
3. Uni-directional link (one-way-neighborship).
Solution: verify #show ip eigrp neighbor
Smooth round-trip time (SRTT)—The number of milliseconds it takes for an EIGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet
Retransmission timeout (RTO), in milliseconds—The amount of time that the software waits before retransmitting a packet from the retransmission queue to a neighbor
Q count—The number of EIGRP packets (Update, Query, and Reply) that the software is waiting to send
The Q count is not decrementing, which indicates that the router is trying to send EIGRP packets but no acknowledgement is being received. RTR B will retry 16 times to resend the packet; eventually, RTR B will reset the neighbor relationship with the log indicating RETRY LIMIT EXCEEDED, and the process starts again. Also, keep in mind that the 16 times retransmission of the same packet is done using unicast, not multicast. Therefore, the RETRY LIMIT EXCEEDED message indicates a problem with transmitting unicast packets over the link, and this is most likely a Layer 1 or Layer 2 problem.
The solution to this problem is to troubleshoot from a Layer 2 perspective. In this example, a call to the WAN provider is needed to find out why the circuit from RTR B to RTR A is broken. After the link between RTR B to RTR A is fixed, the problem will be resolved. Output from show ip eigrp neighbors in Example 7-2 shows that the neighbor relationship after the WAN link has been fixed.
4. Uncommon Subnet (mismatched IP Address/Subnet)
LOG MESSAGE: IP-EIGRP: Neighbor ip address not on common subnet for
5. K Values – If there’s a minipulation of K values on devices it can afftect the neighbor peer.
For EIGRP to establish its neighbors, the K constant value to manipulate the EIGRP metric must be the same. Refer to Chapter 6 for an explanation of the K values. In EIGRP’s metric calculation, the default for the K value is set so that only the bandwidth and the delay of the interface are used to calculate the EIGRP metric. Many times, the network administrator might want other interface factors, such as load and reliability, to determine the EIGRP metric. Therefore, the K values are changed. Because only bandwidth and delay are used in calculations, the remaining K values are set to a value of 0 by default. However, the K values must be the same for all the routers, or EIGRP won’t establish a neighbor relationship. Figure 7-8 shows an example of this case.’
For the network in Figure 7-8, K1 is bandwidth and K3 is delay. The network administrator changed the K values of RTR B to all 1s from K1 to K4, while RTR A retains the default value of K1 and K3 to be 1. In this example, RTR A and RTR B will not form EIGRP neighbor relationship because the K values don’t match. Example 7-5 shows the configuration for RTR B.
Example 7-5 Configuration for RTR B in Figure 7-8
RTR B#router eigrp 1
metric weights 0 1 1 1 1 0
RTR B’s configuration includes the extra metric weights command. The first number is the type of service (ToS) number, which, because it’s not supported, gets a value of 0. The five numbers after the ToS are the K1 through K5 values.
Troubleshooting this problem requires careful scrutiny of the router’s configuration. The solu-tion for this problem is to change all the K values to be the same on all the neighboring routers. In this example, in Router A, changing the K values to match the K value of Router B will solve the problem, as demonstrated in Example 7-6.
Example 7-6 Configuring the K Values on Router A to Match Router B
RTR A#router eigrp 1
metric weights 0 1 1 1 1 0
6. Stuck in active (SIA) – Network prefix goes from passive to active.
Log: %DUAL-3-SIA: Route network mask stuck-in-active state in IP-EIGRP AS. Cleaning up