[an error occurred while processing the directive]
EIGRP is an important part of real-world networking as well as being a major topic on the 642-901 CCNP BSCI exam. As with any networking topic, before you try to master intermediate and advanced skills, you must master the fundamentals. It doesn't get any more fundamental than the EIGRP adjacency process - and it doesn't get any more important, because without that adjacency, we don't have an EIGRP deployment!
In today's CCNP tutorial, we'll work with R1 and R2, two Cisco routers communicating over a serial interface. EIGRP is already running on R2's serial interface, but was just enabled on R1's serial interface. The EIGRP adjacency process begins with R1 sending an EIGRP Hello packet to the multicast address 224.0.0.10 in an attempt to find potential neighbors.
R2 will receive this Hello packet and respond with a Hello packet as well as an EIGRP Update packet. This packet will contain all the EIGRP routes R2 knows of, as long as the rule of split horizon is not violated. (Split horizon dictates that a route cannot be advertised out the same interface that has received an advertisement for that same route.)
Oddly enough, the EIGRP Update packet transmitted by R2 will be a unicast packet, not a multicast. EIGRP Update packets are generally multicast to 224.0.0.10, but during the first exchange of routes with a new neighbor, the Update packet is unicast.
In response, R1 will send an EIGRP ACK, short for acknowledgement. That lets R2 know that R1 received the EIGRP routes. R1 will also send an unicast Update packet to R2, which R2 will acknowledge.
A major difference between EIGRP and OSPF adjacencies is that EIGRP speakers do not have to agree on hello and dead times, where an OSPF adjacency will never form between routers using different hello and dead times. However, EIGRP speakers must agree on the Autonomous System (AS) number as well as the metric weight values. We have an adjacency between R1 and R2, but what happens to that adjacency if the metric weights are changed on R2?
R2(config)#router eigrp 100
R2(config-router)#metric weights 0 1 1 1 1 1
R2#show ip eigrp neighbor
IP-EIGRP neighbors for process 100
R2# (Nothing to see here!)
The adjacency is torn down! If we changed the metric weights on R1 or removed that last configuration from R2, the adjacency would come back up. You should have a very good reason to change the EIGRP metric weights in the first place, but if you do change them on one EIGRP speaker in an AS, you better do so on all the other speakers in the AS as well. And if you do so, verify them with show ip eigrp neighbor!
About the Author:
Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage , home of free CCNA and CCNP tutorials! Pass the CCNA exam with Chris Bryant!
 |
|
|
|
