Semestre 1 CCNP, Módulo 5

Module 5: EIGRP

Overview

Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco-proprietary routing protocol based on IGRP. Unlike IGRP, which is a classful routing protocol, EIGRP supports CIDR, allowing network designers to maximize address space by using CIDR and VLSM. Compared to IGRP, EIGRP boasts faster convergence times, improved scalability, and superior handling of routing loops.

EIGRP has been described as a hybrid routing protocol offering the best of distance vector and link-state algorithms. Technically, EIGRP is an advanced distance vector routing protocol that relies on features commonly associated with link-state protocols. The best traits of OSPF, such as partial updates and neighbor discovery, are similarly used by EIGRP. However, some benefits of OSPF, especially its hierarchical design, come at the price of administrative complexity. Multiarea implementation of OSPF requires mastery of a complex terminology and command set. Yet, the advanced features of EIGRP can be easily implemented and maintained. Although it does not mirror the classic hierarchical design of OSPF, EIGRP is an ideal choice for large, multiprotocol networks build primarily on Cisco routers.

This module surveys the key concepts, technologies, and data structures of EIGRP. This conceptual overview is then followed by a study of EIGRP convergence and basic operation. Finally, this module shows how to configure and verify EIGRP and the use of route summarization.

5.1 EIGRP Fundamentals

5.1.1 EIGRP and IGRP compatibility

Cisco released EIGRP in 1994 as a scalable, improved version of its proprietary distance vector routing protocol, IGRP. IGRP and EIGRP are compatible with each other, although EIGRP offers multiprotocol support and IGRP does not.

Despite being compatible with IGRP, EIGRP uses a different metric calculation and hop-count limitation. EIGRP scales the IGRP metric by a factor of 256. That is because EIGRP uses a metric that is 32-bits long, and IGRP uses a 24-bit metric. By multiplying or dividing by 256, EIGRP can easily exchange information with IGRP.

EIGRP also imposes a maximum hop limit of 224, which is slightly less than the 255 limit for IGRP. However, this is more than enough to support most of the largest internetworks.

Getting dissimilar routing protocols, such as OSPF and RIP, to share information requires advanced configuration. However, sharing or redistribution, is automatic between IGRP and EIGRP as long as both processes use the same autonomous system (AS) number. In Figure , RTB automatically redistributes routes learned by EIGRP to the IGRP AS, and vice versa.

EIGRP will tag routes learned from IGRP, or any outside source, as external because they did not originate from EIGRP routers. On the other hand, IGRP cannot differentiate between internal and external routes. Notice that in the show ip route command output, EIGRP routes are flagged with D, and external routes are denoted by EX. RTA identifies the difference between the network learned via EIGRP (172.16.0.0) and the network redistributed from IGRP (192.168.1.0). RTCs table shows that IGRP makes no such distinction.

RTC, which is running IGRP only, sees only IGRP routes, despite the fact that both 10.1.1.0 and 172.16.0.0 were redistributed from EIGRP.

5.1.2 EIGRP design

Even though EIGRP is compatible with IGRP, it operates quite differently than its predecessor. As an advanced distance vector routing protocol, EIGRP acts like a link-state protocol when updating neighbors and maintaining routing information. The advantages of EIGRP over simple distance vector protocols include the following:

