EIGRP Neighbors

One of the most limiting factors regarding EIGRP is the lack of detailed information about the protocol. A significant component of this is the neighbor relationship. Neighbor relationships are established between two routers running in the same EIGRP autonomous system (AS).

While the “Network Design in the Real World: EIGRP” sidebar provides additional tips regarding EIGRP, most designers would be well advised to consult with others who have deployed the protocol. Although EIGRP is extremely powerful, the reality is that little information is available regarding actual deployments. This can be a significant factor in deployments with high numbers of neighbors, poor addressing and design, and low memory and CPU availability on the routers. Many problems with EIGRP involve the number of neighbors, especially with the Route Switch Module (RSM) in the Catalyst product line. Unlike a router, the RSM typically terminates multiple networks and has many neighbors—more than are found in a typical installation with routers. In addition, the RSM is relatively limited in terms of backplane connectivity (400Mbps) and processor (an RSP 2). Therefore, a high number of neighbors will affect an RSM before a comparable installation with RSP 4s and a 7513 router—a factor that has impacted many EIGRP conversions.

The Diffusing Update Algorithm

The Diffusing Update Algorithm, or DUAL, is the route-determination process in EIGRP. It permits the routing process to determine whether a path advertised is looped or loop-free. In addition, routers using EIGRP can determine alternative paths before receiving updates that link failure has occurred from other routers. The concept of always having a “second-best” route in memory greatly aids in reducing convergence time, which can increase the reliability of the network design.

The primary design criterion for EIGRP is the maintenance of a loop-free topology at all points in the route-calculation process. At the same time, EIGRP attempts to reduce the total amount of convergence time by maintaining alternate routes in memory, a factor that typically works against loop-free techniques. EIGRP maintains information about successors (the best possible route to a destination) and feasible successors (the second-best route to a destination) in order to reduce the amount of time involved in convergence.

Like OSPF, EIGRP uses a hello mechanism to monitor router availability. These messages are sent every five seconds and significantly differentiate EIGRP from other distance-vector protocols. Most distance-vector protocols rely on timers to detect route failure. The benefit of hello messages is the avoidance of black holes—routes that lead to nothing. It is also important to note that updates in EIGRP are sent only when necessary and only to those destinations that require them. This greatly reduces the overhead of the protocol from a bandwidth perspective. In addition, these updates are sent reliably, which means that all updates are sequenced and acknowledged. This works to guarantee convergence assuming that all other factors, including router memory and processor, are working properly. The protocol used for EIGRP is the Reliable Transport Protocol (RTP), but, contrary to its name, it may transport unreliable messages as well.

One of the misunderstood concepts in EIGRP is that of the feasible successor. The feasible successor is not selected from any adjacent router that can reach the destination—rather, the feasible successor must have a lower metric than the router calculating the feasible successor. Stated another way, the reported distance, a value determined by the adjacent router providing its cost to the destination, must be less than the feasible distance, or the second-lowest cost for the calculating router to the destination. The reported distance does not include the cost of the link between the adjacent router and the calculating router. Figure 4.5 illustrates this concept.

FIGURE 4.5  EIGRP feasible successors

In this example, we will presume that the metric is simply based on hop count. As such, Router B is one hop from Router C, and Router D is three hops from Router C. The destination in this example is Router C, and the router we are concerned with is A, which is two hops away.

Router A, assuming all links are active, will place into the routing table a route through B to C—this is clearly the shortest path through the network. However, it will not place a feasible successor route in its table using the route A-D-E-B-C. In the event of link failure between A and B, the router must recalculate the path to C. The rationale is that in order for a route to be feasible, it must have a lower cost to the destination than the current routing metric on the router itself. For example, D would consider D-A-B-C to be feasible in the event of link failure—A’s cost to C is one hop less than D’s.

The behavior of feasible successors is related to the protocol’s primary objective—no loops may exist in the topology at any time. By always selecting a router with a lower metric, the protocol avoids such scenarios, even though this may hinder convergence. Most EIGRP convergence scenarios complete within one second; however, in the worst case a properly working EIGRP process will take 16 seconds. This convergence estimate is based on the detection of a link failure and the time necessary to respond with a new route calculation. In addition, EIGRP provides for multiple feasible successors, which are defined as a set, and up to four variant paths may be load-balanced if configured. Again, the rules defined in the IGRP section apply regarding the variance value and switching methodology, and the benefits are the same. The specific steps used in convergence are shown in Figure 4.6.

FIGURE 4.6  EIGRP convergence process

Eventually, designers and administrators working with EIGRP will receive the following console message:

This message may result from one of two problems—the first is simply a lack of available memory on the router to calculate the route. A route that is unparsed (undergoing recomputation) is considered active, whereas a stable route that has been placed in the tables is passive. The second possible cause is a lack of bandwidth on the link between the two routers—preventing communications between them for route update transmission. One method for addressing this problem is to augment the available bandwidth EIGRP is allocated. By default, EIGRP cannot consume more than 50 percent of the link. Another technique that can help is route summarization.

Designers should keep in mind that EIGRP maintains not only its routing table but also the routing table of each adjacent router. This fact is significant in understanding the importance of summarization, small neighbor relationships, and the routing update mechanism. DUAL uses this additional information to determine the feasible successor, and this data determines whether a computation is required.

	Administrators may wish to adjust the amount of bandwidth available to EIGRP with the ip bandwidth-percent eigrp command. This permits modification of the default 50 percent utilization allowed, which may be necessary for slower links in order to speed convergence.

Route summarization in EIGRP is automatic across major network boundaries, but many administrators disable this feature in order to take advantage of manual summarization on all boundaries and gain more control. For dis-contiguous subnets, this feature must be disabled. This powerful feature not only reduces the size of the routing table but also provides a strong motivator for readdressing projects. The best EIGRP designs yield very small core routing tables—divided at a very high level based on summarization.

	A number of companies have migrated to the reserved addresses specified in RFC 1918 in order to reduce the public Internet addressing shortage under IP v4. Designers should give careful consideration to both IP v6 and the use of public IP addresses—a number of service providers are finding it difficult to provide Layer 3 solutions with private addresses.

Designers should also note that EIGRP can maintain six routes to a destination—a characteristic that can reduce convergence time, as the router simply moves packets to the remaining paths.

Another feature of EIGRP that is often overlooked is mobile hosting. A mobile host is a host that is no longer on its natural subnet. The router will place an exception route to the host in the table—the more specific route superseding the subnet route. Clearly, this can reduce efficiency and greatly increase the size of the routing table. However, as wireless devices become more common in the enterprise, the demand for this feature will increase. This feature was added in IOS version 10.2.