Posts Tagged ‘EIGRP’

EIGRP Network Design

November 23, 2013 10 comments


Enhanced Interior Gateway Routing Protocol (EIGRP) is a routing protocol developed by
Cisco based on the DUAL algorithm. EIGRP was previously proprietary but has recently
been opened up by Cisco with an IETF draft. EIGRP has been accused of having no hierarchy.
This post will show that it’s a false claim and highlight important design factors to
make EIGRP behave and scale in the best way. Future posts will look at OSPF and ISIS.

EIGRP hierarchy

EIGRP has no areas like OSPF does. So how can hierarchy be achieved with EIGRP? First,
let’s remember that EIGRP is distance vector so there is no Link State DataBase (LSDB)
which contains the topology. EIGRP only knows routes and next-hops. It’s still possible
to achieve hierarchy with EIGRP and this is done through summarization and/or filtering.
This means that it’s up to the administrator how much hierarchy is desired and in that
way EIGRP can have more “levels” than OSPF or ISIS.

EIGRP Scaling Considerations

Which factors are important to consider when designing a scalable EIGRP network? The
most important things to consider are IP addressing, bounding the query scope and
cutting down on the number of peers. The most critical part is to not have a too large
query scope.

Active Routes

EIGRP uses the DUAL algorithm. When the network is in its normal state the routes are
considered to be passive. The best known route by EIGRP is called the successor. If
there are loop free alternate paths, these are called feasible successors.

When an EIGRP router loses its successor and there is no feasible successor available it
will send out a query to all peers looking for an alternate path. The router then expects
to receive a reply back in, either with an alternate route or with a reply saying that
there were no alternate paths available. This query could potentially travel across the
entire network unless consideration has been taken to bound the query scope.

IP Addressing

IP addressing is always an important part of a network design but with EIGRP it is especially
important. This is because EIGRP relies on summarization to achieve hierarchy and to bound
the query scope. This means that when addressing remote sites it should be done in such a
manner that it’s easy to summarize from the distribution layer towards the core.

IP addressing

With the addressing in the diagram it’s easy to summarize and the core has fewer routes
which is always a good thing. Right now the core has 2 routes instead of 16 if the
addressing was chosen poorly.

How should the addressing be chosen? This will always depend a lot on the network but
some general guidelines should be to look at which access routers connect to which
distribution routers. The access routers should have networks so that the distribution
router can summarize these routes. Generally this would depend on the geography so
a good practice could be to assign x number of networks for each region to use. Assign
these on “binary boundaries” so instead of adding a network at a time, add 4 or 8 or
something that makes it easy to summarize.

Bounding EIGRP Queries

EIGRP queries are bounded by the following parameters:

  • Local knowledge of a loop free alternate path not learned through the peer sending the query
  • No local knowledge of route due to filtering
  • No local knowledge of route due to summarization
  • No peers to query

This can be seen in the following diagram:

Query scoping

When A loses the network it will query all peers. It’s important to note
that queries will travel one step further than the place where filtering/summary is

Where to Apply Filtering/Summarization

Where should the filtering/summarization be applied? It depends on the network topology.
The most common design is to have two or three layers. If two layers are used, generally
they are called Core and Aggregation. When three layers are used they are called Access,
Distribution and Core.

When using only two layers summarize from the Aggregation layer towards the Core.
This is important to minimize the number of routes in the Core. Routes can also be
summarized from the Core towards the Aggregation layer. The Aggregation layer does not
need to know all the routes, it might even be enough with a default route. It is not
necessary to summarize within the Core. If it’s not possible to summarize outbound
on the Aggregation router then filter on the Core edge routers.

Two layer

When using a three layer design the natural point to do summarization is at the
Distribution layer. Both towards the Core and towards the Access layer. The goal is
to minimize routes within the Core and also towards the Access layer. This will help
both with bounding queries and speeding up convergence.

Three layer

Dangers of Summarization

Although summarization is generally good there are some dangers that need to be
avoided. Summarization can cause black holes and routing loops if care is not taken.
Look at the following diagram:

Black hole

Distribution routers A and B are sending the same summary towards the core. B has a
failure towards the router with the network Because one component route is
still available in the summary, the summary is still advertised towards the core.
If traffic arrives at B destined for, the traffic will be black holed.
Potentially it could be even worse if B follows a default route back towards the
core, causing a routing loop.

To prevent against this scenario, put a link between the distribution routers that
does not do summarization. Summarization should be done up and down layers, not
across them.

Stub Routers

EIGRP has a concept of stub routers, this is not the same as stub routing in OSPF.
What the stub feature does is to define that this is the end of the network, I am
a leaf on the tree. This means that queries will not be sent to stub routers, why
send a query if it’s not possible to get a reply with an alternate path? This is
a great feature for bounding queries. This should be deployed on all Access layer
routers if possible.

When a router is configured as stub, by default it will only announce connected
and summary routes meaning that it will not be transit for any networks. If not
configured as a stub, situations like this could occur:

Unwanted transit

As shown by the arrows, the Access layer routers may become transit which is
generally not desirable. These devices may not be capable of carrying the traffic
load that was between the Distribution layer devices. Queries will also have to be
sent out when the link between A and B fails.