* Rapid convergence – EIGRP routers converge quickly because they rely on a state-of-the-art routing algorithm called the Diffusing Update Algorithm (DUAL). DUAL guarantees loop-free operation at every instant during route computation and allows all routers involved in a topology change to synchronize at the same time.
* Efficient use of bandwidth – EIGRP makes efficient use of bandwidth by sending partial, bounded updates and it consumes minimal bandwidth when the network is stable.
o Partial, bounded updates – EIGRP routers make partial, incremental updates rather than sending their complete tables. This is similar to OSPF operation. However, unlike OSPF routers, EIGRP routers send these partial updates only to the routers that need the information. They do not send to all routers in an area. For this reason, they are called bounded updates.
o Minimal consumption of bandwidth when the network is stable – EIGRP does not use timed routing updates. Instead, EIGRP routers keep in touch with each other using small hello packets. Though exchanged regularly, hello packets do not use a significant amount of bandwidth.
* Support for VLSM and CIDR – Unlike IGRP, EIGRP offers full support for classless IP addressing by exchanging subnet masks in routing updates.
* Multiple network-layer support – EIGRP supports IP, IPX, and AppleTalk through protocol-dependent modules (PDMs).
* Independence from routed protocols – PDMs protect EIGRP from painstaking revision. Evolution of a routed protocol, such as IP, may require a new protocol module, but not necessarily a reworking of EIGRP itself.

5.2.1 EIGRP technologies

EIGRP includes many new technologies. Each of these represents an improvement in operating efficiency, rapidity of convergence, or functionality relative to IGRP and other routing protocols. These technologies fall into one of the following four categories:

* Neighbor discovery and recovery
* Reliable Transport Protocol
* DUAL finite-state machine
* Protocol-specific modules

The following sections examine these technologies in detail.

5.2.2 Neighbor discovery and recovery

Remember that simple distance vector routers do not establish any relationship with their neighbors. RIP and IGRP routers merely broadcast or multicast updates on configured interfaces. In contrast, EIGRP routers actively establish relationships with their neighbors, much the same way that OSPF routers do.

EIGRP routers establish adjacencies with neighbor routers by using small hello packets. – Hellos are sent by default every five seconds. An EIGRP router assumes that as long as it is receiving hello packets from known neighbors, those neighbors (and their routes) remain viable. By forming adjacencies, EIGRP routers do the following:

* Dynamically learn of new routes that join their network
* Identify routers that become either unreachable or inoperable
* Rediscover routers that had previously been unreachable

5.2.3 Reliable transport protocol

Reliable Transport Protocol (RTP) is a proprietary transport-layer protocol that can guarantee ordered delivery of EIGRP packets to all neighbors. On an IP network, hosts use TCP to sequence packets and ensure their timely delivery. However, EIGRP is protocol-independent. Therefore, EIGRP does not rely on TCP/IP to exchange routing information the way that RIP, IGRP, and OSPF do. To stay independent of IP, EIGRP uses its own proprietary transport-layer protocol, Reliable Transport Protocol (RTP) to guarantee delivery of routing information.

EIGRP can call on RTP to provide reliable or unreliable service as the situation warrants. For example, hello packets do not require the overhead of reliable delivery because they are frequent and should be kept small. The reliable delivery of other routing information can actually speed convergence because EIGRP routers are not waiting for a timer to expire before they retransmit.

With RTP, EIGRP can multicast and unicast to different peers simultaneously, allowing for maximum efficiency.

5.2.4 DUAL finite-state machine

The focal point of EIGRP is the Diffusing Update Algorithm (DUAL). This is the route-calculation engine of EIGRP. The full name of this technology is DUAL finite-state machine (FSM). An FSM is an abstract machine, not a mechanical device with moving parts. FSMs define a set of possible states that something can go through, what events cause those states, and what events result from those states. Designers use FSMs to describe how a device, computer program, or routing algorithm will react to a set of input events. The DUAL FSM contains all the logic used to calculate and compare routes in an EIGRP network.

DUAL tracks all the routes advertised by neighbors in addition to using the composite metric of each route to compare them. DUAL also guarantees that each path is loop-free. Lowest-cost paths are then inserted by DUAL into the routing table.

As noted earlier in the module, EIGRP keeps important route and topology information readily available. This information is stored in a neighbor table and a topology table. These tables supply DUAL with comprehensive route information in case of network disruption. DUAL selects alternate routes quickly by using the information in these tables. If a link goes down, DUAL looks for a feasible successor in its neighbor and topology tables.

