In this article I will write about the EIGRP routing protocol and give a quick overview of the inner workings. EIGRP is a Cisco proprietary protocol and offers a great balance between performance and ease of configuration.

The network that we will be implementing is the following:


We will start off by assigning IP addresses to the interfaces connecting R1 and R2.

R1(config)#interface fastEthernet 0/0

R1(config-if)#ip address

R1(config-if)#no shutdown

R2(config)#interface fastEthernet 0/0

R2(config-if)#ip address

R2(config-if)#no shutdown

Go ahead and execute a basic ping test to make sure that you have connectivity between your devices. The next step is to enable EIGRP between these two devices to see what occurs during the neighbor relationship formation. In order to enable EIGRP on R1 we must execute the following commands.

R1(config)#router eigrp 10

R1(config-router)#eigrp router-id


The first command above turns the EIGRP protocol on for this router. The number 10 is the autonomous system number which must match on other routers in your enterprise that you will be creating a neighbor relationship with. Following the first command is the EIGRP router ID which I have set to be for this device. The router ID is used by EIGRP when we redistribute external routes into the EIGRP routing protocol as a loop prevention mechanism. The router ID is not as important for the EIGRP routing protocol as it is for OSPF where several configuration commands rely on it. I manually set the router ID as a good practice guideline since I don’t want to have duplicate IDs in my network. Without explicitly settings a router ID the following guidelines are followed for automatic assignment:

  1. Highest IP address assigned to a loopback interface is selected
  2. If no loopback interfaces are configured then the highest IP address assigned to any other interface is selected

The last command here tells EIGRP on which interface we should build neighbor relationships on. It also tells EIGRP which network to advertise since it is capable of determining the network that specific IP address belongs to. This means that we will send and receive neighbor advertisements on the interface assigned the IP address and also advertise the network since this interface is within the range of that network.

Note that EIGRP uses a wildcard mask as an indicator of the network that we wish to advertise. In order to find the subnet mask from a given wildcard mask, all we have to do is subtract from 255. E.g. if we subtract from the wildcard mask then we get which means that we will only advertise this exact network. Similarly if we have a wildcard of and we want to figure out which network that covers then we do the same thing which gives us a mask of and if we apply this to the address that I used then this means that it will cover the following networks: if you want to go in the other direction where you know your subnet mask and want to find out which wildcard mask will cover your subnet mask then you do the same thing.

Let’s look at the advertisements that EIGRP has started to send on this interface:


Using Wireshark, we can tell that this device is sending EIGRP Hello packets to the multicast IP address Let’s take a closer look to see what’s inside this hello packet.


Starting at layer 2 we see that we are using a destination multicast MAC address. Any MAC address in the range of 01:00:5E:00:00:00 to 01:00:5E:7F:FF:FF is part of the reserved multicast address range. The last 23 bits in this MAC address or the low order 23 bits map directly to the last 23 bits of the multicast IP address. In our case, if we take our multicast IP address and convert the last 23 bits to hexadecimal we get 0.0.10 = 00:00:0A making our multicast MAC address 01:00:5E:00:00:0A

Moving onto layer 3 we see that our destination is a multicast IP address and in this case it is This is a well-known multicast IP address that has been reserved for the EIGRP protocol. The TTL value here is set to 2 on this packet and the reason for this might be the same as I explained in my previous RIP article.

Note that EIGRP does not use UDP or TCP. Instead EIGRP uses IP protocol 88 making it its own IP protocol. EIGRP does have reliability built into it using RTP(Reliable Transport Protocol) which is a Cisco proprietary protocol. Reliability works via simple sequence numbers and acknowledgements.

The actual EIGRP packet format contains a version which tells us the EIGRP process version. The Opcode listed here is 5 which means that this is a Hello packet. Here is a full list of Opcodes that we will see on other EIGRP packets:

1 Update
3 Query
4 Reply
5 Hello

The sequence and acknowledgement fields are used by RTP for reliability which we will see later on. The autonomous system field is listed here and this matches the AS number that we typed in when we enable EIGRP on this router.

Moving onto the parameters at the bottom, we see K1-K6. Each of these K values represents a different vector metric and EIGRP uses a combination of these values to calculate a composite metric. Here is some information from wikipedia that should help with understanding what each K value is for.

