eigrp.v2 (2)

Enhanced Interior Gateway Routing Protocol (EIGRP)

by Jason Sinclair

Introduction EIGRP -- Distance Vector or Link State? Distance Vector Link State History of Distance Vector (DV) IGPs History of EIGRP EIGRP Operation and Mechanics Overview of EIGRP terminology EIGRP Neighbors and the Hello Mechanism EIGRP Packet Format EIGRP does use Router IDs Diffusing Update Algorithm (DUAL) Diffusion EIGRP Metrics EIGRP Route Selection Mechanism EIGRP Internal Mechanisms -- The Databases Topology Changes and Link Failures EIGRP Actions during Link Failure The EIGRP Query/Response Process Stuck-In-Active Events Solving the SIA Problem Route Summarization Default Routes and EIGRP Stub Routing EIGRP in NBMA Networks Spoke to Spoke Connectivity EIGRP Congestion Issues Basic EIGRP Configuration Classful Autosummarization Classless Configuration Additional EIGRP Features EIGRP Load Balancing -- Equal Path Unequal Cost Load Balancing Summarization Automatic Summarization Problems with Auto Summarization Manual Summarization Authentication Bandwidth Use Common EIGRP Configuration Tasks Equal cost load balancing Unequal cost load balancing Running multiple EIGRP processes Configuring EIGRP Unicast Neighbors Configuring EIGRP Neighbor Authentication Protocol Redistribution Overview of Redistribution

Tutorial

of 39Certification Zone - Tutorial

5/31/2005http://www.certificationzone.com/cisco/studyguides/component.html?module=studyguides...

Redistribution between EIGRP Autonomous Systems Automatic and manual redistribution between IGRP and EIGRP Redistribution between other IGPs Redistribution between EIGRP and BGP Conclusion References and Recommended Reading

Introduction Enhanced Interior Gateway Routing Protocol (EIGRP) was developed by Cisco Systems, Inc. The name suggests that it's an enhancement to Cisco's IGRP, but that's a misconception. There are two main families of routing protocols in use in the Internet, distance vector and link state. In this section, we will discuss each of these protocols families.

Distance Vector

In the "Scalable Routing and Link State Review" Tutorial, Howard Berkowitz states: "In a distance vector algorithm, each network entity generates a map of its paths to all connected nodes in the network, but sends this map to only its adjacent neighbors."

A router using a distance vector protocol records the distance (a metric, usually hop count) from it to the destination and the next hop (which is the vector) to reach that destination and communicates this to its neighbors. In Distance Vector protocols, every router builds its own topology or view of the network based on its neighbor's information.

Link State

Also from Howard Berkowitz in the same Guide: "Link state algorithms are a 'mirror' image of distance vector: they create cost maps only of the paths to their adjacent neighbors, but flood the entire routing domain (or area) with these maps."

Link state protocols have two phases: the synchronization of the network-wide link state database, and the computation of routes (next hops) to each destination. Routers using a link state protocol maintain identical views of the network topology.

History of Distance Vector (DV) IGPs

First Generation: The first generation of distance vector protocols is typified by protocols such as RIPv1 and AppleTalk's RTMP. In these first generation protocols, hop count is the only metric used, which means that routing is only optimized when the network consists of links of the same bandwidth. These protocols also employ count-to-infinity rules and split-horizon techniques for loop avoidance. First generation distance vector protocols send the entire routing table by default at periodically defined intervals.

Second Generation: IGRP is a good example of a second-generation distance vector routing protocol. IGRP can make use of more than just the hop-count as a metric and can take into account multiple link characteristics, such as bandwidth and delay. Second generation DV protocols also have additional loop

EIGRP -- Distance Vector or Link State?

A frequently asked question is whether EIGRP is a distance vector or link-state protocol. EIGRP uses a hello protocol and "on demand" updates. This leads some people to believe that it falls into the category of link state. On the other hand, EIGRP also uses aspects of the distance vector model such as relying on a neighbor's perception of the network to calculate the best path.

Cisco markets EIGRP as a hybrid routing protocol. DUAL, which is the essence of the EIGRP decision process, was developed by JJ Garcia-Luna-Alceves who described DUAL as an advanced distance vector algorithm in his original works, and verified this in a personal communication with Howard Berkowitz. Despite Cisco's marketing of EIGRP as a hybrid routing protocol, it is in fact a distance vector protocol, albeit of an advanced form.



avoidance techniques built in and generally send updates and not full tables.

Third Generation: The classic example of a third generation distance vector routing protocol is EIGRP. EIGRP retains the characteristics of IGRP and makes use of a hello sub-protocol to increase response time after link failures. The hello protocol employed also serves to reduce routing traffic that is passed over the network. Third generation DV protocols tend to emphasize loop prevention techniques rather than loop avoidance techniques. DUAL is the algorithm that EIGRP uses to provide this loop prevention functionality.

History of EIGRP

Cisco Systems Inc originally developed IGRP in the 1980s as a replacement routing protocol for the then widely deployed Routing Information Protocol (RIP). RIP gained popularity for a number of reasons, but one of the most telling was the fact that RIP was provided free on several vendors' operating systems. Another reason is that it was, and remains still, simple to configure.

Notwithstanding its popularity, RIPv1 had several limitations including excessive bandwidth utilization, slow convergence times, and network diameter limitations. IGRP was developed by Cisco to address these limitations. The success of IGRP was not long lived, as some of the limitations of RIP persisted, even if those limitations were not as severe.

OSPF and IS-IS were developed in the late 1980s by network architects and implemented as the preferred IGPs for large Enterprise networks, which led Cisco to respond with their development of EIGRP. Cisco first delivered EIGRP in IOS version 9.21.

Cisco's response with EIGRP as an alternative to OSPF and ISIS was for several reasons, namely:

EIGRP is easier to configure in small scale networks

EIGRP is possibly more stable than OSPF and ISIS

EIGRP offers multi-protocol support, including IP, IPX and AppleTalk

Competition

It is a common misconception that EIGRP is just an enhancement to IGRP. It is easy to see how EIGRP's name can promote this misunderstanding, however EIGRP actually bears only minimal resemblance to its predecessor and provides much more functionality and scalability than IGRP.

EIGRP has four main components, three of which are distinctly different from other IGPs:

1. Protocol Dependant Modules (PDM)

EIGRP has a separate module for each of the three routed protocols it supports, namely IP, IPX, and AppleTalk. The choice of routed protocol deployed determines which PDM EIGRP uses.

2. Reliable Transport Protocol (RTP)

The Reliable Transport Protocol (RTP) is responsible for guaranteed delivery of EIGRP packets and also ensures that packets are delivered in order. EIGRP packets are sent via the multicast address 224.0.0.10. Cisco has implemented a concept of reliable multicast where each received multicast packet is acknowledged via a unicast packet to the sender.