Minimizing the Number of Peers

Sometimes there may be dual routers attached to the same LAN as in the following diagram.

Unwanted peering

If EIGRP is configured for all networks, which could be hundreds of VLANs in a big
network, then EIGRP will peer over all networks. This leads to lots of unnecessary
adjacencies which will slow down convergence and lead to a more unstable network.
Also a lot of queries will have to be generated if a route has to go active. Avoid
this situation by using passive-interface default and choose one interface to be
non passive.


This post showed that EIGRP as a protocol does have hierarchy. This hierarchy is
imposed by doing summarization and/or filtering. To design a scalable EIGRP network,
care must be taken when designing the IP plan. Summarization, filtering and the
EIGRP stub feature is important to build a scalable network. EIGRP queries have to
be bounded and this is done through summarization/filtering and the stub feature.


EIGRP named configuration

March 15, 2013 6 comments

You might think that EIGRP being around for so long is not getting any attention from
Cisco, not true. EIGRP is still being developed and in later releases you can run what
is called named configuration. Doing this you can put all EIGRP config under one named
instance, even v6 which is different from the old syntax. If you are on Twitter you should
follow Donnie Savage @diivious. He works for Cisco and is usually present at Cisco Live
presenting on the development of EIGRP.

We start out with the following topology.


So we start out by defining our instance and calling it corp

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router eigrp corp

From there we have the following options:

Router configuration commands:
  address-family  Enter Address Family command mode
  default         Set a command to its defaults
  exit            Exit from routing protocol configuration mode
  no              Negate a command or set its defaults
  service-family  Enter Service Family command mode
  shutdown        Shutdown this instance of EIGRP

From here we can shutdown the process or configure different address families.
We start by setting up IPv4 in the global table.

R2(config-router)#address-family ipv4 autonomous-system 12
Address Family configuration commands:
  af-interface         Enter Address Family interface configuration
  default              Set a command to its defaults
  eigrp                EIGRP Address Family specific commands
  exit-address-family  Exit Address Family configuration mode
  help                 Description of the interactive help system
  maximum-prefix       Maximum number of prefixes acceptable in aggregate
  metric               Modify metrics and parameters for address advertisement
  neighbor             Specify an IPv4 neighbor router
  network              Enable routing on an IP network
  no                   Negate a command or set its defaults
  shutdown             Shutdown address family
  timers               Adjust peering based timers
  topology             Topology configuration mode

From here we define networks, setup static neighbors and configure EIGRP parameters.

We will use regular syntax on R2 for setting up EIGRP.

R2(config-if)#router eigrp 12
R2(config-router)#no auto

The session comes up.

%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor (FastEthernet1/0) is up: new adjacency

R2 is announcing it’s loopback. Lets see if we receive that.

R1#sh ip route eigrp | be Gateway
Gateway of last resort is not set is subnetted, 1 subnets
D [90/2662400] via, 00:00:23, FastEthernet1/0

What more can we configure under the address-family?

R1(config-router-af)#af-interface f1/0
Address Family Interfaces configuration commands:
  authentication      authentication subcommands
  bandwidth-percent   Set percentage of bandwidth percentage limit
  bfd                 Enable Bidirectional Forwarding Detection
  dampening-change    Percent interface metric must change to cause update
  dampening-interval  Time in seconds to check interface metrics
  default             Set a command to its defaults
  exit-af-interface   Exit from Address Family Interface configuration mode
  hello-interval      Configures hello interval
  hold-time           Configures hold time
  next-hop-self       Configures EIGRP next-hop-self
  no                  Negate a command or set its defaults
  passive-interface   Suppress address updates on an interface
  shutdown            Disable Address-Family on interface
  split-horizon       Perform split horizon
  summary-address     Perform address summarization

We configure all EIGRP interface commands under the af-interface. We can setup
authentication of the peering.

R1(config-router-af)#af-interface f1/0
R1(config-router-af-interface)#authentication mode ?
  hmac-sha-256  HMAC-SHA-256 Authentication
  md5           Keyed message digest
R1(config-router-af-interface)#authentication mode md5
R1(config-router-af-interface)#authentication key-chain EIGRP
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor (FastEthernet1/0) is down: authentication mode changed
%DUAL-5-NBRCHANGE: EIGRP-IPv4 12: Neighbor (FastEthernet1/0) is up: new adjacency

What’s new here is that sha-256 is now also supported. From this af-interface mode
we can configure timers and BFD as well.

Now we will configure IPv4 in a VRF called 13.

R1(config)#vrf definition 13
R1(config-vrf)#rd 13:13
R1(config-vrf)#int f1/1
R1(config-if)#no sh
R1(config-if)#vrf forwarding 13
R1(config-if)#ip add
R1(config-router)#address-family ipv4 vrf 13 autonomous-system 13
%DUAL-5-NBRCHANGE: EIGRP-IPv4 13: Neighbor (FastEthernet1/1) is up: new adjacency

Do we receive any prefixes?

R1#sh ip route vrf 13 | be Gate
Gateway of last resort is not set is subnetted, 1 subnets
D [90/2662400] via, 00:00:31, FastEthernet1/1 is variably subnetted, 2 subnets, 2 masks
C is directly connected, FastEthernet1/1
L is directly connected, FastEthernet1/1

