Before EIGRP routers can exchange routes, they must form a neighbor relationship, or adjacency. On occasion, getting this EIGRP adjacency to form can be a little tricky, so we better know how to troubleshoot them!

In the following example, R1 has just had EIGRP enabled on a Serial interface. R1 will send an EIGRP Hello packet out that interface in an attempt to find potential neighbors. EIGRP Hello packets are multicast to 224.0.0.10.

A downstream router, R2, receives this Hello and responds with a Hello of its own. That router will also send an EIGRP Update packet, which contains all the EIGRP-derived routes that R2 knows - with one exception.

R2 cannot advertise an EIGRP route on the same interface that R2 used to learn about the route in the first place. I'm sure you remember that rule of split horizon from your CCNA studies, but you really need to keep that in mind for both the 642-901 BSCI exam and working with real-world production networks.

Did you notice that the EIGRP Update packet going back to R1 was a unicast? Generally, EIGRP Update packets are multicast to 224.0.0.10, just as EIGRP Hello packets are. Cisco's always got an exception to the rule, and the exception with multicasting Update packets occurs during the initial exchange of routes between two new EIGRP neighbors. Update packets are unicast in this particular situation.

R1 will now send an EIGRP Acknowledgement packet, or ack, to let R2 know the routes in the Update packet were received. R1 will also send an Update packet of its own, unicast to R2, containing all EIGRP routes R1 has. R2 will respond with an ack of its own.

Unlike OSPF, EIGRP does not require neighbors to agree on hello and dead times. In the following example, an adjacency has been formed between R2 and R3 using the default values for hello and dead times as well as the metric weights. The router eigrp command indicates that both routers are in EIGRP Autonomous System (AS) 100.

R2(config)#router eigrp 100
R2(config-router)#no auto-summary
R2(config-router)#network 172.12.23.0 0.0.0.255

R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#network 172.12.23.0 0.0.0.255

Let's change the hello and dead timers on R2's Ethernet 0 interface and see what happens to the adjacency. I've disabled EIGRP event logging for the following example, to show you another way to spot an adjacency that went down and then came back up.

R2(config-if)#ip hello eigrp 100 ?
<1-65535> Seconds between hello transmissions

R2(config-if)#ip hello eigrp 100 30

Note the uptime of 19 seconds. That indicates that the EIGRP adjacency did drop, but it came right back up. The mismatched Hello timers didn't prevent the adjacency from forming again, but what about the metric weights?

R2(config)#router eigrp 100
R2(config-router)#metric weights ?
<0-8> Type Of Service (Only TOS 0 supported)

R2(config-router)#metric weights 0 1 1 1 1 1

R2#show ip eigrp neighbor
IP-EIGRP neighbors for process 100
R2#

show ip eigrp neighbor shows us nothing because there's no neighbor to show! We can wait a long, long time for that adjacency to come back, but it's not going to. Potential EIGRP neighbors must agree on the AS number and all metric weight settings in order to become neighbors. Knowing that will help you on the BSCI exam as well as troubleshooting EIGRP adjacencies in the real world!

Chris Bryant,

CCIE #12933