Ordered delivery is ensured by the use of sequence numbers in the EIGRP header. Cisco has patented this methodology.



3. Diffusing Update Algorithm (DUAL)

EIGRP uses the DUAL algorithm to calculate the best path to a destination while guaranteeing a loop free topology. DUAL will be discussed in depth in this Guide. This algorithm was developed outside of Cisco. [Garcia-Luna-Alceves1993]

EIGRP also uses the following mechanism, common to other advanced routing protocols:

4. Hello Sub-Protocol

EIGRP employs a hello sub-protocol for neighbor discovery and recovery, which will be discussed in more detail later in this Guide. OSPF uses a similar protocol.

It is also worth noting here that the use of hello protocols does not define a link-state protocol. It is merely a tracking mechanism. It is the global synchronization of link-state databases that define this family of routing protocols.

EIGRP Operation and Mechanics

Overview of EIGRP terminology

The two tables and diagram below introduce the terminology that will be used in the discussion of EIGRP.

Table 1. EIGRP Topological Elements and Parameters

The show ip eigrp topology command can be used to display the value of some of these parameters. The following diagram reveals how this information can be obtained.

Neighbor A router running the same routing protocol with which communication has been made and some required values match. Neighbors do not need to be physically adjacent.

Neighbor Table

A database maintained by EIGRP that lists each adjacent neighbor discovered by that router via the Hello sub-protocol.

Topology Table

A database maintained by EIGRP of routing information learned via a neighbor.

Successor A neighbor selected as the next hop.

Reported Distance

The distance from the successor to the destination. This is the same as the term 'advertised distance', commonly used in Cisco literature and training courses.

Feasible Distance

The current best distance to a destination.

Feasibility Condition

A step in the DUAL algorithm. The Feasibility Condition is satisfied when the minimum of the neighbors' costs to the destination plus cost of the link to that neighbor is less than the current best cost to the destination.

Feasible Successor

A neighbor that satisfies the Feasibility Condition. EIGRP stores the successor and all neighbors that are closer to the destination.



Table 2. EIGRP Protocol Concepts

Hello A message of a routing protocol used for neighbor discovery and tracking. In EIGRP, hello packets are sent to the multicast address of 224.0.0.10.

Acknowledgements Acknowledgements are sent in response to hello packets. This is how EIGRP guarantees reliable delivery and receipt.

Hello Timer The interval between hello packets. In EIGRP, the default is 5 seconds or 60 seconds depending on the underlying media.

Hold Timer The amount of time a router waits without receiving a hello from a neighbor before marking it as no longer available.

Update An update is a protocol message. An update is sent when any of the following occurs:

when a neighbor first comes up when a router moves from Active to Passive state for any destination when there is a metric increase for a given destination

Query Sent to all neighbors when a router enters a destination into the Active state. The router will remain in the active state unless it receives replies from all its neighbors.

Reply Required response to a query. If the neighbor doesn't have the information, it will in turn send a query to its neighbors.

Active State A router enters a destination into the Active State when it has lost its successor to that destination and has no feasible successor. The router must compute a new route to the destination.

Passive State A destination is said to be in the Passive State when it has a feasible successor in the router's topology table.



EIGRP Neighbors and the Hello Mechanism

EIGRP routers do not exchange routing information until they form a neighbor relationship. To do this, EIGRP uses its version of the hello protocol. EIGRP routers will periodically multicast (224.0.0.10) a hello packet out of its configured interfaces. Note that hellos are sent or received via the primary IP address configured on an interface. EIGRP cannot form a neighbor relationship with secondary address routers.

An EIGRP router receiving hello packets will attempt to form a neighbor relationship with the sender (provided they have common compatible parameters such as common Autonomous System numbers, K values, etc.). Once the neighbor relationship, or adjacency, is established, the two routers exchange full routing information. After the initial exchange of routing information, the routers will only exchange routing information when a topology change is detected. This is known as non-periodic updates. Hello packets are sent and received at periodic intervals to track neighbors.

Hello packets are also used to identify when a neighbor is no longer available. 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 flushed. If the router subsequently hears from the neighbor again, it will reestablish the adjacency and re-exchange routing information.

EIGRP uses two timers to with respect to the hello mechanism:

The neighboring router's Hello timer in the hello packet specifies the Hold time. This allows neighbors with different settings for their timers to interoperate successfully. For example, examine the following figure:

When Router A establishes its adjacency with Router B, it informs Router B that its hello time is 5 seconds. Router B then sets its hold timer for Router A to be 15 seconds -- allowing it to quickly detect a downed link. Router A, in turn, will wait 180 seconds, due to Router B's longer hello time.

EIGRP Packet Format

SIA (Stuck In Active)

A state where the router has not had a response from a query packet for a pre-determined time. The default time is 3 minutes.

Hello 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, X.25 and ATM) that default to 60 seconds. The default hello time can be modified with the ip hello-interval eigrp interface configuration command.

Hold 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 without the router clearing the adjacency. The default hold time can be modified with the ip hold-time eigrp interface configuration command.



EIGRP uses its own reliable protocol to transport EIGRP messages. Like OSPF, EIGRP runs over IP, and is responsible for its own transport-layer retransmission. EIGRP packets can be identified by the IP protocol ID of 88 in the IP header. The same packet format is used to carry all EIGRP messages from hello packets to routing updates. The following diagram gives the format of the EIGRP packet common header.

The preceding is a general-purpose header; similar to the one used by OSPF.

The update is the message frame used to pass prefixes between neighbors. The contents of the update packet can be seen by issuing the debug ip eigrp command. An example output of this is:

IP-EIGRP: Processing incoming UPDATE packet IP-EIGRP: Int 12.12.12.0/24 M 409600 - 256000 153600 SM 128256 - 256 128000

The following table indicates the meaning of each field:

The detailed route information is in the Type-Length-Value (TLV) extensions [Zinin2002].

Table 3. Parameter TLV

Field Description

IP-EIGRP

Indicates that this is an IP Enhanced IGRP packet.

Int Indicates that the route is an internal route. Possible values are Int or Ext.

Prefix Indicates the prefix being sent or received in the update.

M Displays the computed metric, which includes SM and the cost between this router and the neighbor. The first number is the composite metric. The next two numbers are the inverse bandwidth and the delay, respectively.

SM Displays the metric as reported by the neighbor.

Parameter Value Offset Length

Type 0x0001 0 0

Length 12 2 2

K1 4 1



Ks must match between neighbors for a neighbor relationship to form. They are not negotiated, and used in the metric calculation.

IP Internal Route TLVs carry routes generated inside the current EIGRP process.

Table 4. Internal Route TLV

External TLVs carry routes redistributed into the EIGRP process.

K2 5 1

K3 6 1

