EIGRP – Packets & Neighborships


Now we will begin by looking at the makeup of a EIGRP packet and how it is made up. Also look at the different type of messages EIGRP uses to communicate.

EIGRP Packet Header

The IP header of the EIGRP packet specifies IP protocol number 88 within it, and the maximum length of the packet will be the IP MTU of the interface on which it is transmitted, most of the time 1500 octets. Following the IP header is the various Type/Length/Value (TLV) triplets. These TLVs will not only carry the route entries but also provide fields for the management of the DUAL process, multicast sequencing, and IOS software versions from the router.

Within the EIGRP packet header;

  • Version field – is 4-bit field used to indicate the protocol version of the originating EIGRP router process. The version has not changed since its release.
  • OPCode – is a 4-bit field that specifies the EIGRP message type, 1 = Update, 3 = Query, 4 = Reply, 5 = Hello, 6 = IPX SA, 10 = SIA Query, 11 = SIA Reply.
  • Checksum – is a 24-bit field that is used to run a sanity check on the EIGRP packet itself. This field is based on the entire EIGRP packet and not including the IP header.
  • Flags – is a 32-bit field that is used to indicate either an INIT (when set (0x00000001)) for a new EIGRP neighbor or for the Conditional Receive (CR) (second bit (0x00000002)), used in the proprietary Reliable Multicasting algorithm, for EIGRP Reliable Transport Protocol. (RTP)
  • Sequence – is a 32-bit field that contains sequence number used by RTP. This is used to ensure orderly delivery of reliable packets.
  • Acknowledgment – is a 32-bit field that contains the sequence number last heard from the neighbor to which the packet is being sent. A Hello packet with a nonzero ACK field will be treated as an ACK packet rather than as a Hello. Note that an ACK field will only be nonzero if the packet itself is a unicast because an acknowledgment are never multicast.
  • Autonomous System Number – is a 32-bit field that identifies the number of the EIGRP domain.
  • Type/Length/Value (TLV) – is a 32-bit triplet field that is used to carry route entries, as well as provide EIGRP DUAL information. EIGRP supports several different types of TLVs as follows;
    – 0x0001  EIGRP Parameters (General TLV Types)
    – 0x0003  Sequence (General TLV Types)
    – 0x0004  Software Version (General TLV Types)
    – 0x0005  Next Multicast Sequence (General TLV Types)
    – 0x0102  IP Internal Routes (IP-Specific TLV Types)
    – 0x0103  IP External Routes (IP-Specific TLV Types)

TLV Fields

TLVs (type-length-value) are not only found within EIGRP but can be found in other protocols like IS-IS for one. The type and length fields are fixed in size (typically 1-4 bytes), and the value field is of variable size.

  • Type – A binary code, often simply alphanumeric, which indicates the kind of field that this part of the message represents.
  • Length – The size of the value field (typically in bytes)
  • Value – Variable-sized series of bytes which contains data for this part of the message.

TLVs carry EIGRP management information. The Parameters of TLV that are used to convey metric weights and the hold time. The Sequence, Software Version, and Next Multicast Sequence TLVs are used by the Cisco proprietary Reliable Multicast algorithm. As it was mentioned earlier TLV not only works with IP but also IPX and Apple Talk. Each Internal and External Routes TLV contains one route entry. Every Update, Query, and Reply packet contains at least one Routes TLV. The Internal and External Routes TLVs include metric information for the route.

IP Internal Routes TLV

An internal route is a path to a destination within the EIGRP autonomous system.

  • Next Hop – is the next-hop, neighboring router, IP address.
  • Delay – is the sum of the configured delays expressed in units of 10 microseconds. A delay of 0xFFFFFFFF, or 256, indicates an unreachable route.
  • Bandwidth – is 256 x BW(min), or 2,560,000,000 divided by the lowest configured bandwidth of any interface along the route.
  • MTU – is the smallest Maximum Transmission Unit of any link along the route to the destination. This value is not used for the metric calculation.
  • Hop Count – is a number between 0x01 and 0xFF indicating the number of hops to the destination. A router will advertise a directly connected network with a hop count of 0.
  • Reliability – is a number between 0x01 and 0xFF that reflects the total outgoing error rates of the interfaces along the route, calculated on a five-minute exponentially weighted average. 0xFF indicates a 100 percent reliable link.
  • Load – is also a number between 0x01 and 0xFF, reflecting the total outgoing load of the interfaces along the route, calculated on a five-minute exponentially weighted average. 0x01 indicates a minimally loaded link.
  • Reserved – is an unused field and is always 0x0000
  • Prefix Length – specifies the number of network bits of the address mask.
  • Destination – is the destination address of the route.