K Value Meaning Description
K1 Bandwidth Minimum Bandwidth (in kilobits per second) along the path from router to destination network
K2 Load Load (number in range 1 to 255; 255 being saturated)
K3 Delay Total Delay (in 10s of microseconds) along the path from router to destination network
K4 Reliability Reliability (number in range 1 to 255; 255 being the most reliable)
K5 MTU Minimum path Maximum Transmission Unit (MTU) (never used in the metric calculation)
K6 Hop Count Number of routers a packet passes through when routing to a remote network, used to limit the EIGRP AS.

By default we see that only K1 and K3 are set to a value of 1. This means that by default EIGRP will only take into account the bandwidth and delay when it calculates the composite metric. When K1 and K3 are set then the EIGRP metric is calculated based on the following formula:

(BandwidthE + DelayE) * 256


BandwidthE = 107 / (Value of the bandwidth interface command in Kbit/sec)

DelayE = (Value of the delay interface command in tens of microseconds)

The delay is a sum of all delays for this network as it gets advertise from one router to another. When we calculate the delay for a network that is not directly connected to us, we add the delay of our interface were we received the advertisement to the delay that is advertised by the neighboring router.

The last parameter here is the hold time which is the amount of time that a router will consider a neighbor alive without receiving a hello packet. A hello packet by default is sent every 5 seconds and the hold time is by default set to be three times the hello timer which comes out to 15 seconds.

At the bottom you see specific EIGRP software version information. Let’s go ahead and turn on EIGRP on the other end to see what occurs during the neighbor relationship when it comes up.

R2(config)#router eigrp 10

R2(config-router)#eigrp router-id


The first thing that we see is a hello packet from R2. This gets sent to the EIGRP multicast destination IP address as we have seen before.


Notice that the K values of R2 match the values being advertised by R1. R1 will see this hello packet and starts the neighbor relationship process if the K parameters are the same. We can see that the next packet that is sent is an update from R1 directly to R2(no multicast address).


In this packet we see that the Init(initialization) flag has been set and that router 1 is sending this directly to R2’s IP address on that shared network. Notice that this packet has a sequence number that has been set to be 10.

Upon seeing this packet from R1, R2 goes ahead and sends back an update directly to R1 with the init flag set as well. Notice that R2 sends a packet that acknowledges sequence 10 which is the packet that R1 sent originally. This packet also happens to have the same sequence number as the packet that was sent from R1. This is just a coincidence and most of the time it is not likely the case.


After this packet reaches R1, the router will then go ahead and send an acknowledgement to R2 for this packet. An EIGRP acknowledgement is a hello packet that holds no data and is used to acknowledge packets that are received.


At this point in time, the neighbor relationship between both of these devices should be up and operational. The next step is to start transmitting routes that are being advertised via EIGRP. I have gone ahead and created loopback interfaces for networks 172.16.4-7 on R1 and advertised those via EIGRP by using the following command:


After R1 and R2 become neighbor then R1 will send an update packet with the network that we are advertising to R2 directly.


Notice that this packet has a sequence number of 11 and that R1 is advertising the entire class B range to R2. The nexthop field here is set to which should tell R2 that the next hop for this network is R1 or to set your next hop address for these routes to be the IP address of the router that sent you this packet. Lastly, we have a list of metrics that are being sent to R2 with this route to be used for the composite metric calculation.

Let’s go over the calculations for some of these values so that we understand what is happening. Note that we only care about the delay and bandwidth since by default our K values are set so that only these two metrics are taken into account.

The formula for the composite metric is

(BandwidthE + DelayE) * 256

If we want to get the composite bandwidth and composite delay portion separately then all we have to do is distribute 256 and we get

(BandwidthE*256) + (DelayE * 256)


BandwidthE = 107 / (Value of the bandwidth interface command in Kbit/sec)

DelayE = (Value of the delay interface command in tens of microseconds)

The delay is a sum of all delays for this network as it gets advertise from one router to another. When we calculate the delay for a network that is not directly connected to us, we add the delay of our interface were we received the advertisement to the delay that is advertised by the neighboring router.

Let’s go ahead and do the calculations on R1 first to see what we get and then we will look at R2.   Since I am using loopback interfaces for these network that I am advertising then we have to look at the default values assigned to a loopback interface.