K4 7 1

K5 8 1

Reserved 9 1

Hold Time 10 2


Type 0x0102 0 0

Length 2 2

Next Hop 4 4

Delay 8 4

Bandwidth 12 4

MTU 16 3

Hop Count 19 1

Reliability 20 1

Load 21 1

Reserved 23 2

Prefix Length 24 1

Destination value (the announced prefix) 21 1


Length 2 2

Next Hop 4 4

Originating Router 8 4

Originating AS 12 4

Tag 16 4

External metric 20 4

Reserved 24 2

Protocol ID 26 1



Diffusing Update Algorithm (DUAL)

This section will detail the operation of DUAL and highlight how it is used to select a best path. Cisco's use of DUAL in EIGRP is not well documented, although recently Cisco has been more forthcoming with information. We will discuss some of the internals of EIGRP that have been published.

EIGRP is very well known as a proprietary routing protocol developed by Cisco Systems Inc. It is less well known that the DUAL algorithm was invented and patented by J.J. Garcia-Luna-Alceves, then at Stanford Research Institute [Garcia-Luna-Alceves1993]. While his more recent work has not been implemented in Cisco routers, he believes he has developed even faster distance vector algorithms; see his webpage [Garcia-Luna-Alceves].

DUAL is based on the diffusion algorithm proposed by Dijkstra and Scholten [Dijkstra1980] and leverages the observation that it is impossible to create a loop in a topology by picking a shorter path to a destination than is already known. (This assumes, of course, that link costs are nonnegative.)

DUAL uses two key data structures. It is crucial to know and understand these if the concept of DUAL is to be understood.

Array d[k,j] known in EIGRP as the reported or advertised distance, this array holds the distance from each neighbor k to each destination j. The array is populated by updates advertised by neighbors.

Array l[k] -- this structure contains the cost of the link between the local router and each neighbor k. In EIGRP, this is the distance to reach the neighbor.

Using the above data structures, each router attempts to minimize the cost to every destination by selecting the neighbor that minimizes the cost to j. The cost for the path to j through the neighbor, x, is given by Equation 1, below.

Equation 1: Cost to a Destination, j

distance to j = l[x] + d[x,j]

Flags 27 1

Prefix Length 24 1

Delay 28 4

Bandwidth 32 4

MTU 36 3

Hop Count 39 1

Reliability 40 1

Load 41 1

Reserved 42 2

Prefix Length 44 1

Destination value (the announced prefix) 45 3

EIGRP does use Router IDs

It is "well known," but wrong, that only BGP, OSPF, and ISIS use router IDs. EIGRP uses a router ID to identify the router redistributing internal information into the EIGRP process.

Duplicate router IDs can cause as much problem in EIGRP as in other protocols, if there is redistribution into EIGRP. Set the router ID with a stable loopback interface as you do with other protocols.



That is, the cost to reach the destination, denoted as j, is the cost of the link to the next hop router plus the cost of the route from that neighbor to the j.

Now suppose that an update arrives. How do we determine whether we should use the new update in the best path? The answer is given by the basic principle of DUAL: that a loop cannot form if we use a shorter path to a destination. Thus, if a new update arrives yielding a shorter path, we should adopt that update as the new best path. This can be formulated as:

Equation 2: New Best Path

Suppose that the current next hop is x and an update l[k] or d[k,j] is received. If

(l[k] + d[k,j]) < (l[x] + d[x,j])

then the router k is the new best next hop to j. EIGRP will then advertise this to the router's neighbors.

What if an update is received that yields a path longer than the existing best path choice? Do nothing. That is, unless that path is through your current next hop. In that case, the path currently in use has gotten worse. It is necessary to look for a new "acceptable neighbor", in Cisco terminology, a feasible successor.

A feasible successor is any neighbor for which:

Equation 3: Feasible Successor

d[k,j] < current cost to j

This is the feasibility test. If there is no new acceptable neighbor, then continue using the neighbor that has increased the cost as the next hop, while a diffusion computation is carried out (see below). This logically leads us into the concept of choosing the best neighbor from the set of "acceptable neighbors". If we have a set of neighbors, then choose the neighbor that has the least cost path to j

Equation 4: Least Costly Neighbor

The neighbor k, for which

l[k] + d[k,j] <= l[x] + d[x,j], for any feasible successor, x.

Diffusion

If there are no acceptable neighbors, then DUAL dictates that a diffusion computation is carried out. The following occurs:

The routing entry is frozen in a state similar to a holddown where there are no loops but the destination is effectively black holed.

A query that contains the current frozen route information for d[k,j] for each neighbor is sent to all neighbors.

Those routers for which the route is passive, that is, stable in the routing table, send the reply. If the router receiving the query finds the route in the active state due to this newly received information, the router passes the query to all its neighbors.



Ebb state: The diffusion computation will continue until it goes into a state known as the ebb state. This occurs when a router in the active state receives a reply from all its neighbors and returns a reply back to the original querying router. The router will then return to the passive state.

Once the original querying router has received a reply from all its neighbors, the diffusion process is complete and the router can choose the best next hop, k, based on the least cost value

Equation 5: Best Next Hop

l[k] + d[k,j]

To clarify the idea of "feasible successor", consider the diagram below.

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 loop-free for a router to become a feasible successor.)

It is clear that in this example Router C is in fact a feasible successor as its reported distance, 110, is less than the current feasible distance of 160.

EIGRP Metrics

All routing protocols have some concept of a metric, the value used to calculate the best path to a destination. EIGRP uses a composite metric based on a number of link parameters. Although there are five parameters that are tracked by EIGRP for metric computation, it is important to note that only two of these are used by default (bandwidth and delay) and one is not actually used for calculating metrics at all (MTU). These are as follows:

Bandwidth This is the bandwidth of the link in kilobits. Note that the default bandwidth on serial interfaces is 1544 kilobits regardless of the actual link speed configured. The use of the bandwidth statement is needed to correct EIGRP operation. We will discuss this in more detail under the configuration section. Bandwidth is used by default by EIGRP in calculating its composite metric.

Delay This is the propagation delay of the link in question in tens of microseconds. EIGRP uses delay by default to calculate the composite metric.

Reliability Reliability is a measure of how reliable a link is based on historical data pertaining to the amount of time a link has been available to pass data. This is a value from 1 to 255. A value of 255 indicates that a link is 100% reliable. This metric is not by default used by EIGRP.

Load This metric is used to determine how utilized a link is at any given time. Unlike bandwidth or delay, load is not a static number and changes as network traffic load



The following table displays the standard Cisco values for bandwidth and delay for various interface types. Please note that this assumes that the interface bandwidth or delay commands have not been used to modify the default values:

Table 5. Default Bandwidth and Delay for Interface Types

EIGRP Route Selection Mechanism

