EIGRP RECAP;

Part of mastering EIGRP for your CCNP ROUTE (640-902) exam is knowing the fundamentals - and while you're familiar with the multicasting address reserved for EIGRP, you might not know there are actually five EIGRP packet types.

Let's take a look at each and the individual purchase each one serves. 

EIGRP uses the Reliable Transport Protocol (RTP) to handle the guaranteed and reliable delivery of EIGRP packets to neighbors.  "Guaranteed and reliable" sounds a lot like TCP, but the two are quite different in how they operate.  Not all EIGRP packets are going to be sent reliably. 

EIGRP uses five packet types.  You're likely familiar with Hello packets, used for neighbor discovery and to keep existing neighbor relationships alive. EIGRP Hello packets are multicast to 224.0.0.10.

Acknowledgement packets themselves are simply hello packets that contain no data.  Neither Hello nor Ack packets use RTP, and are therefore considered unreliable.

Update packets are sent to new neighbors to allow the neighbor to build an accurate routing and topology table, and are also sent when a change in the network occurs. Update packets are generally multicast packets, but there's one important exception that you'll read about later in this tutorial. 

Query packets are sent when a router loses a successor route and has no feasible successor ("DUAL Query").    

Reply packets are sent in response to query packets, and a reply packet indicates that a new route to the destination has been found.  Update, query, and reply packets all use RTP and are considered reliable.

To see how many of these packets have passed through a router, run show ip eigrp traffic. 

R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process 100
  Hellos sent/received: 2/2
  Updates sent/received: 13/4
  Queries sent/received: 0/0
  Replies sent/received: 0/0
  Acks sent/received: 0/2
  Input queue high water mark 1, 0 drops
  SIA-Queries sent/received: 0/0
  SIA-Replies sent/received: 0/0

To review:  Hello and ACK packets are unreliable. Reply, Query, and Update packets are reliable.

Before EIGRP routers can exchange routes, they have to become neighbors - and some of the packets we just discussed are vital to that adjacency process.

Let's take a look at an EIGRP adjacency and how the packets we just discussed are part of this process.

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.

The downstream router R2 receives this Hello and check it to verify that certain values in the Hello packet - including the Autonomous System number - match those on R2.

If those values match, R2 responds with an EIGRP Update packet, which contains all the EIGRP-derived routes that R2 knows.  (R1 will also receive a Hello packet, multicast from R2.) 

Note the EIGRP Update packet going back to R1 is a unicast.

Generally, EIGRP Update packets are multicast to 224.0.0.10, just as EIGRP Hello packets are.  This particular situation is an exception to that rule - during the initial exchange of routes between two new EIGRP neighbors, update packets are unicast rather than multicast.

Finally, R1 will send an EIGRP Acknowledgement packet 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.

Now that we've got our adjacency, the real fun begins! 

I have got the EIGRP lab up and running and will look at some debugs tomorrow :0)