Which we do. Nothing strange here, just a new syntax for defining VRFs compared
to the old ip vrf syntax.

Finally we will configure IPv6 peering as well. Because EIGRP sends packets from
link local address we don’t even need to configure a global IPv6 address.

R1(config-router)#int f2/0
R1(config-if)#ipv6 enable
R1(config-if)#no sh
R1(config-if)#router eigrp corp
R1(config-router)#address-family ipv6 autonomous-system 14
R1(config-router-af)#af-interface default
R1(config-router-af-interface)#no shut

Only difference here is that instead of defining network we use the interface command
instead to enable it on all active IPv6 interfaces.

R1#sh ipv6 route eigrp
IPv6 Routing Table - default - 2 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
       I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
       EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
       NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
       OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
D   2001::/64 [90/2662400]
     via FE80::C803:82FF:FE80:1C, FastEthernet2/0

And that’s about it. Named configuration is made to unify configuration under
one instance and remove the commands that we used to type under the interface
like authentication and such. It’s now all done under the address-family.
In future posts I will look at Multi Topology Routing (MTR).

EIGRP draft released

February 20, 2013 4 comments

Donnie Savage, Russ White, Don Slice, J. NG and Steven Moore all from Cisco have
published the IETF draft for EIGRP.

You can find it here.

Why would you want to read this draft? If you are a CCIE candidate it should be
obvious why you want to know EIGRP very well. And what better way to confirm your
findings then straight from the horses mouth?

Even if you just want to have a basic look at EIGRP they do a good job of describing
the acronyms used in EIGRP which should be useful for anyone.

I just skimmed through the draft and I wish this had been around when I was studying.
Hopefully this leads to people discussing features when talking about OSPF vs EIGRP
and not just openness.

Categories: EIGRP Tags: , , ,

INE 10 day bootcamp – Review

September 4, 2012 10 comments

I’m back from London and it’s been a great experience. Many readers are interested in what
the bootcamp is like. It is a big investment to go for so it is understandable that you
want to know if it will be worth it. I’ll start by describing the teacher and his teaching

Brian Dennis is a well known and respected man in the network industry. He is CCIE #2210
and has 5x CCIEs. That is among the very best in the world. Brian is not one of those
academic guys that only knows what is written in a book. He as a solid background in the
industry which means he can explain WHY things are the way they are and not just stating
facts without any reasoning behind it. There will be NO powerpoints, it is CLI only and
although he has a topology he is using the configurations are not prebuilt. He will do
them live which means there will be issues, which is GOOD. You get to see a 5x CCIE
troubleshooting and since he hasn’t prepared the faults before you will see how he would
troubleshoot a live problem which is very good practice for the TS lab in the CCIE lab.
Brian is a strong believer in that there are no tips and tricks. If you have an
instructor teaching you all these tips and tricks then that instructor is a fake.
If you know the technology there are no tips and tricks. Sure he can teach you some
useful commands but there are no tips and tricks in routing protocols.

Jeremy Brown is the bootcamp coordinator. He’s a very nice guy and he will help you
with any queries you have about the bootcamp. If you are attending you will be
talking to him for sure.

When you start the class the first day you will be handed a folder with paper and
a pen and some contact information. Brian will introduce himself and give some
general guidelines and explain how the real lab works with TS section and
configuration section etc. Then everyone gets to introduce themselves. My class
had a lot of nationalities, Bolivia, France, Venezuela, Sweden, UK, Ireland,
Norway, Hungary were all represented.

The bootcamp runs from 9 AM in the morning to about 19-20 PM in the evening.
There will be some 15 minute breaks and a lunch break for 1.5h. It is long
days indeed so make sure to get enough sleep in the evening. This is a pure
learning experience, leave the partying for another time. If you want to
have some fun there will be time in the weekend for that.

The first day is about layer two. Since the configuration is built from
scratch it makes sense to start out with layer two. The topology used
is based on Cisco 360 with 5 routers and 4 switches. The routers are ISR
routers and the switches are 3560’s. It is good that this topology is
used since that is very similar to what is being used in the real lab.
When attending the bootcamp you are expected to have a good knowledge
of protocols and that you have watched the INE ATC videos. This is so
that you don’t get overwhelmed by the information in the bootcamp.
The layer two section focused on MST, PPP and frame relay and
spanning tree features like BPDU guard, BPDU filter etc. One advice
that Brian gave is to try to mix in things like PPP, PPPoE, PPPoFR
etc in your labs so that you get used to using these technologies.