When EIGRP calculates the best path or feasible distance to a destination, it makes use of the composite metric. The formula that is used to calculate this composite metric is:

Equation 6: Composite Metric Computation

Where K1, K2, K3, K4, and K5 are constants and

BW = (107 / minBandwidth)

The K constants are passed in the hello packets and must match between neighbors.

The variable minBandwidth is the lowest of any bandwidth along the path to the destination. It is not the bandwidth on the local outgoing interface, but is computed from the minBandwidth for each destination in the Update message.

changes. Load is a value from 1 to 255 with 255 meaning a link is 100% utilized. This is not a metric that EIGRP uses by default.

Maximum Transfer Unit (MTU)

The minimum Maximum Transfer Unit to a destination is tracked by EIGRP, and is often mistaken as a parameter in the calculation of the composite metric. MTU is tracked by EIGRP for internal loop avoidance purposes only. The formula that is used to calculate the composite metric is shown in the following section and does not use the MTU.

Interface Bandwidth (Kb/s) Delay (microseconds)

10 Mb/s Ethernet 10000 1000

100 Mb/s Ethernet 100000 100

1000 Mb/s Ethernet 1000000 10

Token Ring 16000 630

FDDI 100000 100

Serial 1544 20000

Channelized T1 (or E1) 1536 20000

Fractional T1 (or E1) (# channels) * 64 20000

ISDN BRI or PRI 64 20000

Loopback 8000000 5000



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

Delay is measured in tens of microseconds. Note that the output of the show interfaces command displays delay in milliseconds.

On first inspection, this formula may seem quite unwieldy. However, the constants K2, K4, and K5 exist only for backward compatibility with IGRP and are set to zero by default. If the constants K4 and K5 are set to zero, their whole term is removed from the equation. K1 and K3 are set to 1 by default. Using these defaults results in the following, much simplified, formula:

Equation 7: Default EIGRP Composite Metric

CompMetric = [(107 / minBandwidth) + sum of interface delays] * 256

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

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

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

It must be noted here that EIGRP implements an upper hop count limit of 224 hops to a destination. Above that, EIGRP will mark the route to that destination as unreachable.

The following example will help clarify the use of the composite metric in the EIGRP route selection process. Consider the following network topology with some arbitrary values assigned.

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

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

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

Since the path through Router B has the lower cost, it is chosen as the best path to LAN2.

Let's look at the same example again. This time we replace the arbitrary values with actual link values of bandwidth and delay:



Once again, PC1 is attempting to communicate with PC2. Router A must determine the best path to the destination LAN 2. Because we are using only the default metrics of bandwidth and delay, the following formula is used to calculate the composite metric via each path:

CompMetric = [ (107 / minBandwidth ) + sum of interface delays ] *256

The path via Router B has a minimum bandwidth of 384 Kbps and a total delay of 40100. The composite metric is:

[(107 / 384 ) + 40100 ] * 256 = 16932267

Similarly, the path via Router C has a minimum bandwidth of 256 Kbps and a total delay of 40100. The composite metric for this path is:

[(107 / 256 ) + 40100 ] * 256 = 20265600

It is easy now to see that the path chosen with the best composite metric is via Router B.

EIGRP Internal Mechanisms -- The Databases

Two databases are used by EIGRP to store information. These are fundamental to the operation of EIGRP and are described below.

Neighbor Database: Neighbors are discovered via the EIGRP hello sub-protocol. When an EIGRP router forms an adjacency with another EIGRP router, it stores this neighbor information in the neighbor database. The show ip eigrp neighbors command can be used to display the information stored in this database. Sample output is show in the following figure:

Topology Database: EIGRP routers store not only the best route to a destination, they store up to five alternative routes as well. The next hop, along with other necessary information such as feasible



distance and reported distance are stored in the topology database. The information that is stored in the topology database can be viewed by issuing the show ip eigrp topology command. The following figure details the output from this command:

RouterA>show ip eigrp topology IP-EIGRP TOPOLOGY TABLE FOR AS(90)/ID(10.1.18.2) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 0.0.0.0/0, 0 successors, FD is Inaccessible via 172.16.1.3 (307200/281600), Ethernet1/0 via 172.16.1.2 (307200/281600), Ethernet1/0 P 203.18.188.70/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 203.18.188.78/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 203.57.207.0/24, 1 successors, FD is 307200 via 172.16.1.2 (307200/281600), Ethernet1/0 P 172.16.254.0/30, 1 successors, FD is 793600 via 172.16.1.3 (793600/551936), Ethernet1/0 P 192.168.37.0/24, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 202.12.242.105/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0 P 202.12.242.106/32, 1 successors, FD is 307200 via 172.16.1.3 (307200/281600), Ethernet1/0

It is also possible to view a summarized version of the topology database by adding the summary keyword to the show ip eigrp topology command:

RouterA>show ip eigrp topology summary 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 keyword can offer some quick insight into your routing process, including the following:

Total number of routes

Number of routes pending replies

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. If the difference between the head serial and the next serial is great, it can indicate network instability.

The topology database actually contains ALL routes (known to EIGRP) to a destination, though only successors and feasible successors are displayed with the show ip eigrp topology command. To see all of the routes (including non-feasible successors), use the show ip eigrp topology all-links command.

To see detailed information about a route, specify the route in the show ip eigrp topology route



statement. For example:

RouterA>show ip eigrp topology 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 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.

Topology Changes and Link Failures

The true test of a routing protocol is not during normal conditions, but during failure conditions. (Even RIP works reasonably well in stable networks.) EIGRP performs respectably in failure conditions: convergence (the time taken for all routers to have an identical view of the network) is fast and the amount of overhead traffic generated is not excessively high. It does have some issues though. The following sections highlight how EIGRP reacts and behaves when there is a link failure.

EIGRP Actions during Link Failure

This section discusses how the EIGRP implementation of DUAL operates when there are routing topology changes.

It is important to understand the steps a router takes when it loses a route or routes 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 for each unreachable destination

2. It immediately starts searching for a new route.

3. The neighbor's response to this infinity metric update is to immediately start searching for a better route. In addition, the neighbor 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 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. The next section discusses this process in detail.

The EIGRP Query/Response Process

There are 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 to that destination.

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 (A) receives a query, it reacts in the following way:

1. If the route is not in A's routing table, A responds to the querying router with an infinite metric and does nothing else.

2. If A has the route and the query is received from a non-successor, A responds with its best route to the destination.

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

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

b. If A has no feasible successor, it propagates the query to its own neighbors. It waits until it gets responses from its own queries before sending a reply. This turns out to be an important detail (more on this later).

c. If A has no feasible successor, and no other neighbors, it responds with an infinite metric and does nothing else.

It is prudent to introduce a concrete example of this process.



The link between Router A and Router C has failed. Let's look at the query process from the perspective of Router C. Router C has lost its route to LAN 2. Let us presume it has no feasible successor and it starts a query process:

Router C marks the route to LAN 2 as "active".

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

Router D receives a query (and increased metric) from its successor C. 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.

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

Router B receives the query (from Router D). 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.

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.

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

In a network of relatively small scale, this process works extremely well. Queries and responses are very fast, so convergence is usually fast as well. Unfortunately, it breaks down in larger scale topologies:

The design above 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. Router A marks the topology entry for Remote Router 1 as "active".

2. Router A then sends a query to its neighbors (all 50 of them, including Core Router B), searching for a new route.

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

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

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

6. 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).

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

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

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

