Operation of EIGRP


EIGRP uses the same formula that IGRP uses to calculate its composite metric. However, EIGRP scales the metric components by 256 to achieve a finer metric granularity. So if the minimum configured bandwidth on the path to a destination is 512K and the total configured delay is 46000 microseconds, IGRP would calculate a composite metric of 24131. EIGRP, however, will multiply the bandwidth and delay components by 256 for a metric of 256 x 24131 = 6177536.

EIGRP has four components (Figure 7-4):

  • Protocol-Dependent Modules

  • Reliable Transport Protocol (RTP)

  • Neighbor Discovery/Recovery

  • Diffusing Update Algorithm (DUAL)

Figure 7-4. The four major components of EIGRP. RTP and neighbor discovery are lower-level protocols that enable the correct operation of DUAL. DUAL can perform route computations for multiple routed protocols.


This section examines each EIGRP component, with particular emphasis on DUAL, and ends with a discussion of address aggregation.

Protocol-Dependent Modules

EIGRP implements modules for IP, IPX, and AppleTalk, which are responsible for the protocol-specific routing tasks. For example, the IPX EIGRP module is responsible for exchanging route information about IPX networks with other IPX EIGRP processes and for passing the information to the DUAL. Additionally, the IPX module will send and receive SAP information.

As Figure 7-4 shows, the traffic for the individual modules is encapsulated within their respective network layer protocols. EIGRP for IPX, for example, is carried in IPX packets.

EIGRP automatically redistributes with other protocols in many cases:

  • IPX EIGRP automatically redistributes with IPX RIP and NLSP.

  • AppleTalk EIGRP automatically redistributes with AppleTalk RTMP.

  • IP EIGRP automatically redistributes routes with IGRP if the IGRP process is in the same autonomous system.

Redistribution with other IP routing protocols is the subject of Chapter 11.

Configuration of EIGRP for IPX and AppleTalk is outside the scope of this book. Refer to the Cisco Configuration Guide for more information.

Reliable Transport Protocol

The Reliable Transport Protocol (RTP) manages the delivery and reception of EIGRP packets. Reliable delivery means that delivery is guaranteed and that packets will be delivered in order.

Guaranteed delivery is accomplished by means of a Cisco-proprietary algorithm known as reliable multicast, using the reserved class D address 224.0.0.10. Each neighbor receiving a reliably multicast packet unicasts an acknowledgment.

Ordered delivery is ensured by including two sequence numbers in the packet. Each packet includes a sequence number assigned by the sending router. This sequence number is incremented by one each time the router sends a new packet. In addition, the sending router places in the packet the sequence number of the last packet received from the destination router.

In some cases, RTP may use unreliable delivery. No acknowledgment is required, and no sequence number will be included for unreliably delivered EIGRP packets.

EIGRP uses multiple packet types, all of which are identified by protocol number 88 in the IP header:

  • Hellos are used by the neighbor discovery and recovery process. Hello packets are multicast and use unreliable delivery.

  • Acknowledgments (ACKs) are Hello packets with no data in them. ACKs are always unicast and use unreliable delivery.

  • Updates convey route information. Unlike RIP and IGRP updates, these packets are transmitted only when necessary, contain only necessary information, and are sent only to routers that require the information. When updates are required by a specific router, they are unicast. When updates are required by multiple routers, such as upon a metric or topology change, they are multicast. Updates always use reliable delivery.

  • Queries and Replies are used by the DUAL finite state machine to manage its diffusing computations. Queries can be multicast or unicast, and replies are always unicast. Both queries and replies use reliable delivery.

  • Requests were a type of packet originally intended for use in route servers. This application was never implemented, and request packets are noted here only because they are mentioned in some older EIGRP documentation.

If any packet is reliably multicast and an ACK is not received from a neighbor, the packet will be retransmitted as a unicast to that unresponding neighbor. If an ACK is not received after 16 of these unicast retransmissions, the neighbor will be declared dead.

The time to wait for an ACK before switching from multicast to unicast is specified by the multicast flow timer. The time between the subsequent unicasts is specified by the retransmission timeout (RTO). Both the multicast flow timer and the RTO are calculated for each neighbor from the smooth round-trip time (SRTT). The SRTT is the average elapsed time, measured in milliseconds, between the transmission of a packet to the neighbor and the receipt of an acknowledgment. The formulas for calculating the exact values of the SRTT, the RTO, and the multicast flow timer are proprietary.

The following two subsections discuss the EIGRP components that use the various packet types.

Neighbor Discovery/Recovery

Because EIGRP updates are nonperiodic, it is especially important to have a process whereby neighborsEIGRP-speaking routers on directly connected networksare discovered and tracked. On most networks, Hellos are multicast every five seconds, minus a small random time to prevent synchronization. On multipoint X.25, Frame Relay, and ATM interfaces, with access link speeds of T1 or slower, Hellos are unicast every 60 seconds.[5] This longer Hello interval is also the default for ATM SVCs and for ISDN PRI interfaces. In all cases, the Hellos are unacknowledged. The default Hello interval can be changed on a per interface basis with the command ip hello-interval eigrp.

[5] Point-to-point subinterfaces send Hellos every 5 seconds.

When a router receives a Hello packet from a neighbor, the packet will include a hold time. The hold time tells the router the maximum time it should wait to receive subsequent Hellos. If the hold timer expires before a Hello is received, the neighbor is declared unreachable and DUAL is informed of the loss of a neighbor. By default, the hold time is three times the Hello interval180 seconds for low-speed nonbroadcast multiaccess (NBMA) networks and 15 seconds for all other networks. The default can be changed on a per interface basis with the command ip hold-time eigrp. The capability to detect a lost neighbor within 15 seconds, as opposed to 180 seconds for RIP and 270 seconds for IGRP, is one factor contributing to EIGRP's fast reconvergence.

Information about each neighbor is recorded in a neighbor table. As Example 7-6 shows, the neighbor table records the IP address of the neighbor and the interface on which the neighbor's Hellos are received. The hold time advertised by the neighbor is recorded, as is the SRTT and the uptimethe time since the neighbor was added to the table. The RTO is the time, in milliseconds, that the router will wait for an acknowledgment of a unicast packet sent after a multicast has failed. If an EIGRP update, query, or reply is sent, a copy of the packet will be queued. If the RTO expires before an ACK is received, another copy of the queued packet is sent. The Q Count indicates the number of enqueued packets. The sequence number of the last update, query, or reply packet received from the neighbor is also recorded in the neighbor table. The RTP tracks these sequence numbers to ensure that packets from the neighbor are not received out of order. Finally, the H column records the order in which the neighbors were learned.

