Home > Articles

This chapter is from the book

EIGRP Terminology and Operation

EIGRP sends out five different types of packets—hello, update, query, reply, and acknowledge (ACK)—that are used to establish the initial adjacency between neighbors and to keep the topology and routing tables current. When troubleshooting an EIGRP network, network administrators must understand what EIGRP packets are used for and how they are exchanged. For example, if routers running EIGRP do not form neighbor relationships, those routers cannot exchange EIGRP updates with each other. Without EIGRP routing updates, users cannot connect to services across the internetwork. This section explains EIGRP terminology, followed by an explanation of the mechanisms for creating the various EIGRP tables and a discussion about the five types of EIGRP packets. This section also explores how EIGRP routers become neighbors, initial route discovery, route selection, and how the DUAL algorithm functions.

EIGRP Terminology

The following terms are related to EIGRP and are used throughout the rest of this chapter:

  • Neighbor table—EIGRP routers use hello packets to discover neighbors. When a router discovers and forms an adjacency with a new neighbor, it includes the neighbor's address and the interface through which it can be reached in an entry in the neighbor table. This table is comparable to the neighborship (adjacency) database used by link-state routing protocols (as described in Chapter 4). It serves the same purpose—ensuring bidirectional communication between each of the directly connected neighbors. EIGRP keeps a neighbor table for each network protocol supported; in other words, the following tables could exist: an IP neighbor table, an IPX neighbor table, and an AppleTalk neighbor table.
  • Topology table—When the router dynamically discovers a new neighbor, it sends an update about the routes it knows to its new neighbor and receives the same from the new neighbor. These updates populate the topology table. The topology table contains all destinations advertised by neighboring routers; in other words, each router stores its neighbors' routing tables in its EIGRP topology table. If a neighbor is advertising a destination, it must be using that route to forward packets; this rule must be strictly followed by all distance vector protocols. An EIGRP router maintains a topology table for each network protocol configured (IP, IPX, and AppleTalk).
  • Advertised distance (AD) and feasible distance (FD)—DUAL uses distance information, known as a metric or cost, to select efficient, loop-free paths. The lowest-cost route is calculated by adding the cost between the next-hop router and the destination—referred to as the advertised distance—to the cost between the local router and the next-hop router. The sum of these costs is referred to as the feasible distance.
  • Successor—A successor, also called a current successor, is a neighboring router that has a least-cost path to a destination (the lowest FD) that is guaranteed not to be part of a routing loop; successors are offered to the routing table to be used for forwarding packets. Multiple successors can exist if they have the same FD.
  • Routing table—The routing table holds the best routes to each destination and is used for forwarding packets. Successor routes are offered to the routing table. As discussed in Chapter 2, "Routing Principles," if a router learns more than one route to exactly the same destination from different routing sources, it uses the administrative distance to determine which route to keep in the routing table. By default, up to 4 routes to the same destination with the same metric can be added to the routing table (recall that the router can be configured to accept up to 16 per destination). The router maintains one routing table for each network protocol configured.
  • Feasible successor (FS)—Along with keeping least-cost paths, DUAL keeps backup paths to each destination. The next-hop router for a backup path is called the feasible successor. To qualify as a feasible successor, a next-hop router must have an AD less than the FD of the current successor route; in other words, a feasible successor is a neighbor that is closer to the destination, but it is not the least-cost path and, thus, is not used to forward data. Feasible successors are selected at the same time as successors but are kept only in the topology table. The topology table can maintain multiple feasible successors for a destination.

    If the route via the successor becomes invalid (because of a topology change) or if a neighbor changes the metric, DUAL checks for feasible successors to the destination. If a feasible successor is found, DUAL uses it, thereby avoiding recomputing the route. If no suitable feasible successor exists, a recomputation must occur to determine the new successor. Although recomputation is not processor-intensive, it does affect convergence time, so it is advantageous to avoid unnecessary recomputations.