10. 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 you can see that a very large amount of traffic can be generated by a single link outage.

Although the above situation is serious in its own right, a large number of queries and responses can also lead to an event known as Stuck In Active (SIA). This is a potentially network-crippling situation, which we discuss in the next section.

Stuck-In-Active Events

Stuck-in-active (SIA) events are the number one issue when designing and maintaining EIGRP topologies. An SIA event occurs when a query packet gets no reply for a predetermined time (by default, 3 minutes). The following illustrates an SIA event:

Router A 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. An active route is one that has a query about it outstanding. Router A then sends a query to its neighbor, Router B, for a new route to LAN 1

If 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).

Looking again at a large-scale network topology, let's examine the effects of an SIA event.

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 C queries its neighbors. This time Remote Router 150 is experiencing extreme frame relay congestion and its replies to the query from Core Router C are lost. The following events then occur:

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 has not received all of the replies from its own query.

3. Core Router A's SIA timer expires, since it did not receive a response from Core Router B in the allotted time.

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 routes to 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.

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.

Note that an identical process of sending routing updates and query packets for each route lost is also occurring on Core Router B. It is highly likely that Core Router B will overload its own frame relay network and lose its adjacency with Core Router C.

We can see in this example that as a result of the loss of a single link and a single congested link, SIA events have colluded in what could be politely termed a network disaster.

Solving the SIA Problem



Solving the SIA problem in an enterprise environment requires careful network design. This is well beyond the scope of this tutorial; however, we will touch on some possible resolutions here.

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

Increasing the SIA timer

Route summarization

Default Routing

EIGRP Stub Routing

Although increasing the SIA timer may seem the simplest option to resolve SIA events, on closer examination it is usually the least effective. As the network grows, SIA events will return and hence this will only provide a short-term or "Band-Aid" solution.

Route summarization and default routing both involve placing limits on how far queries are propagated. If route summarization is deployed, a carefully planned hierarchical design is required. Default routing may be used, combined with route filters, to accomplish what can be done better with stub networks.

Route Summarization

Let's examine how we might solve the SIA problem with hierarchical addressing and route summarization. If the network had been designed with hierarchical addressing, it might look something like the following:

At Core Router A you manually summarize the address space of 10.2.1.0 to 10.2.50.0 as 10.2.0.0/16 and propagate route 10.2.0.0 /16 to Core Router B. You can perform similar summarization techniques on Core Routers B and C.

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, 10.2.1.0, is not in its routing table, it responds with an infinite metric and does not send any more queries.



Summarization can serve to reduce the query radius of an EIGRP domain, which reduces the occurrence of SIA events.

Default Routes and EIGRP Stub Routing

While you are unlikely to be asked to configure a default route in the CCIE lab, it may come up either on the written exam or in real life. You can use the IGRP method of using an ip default-network command, but it is generally preferable to create a static route to 0.0.0.0/0 and redistribute it into EIGRP. Redistributed static routes are more precise than using default-networks, and have a faster internal lookup time.

EIGRP Stub Routing can be deployed to reduce the number of queries and responses propagated through the network. EIGRP stub routing reduces query/response activity, as queries are not propagated to stub routers.

This is a more scaleable option than the strict use of default routes and Stub Routing provides more flexibility for route propagation and control. Stub routing is configured on the remote stub router with the following router level command:

RouterA(config)# router eigrp 1 RouterA(config-router)# stub {connected | static | summary | receive-only}

EIGRP in NBMA Networks

Non-broadcast multi-access networks are problematic for routing protocols, including EIGRP. Examples of NBMA networks that can offer issues for deploying EIGRP are ATM, Frame Relay, and X.25. The most commonly experienced issues when configuring EIGRP over NBMA networks are:

Spoke to spoke connectivity issues in a hub and spoke environment

Congestion issues.

Spoke to Spoke Connectivity

The following network topology represents a hub and spoke environment.

In this example, routes from LAN 1 are propagated to the Hub Router, but upon examination of the routing table of Router 2; it appears that the Hub Router does not pass these routes to Router 2. This



is, in fact, correct operational behavior for EIGRP. The reason for this is the commonly overlooked loop avoidance technique of split horizon. Split horizon is the concept of not advertising a route back out the interface it came in. In NBMA networks, single interfaces are generally used to connect to multiple remote sites. Generally split horizon issues stem from poor network design.

There are many ways to solve this problem, however the three most common techniques are:

Disable split horizon. The command no ip split-horizon eigrp is used to disable split horizon in EIGRP. This is not a recommended method of resolving spoke-to-spoke connectivity issues, however, due to the possibility of introducing routing loops into the network.

Enable the use of static routes or default routes on the spoke routers. Static routes are added via the ip route command, and default routes are added via the ip default network command. Care needs to be taken that static or static default routes are not inadvertently leaked into the routing domain.

The final, most common, practice of overcoming EIGRP spoke-to-spoke connectivity issues is by making use of point-to-point sub-interfaces. This is perhaps the most cumbersome method of resolving split-horizon issues, but as we will see in the next section, the use of point-to-point sub-interfaces can also resolve other common EIGRP issues.

EIGRP Congestion Issues

In this section, we will identify several NBMA congestion problems and provide some common resolutions to these issues.

NBMA networks tend to terminate many circuits from many destinations on a single router or node. This will result in an EIGRP-enabled router forming neighbor relationships with many other routers. The need to have many neighbor relationships can lead to resource issues on a router, particularly CPU usage.

Problem Solution

Routing updates originating from the hub site are causing congestion on the relatively low speed links to the spoke sites.

EIGRP has a configuration option that allows you to adjust the percentage of bandwidth that EIGRP will use when sending updates or hellos. Using the interface configuration command ip bandwidth percent eigrp modifies this. Please note that this command uses the value configured on the interface via the bandwidth command. It is crucial that this command be used on all interfaces, particularly serial interfaces.

Hello packets being sent simultaneously to a large number of neighbors resulting in output queue drops

This problem can be resolved in several ways:

Use the hold queue out command to increase the size of the output queue, or Use point-to-point interfaces with varying hello timers Over Frame Relay links, the frame relay broadcast queue interface configuration command allows you to create a separate, additional output queue for broadcast packets.