Example 7-6. The command show ip eigrp neighbors is used to observe the IP EIGRP neighbor table.
Wright#show ip eigrp neighbors IP-EIGRP neighbors for process 1 H   Address   Interface   Hold  Uptime   SRTT   RTO   Q   Seq                           (sec)          (ms)        Cnt  Num 3   10.1.1.2  Et0           10  09:01:27   12   200   0   5 2   10.1.4.2  Se1           13  09:02:11   23   200   0   11 1   10.1.2.2  Et1           14  09:02:12    8   200   0   15 0   10.1.3.2  Se0           12  09:02:12   21   200   0   13 Wright#

Diffusing Update Algorithm

DUAL is a convergence algorithm that replaces the Bellman-Ford or Ford-Fulkerson algorithms used by other distance vector protocols. The design philosophy behind DUAL is that even temporary routing loops are detrimental to the performance of a network. DUAL uses diffusing computations, first proposed by E. W. Dijkstra and C. S. Scholten,[6] to perform distributed shortest-path routing while maintaining freedom from loops at every instant. Although many researchers have contributed to the development of DUAL, the most prominent work is that of J. J. Garcia-Luna-Aceves.[7]

[6] Edsger W. Dijkstra and C. S. Scholten. "Termination Detection for Diffusing Computations." Information Processing Letters, Vol. 11, No. 1, pp. 14: 29 August 1980.

[7] J. J. Garcia-Luna-Aceves. "A Unified Approach for Loop-Free Routing Using Link States or Distance Vectors," ACM SIGCOMM Computer Communications Review, Vol. 19, No. 4, pp. 212223: September 1989.

J. J. Garcia-Luna-Aceves. "Loop-Free Routing Using Diffusing Computations," IEEE/ACM Transactions on Networking, Vol. 1, No. 1, February 1993.

DUAL: Preliminary Concepts

For DUAL to operate correctly, a lower-level protocol must ensure that the following conditions are met:[8]

[8] J. J. Garcia-Luna-Aceves. "Area-Based, Loop-Free Internet Routing." Proceedings of IEEE INFOCOMM 94. Toronto, Ontario, Canada, June 1994.

  • A node detects within a finite time the existence of a few neighbor or the loss of connectivity with a neighbor.

  • All messages transmitted over an operational link are received correctly and in the proper sequence within a finite time.

  • All messages, changes in the cost of a link, link failures, and new-neighbor notifications are processed one at a time within a finite time and in the order in which they are detected.

The Cisco EIGRP uses Neighbor Discovery/Recovery and RTP to establish these preconditions.

Before the operation of DUAL can be examined, a few terms and concepts must be described.

Upon startup, a router uses Hellos to discover neighbors and to identify itself to neighbors. When a neighbor is discovered, EIGRP will attempt to form an adjacency with that neighbor. An adjacency is a logical association between two neighbors over which route information is exchanged. When adjacencies have been established, the router will receive updates from its neighbors. The updates will contain all routes known by the sending routers and the metrics of those routes. For each route, the router will calculate a distance based on the distance advertised by the neighbor and the cost of the link to that neighbor.

The lowest calculated metric to each destination will become the feasible distance (FD) of that destination. For example, a router may be informed of three different routes to subnet 172.16.5.0 and may calculate metrics of 380672, 12381440, and 660868 for the three routes. 380672 will become the FD because it is the lowest calculated distance.

The feasibility condition (FC) is a condition that is met if a neighbor's advertised distance to a destination is lower than the router's FD to that same destination.

If a neighbor's advertised distance to a destination meets the FC, the neighbor becomes a feasible successor[9] for that destination. For example, if the FD to subnet 172.16.5.0 is 380672 and a neighbor advertises a route to that subnet with a distance of 355072, the neighbor will become a feasible successor; if the neighbor advertises a distance of 380928, it will not satisfy the FC and will not become a feasible successor.

[9] Successor simply means a router that is one hop closer to a destinationin other words, a next-hop router.

The concepts of feasible successors and the FC are central to loop avoidance. Because feasible successors are always "downstream," (that is, a shorter metric distance to the destination than the FD) a router will never choose a path that will lead back through itself, creating a loop. Such a path would have a distance larger than the FD.

Every destination for which one or more feasible successors exist will be recorded in a topological table, along with the following items:

  • The destination's FD

  • All feasible successors

  • Each feasible successor's advertised distance to the destination

  • The locally calculated distance to the destination via each feasible successor, based on the feasible successor's advertised distance and the cost of the link to that successor

  • The interface connected to the network on which each feasible successor is found[10]

    [10] Actually, the interface is not explicitly recorded in the route table. Rather, it is an attribute of the neighbor itself. This convention implies that the same router, seen across multiple parallel links, will be viewed by EIGRP as multiple neighbors.

For every destination listed in the topological table, the route with the lowest metric is chosen and placed into the route table. The neighbor advertising that route becomes the successor, or the next-hop router to which packets for that destination are sent.

An example will help clarify these terms, but first a brief discussion of the network used in the examples in this section is necessary. Figure 7-5 shows the EIGRP-based network that is used throughout this and the next three subsections.[11] The command metric weights 0 0 0 1 0 0 has been added to the EIGRP process so that only delay is used in the metric calculations. The delay command has been used with the numbers shown at each link; for example, the interfaces of routers Wright and Langley, connected to subnet 10.1.3.0, have been configured with a delay of 2. These steps have been taken to simplify the examples that follow.

[11] Several of the illustrations in this and the following section, and in the network example used throughout, are adapted from Dr. Garcia-Luna-Aceves's "Loop-Free Routing Using Diffusing Computations," with his permission.

Figure 7-5. The examples and illustrations of this and the next two subsections are based on this EIGRP network.


It should be pointed out that although the delay parameters used here sacrifice realism for simplicity, the way the metrics are manipulated is realistic. Many parameters are calculated from an interface's bandwidth specification; some, such as the ip bandwidth-percent eigrp, apply directly to EIGRP. Others, such as OSPF cost, do not. As a result, changes of the configured bandwidth should be avoided except to set serial links to their actual bandwidth. If interface metrics need to be manipulated to influence EIGRP (or IGRP) routing, use delay. Many unexpected headaches can be avoided.

