Mastering EIGRP Metric Calculations

To properly administer an EIGRP network an admin really should know how EIGRP calculates and chooses best paths. If you’ve read any CCNA or CCNP resource you’re probably thinking “that’s easy, EIGRP uses Bandwidth and Delay by default”. And you’re completely right. However, how do these two pieces of information actually influence the resulting metric?

Let’s take a look at what EIGRP devices (routers and switches) do with the bandwidth and delay values:


If you haven’t seen it before, it is the formula EIGRP devices use to calculate the metric of a route. If you’re not sure how to read this formula, don’t worry, I’ve got a shortcut :) But I’ll get to that in a moment.

Throughout this post I will be referring to the path which traffic takes when going from R2 to the network which resides on R3 and R4 as per this topology diagram:

eigrp Continue reading

EIGRP No Auto Summary Command, Part 2

A few years ago I wrote a blog post about EIGRP and the “auto-summary” command called EIGRP No Auto Summary Command, Part 1. In that post I provided a brief description of what “auto-summary” does and demonstrated how it works by creating a basic lab. Now that you’ve seen the basics though, it is time to dig a little deeper.

In the previous post we saw that R1 and R2 were both automatically summarising the and networks respectively and therefore R3 and R4 could not reach one another. That’s seems normal enough seeing as though the command is called “auto-summary”. However, things aren’t that simple unfortunately.

For example, take a look at this topology:


Both routers are running EIGRP, but only R1 has the “auto-summary” command enabled, as per the configurations below:

Continue reading

Emulating a Multi Layer Switch in GNS3

As most of you know, you can get switch-like capabilities in GNS3 by inserting a NM-16ESW in to a compatible router. This is necessary because at present, dynamips is unable to emulate a real switch. This is because Cisco switches use hardware ASICs to perform their duties and unfortunately it is difficult/impossible for this to be emulated in software.

This is not so bad though as you may find you can get quite a lot done with an NM-16ESW. You can even use it to emulate a multilayer switch, as I will now demonstrate using the following topology:


Continue reading

EIGRP Network Command Tips

I discussed the EIGRP “network” command in the EIGEP Network Command – The Easy Way Out post, as well as the EIGRP Route Advertising post, and I’m about to discuss it again in this post. Who knew one command would be the source of so many posts! :)

If given incomplete information, the EIGRP “network” command will do its best to help you complete the command, however, unfortunately it doesn’t always guess correctly.

For example, if you wanted to activate EIGRP on a single interface on your router which had the IP address, you’d use the following commands:

R3(config-router)#router ei 10

You could then use the “do” command which I discussed previously to verify that the router took your configuration entry correctly, as per the below:

R3(config-router)#do sh run | begin router eigrp
router eigrp 10

Continue reading

EIGEP Network Command – The Easy Way Out

In my EIGRP Route Advertising post I said “in order for two routers to exchange EIGRP routes, they must both be part of the same subnet and have a network command specifying that particular subnet, or, at the very least, their specific IP address on that subnet”. In that entry I then went on to use the routers’ specific IP addresses. In this entry, I’m going to explain how you can specify a larger subnet in order to reduce the number of network commands you must apply.

To do this, I’ll use the following topology:


We’ll configure the R2 and R3 in the same way as we did previous, by specifying the exact addresses of the interfaces we want to advertise.

Continue reading

Dangers of the EIGRP “Neighbor” Command

I have touched on EIGRP a few times before and here we are again.

In my EIGRP Route Advertising post I explained how EIGRP neighbor relationships can be created using the “network” command. In this post I will explain how they can be formed using the “neighbor” command and the dangers of using it as well.

To do this, I’ll be using the following topology:

To get started, let’s create a “normal” EIGRP network on all of the routers using the “network” command.

Continue reading

EIGRP No Auto Summary Command, Part 1

In my previous post about EIGRP Route Advertisements I touched on the “no auto-summary” command, but did not delve in to the details of what this command actually does, so today I will.

In a nutshell (see Part 2 for a more detailed explanation), when using EIGRP the “auto-summary” command (which is enabled by default), what happens is that the router automatically creates summary routes for all of the networks which you specify in your EIGRP configuration (with the “network” command). And these aren’t good summary routes either – they are routes which are summarised to their classful boundary.

For example, if you issue the following command:


Instead of advertising the network as /24, the router will advertise the entire /8 network instead. To prevent this from happening (which just about everyone does these days), you must issue the following command:

no auto-summary

To see what type of “damage” can be caused by leaving the default “auto-summary” command enabled, please read on.

Here is the topology I’ll be using to demonstrate:

topology Continue reading

EIGRP Route Advertising

In the forums that I frequently visit I always see people asking how EIGRP route advertising works. The users are not sure how to correctly use the “network” command and usually use more commands than are necessary. So in today’s post, using the diagram below, I will explain how to advertise EIGRP routes properly.

Now before we get started let me explain what the “network” command actually does. The “network” command tells the router which directly connected routes (routes which the router owns/is a part of) it can advertise to its peers. In order for two routers to exchange EIGRP routes, they must both be part of the same subnet and have a “network” command specifying that particular subnet, or, at the very least, their specific IP address on that subnet. Confused? That’s OK, I’ll explain it in more detail soon.

Here is the topology we’ll be using:

Let’s take a look at what R1’s routing table looks like: is subnetted, 1 subnets
C is directly connected, Loopback0
C is directly connected, FastEthernet0/0

Continue reading