This is a continuation to part 1 of the EIGRP Configuration overview. In this article I will go over some advanced EIGRP configuration options.

One of the first things that we want to do after configuring EIGRP is to limit to which interfaces we create neighbor relationships on. On interfaces where only end-user stations will be plugged into we can set the interface mode to passive. Making the interface mode passive means that we won’t send HELLO messages out those interfaces but we will still advertise this network via EIGRP so that other routers know how to reach it.

Let’s go ahead and switch the loopback interfaces in R1 that we have configured to simulate LANs to passive mode. The following command will make this change:

R1(config-router)#passive-interface loopback 4

R1(config-router)#passive-interface loopback 5

R1(config-router)#passive-interface loopback 6

R1(config-router)#passive-interface loopback 7

You should do the same thing in the 172.16.0-3.0/24 networks that we are simulating in R4 to be LANs. The last thing is to not forget to change the interface that links us to the internet via R2 to passive mode. We shouldn’t be advertising any EIGRP information to our ISP.

We can verify passive interfaces by using the show ip protocols command:


An alternative way of making interfaces passive is to use the following command:

R1(config-router)#passive-interface default

This will make ALL interfaces passive by default. You must then manually make an interface connecting you to a neighbor not passive via the

R1(config-router)#no passive-interface TYPE #/#


The next EIGRP improvement that we will configure is manual summary routes to decrease the size of our routing table. It is always the case that a smaller routing table leads to faster forwarding of packets. In our test environment our routing table is small but imagine having hundreds if not thousands of routes. Summarization can help reduce the size of your routing table in those scenarios. EIGRP gives us the ability to summarize at any location in our network but our IP addressing assignment must be distributed in such a way that we can do efficient summarization for it to work.

Here is the current routing table for R2:


Based on the distribution of addressing in our network, R1 and R4 are places where we can summarize. R1 is advertising networks 172.16.4-7.0/24 while R4 holds 172.16.0-3.0/24 note that both of these consecutive ranges can easily be summarized into one summary address. R1 network ranges can be covered by the following summary address which covers exactly networks on a similar note we can use the following summary address for R4 which will cover Initially, when configuring this infrastructure the IP addressing assignment is something that I took into account so that I could later on do summarization. Let’s go ahead and implement summarization so that we can see how it works.

When we inject manual summary routes, we must do so under the interface of the router that will be advertising them. In this case we will apply the command to R1 and R4 on their uplinks leading to R2 and R3. Let’s go ahead and start on R1 first and let’s type the following command under the f0/0.

R1(config-if)#ip summary-address eigrp 10

Notice that the neighbor relationship with R2 synchronizes itself as soon as we configure the summary address.


Let’s take a look at R2 to see the state of the routing table:


We can see that the summary address is there now but we are still getting the other networks for some reason. Upon closer inspection you can tell that the other networks are being advertised via or R3. The reason for this is that we have still not yet configured the summary route on the serial 1/0 interface. Let’s go ahead and do so.

Looking at R2 we now have the following:


And after making the changes in R4 to both interfaces as well:


Note: It is important to remember that the summary route metric components are based on the lowest metric route upon which the summary route is based.

The next advanced EIGRP topic to look at is that of load balancing. EIGRP by default will only load balance across equal cost links. If we have multiple unequal cost links to a destination network and we want to utilize all of them then we must modify certain parameters so that EIGRP can take advantage of them. From R2 perspective the EIGRP topology looks like the following:


Network is being load balanced across two links since we have 2 successors listed with equal cost metrics for both of them. Notice how network has 1 successor and also another feasible successor via serial2/0 as a backup. If we want to use serial2/0 then we must modify a parameter that is called the variance. The variance is by default set to 1 and can be modified so that for example if we want to load balanced across links that are twice as bad as our successor then we must set it to 2. The current metric for the successor router is 412160 which means that if we want to use the backup path actively then we must set the variance to 2297856/412160 = 5.5752 or 6 since if we use 5 then 5 * 412160 will be less than the metric for the feasible successor. Let’s go ahead and do that now to see what the results are.

R2(config)#router eigrp 10

R2(config-router)#variance 6

Variance can be any multiplier between 1 and 128.


Notice how network now has two paths listed via two different interfaces. On a similar note looking at the network we see 3 paths listed. By default EIGRP is configured to support a maximum of 4 paths and this means that if we had 5 equal cost paths then we would not be able to take advantage of all of them. We can modify the maximum number of paths via the following command

R2(config-router)#maximum-paths #

Where # can be anything between 1-16. We can verify all of this information via the show ip protocols command.


The last thing that we will do is configure EIGRP authentication. EIGRP authentication will protect us by only allowing us to become neighbors with only other routers that share the same key as we do. In order for authentication to work properly, we must first configure the time settings on our routers so that they are all synchronized. We can configure NTP or set the clock manually. NTP is the recommended method as it will give us more accurate time but for this example we will just do it manually since I don’t have a local time-server configured.



R1#clock set 10:20:00 30 SEP 2013

Once we have the time set properly on our router, we must create a key chain that will hold all of our keys. The key chain is capable of holding multiple keys so that we can configure keys that will expire after a certain period of time and have another one ready to be used. Each key has a  passphrase and a validity period.

R1(config)#key chain EIGRP-KEYS

R1(config-keychain)#key 1

R1(config-keychain-key)#key-string SECRET

R1(config-keychain-key)#accept-lifetime 10:24:00 30 SEP 2013 infinite

R1(config-keychain-key)#send-lifetime 10:24:00 30 SEP 2013 infinite

The first command will create a key chain named EIGRP-KEYS and then we create a key that is number 1 on this key chain. All keys in the key chain must have unique numbers. The third command will configure the passphrase for this key and then we specify the accept and send lifetime for this key.

For this example our keys have no expiration. It is recommended to create keys that will expire after a certain amount of time. In order to not experience any downtime when keys expires, we should configure a secondary key whose start date overlaps with the end date of the first key so that your neighbor relationship never comes down.

Note: The key # and key-string has to match on neighboring routers as they are both used together to come up with the MD5 hash.

After we have created our keys, we must apply them to interfaces where we have EIGRP neighbors that we want to use authentication. When we send EIGRP messages we will use the lowest key number among all currently valid keys. When we receive EIGRP messages, we check the MD5 digest using ALL currently valid keys. The commands to enable authentication are the following:

R1(config-if)#ip authentication mode eigrp 10 md5

R1(config-if)#ip authentication key-chain eigrp 10 EIGRP-KEYS

The first command specifies that this will apply to EIGRP autonomous system 10. The second command states the key chain that we will use for EIGRP AS 10.

Notice how on R2 we get a notification stating that a neighbor change has occurred and that authentication failed as soon as we enable authentication on R1.


Looking at the EIGRP neighbor table, we see that R1 is now missing from the list as a neighbor.


After configuring authentication on R2 our neighbor relationship comes back up.


We can see that R1 is back up.


To view key chain information we can use the show key chain command:


Lastly it is important to understand that EIGRP authentication does not provide privacy as anyone can still join the multicast group and see the information that is being advertised but they can not become our neighbors and inject fake routes unless they know the authentication string.

A packet capture will show you that HELLO packets are now being sent with an MD5 digest for authentication purposes.



This finishes the coverage of the EIGRP routing protocol. Up next, I will focus on OSPF and will go through the configuration and verification for the routing protocol. Thanks for tuning in and I hope to see you here next time.

Leave a Reply