Populating EIGRP Tables

Figure 3-3 illustrates the three tables that EIGRP uses in its operation:

  • The neighbor table lists adjacent routers
  • The topology table lists all the learned routes to each destination
  • The routing table contains the best route (the successor route) to each destination.
Figure 3-3

Figure 3-3 EIGRP Maintains a Neighbor Table, a Topology Table, and a Routing Table

The neighbor table includes the address of each neighbor and the interface through which it can be reached.

The neighbor-table entry also includes information required by RTP. Sequence numbers are employed to match acknowledgments with data packets, and the last sequence number received from the neighbor is recorded, to detect out-of-order packets. A transmission list is used to queue packets for possible retransmission on a per-neighbor basis. Round-trip timers are kept in the neighbor-table entry to estimate an optimal retransmission interval.

Each router forwards a copy of its IP routing table to all its adjacent EIGRP neighbors, as specified in its EIGRP neighbor table. Each router then stores the routing tables of the adjacent neighbors in its EIGRP topology table (database). The topology table also maintains the metric that each neighbor advertises for each destination (the AD) and the metric that this router would use to reach the destination via that neighbor (the FD). The show ip eigrp topology all-links command displays all the IP entries in the topology table, while the show ip eigrp topology command displays only the successor(s) and feasible successor(s) for IP routes.

The topology table is updated when a directly connected route or interface changes or when a neighboring router reports a change to a route.

A topology-table entry for a destination can exist in one of two states: active or passive.

If feasible successors are always available, a destination never has to go into the active state, thereby avoiding a recomputation.

A recomputation occurs when the current route to a destination, the successor, goes down and there are no feasible successors for the destination. The router initiates the recomputation by sending a query packet to each of its neighboring routers. If the neighboring router has a route for the destination, it will send a reply packet; if it does not have a route, it sends a query packet to its neighbors. In this case, the route is also in the active state in the neighboring router. While a destination is in the active state, a router cannot change the routing table information for the destination. After a router has received a reply from each neighboring router, the topology table entry for the destination returns to the passive state.

Each router then examines its EIGRP topology table and determines the best route and other feasible routes to every destination network. A router compares all FDs to reach a specific network and then selects the route with the lowest FD and places it in the IP routing table; this is the successor route. The FD for the chosen successor route becomes the EIGRP routing metric to reach that network in the routing table.

EIGRP Packets

EIGRP uses the following five types of packets:

  • Hello—Hello packets are used for neighbor discovery. They are sent as multicasts and do not require an acknowledgment. (They carry an acknowledgment number of 0.)
  • Update—Update packets contain route change information. An update is sent to communicate the routes that a particular router has used to converge; an update is sent only to affected routers. These updates are sent as multicasts when a new route is discovered, and when convergence is completed (when the route becomes passive). To synchronize topology tables, updates are sent as unicasts to neighbors during their EIGRP startup sequence. Updates are sent reliably.
  • Query—When a router is performing route computation and does not have a feasible successor, it sends a query packet to its neighbors, asking if they have a successor to the destination. Queries are normally multicast but can be retransmitted as unicast packets in certain cases; they are sent reliably.
  • Reply—A reply packet is sent in response to a query packet. Replies are unicast to the originator of the query and are sent reliably.
  • ACK—The ACK is used to acknowledge updates, queries, and replies. ACK packets are unicast hello packets and contain a nonzero acknowledgment number. (Note that hello and ACK packets do not require acknowledgment.)

The hello packet is the first type exchanged by EIGRP routers. The following section provides details of the hello protocol and how hello packets are used. The details of how the other packet types are used are provided throughout the rest of the chapter.

EIGRP Hello Packets

Through the hello protocol, an EIGRP router dynamically discovers other EIGRP routers directly connected to it. The router sends hello packets out of interfaces configured for EIGRP using the EIGRP multicast address 224.0.0.10. When an EIGRP router receives a hello packet from a router belonging to the same autonomous system (AS), it establishes a neighbor relationship (adjacency).