Point-to-point links seem to become more saturated than other interfaces.

As you will recall, EIGRP has differing default hello timers on different media. On point-to-point links (regardless of bandwidth), the default hello timer is 5 seconds. This is in stark contrast with the default hello timer of 60 seconds on low speed WAN links. To resolve this issue, the hello timer can be increased on the congested links. However, it should be noted that convergence time would be increased in line with this.



In the SIA section of this tutorial, we saw an example of how a topology change coupled with a congested link led to a major SIA event. That is why it is critical that all congestion issues are addressed as soon as diagnosed in an EIGRP environment. What may be a small amount of congestion at some point in time can easily result in major congestion issues when there is a topology change. Prevention, as always, is better than the cure.

Basic EIGRP Configuration Configuring a basic EIGRP setup is a trivial task. This is one of the strengths of EIGRP. The following output shows the basic commands required to configure classful EIGRP:

config)# router eigrp AS_number (config-router)# network ip_network

The following diagram shows a sample network topology and the necessary configuration commands required to enable EIGRP for this network. It also reveals how easy EIGRP is to configure.

As with configuring any IGP on a Cisco router, the network command is used to enable the routing protocol on any interface configured within that network space. To determine what interfaces are participating in EIGRP use the show ip eigrp interfaces command.

RouterA#sh ip eigrp interfaces 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

Not only does this command show which interfaces are configured for EIGRP, it also shows how many neighbors or peers are on each interface. To discover information relating to the peers, use the show ip protocols command.

RouterA>show ip protocols 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

Classful Autosummarization

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.

If you add the no auto-summary command, EIGRP will not auto-summarize at classful boundaries, but will advertise all subnets.

Classless Configuration

IOS release 12.0(4)T added the option of placing wildcard bits to identify specific subnets to be included in the EIGRP process (and in turn subnets to be excluded). The stability of this feature in early 12.0 IOS trains is rather dubious, however, and is not recommended unless later revisions of IOS are deployed (12.1 and higher).

Additional EIGRP Features

EIGRP Load Balancing -- Equal Path

By default, EIGRP load balances over a maximum of 4 equal-cost links. This default can be changed to a maximum of 6 paths with the command maximum-paths under the EIGRP process. Let's look at a simple case of a router with two equal metric paths to a destination.

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.

Unequal Cost Load Balancing



EIGRP also supports unequal-cost load balancing with the variance command. Consider the following network.

Router A has two paths to LAN 1. However, since the metrics are not equal, only one path will be used. This is the path through Router C. However, you can use the command variance to cause EIGRP to share the load over the two links as though they were equal cost. Configuring EIGRP unequal cost load balancing will be discussed in more depth in the Common EIGRP Configuration Tasks Section of this Tutorial.

There are a few aspects to consider about unequal-cost load balancing.

1. 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).

2. By default, the load balancing is 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 command.

3. Traffic will be load balanced across up to six paths, if they all fall within the variance. This number can be modified, though, with the maximum-paths command. By default, EIGRP will use up to 4 maximum paths.

4. Only the best route will appear in the routing table. You will not see the other routes. This route can be viewed by issuing the show ip route command.

Summarization

EIGRP is fairly CPU- and memory-intensive. It gets particularly resource hungry during link failure conditions. It is possible to overload the largest of CPUs with EIGRP processing alone. Route summarization is one of the tools provided to relieve some of this burden.

Observe the following network. Two major (10.0.0.0 /8 and 172.16.0.0 /16) networks in the same Autonomous System meet at Router D:



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 the perspective of Router Z:

RouterZ#show 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

Quite clearly, this is an inefficient routing table. Routers X, Y, and Z in this example 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#show 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

Route summarization can be automatic or manual.

Automatic Summarization

Route summarization is enabled by default on Cisco routers. The process works as follows:

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 entered into 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.

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 will have a single route to 172.16.0.0/16 in their routing tables via Router D.

Routers X, Y, and Z will have a single route to 10.0.0.0/8 in their routing tables again via Router D.

Full connectivity is established with a minimum of routes.

Problems with Auto Summarization

Automatic summarization does not always work well. For example, reexamine the network above. Suppose the network administrator decides that a 10/8 subnet is needed off Router Y, as shown in the figure below.



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 as well! 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?

Viewing the routing table on Router Y provides some insight.

RouterY>show 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 summarizes the 10.0.0.0 network and points it to NULL0. It is then sends this route to its neighbors. Looking at the topology database on Router Z confirms this.

RouterZ>show ip eigrp topology 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 cause of this problem is that these subnets are not contiguous. Auto summarization does not support non-contiguous 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, manual summarization provides stricter control and solves the problem of non-contiguous subnets. Manual summarization consists of two configuration tasks.

Disable automatic summarization: This is done in router configuration mode with the no auto-summary command:

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

Manually summarize on a per-interface basis: This is performed in interface configuration mode. You configure the summary address that you want advertised from the interface. Only the summary network configured will be advertised, and all subnets within that summary will be suppressed. It is crucial to remember that manual summarization of EIGRP is configured on a per interface basis, unlike other IGPs.

(config)# interface interface (config-router)# ip summary-address eigrp AS_number network mask

Manual summarization works like automatic summarization in that a route for the summarized network pointing to the NULL0 interface is inserted into the routing table. This route is then distributed to the neighbors.

Following is the sample network that we used for our automatic summarization example.

The following configuration can be used to disable automatic summarization and enable manual summarization.

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. There is no change from auto summarization as there are no non-contiguous subnets. A summary route to 10.1.0.0 /24 is sent to Router X. In this manner, it is possible for the 10.2.1.0 route to coexist in that network. Auto summarization must, of course, be disabled on Router Y for this to work.

The resulting routing table on Router Y is below.

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.

Authentication

Since Cisco IOS version 11.3, EIGRP has provided support for MD5 authentication of updates and hellos between neighbors. Authentication is configured on a per interface basis and makes use of the MD5 hashing algorithm. Configuring authentication on an interface does not require its use with all neighbors, except when the neighbors are on a shared media, such as Ethernet.

EIGRP does not provide the option of configuring clear-text authentication between neighbors and some argue that this is less flexible than RIPv2 or OSPF, which do allow for this form of authentication. However, RIPv2 and OSPF only allow for clear text authentication to ensure operability with other vendor's implementations of these protocols. MD5 authentication is always recommended due to its higher level of security. Obviously, EIGRP does not need to concern itself with other vendor inter-operability, as EIGRP is a Cisco-proprietary protocol and will be configured only on Cisco devices.

Configuration of neighbor authentication is performed with the use of key-chains and a sample



configuration is provided in the configuration section.

Bandwidth Use