Later in the week we moved on to IGPs. OSPF will be the main topic.
This is natural since OSPF will guaranteed be in your lab and you
REALLY need to know OSPF to pass the lab. Brian is an OSPF
machine, he knows the LSDB like the back of his hand. He is very
methodical and will confirm each step and show you in the LSDB
what we are seeing and why we are seeing it. He’s not one of
those guys that clears the routing table when he runs into a
glitch, he will explain how and why it is there. He had a very
good section about the forwarding address, this is an important
part of OSPF and Brian explained why it is used. He had a very
good analogy with BGP where basically if the FA is not set then
you are using next-hop-self and if it is set then the next-hop
is preserved. He also had a good explanation of the capability
transit feature and he did some great diagrams showing which
LSAs go where. This is basic knowledge but he put it so well in
that diagram. We also talked about virtual links and things like
that. One good command he showed was the show ip ospf rib
command. EIGRP and RIP will be shorter sections, he will only
show some more advanced configuration since these protocols are
a bit simpler to understand. For EIGRP he showed hot do do
unequal cost load balancing and how to calculate the metric
if you want to get a certain ratio. He showed how to do
offset-list, leak maps and authentication.

After we were done with IGPs we moved on to route redistribution.
This topic alone is enough to provide a good bootcamp experience.
Brian will in detail explain the difference between control plane
and data plane loops and why loops can occur. The important thing
to remember is that we are trying to protect the routes with a
high AD from being learned in a protocol with a lower AD. Usually
RIP is involved or EIGRP external routes since those have a high
AD. Brian will show you how to take any INE Vol2 lab topology
diagram and just look at it and identify potential issues.
This is a very good practice and when you can look at a diagram
and know what to do without even thinking about configuration
yet then you are in a good place. Brian will with his diagrams
show you where every command lives like the OSPF LSDB, OSPF RIB,
RIB, FIB etc. This is very good practice to make sure you have
a full understanding of what is going on.

BGP is of course an important topic and Brian is covering that
for sure. Brian starts by describing peering and goes through
some common misconceptions. BGP has no authentication,
wait for it…TCP has, this is a common misconception. It is
TCP providing the authentication of packets and not BGP.
He will explain concepts like hot potato vs cold potato routing.
He will show you the difference between disable-connected-check and
ebgp-multihop. He will teach you about route reflectors and
confederations and why you want to use the one or the other.
He will also explain MED in detail, something I found very useful,
explaining how deterministic MED works and always-compare-med.
He has such knowledge of everything and one thing I didn’t know
before is that networks in the BGP table are sorted by age where
the youngest network is listed first.

Building on BGP means MPLS comes naturally. These go hand in
hand and for the v4 CCIE lab you need to know MPLS. Brian
will of course explain the use of RD and RT. Remember that RD
only has a use in BGP. He shows where all the commands and
routes live and how to do troubleshooting for MPLS. The good
thing is that you will run into things that you didn’t maybe
think about and that will provide great troubleshooting. OSPF
is the most complicated PE-CE protocol and he will give you all
the details how to use Domain-ID, sham links and how the
external route tag and DN bit works.

First week is over. Time for some recovery. Have some fun and
go for some sightseeing or just do labs, the choice is yours.
Just make sure that you are well rested for when monday comes.

The second week started out with multicast. This was maybe my
favourite topic and I learned a lot from this section.
As I mentioned earlier Brian doesn’t believe in tips and tricks
and multicast is one of those topics where people have a lack
of understanding and that is why they go looking for tricks.
Multicast is 90% about PIM, you need to know PIM if you want
to be good with multicast. Brian shows common errors like having
a broken SPT or RPF failures and things like that. These usually
occur when hub and spoke frame relay is involved. With just a
few commands you can become very good with analyzing multicast.
Show ip pim interface, show ip pim neighbor,
show ip rpf x.x.x.x and show ip pim rp mapping will give you most
of the information you will need. The best thing about the
multicast section was that when we ran into errors Brian was very
methodical, instead of just pinging over and over he showed us
what was wrong and then cleared the mroute table, this will
make the mtree build again so that you always go back to a
well known state. It is probably common to have the correct
configuration but move away from it due to lack of patience
or lack of understanding of what is really going on.

Time for the killer topic, probably the most hated topic in
the entire blueprint for most candidates. You guessed it, it is
time for PfR. Where does this hate come from? Well it comes
from the fact that the 12.4 implementation of PfR is just so
incredibly bad. If I were to select one topic that is difficult
to study on your own and that you can really benefit from going
to a bootcamp then that would be PfR. Brian starts out with some
basic topologies and then moves on to some more advanced scenarios.
This topic runs for one day or even a bit more. You WILL run into
a lot of issues due to the implementation of PfR in 12.4. If you
have seen the PfR Vseminar then this will be a lot like that
with the added benefit that you can ask Brian questions of course.

The next big topic is QoS. Brian goes through frame relay
traffic shaping using both legacy syntax and MQC. He will go
through how to use policing and shaping. The coolest thing
about this part was how we configured values for policing
like Bc and then Brian showed by sending ICMP packets how the
token buckets are really working. You might be in for some
surprises here! No powerpoints here for sure! He will explain
the difference between single rate and dual rate policers and
why you would configure them for which scenarios. Then he will
go through the Catalyst QoS. This is a confusing section for
many since the Catalyst QoS is a bit convoluted. Brian shows
how the L2 QoS is very similar to MQC but the syntax is just
a bit strange. He shows how to use the priority queue and how
to use the share and shape queues for the SRR queues.

Whatever time is left will be spent on topics like EEM and
services that you would like to go through. If you feel that
you are weak in some service then this would be a good time to
ask Brian to go through it. I left the bootcamp at 3 PM on
friday and I probably missed a couple of hours in the end.
If you can find a later flight or go home on saturday that
could be a good option.