In Example 7-7, the command show ip eigrp topology is used to observe the topology table of router Langley. Each of the seven subnets shown in Figure 7-5 is listed, along with the feasible successors for the subnets. For example, the feasible successors for subnet 10.1.6.0 are 10.1.3.1 (Wright) and 10.1.5.2 (Chanute), via interfaces S0 and S1, respectively.

Example 7-7. Topology table of router Langley.
Langley#show ip eigrp topology IP-EIGRP Topology Table for process 1 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,        r - Reply status P 10.1.3.0/24, 1 successors, FD is 512          via Connected, Serial0 P 10.1.2.0/24, 1 successors, FD is 768          via 10.1.3.1 (768/256), Serial0          via 10.1.5.2 (1280/256), Serial1 P 10.1.1.0/24, 1 successors, FD is 768          via 10.1.3.1 (768/256), Serial0          via 10.1.5.2 (1536/512), Serial1 P 10.1.7.0/24, 1 successors, FD is 256          via Connected, Ethernet0 P 10.1.6.0/24, 1 successors, FD is 1024          via 10.1.3.1 (1024/512), Serial0          via 10.1.5.2 (1792/768), Serial1 P 10.1.5.0/24, 1 successors, FD is 1024          via Connected, Serial1 P 10.1.4.0/24, 1 successors, FD is 5632          via 10.1.3.1 (5632/5120), Serial0          via 10.1.5.2 (6400/5376), Serial1 Langley#

Two metrics in parentheses are also associated with each feasible successor. The first number is the locally calculated metric from Langley to the destination. The second number is the metric advertised by the neighbor. For example, in Figure 7-5 the metric from Langley to subnet 10.1.6.0 via Wright is 256 x (2 + 1 + 1) = 1024, and the metric advertised by Wright for that destination is 256 x (1 + 1) = 512. The two metrics for the same destination via Chanute are 256 x (4 + 1 + 1 + 1) = 1792 and 256 x (1 + 1 + 1) = 768.

The lowest metric from Langley to subnet 10.1.6.0 is 1024, so that is the FD. Example 7-8 shows Langley's route table, with the chosen successors.

Example 7-8. Langley's route table shows that a single successor has been chosen for each known destination, based on the lowest metric distance.
Langley#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        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 Gateway of last resort is not set      10.0.0.0/8 is subnetted, 7 subnets C       10.1.3.0 is directly connected, Serial0 D       10.1.2.0 [90/768] via 10.1.3.1, 00:32:06, Serial0 D       10.1.1.0 [90/768] via 10.1.3.1, 00:32:07, Serial0 C       10.1.7.0 is directly connected, Ethernet0 D       10.1.6.0 [90/1024] via 10.1.3.1, 00:32:07, Serial0 C       10.1.5.0 is directly connected, Serial1 D       10.1.4.0 [90/5632] via 10.1.3.1, 00:32:07, Serial0 Langley#

Langley has only one successor for every route. The topology table of Cayley (Example 7-9) shows that there are two successors for 10.1.4.0 because the locally calculated metric for both routes matches the FD. Both routes are entered into the route table (Example 7-10), and Cayley will perform equal-cost load balancing.

Example 7-9. Topology table of Cayley, showing two successors to subnet 10.1.4.0.
Cayley#show ip eigrp topology IP-EIGRP Topology Table for process 1 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,        r - Reply status P 10.1.3.0/24, 1 successors, FD is 768          via 10.1.1.1 (768/512), Ethernet0 P 10.1.2.0/24, 1 successors, FD is 512          via 10.1.1.1 (512/256), Ethernet0 P 10.1.1.0/24, 1 successors, FD is 256          via Connected, Ethernet0 P 10.1.7.0/24, 1 successors, FD is 1024          via 10.1.1.1 (1024/768), Ethernet0 P 10.1.6.0/24, 1 successors, FD is 256          via Connected, Serial0 P 10.1.5.0/24, 1 successors, FD is 1536          via 10.1.1.1 (1536/1280), Ethernet0 P 10.1.4.0/24, 2 successors, FD is 5376          via 10.1.6.1 (5376/5120), Serial0          via 10.1.1.1 (5376/5120), Ethernet0 Cayley#

Example 7-10. Equal-cost load sharing will be performed between the two successors to 10.1.4.
Cayley#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      10.0.0.0/24 is subnetted, 7 subnets D       10.1.3.0 [90/768] via 10.1.1.1, 00:01:19, Ethernet0 D       10.1.2.0 [90/512] via 10.1.1.1, 00:01:19, Ethernet0 C       10.1.1.0 is directly connected, Ethernet0 D       10.1.7.0 [90/1024] via 10.1.1.1, 00:01:19, Ethernet0 C       10.1.6.0 is directly connected, Serial0 D       10.1.5.0 [90/1536] via 10.1.1.1, 00:01:19, Ethernet0 D       10.1.4.0 [90/5376] via 10.1.1.1, 00:01:19, Ethernet0                  [90/5376] via 10.1.6.1, 00:01:19, Serial0 Cayley#

The topology table of Chanute (Example 7-11) shows several routes for which there is only one feasible successor. For example, the route to 10.1.6.0 has an FD of 768, and Wright (10.1.2.1) is the only feasible successor. Langley has a route to 10.1.6.0, but its metric is 256 x (2 + 1 + 1) = 1024, which is greater than the FD. Therefore, Langley's route to 10.1.6.0 does not satisfy the FC, and Langley does not qualify as a feasible successor.

Example 7-11. Several of the subnets reachable from Chanute have only one feasible successor.
Chanute#show ip eigrp topology IP-EIGRP Topology Table for process 1 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,        r - Reply status P 10.1.3.0/24, 1 successors, FD is 768          via 10.1.2.1 (768/512), Ethernet0          via 10.1.5.1 (1536/512), Serial0 P 10.1.2.0/24, 1 successors, FD is 256          via Connected, Ethernet0 P 10.1.1.0/24, 1 successors, FD is 512          via 10.1.2.1 (512/256), Ethernet0 P 10.1.7.0/24, 1 successors, FD is 1024          via 10.1.2.1 (1024/768), Ethernet0          via 10.1.5.1 (1280/256), Serial0 P 10.1.6.0/24, 1 successors, FD is 768          via 10.1.2.1 (768/512), Ethernet0 P 10.1.5.0/24, 1 successors, FD is 1024          via Connected, Serial0 P 10.1.4.0/24, 1 successors, FD is 5376          via 10.1.2.1 (5376/5120), Ethernet0 Chanute#