The time interval of hello packets varies depending on the medium. Hello packets are released every 5 seconds on a LAN link such as Ethernet, Token Ring, and FDDI. The default interval is also set to 5 seconds for point-to-point links such as PPP, High-Level Data Link Control (HDLC), point-to-point Frame Relay, and Asynchronous Transfer Mode (ATM) subinterfaces, and for multipoint circuits with bandwidth greater than T1, including Integrated Digital Services Network (ISDN) Primary Rate Interface (PRI), ATM, and Frame Relay. Hello packets are sent out less frequently on lower-speed links, such as multipoint circuits with a bandwidth less than or equal to T1, including ISDN Basic Rate Interface (BRI), Frame Relay, ATM, and X.25. Hellos are generated at 60-second intervals on these types of interfaces.

You can adjust the rate at which hello packets are sent, called the hello interval, on a per-interface basis with the ip hello-interval eigrp as-number seconds interface configuration command.

Hello packets include the hold time.

The hold-time interval is set by default to 3 times the hello interval. Therefore, the default hold-time value is 15 seconds on LAN and fast WAN interfaces and 180 seconds on slower WAN interfaces. You can adjust the hold time with the ip hold-time eigrp as-number seconds interface configuration command.

If a packet is not received before the expiration of the hold time, the neighbor adjacency is deleted, and all topology table entries learned from that neighbor are removed, as if the neighbor had sent an update stating that all the routes are unreachable. If the neighbor is a successor for any destination networks, those networks are removed from the routing table, and alternative paths, if available, are computed. This lets the routes quickly reconverge if an alternative feasible route is available.

EIGRP Neighbors

The possibility exists for two routers to become EIGRP neighbors even though the hello and hold time values do not match; this means that the hello interval and hold-time values can be set independently on different routers.

Secondary addresses can be applied to interfaces to solve particular addressing issues, although all routing overhead traffic is generated through the primary interface address. EIGRP will not build peer relationships over secondary addresses, because all EIGRP traffic uses the interface's primary address. To form an EIGRP adjacency, all neighbors use their primary address as the source IP address of their EIGRP packets. Adjacency between EIGRP routers takes place if the primary address of each neighbor is part of the same IP subnet. In addition, peer relationships are not formed if the neighbor resides in a different autonomous system or if the metric-calculation mechanism constants (the K values) are misaligned on that link. (K values are discussed in the "EIGRP Metric Calculation" section later in this chapter.)

Neighbor Table

An EIGRP router multicasts hello packets to discover neighbors; it forms an adjacency with these neighbors so that it can exchange route updates. Only adjacent routers exchange routing information. Each router builds a neighbor table from the hello packets it receives from adjacent EIGRP routers running the same network layer protocol. EIGRP maintains a neighbor table for each configured network-layer protocol. You can display the IP neighbor table with the show ip eigrp neighbors command, as shown in Example 3-1.

Example 3-1. Sample Output for the show ip eigrp neighbors Command

R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address        Interface   Hold  Uptime   SRTT  RTO  Q  Seq
                               (sec)          (ms)      Cnt Num
0   192.168.1.102  Se0/0/1     10    00:07:22   10  2280  0  5
R1#

This table includes the following key elements:

  • H (handle)—A number used internally by the Cisco IOS to track a neighbor.
  • Address—The neighbor's network-layer address.
  • Interface—The interface on this router through which the neighbor can be reached.
  • Hold Time—The maximum time, in seconds, that the router waits to hear from the neighbor without receiving anything from a neighbor before considering the link unavailable. Originally, the expected packet was a hello packet, but in current Cisco IOS software releases, any EIGRP packets received after the first hello from that neighbor resets the timer.
  • Uptime—The elapsed time, in hours, minutes, and seconds since the local router first heard from this neighbor.
  • Smooth Round Trip Timer (SRTT)—The average number of milliseconds it takes for an EIGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet. This timer is used to determine the retransmit interval, also known as the retransmit timeout (RTO).
  • RTO—The amount of time, in milliseconds, that the router waits for an acknowledgment before retransmitting a reliable packet from the retransmission queue to a neighbor.
  • Queue count—The number of packets waiting in the queue to be sent out. If this value is constantly higher than 0, a congestion problem might exist. A 0 indicates that no EIGRP packets are in the queue.
  • Seq Num—The sequence number of the last update, query, or reply packet that was received from this neighbor.

