Part of earning your CCNA and CCNP - especially passing the difficult CIT exam - is becoming a master network troubleshooter. Today, we'll take a look at troubleshooting EIGRP and spotting common errors.

Most adjacency issues are easily resolved - mistyped IP address, bad wildcard mask in the neighbor statement, mistyped EIGRP AS number, and so forth. You know the AS number has to match, but always double-check that. Next, check the wildcard mask to make sure the correct interfaces are EIGRP-enabled. In the following example, we've configured three loopbacks on R2 and want to advertise all three loopbacks via EIGRP, but R4 only sees one.

R2(config)#int loopback1

R2(config-if)#ip address 10.1.1.1 255.255.255.0

R2(config-if)#int loopback2

R2(config-if)#ip address 10.1.2.1 255.255.255.0

R2(config-if)#int loopback3

R2(config-if)#ip address 10.1.3.1 255.255.255.0

R2(config-if)#router eigrp 100

R2(config-router)#no auto

R2(config-router)#network 10.1.1.0 0.0.0.255

R2(config-router)#network 172.12.23.0 0.0.0.255

R4#show ip route eigrp

10.0.0.0/24 is subnetted, 1 subnets

D 10.1.1.0 [90/409600] via 172.12.23.2, 00:00:25, Ethernet0

We know it's not an adjacency issue, because R4 has to have an adjacency to get the route. Perhaps the config on R2 is the problem.

R2(config-if)#router eigrp 100

R2(config-router)#no auto

R2(config-router)#network 10.1.1.0 0.0.0.255

R2(config-router)#network 172.12.23.0 0.0.0.255

The only one of the three networks that matches that network statement is 10.1.1.0 /24. As a result, the networks 10.1.2.0 /24 and 10.1.3.0 /24 will not be advertised.

We could use a network statement with 10.1.0.0 0.0.255.255 to successfully advertise the loopbacks, but by breaking the three networks down into binary, we can see that the three networks have the first 22 bits in common. Therefore, a better wildcard mask to use is 0.0.3.255.

R2(config-router)#no network 10.1.1.0 0.0.0.255

R2(config-router)#network 10.1.0.0 0.0.3.255

R4#show ip route eigrp

10.0.0.0/24 is subnetted, 3 subnets

D 10.1.3.0 [90/409600] via 172.12.23.2, 00:00:36, Ethernet0

D 10.1.2.0 [90/409600] via 172.12.23.2, 00:00:36, Ethernet0

D 10.1.1.0 [90/409600] via 172.12.23.2, 00:00:36, Ethernet0

Another factor that must match between potential EIGRP neighbors is the K-metrics, or metric weights. Let's change the EIGRP metric weights on R2 and watch the effect on its adjacency with R4.

R2(config)#router eigrp 100

R2(config-router)#metric weights 0 1 2 3 4 5 ?

03:33:18: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.4 (Ethernet0) is down: metric changed

03:33:20: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.4 (Ethernet0) is down: K-value mismatch

The adjacency goes down, and the router's kind enough to tell you that it's the result of the metrics changing. We'll also see that message on R4, but just in case you don't see it, debug eigrp packet will indicate the K-value mismatch as well.

R4#debug eigrp packet

EIGRP Packets debugging is on

(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK)

3w2d: EIGRP: Received HELLO on Ethernet0 nbr 172.12.23.2

3w2d: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0

3w2d: K-value mismatch

3w2d: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.23.2 (Ethernet0) is down:K-value mismatch

The changed K-values will also appear in the running configuration. This is one time when you don't have to depend on debugs to know what the problem is - the router's going to scream at you until you fix it!