If a feasible successor advertises a route for which the locally calculated metric is lower than the metric via the present successor, the feasible successor will become the successor. The following conditions can cause this situation to occur:

  • A newly discovered route

  • The cost of a successor's route increasing beyond that of a feasible successor

  • The cost of a feasible successor's route decreasing to below the cost of the successor's route

For example, Example 7-12 shows that Lilienthal's successor to subnet 10.1.3.0 is Cayley (10.1.6.2). Suppose the cost of the link between Lilienthal and Wright is decreased to one. Wright (10.1.4.1) is advertising a distance of 512 to subnet 10.1.3.0; with the new cost of the link to Wright, Lilienthal's locally calculated metric to the subnet via that router is now 768. Wright will replace Cayley as the successor to subnet 10.1.3.0.

Example 7-12. Topology table for Lilienthal.
Lilienthal#show ip eigrp topology IP-EIGRP Topology Table for process 1 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,        r - Reply status P 10.1.3.0/24, 1 successors, FD is 1024          via 10.1.6.2 (1024/768), Serial0          via 10.1.4.1 (5632/512), Serial1 P 10.1.2.0/24, 1 successors, FD is 768          via 10.1.6.2 (768/512), Serial0          via 10.1.4.1 (5376/256), Serial1 P 10.1.1.0/24, 1 successors, FD is 512          via 10.1.6.2 (512/256), Serial0          via 10.1.4.1 (5376/256), Serial1 P 10.1.7.0/24, 1 successors, FD is 1280          via 10.1.6.2 (1280/1024), Serial0          via 10.1.4.1 (5888/768), Serial1 P 10.1.6.0/24, 1 successors, FD is 256          via Connected, Serial0 P 10.1.5.0/24, 1 successors, FD is 1792          via 10.1.6.2 (1792/1536), Serial0          via 10.1.4.1 (6400/1280), Serial1 P 10.1.4.0/24, 1 successors, FD is 5120          via Connected, Serial1 Lilienthal#

Next, suppose Lilienthal discovers a new neighbor that is advertising a distance of 256 to subnet 10.1.3.0. This distance is lower than the FD, so the new neighbor will become a feasible successor. Suppose further that the cost of the link to the new neighbor is 256. Lilienthal's locally calculated metric to 10.1.3.0 via the new neighbor will be 512. This metric is lower than the distance via Wright, so the new neighbor will become the successor to 10.1.3.0.

Feasible successors are important because they reduce the number of diffusing computations and therefore increase performance. Feasible successors also contribute to lower reconvergence times. If a link to a successor fails, or if the cost of the link increases beyond the FD, the router will first look into its topology table for a feasible successor. If one is found, it will become the successor; this selection normally occurs in the sub-second range. The router will begin a diffusing computation only if a feasible successor cannot be found. The key to successful EIGRP design, then, is ensuring that a feasible successor always exists for all destinations.

The following section gives a more formal set of rules for when and how a router will search for feasible successors. This set of rules is called the DUAL finite state machine.

DUAL Finite State Machine

When an EIGRP router is performing no diffusing computations, each route is in the passive state. Referring to any of the topology tables in the previous section, a key to the left of each route indicates a passive state.

A router will reassess its list of feasible successors for a route, as described in the last section, any time an input event occurs. An input event can be the following:

  • A change in the cost of a directly connected link

  • A change in the state (up or down) of a directly connected link

  • The reception of an update packet

  • The reception of a query packet

  • The reception of a reply packet

The first step in its reassessment is a local computation in which the distance to the destination is recalculated for all feasible successors. The possible results are

  • If the feasible successor with the lowest distance is different from the existing successor, the feasible successor will become the successor.

  • If the new distance is lower than the FD, the FD will be updated.

  • If the new distance is different from the existing distance, updates will be sent to all neighbors.

While the router is performing a local computation, the route remains in the passive state. If a feasible successor is found, an update is sent to all neighbors and no state change occurs.

If a feasible successor cannot be found in the topology table, the router will begin a diffusing computation and the route will change to the active state. Until the diffusing computation is completed and the route transitions back to the passive state, the router cannot

  • Change the route's successor

  • Change the distance it is advertising for the route

  • Change the route's FD

  • Begin another diffusing computation for the route

A router begins a diffusing computation by sending queries to all of its neighbors (Figure 7-6). The query will contain the new locally calculated distance to the destination. Each neighbor, upon receipt of the query, will perform its own local computation:

  • If the neighbor has one or more feasible successors for the destination, it will send a reply to the originating router. The reply will contain that neighbor's minimum locally calculated distance to the destination.

  • If the neighbor does not have a feasible successor, it too will change the route to the active state and will begin a diffusing computation.

Figure 7-6. A diffusing computation grows as queries are sent and shrinks as replies are received.


For each neighbor to which a query is sent, the router will set a reply status flag (r) to keep track of all outstanding queries. The diffusing computation is complete when the router has received a reply to every query sent to every neighbor.

In some cases, a router does not receive a reply to every query sent. For example, this might happen in large networks with many low-bandwidth or low-quality links. At the beginning of the diffusing computation, an Active timer is set for three minutes. If all expected replies are not received before the Active time expires, the route is declared stuck-in-active (SIA). The neighbor or neighbors that did not reply will be removed from the neighbor table, and the diffusing computation will consider the neighbor to have responded with an infinite metric.

The default three-minute Active time can be changed or disabled with the command timers active-time. The deletion of a neighbor because of a lost query obviously can have disruptive results, and SIAs should never occur in a stable, well-designed network. The troubleshooting section of this chapter discusses SIAs in more detail. That same section describes a recent enhancement to the SIA procedures, using two new EIGRP messagesSIA Query and SIA Replythat both reduce the chance of occurrences of SIAs and, when they do occur, make them easier to troubleshoot.

At the completion of the diffusing computation, the originating router will set FD to infinity to ensure that any neighbor replying with a finite distance to the destination will meet the FC and become a feasible successor. For each of these replies, a metric is calculated based on the distance advertised in the reply plus the cost of the link to the neighbor who sent the reply. A successor is selected based on the lowest metric, and FD is set to this metric. Any feasible successors that do not satisfy the FC for this new FD will be removed from the topology table. Note that a successor is not chosen until all replies have been received.