EIGRP Reliability

EIGRP's reliability mechanism ensures delivery of critical route information to neighboring routers. This information is required to allow EIGRP to maintain a loop-free topology. For efficiency, only certain EIGRP packets are transmitted reliably.

Recall that RTP is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. RTP supports an intermixed transmission of multicast and unicast packets.

RTP ensures that ongoing communication is maintained between neighboring routers. As such, a retransmission list is maintained for each neighbor. This list indicates packets not yet acknowledged by a neighbor within the RTO. It is used to track all the reliable packets that were sent but not acknowledged.

The use of reliable multicast packets is efficient. However, a potential delay exists on multiaccess media where multiple neighbors reside. The next reliable multicast packet cannot be transmitted until all peers have acknowledged the previous multicast. If one or more peers are slow to respond, this adversely affects all peers by delaying the next transmission. RTP is designed to handle such exceptions: Neighbors that are slow to respond to multicasts have the unacknowledged multicast packets retransmitted as unicasts. This allows the reliable multicast operation to proceed without delaying communication with other peers, helping to ensure that convergence time remains low in the presence of variable-speed links.

The multicast flow timer determines how long to wait for an ACK packet before switching from multicast to unicast. The RTO determines how long to wait between the subsequent unicasts. The EIGRP process for each neighbor calculates both the multicast flow timer and RTO, based on the SRTT. The formulas for the SRTT, RTO, and multicast flow timer are Cisco-proprietary. In a steady-state network where no routes are flapping, EIGRP waits the specified hold-time interval before it determines that an EIGRP neighbor adjacency is down. Therefore, by default, EIGRP waits up to 15 seconds on high-speed links and up to 180 seconds on low-speed, multipoint links. When EIGRP determines that a neighbor is down and the router cannot reestablish the adjacency, the routing table removes all networks that could be reached through that neighbor. The router attempts to find alternative routes to those networks so that convergence can occur. The 180-second hold time on low-speed links can seem excessive, but it accommodates the slowest-speed multipoint links, which are generally connected to less-critical remote sites. In some networks with mission-critical or time-sensitive applications (such as IP telephony), even on high-speed links, 15 seconds is too long. The point to remember is that other conditions can override the hold time and allow the network to converge quickly.

For example, if the network is unstable and routes are flapping elsewhere because a remote site is timing out on its adjacency, EIGRP hold timers begin counting down from 180 seconds. When the upstream site sends the remote site an update, and the remote site does not acknowledge the update, the upstream site attempts 16 times to retransmit the update. The retransmission occurs each time the RTO expires. After 16 retries, the router resets the neighbor relationship. This causes the network to converge faster than waiting for the hold time to expire.

Initial Route Discovery

EIGRP combines the process of discovering neighbors and learning routes. Figure 3-4 illustrates the initial route discovery process.

Figure 3-4

Figure 3-4 Initial Route Discovery

