In response to the scaling problems of RIP, Cisco developed a proprietary IGP of its own called Interior Gateway Routing Protocol (IGRP). This protocol was later updated and improved, with the result called Enhanced IGRP (EIGRP). Because these protocols are proprietary, they are only implemented on Cisco equipment. As always in this book, I recommend that readers avoid proprietary protocols for compatibility reasons. However, I include this discussion on IGRP and EIGRP because they are remarkably efficient and easy to implement. Furthermore, Cisco has produced not only IP, but also IPX and AppleTalk versions of EIGRP, making multiprotocol networks easier to administer.
IGRP and EIGRP are distance-vector algorithms just like RIP. But they are able to operate on much larger networks while consuming much less bandwidth. There are a number of differences between the original IGRP and the more recent EIGRP. One of the most important is that, like RIP Version 1, IGRP cannot handle Variable-Length Subnet Masks (VLSM). The other main difference is the use of a new algorithm called Diffusing Update Algorithm (DUAL )in EIGRP, which provides better convergence properties.
The enhancements in EIGRP make it a much more useful protocol. I recommend avoiding IGRP in favor of EIGRP wherever possible. In fact, the only place where IGRP is likely to be used is in older networks originally built before the advent of EIGRP. In most cases it is relatively easy to complete an upgrade from IGRP to EIGRP simply by configuring the protocols to redistribute routing information into one another. Then it should be possible simply to move the IGRP/EIGRP dividing line through the network one router at a time. Note that this might require the temporary use of additional static routes because IGRP does not cope well with splitting up networks in ways that cannot be easily summarized. The remainder of this section focuses on EIGRP.
An important difference between EIGRP and RIP is how they handle routing updates. While RIP sends out the entire routing table periodically, EIGRP only sends incremental updates. So, if a router has no updates to send, it sends only a tiny HELLO packet to each of its neighbors. This allows EIGRP to consume much less bandwidth than RIP.
The first thing an EIGRP router does when it comes up on the network is send out HELLO packets to establish the neighbor relationships with all of the routers on directly connected networks. As soon as it discovers a new neighbor, the router sends it a query requesting that it send its routing table.
EIGRP is uses a Distance Vector routing algorithm, like RIP. However, unlike RIP, the distances are calculated based on the speed and latency of each path. The latency is found by adding up the round-trip delays of every link in the path. The speed comes from the bandwidth of slowest link. The actual formula used by EIGRP[1] is:
[1] In fact, this is the simplified version of the formula that results from using the default k values. There are five variables, k1 to k5, that control the relative weightings of the delay and bandwidth. They also introduce using the reliability and load of the link to control the metric further. However, I advise using the default k parameters to avoid confusion and instability that can result from accidentally choosing poor combinations of values. As always in networking, simplicity is a virtue.
The delays in this equation are measured in microseconds; the bandwidth in kilobits per second.
Figure 6-5 shows a simple example of how these metrics work. Router R1 connects to Router R2 via a 10Mbps Ethernet connection. The delay on this link (including the latencies of the routers themselves) is 2000 microseconds (2 milliseconds). Router R2 connects to Router R3 over a 4Mbps Token Ring with a delay of 3500 microseconds (3.5 ms).
In calculating the metric to the network 10.1.6.0/24, Router R1 must first figure out what the lowest bandwidth is. It gets this information from its neighbor, R2. R2 has already found out that the minimum bandwidth is associated with the 4Mbps Token Ring that it uses to connect to R3. So R1 compares this to its own link and uses the lower one. In this way, each router along a multihop path needs only to include one minimum bandwidth for each route. At each successive hop, the next router compares the reported minimum bandwidth with that of its own link and takes the slower one.
For each successive hop, the routers must also keep track of the total delay so far. Each router adds the delay for its own leg to the running total. This greatly simplifies the calculations that each router needs to perform. In this example:
This metric is a large number. In RIP the maximum metric is 15. In EIGRP the maximum is 232 = 4,294,967,296. Clearly, this means that EIGRP can't use the same counting-to-infinity algorithm to get out of loops the way RIP does.
Instead, EIGRP relies on its Split Horizon implementation and on its neighbor relationships to avoid loops. Recall from the RIP discussion that Split Horizon means that the router doesn't advertise itself as a route to any device that it considers closer to the destination. In particular, if a router is using a particular next hop router to get to some destination network, then it never tells the next hop router that it knows how to get to that destination.
RIP used a modified version of Split Horizon in which it does advertise the path to the destination network, but it does so with a metric of infinity so that it is never used. This is called Split Horizon with Poisoned Reverse. EIGRP uses a similar rule for exactly the same reasons.
EIGRP only works with incremental updates rather than distributing the entire routing table. So when a router detects a topology change, it alerts its neighbors to flush this route from their tables. They can then determine a new optimal path. There is no need to count to infinity incrementally before removing the route. The DUAL algorithm eliminates routing loops.
Unlike OSPF, EIGRP does not support the use of areas. The entire AS acts as a single unit. However, EIGRP can use its autosummarization feature to achieve many of the same benefits as OSPF does using areas. In fact, the existence of areas in OSPF forces all route summarization to be done at the Area Border Routers. In EIGRP, however, route summarization can be done at multiple levels.
EIGRP is said to be a Classless routing protocol because it can summarize at any bit in the network address, without being concerned about the class of the address range. Thus, a carefully designed hierarchical network can have a very efficient routing table. Figure 6-6 shows an example of how this might work. This is a hierarchical network design with a large number of Distribution Areas. When allocating the IP addresses downstream from the Distribution Routers, one has to be careful to ensure that the routes can be summarized.
The most important restriction on this sort of summarization is that you cannot break up any summarized address range across multiple Distribution Areas. In Figure 6-6 a range of subnets from 10.25.0.0 to 10.25.3.0 to is given the first group of LAN segments in Distribution Area 1. These could be subnetted in whatever way is appropriate. But Routers D1C and D1D can summarize the connections to this group as 10.25.0.0/22. Then you need to be careful only that you don't assign subnets from these ranges anywhere else in the network.
Following the summarization process up the diagram toward the Core, Routers D1A and D1B can have a single summary route for both 10.25.0.0/22 and 10.25.4.0/22, namely 10.25.0.0/21. These routes then point to Routers D1C and D1D.
Suppose the designer needs to reserve a large number of subnets for growth in this Distribution Area. He might allow the summary route for the entire area to be 10.25.0.0/17. Then Distribution Area 2 could be summarized as 10.25.128.0/17. In this way, each router can have an extremely compact routing table that is easy to update throughout the network. The routers in the Core don't have to care about whether a particular subnet, such as 10.25.3.5/32, is behind router D1C or D1F. All they have to know is that D1A and D1B take care of a large range of addresses that happens to include this subnet.
The same sort of summarization also happens in the other direction. If Distribution Area 2 is summarized as 10.25.128.0/9, then every router in Distribution Area 1 will see a route for this summary network pointing into the Core. There is no need for these routers to see any more detail.
By default, EIGRP automatically summarizes whenever two different IP networks meet if the networks represent two different Classes. For example, where a section of network containing 172.16.0.0/16 meets another one using 172.17.0.0/16, they will both be summarized.
However, if the subnet addresses are allocated in a good hierarchical scheme, you can configure the routers to summarize other smaller ranges. It is a good idea to do so because every router should have a simple, concise, routing table.
If the network is not planned this way, then summarization doesn't make sense. For example, some of the subnets of 10.25.3.0 are located in Distribution Area 1 and others are in Distribution Area 2, then it is not possible to summarize either one.
EIGRP can also handle multiple routes to a particular destination. The network in Figure 6-6 has two connections from each router to the next level above it. Each of the higher-level routers will see two routes to everything downstream from it. EIGRP allows these routers to keep and use both of these routes.
In the example, there are two paths from Router D1A to 10.25.3.0: one through D1C and the other through D1D. If both of these links have the same metric, then EIGRP uses equal-cost multipath routing. In most cases, the router simply alternates the traffic flows between the different paths. The packets belonging to a particular TCP session are called a flow. So equal cost multipath routing keeps all of these packets on the same path. However, as each new session is established, the router attempts to balance the paths since they have the same cost.
If the packets from several different flows are coming sufficiently quickly, the router sends the second packet out the second path before the first packet has finished departing along the first path. This allows a simple form of load sharing between the paths. However, this form of load sharing is not terribly bandwidth efficient, so you will get considerably less than twice the bandwidth of one path in practice.
EIGRP uses an interesting technique for keeping its routing tables up-to-date. Even though it only uses the best route, the EIGRP topology table keeps a list of every path to every subnet. This way, if the best path goes away it can select a feasible successor. But if there are no feasible successors when a route disappears, the router puts this route into an "ACTIVE" state and queries its neighbors to find a new path to the destination. If one or more of the neighbors knows a path to this destination network (or a summary route that contains this one), they respond. But if they do not have a route, they in turn query their neighbors.
Sometimes the destination is simply nowhere to be found. This can happen because a failure somewhere in the network has isolated some subnets. Sometimes the process of trying to find a new path can fail to converge. In the ever-expanding chain of queries from one router to the next, each device is waiting for a response. If the network is too large or if it contains too many high-latency sections, it may become difficult for this process to converge.
If the queries for an "ACTIVE" route are not satisfied within the timeout period of a few minutes, the router gives the dreaded "Stuck In Active" message. It then clears the neighbor relationship with the router that failed to respond. This can happen either because the route has disappeared or because a communication problem has broken the chain of queries somewhere in the network. Either way, "Stuck In Active" represents a serious problem, particularly if it happens repeatedly.
When the routers in an EIGRP network issue large numbers of "Stuck In Active" messages, it is important to determine where thing are getting "Stuck." This is by far more serious than the "ACTIVE" problem, which just means that a route is missing. When these messages appear, the network engineer should find out which neighbor relationships are being reset. This could be happening anywhere in the network, not necessarily on or adjacent to the router that reports the "Stuck In Active."
The easiest way to find these problems is to ensure that EIGRP is configured to log neighbor status changes. Then, when the "Stuck In Active" messages appear, attempt to track where the neighbor relationships are flapping. In some cases the neighbors that are changing are randomly dispersed throughout the network. This may indicate that the EIGRP AS has simply become too large to be stable. This can happen particularly when the automatic route summarization features of EIGRP are not used effectively.
EIGRP networks are grouped into Autonomous Systems (ASes). Each router that has EIGRP configured must specify the AS number. All neighbors must be in the same AS to exchange routes.
It is possible to break up an EIGRP network into multiple ASes, but these ASes cannot be directly connected to one another. The problem is that the router sitting on the border between the two ASes is a full member of both. It maintains a distinct topology database for each AS. But consider what happens when a route in one of the ASes disappears. As I discussed in the previous section, that route becomes "ACTIVE" as EIGRP attempts to find an alternate path. When the router that is a member of both ASes marks this route as "ACTIVE," it queries all of its neighbors for a possible alternate. That includes the neighbors that belong to the other AS. So any ACTIVE route queries from one AS are forwarded over to the other AS. This means that if there are stability problems in one AS, they will be inherited by the other.
The main reason to break up a network into multiple ASes is to help convergence and stability of each of the smaller units. In doing so you must be careful to separate these ASes more effectively by using another protocol between them. Since EIGRP is an IGP, it is natural to use an EGP, such as BGP, to perform this function. However, it can also be effective simply to use another IGP such as RIP or OSPF.
Like RIP, EIGRP lets you tag routes that originate from outside of the AS. But, while RIP made it difficult to use this information to make routing decisions, it is relatively straightforward in EIGRP. This information is commonly used to keep traffic inside the AS if any internal path exists. For example, consider a network with two ASes. It might turn out that the shortest path between two segments in the same AS actually passes through the second AS. But usually this is not desirable. After all, what is the point of breaking up the network into ASes if there is no real division between them? In EIGRP, these route tags ensure that if there are two routes for a particular network, one internal and one external, then the internal one is preferred automatically.
Sometimes you might want to use that external route for administrative or cost reasons. More commonly, there might be two or more different external routes for a particular network. For example, there might be more than one Autonomous System Boundary Router (ASBR) connecting to one or more external ASes. In this case the external route with the best metric may not actually be the administratively preferred path.
For these types of situations, Cisco lets you use policy-based routing to act on these route tags. In the simplest implementation, the routers at the edges of the ASes might just add a large delay to one external route.
Although they are intended to act as IGP, IGRP, and EIGRP are sometimes used themselves as EGPs to interconnect OSPF ASes. EIGRP has excellent route-summarization properties, making it also useful for summarizing routes between ASes.
A real EGP such as BGP has better native filtering properties than EIGRP does. Furthermore, because EIGRP is a proprietary standard, it is probably not appropriate for interconnecting the networks of different organizations.
However, two or three OSPF ASes can be easily interconnected within the same organization. This is particularly true if the network designer intends to share all routes between these ASes. EIGRP is extremely simple to configure, and it works well when redistributing routing information with OSPF. So for purely internal uses like this, it may be easier to use EIGRP than BGP to function as the EGP.
Cisco has made it very easy to distribute routes between EIGRP and other routing protocols. All you need to do is configure a border router that talks to both protocols. Then, in configuring the two protocols, one just instructs each to redistribute routes from the other. But usually AS boundaries serve multiple purposes. It is usually necessary to restrict what information flows between the two protocols.
At a minimum, you must be careful about how the metrics of the external routes look to each protocol. They will be tagged as external routes, so you can always use policy-based routing if you need to. But, as I discussed in Chapter 3, policy-based routing should be used as sparingly as possible. In fact, it is best if used only at the boundary between the two protocols—that is, only on the ASBR routers.
Routers can also set default metrics for all injected external routes in both ASes. This is useful when the two protocols handle metrics in fundamentally different ways, as with RIP and EIGRP. In this case the network designer might want RIP to show all of the external EIGRP routes with a minimum metric of 5. On the EIGRP side, she might want to specify a large minimum administrative delay for all injected RIP routes. Setting default metrics in this way is often the simplest way to control the routes injected from foreign routing protocols.
The situation becomes more complicated when some routes should not be redistributed. For example, there might be a third AS, perhaps running still another routing protocol. Suppose the network has an EIGRP AS connecting to each of two different OSPF ASes. Then the designer decide must if she wants the EIGRP AS to carry traffic between these other two systems. If not, then the boundary router between OSPF AS number 1 and the EIGRP AS can simply refuse to pass along the routing information for AS number 2.
Cisco makes this easy with the use of distribute lists in the EIGRP configuration.