Because there are multiple types of input events that can cause a route to change state, some of which might occur while a route is active, DUAL defines multiple active states. A query origin flag (O) is used to indicate the current state. Figure 7-7 and Table 7-2 show the complete DUAL finite state machine.

Figure 7-7. The DUAL finite state machine. The query origin flag (O) marks the current state of the diffusing calculation. See Table 7-2 for a description of each input event (IE).


Table 7-2. Input events for the DUAL finite state machine.

Input Event

Description

IE1

Any input event for which FC is satisfied or the destination is unreachable

IE2

Query received from the successor; FC not satisfied

IE3

Input event other than a query from the successor; FC not satisfied

IE4

Input event other than last reply or a query from the successor

IE5

Input event other than last reply, a query from the successor, or an increase in distance to destination

IE6

Input event other than last reply

IE7

Input event other than last reply or increase in distance to destination

IE8

Increase in distance to destination

IE9

Last reply received; FC not met with current FD

IE10

Query received from the successor

IE11

Last reply received; FC met with current FD

IE12

Last reply received; set FD to infinity


Two examples can help clarify the DUAL process. Figure 7-8 shows the example network, focusing only on each router's path to subnet 10.1.7.0; refer to Figure 7-5 for specific addresses. On the data links, an arrow indicates the successor each router is using to reach 10.1.7.0. In parentheses are each router's locally calculated distance to the subnet, the router's FD, the reply status flag (r), and the query origin flag (O), respectively. Active routers are indicated with a circle in subsequent figures and examples using this network.

Figure 7-8. All routes to subnet 10.1.7.0 are in the passive state, indicated by r = 0 and O = 1.


Diffusing Computation: Example 1

This example focuses only on Cayley and its route to subnet 10.1.7.0. In Figure 7-9, the link between Cayley and Wright (10.1.1.1) has failed. EIGRP interprets the failure as a link with an infinite distance.[12] Cayley checks its topology table for a feasible successor to 10.1.7.0 and finds none (refer to Example 7-9).

[12] An infinite distance is indicated by a delay of 0xFFFFFFFF, or 4294967295.

Figure 7-9. The link between Wright and Cayley has failed, and Cayley does not have a feasible successor to subnet 10.1.7.0.


Cayley's route becomes active (Figure 7-10). The distance and the FD of the route are changed to unreachable, and a query containing the new distance is sent to Cayley's neighbor, Lilienthal. Cayley's reply status flag for Lilienthal is set to one, indicating that a reply is expected. Because the input event was not the reception of a query (IE3), O=1.

Figure 7-10. Cayley's route to 10.1.7.0 transitions to active, and Lilienthal is queried for a feasible successor.


Upon receipt of the query, Lilienthal performs a local computation (Figure 7-11). Because Lilienthal has a feasible successor for 10.1.7.0 (refer to Example 7-12), the route does not become active. Wright becomes the new successor, and a reply is sent with Lilienthal's distance to 10.1.7.0 via Wright. Because the distance to 10.1.7.0 has increased and the route did not become active, the FD is unchanged at Lilienthal.

Figure 7-11. Lilienthal has a feasible successor to 10.1.7.0. A local computation is performed, a reply is sent to Cayley with the distance via Wright, and an update is sent to Wright.


Upon receipt of the reply from Lilienthal, Cayley sets r=0 and the route becomes passive (Figure 7-12). Lilienthal becomes the new successor, and the FD is set to the new distance. Finally, an update is sent to Lilienthal with Cayley's locally calculated metric. Lilienthal will also send an update advertising its new metric.

Figure 7-12. Cayley's route to 10.1.7.0 becomes passive, and an update is sent to Lilienthal.


EIGRP packet activity can be observed with the debug command debug eigrp packets. By default, all EIGRP packets are displayed. Because Hellos and ACKs can make the debug output hard to follow, the command allows the use of optional keywords so that only specified packet types are displayed. In Example 7-13, debug eigrp packets query reply update is used to observe the packet activity at Cayley for the events described in this example.

Example 7-13. The EIGRP packet events described in this example can be observed in these debug messages.
Cayley#debug eigrp packet update query reply EIGRP Packets debugging is on     (UPDATE, QUERY, REPLY) B# %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down EIGRP: Enqueueing QUERY on Serial0 iidbQ un/rely 0/1 serno 45-49 EIGRP: Enqueueing QUERY on Serial0 nbr 10.1.6.1 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 45-49 EIGRP: Sending QUERY on Serial0 nbr 10.1.6.1   AS 1, Flags 0x0, Seq 45/64 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 45-49 EIGRP: Received REPLY on Serial0 nbr 10.1.6.1   AS 1, Flags 0x0, Seq 65/45 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0 EIGRP: Enqueueing UPDATE on Serial0 iidbQ un/rely 0/1 serno 50-54 EIGRP: Enqueueing UPDATE on Serial0 nbr 10.1.6.1 iidbQ un/rely 0/0 peerQ un/rely  0/0 serno 50-54 EIGRP: Sending UPDATE on Serial0 nbr 10.1.6.1   AS 1, Flags 0x0, Seq 46/66 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 50-54 EIGRP: Received UPDATE on Serial0 nbr 10.1.6.1   AS 1, Flags 0x0, Seq 67/46 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

Flags, in the debug messages, indicate the state of the flags in the EIGRP packet header (see the section "EIGRP Packet Header" later in this chapter). 0x0 indicates that no flags are set. 0x1 indicates that the initialization bit is set. This flag is set when the enclosed route entries are the first in a new neighbor relationship. 0x2 indicates that the conditional receive bit is set. This flag is used in the proprietary Reliable Multicasting algorithm:

  • Seq is the Packet Sequence Number/Acknowledged Sequence Number.

  • idbq indicates packets in the input queue/packets in the output queue of the interface.

  • iidbq indicates unreliable multicast packets awaiting transmission/reliable multicast packets awaiting transmission on the interface.

  • peerQ indicates unreliable unicast packets awaiting transmission/reliable unicast packets awaiting transmission on the interface.

  • serno is a pointer to a doubly linked serial number for the route. This is used by an internal (and proprietary) mechanism for tracking the correct route information in a rapidly changing topology.

Diffusing Computation: Example 2

This example focuses on Wright and its route to subnet 10.1.7.0. Although the combination of input events portrayed here (the delay of a link changing twice during a diffusing computation) is unlikely to occur in real life, the example shows how DUAL handles multiple metric changes.