The following describes the initial route discovery process:

  1. A new router (Router A) comes up on the link and sends out a hello packet through all of its EIGRP-configured interfaces.
  2. Routers receiving the hello packet on one interface (Router B in Figure 3-4) reply with update packets that contain all the routes they have in their routing table, except those learned through that interface (because of the split horizon rule). Router B sends an update packet to Router A, but a neighbor relationship is not established until Router B sends a hello packet to Router A. The update packet from Router B has the initial bit set, indicating that this is the initialization process. The update packet contains information about the routes that the neighbor (Router B) is aware of, including the metric that the neighbor is advertising for each destination.
  3. After both routers have exchanged hellos and the neighbor adjacency is established, Router A replies to Router B with an ACK packet, indicating that it received the update information.
  4. Router A inserts the update packet information in its topology table. The topology table includes all destinations advertised by neighboring (adjacent) routers. It is organized so that each destination is listed, along with all the neighbors that can get to the destination and their associated metrics.
  5. Router A then sends an update packet to Router B.
  6. Upon receiving the update packet, Router B sends an ACK packet to Router A.

After Router A and Router B successfully receive the update packets from each other, they are ready to chose the successor (best) and feasible successor (backup) routes in the topology table, and offer the successor routes to the routing table.

Route Selection

The EIGRP route selection process is perhaps what most distinguishes it from other routing protocols. EIGRP selects primary (successor) and backup (feasible successor) routes and injects those into the topology table. The primary (successor) routes are then moved to the routing table.

EIGRP supports several types of routes: internal, external, and summary. Internal routes originate within the EIGRP autonomous system. External routes are learned from another routing protocol or another EIGRP autonomous system. Summary routes are routes encompassing multiple subnets.

EIGRP uses DUAL to calculate the best route to a destination. DUAL selects routes based on the composite metric and ensures that the selected routes are loop-free. DUAL also calculates backup routes (feasible successor routes) to a destination that are loop-free. If the best route fails, EIGRP immediately uses a backup route without any need for holddown, because the feasible successor route (if one exists) is loop-free; this results in fast convergence.

EIGRP Metric Calculation

The EIGRP metric calculation can use five variables, but EIGRP uses only two by default:

  • Bandwidth—The smallest (slowest) bandwidth between the source and destination
  • Delay—The cumulative interface delay along the path

The following criteria, although available, are not commonly used, because they typically result in frequent recalculation of the topology table:

  • Reliability—The worst reliability between the source and destination, based on keepalives.
  • Loading—The worst load on a link between the source and destination based on the packet rate and the interface's configured bandwidth.
  • Maximum transmission unit (MTU)—The smallest MTU in the path. (MTU is included in the EIGRP update but is actually not used in the metric calculation.)

EIGRP calculates the metric by adding together weighted values of different variables of the path to the network in question. The default constant weight values are K1 = K3 = 1, and K2 = K4 = K5 = 0.

In EIGRP metric calculations, when K5 is 0 (the default), variables (bandwidth, bandwidth divided by load, and delay) are weighted with the constants K1, K2, and K3. The following is the formula used:

  • metric = (K1 * bandwidth) + [(K2 * bandwidth) / (256 – load)] + (K3 * delay)

If these K values are equal to their defaults, the formula becomes

  • metric = (1 * bandwidth) + [(0 * bandwidth) / (256 – load)] + (1 * delay)

    metric = bandwidth + [0] + delay

    metric = bandwidth + delay

If K5 is not equal to 0, the following additional operation is performed:

  • metric = metric * [K5 / (reliability + K4)]

K values are carried in EIGRP hello packets. Mismatched K values can cause a neighbor to be reset (only K1 and K3 are used, by default, in metric compilation). These K values should be modified only after careful planning; changing these values can prevent your network from converging and is generally not recommended.

EIGRP uses the same metric formula as IGRP, but EIGRP represents its metrics in a 32-bit format instead of the 24-bit representation used by IGRP. This representation allows a more granular decision to be made when determining the successor and feasible successor.

The EIGRP metric value ranges from 1 to 4,294,967,296. The IGRP metric value ranges from 1 to 16,777,216. EIGRP metrics are backward compatible with IGRP, as illustrated in Figure 3-5. When integrating IGRP routes into an EIGRP domain using redistribution, the router multiplies the IGRP metric by 256 to compute the EIGRP-equivalent metric. When sending EIGRP routes to an IGRP routing domain, the router divides each EIGRP metric by 256 to achieve the proper 24-bit metric.