IP External Routes TLV

An external route is a path that leads to a destination outside of the EIGRP autonomous system and that has been redistributed into the EIGRP domain.

  • Next Hop – is the next-hop IP address. On a multiaccess network, the router advertising the route might not be the best next-hop router to the destination. The Next Hop field allows the “bilingual” router to tell its EIGRP neighbors, “Use address A.B.C.D as the next hop instead of using my interface address.”
  • Originating Router – is the IP address or router ID of the router that redistributed the external route into the EIGRP autonomous system.
  • Originating Autonomous System Number – is the autonomous system number of the router originating the route.
  • Arbitrary Tag – may be used to carry a tag set by route maps.
  • External Protocol Metric – is the metric of the external protocol.
  • Reserved – is an unused field and is always 0x0000.
  • External Protocol ID – specifies the protocol from which the external route was learned. 0x01 = IGRP, 0x02 = EIGRP, 0x03 = Static Route, 0x04 = RIP, 0x05 = Hello, 0x06 = OSPF, 0x07 = IS-IS, 0x08 = EGP, 0x09 = BGP, 0x0A = IDRP, 0x0B = Connected Link.
  • Flags – currently constitute just two flags. If the right-most bit of the eight-bit field is set (0x01), the route is an external route. If the second bit is set (0x02), the route is a candidate default route.

EIGRP Packets

EIGRP will use six different packet types when communicating with its neighboring EIGRP routers,

  • 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 neighboring devices. EIGRP Hello packets are sent to the link local Multicast group address  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. Update packets contain EIGRP routing updates. When a new neighbor is discovered, Update packets are sent via Unicast to the neighbor which the can build up its EIGRP Topology Table. 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.
  • Query Packet – 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. 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.

To best see these packets been used by EIGRP us the following debug command;

Router#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

Another very good command to see what packets have been sent and received by your router use the following show command;

Router#sh ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 100
Hellos sent/received: 216/185
Updates sent/received: 19/17
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 10/4
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Hello Process ID: 230
PDM Process ID: 194
IP Socket queue:   0/2000/4/0 (current/max/highest/drops)
Eigrp input queue: 0/2000/4/0 (current/max/highest/drops)

Reliable Transport Protocol

The RTP manages the delivery and reception of EIGRP packets. Reliable delivery means that delivery is guaranteed and that packets will be delivered in order. Guaranteed delivery is accomplished by means of a Cisco-proprietary algorithm known as reliable multicast, using the reserved class D address Each neighbor receiving a reliably multicast packet unicasts an acknowledgment. Ordered delivery is ensured by including two sequence numbers in the packet. Each packet includes a sequence number assigned by the sending router. This sequence number is incremented by one each time the router sends a new packet. In addition, the sending router places in the packet the sequence number of the last packet received from the destination router. This can be seen in the following debug output;

*Mar  1 00:26:01.015: EIGRP: Sending UPDATE on FastEthernet0/0 nbr
*Mar  1 00:26:01.015:   AS 100, Flags 0x8, Seq 13/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 3-3
*Mar  1 00:26:01.183: EIGRP: Received ACK on FastEthernet0/0 nbr
*Mar  1 00:26:01.183:   AS 100, Flags 0x0, Seq 0/13 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

In some cases, RTP is not need and unreliable delivery is used. This is done by not needing an acknowledgment and no sequence number will be included.

As discussed earlier EIGRP used the following packet types, Hello, ACK, Update, Query, Reply and Request. The time to wait for an ACK before switching from multicast to unicast is specified by the multicast flow timer. The time between the subsequent unicasts is specified by the retransmission timeout (RTO). Both the multicast flow timer and the RTO are calculated for each neighbor from the smooth round-trip time(SRTT). The SRTT is the average elapsed time, measured in milliseconds, between the transmission of a packet to the neighbor and the receipt of an acknowledgment. The formulas for calculating the exact values of the SRTT, the RTO, and the multicast flow timer are proprietary.


EIGRP updates are nonperiodic, it is important to have a process whereby neighbors EIGRP-speaking routers on directly connected networks are discovered and tracked. EIGRP may be configured to discover neighboring routers dynamically (default) or statically.