In Figure 7-13, the cost of the link between Wright and Langley changes from 2 to 10. The distance to 10.1.7.0 via Langley now exceeds Wright's FD, causing that router to begin a local computation. The metric is updated, and Wright sends updates to all its neighbors except the neighbor on the link whose cost changed (Figure 7-14).

Figure 7-13. Cayley's route to 10.1.7.0 becomes passive, and an update is sent to Lilienthal.


Figure 7-14. Wright sends updates containing the new metric to all neighbors except Langley.


Note that Langley was the only feasible successor to subnet 10.1.7.0 because Chanute's locally calculated metric is higher than Wright's FD (1024 > 768). The metric increase on the Wright-Langley link causes Wright to look in its topology table for a new successor. Because the only feasible successor that Wright can find in its topology table is Langley, the route becomes active. Queries are sent to the neighbors (Figure 7-15).

Figure 7-15. Wright's route to 10.1.7.0 becomes active, and it queries its neighbors for a feasible successor. In response to the earlier update from Wright, Cayley makes its route active and queries its neighbors; also, Chanute changes its metric and sends updates.


At the same time, the updates sent by Wright in Figure 7-14 cause Cayley, Lilienthal, and Chanute to perform a local calculation.

At Cayley, the route via Wright now exceeds Cayley's FD (2816 > 1024). The route goes active and queries are sent to the neighbors.

Lilienthal is using Cayley as a successor and in Figure 7-15 has not yet received the query from Cayley. Therefore, Lilienthal merely recalculates the metric of the path via Wright, finds that it no longer meets the FC, and drops the path from the topology table.

At Chanute, Wright is the successor. Because Wright's advertised distance no longer meets the FC at Chanute (2816 > 1024) and because Chanute does have a feasible successor (refer to Example 7-11), Wright is deleted from Chanute's topology table. Langley becomes the successor at Chanute; the metric is updated, and Chanute sends updates to its neighbors (refer to Figure 7-15). The route at Chanute never becomes active.

Cayley, Lilienthal, and Chanute each respond differently to the queries from Wright (Figure 7-16).

Figure 7-16. Cayley (a) replies to Wright's query. Lilienthal (b) replies to Wright's query and (c) goes active for the route, sending queries in response to Cayley's query. Chanute (d) replies to Wright's query. Wright (e) replies to Cayley's query.


Cayley is already active. Because the input event is a query from the successor, the query origin flag will be 2 (O=2) (refer to Figure 7-7 and Table 7-2).

Lilienthal, upon the receipt of Wright's query, sends a response with its distance via Cayley. However, just after the reply is sent, Lilienthal receives the query from Cayley. The FD is exceeded, the metric is updated, and the route goes active. Lilienthal queries its neighbors.

Chanute, which has already switched to Langley as its successor, merely sends a reply.

While all this is going on, Figure 7-16 shows that the cost of the link between Wright and Langley again increases, from 10 to 20. Wright will recalculate the metric to 10.1.7.0 based on this new cost, but because the route is active, neither the FD nor the distance it advertises will change until the route becomes passive.

According to Figure 7-7 and Table 7-2, an increase in the distance to the destination while the route is active will cause O=0 (Figure 7-17). Wright responds to the query from Lilienthal. The distance it reports is the distance it had when the route first became active (remember, the advertised distance cannot change while the route is active). Cayley also sends a reply to Lilienthal's query.

Figure 7-17. Wright cannot change the metric it advertises until the route becomes passive.


Lilienthal, having received replies to all its queries, will transition the route to passive (Figure 7-18). A new FD is set for the route. Cayley remains the successor because its advertised route is lower than the FD at Lilienthal. Lilienthal also sends a reply to Cayley's query.

Figure 7-18. Having received the last expected reply, Lilienthal changes its route to the passive state (r=0, O=1).


Figure 7-18 also shows that the distance has changed again, from 20 to 15. Wright recalculates its local distance for the route again, to 4096 (Figure 7-19). If it were to receive a query before going passive, the route would still be advertised with a distance of 2816the distance when the route went active.

Figure 7-19. Having received its last expected reply, Cayley changes its route to the passive state.


When Cayley receives the reply to its query, its route to 10.1.7.0 also becomes passive (Figure 7-19) and a new FD is set. Although Wright's locally calculated metric is 4096, the last metric it advertised was 2816. Therefore, Wright meets the FC at Cayley and becomes the successor to 10.1.7.0. A reply is sent to Wright.

In Figure 7-20, Wright has received a reply to every query it sent, and its route becomes passive. It chooses Chanute as its new successor and changes the FD to the sum of Chanute's advertised distance and the cost of the link to that neighbor. Wright sends an update to all its neighbors, advertising the new locally calculated metric.

Figure 7-20. Wright transitions to passive, chooses Chanute as the successor, changes the FD, and updates all neighbors.


Cayley is already using Wright as the successor. When it receives the update from Wright with a lower cost, it changes its locally calculated metric and FD accordingly and updates its neighbors (Figure 7-21).

Figure 7-21. Cayley recalculates its metric, changes the FD based on the lower cost advertised by Wright, and updates its neighbors.


The update from Cayley has no effect at Wright because it does not satisfy the FC there. At Lilienthal the update causes a local computation. Lilienthal lowers the metric, lowers the FD, and updates its neighbors (Figure 7-22).

Figure 7-22. Lilienthal recalculates its metric, changes the FD based on the update from Cayley, and updates its neighbors.


Although they are rather elaborate and might take several readings to fully understand, this and the previous example contain the important core behavior of diffusing computations:

  • Any time an input event occurs, perform a local calculation.

  • If one or more feasible successors are found in the topology table, take the ones with the lowest metric cost as the successors.

  • If no feasible successor can be found, make the route active and query the neighbors for a feasible successor.

  • Keep the route active until all queries are answered by reply or by the expiration of the active timer.

  • If the diffusing calculation does not result in the discovery of a feasible successor, declare the destination unreachable.

EIGRP Packet Formats

The IP header of an EIGRP packet specifies protocol number 88, and the maximum length of the packet will be the IP maximum transmission unit (MTU) of the interface on which it is transmittedusually 1500 octets. Following the IP header is an EIGRP header followed by various Type/Length/Value (TLV) triplets. These TLVs will not only carry the route entries but also may provide fields for the management of the DUAL process, multicast sequencing, and IOS software versions.

EIGRP Packet Header

Figure 7-23 shows the EIGRP header, which begins every EIGRP packet.