A successor is a neighboring router that is currently being used for packet forwarding. A successor also provides the least-cost route to the destination and is not part of a routing loop. Feasible successors provide the next lowest-cost path without introducing routing loops. Feasible successor routes can be used in case the existing route fails. Packets to the destination network are immediately forwarded to the feasible successor. The router is then promoted to the status of successor. – .

Note in the example that router D does not have a feasible successor identified. The feasible distance (FD) for router D to router A is 2 and the advertised distance (AD) by way of router C is 3. Because the AD is greater than the FD, no feasible successor is placed in the topology table. Router C has a feasible successor identified because the AD from Router D is less than the FD. Router E does not have a feasible successor because the AD from Router C is equal to the FD.

5.2.5 Protocol-dependent modules

The modular design is one of the most attractive features of EIGRP. Modular designs prove to be the most scalable and adaptable. Support for routed protocols such as IP, IPX, and AppleTalk is included in EIGRP through protocol-dependent modules (PDMs). In theory, EIGRP can easily adapt to new or revised routed protocols by adding protocol-dependent modules.

Each PDM is responsible for all functions related to its specific routed protocol. The IP-EIGRP module is responsible for the following:

* Sending and receiving EIGRP packets that bear IP data
* Notifying DUAL of new IP routing information that is received
* Maintaining the results of DUAL routing decisions in the IP routing table
* Redistributing routing information that was learned by other IP-capable routing protocols

5.3.1 EIGRP packet types

Like OSPF, EIGRP relies on several different kinds of packets to maintain its various tables and establish complex relationships with neighbor routers. The five EIGRP types are listed as follows:

* Hello
* Acknowledgment
* Update
* Query
* Reply

The following sections describe these packet types in detail.

Hello Packets
EIGRP relies on hello packets to discover, verify, and rediscover neighbor routers. Rediscovery occurs if EIGRP routers do not receive each other's hellos for a hold time interval but then reestablish communication.

EIGRP routers send hellos at a fixed and configurable interval, called the hello interval. The default hello interval depends on the bandwidth of the interface.

EIGRP hello packets are multicast. On IP networks, EIGRP routers send hellos to the multicast IP address 224.0.0.10.

An EIGRP router stores information about neighbors in the neighbor table, including the last time that each neighbor responded. The information will only be stored if any of its EIGRP packets, hello or otherwise, is received. If a neighbor is not heard from for the duration of the hold time, EIGRP considers that neighbor down, and DUAL must step in to reevaluate the routing table. By default, the hold time is three times the hello interval, but an administrator can configure both timers as desired.

Recall that OSPF requires neighbor routers to have the same hello and dead intervals to communicate. EIGRP has no such restriction. Neighbor routers learn about each other's respective timers through the exchange of hello packets. They use that information to forge a stable relationship, unlike timers.

Acknowledgment Packets
An EIGRP router uses acknowledgment packets to indicate receipt of any EIGRP packet during a reliable exchange. Recall that RTP can provide reliable communication between EIGRP hosts. To be reliable, a sender's message must be acknowledged by the recipient. Acknowledgment packets, which are dataless hello packets, are used for this purpose. Unlike multicast hellos, acknowledgment packets are unicast. Acknowledgments can also be made by piggybacking on other kinds of EIGRP packets, such as reply packets.

Hello packets are always sent unreliably and therefore do not require acknowledgment.

Update Packets
Update packets are used when a router discovers a new neighbor. An EIGRP router sends unicast update packets to that new neighbor so that the new router can add to its topology table. More than one update packet may be needed to convey all the topology information to the newly discovered neighbor.

Update packets are also used when a router detects a topology change. In this case, the EIGRP router sends a multicast update packet to all neighbors, alerting them about the change.

All update packets are sent reliably.

Query and Reply Packets
EIGRP routers use query packets whenever it needs specific information from one or all of its neighbors. A reply packet is used to respond to a query.