So now you have gone through a wall of text and you are
whondering what I think about it? Well if it wasn’t obvious
from my text then Yes! Go for it! Yes it costs to go and
with everything to account for like living expense and hotel,
yes it is costly. However if you look just at the price for the
bootcamp which is around 5990$. That is actually a good price,
if you consider that you can get 1500$ paid for your lab then
the cost is actually 4500$ Where I live one week of training
at Global Knowledge is usually around 3000$ for a week and
then often you get some Power Point guy reading slides or you
doing labs while the instructor is watching. The one thing I
found best about the bootcamp was that you learn how to think
at a higher level. Being a CCIE is not about knowing a lot of
commands, it is about thinking at a high level. You get to pick
the brain of a 5x CCIE with real world experience, you won’t
find many guys like that in the world and from what I’ve seen
I would rank Brian among the very best of them. The IGP, Multicast,
Redistribution, PfR sections were very good and you will learn a lot
for sure even if you were strong in these areas before.

Hopefully in class you will meet some new friends. I met some
people people in class I had only seen online before and also made
some new friends. I had a great time with David Rothera, Gian Paolo,
Jose Leitao, Susana and Harald. I also met Darren
for the first time, we have known each other online for a while now
but never met. I also had the chance to meet Patrick Barnes which is
another of my online friends 🙂

I’ve tried to cover as much as I can remember but always feel free
to ask questions in the comments section if you have anything you are
still thinking about.

Route redistribution – Route-maps and tagging

August 16, 2012 2 comments

Earlier I have done some posts on route redistribution and on
route filtering in different protocols. I wanted to expand on this
by showing different ways we can tag and do filtering with route-maps
when doing route redistribution.

We start out with this topology where two different OSPF segments are
separated by an EIGRP segment.

R2 will redistribute between OSPF and EIGRP mutually. R1 is redistributing
its loopback so it will be an external OSPF route. R4 and R5 will mutually
redistribute between EIGRP and OSPF. One interesting aspect about EIGRP is
that in the EIGRP packet we can see which protocol that originated the
route from the beginning. Take a look at this output showing the R1 loopback
in the EIGRP domain.

R4#sh ip eigrp topo
IP-EIGRP (AS 100): Topology entry for
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560002816
  Routing Descriptor Blocks: (FastEthernet0/0), from, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that it came from OSPF 1 and that the ASBR is
We also see that it had a metric of 20 and no tag applied to it. Where
is this information carried? Take a look at this packet capture.

We can see that a lot of information is carried for external routes.
This gives us options when doing tagging and filtering.

We configure distribution on R2 and then look at our options for doing
tagging and filtering.

R2#sh run | s router
router eigrp 100
 redistribute ospf 1 metric 1 1 1 1 1

If we look at R4 we should have two external routes with AD 170 going towards
the OSPF domain.

R4#sh ip route eigrp | i EX
D EX [170/2560002816] via, 00:07:22, FastEthernet0/0
D EX [170/2560002816] via, 00:07:22, FastEthernet0/0

If we traceroute this traffic will go straight to R2.

R4#traceroute num

Type escape sequence to abort.
Tracing the route to

  1 32 msec 40 msec 28 msec
  2 60 msec *  64 msec

What if we want external routes to go through R5 instead? We can
match on the route-type and incoming interface to block R2 routes.
This is a pretty blunt tool but can be good for some scenarios.

R4(config)#route-map RM_DENY_EXT_FA0/0 deny 10
R4(config-route-map)#match route-type external
R4(config-route-map)#route-map RM_DENY_EXT_FA0/0 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FA0/0 in fa0/0

So what we just did is filter all external routes coming in on Fa0/0.
Did we achieve the wanted result?

R4#sh ip route eigrp | i EX
D EX [170/2560030976] via, 00:00:21, FastEthernet0/1
D EX [170/2560030976] via, 00:00:21, FastEthernet0/1
R4#traceroute num

Type escape sequence to abort.
Tracing the route to

  1 40 msec 36 msec 16 msec
  2 56 msec 40 msec 40 msec
  3 48 msec 28 msec 44 msec
  4 68 msec *  68 msec

Now all external routes will go through R5 instead.

Currently we are not doing redistribution on R4 and R5. What will
happen with the EIGRP external routes when we do redistribution?
First we remove the previous configuration and then we configure

R4(config)#router eigrp 100
R4(config-router)#no distribute-list route-map RM_DENY_EXT_FA0/0 in FastEthernet0/0
R4(config-router)#redistribute ospf 1 metric 1 1 1 1 1
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 sub
R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 1 1 1 1 1
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 sub

From R4 we now look at how it reaches

R4#sh ip route
Routing entry for
  Known via "eigrp 100", distance 170, metric 2560002816, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from on FastEthernet0/1, 00:00:52 ago
  Routing Descriptor Blocks:, from, 00:00:52 ago, via FastEthernet0/1
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1
  *, from, 00:00:52 ago, via FastEthernet0/0
      Route metric is 2560002816, traffic share count is 1
      Total delay is 110 microseconds, minimum bandwidth is 1 Kbit
      Reliability 1/255, minimum MTU 1 bytes
      Loading 1/255, Hops 1