Figure 7-23. EIGRP packet header.


  • Version specifies the particular version of the originating EIGRP process. The version of the EIGRP process itself has not changed since its release.

  • Opcode specifies the EIGRP packet type, as shown in Table 7-3. Although the IPX SAP packet type is included in the table, a discussion of IPX EIGRP is outside the scope of this book.

    Table 7-3. EIGRP packet types.

    Opcode

    Type

    1

    Update

    3

    Query

    4

    Reply

    5

    Hello

    6

    IPX SAP

    10

    SIA Query

    11

    SIA Reply


  • Checksum is a standard IP checksum. It is calculated for the entire EIGRP packet, excluding the IP header.

  • Flags currently include just two flags. The right-most bit is Init, which when set (0x00000001) indicates that the enclosed route entries are the first in a new neighbor relationship. The second bit (0x00000002) is the Conditional Receive bit, used in the proprietary Reliable Multicasting algorithm.

  • Sequence is the 32-bit sequence number used by the RTP.

  • ACK is the 32-bit sequence number last heard from the neighbor to which the packet is being sent. A Hello packet with a nonzero ACK field will be treated as an ACK packet rather than as a Hello. Note that an ACK field will only be nonzero if the packet itself is unicast because acknowledgments are never multicast.

  • Autonomous System Number is the identification number of the EIGRP domain.

Following the header are the TLVs, whose various types are listed in Table 7-4. IPX and AppleTalk types are included, although they are not discussed in this book. Each TLV includes one of the two-octet type numbers listed in Table 7-4, a two-octet field specifying the length of the TLV, and a variable field whose format is determined by the type.

Table 7-4. Type/Length/Value (TLV) types.

Number

TLV Type

General TLV Types

0x0001

EIGRP Parameters

0x0003

Sequence

0x0004

Software Version[*]

0x0005

Next Multicast Sequence

IP-Specific TLV Types

0x0102

IP Internal Routes

0x0103

IP External Routes

AppleTalk-Specific TLV Types

0x0202

AppleTalk Internal Routes

0X0203

AppleTalk External Routes

0x0204

AppleTalk Cable Configuration

IPX-Specific TLV Types

0x0302

IPX Internal Routes

0x0303

IPX External Routes


[*] This packet indicates whether the older software release is running (software version 0) or the newer release, as of IOS 10.3(11), 11.0(8), and 11.1(3), is running (version 1).

General TLV Fields

These TLVs carry EIGRP management information and are not specific to any one routed protocol. The Parameters TLV, which is used to convey metric weights and the hold time, is shown in Figure 7-24. The Sequence, Software Version, and Next Multicast Sequence TLVs are used by the Cisco proprietary Reliable Multicast algorithm and are beyond the scope of this book.

Figure 7-24. EIGRP Parameters TLV.


IP-Specific TLV Fields

Each Internal and External Routes TLV contains one route entry. Every Update, Query, and Reply packet contains at least one Routes TLV.

The Internal and External Routes TLVs include metric information for the route. As noted earlier, the metrics used by EIGRP are the same metrics used by IGRP, although scaled by 256.

IP Internal Routes TLV

An internal route is a path to a destination within the EIGRP autonomous system. The format of the Internal Routes TLV is shown in Figure 7-25.

Figure 7-25. The IP Internal Routes TLV.


  • Next Hop is the next-hop IP address. This address might or might not be the address of the originating router.

  • Delay is the sum of the configured delays expressed in units of 10 microseconds. Notice that unlike the 24-bit delay field of the IGRP packet, this field is 32 bits. This larger field accommodates the 256 multiplier used by EIGRP. A delay of 0xFFFFFFFF indicates an unreachable route.

  • Bandwidth is 256 x BWIGRP(min), or 2,560,000,000 divided by the lowest configured bandwidth of any interface along the route. Like Delay, this field is also eight bits larger than the IGRP field.

  • MTU is the smallest Maximum Transmission Unit of any link along the route to the destination. Although an included parameter, it has never been used in the calculation of metrics.

  • Hop Count is a number between 0x01 and 0xFF indicating the number of hops to the destination. A router will advertise a directly connected network with a hop count of 0; subsequent routers will record and advertise the route relative to the next-hop router.

  • Reliability is a number between 0x01 and 0xFF that reflects the total outgoing error rates of the interfaces along the route, calculated on a five-minute exponentially weighted average. 0xFF indicates a 100 percent reliable link.

  • Load is also a number between 0x01 and 0xFF, reflecting the total outgoing load of the interfaces along the route, calculated on a five-minute exponentially weighted average. 0x01 indicates a minimally loaded link.

  • Reserved is an unused field and is always 0x0000.

  • Prefix Length specifies the number of network bits of the address mask. Destination is the destination address of the route. Although the field is shown as a three-octet field in Figure 7-25 and Figure 7-26 (see next section), the field varies with the specific address. For example, if the route is to 10.1.0.0/16, the prefix length will be 16 and the destination will be a two-octet field containing 10.1. If the route is to 192.168.17.64/27, the prefix length will be 27 and the destination will be a four-octet field containing 192.168.16.64. If this field is not exactly three octets, the TLV will be padded with zeros to make it end on a four-octet boundary.

    Figure 7-26. The IP External Routes TLV.


IP External Routes TLV

An external route is a path that leads to a destination outside of the EIGRP autonomous system and that has been redistributed into the EIGRP domain. Figure 7-26 shows the format of the External Routes TLV:

  • Next Hop is the next-hop IP address. On a multiaccess network, the router advertising the route might not be the best next-hop router to the destination. For example, an EIGRP-speaking router on an Ethernet link might also be speaking BGP and might be advertising a BGP-learned route into the EIGRP autonomous system. Because other routers on the link do not speak BGP, they might have no way of knowing that the interface to the BGP speaker is the best next-hop address. The Next Hop field allows the "bilingual" router to tell its EIGRP neighbors, "Use address A.B.C.D as the next hop instead of using my interface address."

  • Originating Router is the IP address or router ID of the router that redistributed the external route into the EIGRP autonomous system.

  • Originating Autonomous System Number is the autonomous system number of the router originating the route.

  • Arbitrary Tag may be used to carry a tag set by route maps. See Chapter 14 for information on he use of route maps.

  • External Protocol Metric is, as the name implies, the metric of the external protocol. This field is used, when distributing with IGRP, to track the IGRP metric.

  • Reserved is an unused field and is always 0x0000.

  • External Protocol ID specifies the protocol from which the external route was learned. Table 7-5 lists the possible values of this field.

    Table 7-5. Values of the External Protocol ID field.

    Code

    External Protocol

    0x01

    IGRP

    0x02

    EIGRP

    0x03

    Static Route

    0x04

    RIP

    0x05

    Hello

    0x06

    OSPF

    0x07

    IS-IS

    0x08

    EGP

    0x09

    BGP

    0x0A

    IDRP

    0x0B

    Connected Link


  • Flags currently constitute just two flags. If the right-most bit of the eight-bit field is set (0x01), the route is an external route. If the second bit is set (0x02), the route is a candidate default route. Default routes are discussed in Chapter 12.