If an EIGRP router loses its successor and cannot find a feasible successor for a route, DUAL places the route in the active state. At this point, the router multicasts a query to all neighbors, searching for a successor to the destination network. Neighbors must send replies that either provide information on successors or indicate that no successor information is available.

Queries can be multicast or unicast, while replies are always unicast. Both packet types are sent reliably.

5.3.2 EIGRP tables

DUAL can select alternate routes based on the tables kept by EIGRP. By building these tables, every EIGRP router can track all the routing information in an AS, not just the best routes.

The following sections examine the neighbor table, the routing table, and the topology table in detail and provide an example of each. In addition, the various packet types used by EIGRP to build and maintain these tables will be investigated.

The Neighbor Table
The most important table in EIGRP is the neighbor table. The neighbor relationships tracked in the neighbor table is the basis for all the EIGRP routing update and convergence activity.

The neighbor table contains information about adjacent neighboring EIGRP routers. Whenever a new neighbor is discovered, the address of that neighbor and the interface used to reach it are recorded in a new neighbor table entry.

A neighbor table is used to support reliable, sequenced delivery of packets. One field in each row of the table includes the sequence number of the last packet received from that neighbor. EIGRP uses this field to acknowledge a neighbor's transmission and to identify packets that are out of sequence.

An EIGRP neighbor table includes the following key elements:

* Neighbor address (Address) – The network layer address of the neighbor router.
* Hold time (Hold Uptime) – The interval to wait without receiving anything from a neighbor before considering the link unavailable. Originally, the expected packet was a hello packet. However, in current Cisco IOS software releases, any EIGRP packets received after the first hello will reset the timer.
* Smooth Round-Trip Timer (SRTT) – The average time that it takes to send and receive packets from a neighbor. This timer is used to determine the retransmit interval (RTO).
* Queue count (Q Cnt) – The number of packets waiting in queue to be sent. If this value is constantly higher than zero, then there may be a congestion problem at the router. A zero means that there are no EIGRP packets in the queue.

Note that an EIGRP router can maintain multiple neighbor tables, one for each PDM running, for example, IP, IPX, and AppleTalk. A router must run a unique EIGRP process for each routed protocol.

5.3.3 EIGRP tables (continued)

The Topology Table
EIGRP uses its topology table to store all the information it needs to calculate a set of distances and vectors to all reachable destinations. EIGRP maintains a separate topology table for each routed protocol.

The topology table is made up of all the EIGRP routing tables in the autonomous system. By tracking this information, EIGRP routers can find alternate routes quickly. The topology table includes the following fields:

* Feasible distance (FD is xxxx) – The feasible distance (FD) is the lowest calculated metric to each destination. In Figure , the feasible distance to 32.0.0.0 is 2195456 as indicated by FD.
* Route source (by way of xxx.xxx.xxx.xxx) – The source of the route is the identification number of the router that originally advertised that route. This field is populated only for routes learned externally from the EIGRP network. Route tagging can be particularly useful with policy-based routing. In Figure , the route source to 32.0.0.0 is 200.10.10.10 through 200.10.10.10.
* Reported distance (FD/RD) – The reported distance (RD) of the path is the distance reported by an adjacent neighbor to a specific destination. In Figure , the reported distance to 32.0.0.0 is 281600 as indicated by 2195456/281600.

In addition to these fields, each entry includes the interface through which the destination is reachable.

EIGRP sorts the topology table so that the successor routes are at the top, followed by feasible successors. At the bottom, EIGRP lists routes that DUAL believes to be loops in the topology table.

How does an EIGRP router determine which routers are successors and which routers are feasible successors? Assume that the routing table for RTA includes a route to Network Z through RTB. From the point of view of RTA, RTB is the current successor for Network Z. RTA will forward packets destined for Network Z to RTB. RTA must have at least one successor for Network Z for DUAL to place it in the routing table.