Dynamic neighbor discovery is performed by sending EIGRP Hello packets to the destination Multicast group address This is performed as soon as the network command is configured under the EIGRP routing process. The neighbors then exchange their full routing tables using full Updates. These Updates contain information about all known routes that the router knows about. Because Update packets are sent reliably, they must be explicitly acknowledged by the receiver. After this full Update of routing tables is completed, EIGRP neighbor routers will send only incremental updates to advise neighbors of status or routing changes and will not send their full routing table again to the neighbors.

Static EIGRP neighbor relationships require manual neighbor configuration on the router. When static EIGRP neighbors are configured, the local router uses the Unicast neighbor address to send packets to these routers and not the multicast address You would mostly find static neighbors been configured on media that does not natively support Broadcast or Multicast packets, such as Frame Relay & NBMA.

Static neighbor can be configured with the following router process command;

Router(config-router)#neighbor fastethernet 0/0

Always remember EIGRP enabled routers will not establish neighbor adjacency if one router is configured to use Unicast (static) while another uses Multicast (dynamic).

It is important to understand that simply enabling EIGRP between two or more routers does not guarantee that a neighbor adjacency will be established. EIGRP neighbor adjacency may not establish due to any of the following:

  • Mismatched EIGRP Authentication Parameters (if configured)
  • Mismatched EIGRP K Values (Metric)
  • Mismatched EIGRP Autonomous System (AS) Number
  • Using secondary addresses for EIGRP neighbor relationships
  • The neighbors are not on a common subnet

On most networks, Hellos are multicast every five seconds, minus a small random time to prevent synchronization. On multipoint X.25, Frame Relay, and ATM interfaces, with access link speeds of T1 or slower, Hellos are unicast every 60 seconds, point-to-point sub-interfaces send hellos every 5 seconds. In all of these cases the Hellos are unacknowledged.

The default Hello interval can be change with the following interface command;

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

The Hold time tells the router the maximum time it should wait to receive subsequent Hellos. If the hold timer expires before a Hello is received, the neighbor is declared unreachable and DUAL is informed of the loss of a neighbor. By default, the hold time is three times the Hello. So on low-speed nobroadcast networks, links T1 or less, the Hold timer will be 180 seconds. On all other network types the Hold timer will be 15 seconds.

These defauls can also be changed with the following interface command:

Router(config-if)#ip hold-time eigrp 100 ?
<1-65535>  Seconds before neighbor is considered down

Information about each neighbor is recorded in a neighbor table.

Router#sh ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)               (ms)           Cnt Num
1              Fa0/0             11 00:00:08     87     522    0    6
0              Fa0/0             14 00:01:54   1300   5000   0   3

The neighbor table records the IP address of the neighbor and the interface on which the neighbor’s Hellos are received. The hold time advertised by the neighbor is recorded, as is the SRTT and the uptime, the time since the neighbor was added to the table. The RTO is the time, in milliseconds, that the router will wait for an acknowledgment of a unicast packet sent after a multicast has failed. If an EIGRP update, query, or reply is sent, a copy of the packet will be queued. If the RTO expires before an ACK is received, another copy of the queued packet is sent. The Q Count indicates the number of enqueued packets. The sequence number of the last update, query, or reply packet received from the neighbor is also recorded in the neighbor table. The RTP tracks these sequence numbers to ensure that packets from the neighbor are not received out of order. Finally, the H column records the order in which the neighbors were learned.

  • H – The list of neighbors in the order they are learned, starting at 0.
  • Address – The IP address of the neighbor.
  • Interface – The interface via which the neighbor is learned.
  • Hold – The Hold timer for the neighbor. If it gets to 0, the neighbor is down.
  • Uptime – Timer for how long the neighbor relationship has been up.
  • SRTT – This is the Smooth Round Trip Time, which is the time it takes to send and receive a reliable EIGRP packet.
  • RTO – This is the Round Trip Timeout, which is the amount of time the router will wait to retransmit the EIGRP reliable packet if an Ack is not received.
  • Q Cnt – This is the number of EIGRP packets (Update, Query, and Reply) that the software is waiting to send.
  • Seq Num – This is the sequence number of the last EIGRP reliable packets being received from the neighbor. This is to ensure that packets received from the neighbor are in order.

There is a single EIGRP Neighbor Table for each Protocol Dependent Module (PDM).