Figure 3-5

Figure 3-5 Initial Route Discovery

EIGRP Metric Calculation Example

In Figure 3-6, Router A has two paths to reach Router D (and thus any networks behind Router D). The bandwidths (in kbps) and the delays (in tens of microseconds) of the various links are also shown.

Figure 3-6

Figure 3-6 EIGRP Metric Calculation Example

The least bandwidth along the top path (A → B → C → D) is 64 kbps. The EIGRP bandwidth calculation for this path is as follows:

  • bandwidth = (107 / least bandwidth in kbps) * 256

    bandwidth = (10,000,000 / 64) * 256 = 156,250 * 256 = 40,000,000

The delay through the top path is as follows:

  • delay = [(delay A → B) + (delay B → C) + (delay C → D)] * 256

    delay = [2000 + 2000 + 2000] * 256

    delay = 1,536,000

Therefore, the EIGRP metric calculation for the top path is as follows:

  • metric = bandwidth + delay

    metric = 40,000,000 + 1,536,000

    metric = 41,536,000

The least bandwidth along the lower path (A → X → Y → Z → D) is 256 kbps. The EIGRP bandwidth calculation for this path is as follows:

  • bandwidth = (107 / least bandwidth in kbps) * 256

    bandwidth = (10,000,000 / 256) * 256 = 10,000,000

The delay through the lower path is as follows:

  • delay = [(delay A → X) + (delay X → Y) + (delay Y → Z) + (delay Z → D)] * 256

    delay = [2000 + 2000 + 2000 + 2000] * 256

    delay = 2,048,000

Therefore, the EIGRP metric calculation for the lower path is as follows:

  • metric = bandwidth + delay

    metric = 10,000,000 + 2,048,000

    metric = 12,048,000

Router A therefore chooses the lower path, with a metric of 12,048,000, over the top path, with a metric of 41,536,000. Router A installs the lower path with a next-hop router of X and a metric of 12,048,000 in the IP routing table.

The bottleneck along the top path, the 64-kbps link, can explain why the router takes the lower path. This slow link means that the rate of transfer to Router D would be at a maximum of 64 kbps. Along the lower path, the lowest speed is 256 kbps, making the throughput rate up to that speed. Therefore, the lower path represents a better choice, such as to move large files quickly.

Routing Table and EIGRP DUAL

DUAL is the finite-state machine that selects which information is stored in the topology and routing tables. As such, DUAL embodies the decision process for all EIGRP route computations. It tracks all routes advertised by all neighbors; uses the metric to select an efficient, loop-free path to each destination; and inserts that choice in the routing table.

Advertised Distance and Feasible Distance

A router compares all FDs to reach a specific network in its topology table. The route with the lowest FD is placed in its IP routing table; this is the successor route. The FD for the chosen route becomes the EIGRP routing metric to reach that network in the routing table.

For example, in Figure 3-7, Routers A and B send their routing tables to Router C, whose tables are shown in the figure. Both Routers A and B have paths to network 10.1.1.0/24 (among many others that are not shown).

Figure 3-7

Figure 3-7 EIGRP Chooses the Route with the Lowest Feasible Distance

The routing table on Router A has an EIGRP metric of 1000 for 10.1.1.0/24. Therefore, Router A advertises 10.1.1.0/24 to Router C with a metric of 1000. Router C installs 10.1.1.0/24 from Router A in its EIGRP topology table with an AD of 1000. Router B has network 10.1.1.0/24 with a metric of 1500 in its IP routing table. Therefore, Router B advertises 10.1.1.0/24 to Router C with an AD of 1500. Router C places the 10.1.1.0/24 network from Router B in the EIGRP topology table with an AD of 1500.