By default, EIGRP will use a maximum of 50% of the configured bandwidth of an interface. It is critical for proper EIGRP operation to the set the correct interface bandwidth via the bandwidth command. An example is in order here to highlight how not setting the correct bandwidth can cause EIGRP to function incorrectly.

Assume that we have a standard serial interface running HDLC but that it is being provided clocking from a DCE device at 64 kbps. The network operator configuring this link forgets that the default bandwidth of a serial interface is 1.544 Mbps and thus does not use the bandwidth 64000 statement on the serial interface. EIGRP will attempt to use 0.5 * 1544 (772 kbps), higher than the capacity of the link. Thus, EIGRP operation could potentially saturate this link.

It is important to get into the habit of configuring the correct interface bandwidth when deploying EIGRP. This is, in fact, an excellent practice even if you are not working with EIGRP.

The default bandwidth that EIGRP will attempt to use can be modified via the ip bandwidth-percent eigrp.

Common EIGRP Configuration Tasks Several configuration examples have been provided in this Tutorial so far. This section of the Tutorial is intended to provide some configuration information for some of the more common scenarios.

Equal cost load balancing

By default, EIGRP supports equal cost load balancing and will use up to 4 paths if equal. This can be modified by using the maximum-paths x statement under the EIGRP process. The maximum number of paths that can be load balanced is 6. In the following diagram, there are two equal paths to PC1.

In this scenario, there is no need for any additional configuration commands to allow EIGRP to share traffic across both paths. The command maximum-paths 1 can be used to disable load balancing.

Unequal cost load balancing

EIGRP also supports unequal cost load balancing.



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:

RouterA(config)# router eigrp AS_number RouterA(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.

Running multiple EIGRP processes

It is possible to run multiple EIGRP process on a singe router by specifying a different autonomous system number for each instance of EIGRP. There are a few reasons that more than one process may be required on a single router including integrating previously separate networks, security considerations, and redistribution requirements. Although it is possible and may be required, running multiple instances of EIGRP on a single router should be seen as an interim solution and should not be used as a long-term strategy.

In the event that it is necessary to run multiple EIGRP processes, the following configuration can be used.

RouterA(config)#router eigrp 1 RouterA(config-router)#network x.x.x.x RouterA(config-router)#exit RouterA(config)#router eigrp 2 RouterA(config-router)#network y.y.y.y

Note that the AS numbers have been used here are for indicative purposes only and will not necessarily reflect your topology.

Configuring EIGRP Unicast Neighbors

EIGRP uses a multicast mechanism for sending hellos and updates to neighbors. In some situations, it may be necessary to configure EIGRP hellos and updates to be sent via unicast packets instead. This is quite simple to configure and makes use of the neighbor command under router configuration mode. An example of configuring the EIGRP unicast neighbor feature is below.

RouterA(config)#router eigrp 1 RouterA(config-router)#network x.x.x.x RouterA(config)#neighbor a.b.c.d

For example, unicast neighbors would be required when deploying EIGRP across media with no support



for multicast delivery, or where the Network Administrator wishes to reduce the number of multicast packets to a network.

Configuring EIGRP Neighbor Authentication

One of the enhancements of EIGRP over IGRP is that EIGRP supports MD5 authentication between neighbors. MD5 is an encrypting hash algorithm. In the event that secure neighbor relationships are required in EIGRP, the following is a sample of how to configure authentication.

RouterA(config-int)ip authentication mode eigrp 1 md5 RouterA)config-int)ip authentication key-chain eigrp 1 certzone RouterA(config-int)exit RouterA(config)key chain certzone RouterA(config-keychain)key 1 RouterA(config-keychain-k)key-string test RouterA(config-keychain-k)accept-lifetime infinite RouterA(config-keychain-k)send-lifetime infinite

The value in the key-string must match on all routers that are configured for EIGRP authentication. Key chains are quite powerful and there are several other configuration options, ranging from expiring keys to pre-set start dates and times that have not been discussed here.

Protocol Redistribution

Overview of Redistribution

It is quite common, if not ideal, for a number of different routing protocols to be operational across a network. The following sections discuss how to configure redistribution between EIGRP and other IGPs and EGPs. First, we will review the principles of redistribution.

One of the first concepts that must be understood when discussing or configuring redistribution is that of administrative distance. Administrative Distance can be described as the "believability" of a routing protocol. The routing protocol with the lowest AD is preferred. If a router receives a routing update from two different routing protocols with two different ADs, the router will install the route learned via the protocol with the lower AD into the main routing table that. The following table shows some of the common default ADs on Cisco routers.

Table 6. Administrative Distances

Protocol Administrative Distance

Directly Connected 0

Static Routes 1

EIGRP (internal) 90

IGRP 100

OSPF 110

IS-IS 115

RIP 120

EIGRP (external) 170



Although the table above illustrates the default Administrative Distances, it should be noted that these defaults can be modified by using the distance command under the appropriate routing process.

A further note is that Administrative Distance is taken into consideration prior to any metric calculations on the receiving router and hence it is possible for a router to install a route into the main routing table that has a better Administrative Distance but a worse metric or path to the destination. This is common when multiple routing protocols are deployed and each uses different metrics.

You may have noticed that EIGRP actually has two ADs: internal and external. Internal EIGRP routes are those that are contained within the EIGRP Autonomous System and external routes are those that are learned from outside the Autonomous System. The reason for the higher AD value for external routes is that EIGRP assumes that these routes were introduced into the EIGRP domain via some external mechanism (i.e. redistribution) and hence may not be as reliable as those routes learned internally.

The following output details how to learn the AD of routes received by a router.

router#show 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 the highlighted values. The metrics are the number that appears directly after the AD.

Redistribution between EIGRP Autonomous Systems

We have seen previously that it is possible, and sometimes required (however not recommended) to run multiple EIGRP processes on a router in different Autonomous Systems. Redistributing between two EIGRP ASs is accomplished with the following commands.

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

AS1 is the AS that you are redistributing into and AS2 is the AS you are redistributing from.

When redistributing it is important to realize that auto summarization does not occur.

Unknown 255



Automatic and manual redistribution between IGRP and EIGRP

There are two methods of redistributing between IGRP and EIGRP, depending on whether or not the two routing domains have the same AS number. The following diagram illustrates automatic redistribution between IGRP and EIGRP. Note that both routing domains are using the same AS number of 90:

Redistribution will occur automatically with no additional configuration commands required. Metrics between the two routing domains are preserved since IGRP and EIGRP make use of the same composite metric, albeit EIGRP multiplies the metric by 256. No automatic summarization takes place.

The following output from Router D highlights automatic redistribution. Please take particular note of the AD of the routes and also the fact that automatic summarization does not occur.

RouterD>show 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/16 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/8 IS SUBNETTED, 1 SUBNETS C 10.1.16.0 IS DIRECTLY CONNECTED, SERIAL0/0

