origin: http://websistent.com/demystifying-eigrp-message-types-wireshark/

EIGRP (Enhanced Interior Gateway Routing Protocol) is a Cisco proprietary routing protocol which even though seems to work like a Distance-Vector protocol is in fact several notches above other routing protocols in the distance-vector domain. While configuring it is a breeze what happens behind the scenes ? What goes in the wire when a “network” router subcommand is issued ? How do things converge quickly when a topology change occurs ? These questions made me create a simple topology in GNS3 and capture packets using wireshark. So join me in unraveling the mystery inside an EIGRP packet.

EIGRP Message Types:


This is the first message type sent when the EIGRP process comes up on a router. It contains several parameters like K values and AS number which are checked by the router receiving the hello message before forming neighborship.

eigrp hello parameters
An EIGRP hello packet contains several parameters which a receiving router checks with its own EIGRP configuration, neighborship forms only if these parameters match.

They are sent out every 5 seconds by default on a high bandwidth links and every 60 seconds on low bandwidth links.

eigrp hello timer
On high-speed link the default “hello timer” is 5 seconds and the packet capture shows a hello message sent at approximate 5 second intervals.

Hello messages sent by stub routers also have “Stub” parameters like connected, summary, redistributed, receive-only, static.

eigrp hello stub
The EIGRP hello message sent by a stub router contains “stub flags” which are the stub parameters defined in the “eigrp stub” command.

Hello messages are multicasted by default but if neighbors are configured statically on a non broadcast medium like Frame Relay they are unicasted.

Wireshark filters:

(eigrp.opcode == 5) && (eigrp.ack == 0)

We have to add a filter for the “Acknowledge” field because the “opcode” of both HELLO and ACKNOWLEDGE is same but the latter has a non zero value in the “Acknowledge” field.


Displaying HELLO messages from EIGRP stub routers is very simple as only HELLO messages from stub routers have “stub_flags” in them.


This packet contains routes known by the router, this is sent after the parameters mentioned in the HELLO messages match and neighborship is formed. The first time UPDATE packets are unicasted after neighborship is formed, these contain all the routes and are called “full updates”.

eigrp full update
A full update packet is sent the first time after two routers become EIGRP neighbors, these messages are unicasted.

Later on when topology changes occur and when new links are added UPDATE messages are multicasted and it contains only the new “route” these are called “partial updates”.

eigrp partial update
An EIGRP partial update is sent when topology changes occur, only the affected network is advertised via a multicast.

Each “route” in the UPDATE message contains metrics like bandwidth, delay, load, reliability and other information like prefix length, MTU, hop count.

eigrp poison reverse
A poison reverse is used to prevent routing loops. When a router receives an UPDATE packet it sends back an UPDATE with the same route but with infinite metrics.

UPDATE messages are also used to perform “poison reverse” by advertising a “received” route with an infinite metric. Example, Router A and Router B are EIGRP neighbors. Router A advertises a route to Router B with certain metrics, now Router B advertises the same route to Router A with an infinite metric (Destination unreachable) so that “routing loops” don’t occur.

Wireshark filters:

eigrp.opcode == 1

This filter displays both full and partial updates.

(eigrp.opcode == 1) && !(ip.dst ==

This filter displays full updates which are unicast packets

(eigrp.opcode == 1) && (ip.dst ==

This will display partial updates which are muticast packets.

(eigrp.opcode == 1) && (expert.message == "Destination unreachable")

This will display only “poison reverse” UPDATE messages. Since they have an infinite metric they are deemed “Unreachable”.

Note: Filtering “full” and “partial” updates is possible only on broadcast medium were neighbors are discovered dynamically. On non broadcast medium like frame relay all UPDATE messages are unicasted.


This message type shares the same opcode of a HELLO packet (Opcode 5) but it is used to acknowledge the receipt of UPDATE, QUERY and REPLY messages. Also unlike a HELLO message it doesn’t have “EIGRP parameters”.

eigrp acknowledge message
The EIGRP acknowledge packet confirms the receipt of UPDATE, REPLY and QUERY packets by placing the “sequence” number of these packets in its own “Acknowledge” field.

It works similar to a TCP 3-way handshake, when a UPDATE, QUERY or REPLY message is received the value in the “sequence” field is placed in the “Acknowledge” field and an ACKNOWLEDGE message is sent but unlike a TCP handshake the sequence value is not incremented in acknowledge. This method of communication is done with Cisco’s proprietary Reliable Transport Protocol. Acknowledge packets are only unicasted.

Wireshark filter:

(eigrp.opcode == 5) && !(eigrp.ack == 0)

Just a small change of adding a NOT operator (!) to the “Acknowledge” field displays EIGRP Acknowledge messages.


Whenever a router loses a route to a network it sends out multicast QUERY messages to all its neighboring routers for finding out other paths to that network. A QUERY message looks similar to an UPDATE packet but contains metrics which make the route unreachable.

eigrp query
When a router looses its best route (successor) for a network and there is no backup route (feasible successor) for it, the router sends an EIGRP query message to locate any alternate routes for that network.

When a QUERY is sent the router expects a REPLY message containing the whereabouts of the route. QUERY messages are not sent to STUB routers.

Wireshark filter:

eigrp.opcode == 3


A REPLY message is sent when a QUERY message is received for a particular network. It looks similar to an UPDATE packet and contains the metrics bandwidth, delay, load and reliability. If the router sending the REPLY knows an alternate path to the “queried” route it contains the necessary metrics, on the other hand if it doesn’t know a path for that route it sets the metrics very high making it unreachable. A REPLY message is unicasted.

eigrp reply
When a router receives a QUERY message for a network it sends a REPLY message containing metrics of that network if it knows a route. Else it sends a REPLY with infinite metrics conveying that it doesn’t know how to reach that network.

The “Acknowledge” field of a REPLY packet contains the “Sequence” value of the QUERY for which it is being sent.

Wireshark filter:

eigrp.opcode == 4

EIGRP MD5 Authentication

EIGRP supports MD5 authentication using “key chains”, when enabled it added a MD5 encrypted string to the HELLO, UPDATE, QUERY and REPLY packets. Only if this authentication data matches with the locally configured “key string” will the message be accepted.

eigrp md5 authentication
EIGRP supports MD5 authentication, when enabled Authentication data is added to HELLO, UPDATE, QUERY and REPLY messages.