Why does it have two entries for Take a look in the
EIGRP topology table.

R4#sh ip eigrp topo
IP-EIGRP (AS 100): Topology entry for
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 2560002816
  Routing Descriptor Blocks: (FastEthernet0/0), from, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is
        AS number of route is 1
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000) (FastEthernet0/1), from, Send flag is 0x0
      Composite metric is (2560002816/2560000256), Route is External
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 110 microseconds
        Reliability is 1/255
        Load is 1/255
        Minimum MTU is 1
        Hop count is 1
      External data:
        Originating router is
        AS number of route is 10
        External protocol is OSPF, external metric is 20
        Administrator tag is 0 (0x00000000)

We can see that one route is originating from OSPF 1, which is the true
source of the route and one is originating via OSPF 10. R5 is learning
this route via OSPF and then redistributing it into EIGRP and R4 is
learning that via EIGRP. Let us confirm that R5 sees this as an OSPF

R5#sh ip route
Routing entry for
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 1 1 1 1 1
  Last update from on FastEthernet1/0, 00:08:12 ago
  Routing Descriptor Blocks:
  *, from, 00:08:12 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

Which it does. What would happen if R5 was redistributing with a
better metric than R2 is doing? First we enable debugging of ip
routing on R4. Remember that in a stable topology where everything
is converged there should be no changes.

R4#debug ip routing
IP routing debugging is on

Then we change the metric on R5.

R5(config)#router eigrp 100
R5(config-router)#redistribute ospf 10 metric 100000 10 255 1 1500
RT: eigrp's (via metric changed from distance/metric [170/2560002816] to 

RT: del via, eigrp metric [170/2560002816]
RT: eigrp's (via metric changed from distance/metric [170/2560002816] to 

RT: del via, eigrp metric [170/2560002816]

We can see that the metric change but at least we have no flapping.

R4#sh ip route
Routing entry for
  Known via "eigrp 100", distance 170, metric 30720, type external
  Redistributing via eigrp 100, ospf 10
  Advertised by ospf 10 subnets
  Last update from on FastEthernet0/1, 00:02:33 ago
  Routing Descriptor Blocks:
  *, from, 00:02:33 ago, via FastEthernet0/1
      Route metric is 30720, traffic share count is 1
      Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Do we still have reachability?

R4#traceroute num

Type escape sequence to abort.
Tracing the route to

  1 40 msec 16 msec 28 msec
  2 48 msec 32 msec 28 msec
  3 24 msec 44 msec 28 msec
  4 52 msec 48 msec 52 msec
  5 60 msec 60 msec 64 msec
  6 64 msec 60 msec 60 msec
  7 84 msec 108 msec 100 msec

Now we have a routing loop. What is happening here is that R4
is learning the route first via EIGRP and redistributes it into
OSPF. R5 learns this route via OSPF and then redistributes it
back into EIGRP and then R4 learns this route. They are now
both pointing at each other which means we have a loop.

What are our options of solving this? One way of solving it is
to increase the OSPF external AD on R5. That way R5 should not
redistribute it back to R4.

R5(config-router)#distance ospf external 180

R4#sh ip route
Routing entry for
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 2
  Last update from on FastEthernet1/0, 00:00:38 ago
  Routing Descriptor Blocks:
  *, from, 00:00:38 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

R4#traceroute num

Type escape sequence to abort.
Tracing the route to

  1 56 msec 36 msec 16 msec
  2 48 msec 40 msec 40 msec
  3 52 msec 52 msec 52 msec
  4 112 msec 76 msec 72 msec
  5 96 msec *  120 msec

That solved the loop changing the distance is a bit of a hack unless
we incorporate the same policy on all devices. At least all devices
involved in redistribution should have the same policy.

R4(config)#router ospf 10
R4(config-router)#distance ospf external 180

R4#traceroute num

Type escape sequence to abort.
Tracing the route to

  1 28 msec 32 msec 12 msec
  2 44 msec *  60 msec

Yes, that solved it. A more elegant way is to use tagging and
filtering. We remove the previous distance commands.

What we can do now is to tag all external routes coming from OSPF 1
and then deny those routes from coming in if they have a tag set.
On R4 we tag routes with tag 444 and on R5 we will tag with 555.
First we confirm that the loop is back. You should note that with
redistribution you may see different results than I due to order of
operation. If that happens you could shutdown R5 link to R3 and
the loop should be back.

R4#traceroute num

Type escape sequence to abort.
Tracing the route to

  1 16 msec 44 msec 24 msec
  2 36 msec 28 msec 36 msec
  3 32 msec 40 msec 32 msec
  4 48 msec 56 msec 48 msec
  5 64 msec 56 msec 68 msec
  6 48 msec 64 msec 60 msec

It is still there. Time for some route-maps.