The second method of redistributing between IGRP and EIGRP is used when the two routing domains have different AS numbers. It is called manual redistribution, as it requires additional configuration. Note that in the following diagram the AS number in the IGRP domain is 100 and in the EIGRP domain it is 90:

Metrics are preserved when redistributing between IGRP and EIGRP. The following configuration is all that is required on Router C to enable manual redistribution



router eigrp 90 redistribute igrp 100 network 10.0.0.0 ! router igrp 100 redistribute eigrp 90 network 172.16.0.0

Redistribution between other IGPs

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

RouterA(config)# router eigrp AS1 RouterA(config-router)# redistribute protocol [process_id]

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. RIP, for example, uses hop count as its metric, but EIGRP does not understand this metric. What metric should EIGRP assign to a route learned from another protocol? There are two ways of answering this question.

1. Assign a metric for all routes from a particular protocol. Assigning the metric via the redistribute command accomplishes this. All routes from that redistributed protocol will receive this metric. The syntax of the redistribute command is as follows:

RouterA(config)# router eigrp AS1 RouterA(config-router)# redistribute protocol metric bandwidth delay reliabilit

The above 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 configuration 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 the diagram above:

router eigrp 90 network 10.0.0.0



default-metric 100000 100 255 1 1500 ! router ospf network 172.16.0.0

When redistribution is carried out without assigning an appropriate metric, EIGRP differs vastly from OSPF. If a route is redistributed into OSPF with a metric that OSPF does not understand, it will, by default, assign the redistributed route a metric of 20. Other IGPs assign a metric of 0. ISIS is the only IGP implemented by Cisco that understands a metric of 0. RIP and IGRP do not understand the 0 metric and will not function. Assigning a metric when redistributing via either of the above methods is absolutely critical.

Redistribution between EIGRP and BGP

Redistribution from an EGP such as BGP into any IGP is not recommended practice due to the size of today's BGP tables. BGP is designed to handle very large routing tables, whereas IGPs are not generally designed to handle tables that large. In the event that redistribution is required, the syntax is no different from redistributing from IGPs into EIGRP.

If this form of redistribution is used, careful attention must be made to filtering these redistributed routes. If the full BGP routing table, 100,000 plus routes, were redistributed into an EIGRP process, it would overwhelm the router's resources and might well result in a crash.

Conclusion This Tutorial has provided an overview of the operation and mechanics of Cisco's proprietary routing protocol EIGRP. EIGRP is often compared with link state routing protocols such as OSPF and less often with ISIS. The main advantage of EIGRP over OSPF and ISIS is its ease of configuration. This ease of configuration, however, does not automatically define EIGRP as the routing protocol of choice, especially for large-scale networks.

That said, EIGRP can scale to large network topologies, however some of its inherent issues, particularly SIA, and the fact that many Network Administrators do not pay the same attention to hierarchical design mean that EIGRP may not scale as well as other protocols. There are also concerns that EIGRP will not interoperate with non-Cisco equipment. With the movement of IPX and Apple to IP transports, the integrated protocol capability of EIGRP becomes less important, although still may be very helpful in some enterprises.

A number of practices must be observed when deploying EIGRP for large-scale network topologies. The first is that EIGRP, like OSPF and ISIS, should be treated as a hierarchical routing protocol. Furthermore, the scope of EIGRP queries should be limited; the number of router dependencies in the network should be minimized; addressing schemes should be contiguous and allow for summarization; and there should also be, where possible, multiple paths to destinations for redundancy. All these practices are generally taken into account with protocols such as OSPF and ISIS. However, they are often neglected when deploying EIGRP.

Many people speak of convergence times and router resource requirements when comparing IP routing protocols; however, this can be quite biased towards one routing protocol depending on the design of the network the protocol is implemented in. Convergence times in EIGRP compared to OSPF and ISIS tend to be much faster when there is a feasible successor for a route, however if DUAL is invoked convergence times tend to favor OSPF, particularly in situations where the alternate route is some distance away from the converging router.

EIGRP generally uses less memory than OSPF overall, however from a pure route storage perspective, OSPF uses approximately 146 bytes per route, whereas EIGRP requires approximately 193 bytes of memory. The argument of whether link state protocols or EIGRP consume more CPU cycles again



comes down to design considerations; generally speaking EIGRP maintains a constant, relatively low CPU load, whereas when Dijkstra is invoked in link state protocol topology changes, there tends to be short bursts of quite significant CPU utilization. Another way of describing this is that when a network is converged and there are no topology changes, EIGRP requires slightly more CPU resources to operate than link state protocols. When there is a topology change (particularly if EIGRP has a feasible successor to the destination), the CPU load is often greater with link state protocols.

No IGP scales well, even when implementing hierarchical design, beyond 1000 to 2000 routers. In networks of this scale, thought should be given to deploying a set of IGP domains that are linked via a 'backbone of backbones'. BGP is the most common option for this; however, in certain cases the use of static routes, with judicious use of floating static routes for redundancy, may also provide a reliable solution.

With all this in mind, EIGRP can operate well in large-scale topologies, provided careful attention is paid in the design stages and the above factors must always be considered. Generally, when an EIGRP implementation does not operate as well as expected, it is not due to EIGRP per se, it is more that proper design methods have not been followed and a poor network design has been deployed.

References and Recommended Reading [Dijkstra1980] E.W. Dijkstra & C.S. Scholten. "Termination detection for diffusing computations," Information Processing Letters, 11(1), 1980. http://www.cse.ucsc.edu/research/ccrg/publications/jj.dual.ton93.pdf

[Garcia-Luna-Alceves] Website for JJ Garcia-Luna-Alceves, http://www.cse.ucsc.edu/~jj/

[Garcia-Luna-Alceves1993] J.J. Garcia-Luna-Alceves. "Loop-free Routing using Diffusing Computations," IEEE/ACM Transactions on Networking, 1(1), February 1993. http://www.cse.ucsc.edu/research/ccrg/publications/jj.dual.ton93.pdf

[Retana1999] Retana, A., White, R., Slice, D. CCIE Professional Development: Advanced IP Network Design. Cisco Press, 1999.

[Retana2000] Retana, A., White, R., Slice, D. EIGRP for IP: Basic Operation and Configuration. Addison-Wesley, 2000.

[Zinin2002] Zinin, A. Cisco IP Routing: Packet Forwarding and Intradomain Routing Protocols. Addison-Wesley, 2002.

[IE-EIGRP-WP2-F03] [2002-09-30-01]



eigrp.v2 (2)

Documents

eigrp redistribution

eigrp stub routing eigrp

eigrp unicast neighbors

link failures eigrp

linkstate protocol

multiple eigrp processes

eigrp queryresponse

eigrp decision process