This section describes the different types of messages using by EIGRP. However, before delving into the specifics of the different message types, it is important to have a solid understanding of the EIGRP packet header, wherein these messages are contained.

EIGRP Packet Header

Although going into specifics on the EIGRP packet formats is beyond the scope of the ROUTE exam, a fundamental understanding of the EIGRP packet header is important in order to completely understand the overall operation of the EIGRP routing protocol. Figure 2-1 shows the format of the EIGRP packet header:

Fig. 2-1. EIGRP Packet Header Fields

Within the EIGRP packet header, the 4-bit Version field is used to indicate the protocol version. Current Cisco IOS images support EIGRP version 1.x. The 4-bit OPCode specifies the EIGRP packet or message type. The different EIGRP packet types are each assigned a unique OPCode value, which allows them to be differentiated from other packet types. These messages will be described in detail later in this chapter.

The 24-bit Checksum field is used to run a sanity check on the EIGRP packet. This field is based on the entire EIGRP packet excluding the IP header.  The 32-bit Flags field is used to indicate either an INIT for a new EIGRP neighbor or for the Conditional Receive (CR) for EIGRP Reliable Transport Protocol. RTP and the CR will be described in detail later in this chapter.

The 32-bit Sequence field specifies the sequence number used by EIGRP Reliable Transport Protocol to ensure orderly delivery of reliable packets. The Acknowledgment field, which is also 32-bits long, is used to acknowledge the receipt of an EIGRP reliable packet.

The 32-bit Autonomous System Number field specifies the Autonomous System Number of the EIGRP domain. And finally, the 32-bit Type/Length/Value (TLV) triplet field is used to carry route entries, as well as provide EIGRP DUAL information. EIGRP supports several different types of TLVs, with the most common being the following:

• The Parameters TLV, which has the parameters to establish neighbor relationships
• The Sequence TLV, which is used by Reliable Transport Protocol
• The Next Multicast Sequence TLV, which is used by Reliable Transport Protocol
• The EIGRP internal route TLV, which is used for internal EIGRP routes
• The EIGRP external route TLV, which is used for external EIGRP routes

 

NOTE: You are not required to go into detail on the different EIGRP TLVs.

Figure 2-2 shows the different fields as they appear in a wire capture of an EIGRP packet:

Fig. 2-2. EIGRP Packet Header Capture

Within the EIGRP packet header, the 4-bit OPCode field is used to specify the EIGRP packet type or message. EIGRP uses different message or packet types, which are Hello packets, Acknowledgement packets, Update packets, Query packets, Reply packets, and also Request packets. These packet types are described in detail in the following sections.

Hello Packets

EIGRP sends Hello packets once it has been enabled on a router for a particular network. These messages are used to identify neighbors and once identified, serve or function as a keepalive mechanism between neighbors. EIGRP neighbor discovery and recovery is described in detail later in this chapter.

EIGRP Hello packets are sent to the link local Multicast group address 224.0.0.10.  Hello packets sent by EIGRP do not require an Acknowledgment to be sent confirming that they were received. Because they require no explicit acknowledgment, Hello packets are classified as unreliable EIGRP packets. EIGRP Hello packets have an OPCode of 5.

Acknowledgement Packets

An EIGRP Acknowledgment (ACK) packet is simply an EIGRP Hello packet that contains no data. Acknowledgement packets are used by EIGRP to confirm reliable delivery of EIGRP packets. ACKs are always sent to a Unicast address, which is the source address of the sender of the reliable packet, and not to the EIGRP Multicast group address. In addition, Acknowledgement packets will always contain a non-zero acknowledgment number. The ACK uses the same OPCode as the Hello Packet because it is essentially just a Hello that contains no information. The OPCode is 5.

Update Packets