Router C in Figure 3-7 has two entries to reach 10.1.1.0/24 in its topology table. The EIGRP metric for Router C to reach either Router A or B is 1000. This cost (1000) is added to the respective AD from each router, and the results represent the FDs that Router C must travel to reach network 10.1.1.0/24. Router C chooses the least-cost FD (2000) and installs it in its IP routing table as the best route to reach 10.1.1.0/24. The EIGRP metric in the routing table is the best FD from the EIGRP topology table.

Successor and Feasible Successor

A router is chosen as a successor because it has the lowest FD of all possible paths to that destination network. The successor is the next router in line to reach that destination. In other words, it is the router with the best path to reach that destination network.

An EIGRP router selects the best path to reach a given network and then installs the destination network, the metric to reach that network, the outbound interface to reach the next-hop router, and the IP address of the next-hop router into the IP routing table. If the EIGRP topology table has many entries that have an equal-cost FD to a given destination network, all successors (up to four by default) for that destination network are installed in the routing table.

All routing protocols can install only the next-hop router information in the routing table; information about the subsequent routers in the path is not put in the routing table. Each router relies on the next-hop router to make a reliable decision to reach a specific destination network. The hop-by-hop path through a network goes from one router to the next. Each router makes a path selection to reach a given network and installs the best next-hop address along the path to reach that destination network. A router trusts a route's successor (the best next-hop router) to send traffic toward that destination address.

The routing table is essentially a subset of the topology table; the topology table contains more detailed information about each route, any backup routes, and information used exclusively by DUAL.

FSs are selected at the same time the successors are identified. These FS routes are kept in the topology table; the topology table can retain multiple FS routes for a destination.

This requirement ensures that the FS cannot use a route through the local router (which would be a routing loop), because the AD through the FS is less than the best route through the local router. For example, as shown in Figure 3-8, Router B is an FS, because the AD through Router B (1500) is less than the FD of the current successor, Router A (2000).

Figure 3-8

Figure 3-8 Feasible Successor's AD Must Be Less Than the Successor's FD

When a router loses a route, it looks at the topology table for an FS. If one is available, the route does not go into an active state; rather, the best FS is promoted as the successor and is installed in the routing table. The FS can be used immediately, without any recalculation. If there are no FSs, a route goes into active state, and route computation occurs. Through this process, a new successor is determined (if there is one). The amount of time it takes to recalculate the route affects the convergence time.

Figure 3-9 illustrates another example. Router C's initial topology table is shown at the top of the figure. Router B is the successor for network 10.1.1.0/24, and Router D is the FS.

Figure 3-9

Figure 3-9 With a Feasible Successor, EIGRP Can Recover Immediately from Network Failures

In Figure 3-9, the link between Router B and Router C fails. Router C removes the route 10.1.1.0/24 through Router B from its routing table and searches the EIGRP topology table for an FS; Router D is an FS. Because Router D can still reach the network and does not send an update or query packet to inform Router C of the lost route, Router C immediately uses the path through Router D. Router C chooses this path because the AD through Router D (1500) is less than the FD of the best route, through Router B (2000); this path is guaranteed to be loop free.

DUAL Example

The mathematical formula to ensure that the FS is loop free requires that the AD of the backup route be less than the FD of the successor. When the AD of the second-best route is greater than or equal to the FD of the successor, an FS cannot be chosen. In this case, a discovery process that uses EIGRP queries and replies must be used to find any alternative paths to the lost networks.

The following example examines partial entries for network 10.1.1.0/24 in the topology tables for Routers C, D, and E in Figure 3-10, to give you a better understanding of EIGRP behavior. The partial topology tables shown in Figure 3-10 indicate the following:

  • AD—The advertised distance is equal to the cost of the path to network 10.1.1.0/24 as advertised by neighboring routers.
  • FD—The feasible distance is equal to the sum of the AD for a neighbor to reach 10.1.1.0/24, plus the metric to reach that neighbor.
  • Successor—The successor is the forwarding path used to reach network 10.1.1.0/24. The cost of this path is equal to the FD.
  • FS—The feasible successor is an alternative loop-free path to reach network 10.1.1.0/24.