R4(config)#route-map RM_DENY_EXT_FROM_R5 deny 10
R4(config-route-map)#match tag 444
R4(config-route-map)#route-map RM_DENY_EXT_FROM_R5 permit 100
R4(config-route-map)#route-map RM_SET_TAG_444 permit 10
R4(config-route-map)#match source-protocol ospf 1
R4(config-route-map)#match route-type external
R4(config-route-map)#set tag 444
R4(config-route-map)#route-map RM_SET_TAG_444 permit 100
R4(config-route-map)#router eigrp 100
R4(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R5 in
R4(config-router)#router ospf 10
R4(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_444 sub

First we will confirm on R5 that we now see a tag.

R5#sh ip route
Routing entry for
  Known via "ospf 10", distance 110, metric 20
  Tag 444, type extern 2, forward metric 2
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 100000 10 255 1 1500
  Last update from on FastEthernet1/0, 00:00:48 ago
  Routing Descriptor Blocks:
  *, from, 00:00:48 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1
      Route tag 444

We now see the tag. There should be no tag on EIGRP internal routes.
We can confirm this on R6.

R6#sh ip route
Routing entry for
  Known via "ospf 10", distance 110, metric 20, type extern 2, forward metric 1
  Last update from on FastEthernet0/1, 08:28:39 ago
  Routing Descriptor Blocks:, from, 08:28:39 ago, via FastEthernet0/1
      Route metric is 20, traffic share count is 1
  *, from, 08:30:34 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

There should be no loop on R4 now. We will test with a traceroute.

R4#traceroute num

Type escape sequence to abort.
Tracing the route to

  1 28 msec 44 msec 12 msec
  2 36 msec *  48 msec

The loop is gone. We should implement the same policy on R5 so if
R4 sends routes back to R5 it should stop it from learning them.

R5(config)#route-map RM_DENY_EXT_FROM_R4 deny 10
R5(config-route-map)#match tag 555
R5(config-route-map)#route-map RM_DENY_EXT_FROM_R4 permit 100
R5(config-route-map)#route-map RM_SET_TAG_555 permit 10
R5(config-route-map)#match source-protocol ospf 1
R5(config-route-map)#match route-type external
R5(config-route-map)#set tag 555
R5(config-route-map)#router eigrp 100
R5(config-router)#distribute-list route-map RM_DENY_EXT_FROM_R4 in
R5(config-router)#router ospf 10
R5(config-router)#redistribute eigrp 100 route-map RM_SET_TAG_555 sub

And that concludes this lesson. Route redistribution is always fun 🙂
You can look at some of my older posts for more ideas about filtering

Filtering routes in EIGRP

July 21, 2011 Leave a comment

EIGRP is often called a hybrid because it has some similar features to link state protocols and
also has distance vector features but the truth is that it is a distance vector protocol.

Even though it is distance vector it does have some nice features and today I will show a
couple of different ways of filtering in EIGRP.

We start out with this topology of four routers. You can download the topology and initial
configs from here.

Routers R1-R3 are running EIGRP in AS1 and routers R2-R4 are running RIP. R4 is announcing
a loopback in RIP. We configure R2 and R3 to redistribute from RIP to EIGRP and then
I will show how to filter the route.

R3 is configured exactly the same. Let’s see if we can see the prefix.

Indeed we can. Now let’s look at our filtering options.

We will start out with a regular distribute-list, everyone knows how to do this. We create
a standard access-list matching our prefix

The prefix is now filtered. What if we want to block the prefix but only from R2 and allow
it in from R3? Either we could reuse the ACL and apply it to the interface in our distribute-list
but that might not be possible if R1-R2-R3 were connected on a common Ethernet segment.

We will use an extended access-list instead, the source will match on the gateway
announcing the prefix and the destination will be the prefix we want to filter.
So let’s block the prefix from R2. In this case we must use a numbered ACL, named ACL’s
don’t work for some reason.

That worked as expected. We now only see the route from R3.

The downside of using ACL’s is that we can’t match on prefix length. We need to use
a prefix-list for this. Lets try that. We will announce a /25 subnet from R4 and filter
any prefixes that are longer than /24.

Let’s check that it is reachable from R1.

Indeed it is. Now let’s filter this with a prefix-list.

Hey! Where did all my routes go?! We forgot to permit everything else with le 32.
Now we have filtered the /25 but allowed everything else. If we want to be more
specific we can tie this distribute-list to the neighbors and even interfaces.

We can also filter using the distance command. How does that work? Remember that
the lower the AD the more trustworthy a route is. What happens if we set it to 255?
255 is the worst and routes with 255 won’t even be considered for installing into
the routing table. Let’s try that. We start by adding some prefixes on R2.
We add on a loopback and then we create two static routes, one that is
redistributed via the network command and one that is redistributed via static.

Let’s look at the routing table of R1.

First notice that is an internal route but is an external.
If we redistribute static they will be external, that is well known. No as well known
is the possibility to create a static route and redistribute it via the network command.
If we do this we must route to an interface instead of a next-hop. The advantage is that we
can make the route look internal. Now let’s try some filtering. Unfortunately we can’t
change the AD for specific external routes, it’s all or nothing. Let’s say that we don’t
want to install any external paths. This is the current state of R1 and external routes.

We will set the AD to 255 for all external routes.

Now the routes are gone. What if we want to filter a specific internal route?

We set to distance to 255, we don’t care about the route source and we match ACL 1
which is the route that we want to filter.

There is one more type of filtering I would like to show and it is the route-map.
We will configure a route tag on R3 and match this tag on R1.

First we look at the route to on R1, it is installed via R3.

Then we configure tagging on R3.

Now we configure a route-map that matches the tag and denies the prefix.

The route is now installed via R2 instead. The great thing with EIGRP is that we
can use the route-map with the distribute-list which we can’t with other

We can even do more advanced things like matching on source-protocol or metric.

Now look at the routing table.

Only the routes that were not source from RIP are still in the routing table.

This post should give you a good understanding of what filtering is available
in EIGRP. The possibilities are endless!

Enhanced Interior Gateway Protocol (EIGRP) – notes

November 20, 2010 Leave a comment

  • Cisco proprietary
  • Uses IP protocol 88 as transport
  • Support for MD5 authentication (no clear text)
  • Sends updates to
  • Distance vector but has some link state like features


Uses a hello and a hold timer. Neighbors discovered via hello protocol. Hold timer used for declaring when a neighbor is dead. EIGRP doesn’t use it own timers for keeping track of the neighbor, it uses the timers that the neighbor supplied in the hello packet. Retransmission TimeOut (RTO) timer used for knowing if to resend an update to a neighbor. Smoothed Round Trip Time (SRTT) keeps track of latency between neighbors and the RTO is derived from the SRTT timer. SRTT is the average time in ms between sending a packet to a neighbor and receiving an ACK. The default timer for hello is 5 seconds for most interfaces and a hold time of 15. NBMA interfaces with T1 or lower speeds use a 60 second hello timer and a 180 second hold time. Changing the hello timer does not automatically adjust the hold time.

Sending updates

Updates are sent as multicasts but resends are unicast to neighbors who didn’t ACK the update before the RTO timer expired. 16 resends using unicast will be used before declaring a neighbor dead. The multicast flow timer is used for knowing when to switch to unicast packets instead of multicast for a neighbor.


Based on cumulative delay and constraining bandwidth. Can factor in load, reliability and MTU if needed but not recommended by Cisco. To change what K values are used (constants) set them with the metric weights command. To calculate the metric use: 256*(10^7/bandwidth)+256(delay).

EIGRP measures delay in tens of microseconds, this needs to be considered when calculating the metric.
EIGRP uses Reported Distance (RD) and Feasible Distance (FD) for the metric. Reported distance is what the neighbor sending the update has calculated the metric to be. Feasible distance is the distance of the route with the lowest metric, it is the RD + the distance between the neighbor announcing the route and the local router. The route with the lowest metric that is entered into the routing table is called a successor route. A feasible successor route is a route that doesn’t have the lowest metric but meets the feasibility condition meaning it has a RD lower than what the current FD is.

Input events and local computation

When an input event occurs EIGRP needs to react, this could be an interface failing, a neighbor failing or an update for a new prefix. When the input event has occured EIGRP performs a local computation, EIGRP looks for a Feasible Successor (FS) route in its topology table and if it cannot find one it will actively query its neighbors for a route.

EIGRP algorithm

Uses the Diffusing Update ALgorithm (DUAL). Functioning routes are in a passive mode. Routes that no longer have a successor is in active mode since the route has to query its neighbors for a FS. The term Stuck In Active (SIA) means that an route has been active for too long, the active timer has expired. The active timer is set to 180 seconds by default, the active timer can also be disabled if needed.

Load balancing

EIGRP allows for up to 16 equal-metric routes to be installed in the routing table, the default is four.  EIGRP also has something called variance. Variance allows for non equal-metric load balancing.  The route still has to meet the feasibility condition to be considered for load balancing. The variance command is a multiplier,  if the FD is 10000 for the current succcessor and there is a FS with a RD of 5000 and FD of 200000, variance 2 would make the router load balance between these two routes, variance 2 means the FD of the second best route can be twice as high as the best.
The load balancing can be done in a few different ways, traffic-share balanced means that the traffic will be distributed according to the metric, routes with lower metrics will see more traffic on them. Traffic-share min, install multiple routes but send only traffic on the one with the lowest metric. Traffic-share min across-interfaces, if more than one route has the same metric choose different outgoing interfaces for a better load balancing. The no traffic-share command will balance evenly across routes no matter what the metric is.


EIGRP has support for MD5 authentication, clear text is not supported. The keys are entered into a key-chain. A key can have a lifetime specified or use a lifetime that is always valid. Authentication is configured per interface.


Uses auto-summary by default, turned off with no auto-summary. EIGRP has support for summarizing on every EIGRP interface compared to OSPF which can only summarize at area borders.

Split horizon

EIGRP is a distance vector protocol which means it uses split horizon. Split horizon means the router doesn’t send updates back out on the interface it received them. This can cause issues in non P2P networks. Split horizon can be turned off on an interface basis with the command no ip split-horizon eigrp asn command where asn is the AS-number specified.


Has support for distribute lists and offset lists. Distribute lists are used for filtering inbound or outbound routing updates and what is allowed to enter the routing table. Offset lists are used to change the metric, only adding to the metric is supported, not removing from it.

Categories: CCIE, EIGRP, Notes, Routing Tags: , , ,