When designing an enterprise network, you will need a routing protocol at some point. If your network is a campus or data center, you will want to use an IGP routing protocol. You have three main choices: OSPF, EIGRP, or IS-IS. Even if I am not a fan of EIGRP, I know you can build large, reliable, and fast networks with it. EIGRP’s main downside is that it became a standard later, so only Cisco and Huawei implement it. If your network is full Cisco, and you don’t plan to introduce other vendors, EIGRP can be a valid choice. In this post, we will see how to prepare a solid EIGRP design that addresses most of the needs in the enterprise.
As you can tell, this post is all about network design. This means it may be hard to understand if you are new to routing concepts. If you are, start small by understanding EIGRP first. Once you understand how it works, you can start thinking about making a design with it.
EIGRP Design
How to optimize EIGRP
To optimize EIGRP, we need to know how it works. EIGRP is considered an advanced distance-vector protocol. It means that routers forward packets around the network based on the information they receive from their peers. No router holds a complete picture of the network, instead they trust their peer will get the packet where it needs to go. So, the job of each router is only to get the packet to the right next router.
To ensure each router knows what is the right next router, routers speak with each other. They send and ask routes and updates, and this process can be cumbersome. The more routers you have, and the farther apart they are, the more the complexity increases. With that complexity, routers takes time to get their message across the entire network.
If a router has no information about a destination, it will query its peers for it. All the peers will query their other peers, and so on until some router with the route is found. The potential reach of each query is the query scope. The larger it is, as we said, the more time it takes to get information around. Furthermore, if it is too big you may start to have loops. So, the best way to optimize EIGRP is to reduce the query scope.
The best way to optimize EIGRP is to reduce the query scope.
An approach could be to segment a larger EIGRP network into smaller ones, and redistribute between them. Not recommended! This will cause metric issues, as the metric is not propagated by default from an EIGRP as to the other. It will lead to suboptimal routing. Instead, there are other solutions to optimize the query scope.
Multilayer EIGRP
A valid design is multilayer EIGRP. In fact, even if EIGRP has no concept similar to OSPF areas, you can still design it to be multilayer. In other words, you are producing a multi-tiered hierarchical topology, which can be of two or three layers, depending on the need. If you are familiar, this is similar to the three-tiered LAN architecture.
To deploy EIGRP in a hierarchy, you need to identify zones and choke points. A zone is simply a group of routers with many connections between each other. Typically, it may be a site or a building. Instead, a choke-point is a router placed between zones, in such a manner that the only way from a zone to another is via one or two choke points.
Once you identify the choke points, you can start applying summarization on them. The more you can summarize, the less routes will appear in the routing tables of your routers. Less routes means less queries, which turns out to reduce the query scope as well. This also makes the network more stable, as the change to a small network does not trigger an entire recomputation: only routers knowing the specific network will do that, not the ones receiving the summary.
If you want to do efficient summarization, as with any protocol, you need to have a consistent addressing plan so that devices addresses in a zone are somewhat contiguous.
With this approach, you can easily deploy two or three layers. If you are starting small, deploy a flat network and consider that as the core. In case your network grows, you will attach new zones to it.
Tuning
Having a multilayer EIGRP design is a good start, but you can do some additional tuning as well. This becomes more important if you want to have your hierarchy on three levels. Here are a few rules to apply.
- Implement routing policies to control how many/which routes the distribution layer will accept from the access
- Aggregate (summarize) in the distribution layer as much as possible
- Consider traffic engineering to direct traffic to the best core router based on source-destination
Hub-and-Spoke
In some cases, you may have a network where all the remote sites talk with each other through a central location, the hub. If you plan to run EIGRP on this design, you may face several challenges. For example, summarization can be harder, and if the connection between the spokes and the hub is redundant you may end up with suboptimal routing. That’s because traffic may get to the “wrong” router inside the hub, the one which is farther from the target destination. This is common if you want to summarize toward the spokes.
A solution to that is route leaking. It means you still advertise the summary, but also advertise some more specific routes from a router. Both routers in the hub will advertise the spoke they connect to, but one of them will also advertise the leak. That router will be the preferred for that destination, allowing even a sort of load balancing.
If your spokes are simply dead ends of the network, you can consider making them stub. They will basically receive only a default route from the hub, reducing the query scope enormously.
Fast Convergence
EIGRP may be slow in reacting to network changes. To ensure it is fast enough, always enable Bidirectional Flow Detection (BFD). BFD is a protocol to monitor layer 2 reachability between two routers with fast hellos. Using that will detect issues much faster than native EIGRP detection. If you are curious about BFD, you can read RFC 5880.
Wrapping it up
This post, packed with information, does not one to make you a master of EIGRP design in 20 minutes. Instead, it aims to give you an idea of the areas where you need to focus in order to have your EIGRP design right. In a nutshell:
- Focus on reducing the amount of queries traversing the network (query scope)
- Do that with summarization at strategic choke points, and consider route leaking to prevent suboptimal routing
- Use BFD to converge faster
- Try to have your network as hierarchical as possible
Are these considerations enough to kick-off your EIGRP design? Do you have some doubts? Let me know in the comments.
