Jesin's Blog

Welcome to the Portal of Technology

  • Facebook
  • GitHub
  • Google+
  • RSS
  • Twitter
  • Home
  • Categories
    • Domains
    • Linux
    • Networking
    • PHP
    • Virtualization
    • Web Design
    • Web Servers
    • Windows
  • WordPress Plugins
    • Custom Error Pages
    • HTTP Digest Authentication
    • Mailgun Email Validator
  • Toolbox
    • DNS Lookup Tool
    • htdigest Generator Tool Online
    • htpasswd Generator Tool Online
    • HTTP Headers Lookup Tool
    • MD5 Encryption Tool
    • Open Port Check Tool
    • SHA-1 Encryption Tool
    • URL Encoding/Decoding Tool
  • About Me
  • Contact Me
  • Sitemap
Home ›
Networking ›
Demystifying EIGRP message types with Wireshark

Demystifying EIGRP message types with Wireshark

June 25, 2013 Networking Jesin A 9 Comments

networking category thumbnail

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
  • Update
  • Acknowledge
  • Query
  • Reply

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.

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.

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”.

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 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:

eigrp.opcode == 1

This filter displays both full and partial updates.

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

This filter displays full updates which are unicast packets

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

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.

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”.

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.

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.

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

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.

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.

Hope this article was useful for all those preparing for Cisco certifications or those trying to understand EIGRP, I’d love to hear what you think so do leave a comment below.

Related posts:

networking category thumbnailHow to Configure a Cisco router as a Frame Relay Switch networking category thumbnailConfigure Inter-VLAN routing on Cisco Router networking category thumbnailAnswers for CCNP TSHOOT Demo Exam networking category thumbnailHow to connect GNS3 to the Internet cisco packet tracer dial up thumbnailCisco Packet Tracer Dial Up

Tags: cisco, eigrp, wireshark

Comments

  1. Jonnel says

    October 16, 2013 at 10:43 am

    Thanks for these! very informative. There are information that I can’t find in other sites. Thanks again!

    Reply
  2. Mario Uzae says

    June 23, 2014 at 5:06 am

    Hi Jesin, congratulations ! This was very usefull for me, and i would like to ask you, how a router running EIGRP does to calculate RD(Reported Distance), it is passed by the EIGRP UPDATE or it is calculated locally with Bandwidth and Delay received ?

    Thanks,

    Mario

    Reply
    • Jesin A says

      June 24, 2014 at 12:26 am

      Hi Mario,

      UPDATE messages only send the metrics, have a look at this screenshot.

      The receiving router then calculates the RD with it.

      Reply
      • Mario says

        June 24, 2014 at 4:25 am

        Hi Jesin, it is clearly !

        Thanks,

        Mario

        Reply
  3. Suneel Sharma says

    December 31, 2014 at 10:26 am

    HI jesin,

    I was trying to understand about EIGRP messages. I tried for it on many websites, in videos but I could not find these information in any site and video.

    It is a very useful information for me. I am thankful for these information.

    Thanks.

    Reply
  4. Dom says

    August 20, 2015 at 2:52 pm

    Thanks. Just what I was looking for.

    Reply
  5. Mahmoud Mahboubi says

    September 27, 2015 at 4:19 am

    Hello and thanks for your efforts
    I checked your trace but i think u had a mistake!!!
    the first update actually the full update sent to 224.0.0.10 and the partial update sent to a unicast address.
    please check your pictures again and notice to the sequence numbers of packets.
    thank you.

    Reply
    • Jesin A says

      September 30, 2015 at 11:37 pm

      Hi Mahmoud,

      This is from the Cisco documentation:

      When a new neighbor is discovered, update packets are sent so the neighbor can build up its topology table. In this case, update packets are unicast. In other cases, such as a link cost change, updates are multicast.

      Reply
  6. Kundan Singh says

    November 6, 2017 at 7:19 pm

    awesome bro keep it up

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Get a wealth of information delivered to your inbox. Subscribe and never miss a single article.

  • Tutorials and howtos
  • Code, scripts and commands
  • Online Tools

* No spam, unsubscribe anytime

Hire Me

  • SSL installation and hardening (A+ on Qualys SSL test)
  • Apache & Nginx configuration
  • Email deliverability improvement (10/10 on Mail Tester & MailGenius)
  • WordPress customization, optimization and migration
  • and much more…

    Tools

    • DNS Lookup Tool
    • htdigest Generator Tool Online
    • htpasswd Generator Tool Online
    • HTTP Headers Lookup Tool
    • MD5 Encryption Tool
    • Open Port Check Tool
    • SHA-1 Encryption Tool
    • URL Encoding/Decoding Tool

    Nav

    • Home
    • About Me
    • Contact Me
    • Privacy Policy
    • Sitemap
    Vultr SSD VPS

    Creative Commons License
    Jesin's Blog by Jesin A is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
    Based on a work at websistent.com.