From the show interfaces command we can get the

Bandwidth = 8000000 Kbit/sec

Delay = 5000 microseconds = 500 tens of microseconds

We know from above that the composite bandwidth is

(BandwidthE*256) = (107/8000000) * 256 = (1.25) * 256 = 256 = Scaled Bandwidth

Note: EIGRP drops the decimal portion from values when it does calculation which means that we can drop the .25 and get the answer for the scaled bandwidth. On a similar note

(DelayE * 256) = 500 * 256 = 128,000 = Scaled Delay

Let’s go ahead and type a couple of verification commands on R1 to see what the status of EIGRP looks like so far. The first command will give us a listing of our neighbors and in this case we can see that R2 is one of them.


This command list the address of our neighbor and the outgoing interface that we are using to reach them. The hold time list the amount of time in seconds before we consider our neighbor dead. The hold time will reset itself when we get a hello message from our neighbor. By default EIGRP sends hello messages every 5 seconds and the default hold time is 15 seconds. If you don’t miss any hello packets from your neighbor then this value should never go below 10 seconds. The next column over is the uptime which should be self-explanatory and the SRTT which follows it is the source round trip timer in milliseconds. The SRTT value tells us how long it takes us to get to our neighbor and back. The RTO value stands for the retransmit timeout and it tells us how long in milliseconds it is going to take before it retransmits a message. The SRTT is used to calculate the RTO and this means that a high SRTT value will lead to a high RTO. When a router doesn’t receive an acknowledgement from its peer then it will use the RTO timer to see when it should send the same packet over again. The “Q cnt” column stands for queue count and it list the number of packets that are currently sitting in the queue and waiting to be transmitted. The last column is the Sequence number which list the version of the EIGRP database that we are both running.

Moving onto R2 let’s take a look and see what it is currently seeing with regards to routes.


It looks like R2 is receiving the network from R1. This should start to raise some flags since R1 does not own the entire network range. EIGRP has a feature called auto summarization that is turned on by default. The formal definition for this feature is the following:

“When a router has multiple working interfaces, and those interfaces use IP addresses in different classful networks, the router advertises a summary route for each classful network on interfaces attached to a different classful network.”

In order to turn this off we must head over to R1 and type the following command:

R1(config-router)#no auto-summary

As soon as we turn this off, router 1 sends an EIGRP update to the multicast address.

Note, it is important to turn off auto summary on all your routers in your EIGRP AS to be consistent.


Notice how this update packet list the four networks 172.16.4-7.0/24 separately rather than summarizing all of these back to the classful network. The metric doesn’t change and it is the same across all four networks since they are all being represented using loopback interfaces on R1. Looking at the R2 routing table we now see the following.


The two numbers in square brackets stand for the administrative distance and the metric. We already know that EIGRP has a default AD of 90 and that the metric is the following assuming that we are using default settings

(BandwidthE*256) + (DelayE * 256)


BandwidthE = 107 / (Value of the bandwidth interface command in Kbit/sec)

DelayE = (Value of the delay interface command in tens of microseconds)

Let’s calculate this metric to see if we come up with the same answer as what R2 is displaying. Let’s start of by viewing some of the K values for one of the routes that we learned from R1.


Bandwidth and delay are the only things that we care about so let’s go ahead and verify them. R2 connects to R1 via interface f0/0


We can see that the BW is 10000 Kbit/sec which is correct. The delay here is 1000 micro seconds  or 100 tens of microseconds. When calculating the delay for a route we have to take the sum of all delay for this route as it goes from one router to the next. In R1 we calculated this delay to be  500 tens of microseconds and here we have 100 tens of microseconds. Now that we have everything, let’s go ahead and plug these into our equation

BandwidthE = 107/10000 = 1000

DelayE = 500 + 100 = 600

(1000 * 256) + (600 * 256) = 409600 Composite metric

We can see here that the metric that we calculated matches the metric that EIGRP calculated.

Before moving forward we are going to set the network on R2 as our default route since it connects us to the internet. We can do this via the following command on R2

R2(config)#ip default-network

Note: This is not an EIGRP command but rather a global configuration command. Also, this command is classful which means that it installs the route to the major network.