Can RTA have more than one successor for Network Z? IIf RTC claims to have a route to Network Z with the exact same metric as RTB, then RTA also considers RTC a successor. DUAL will then install a second route to Network Z through RTC.

Any of the other neighbors of RTA, that advertise a loop-free route to Network Z will be identified as feasible successors in the topology table. However, they must have a higher than best-route metric and lower than FD.

A router views its feasible successors as neighbors that are downstream, or closer, to the destination than it is. If something goes wrong with the successor, DUAL can quickly identify a feasible successor from the topology table and install a new route to the destination. If no feasible successors to the destination exist, DUAL places the route in the active state. Entries in the topology table can be in one of two states: active or passive. These states identify the status of the route indicated by the entry rather than the status of the entry itself.

A passive route is one that is stable and available for use. An active route is a route in the process of being recomputed by DUAL. Recomputation happens if a route becomes unavailable and DUAL cannot find any feasible successors. When this occurs, the router must ask neighbors for help in finding a new, loop-free path to the destination. Neighbor routers are compelled to reply to this query. If a neighbor has a route, it will reply with information about the successor(s). If not, the neighbor notifies the sender that it does not have a route to the destination either.

Excess recomputation is a symptom of network instability and results in poor performance. To prevent convergence problems, DUAL always tries to find a feasible successor before resorting to a recomputation. If a feasible successor is available, DUAL can quickly install the new route and avoid recomputation.

"Stuck in Active" Routes
If one or more routers to which a query is sent do not respond with a reply within the active time of 180 seconds or three minutes, the route, or routes, in question are placed in the "stuck in active" state. When this happens, EIGRP clears the neighbors that did not send a reply and logs a "stuck in active" error message for the route(s) that went active.

5.3.4 Route tagging with EIGRP

Not only does the topology table track information regarding route states, but it also can record special information about each route. EIGRP classifies routes as either internal or external. EIGRP uses a process called route tagging to add special tags to each route. These tags identify a route as internal or external, and may include other information as well.

Internal routes originate from within the EIGRP AS. External routes originate from outside the system. Routes learned (redistributed) from other routing protocols, such as RIP, OSPF, and IGRP are external. Static routes originating from outside the EIGRP AS and redistributed inside are also external routes.

All external routes are included in the topology table and are tagged with the following information:

* The identification number, known as router ID, of the EIGRP router that redistributed the route into the EIGRP network
* The AS number of the destination
* The protocol used in that external network
* The cost or metric received from that external protocol
* The configurable administrator tag

Figure shows a specific topology table entry for an external route.

Using route tagging, particularly the administrator tag, gives an advantage when developing a precise routing policy. The administrator tag can be any number between 0 and 255. This is a custom tag that can be used to implement a special routing policy. External routes can be accepted, rejected, or propagated based on any of the route tags, including the administrator tag. Configuring an administrator tag in this way affords a high degree of control. This level of precision and flexibility proves especially useful when EIGRP networks interact with BGP networks, which themselves are policy-based. BGP will be covered in depth in Module 9.

5.4.1 Convergence using EIGRP

The sophisticated algorithm of DUAL results in exceptionally fast EIGRP convergence. To better understand convergence when using DUAL, consider the scenario . RTA can reach network 24 via three different routers: RTX, RTY, or RTZ.

The composite metric of EIGRP is replaced by a link cost to simplify calculations. The RTA topology table includes a list of all routes advertised by neighbors. For each network, RTA keeps the real, computed, cost of getting to the network. RTA also keeps the advertised cost or the reported distance from its neighbor.

At first, RTY is the successor to Network 24, by virtue of its lowest computed cost. The lowest calculated metric from RTA to Network 24 is 31. This value is the FD to Network 24.

What if the successor to Network 24, RTY, becomes unavailable?

RTA follows a three-step process to select a feasible successor to become a successor for Network 24:

1. Determine which neighbors have reported distances (RD) to Network 24 that is less than the FD reported by RTA to Network 24. The FD is 31. The RD for RTX is 30, while the RD for RTZ is 220. Therefore, the RD for RTX is below the current FD, while the RD for RTZ is not.
2. Determine the minimum computed cost to Network 24 from among the remaining routes available. The computed cost by way of RTX is 40, while the computed cost by way of RTX is 230. Therefore, RTX provides the lowest computed cost.
3. Determine whether any routers that met the criterion in Step 1 also met the criterion in Step 2. RTX has done both, so it is the feasible successor.

With RTY down, RTA immediately uses RTX, which is the feasible successor, to forward packets to Network 24. The capability to make an immediate switchover to a backup route gives EIGRP exceptionally fast convergence time. However, what happens if RTX also becomes unavailable?

Can RTZ be a feasible successor? Using the same three-step process as before, RTA finds that RTZ is advertising a cost of 220, which is greater than the FD of 31for RTA. Therefore, RTZ cannot be a feasible successor as of yet. The FD can change only during an active-to-passive transition, and this did not occur, so it remains at 31. At this point, because there has not been a transition to active state for Network 24, DUAL has been performing what is called a local computation.

RTA cannot find any feasible successors, so it finally transitions from passive to active state for Network 24 and queries its neighbors about Network 24. This process is known as a diffusing computation. When Network 24 is in an active state, the FD is reset. This allows RTA to at last accept RTZ as the successor to Network 24.

5.5.2 EIGRP and the bandwidth command

The following three rules should be adhered to when configuring EIGRP over an NBMA cloud such as Frame Relay:

* EIGRP traffic should not exceed the CIR capacity of the virtual circuit (VC).
* The aggregated traffic EIGRP has over all the VCs should not exceed the access line speed of the interface.
* The bandwidth allocated to EIGRP on each VC must be the same in both directions.

If these rules are understood and followed, EIGRP works well over the WAN. If care is not taken in the configuration of the WAN, EIGRP can swamp the network.

Configuring Bandwidth over a Multipoint Network
The configuration of the bandwidth command in an NBMA cloud depends on the design of the VCs. If the serial line has many VCs in a multipoint configuration, and all of the VCs share bandwidth evenly, set the bandwidth to the sum of all of the CIRs. In Figure , the CIR for each VC is set to 56 Kbps. Since there are four VCs, the bandwidth is set to 224 (4 x 56).

Configuring Bandwidth over a Hybrid Multipoint Network
If the multipoint network has differing speeds allocated to the VCs, a more complex solution is needed. The following are the two main approaches:

* Take the lowest CIR and multiply this by the number of VCs. This is applied to the physical interface. The problem with this configuration is that the higher-bandwidth links may be underutilized.
* Use subinterfaces. The bandwidth command may be configured on each subinterface, which allows different speeds on each VC. In this case, subinterfaces are configured for the links with the differing CIRs. The links that have the same configured CIR are presented as a single subinterface with a bandwidth reflecting the aggregate CIR of all the circuits. Three of the VCs have the same CIR, 256 Kbps. All three VCs are grouped together as a multipoint subinterface, serial 0/0.1. The single remaining VC, which has a lower CIR, 56 Kbps, can be assigned a point-to-point subinterface, serial0/0.2.

5.5.3 The bandwidth-percent command

The bandwidth-percent command configures the percentage of bandwidth that may be used by EIGRP on an interface. By default, EIGRP is set to use only up to 50% of the bandwidth of an interface to exchange routing information. In order to calculate its percentage, the bandwidth-percent command relies on the value set by the bandwidth command.

Use the bandwidth-percent command when the bandwidth setting of a link does not reflect its true speed. The bandwidth value may be artificially low for a variety of reasons, such as to manipulate the routing metric, or to accommodate an oversubscribed multipoint Frame Relay configuration. Regardless of the reasons, configure EIGRP to overcome an artificially low bandwidth setting by setting the bandwidth-percent to a higher number. In some cases, it may even be set to a number above 100.

