Introduction

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 10.0.0.0/24 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
applied.

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 10.0.0.0/24. 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 10.0.0.0/24, 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.

Summary

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 Network Design
Tagged on:                     

11 thoughts on “EIGRP Network Design

  • November 23, 2013 at 2:41 pm
    Permalink

    Good post Daniel. First time I’ve seen this written down and I have done such a hierarchical design all be it with a single large Core and multiple Access Areas connected to it for a UK-wide network. Use of ip prefix-lists, distribute lists, reduced adjacencies over multiple VLANs and default routes for pre-defined large network blocks solved the problem.

    This Network looked a lot like a standard OSPF or ISIS two-layer topology.

    Reply
    • November 23, 2013 at 9:57 pm
      Permalink

      Great to hear from you man. EIGRP can be very scalable when designed the right way. I heard of a network that was like 4 levels. Something like access router for region, distribution router for region, national distribution router and national core. There were very few routes in the Core because they designed it properly.

      Sounds like you did a good job of designing it 🙂 How are things otherwise?

      Reply
      • November 24, 2013 at 12:44 pm
        Permalink

        Daniel,

        Hi, I’m fine thanks. Still haven’t made time to sit the Lab and am winding up to re-do the Written in the coming month because of this.

        On “my” EIGRP Network design – even though the final solution looked good and kept routes to a minimum it was a lot or work to design and build, especially so compared to just dropping in Int ISIS or OSPF. I have a lot of respect for EIGRP and was really pleased to see the IETF picking this up!

        I liked your STP training demo!

        Cheers.

        Reply
        • November 24, 2013 at 1:49 pm
          Permalink

          ISIS and OSPF are easier that way but I think EIGRP can beat them in many ways if done right with the flexibility that comes with it.

          Glad to hear you like the STP demo 🙂

          Wish you luck when you do sit the lab. Keep in touch and tell me if you need any help.

          Reply
  • November 23, 2013 at 2:43 pm
    Permalink

    As always great write up. Few more years there will be lot of movement towards flat network rather than hierarchy network, as lot of enterprises start to question about need for distribution layer though. When SDN matures this will happen.

    Reply
    • November 23, 2013 at 9:55 pm
      Permalink

      Thanks Selva,

      Great to hear from you. Yes, we will see some flat networks working like a fabric. I think this is still some time away for SP and Enterprise though. Datacenter will be the first to take the plunge.

      Reply
  • November 23, 2013 at 7:05 pm
    Permalink

    Well done! Great write up. Easy to understand. Good timing for me as I’m redesigning an EIGRP network.

    Reply
    • November 23, 2013 at 9:54 pm
      Permalink

      Great to hear that 🙂 I actually think EIGRP is a very good protocol that has got a lot of bad credit due to that it was Cisco proprietary.

      There is a good Cisco Live session where they discuss that Cisco proposed to IETF to start with EIGRP as a standard but the IETF declined.

      Reply
  • December 2, 2013 at 3:03 pm
    Permalink

    I’m curious how widely EIGRP is deployed in Sweden, specifically. Do the big cisco shops default to OSPF irregardless of circumstances?

    Reply
    • December 2, 2013 at 3:59 pm
      Permalink

      I can only speak of my own experience but I haven’t seen EIGRP in the places I have worked/done consulting. One reason probably being that bigger shops usually have at least some non Cisco devices. The other reason is probably that people know OSPF better, or at least they think so.

      EIGRP is actually much simpler protocol wise and it will converge much faster by default if you design your network properly.

      I have no issue with people choosing one or the other but they often do so for the wrong reasons.

      Reply
  • October 4, 2016 at 4:25 pm
    Permalink

    Hi Daniel ,
    Great work !! This actually gives clear picture about the designing the network when eigrp is an option as protocol . It simplifies the complex things. As a matter of understanding the eigrp is easy but when it comes to design it becomes hard to visualise the eigrp routes moving and implementing design and giving the answers to the shareholders for purpose of the design . I am also looking for some more practical scenarios and case studies where eigrp is implemented successfully with stepwise approach .I want to take references for my datacentre and multiple sites design approach . It also has the connections for site to site vpn ,IPsec GRE tunnel using eigrp to exchange routes between datacentre and remote sites .Please help me to get more design cases so I become confident on my assignments.
    Thanks in advance for your support !!
    Girish

    Reply

Leave a Reply to reaper81 Cancel reply

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