Figure 3-10

Figure 3-10 DUAL Example, Step 1

The network shown in Figure 3-10 is stable and converged.

In Figure 3-11, Routers B and D detect a link failure. After being notified of the link failure, DUAL does the following, as shown in Figure 3-11:

  • At Router D, it marks the path to network 10.1.1.0/24 through Router B as unusable.
Figure 3-11

Figure 3-11 DUAL Example, Step 2

The following steps then occur, as shown in Figure 3-12:

  • At Router D, there is no FS to network 10.1.1.0/24, because the AD via Router C (3) is greater than the FD via Router B (2). Therefore, DUAL does the following:
    • — Sets the metric to network 10.1.1.0/24 as unreachable (–1 is unreachable).
    • — Because an FS cannot be found in the topology table, the route changes from the passive state to the active state. In the active state, the router sends out queries to neighboring routers looking for a new successor.
    • — Sends a query to Routers C and E for an alternative path to network 10.1.1.0/24.
    • — Marks Routers C and E as having a query pending (q).
  • At Router E, DUAL marks the path to network 10.1.1.0/24 through Router D as unusable.
  • At Router C, DUAL marks the path to network 10.1.1.0/24 through Router D as unusable.
Figure 3-12

Figure 3-12 DUAL Example, Step 3

The following steps then occur, as shown in Figure 3-13:

  • At Router D:
    • — DUAL receives a reply from Router C that indicates no change to the path to network 10.1.1.0/24.
    • — DUAL removes the query flag from Router C.
    • — DUAL stays active on network 10.1.1.0/24, awaiting a reply from Router E to its query (q).
  • At Router E, there is no FS to network 10.1.1.0/24, because the AD from Router C (3) is not less than the original FD (also 3).
    • — DUAL generates a query to Router C.
    • — DUAL marks Router C as query pending (q).
  • At Router C, DUAL marks the path to network 10.1.1.0/24 through Router E as unusable.
Figure 3-13

Figure 3-13 DUAL Example, Step 4

The following steps then occur, as shown in Figure 3-14:

  • At Router D, DUAL stays active on network 10.1.1.0/24, awaiting a reply from Router E (q).
  • At Router E:
    • — DUAL receives a reply from Router C indicating no change.
    • — It removes the query flag from Router C.
    • — It calculates a new FD and installs a new successor route in the topology table.
    • — It changes the route to network 10.1.1.0/24 from active to passive (converged).
Figure 3-14

Figure 3-14 DUAL Example, Step 5

The following steps then occur, as shown in Figure 3-15:

  • At Router D
    • — DUAL receives a reply from Router E.
    • — It removes the query flag from Router E.
    • — It calculates a new FD.
    • — It installs new successor routes in the topology table. Two routes (through Routers C and E) have the same FD, and both are marked as successors.
    • — It changes the route to network 10.1.1.0/24 from active to passive (converged).
Figure 3-15

Figure 3-15 DUAL Example, Step 6

The following steps then occur, as shown in Figure 3-16:

  • At Router D, two successor routes are in the topology table for network 10.1.1.0/24. Both successor routes are listed in the routing table, and equal-cost load balancing is in effect.
  • The network is stable and converged.
Figure 3-16

Figure 3-16 DUAL Example, Step 7

Figure 3-10, the original topology before the link failure, shows traffic from Router E passing through Routers D and B. In Figure 3-16, the new topology shows traffic from Routers D and E going through Routers C and B. Notice that throughout the entire convergence process, routes to network 10.1.1.0/24 become active only on Routers D and E. The route to network 10.1.1.0/24 on Router C remains passive because the link failure between Routers B and D does not affect the successor route from Router C to network 10.1.1.0/24.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020