For example, assume that the actual bandwidth of a router serial link is 64 Kbps, but the bandwidth value is set artificially low, to 32 Kbps. The figure shows how to modify the behavior of EIGRP so that it limits routing protocol traffic according to the actual bandwidth of the serial interface. The example configuration sets the bandwidth-percent on serial 0/0 to 100 percent for the EIGRP process running in AS 24. Since 100 percent of 32 kbps is 32, EIGRP will be allowed to use half of the actual bandwidth of 64 Kbps.

NOTE:

The EIGRP percentage of bandwidth for IP may be changed with the following command:

ip bandwidth-percent eigrp

5.5.4 Summarizing EIGRP Routes: no auto-summary

EIGRP automatically summarizes routes at the classful boundary, the boundary where the network address ends as defined by class-based addressing. This means that even though RTC is connected only to the subnet 2.1.1.0, it will advertise that it is connected to the entire Class A network, 2.0.0.0. In most cases, auto summarization is a good thing, keeping the routing tables as compact as possible.

In the presence of discontiguous subnetworks, automatic summarization must be disabled for routing to work properly. To turn off auto-summarization, use the following command:

Router(config-router)#no auto-summary

5.5.5 Summarizing EIGRP Routes: Interface Summarization

EIGRP also enables manual configuration of a prefix to use as a summary address. Manual summary routes are configured on a per-interface basis. The interface that will propagate the route summary must first be selected and then defined with the ip summary-address eigrp command, which has the following syntax:

Router(config-if)#ip summary-address eigrp autonomous-system-number ip-address mask administrative-distance

EIGRP summary routes have an administrative distance of 5 by default. Optionally, they can be configured for a value between 1 and 255.

In the figure, RTC can be configured using the following commands shown:

RTC(config)#router eigrp 2446
RTC(config-router)#no auto-summary
RTC(config-router)#exit
RTC(config)#interface serial0/0
RTC(config-if)#ip summary-address eigrp 2446 2.1.0.0 255.255.0.0

Therefore, RTC will add a route to its table, as follows:

D 2.1.0.0/16 is a summary, 00:00:22, Null0

Notice that the summary route is sourced from Null0, and not an actual interface. That is because this route is used for advertisement purposes and does not represent a path that RTC can take to reach that network. On RTC, this route has an administrative distance of 5.

In the figure, RTD is oblivious to the summarization but accepts the route. It assigns the route the administrative distance of a "normal" EIGRP route, which is 90, by default. In the configuration for RTC, automatic summarization is turned off, with no auto-summary command. Otherwise RTD would receive two routes, the manual summary address of 2.1.0.0/16 and the automatic, classfull address of 2.0.0.0/8.

In most cases, when using manual summarization, the no auto-summary command should be configured.

5.6.1 Verifying EIGRP operation

Throughout this module the EIGRP show commands have been used to verify EIGRP operation. Figure lists the key EIGRP show commands and briefly describes their functions.

The Cisco IOS debug feature also provides useful EIGRP monitoring commands.

5.7.1 Configuring EIGRP

5.7.2 Configuring EIGRP fault tolerance

5.7.3 Configuring EIGRP summarization

5.8.1 EIGRP challenge lab

Summary

EIGRP, a Cisco proprietary routing protocol, is an advanced distance vector protocol that uses the DUAL algorithm. It includes features such as rapid convergence, reduced bandwidth usage, and multiple network-layer support.

EIGRP converges rapidly, performs incremental updates, routes IP, and summarizes routes. The labs demonstrated how to configure and verify EIGRP configuration for various protocols.

by sdominguez.com

• prepara tu examen ccna.
• prepara tu examen ccnp.
• prepara tu certificacion ccnp.
• prepara tu certificacion ccna.
• prepara tu examenes ccna.
• prepara tu examenes ccnp.
• prepara tu certificaciones ccnp.
• prepara tu certificacion ccna.