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:
Hello
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.
They are sent out every 5 seconds by default on a high bandwidth links and every 60 seconds on low bandwidth links.
Hello messages sent by stub routers also have “Stub” parameters like connected, summary, redistributed, receive-only, static.
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:
1
|
(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.
1
|
eigrp.stub_flags |
Displaying HELLO messages from EIGRP stub routers is very simple as only HELLO messages from stub routers have “stub_flags” in them.
Update
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”.
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”.
Each “route” in the UPDATE message contains metrics like bandwidth, delay, load, reliability and other information like prefix length, MTU, hop count.
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 10.10.10.0/24 to Router B with certain metrics, now Router B advertises the same 10.10.10.0/24 route to Router A with an infinite metric (Destination unreachable) so that “routing loops” don’t occur.
Wireshark filters:
1
|
eigrp.opcode == 1 |
This filter displays both full and partial updates.
1
|
(eigrp.opcode == 1) && !(ip.dst == 224.0.0.10) |
This filter displays full updates which are unicast packets
1
|
(eigrp.opcode == 1) && (ip.dst == 224.0.0.10) |
This will display partial updates which are muticast packets.
1
|
(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.
Acknowledge
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”.
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:
1
|
(eigrp.opcode == 5) && !(eigrp.ack == 0) |
Just a small change of adding a NOT operator (!) to the “Acknowledge” field displays EIGRP Acknowledge messages.
Query
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.
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:
1
|
eigrp.opcode == 3 |
Reply
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.
The “Acknowledge” field of a REPLY packet contains the “Sequence” value of the QUERY for which it is being sent.
Wireshark filter:
1
|
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.