EIGRP Update packets are used to convey reachability of destinations. In other words, Update packets contain EIGRP routing updates. When a new neighbor is discovered, Update packets are sent via Unicast to the neighbor can build up its EIGRP Topology Table. In other cases, such as a link cost change, updates are sent via Multicast. It is important to know that Update packets are always transmitted reliably and always require explicit acknowledgement. Update packets are assigned an OPCode of 1. An EIGRP Update is illustrated in Figure 2-3:

Fig. 2-3. EIGRP Update Packet

NOTE: You are not required to go into detail on the information contained in EIGRP packets.

Query Packets

EIGRP Query packets are Multicast and are used to reliably request routing information. EIGRP Query packets are sent to neighbors when a route is not available and the router needs to ask about the status of the route for fast convergence. If the router that sends out a Query does not receive a response from any of its neighbors, it resends the Query as a Unicast packet to the non-responsive neighbor(s). If no response is received in 16 attempts, the EIGRP neighbor relationship is reset. This concept will be described in further detail later in this chapter. EIGRP Query packets are assigned an OPCode of 3.

Reply Packets

EIGRP Reply packets are sent in response to Query packets. The Reply packets are used to reliably respond to a Query packet. Reply packets are Unicast to the originator of the Query. The EIGRP Reply packets are assigned an OPCode of 4.

Request Packets

Request packets are used to get specific information from one or more neighbors and are used in route server applications. These packet types can be sent either via Multicast or Unicast, but are always transmitted unreliably. In other words, they do not require an explicit acknowledgment.

NOTE: While EIGRP Hello and ACK packets have been described as two individual packet types, it is important to remember that some texts, EIGRP Hello and ACK packets are considered as the same type of packet. This is because, as was stated earlier in this section, an ACK is simply an EIGRP Hello packet that contains no data.

The debug eigrp packets command may be used to print real-time debugging information on the different EIGRP packets described in this section. Keep in mind that this command also includes additional packets which are not described as they are beyond the scope of the current ROUTE exam. The following output illustrates the use of this command:

R1#debug eigrp packets ?
	SIAquery  EIGRP SIA-Query packets
	SIAreply  EIGRP SIA-Reply packets
	ack       EIGRP ack packets
	hello     EIGRP hello packets
	ipxsap    EIGRP ipxsap packets
	probe     EIGRP probe packets
	query     EIGRP query packets
	reply     EIGRP reply packets
	request   EIGRP request packets
	retry     EIGRP retransmissions
	stub      EIGRP stub packets
	terse     Display all EIGRP packets except Hellos
	update    EIGRP update packets
	verbose   Display all EIGRP packets
	<cr>

The show ip eigrp traffic command is used to view the number of EIGRP packets sent and received by the local router. This command is also a powerful troubleshooting tool. For example, if the routing is sending out Hello packets but not receiving any back, this could indicate that the intended neighbor is not configured, or even that an ACL may be blocking EIGRP packets. These concepts are expanded on in the TSHOOT study guide. The output of this command is shown below:

R2#show ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 150
	Hellos sent/received: 21918/21922
	Updates sent/received: 10/6
	Queries sent/received: 1/0
	Replies sent/received: 0/1
	Acks sent/received: 6/10
	SIA-Queries sent/received: 0/0
	SIA-Replies sent/received: 0/0
	Hello Process ID: 178
	PDM Process ID: 154
	IP Socket queue:   0/2000/2/0 (current/max/highest/drops)
	Eigrp input queue: 0/2000/2/0 (current/max/highest/drops)

In summation, Table 2-1 summarizes the EIGRP packets described in the section and whether or not they are sent unreliably or reliably:

Message Type	Description	Sent
Hello	Used for neighbor discovery, recovery and for keepalives	Unreliably
Acknowledgement	Used to acknowledge receipt of information	Unreliably
Update	Used to convey routing information	Reliably
Query	Used to request specific routing information	Reliably
Reply	Used to respond to a Query	Reliably
Request	Used to request information in route server applications	Unreliably

Tab. 2-1. EIGRP Packet Summary