The remaining fields describe the metrics and the destination address. The descriptions of these fields are the same as those given in the discussion of the Internal Routes TLV.

Address Aggregation

Chapter 1, "Routing Basics," introduced the practice of subnetting, in which the address mask is extended into the host space to address multiple data links under one major network address. Chapter 6 introduced the practice of variable-length subnet masking, in which the address mask is extended even more to create subnets within subnets.

From an opposite perspective, a subnet address may be thought of as a summarization of a group of sub-subnets. And a major network address may be thought of as a summarization of a group of subnet addresses. In each case, the summarization is achieved by reducing the length of the address mask.

Address aggregation takes summarization a step further by breaking the class limits of major network addresses. An aggregate address represents a numerically contiguous group of network addresses, known as a supernet.[13] Figure 7-27 shows an example of an aggregate address.

[13] An aggregate is, more correctly, any summarized group of addresses. For clarity, in this book the term aggregate refers to a summarization of a group of major network addresses.

Figure 7-27. This group of network addresses can be represented with a single aggregate address, or subnet.


Figure 7-28 shows how the aggregate address of Figure 7-27 is derived. For a group of network addresses, find the bits that are common to all of the addresses and mask these bits. The masked portion is the aggregate address.

Figure 7-28. The aggregate address is derived by masking all the common bits of a group of numerically contiguous network addresses.


When designing a supernet, it is important that the member addresses should form a complete, contiguous set of the formerly masked bits. In Figure 7-28, for example, the 20-bit mask of the aggregate address is four bits less than the mask of the member addresses. Of the four "difference" bits, notice that they include every possible bit combination from 0000 to 1111. Failure to follow this design rule could make the addressing scheme confusing, could reduce the efficiency of aggregate routes, and might lead to routing loops and black holes.

The obvious advantage of summary addressing is the conservation of network resources. Bandwidth is conserved by advertising fewer routes, and CPU cycles are conserved by processing fewer routes. Most important, memory is conserved by reducing the size of the route tables.

Classless routing, VLSM, and aggregate addressing together provide the means to maximize resource conservation by building address hierarchies. Unlike IGRP, EIGRP supports all of these addressing strategies. In Figure 7-29, the engineering division of Treetop Aviation has been assigned 16 class C addresses. These addresses have been assigned to the various departments according to need.

Figure 7-29. At Treetop Aviation, several departments within a larger division are aggregating addresses. In turn, the entire division can be advertised with a single aggregate address (192.168.16.0/20).


The aggregate addresses of the engines, electrical, and hydraulics departments are themselves aggregated into a single address, 192.168.16.0/21. That address and the aggregate address of the airframe department are aggregated into the single address 192.168.16.0/20, which represents the entire engineering division.

Other divisions may be similarly represented. For example, if Treetop Aviation had a total of eight divisions and if those divisions were all addressed similarly to the engineering division, the backbone router at the top of the hierarchy might have only eight routes (Figure 7-30).

Figure 7-30. Although there are 128 major network addresses and possibly more than 32,000 hosts in this network, the backbone router has only eight aggregate addresses in its route table.


The hierarchical design is continued within each department of each division by subnetting the individual network addresses. VLSM may be used to further divide the subnets. The routing protocols will automatically summarize the subnets at network boundaries, as discussed in previous chapters.

Address aggregation also allows both address conservation and address hierarchies in the Internet. With the exponential growth of the Internet, two increasing concerns have been the depletion of available IP addresses (particularly class B addresses) and the huge databases needed to store the Internet routing information.

A solution to this problem is Classless Interdomain Routing (CIDR).[14] Under CIDR, aggregates of class C addresses are allocated by the IANA to the various worldwide address assignment authorities such as Asia Pacific Network Information Centre (APNIC) in Asia, American Registry for Internet Numbers (ARIN) in North America, and Réseaux IP Européens (RIPE) in Europe. The aggregates are organized geographically, as shown in Table 7-6.

[14] V. Fuller, T. Li, J. I. Yu, and K. Varadhan. "Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy," RFC 1519. September 1993.

Table 7-6. CIDR address allocations by geographic region.

Region

Address Range

Multiregional

192.0.0.0193.255.255.255

Europe

194.0.0.0195.255.255.255

Others

196.0.0.0197.255.255.255

North America

198.0.0.0199.255.255.255

Central/South America

200.0.0.0201.255.255.255

Pacific Rim

202.0.0.0203.255.255.255

Others

204.0.0.0205.255.255.255

Others

206.0.0.0207.255.255.255


The address assignment authorities in turn divide their portions among the regional Internet Service Providers (ISPs). When an organization applies for an IP address and requires addressing for fewer than 32 subnets and 4096 hosts, it will be given a contiguous group of class C addresses called a CIDR block.

In this way, the Internet routers of individual organizations might advertise a single summary address to their ISP. The ISP, in turn, aggregates all of its addresses, and ideally all ISPs in a region of the world may be summarized by the addresses of Table 7-6. Knowing that the current size of the Internet routing table is approaching 200,000 routes, it is obvious that CIDR has not been adhered to as well as intended. Nonetheless, the concept is a good one. Similar efforts are under way to constrain IPv6 address assignments geographically; we can only hope that the efforts are more successful than they were with IPv4.

EIGRP and IPv6

As the second edition of this book is being written, EIGRP does not support IPv6. However, an effort to extend EIGRP for IPv6 support is under way, and it is expected that by the time you are reading this chapter that extension will be available. Because EIGRP packets use TLVs to carry data, extending the protocol to support IPv6 will be a simple matter of adding IPv6-specific TLVs.




CCIE Professional Development Routing TCP/IP (Vol. 12005)
Routing TCP/IP, Volume 1 (2nd Edition)
ISBN: 1587052024
EAN: 2147483647
Year: 2005
Pages: 233

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net