EIGRP Tutorial

by Don Dettmore

Introduction to EIGRP

Prerequisites: This document assumes that the reader has knowledge in a number of areas required to understand EIGRP. These include solid knowledge of IP, IPX, and AppleTalk routing fundamentals; an understanding of various LAN and WAN media; as well as a basic knowledge of Cisco router configuration commands. In addition, this document does not cover protocol-independent routing features such as route filtering, distribute lists, route maps, or default routing.

When enterprise IP networks started gaining in popularity in the 1980's, the primary interior routing protocol in use was RIP (Routing Information Protocol). This was by no means planned -- RIP happened to come free with several UNIX distributions and it was simple to set up and maintain. Unfortunately, as networks got larger, RIP's performance started to decline. In very large networks, RIP's excessive bandwidth utilization and relatively low hopcount limit made it unusable.

Cisco's solution to this was the Interior Gateway Routing Protocol (IGRP). It alleviated some of RIP's problems, and gained a small following. Unfortunately, it too had scalability problems (though not as bad as RIP's), and eventually there was a need for an enterprise-level interior routing protocol.

Network architects responded with the link-state protocols, the most successful of which was Open Shortest Path First (OSPF). OSPF solved almost all of the scalability issues -- it had an ingenious design. But, it was difficult to both implement and maintain. It required extensive planning and expensive engineers, both of which were hard to come by. Worse still, early implementations of OSPF were buggy, and network managers were loath to introduce more instability into their networks.

Cisco again came up with an answer: the Enhanced Interior Gateway Routing Protocol (EIGRP). Though called Enhanced IGRP, this new version bears almost no resemblance to its predecessor, beyond the configuration commands. EIGRP is a completely new protocol. It successfully addresses most network scalability needs, while remaining (relatively) simple to set up and maintain.

EIGRP certainly is not the only choice for interior routing in large-scale networks. OSPF and IS-IS have both similarities and differences (notably vendor independence), but there is also more knowledge of their behavior in large networks.

Advanced Distance Vector Protocol

RIP and IGRP are distance-vector routing protocols, meaning they make decisions based on the next-hop metrics. Routers only learn metrics from their neighbors and then compute the lowest cost paths based on those metrics. EIGRP also follows the distance vector approach, but has numerous additional features, some of which were introduced in OSPF and IS-IS and some that are unique to EIGRP.

OSPF and ISIS are link-state protocols, which build a complete topology map of the network, including all links. They then make their decisions based on this map.

Look at DV routing protocols as if they were "generations":

1st Generation: Typified by IP RIP and AppleTalk RTMP. Hop count is the only metric, which limits the size of the network and can only optimize routes when all links have identical bandwidth. Uses count-to-infinity and split horizon for loop detection. Under the constraints of split horizon, sends the entire routing table periodically, whether there are changes or not.

2nd Generation: Typified by IGRP, and to a limited extent by IPX RIP. Has more advanced metrics that allow different line speeds to be used in a reasonably optimal manner. Has additional loop detection mechanisms. Under the constraints of split horizon, sends the entire routing table periodically, whether there are changes or not.

3rd Generation: Typified by EIGRP. Continues to have bandwidth-aware metrics. Uses hello subprotocol to minimize routing traffic while speeding failure detection. Emphasis on loop prevention rather than loop detection. Sends updates only.

EIGRP is called (by Cisco) an advanced distance-vector protocol. It is a distance-vector protocol, meaning it makes decisions based on metric information it receives from its neighbors. However it employs some of the advanced mechanisms of the link-state protocols. It establishes neighbor relationships with adjacent routers, it sends only changes in its updates, and it keeps a topology database. For that reason, Cisco marketing often calls EIGRP a hybrid protocol (though by strict definition it is distance-vector).

EIGRP vs. Traditional Distance Vector (RIP or IGRP)

EIGRP has the following advantages over either RIP or IGRP:

• It supports classless interdomain routing (CIDR) and variable-length subnet masks (VLSM).

• It sends routing updates only when network topology changes -- instead of its entire routing table at regular intervals.

• Its convergence is very fast -- often instantaneous due to the topology database.

• Its algorithm offers complete protection from routing loops (well, almost).

EIGRP vs. OSPF

EIGRP offers the following benefits over OSPF:

• It is much simpler to install and maintain (keep in mind though, EIGRP has its own issues with large networks, and requires a degree of expertise. However, it is not nearly as difficult as OSPF).

• It is less CPU intensive.

• It supports IPX and AppleTalk. OSPF supports only IP.

• EIGRP supports unequal-cost load balancing.

• EIGRP (with properly designed summarization) does not propagate topology changes to every router in its area. This can save valuable bandwidth, especially in unstable or frequently fluctuating environments. Even with summarization, OSPF propagates network changes to all routers in an area.

EIGRP is not perfect, though; it does have the following weaknesses:

• It is Cisco proprietary -- it does not interoperate with other vendors' devices. This, of course, is the big one. If you are working in a mixed environment, EIGRP doesn't make as much sense.

• In a poorly designed network, EIGRP's stuck-in-active (SIA) mechanism can wreak havoc. In particular, one malfunctioning router can trigger a chain reaction that brings an entire network to its knees. OSPF handles the "one bad router" problem much better. However, if EIGRP is properly designed, this problem can be overcome. This scenario will be covered in detail later in the tutorial.

EIGRP Fundamentals

EIGRP Basic Configuration

One of EIGRP's strengths is its ease of configuration -- to configure EIGRP on a router:

(config)# router eigrp ASNUMBER
(config-router)# network IPNETWORK

ASNUMBER = Autonomous system of the EIGRP network

For example, Figure 1 displays a router and its EIGRP configuration:

Figure 1. Basic EIGRP Configuration

Any interface that lies within the network indicated in the network statement runs the EIGRP process. Verify this with the SHOW IP EIGRP INTERFACES exec command. For example, from Figure 1:

RouterA#sh ip ei int
IP-EIGRP interfaces for process 90
            Xmit Queue   Mean  Pacing Time  Multicast   Pending
Int  Peers  Un/Reliable  SRTT  Un/Reliable  Flow Timer  Routes
Se0/1   1      0/0          230   2/95          1235         0
Se0/0   1      0/0         1494   1/63          7531         0

You can see that both interfaces S0/0 and S0/1 are active and have active peers. You can see which peers with the SHOW IP PROTOCOL exec command:

ROUTERA>SH IP PROT
ROUTING PROTOCOL IS "EIGRP 90"
  OUTGOING UPDATE FILTER LIST FOR ALL INTERFACES IS
  INCOMING UPDATE FILTER LIST FOR ALL INTERFACES IS
  DEFAULT NETWORKS FLAGGED IN OUTGOING UPDATES
  DEFAULT NETWORKS ACCEPTED FROM INCOMING UPDATES
  EIGRP METRIC WEIGHT K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP MAXIMUM HOPCOUNT 100
  EIGRP MAXIMUM METRIC VARIANCE 1
  REDISTRIBUTING: EIGRP 90
  AUTOMATIC NETWORK SUMMARIZATION IS IN EFFECT
  ROUTING FOR NETWORKS:
    10.0.0.0
  ROUTING INFORMATION SOURCES:
    GATEWAY         DISTANCE      LAST UPDATE
    (THIS ROUTER)      5       00:52:55
    10.1.18.1        90      00:52:33
    10.1.17.1        90      00:52:33
  DISTANCE: INTERNAL 90 EXTERNAL 170

Note: EIGRP automatically summarizes network statements to their classful state. For example, NETWORK 10.1.2.0 is automatically summarized to NETWORK 10.0.0.0. IOS release 12.0(4)T added the option of placing wildcard bits to specifically identify subnets to be included (and in turn subnets to be excluded).

The EIGRP Route Selection Process

EIGRP uses a best-metric method of determining which path to take to a destination. Each link in a network has a cost, or metric associated with it. Each router sends the metrics for each of its routes to its neighbors. The neighbors then compute a total distance for a destination, and use that distance to determine the best path. For example, examine Figure 2. Keep in mind that this is extremely simplified -- we'll get into more detail in the next section.

Figure 2. EIGRP Route Selection

PC1 is sending a packet to PC2. Router A receives the packet, which has a destination network of LAN2. There are two possible paths to LAN2:

1. Through Router B. Router B has reported a distance of 110 to get to LAN2. That, plus the 50 to get to Router B equals a total distance of 160.

2. Through Router C. Router C has reported a distance of 110 to get to LAN2. That, plus the 100 to get to Router C equals a total distance of 210.

Since the path through Router B has a lesser distance, it is chosen as the best path to LAN2.

EIGRP Metrics

Note: On the surface, the EIGRP metrics appear to be overwhelmingly complex. In the real world, however, they are very manageable. We'll see that in a minute.

EIGRP uses a combination of four values to compute the distance to a destination. The four values are:

Delay - the total delay (in ms) to the destination

Bandwidth - 10⁷ divided by the minimum bandwidth of any link in the path to the destination

Load - on a scale of 1-255, how loaded the link is (255 is completely saturated)

Reliability - on a scale of 1-255, how reliable the path is (255 is completely reliable)

The formula for computing the metric is:

Where K1, K2, K3, K4, and K5 are constant coefficients and

BW = (10⁷ / minBandwidth) * 256

minBandwidth is not the bandwidth on the local outgoing interface. It is the lowest of any bandwidth along the path to the destination.

This differs from the bandwidth usage in OSPF, in which route cost, by default, derives from the sum of interface costs along the path. OSPF interface cost defaults to 108/interfaceBandwidth, where interfaceBandwidth is 1544 or the value of the interface bandwidth commands (with a value in kilobits).

Delay is measured in tens of microseconds. This is different from the output of the show interfaces command, which displays delay in milliseconds.

This whole formula may seem unmanageable, but in practice it really isn't. K2, K4, and K5 only exist for backward compatibility with IGRP, and are set to zero by default (actually, if K4 and K5 are zero, their whole term is completely left out of the equation). K1 and K3 are set to 1 by default. This leaves us with the following formula:

[ (10⁷ / minBandwidth ) + sum of interface delays ] *256

EIGRP uses this formula of metric computation to accomplish two things:

1. On routes of few hops, the route with the greatest minimum bandwidth is usually preferred.

2. On routes with many hops, the route with the least total delay is usually preferred.

Figure 3 displays the same network as Figure 2, but this time with the actual link values.

Figure 3. EIGRP Metric Values

Once again, PC1 is attempting to talk to PC2. Router A must determine the best path. The path through Router B has the greatest available bandwidth (with the delay being the same), so it is chosen as the route to LAN 2.

Metric delay and bandwidth values are easy to determine. They are based on the interface type and link speed. Table 1 illustrates standard Cisco values.

Table 1. Standard Cisco Bandwidth and Delay Values

Delay and bandwidth parameters are both configurable. You can change them to manipulate your routing table as needed (though be sure you have a good reason and you know what you are doing). K values are also configurable, but changing them is not recommended and can lead to unpredictable results. Also remember that all routers in an autonomous system must agree on K values.

Note: When EIGRP advertises the metric values for a route, it advertises two other values not mentioned here: MTU and hopcount. These are used for purposes such as loop avoidance, but not for determining a composite metric.

EIGRP Terminology

EIGRP defines four terms that you must understand: successor, feasible successor, feasible distance, and reported distance.

Successor: The next-hop router to a destination, as reported by SHOW IP ROUTE.

Feasible Successor: A router closer to the destination than the current router. As we will see, EIGRP not only tracks the successor, but also other routers that may provide valid paths to a destination in the event the successor fails.

Feasible Distance: The current best distance (metric) to a destination. In other words, the metric through the successor.

Reported Distance: The distance from the successor to the destination network.

These values are kept in the EIGRP topology database. The topology database contains all known routes to a destination, not just the route in the routing table. It can be examined with the SHOW IP EIGRP TOPOLOGY exec command. For example, Figure 4 illustrates the SHOW IP EIGRP TOPOLOGY output from Router A:

Figure 4. Show IP EIGRP Topology

To get to LAN2 (10.1.5.0) from RouterA:

Successor: 10.1.18.1 (RouterB). This route has the least distance, so it is the successor. This is the route that would be found in the routing table.

Feasible Successor: 10.1.17.1 (RouterC). This is a possible route, but not the best.

Feasible Distance: 7693056. This is the distance of the route through the successor.

Reported Distance: 5514496. This is the distance from the successor (RouterB) to the destination. In other words, the successor's Feasible Distance to the destination.

SHOW IP EIGRP TOPOLOGY does not show ALL routes to a destination, though. It only shows those that go through feasible successors. What's the difference? The path through a feasible successor is guaranteed to be loop-free. If a router may possibly cause a loop, it does not become a feasible successor, and its route is not placed in the topology database (well, it is, but it is not used). How does EIGRP determine if a path is loop-free? It uses EIGRP's DUAL Algorithm.

The DUAL Algorithm

The DUAL Algorithm, among other things, is used to determine if an alternate path to a destination is loop-free. It states: "A path is loop-free if the reported distance is less than the current feasible distance." (Stop here and think about that for a second). If the reported distance is greater than the current feasible distance, the path may (but not necessarily) have a loop, and, therefore, it is not a feasible successor. But if the reported distance is less than the feasible distance, there cannot be a loop.

For example, examine Figure 5. Router A's best path to LAN2 goes through Router B. Therefore Router B is the successor. Is Router C a feasible successor? (Remember that a path must be guaranteed to be loop-free for a router to become a feasible successor.)

Figure 5: EIGRP Feasible Successors

Yes, Router C is a feasible successor. Its reported distance, 110, is less than the current feasible distance of 160.

EIGRP Hello Packets

EIGRP Routers do not exchange routing information until they form a neighbor relationship. To do this, EIGRP uses its version of the HELLO protocol. Periodically (every 5 seconds for high-speed interfaces) an EIGRP router multicasts a hello packet out of its configured interfaces. HELLOs flow only from primary IP addresses; EIGRP does not form neighbors with secondary addresses.

EIGRP routers that receive these packets will attempt to form a neighbor relationship with the sender (provided they are compatible -- common autonomous system numbers, K values, etc.). Once the neighbor relationship, or adjacency, is established, the two will exchange full routing information. Thereafter, they will only exchange routing information when a change is detected. However, they continue to send and receive hello packets.

The hello protocol is not used just to find neighbors; it is also used to detect when neighbors drop. EIGRP keeps track of the hello packets it receives from its neighbors and if it doesn't hear from a neighbor for a certain amount of time, it will drop the neighbor relationship. That causes all information learned from that neighbor, such as routing and topology information, to be dropped as well. If the router subsequently hears from the neighbor again, they will reestablish the adjacency and re-exchange routing information.

EIGRP uses two timers to accomplish its goals:

Hello Timer: The Hello timer specifies how often hello packets are sent. The default is 5 seconds for most interfaces. The exceptions are low-speed NBMA interfaces (such as frame relay) which default to 60 seconds. The default hello time can be modified with the IP HELLO-INTERVAL EIGRP interface configuration command.

Hold Timer: The Hold timer specifies how long a router will wait without hearing from a neighbor before clearing the adjacency. It defaults to 3 times the Hello timer (15 seconds for most interfaces and 180 seconds for NMBA interfaces). Having the hold time equal to three times the hello timer allows for a hello packet or two to be lost (for whatever reason) without clearing the adjacency. The default hold time can be modified with the ip hold-time eigrp interface configuration command.

EIGRP Packet Format

Instead of riding an established protocol, like TCP or UDP, EIGRP designers developed their own reliable protocol to carry EIGRP messages. This packet format carries all messages, from hello packets to routing updates. The format is shown in Figure 7:

Figure 7. EIGRP Packet Format

EIGRP ensures reliable communication using a sequencing and acknowledgement mechanism similar to TCP. Unlike TCP though, EIGRP uses a fixed window size of 1. Type/Length/Value fields carry the packet data (usually routing updates or queries).

The Neighbor and Topology Databases

EIGRP keeps track of two databases of information: the neighbor database and the topology database.

Neighbor Database: Neighbors are found with the hello protocol. When a router exchanges hello packets and establishes a neighbor relationship, it stores information about the neighbor in the neighbor database. Examine the neighbor database with the SHOW IP EIGRP NEIGHBORS exec command. Figure 8 shows an example of this.

Figure 8. Show IP EIGRP Neighbors

Topology Database: EIGRP Routers store not only the best route to a destination, but up to five alternate routes as well. These, along with their associated information (feasible distance, reported distance, etc.), are kept in the topology database. Use the show ip eigrp topology exec command to view it. Refer back to Figure 4 for an example. A summary of the topology database can be shown with the show ip eigrp topology summary exec command. Examine the following output:

ROUTERA>SH IP EI TOP SUM
IP-EIGRP TOPOLOGY TABLE FOR AS(90)/ID(10.1.18.2)
HEAD SERIAL 13, NEXT SERIAL 25
6 ROUTES, 0 PENDING REPLIES, 0 DUMMIES
IP-EIGRP ENABLED ON 3 INTERFACES, NEIGHBORS PRESENT ON 2 INTERFACES
QUIESCENT INTERFACES: SE0/1 SE0/0

The summary command can offer some quick insight into your routing process, including the following:

• Total number of routes

• Number of routes pending replies (more on this later)

• Total number of interfaces and neighbors

• Head serial and next serial -- every time a change is made to the topology database, the next serial is incremented by one (head serial is where it started). This is a direct reflection on the stability of your network.

To see detailed information about a route, specify the route in the SHOW IP EIGRP TOPOLOGY ROUTE statement. For example:

ROUTERA>SH IP EI TOP 10.1.5.0 255.255.255.0
IP-EIGRP TOPOLOGY ENTRY FOR 10.1.5.0/24
  STATE IS PASSIVE, QUERY ORIGIN FLAG IS 1, 1 SUCCESSOR(S), FD IS 7693056
  ROUTING DESCRIPTOR BLOCKS:
  10.1.18.1 (SERIAL0/0), FROM 10.1.18.1, SEND FLAG IS 0X0
      COMPOSITE METRIC IS (7693056/5514496), ROUTE IS INTERNAL
      VECTOR METRIC:
        MINIMUM BANDWIDTH IS 384 KBIT
        TOTAL DELAY IS 40100 MICROSECONDS
        RELIABILITY IS 240/255
        LOAD IS 1/255
        MINIMUM MTU IS 1500
        HOP COUNT IS 2
  10.1.17.1 (SERIAL0/1), FROM 10.1.17.1, SEND FLAG IS 0X0
      COMPOSITE METRIC IS (11026432/5514496), ROUTE IS INTERNAL
      VECTOR METRIC:
        MINIMUM BANDWIDTH IS 256 KBIT
        TOTAL DELAY IS 40100 MICROSECONDS
        RELIABILITY IS 240/255
        LOAD IS 1/255
        MINIMUM MTU IS 1500
        HOP COUNT IS 2

Note that with each route, not only is the total (composite) metric shown, but the individual components used to compute the metric are shown as well (collectively, these are known as the vector metric). This brings up an interesting point: when a router sends an EIGRP route to a neighbor, it does not include its composite metric, but instead it includes all of the components (vector metric). The receiving router then uses the vector metric to compute not only its own metric, but the reported distance as well.

EIGRP Features

EIGRP contains a number of features that enhance its scalability and efficiency. In this section we will examine two of them: route summarization and load balancing.

Route Summarization

Despite all of its strengths (or perhaps because of them), EIGRP is a fairly CPU- and memory-intensive protocol. It gets particularly bad during link failure conditions. It is possible to overload the largest of CPUs with EIGRP processing alone. We'll discuss this in more depth later. Route summarization is one of the tools provided to relieve some of this burden.

Observe the network in Figure 9. Two major networks (10.0.0.0 /8 and 172.16.0.0 /16) meet at Router D (the entire network is one autonomous system, though).

Figure 9. Route Summarization

Without summarization, every 10.0.0.0 subnet appears in the routing table of Routers X, Y and Z. For example, the following is the routing table from Router Z:

ROUTERZ#SH IP ROUTE
CODES: C - CONNECTED, S - STATIC, I - IGRP, R - RIP, M - MOBILE, B - BGP
       D - EIGRP, EX - EIGRP EXTERNAL, O - OSPF, IA - OSPF INTER AREA
       N1 - OSPF NSSA EXTERNAL TYPE 1, N2 - OSPF NSSA EXTERNAL TYPE 2
       E1 - OSPF EXTERNAL TYPE 1, E2 - OSPF EXTERNAL TYPE 2, E - EGP
       I - IS-IS, L1 - IS-IS LEVEL-1, L2 - IS-IS LEVEL-2, * - CANDIDATE DEFAULT
       U - PER-USER STATIC ROUTE, O - ODR
GATEWAY OF LAST RESORT IS NOT SET
     172.16.0.0/24 IS SUBNETTED, 4 SUBNETS
D       172.16.0.0 [90/2195456] VIA 172.16.2.2, 00:08:24, SERIAL0
D       172.16.1.0 [90/2681856] VIA 172.16.2.2, 00:08:24, SERIAL0
                   [90/2681856] VIA 172.16.3.1, 00:08:24, SERIAL1
C       172.16.2.0 IS DIRECTLY CONNECTED, SERIAL0
C       172.16.3.0 IS DIRECTLY CONNECTED, SERIAL1
     10.0.0.0/24 IS SUBNETTED, 6 SUBNETS
D       10.1.8.0 [90/8253696] VIA 172.16.2.2, 00:08:24, SERIAL0
D       10.1.5.0 [90/2198016] VIA 172.16.2.2, 00:08:24, SERIAL0
D       10.1.19.0 [90/6049536] VIA 172.16.2.2, 00:08:24, SERIAL0
D       10.1.18.0 [90/8228096] VIA 172.16.2.2, 00:08:24, SERIAL0
D       10.1.17.0 [90/11561472] VIA 172.16.2.2, 00:08:24, SERIAL0
D       10.1.16.0 [90/6049536] VIA 172.16.2.2, 00:08:24, SERIAL0

Such a large table is not necessary, though. Routers X, Y, and Z really only need to know to send all packets destined for any 10.0.0.0 network to Router D. This can be accomplished with route summarization. Instead of advertising the individual 10.0.0.0 /24 networks to the 172.16.0.0 network, Router D summarizes them all into one route: 10.0.0.0 /8. This one route is then propagated throughout the 172.16.0.0 network.

After summarization, the routing table on Router Z looks like this:

ROUTERZ#SH IP ROUTE
CODES: C - CONNECTED, S - STATIC, I - IGRP, R - RIP, M - MOBILE, B - BGP
       D - EIGRP, EX - EIGRP EXTERNAL, O - OSPF, IA - OSPF INTER AREA
       N1 - OSPF NSSA EXTERNAL TYPE 1, N2 - OSPF NSSA EXTERNAL TYPE 2
       E1 - OSPF EXTERNAL TYPE 1, E2 - OSPF EXTERNAL TYPE 2, E - EGP
       I - IS-IS, L1 - IS-IS LEVEL-1, L2 - IS-IS LEVEL-2, * - CANDIDATE DEFAULT
       U - PER-USER STATIC ROUTE, O - ODR
GATEWAY OF LAST RESORT IS NOT SET
     172.16.0.0/24 IS SUBNETTED, 4 SUBNETS
D       172.16.0.0 [90/2195456] VIA 172.16.2.2, 00:40:47, SERIAL0
D       172.16.1.0 [90/2681856] VIA 172.16.2.2, 00:40:47, SERIAL0
                   [90/2681856] VIA 172.16.3.1, 00:40:47, SERIAL1
C       172.16.2.0 IS DIRECTLY CONNECTED, SERIAL0
C       172.16.3.0 IS DIRECTLY CONNECTED, SERIAL1
D    10.0.0.0/8 [90/2198016] VIA 172.16.2.2, 00:00:09, SERIAL0

There are two ways to accomplish route summarization: automatic and manual. We will discuss both of those in the following section.

Automatic Summarization

Route summarization is enabled by default on Cisco routers -- it will happen automatically. The process works like this:

1. Whenever more than one major (classful) network is defined with the EIGRP NETWORK statements, summarization will occur.

2. For each classful network defined, a summary route pointing to the NULL0 interface is created in the routing table. This route has an administrative distance of 5 and the minimum metric of all subnets being summarized.

3. Only the summarized route (from step 2) is advertised to neighbors on different classful networks.

Figure 10 illustrates this in detail.

Figure 10. Automatic Route Summarization

Both networks, 10.0.0.0 and 172.16.0.0, are defined in the EIGRP configuration. Router D creates the summary routes, and then advertises the 10.0.0.0 route out interface F0/1 and the 172.16.0.0 out interfaces S0/0 and S0/1. The final result is the following:

• Routers A, B, and C have a single route to 10.0.0.0 /8 in their routing tables -- going through Router D.

• Routers X, Y, and Z have a single route to 172.16.0.0 /16 in their routing tables -- going through Router D.

Full connectivity is established with a minimum of routes. We will also find later that this is the principle tool used to avoid SIA (stuck-in-active) network disruptions.

Problems with Auto Summarization

Unfortunately, automatic summarization does not always work out well. For example, examine the network in Figure 10 again. Suppose the network manager decides that a 10.0.0.0 subnet is needed off of Router Y. The network now looks like this (Figure 11):

Figure 11. Automatic Summarization Failure

When the network manager adds the NETWORK 10.0.0.0 statement to the EIGRP configuration on Router Y, Router Y loses connectivity to Routers A, B, and C. Even, worse, Router Z does too! Furthermore, none of Routers A, B, C, or D can see the new subnet. What's going on here? EIGRP supports VLSM and CIDR. So what's the problem?

A glimpse at the routing table on Router Y provides some insight:

ROUTERY>SH IP ROUTE
CODES: C - CONNECTED, S - STATIC, I - IGRP, R - RIP, M - MOBILE, B - BGP
       D - EIGRP, EX - EIGRP EXTERNAL, O - OSPF, IA - OSPF INTER AREA
       N1 - OSPF NSSA EXTERNAL TYPE 1, N2 - OSPF NSSA EXTERNAL TYPE 2
       E1 - OSPF EXTERNAL TYPE 1, E2 - OSPF EXTERNAL TYPE 2, E - EGP
       I - IS-IS, L1 - IS-IS LEVEL-1, L2 - IS-IS LEVEL-2, * - CANDIDATE DEFAULT
       U - PER-USER STATIC ROUTE, O - ODR
GATEWAY OF LAST RESORT IS NOT SET
     172.16.0.0/16 IS VARIABLY SUBNETTED, 5 SUBNETS, 2 MASKS
D       172.16.0.0/24 [90/2195456] VIA 172.16.1.2, 00:32:09, SERIAL0
D       172.16.0.0/16 IS A SUMMARY, 00:32:17, NULL0
C       172.16.1.0/24 IS DIRECTLY CONNECTED, SERIAL0
D       172.16.2.0/24 [90/2681856] VIA 172.16.1.2, 00:32:09, SERIAL0
                      [90/2681856] VIA 172.16.3.2, 00:32:09, SERIAL1
C       172.16.3.0/24 IS DIRECTLY CONNECTED, SERIAL1
     10.0.0.0/8 IS VARIABLY SUBNETTED, 2 SUBNETS, 2 MASKS
D       10.0.0.0/8 IS A SUMMARY, 00:32:01, NULL0
C       10.2.1.0/24 IS DIRECTLY CONNECTED, ETHERNET0

Since Router Y now supports two classful networks, it is summarizing the 10.0.0.0 network and pointing it to NULL0. It is then sending this route to its neighbors. Looking at the topology database on Router Z confirms this:

ROUTERZ>SH IP EI TOP
IP-EIGRP TOPOLOGY TABLE FOR PROCESS 90
CODES: P - PASSIVE, A - ACTIVE, U - UPDATE, Q - QUERY, R - REPLY,
       R - REPLY STATUS
P 10.0.0.0/8, 1 SUCCESSORS, FD IS 2195456
         VIA 172.16.3.1 (2195456/281600), SERIAL1
         VIA 172.16.2.2 (2198016/284160), SERIAL0
P 172.16.0.0/24, 1 SUCCESSORS, FD IS 2195456
         VIA 172.16.2.2 (2195456/281600), SERIAL0
P 172.16.1.0/24, 2 SUCCESSORS, FD IS 2681856
         VIA 172.16.3.1 (2681856/2169856), SERIAL1
         VIA 172.16.2.2 (2681856/2169856), SERIAL0
P 172.16.2.0/24, 1 SUCCESSORS, FD IS 2169856
         VIA CONNECTED, SERIAL0
P 172.16.3.0/24, 1 SUCCESSORS, FD IS 2169856
         VIA CONNECTED, SERIAL1

Router Z has two (summarized) routes to 10.0.0.0 /8: one through Router Y and one through Router X (sent to it by Router D). Since the route through Router Y has the better metric, that route is used. Thus, packets sent to 10.2.1.0 /24 are delivered, and packets to any other 10.0.0.0 subnet are dropped.

The main problem is the discontinuous subnets. Auto summarization does not support discontinuous subnets. Instead, you can achieve a higher degree of control over summarization by using manual summarization.

Manual Summarization

Instead of automatically summarizing networks and distributing classful addresses, you can summarize them manually in any way you wish. It is a two-step process:

Disable automatic summarization: This is done in router-config mode with the NO AUTO-SUMMARY command.

(config)# router eigrp ASNUMBER
(config-router)# no auto-summary

Manually summarize on a per-interface basis: This is done in interface configuration mode. You configure the summary address that you want advertised from the interface. Any subnets within that summary network are not advertised, only the summary network itself.

(config)# interface INTERFACE
(config-router)# ip summary-address eigrp ASNUMBER NETWORK MASK

Manual summarization works in a fashion similar to automatic summarization: a route for the summarized network pointing to the NULL0 interface is inserted into the routing table. That route is then distributed to the neighbors.

We can now go back to the network in Figure 11 and configure manual summarization on Router D. The configuration looks like this:

HOSTNAME ROUTERD
INTERFACE SERIAL0/0
 IP ADDRESS 10.1.16.1 255.255.255.0
 IP SUMMARY-ADDRESS EIGRP 90 172.16.0.0 255.255.0.0
INTERFACE SERIAL0/1
 IP ADDRESS 10.1.19.1 255.255.255.0
 IP SUMMARY-ADDRESS EIGRP 90 172.16.0.0 255.255.0.0
INTERFACE FASTETHERNET0/1
 IP ADDRESS 172.16.0.1 255.255.255.0
 IP SUMMARY-ADDRESS EIGRP 90 10.1.0.0 255.255.0.0
ROUTER EIGRP 90
 NETWORK 10.0.0.0
 NETWORK 172.16.0.0
 NO AUTO-SUMMARY

A summary route to 172.16.0.0 /16 is sent to Routers B and C. This is the same as with auto summarization since there are no discontinuous subnets. A summary route to 10.1.0.0 /24 is sent to Router X. That way, the 10.2.1.0 route can coexist in that network. Note that auto summarization must be disabled on Router Y for this to work.

Now we can examine the routing table on Router Y:

RouterY#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
       U - per-user static route, o - ODR
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 4 subnets
D       172.16.0.0 [90/2195456] via 172.16.1.2, 00:22:52, Serial0
C       172.16.1.0 is directly connected, Serial0
D       172.16.2.0 [90/2681856] via 172.16.1.2, 00:22:52, Serial0
C       172.16.3.0 is directly connected, Serial1
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.2.1.0/24 is directly connected, Ethernet0
D       10.1.0.0/16 [90/2198016] via 172.16.1.2, 00:17:24, Serial0

Router Y sees its directly connected network (10.2.1.0) but does not summarize it. It also sees a route to 10.1.0.0 /24, which originates from Router D.

EIGRP Load Balancing

By default, EIGRP load balances over equal-cost links. Observe the network in Figure 12.

Figure 12. Equal Cost Load Balancing

Router A has two paths to LAN 1: through Router B and through Router C. Since both paths have the same composite metric, they are used alternatively. In other words, they are evenly load balanced. The precise load balancing flow depends on the packet switching mechanism used by the router:

• Process switching load balances on a per packet basis.

• Fast switching load balances on a per network prefix basis. (As do optimum switching, silicon switching, and Netflow switching.)

• Cisco Express Forwarding load balances on a "source-destination pair" basis.

EIGRP also supports unequal-cost load balancing with the VARIANCE command. Examine the network in Figure 13:

Figure 13. Unequal Cost Load Balancing

Once again, Router A has two paths to LAN 1. However, since the metrics are not equal, only one path appears in the routing table (the one through Router C). However, with the VARIANCE router configuration command, the load can be shared over the two links. The command syntax is

(config)# router eigrp ASNUMBER
(config-router)# variance MULTIPLIER

The multiplier is the factor by which the lesser route must be within the primary route. For example, if the multiplier is 2 and the primary route metric is 100, the secondary route must have a metric of 200 or less to be used for load balancing.

There are a few additional things to know about unequal-cost load balancing:

• A secondary route can be considered for unequal-cost load balancing only if it is a feasible successor. (This is the most common oversight. Often, the secondary link is not a feasible successor).

• By default, the load balancing is done proportional to the link speed. For example, if the primary link is twice as fast, it will get twice the traffic. However, this can be changed with the TRAFFIC-SHARE router config command.

• Traffic will be load balanced across up to six paths, provided that they all fall within the variance. This number may be modified, though, with the MAXIMUM-PATHS router config command.

• Only the best route will appear in the routing table.

Link Failure Processing

The true test of a routing protocol is not during normal conditions, but during failure conditions. (Even RIP works pretty well in stable networks.) EIGRP performs respectably in failure conditions: convergence is very fast and the amount of traffic generated is not too bad. It does have some issues though. We will discuss how to plan for these with careful network design. First, we start with how EIGRP reacts to link failures.

EIGRP Actions during Link Failure

It is important to understand the steps a router takes when it loses a route(s) from its routing table. Routes are usually removed from the routing table when a link or an interface goes down, a neighbor is lost, or an update with an infinite metric is received. In any of these cases, the router does the following:

1. It sends an update packet to its neighbors with the delay part of the metric set to infinity.

2. It immediately starts searching for a new route.

It is also important to note the neighbor's response to this infinity metric update. Whenever a router receives an update from its successor with an increased metric, it immediately starts searching for a better route. In addition, the neighbor probably has to report the increased metric to its neighbors. The result is usually a chain reaction, leading many routers to simultaneously search for a new route to a destination.

The process of searching for a new route is also fairly straightforward:

1. If the router has a feasible successor, it immediately switches to it and informs its neighbors of the new metric. In this case convergence is almost instantaneous.

2. If the router does not have a feasible successor, or the successor stays the same with just an increased metric, it queries its neighbors for a better route.

It is this query/response process that becomes complex. We will spend the next section discussing it in detail.

The EIGRP Query/Response Process

There are basically three situations in which a router will query its neighbors for a route to a destination:

1. It has received an increased metric from its successor, and it has no better route.

2. It has lost a route from its routing table and has no feasible successor. (Technically, this is the same as the previous condition; you lose a route when its metric goes to infinity.)

3. It receives a query from its successor and has no feasible successor.

When a router receives a query, it reacts in the following way:

1. If the route is not in its routing table, it responds with an infinite metric and does nothing else.

2. If the query is received from a non-successor, it responds with its best route.

3. If the query is received from its successor, it overwrites its current information about that route with the new information in the query packet and then does one of three things:

   1. If it has a feasible successor, it sends a reply to the querying router and recalculates its own routing table.

   2. If it has no feasible successor, and no other neighbors, it responds with an infinite metric.

   3. If it has no feasible successor, it propagates the query to its own neighbors. It then does not respond to the initial query until it gets responses from its own queries. This turns out to be a very significant detail (more on this later).

Let's put all of this information together and look at an example of the query process in Figure 14:

Figure 14. The Query/Response Process

The link between Router A and Router C has gone down. We'll look at the query process from the perspective of Router C. Router C has lost its route to LAN 2. Since it has no feasible successor, it starts a query process:

1. Router C sends a query packet to Router D, searching for a route to LAN 2.

2. Router D has received a query (and increased metric) from its successor. Since it has no feasible successor, it sends a query to its neighbors, Router X and Router B, searching for a route to LAN 2.

3. Router X receives the query (from Router C). Since it got the query from its successor, and it has no other neighbors, it responds with an infinite metric.

4. Router B receives the query (from Router C). It too received the query from its successor, but in this case, it has a feasible successor -- through Router A. Router B responds to the query with the new route through Router A and adjusts its own routing table.

5. Router D receives the response from Router B. It takes the new route and responds to the original query from Router C. It then adjusts its own routing table and informs its neighbors (Router X and C) of the new route.

6. Router C gets its original query back with the new route. It adjusts its routing table and the query/response process is complete.

This process, though a bit cumbersome, works well in small environments. Queries and responses are very fast, so convergence is usually good. Unfortunately, it breaks down in larger environments. Examine the network in Figure 15.

Figure 15. A Large-scale EIGRP Implementation

This type of design is fairly common in enterprise environments. There are three core sites, connected together by high-speed point-to-point links. Each core site connects to 50 remote sites over low-bandwidth frame relay links. Observe what happens when the link between Core Router A and Remote Router 1 fails:

1. Core Router A does not have a feasible successor to Remote Router 1, so it sends a query to its neighbors (all 50 of them, including Core Router B), searching for a new route.

2. Remote Routers 2-50 receive the query from their successor, but since they have no other neighbors they respond with an infinite metric.

3. Core Router B receives the query from Core Router A. Since it has no feasible successor, it queries its neighbors (all 51 of them).

4. Remote Routers 51-100 behave just as Remote Routers 2-50 did.

5. Core Router C receives the query from Core Router B. It too has no feasible successor, so it queries its neighbors (again all 50 of them).

6. Remote Routers behave just as Remote Routers 2-100 did.

7. Core Router C receives all of its replies, so it replies to Core Router B.

8. Router B has now received all of its replies, so it replies to Core Router A.

9. Core Router A has now received all of its replies.

You can see that even though only one remote link went down, every router in the network had to participate in the query process. Scale this to a network of 10,000 routers, and now you are talking about a significant amount of traffic for one down link,

Unfortunately, it gets worse. A large amount of queries and responses can lead to Stuck-In-Active events, which can cause complete network meltdown.

Stuck-In-Active Events

Stuck-in-active (SIA) events are the bane of every EIGRP network. In fact, they should be the number-one design consideration when planning an enterprise EIGRP design. An SIA event occurs when a query packet gets no reply. The sequence of events goes like this (Figure 16 presents a small piece of a network):

Figure 16. SIA Activity

1. Router A (for whatever reason) needs to find a new route to LAN 1 and it does not have a feasible successor. The first thing Router A does is mark current route to LAN 1 active in the EIGRP topology table. (This was not mentioned in the previous section, but it always occurs at the beginning of the query/response process.) An active route is one that has a query about it outstanding. Contrast this with a passive route, which is a route in a stable state.

2. Router A then queries its neighbor, Router B, for a new route to LAN 1.

3. For argument's sake, let's say Router B, for whatever reason, does not respond to the query within a specified amount of time. The default time is 3 minutes (we will call this the SIA timer).

4. When the SIA timer expires and Router A still has not heard a response from router B, it removes its adjacency with Router B and continues the query/response process. The route is now called stuck-in-active.

The query/response process will probably now complete successfully, but the adjacency with Router B was lost! Any route learned from Router B is removed from the routing table, and new query/response processes are started to find new routes to these destinations (at least until the adjacency is reestablished by the hello protocol).

Let's look at the network in Figure 15 again, and examine the effects of an SIA event. Once again, we will say that the link between Core Router A and Remote Router 1 fails. The query/response process proceeds just as it did on in the original scenario until step 5. This time, though, Remote Router 150 is experiencing extreme frame relay congestion and its replies to the query from Core Router C are lost. This is what happens:

1. Core Router C cannot respond to the query from Core Router B, since it has not received all of the replies from its own query.

2. Core Router B likewise cannot respond to the query from Core Router A, since it now has not received all of the replies from its own query.

3. Core Router A's SIA timer will now expire, since it did not receive a response from Core Router B.

4. Core Router A now clears its adjacency with Core Router B and removes every route it has learned from it. Remote sites 1-50 have now lost two-thirds of the network.

5. Core Router A must propagate each of these route losses to each neighbor. It must also try to find a new route for every route it has lost, so it starts the query/response process and sends query packets for each route to each of its neighbors.

6. The Frame Relay network may now become even more congested, leading to more SIA events. In addition, the router CPU could become overloaded by the mass of route processing requests.

7. Note that the same process (routing updates and query packets for each route lost) is also happening on Core Router B, making it likely that it will overload its own frame relay network and lose its adjacency with Core Router C.

The final result is a total network disaster, all caused by one lost link and one congested frame relay circuit.

Solving the SIA Problem

Solving the SIA problem in an enterprise environment requires a careful network design, and is beyond the scope of this tutorial. However, since it utilizes some of the tools we have discussed, we will touch on it briefly.

Some of the more popular ways of avoiding SIA events include the following:

• Increasing the SIA timer

• Route summarization

• Default Routing

Of these, increasing the SIA timer is usually the least effective. It only amounts to a short-term fix. As the network grows, SIA events will return. The other two choices, route summarization and default routing, both involve placing limits on how far queries will be propagated. Route summarization does this, but, as mentioned earlier, requires a carefully planned hierarchical design. Default routing can also be used, combined with route filters, to accomplish the same thing on stub networks.

Let's examine how we might solve the SIA problem from Figure 15 with hierarchical addressing and route summarization. If the network had been designed with hierarchical addressing, it might look something like that shown in Figure 17.

Figure 17. Enterprise Network with Hierarchical Addressing

At Core Router A, instead of propagating all the remote site networks, you manually summarize the address space and propagate a route to 10.2.0.0 /16 to Core Router B. You do similar summarizations on Core Routers B and C.

Now, when the link between Core Router A and Core Router B fails, the sequence of events is as follows:

1. Core Router A does not have a feasible successor to Remote Router 1, so it sends a query to its neighbors (all 50 of them, including Core Router B), searching for a better route.

2. Remote Routers 2-50 receive the query from their successor, but since they have no other neighbors they respond with an infinite metric.

3. Core Router B receives the query, but since the route being queried on (10.2.1.0) is not in its routing table, it responds with an infinite metric and does not send any more queries.

The query radius has now been severely limited and SIA events are unlikely.

Redistribution with other Interior Gateway Protocols

Often, a pure EIGRP environment is unlikely. Eventually you will have to connect to other divisions, companies, or clients that are be using another routing protocol. That requires sharing routing information between the two protocols. We will discover how to configure redistribution in several different scenarios.

Redistribution Fundamentals

The first concept to understand is administrative distance. Each route in a routing table is assigned an administrative distance based on the routing protocol that received the route. The administrative distance is used whenever a router receives exactly the same route from two different sources. The route with the lower administrative distance is the route that gets placed in the routing table. Note that this happens before any metric comparisons take place. For example, suppose a router receives two routes to 10.1.1.0/24, one with an AD of 100 and one with an AD of 90. The route with the AD of 90 gets placed in the routing table. The exec command SHOW IP ROUTE displays the AD with each route:

ROUTERD#SH IP ROUTE
CODES: C - CONNECTED, S - STATIC, I - IGRP, R - RIP, M - MOBILE, B - BGP
       D - EIGRP, EX - EIGRP EXTERNAL, O - OSPF, IA - OSPF INTER AREA
       N1 - OSPF NSSA EXTERNAL TYPE 1, N2 - OSPF NSSA EXTERNAL TYPE 2
       E1 - OSPF EXTERNAL TYPE 1, E2 - OSPF EXTERNAL TYPE 2, E - EGP
       I - IS-IS, L1 - IS-IS LEVEL-1, L2 - IS-IS LEVEL-2, IA - IS-IS INTER AREA
       * - CANDIDATE DEFAULT, U - PER-USER STATIC ROUTE, O - ODR
       P - PERIODIC DOWNLOADED STATIC ROUTE
GATEWAY OF LAST RESORT IS NOT SET
     172.16.0.0/24 IS SUBNETTED, 3 SUBNETS
C       172.16.0.0 IS DIRECTLY CONNECTED, FASTETHERNET0/1
I       172.16.1.0 [100/8486] VIA 172.16.0.2, 00:01:21, FASTETHERNET0/1
I       172.16.2.0 [100/8486] VIA 172.16.0.2, 00:01:21, FASTETHERNET0/1
     10.0.0.0/8 IS VARIABLY SUBNETTED, 7 SUBNETS, 2 MASKS
D       10.1.8.0/24 [90/6049536] VIA 10.1.16.2, 00:00:21, SERIAL0/0
                         [90/6049536] VIA 10.1.19.2, 00:00:21, SERIAL0/1
S       10.0.0.0/8 [1/0] VIA 10.1.17.0
C       10.1.5.0/24 IS DIRECTLY CONNECTED, FASTETHERNET0/0
C       10.1.19.0/24 IS DIRECTLY CONNECTED, SERIAL0/1
D       10.1.18.0/24 [90/6023936] VIA 10.1.19.2, 00:00:21, SERIAL0/1

The administrative distances are highlighted.

EIGRP assigns to internal routes an AD of 90 and to external routes an AD of 170 (more on internal and external routes in a minute). Other IGP default values for AD are shown in Table 2.

Table 2. IGP Default Administrative Distances

Administrative distance can be manually modified with the DISTANCE router configuration command.

There is a difference between internal and external EIGRP routes. Internal routes are routes to networks contained within the EIGRP autonomous system. External routes are to networks outside of the autonomous system, which is why they have a higher value. EIGRP assumes that since they were imported into the AS in some fashion, they are less credible.

Redistribution between EIGRP Autonomous Systems

Redistribution between two EIGRP autonomous systems (AS) is very easy. Just one configuration command is all that is required. EIGRP automatically transfers the metrics between AS so your composite distances are preserved.

The following is the syntax to reconfigure redistribution between two AS:

(config)# router eigrp AS1
(config-router)# redistribute PROTOCOL AS2

AS1 = the AS you are redistributing routes into

AS2 = the AS you are redistributing routes from

There is one caveat: redistribution does not auto summarize, even between classful networks. All subnet routes distributed into an AS are propagated throughout the network. An example of this will be shown in the next section.

Redistribution between EIGRP and IGRP

Redistribution between EIGRP and IGRP encompasses two slightly different situations. The first is when both use the same autonomous system number. Observe the network in Figure 18.

Figure 18. Redistribution Between IGRP and EIGRP in the Same AS

Here, redistribution is automatic, there are no commands needed. Metrics are automatically preserved as well (since the EIGRP composite metric is the same as the IGRP multiplied by a factor of 256). However, like redistribution between two EIGRP systems, no auto summarization occurs. Observe the routing table from Router D:

ROUTERD>SH IP ROUTE
CODES: C - CONNECTED, S - STATIC, I - IGRP, R - RIP, M - MOBILE, B - BGP
       D - EIGRP, EX - EIGRP EXTERNAL, O - OSPF, IA - OSPF INTER AREA
       N1 - OSPF NSSA EXTERNAL TYPE 1, N2 - OSPF NSSA EXTERNAL TYPE 2
       E1 - OSPF EXTERNAL TYPE 1, E2 - OSPF EXTERNAL TYPE 2, E - EGP
       I - IS-IS, L1 - IS-IS LEVEL-1, L2 - IS-IS LEVEL-2, IA - IS-IS INTER AREA
       * - CANDIDATE DEFAULT, U - PER-USER STATIC ROUTE, O - ODR
       P - PERIODIC DOWNLOADED STATIC ROUTE
GATEWAY OF LAST RESORT IS NOT SET
     172.16.0.0/24 IS SUBNETTED, 3 SUBNETS
D EX    172.16.0.0 [170/5514496] VIA 10.1.16.1, 00:01:48, SERIAL0/0
D EX    172.16.1.0 [170/6026496] VIA 10.1.16.1, 00:01:20, SERIAL0/0
     10.0.0.0/24 IS SUBNETTED, 1 SUBNETS
C       10.1.16.0 IS DIRECTLY CONNECTED, SERIAL0/0

Note the administrative distances of the redistributed routes, as well as the fact that they are not summarized.

The other EIGRP/IGRP redistribution scenario involves two separate autonomous systems. Observe the network in Figure 19.

Figure 19. Redistribution between IGRP and EIGRP

When the two protocols are defined in different AS, redistribution must be manually configured. However, since EIGRP metrics are preserved, configuration is minimal. The following is the configuration on Router C:

ROUTER EIGRP 90
 REDISTRIBUTE IGRP 100
 NETWORK 10.0.0.0
!
ROUTER IGRP 100
 REDISTRIBUTE EIGRP 90
 NETWORK 172.16.0.0

Redistribution now occurs similar to how it did with one autonomous system.

Redistribution between EIGRP and Other IGPs

Redistribution between EIGRP and other IGPs is fairly straightforward. The command is essentially the same as in the previous scenarios:

(config)# router eigrp AS1
(config-router)# redistribute PROTOCOL [PROCESSID]

There is one important issue that needs to be addressed when redistributing from external IGPs: imported metrics.

When a route is redistributed into EIGRP, it must be assigned a metric that the rest of the EIGRP system will understand. There are two ways of accomplishing this:

1. Assign a metric for all routes from a particular protocol. This is done by assigning the metric in the redistribute command statement. All routes from that protocol will receive this metric. The syntax of the redistribute command is as follows:

   (config)# router eigrp AS1
   (config-router)# redistribute PROTOCOL metric BANDWIDTH DELAY RELIABILITY LOAD MTU
   

   For example, examine the network in Figure 20.

   Figure 20: Redistribution between EIGRP and OSPF

   This network has decided to redistribute all of the routes from OSPF into EIGRP and assign them the metric equivalent to 100 Mb/s Ethernet. Here is the configuration for Router C:

   ROUTER EIGRP 90
   REDISTRIBUTE OSPF METRIC 100000 100 255 1 1500
   NETWORK 10.0.0.0
   !
   ROUTER OSPF
   NETWORK 172.16.0.0
   

2. Assign a default metric for all redistributed protocols. This is done with the DEFAULT-METRIC router config command. This assigns a fixed metric to every route that is redistributed regardless of the source protocol. For example, to assign a default metric to the redistributed routes in Figure 20:

   ROUTER EIGRP 90
   NETWORK 10.0.0.0
   DEFAULT-METRIC 100000 100 255 1 1500
   !
   ROUTER OSPF
   NETWORK 172.16.0.0
   

Note: More detailed information on route redistribution can be found in various other White Papers on CertificationZone.com, such as Ron Trunk's Interior Redistribution White Paper for details of the use of policy routing in redistribution, and Howard Berkowitz's BGP series for redistribution in exterior routing.

EIGRP in NBMA Networks

NBMA (non-broadcast multi-access) networks, such as X.25, frame relay, or ATM, can present EIGRP with some problems. Frame relay is particularly troublesome, due to its high number of neighbors per interface and relatively slow speed (X.25 usually does not have that many neighbors, and ATM is frequently high enough speed to alleviate these problems).

We will look at two problems in particular: spoke connectivity in hub and spoke topologies and EIGRP congestion.

Spoke Connectivity in Hub and Spoke Configurations

Observe the network in Figure 21.

Figure 21. Frame Relay Hub and Spoke Topology

LAN 1 cannot communicate with LAN 2. Split horizon is the cause. EIGRP (like all other distance-vector protocols) follows the split horizon algorithm, which means that a router does not advertise information out the same interface that it received it on. So when Spoke Router 2 advertises the route to LAN 2 to the hub router, the hub router does not send it down to Spoke Router 1 (remember that NMBA networks use one interface to connect to numerous locations).

There are a few ways to solve this problem. The three most popular are:

• Disable split horizon with the NO IP SPLIT-HORIZON EIGRP interface configuration command. Since it can have adverse side effects, this solution is not recommended.

• Use default routing. Either apply static default routes to the spoke routers or use the IP DEFAULT-NETWORK mechanism.

• Use point-to-point subinterfaces to define a different network for each PVC.

Note that an IP DEFAULT-NETWORK command on the hub requires the least amount of configuration and upkeep, so it is the most scalable solution. However, subinterfaces can solve several other problems (some of which we will see), so it is a very popular solution.

EIGRP Congestion

NMBA networks tend to concentrate a large number of circuits into a single node. This results in numerous EIGRP neighbors and can lead to EIGRP taking a substantial amount of resources to run. We will look at several common NMBA congestion problems and the steps you can take to relieve them.

Problem #1: Routing updates from the hub are congesting the low-bandwidth PVCs to the spokes.

Solution #1: The IP BANDWIDTH-PERCENT EIGRP interface configuration command allows you to specify the maximum amount of bandwidth of a link that EIGRP may use at any given time. This percentage is based on of the interface's bandwidth parameter, so be sure to set this accurately with the BANDWIDTH interface configuration command.

Problem #2: Hello packets sent simultaneously to a large number of neighbors are overflowing the output queue and causing drops.

Solution #2: There are several steps you can take:

• Increase the output queue size with the HOLD-QUEUE OUT command

• Use point-to-point subinterfaces with varying hello timers. For example, if you had four subinterfaces with hello timers of 5, 6, 7, and 9 seconds respectively, your hello packets would almost always be spread out.

• For frame relay links, the FRAME-RELAY BROADCAST-QUEUE interface configuration command allows you to create an additional output queue solely for broadcasts.

Problem #3: Point-to-Point interfaces get congested more easily.

Solution #3: Point-to-point subinterfaces have a 5-second hello packet interval instead of the default 60 seconds for low speed WAN interfaces. Increase this value if fast convergence isn't a prime concern.

Carefully calculating how much bandwidth you have and how much EIGRP should require can help you pick the thresholds you should use when configuring these links. Remember to always plan for a worst-case scenario. Ask yourself "what is the largest state change possible at once?" and configure accordingly.

EIGRP with IPX and AppleTalk

EIGRP is the only enterprise routing protocol to support IPX and AppleTalk as well as IP. IPX and AppleTalk are both LAN-based protocols and EIGRP can help them significantly in the WAN environment. However, since neither protocol was designed with the WAN in mind, you will find that their EIGRP implementations are severely limited compared to IP. Features such as route summarization and default routing are not available. However, their EIGRP implementations are still built around DUAL, and still use the basic mechanisms of EIGRP.

EIGRP and IPX

Novell designed IPX for the LAN environment. Many of the scalability features of IP that we take for granted are just not part of IPX. For example, IPX does not have a hierarchical design. And Novell took many years before they added a default route mechanism to IPX. Worse still, IPX depends on broadcasts, both RIP and SAP, to find its services. This makes it very unsuitable for large WANs. Fortunately, IPX EIGRP, in combination with other features such as SAP filters, can successfully migrate an IPX LAN to scalable WAN.

IPX EIGRP vs. IP EIGRP

IPX EIGRP shares many characteristics of IP EIGRP, such as the following:

• The DUAL algorithm

• The HELLO protocol

• Establishing adjacencies

• Metric calculation

• Topology and neighbor databases

• Show commands are the same.

However, there are significant differences as well:

• IPX routes have no administrative distance. Instead IPX routes are chosen solely on their metric value. Of course, this requires the metrics to be comparable. Fortunately, the designers of IPX EIGRP took this into account and developed an algorithm to successfully compare IPX EIGRP and RIP metrics to determine the best route.

• IPX EIGRP does not support route summarization. Since IPX is not hierarchical in nature, route summarization isn't possible.

• IPX EIGRP uses broadcasts instead of multicasts.

Configuration of IPX EIGRP

Basic configuration of IPX EIGRP is very straightforward:

(config)# ipx router eigrp AS#
(config-router)# network NETWORK#

Interestingly enough, you can't run IPX EIGRP with IPX RIP completely turned off. They must be run together. Novell servers depend on IPX RIP to find things. If it is turned off on your routers, your servers can start to lose visibility across the WAN. Because of that, there are two efficient methods of running IPX EIGRP:

• IPX RIP in the LAN -- IPX EIGRP over WAN links

• Both IPX RIP and IPX EIGRP in the LAN -- IPX EIGRP over WAN links

Each of these involves removing RIP from your WAN links (which was the initial impetus to moving to EIGRP in the first place!). Since IPX RIP is enabled on all interfaces with IPX network numbers defined, you must manually remove RIP. This is easy and straightforward:

(config)# ipx router rip
(config-router)# no network NETWORK#

Note: IPX EIGRP does not support IPXWAN. IPXWAN uses dynamic IPX network numbers, and EIGRP numbers must be assigned manually. Therefore, the two are incompatible.

Figure 22 shows an IPX WAN with IPX RIP running over the LAN links and IPX EIGRP running over the WAN links:

Figure 22. IPX RIP and EIGRP

Operation of IPX EIGRP

EIGRP was designed to be as user-friendly as possible. Several processes automatically happen behind the scenes to make EIGRP function correctly with only the minimal configuration we have presented:

• EIGRP metrics are compatible with RIP metrics. We've already mentioned this one.

• Route redistribution between IPX EIGRP and IPX RIP is automatic. You can run these protocols on separate networks (such as in Figure 21), and the routes will be automatically redistributed (and the metrics translated).

• IPX uses incremental SAP updates and suppresses regular SAP broadcasts on WAN links. It does this by building a secondary SAP database -- an EIGRP SAP database. When an EIGRP router receives a SAP packet, it places the contents in the secondary SAP database and then the main SAP database. When it establishes an adjacency with a router over a WAN link, it sends the whole database. Thereafter, it sends only changes that are made. It can do this because EIGRP is a reliable protocol.

These combinations of features make EIGRP an ideal replacement for IPX RIP in the enterprise WAN.

EIGRP and AppleTalk

AppleTalk EIGRP shares many characteristics of IPX EIGRP. Most of the advanced IP features, such as route summarization and default routing, are not found in AppleTalk EIGRP. Also, AppleTalk EIGRP is primarily designed for WAN links. Like IPX, AppleTalk's primary routing protocol (RTMP) must run in the LAN for it to function properly. Therefore, we'll find that except for some (major) configuration differences, this section is remarkably similar to the last.

AppleTalk EIGRP vs. IP EIGRP

We'll start again by looking at the similarities between IP EIGRP and AppleTalk EIGRP:

• The DUAL algorithm

• The HELLO protocol

• Establishing adjacencies

• Metric calculation

• Topology and neighbor databases

• Show commands are the same

However, there are significant differences as well:

• There is no autonomous system in AppleTalk EIGRP. Instead, each router has a Router ID. This ID must be unique.

• AppleTalk EIGRP uses broadcasts instead of multicasts.

• AppleTalk routes have no administrative distance. Instead AppleTalk EIGRP routes are always preferred to RTMP routes.

• AppleTalk EIGRP does not support route summarization. Since AppleTalk is not hierarchical in nature, route summarization is again impossible.

Configuration of AppleTalk EIGRP

Basic configuration of AppleTalk EIGRP is quite different from IP and IPX. First, there is no router configuration mode. Instead, the EIGRP process is defined in global configuration mode. Then, the protocol is applied to each interface it runs on. Basic configuration looks like the following:

(config)# appletalk routing eigrp ROUTERID
(config)# interface INTERFACE
(config-if)# appletalk protocol eigrp

Like IPX, you can't run AppleTalk EIGRP while completely turning off RTMP. RTMP is used to find cable ranges and routers on the LAN. If you disable it you will lose connectivity to your WAN. Because of that, there are two efficient methods of running IPX EIGRP:

• RTMP in the LAN -- AppleTalk EIGRP over WAN links

• Both RTMP and AppleTalk EIGRP in the LAN -- AppleTalk EIGRP over WAN links.

Again, each of these involves removing RTMP from your WAN links. Since RTMP is enabled by default when AppleTalk is enabled, it must be manually disabled. This too is done on a per interface basis:

(config)# interface INTERFACE
(config-if)# no appletalk protocol rtmp

Operation of AppleTalk EIGRP

AppleTalk EIGRP was designed to be as user-friendly as possible. As with IPX, several processes happen automatically behind the scenes to make EIGRP function correctly with minimal configuration:

• EIGRP metrics are compatible with RTMP metrics. As with IPX, AppleTalk EIGRP designers came up with an algorithm to allow the metrics to be translated to one another.

• Route redistribution between AppleTalk EIGRP and RTMP is automatic. You can run these protocols on separate interfaces and the routes will be automatically redistributed (and the metrics translated).

Note: more detailed information on AppleTalk can be obtained in Priscilla Oppenheimer's AppleTalk White Paper on CertificationZone.com

Conclusions

EIGRP is a major step forward in routing protocol design. It is simple to use and administer yet scalable enough for the most demanding of networks. In addition, it overcomes a few of the shortcomings of OSPF. Its biggest downfall is its proprietary nature, but if you can commit yourself to a purely Cisco architecture, it should be the ideal interior protocol for your LAN and WAN needs.

[IE-EIGRP-WP1-F05]
[2000-12-31-01]