Looking at the routing table on R2 we see the following:


Notice the candidate default route marked by the * symbol. Let’s go ahead and advertise R2’s internet connection into EIGRP via the following command.


We should see this route come up on R1’s routing table.


So this looks great. We can see that we have learned that route via EIGRP to the network via This is marked as a candidate default route and our gateway of last resort has been set to At this point in time I am going to go ahead and configure R3 and R4 so that we can have a fully functional EIGRP environment that we can run verification commands against. When you are done with the configuration, R2 should see the following with regards to its neighbors


Looking at the topology from R2’s perspective we get the following:


Let’s go over some of the terminology in this command so that we understand what we are looking at. In here we have a list of all routes that have been learned via EIGRP or are being advertised via EIGRP by us. Besides each route, we have a code which is represented by a letter and in this case we see “P” which stands for passive. In the EIGRP realm, anything that is passive means that it is in a good and stable state. When you lose a connection to one of your neighbors, any routes that had your neighbor listed as the next hop address will go into an “active” state and we will see them listed with the letter A. The active state means that we are actively looking for a backup path to reach this network.

The next parameter that we will go over is the meaning of the “successors” keyword. All routes listed have at least one successor which is the best next hop address to reach this network. The best next hop address is chosen based on the value of the composite metric and is the one that goes in our routing table. Listed right next to the number of successors is the FD keyword which means the feasible distance or EIGRP composite metric for the best route for this specific network. If we look at the network we note that it has 1 best next hop address and this next hop address has a FD of 412160. Right below this entry we see two different next hop addresses. The first next hop via has an outgoing interface of FastEthernet 0/1 and the second next hop via has an outgoing interface of Serial 2/0.

Right next to the next hop address, we have two numbers in parenthesis separated by a slash. The first number represents the composite metric calculated to this network by us via that next hop address. The second number is the composite metric for this network calculated by the advertising neighbor and is known as the reported distance. Notice that the composite metric calculate by us to network via is (412160/156160). 412160 is less than 2297856 and this means that it will go into our routing table due to the lower metric, this number is what EIGRP calls the feasible distance. The second best next way to reach this network via is considered a backup route or a feasible successor and should our primary method to reach this network go down, then EIGRP will quickly move this to the routing table. Not all backup routes make their way into the EIGRP topology table, only backup routes that have a lower reported distance(128256) than the feasible distance of the primary route(412160) will show up.

Looking at the network we notice that this route has 2 successors. This means that there are two equal cost paths or paths that have equivalent feasible distances to reach this network. When we look at the routing table:


They are both listed there and this means that we are load balancing between these two neighbors to send traffic to that destination.

The next verification command that we will look at is the following:


This command will tell you the EIGRP AS number and what our current router ID is. It list the number of routes and the number of interfaces that it is enabled on. It also shows you the number of neighbors present and which interfaces it is currently quiescent on. These interfaces are those in which there are no outstanding queries, replies, or updates on.

This is another useful command:


The show ip protocols command will give us information about the routing protocols that we are running on this router. In here we see the EIGRP protocol with the AS number that we configured. This command shows us the K values and which ones we have currently turned on as indicated by a value of 1. Of other importance here is the variance which is used for load balancing purposes and is something that we will be discussing as well. The other important field here is the maximum path which is also something that we will be looking into. Near the bottom we see the networks that we are currently advertising and also our EIGRP neighbors or routing information sources.

That finishes the majority of basic EIGRP commands that can help with troubleshooting. I will finish this article here and continue on part 2 with the advanced configuration options for EIGRP. Thank you for taking your time to read this article and I will see you here next time.

2 Responses to “EIGRP Configuration Overview Part 1”

  1. Good One.. Great Work


  1. EIGRP Configuration Overview Part 2 | HIGHLNK - […] is a continuation to part 1 of the EIGRP Configuration overview. In this article I will go over some advanced…
  2. OSPF Configuration Overview Part 1 | HIGHLNK - […] that OSPF takes an area parameter which means that the interface that matches this wildcard(See my EIGRP article for…
  3. OSPF Configuration Overview Part 4 | HIGHLNK - […] will now configure EIGRP following some of the guidelines from my previous article. See below for the commands used…

Leave a Reply