The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to use the interior gateway protocol called Enhanced Interior Gateway Routing Protocol (EIGRP).
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
In a well-designed network, EIGRP scales well and provides extremely quick convergence times with minimal network traffic.
Some of the advantages of EIGRP are:
EIGRP is an enhanced distance vector protocol, which relies on the Diffused Update Algorithm (DUAL) to calculate the shortest path to a destination within a network.
There are two major revisions of EIGRP, versions 0 and 1. Cisco IOSĀ® versions earlier than 10.3(11), 11.0(8), and 11.1(3) run the earlier version of EIGRP; some of this information does not apply to older versions. The later version of in EIGRP is recommended because it includes many performance and stability enhancements.
A typical distance vector protocol saves this information when it computes the best path to a destination: the distance (total metric or distance, such as hop count) and the vector (the next hop). For instance, all the routers in the network in Figure 1 run Routing Information Protocol (RIP). Router Two chooses the path to Network A by examination of the hop count through each available path.
Figure 1
Since the path through Router Three is three hops, and the path through Router One is two hops, Router Two chooses the path through One and discards the information it learned through Three. If the path between Router One and Network A goes down, Router Two loses all connectivity with this destination until it times out the route of its routing table (three update periods, or 90 seconds), and Router Three re-advertises the route (which occurs every 30 seconds in RIP). With any hold-down time not included, it takes between 90 and 120 seconds for Router Two to switch the path from Router One to Router Three.
EIGRP does not depend on full periodic updates to re-converge, instead it builds a topology table from each of its neighbor advertisements (the data is not discarded) and converges by a search for a likely loop-free route in the topology table, or, if it does not find another route, it queries its neighbors. Router Two saves the information it received from both Routers One and Three. It chooses the path through One as its best path (the successor) and the path through Three as a loop-free path (a feasible successor). When the path through Router One becomes unavailable, Router Two examines its topology table and, when it finds a feasible successor, begins use of the path through Three immediately.
From this brief explanation, it is apparent that EIGRP must provide:
a system where it sends only the updates needed at a given time; this is accomplished through neighbor discovery and maintenance
a way to determine which paths a router has learned are loop-free
a process to clear bad routes from the topology tables of all routers on the network
a process to search neighbors to find paths to lost destinations
Each of these requirements are covered in turn.
To distribute routing information throughout a network, EIGRP uses non-periodic incremental routing updates. That is, EIGRP only sends routing updates about paths that have changed when those paths change.
If you only send routing updates, you cannot discover when a path through an adjacent router is no longer available. You cannot time out routes and expect to receive a new routing table from your neighbors. EIGRP relies on neighbor relationships to propagate routing table changes throughout the network; two routers become neighbors when they see hello packets on a common network.
EIGRP sends hello packets every 5 seconds on high bandwidth links and every 60 seconds on low bandwidth multipoint links.
5-second hello:
broadcast media, such as Ethernet, Token Ring, and FDDI
point-to-point serial links, such as PPP or HDLC leased circuits, Frame Relay point-to-point sub-interfaces, and ATM point-to-point sub-interface
high bandwidth (greater than T1) multipoint circuits, such as ISDN PRI and Frame Relay
60-second hello:
multipoint circuits T1 bandwidth or slower, such as Frame Relay multipoint interfaces, ATM multipoint interfaces, ATM switched virtual circuits, and ISDN BRIs
The rate at which EIGRP sends hello packets is called the hello interval, and you can adjust it per interface with the ip hello-interval eigrp command. The hold time is the amount of time that a router considers a neighbor alive when it does not receive a hello packet. The hold time is typically three times the hello interval, by default, 15 seconds, and 180 seconds. You can adjust the hold time with the ip hold-time eigrp command.
Note: If you change the hello interval, the hold time is not automatically adjusted to account for this change. You must manually adjust the hold time to reflect the configured hello interval.
It is possible for two routers to become EIGRP neighbors even though the hello and hold timers do not match. The hold time is included in the hello packets so each neighbor can stay alive even though the hello interval and hold timers do not match. While there is no direct way to determine what the hello interval is on a router, you can infer it from the output of the show ip eigrp neighbors command on the adjacent router.
If you have the output of a show ip eigrp neighbors command from your Cisco device, you can use the Cisco CLI Analyzer to display potential issues and fixes, if have JavaScript enabled.
router#show ip eigrp neighbors IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 1 10.1.1.2 Et1 13 12:00:53 12 300 0 620 0 10.1.2.2 S0 174 12:00:56 17 200 0 645 rp-2514aa#show ip eigrp neighbor IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 1 10.1.1.2 Et1 12 12:00:55 12 300 0 620 0 10.1.2.2 S0 173 12:00:57 17 200 0 645 rp-2514aa#show ip eigrp neighbor IP-EIGRP neighbors for process 1 H Address Interface Hold Uptime SRTT RTO Q Seq Type (sec) (ms) Cnt Num 1 10.1.1.2 Et1 11 12:00:56 12 300 0 620 0 10.1.2.2 S0 172 12:00:58 17 200 0 645
The value in the Hold column of the command output must never exceed the hold time, and must never be less than the hold time minus the hello interval (unless, of course, you lose hello packets). If the Hold column usually ranges between 10 and 15 seconds, the hello interval is 5 seconds, and the hold time is 15 seconds. If the Hold column usually has a wider range - between 120 and 180 seconds - the hello interval is 60 seconds, and the hold time is 180 seconds. If the numbers do not seem to fit one of the default timer settings, check the interface in question on the neighboring router. The hello and hold timers perhaps was configured manually.
Note: EIGRP does not build peer relationships over secondary addresses. All EIGRP traffic is sourced from the primary address of the interface.
There are no limitations on the number of neighbors that EIGRP can support. The actual number of supported neighbors depends on the device capabilities, such as:
memory capacity
the power to process
amount of exchanged information, such as the number of routes sent
topology complexity
network stability
Now that these routers talk to each other, what do they talk about? Their topology tables, of course! EIGRP, unlike RIP and IGRP, does not rely on the routing (or forwarding) table in the router to hold all of the information it needs to operate. Instead, it builds a second table, the topology table, from which it installs routes in the routing table.
Note: As of Cisco IOS versions 12.0T and 12.1, RIP maintains its own database from which it installs routes into the routing table.
To see the basic format of the topology table on a router that runs EIGRP, issue the show ip eigrp topology command. The topology table contains the information needed to build a set of distances and vectors to each reachable network along with:
lowest bandwidth on the path to this destination as reported by the upstream neighbor
total delay
path reliability
path loading
minimum path maximum transmission unit (MTU)
feasible distance
reported distance
route source (external routes are marked)
If you have the output of a show ip eigrp topology command from your Cisco device, you can use Cisco CLI Analyzer to display potential issues and fixes. To use Cisco CLI Analyzer, you must have JavaScript enabled.
EIGRP uses the minimum bandwidth on the path to a destination network and the total delay to compute routing metrics. It is not recommended that you configure other metrics because it can cause routing loops in your network. The bandwidth and delay metrics are determined from values configured on the interfaces of routers in the path to the destination network.
For instance, in Figure 2, Router One computes the path to Network A.
Figure 2
It starts with the two advertisements for this network: one through Router Four, with a minimum bandwidth of 56 and a total delay of 2200; and the other through Router Three, with a minimum bandwidth of 128 and a delay of 1200. Router One chooses the path with the lowest metric.
Compute the metrics. EIGRP calculates the total metric when it scales the bandwidth and delay metrics. EIGRP uses this formula to scale the bandwidth:
bandwidth = (10000000/bandwidth(i)) * 256
where bandwidth(i) is the least bandwidth of all outgoing interfaces on the route to the destination network represented in kilobits.
EIGRP uses this formula to scale the delay:
delay = delay(i) * 256
where delay(i) is the sum of the delays configured on the interfaces, on the route to the destination network, in tens of microseconds. The delay as shown in the show ip eigrp topology or show interface commands is in microseconds, so you must divide by 10 before you use it in this formula. The delay is used because it shows on the interface.
EIGRP uses these scaled values to determine the total metric to the network:
metric = ([K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]) * 256
Note: The K values must be used after careful planning. Mismatched K values prevent a neighbor relationship to build, which can cause your network to fail to converge.
Note: If K5 = 0, the formula reduces to Metric = ([k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay]) * 256.
The default values for K are:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
For default behavior, you can simplify the formula as shown here:
metric = bandwidth + delay
Cisco routers do not perform floating point math, so at each stage in the calculation, you need to round down to the nearest integer to properly calculate the metrics.
In this example, the total cost through Router Four is:
inimum bandwidth = 56k total delay = 100 + 100 + 2000 = 2200 [(10000000/56) + 2200] x 256 = (178571 + 2200) x 256 = 180771 x 256 = 46277376
And the total cost through Router Three is:
minimum bandwidth = 128k
total delay = 100 + 100 + 1000 = 1200
[(10000000/128) + 1200] x 256 = (78125 + 1200) x 256 = 79325 x 256 = 20307200
To reach Network A, Router One chooses the route through Router Three.
Note: The bandwidth and delay values used are those configured on the interface through which the router reaches its next hop to the destination network. For example, Router Two advertised Network A with the delay configured on its Ethernet interface; Router Four added the delay configured on its Ethernet, and Router One added the delay configured on its serial.
Feasible distance is the best metric along a path to a destination network, which includes the metric to the neighbor that advertises that path. Reported distance is the total metric along a path to a destination network as advertised by an upstream neighbor. A feasible successor is a path whose reported distance is less than the feasible distance (current best path). Figure 3 illustrates this process:
Figure 3
Router One sees that it has two routes to Network A: one through Router Three and another through Router Four.
The route through Router Four has a cost of 46277376 and a reported distance of 307200.
The route through Router Three has a cost of 20307200 and a reported distance of 307200.
Note: In each case, EIGRP calculates the reported distance from the router that advertises the route to the network. In other words, the reported distance from Router Four is the metric to get to Network A from Router Four, and the reported distance from Router Three is the metric to get to Network A from Router Three. EIGRP chooses the route through Router Three as the best path and uses the metric through Router Three as the feasible distance. Since the reported distance to this network through Router Four is less than the feasible distance, Router One considers the path through Router Four a feasible successor.
When the link between Routers One and Three goes down, Router One examines each path it knows to Network A and finds that it has a feasible successor through Router Four. Router One uses this route, which uses the metric through Router Four as the new feasible distance. The network converges instantly, and updates to downstream neighbors are the only traffic from the routing protocol.
The scenario shown in Figure 4 is more complex.
Figure 4
There are two routes to Network A from Router One: one through Router Two with a metric of 46789376 and another through Router Three with a metric of 20307200. Router One chooses the lowest of these two metrics as its route to Network A, and this metric becomes the feasible distance. Look at the path through Router Two to see if it qualifies as a feasible successor. The reported distance from Router Two is 46277376, which is higher than the feasible distance - so this path is not a feasible successor. If you were to look in the topology table of Router One at this point (use show ip eigrp topology), you would only see one entry for Network A - through Router Three. (In reality there are two entries in the topology table at Router One, but only one is a feasible successor, so the other is not displayed in show ip eigrp topology; you can see the routes that are not feasible successors with show ip eigrp topology all-links).
Assume that the link between Router One and Router Three goes down. Router One sees that it has lost its only route to Network A, and queries each of its neighbors (in this case, only Router Two) to see if they have a route to Network A. Since Router Two does have a route to Network A, it responds to the query. Since Router One no longer has the better route through Router Three, it accepts this route through Router Two to Network A.
How does EIGRP use the concepts of feasible distance, reported distance, and feasible successor to determine if a path is valid, and not a loop? In Figure 4a, Router Three examines routes to Network A. Since split horizon is disabled (for example, if these are multipoint Frame Relay interfaces), Router Three shows three routes to Network A: through Router Four, through Router Two (path is two, one, three, four), and through Router One (path is one, two, three, four).
Figure 4a
If Router Three accepts all of these routes, it results in a routing loop. Router Three thinks it can get to Network A through Router Two, but the path through Router Two passes through Router Three to get to Network A. If the connection between Router Four and Router Three goes down, Router Three believes it can get to Network A through one of the other paths, but because of the rules to determine feasible successors, it never uses these paths as alternates. Look at the metrics to see why:
total metric to Network A through Router Four: 20281600
total metric to Network A through Router Two: 47019776
total metric to Network A through Router One: 47019776
Since the path through Router Four has the best metric, Router Three installs this route in the forwarding table and uses 20281600 as its feasible distance to Network A. Router Three then computes the reported distance to Network A through Routers Two and One: 47019776 for the path through Router Two, and 47019776 for the path through Router One. Because both of these metrics are greater than the feasible distance, Router Three does not install either route as a feasible successor for Network A.
Suppose that the link between Routers Three and Four goes down. Router Three queries each of its neighbors for an alternative route to Network A. Router Two receives the query and, because the query is from its successor, searches each of the other entries in its topology table to see if there is a feasible successor. The only other entry in the topology table is from Router One, with a reported distance equal to the last known best metric through Router Three. Because the reported distance through Router One is not less than the last known feasible distance, Router Two marks the route as unreachable and queries each of its neighbors - in this case, only Router One - for a path to Network A.
Router Three also sends a query for Network A to Router One. Router One examines its topology table and finds that the only other path to Network A is through Router Two with a reported distance equal to the last known feasible distance through Router Three. Once again, since the reported distance through Router Two is not less than the last known feasible distance, this route is not a feasible successor. Router One marks the route as unreachable and queries its only other neighbor, Router Two, for a path to Network A.
This is the first level of queries. Router Three has queried each of its neighbors in an attempt to find a route to Network A. In turn, Routers One and Two have marked the route unreachable, and queried each of their other neighbors in an attempt to find a path to Network A. When Router Two receives the Router One query, it examines its topology table and notes that the destination is marked as unreachable. Router Two replies to Router One that Network A is unreachable. When Router One receives the Router Two query, it also sends back a reply that Network A is unreachable. Now Routers One and Two have both concluded that Network A is unreachable, and they reply to the original Router Three query. The network has converged, and all routes return to the passive state.
In the previous example, the split horizon does not show how EIGRP uses the feasible distance and the reported distance to determine if a route is likely to be a loop. In some circumstances, however, EIGRP uses split horizon to prevent routing loops as well. Before you examine the details of how EIGRP uses split horizon, examine what the split horizon is and how it works. The split horizon rule states:
Never advertise a route out of the interface through which you learned it.
For instance, in Figure 4a, if Router One is connected to Routers Two and Three through a single multipoint interface (such as Frame Relay), and Router One learned about Network A from Router Two, it does not advertise the route to Network A back out the same interface to Router Three. Router One assumes that Router Three would learn about Network A directly from Router Two.
Figure 4a
Poison reverse is another way to avoid routing loops. Its rule states:
Once you learn of a route through an interface, advertise it as unreachable back through that same interface.
For example, the routers in Figure 4a have poison reverse enabled. When Router One learns about Network A from Router Two, it advertises Network A as unreachable through its link to Routers Two and Three. Router Three, if it shows any path to Network A through Router One, removes that path because of the unreachable advertisement. EIGRP combines these two rules to help prevent routing loops.
EIGRP uses split horizon or advertises a route as unreachable when:
two routers are in startup mode (they exchange topology tables for the first time)
a topology table change is advertised
a query is sent
Review each case.
When two routers first become neighbors, they exchange topology tables during startup mode. For each table entry a router receives during startup mode, it advertises the same entry back to its new neighbor with a maximum metric (poison route).
In Figure 5, Router One uses variance to balance the traffic destined to Network A between the two serial links; that is, the 56k link between Routers Two and Four, and the 128k link between Routers Three and Four.
Figure 5
Router Two sees the path through Router Three as a feasible successor. If the link between Routers Two and Four goes down, Router Two simply re-converges on the path through Router Three. Since the split horizon rule states that you must never advertise a route out of the interface through which you learned about it, Router Two would not normally send an update. However, this leaves Router One with an invalid topology table entry.
When a router changes its topology table in such a way that the interface through which the router reaches network changes, it turns off split horizon and poison reverses the old route out all interfaces. In this case, Router Two turns off split horizon for this route, and advertises Network A as unreachable. Router One hears this advertisement and flushes its route to Network A through Router Two from its routing table.
Queries result in a split horizon only when a router receives a query or update from the successor it uses for the destination in the query. Look at the network in Figure 6.
Figure 6
Router Three receives a query about 10.1.2.0/24 (which it reaches through Router One) from Router Four. If Three does not have a successor for this destination because a link flap or other temporary network condition, it sends a query to each of its neighbors; in this case, Routers One, Two, and Four. If, however, Router Three receives a query or update (such as a metric change) from Router One for the destination 10.1.2.0/24, it does not send a query back to Router One, because Router One is its successor to this network. Instead, it only sends queries to Routers Two and Four.
It can take a long time for a query to be answered. If so, the router that issued the query gives up and clears its connection to the router that does not answer, and this restarts the neighbor session. This is known as a stuck in active (SIA) route. The most basic SIA routes occur when it simply takes too long for a query to reach the other end of the network and for a reply to travel back. For instance, in Figure 7, Router One records a large number of SIA routes from Router Two.
Figure 7
After some investigation, the problem is narrowed down to the delay over the satellite link between Routers Two and Three. There are two viable solutions to this type of problem. The first is to increase the amount of time the router waits after it sends a query before it declares the route SIA. This setting can be changed with the timers active-time command.
The better solution, however, is to redesign the network to reduce the range of queries (so very few queries pass over the satellite link). Query range is covered in the Query Range section of this article. Query range in itself, however, is not a common reason for reported SIA routes. More often, some router on the network cannot answer a query for one of these reasons:
The router is too busy to answer the query (generally due to high CPU utilization).
The router has memory problems and cannot allocate the memory to process the query or build the reply packet.
The circuit between the two routers is not good; there are not enough packets that get through to keep the neighbor relationship up, but some queries or replies are lost between the routers.
unidirectional links (a link on which traffic can only flow in one direction because of a failure)
When you troubleshoot SIA routes use this three-step process:
Find the routes that are consistently reported as SIA.
Find the router that consistently fails to answer queries for these routes.
Find the reason that router does not receive or answer queries.
The first step is easy. If you log console messages, a quick perusal of the log shows the routes often marked as SIA. The second step is more difficult. The command to gather this information is show ip eigrp topology active:
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status A 10.2.4.0/24, 0 successors, FD is 512640000, Q 1 replies, active 00:00:01, query-origin: Local origin via 10.1.2.2 (Infinity/Infinity), Serial1 1 replies, active 00:00:01, query-origin: Local origin via 10.1.3.2 (Infinity/Infinity), r, Serial3 Remaining replies: via 10.1.1.2, r, Serial0
Any neighbors that show an R have yet to reply (the active timer shows how long the route has been active). These neighbors cannot show up in the Remaining replies section; they can appear among the other RDBs. Pay particular attention to routes that have outstanding replies and have been active for some time, generally two to three minutes. Run this command several times and you begin to see which neighbors do not respond to queries (or which interfaces seem to have a lot of unanswered queries). Examine this neighbor to see if it consistently waits for replies from any of its neighbors. Repeat this process until you find the router that consistently does not answer queries. You can look for problems on the link to this neighbor, memory or CPU utilization, or other problems with this neighbor.
If the query range is the problem, do not increase the SIA timer; instead, reduce the query range.
This section examines different scenarios that involve redistribution. The examples listed show the minimum required to configure redistribution. Redistribution can potentially cause problems, such as below-optimal routing, routing loops, or slow convergence. To avoid these problems, see the Avoiding Problems Due to Redistribution section.
Figure 8 shows that the routers are configured as:
Figure 8
Router One
router eigrp 2000 !--- The "2000" is the autonomous system network 172.16.1.0 0.0.0.255
Router Two
router eigrp 2000 redistribute eigrp 1000 route-map to-eigrp2000 network 172.16.1.0 0.0.0.255 ! router eigrp 1000 redistribute eigrp 2000 route-map to-eigrp1000 network 10.1.0.0 0.0.255.255 route-map to-eigrp1000 deny 10 match tag 1000 ! route-map to-eigrp1000 permit 20 set tag 2000 ! route-map to-eigrp2000 deny 10 match tag 2000 ! route-map to-eigrp2000 permit 20 set tag 1000
Router Three
router eigrp 1000 network 10.1.0.0 0.0.255.255
Router Three advertises the network 10.1.2.0/24 to Router Two through autonomous system 1000; Router Two redistributes this route into autonomous system 2000 and advertises it to Router One.
Note: The routes from EIGRP 1000 are tagged 1000 before they are redistributed to EIGRP 2000. When routes from EIGRP 2000 are redistributed back to EIGRP 1000, the routes with 1000 tags are denied to ensure a loop-free topology. For more information on redistribution among routing protocols, please see Redistributing Routing Protocols.
For Router One:
one#show ip eigrp topology 10.1.2.0 255.255.255.0 IP-EIGRP topology entry for 10.1.2.0/24 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 46763776 Routing Descriptor Blocks: 172.16.1.2 (Serial0), from 172.16.1.2, Send flag is 0x0 Composite metric is (46763776/46251776), Route is External Vector metric: Minimum bandwidth is 56 Kbit Total delay is 41000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 2 External data: Originating router is 172.16.1.2 AS number of route is 1000 External protocol is EIGRP, external metric is 46251776 Administrator tag is 1000 (0x000003E8)
Notice that although the link between Routers One and Two has a bandwidth of 1.544Mb, the minimum bandwidth shown in this topology table entry is 56k. This means that EIGRP preserves all metrics when it redistributes between two EIGRP autonomous systems.
Redistribution between EIGRP and other protocols, for example, RIP and OSPF, works in the same way as all redistribution. Use the default metric when you redistribute between protocols. You need to be aware of these two issues when you redistribute between EIGRP and other protocols:
Routes redistributed into EIGRP are not always summarized, see the Summarization section for an explanation.
External EIGRP routes have an administrative distance of 170.
When you install a static route to an interface and configure a network statement with router eigrp, which includes the static route. EIGRP redistributes this route as if it were a directly connected interface.
Figure 9
In Figure 9, Router One has a static route to the network 172.16.1.0/24 configured through interface Serial 0:
ip route 172.16.1.0 255.255.255.0 Serial0
And Router One also has a network statement for the destination of this static route:
router eigrp 2000 network 10.0.0.0 network 172.16.0.0 no auto-summary
Router One redistributes this route, even though it does not redistribute static routes, because EIGRP considers this a directly attached network. On Router Two, this looks as shown:
two#show ip route .... 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.1.1.0/24 is directly connected, Serial0 D 10.1.2.0/24 [90/2169856] via 10.1.1.1, 00:00:47, Serial0 172.16.0.0/24 is subnetted, 1 subnets D 172.16.1.0 [90/2169856] via 10.1.1.1, 00:00:47, Serial0
The route to 172.16.1.0/24 appears as an internal EIGRP route on Router Two.
There are two forms of summarization in EIGRP: auto-summaries and manual summaries.
EIGRP performs an auto-summarization each time it crosses a border between two different major networks. For example, in Figure 10, Router Two advertises only the 10.0.0.0/8 network to Router One, because the interface Router Two uses to reach Router One is in a different major network.
Figure 10
On Router One, it looks like this:
one#show ip eigrp topology 10.0.0.0 IP-EIGRP topology entry for 10.0.0.0/8 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 11023872 Routing Descriptor Blocks: 172.16.1.2 (Serial0), from 172.16.1.2, Send flag is 0x0 Composite metric is (11023872/10511872), Route is Internal Vector metric: Minimum bandwidth is 256 Kbit Total delay is 40000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1
This route is not marked as a summary route in any way; it looks like an internal route. The metric is the best metric from among the summarized routes. The minimum bandwidth on this route is 256k, although there are links in the 10.0.0.0 network that have a bandwidth of 56k.
On the router with the summarization, a route is built to null0 for the summarized address:
two#show ip route 10.0.0.0 Routing entry for 10.0.0.0/8, 4 known subnets Attached (2 connections) Variably subnetted with 2 masks Redistributing via eigrp 2000 C 10.1.3.0/24 is directly connected, Serial2 D 10.1.2.0/24 [90/10537472] via 10.1.1.2, 00:23:24, Serial1 D 10.0.0.0/8 is a summary, 00:23:20, Null0 C 10.1.1.0/24 is directly connected, Serial1
The route to 10.0.0.0/8 is marked as a summary through Null0. The topology table entry for this summary route looks like this:
two#show ip eigrp topology 10.0.0.0 IP-EIGRP topology entry for 10.0.0.0/8 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 10511872 Routing Descriptor Blocks: 0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0 (Note: The 0.0.0.0 here means this route is originated by this router.) Composite metric is (10511872/0), Route is Internal Vector metric: Minimum bandwidth is 256 Kbit Total delay is 20000 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 0
To make Router Two advertise the components of the 10.0.0.0 network instead of a summary, configure no auto-summary on the EIGRP process on Router Two:
On Router Two:
router eigrp 2000 network 172.16.0.0 network 10.0.0.0 no auto-summary
With auto-summary turned off, Router One now sees all of the components of the 10.0.0.0 network:
one#show ip eigrp topology IP-EIGRP Topology Table for process 2000 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 10.1.3.0/24, 1 successors, FD is 46354176 via 172.16.1.2 (46354176/45842176), Serial0 P 10.1.2.0/24, 1 successors, FD is 11049472 via 172.16.1.2 (11049472/10537472), Serial0 P 10.1.1.0/24, 1 successors, FD is 11023872 via 172.16.1.2 (11023872/10511872), Serial0 P 172.16.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0
There are some caveats to the summarization of external routes that are covered later in the Auto-Summarization of External Routes section.
EIGRP allows you to summarize internal and external routes on virtually any bit boundary with manual summarization. For example, in Figure 11, Router Two summarizes 192.168.1.0/24, 192.168.2.0/24, and 192.168.3.0/24 into the CIDR block 192.168.0.0/22.
Figure 11
The configuration on Router Two is shown:
two#show run .... ! interface Serial0 ip address 10.1.50.1 255.255.255.0 ip summary-address eigrp 2000 192.168.0.0 255.255.252.0 no ip mroute-cache ! .... two#show ip eigrp topology IP-EIGRP Topology Table for process 2000 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 10.1.10.0/24, 1 successors, FD is 45842176 via Connected, Loopback0 P 10.1.50.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 192.168.1.0/24, 1 successors, FD is 10511872 via Connected, Serial1 P 192.168.0.0/22, 1 successors, FD is 10511872 via Summary (10511872/0), Null0 P 192.168.3.0/24, 1 successors, FD is 10639872 via 192.168.1.1 (10639872/128256), Serial1 P 192.168.2.0/24, 1 successors, FD is 10537472 via 192.168.1.1 (10537472/281600), Serial1
Look at the ip summary-address eigrp command under interface Serial0 and the summary route via Null0. On Router One, this is seen as an internal route:
one#show ip eigrp topology IP-EIGRP Topology Table for process 2000 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 10.1.10.0/24, 1 successors, FD is 46354176 via 10.1.50.1 (46354176/45842176), Serial0 P 10.1.50.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 192.168.0.0/22, 1 successors, FD is 11023872 via 10.1.50.1 (11023872/10511872), Serial0
EIGRP does not auto-summarize external routes unless there is a component of the same major network that is an internal route. Figure 12 illustrates this:
Figure 12
Router Three injects external routes to 192.168.2.0/26 and 192.168.2.64/26 into EIGRP with the redistribute connected command, as shown in the configurations listed.
Router Three
interface Ethernet0 ip address 192.168.2.1 255.255.255.192 ! interface Ethernet1 ip address 192.168.2.65 255.255.255.192 ! interface Ethernet2 ip address 10.1.2.1 255.255.255.0 !router eigrp 2000 redistribute connected network 10.0.0.0 default-metric 10000 1 255 1 1500
With this configuration on Router Three, the routing table on Router One shows:
one#show ip route .... 10.0.0.0/8 is subnetted, 2 subnets D 10.1.2.0 [90/11023872] via 10.1.50.2, 00:02:03, Serial0 C 10.1.50.0 is directly connected, Serial0 192.168.2.0/26 is subnetted, 1 subnets D EX 192.168.2.0 [170/11049472] via 10.1.50.2, 00:00:53, Serial0 D EX 192.168.2.64 [170/11049472] via 10.1.50.2, 00:00:53, Serial0
Although auto-summary normally causes Router Three to summarize the 192.168.2.0/26 and 192.168.2.64/26 routes into one major net destination (192.168.2.0/24), it does not do this because both routes are external. However, if you reconfigure the link between Routers Two and Three to 192.168.2.128/26 and add network statements for this network on Routers Two and Three, the 192.168.2.0/24 auto-summary is then generated on Router Two.
Router Three
interface Ethernet0 ip address 192.168.2.1 255.255.255.192 ! interface Ethernet1 ip address 192.168.2.65 255.255.255.192 ! interface Serial0 ip address 192.168.2.130 255.255.255.192 ! router eigrp 2000 network 192.168.2.0
Now Router Two generates the summary for 192.168.2.0/24:
two#show ip route .... D 192.168.2.0/24 is a summary, 00:06:48, Null0 ....
And Router One shows only the summary route:
one#show ip route .... 10.0.0.0/8 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Serial0 D 192.168.2.0/24 [90/11023872] via 10.1.50.2, 00:00:36, Serial0
When a router processes a query from a neighbor, these rules apply as listed in the table.
Query From | Route State | Action |
neighbor (not the current successor) |
passive |
reply with current successor information. |
successor |
passive |
attempt to find new successor; if successful, reply with new information; if not successful, mark destination unreachable and query all neighbors except the previous successor. |
any neighbor |
no path through this neighbor before query |
reply with best path currently known. |
any neighbor |
not known before query |
reply that the destination is unreachable. |
neighbor (not the current successor) |
active |
if there is no current successor to these destinations (normally this would be true), reply with an unreachable. If there is a good successor, reply with the current path information. |
successor |
active |
Attempt to find new successor; if successful, reply with new information; if not successful, mark destination unreachable and query all neighbors except the previous successor. |
The actions in the previous table impact the range of the query in the network when it discovers how many routers receive and reply to the query before the network converges on the new topology. To see how these rules affect the way queries are managed, look at the network in Figure 13, which runs under normal conditions.
Figure 13
This is expected with regards to network 192.168.3.0/24 (far right side):
Router One has two paths to 192.168.3.0/24:
through Router Two with a distance of 46533485 and a reported distance of 20307200
through Router Three with a distance of 20563200 and a reported distance of 20307200
Router One chooses the path through Router Three and keeps the path through Router Two as a feasible successor
Routers Two and Three show one path to 192.168.3.0/24 through Router Four
Suppose that 192.168.3.0/24 fails. The activity expected on this network is that Figures 13a through 13h illustrate the process.
Router Five marks 192.168.3.0/24 as unreachable, and queries Router Four:
Figure 13a
When Router Four receives a query from its successor, it attempts to find a new feasible successor to this network. It does not find one, so it marks 192.168.3.0/24 as unreachable and query Routers Two and Three:
Figure 13b
Routers Two and Three, in turn, see that they have lost their only feasible route to 192.168.3.0/24, and mark it as unreachable; they both send queries to Router One:
Figure 13c
Assume that Router One receives the query from Router Three first and marks the route as unreachable. Router One then receives the query from Router Two. Although another order is possible, they all have the same final result.
Figure 13d
Router One replies to both queries with unreachables; Router One is now passive for 192.168.3.0/24:
Figure 13e
Routers Two and Three reply to the query from Router Four; Routers Two and Three are now passive for 192.168.3.0/24:
Figure 13f
When Router Five receives the reply from Router Four, it removes network 192.168.3.0/24 from its routing table; Router Five is now passive for network 192.168.3.0/24. Router Five sends updates back to Router Four so the route is removed from the topology and routing tables of the other routers.
Figure 13g
Although there can be other query paths or orders to process, all routers in the network process a query for network 192.168.3.0/24 when that link goes down. Some routers can process more than one query (Router One in this example). In fact, if the queries were to reach the routers in a different order, some would process three or four queries. This is a good example of an unbounded query in an EIGRP network.
Look at the paths to 10.1.1.0/24 in the same network:
Router Two has a topology table entry for the 10.1.1.0/24 network with a cost of 46251885 through Router One.
Router Three has a topology table entry for the 10.1.1.0/24 network with a cost of 20281600 through Router One.
Router Four has a topology table entry for the 10.0.0.0/8 network (because Routers Two and Three auto-summarize to the major network boundary) through Router Three with a metric of 20307200 (the reported distance through Router Two is higher than the total metric through Router Three, so the path through Router Two is not a feasible successor).
Figure 14
If 10.1.1.0/24 goes down, Router One marks it as unreachable, and then queries each of its neighbors (Routers Two and Three) for a new path to that network:
Figure 14a
Router Two, when it receives the query from Router One, marks the route as unreachable (because the query is from its successor) and then queries Routers Four and Three:
Figure 14b
Router Three, when it receives the query from Router One, marks the destination as unreachable and queries Routers Two and Four:
Figure 14c
Router Four, when it receives the queries from Routers Two and Three, replies that 10.1.1.0/24 is unreachable (Router Four has no knowledge of the subnet in question, since it only has the 10.0.0.0/8 route):
Figure 14d
Routers Two and Three reply to each other that 10.1.1.0/24 is unreachable:
Figure 14e
Since Routers Two and Three now have no outstanding queries, they both reply to Router One that 10.1.1.0/24 is unreachable:
Figure 14f
The query, in this case, is bounded by the auto-summarization at Routers Two and Three. Router Five does not participate in the query process and is not involved in the re-convergence of the network. Queries can also be bound by manual summarization, autonomous system borders, and distribution lists.
If a router redistributes routes between two EIGRP autonomous systems, it replies to the query within the normal rules for the process and launches a new query into the other autonomous system. For example, if the link to the network attached to Router Three goes down, Router Three marks the route unreachable and queries Router Two for a new path:
Figure 15a
Router Two replies that this network is unreachable and launches a query into autonomous system 200 toward Router One. Once Router Three receives the reply to its original query, it removes the route from its table. Router Three is now passive for this network:
Figure 15b
Router One replies to Router Two, and the route goes passive:
Figure 15c
While the original query did not propagate throughout the network (it was bound by the autonomous system border), the original query leaks into the second autonomous system in the form of a new query. This prevents stuck in active (SIA) problems in a network because it limits the number of routers a query must pass through before it is answered. However, but it does not solve the overall problem with each router that must process the query. This method can make the problem worse and prevent the auto-summarization of routes that would otherwise be summarized (external routes are not summarized unless there is an external component in that major network).
Rather than block the propagation of a query, distribution lists in EIGRP mark any query reply as unreachable. Use Figure 16 as an example.
Figure 16
In figure 16:
Router Three has a distribute-list applied against its serial interfaces that only permits it to advertise Network B.
Routers One and Two do not know that Network A is reachable through Router Three (Router Three is not used as a transit point between Routers One and Two).
Router Three uses Router One as its preferred path to Network A and does not use Router Two as a feasible successor.
When Router One loses its connection to Network A, it marks the route as unreachable and sends a query to Router Three. Router Three does not advertise a path to Network A because of the distribution list on its serial ports.
Figure 16a
Router Three marks the route as unreachable, then queries Router Two:
Figure 16b
Router Two examines its topology table and finds that it has a valid connection to Network A. The query was not affected by the distribution list in Router Three:
Figure 16c
Router Two replies that Network A is reachable; Router Three now has a valid route:
Figure 16d
Router Three builds the reply to the query from Router One, but the distribution list causes Router Three to send a reply that Network A is unreachable, even though Router Three has a valid route to Network A:
Figure 16e
Some routing protocols consume all of the available bandwidth on a low bandwidth link while they converge (adapt to a change in the network). EIGRP avoids this congestion and manages the speed at which packets are transmitted on a network, so, it uses only a portion of the available bandwidth. The default configuration for EIGRP is to use up to 50 percent of the available bandwidth, but this can be changed with this command:
router(config-if)# ip bandwidth-percent eigrp 2? <1-999999> Maximum bandwidth percentage that EIGRP can use
Essentially, each time EIGRP queues a packet to be transmitted on an interface, it uses this formula to determine how long to wait before it sends the packet:
ip bandwidth-percent eigrp 2
(8 * 100 * packet size in bytes) / (bandwidth in kbps * bandwidth percentage)
For instance, if EIGRP queues a packet to be sent over a serial interface that has a bandwidth of 56k, and the packet is 512 bytes, EIGRP waits:
(8 * 100 * 512 bytes) / (56000 bits per second * 50% bandwidth) (8 * 100 * 512) / (56000 * 50) 409600 / 2800000 0.1463 seconds
This allows a packet (or groups of packets) of at least 512 bytes to transmit on this link before EIGRP sends its packet. The pacing timer determines when the packet is sent and is expressed in milliseconds. The pacing time for the packet in the previous example is 0.1463 seconds. There is a field in show ip eigrp interface that displays the pacing timer:
outer#show ip eigrp interface IP-EIGRP interfaces for process 2 Xmit Queue Mean Pacing Time Multicast Pending Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0 1 0/0 28 0/15 127 0 Se1 1 0/0 44 0/15 211 0 router#
The time displayed is the pacing interval for the maximum transmission unit (MTU), the largest packet that can be sent over the interface.
There are two ways to inject a default route into EIGRP: redistribute a static route or summarize to 0.0.0.0/0. Use the first method when you want to draw all traffic to unknown destinations to a default route at the core of the network. This method advertises connections to the Internet. For example:
ip route 0.0.0.0 0.0.0.0 x.x.x.x (next hop to the internet) ! router eigrp 100 redistribute static default-metric 10000 1 255 1 1500
The static route that is redistributed into EIGRP does not have to be to network 0.0.0.0. If you use another network, you must use the ip default-network command to mark the network as a default network.
If you summarize, a default route works only when you want to provide remote sites with a default route. Since summaries are configured per interface, you can use the distribute-lists or other mechanisms to prevent the default route from spread toward the core of your network. Note that a summary to 0.0.0.0/0 overrides a default route learned from any other routing protocol. The only way to configure a default route on a router with this method is to configure a static route to 0.0.0.0/0. (Start with Cisco IOS Software 12.0(4)T, and you can also configure an administrative distance on the end of the ip summary-address eigrp command, so the local summary does not override the 0.0.0.0/0 route).
router eigrp 100 network 10.0.0.0 ! interface serial 0 encapsulation frame-relay no ip address ! interface serial 0.1 point-to-point ip address 10.1.1.1 frame-relay interface-dlci 10 ip summary-address eigrp 100 0.0.0.0 0.0.0.0
EIGRP puts up to four routes of equal cost in the routing table, which the router then load balances. The type of load balance (per packet or per destination) depends on the type of switching that is done in the router. EIGRP, however, can also load balance over unequal cost links.
Note: With max-paths, you can configure EIGRP to use up to six routes of equal cost.
If there are four paths to a given destination, and the metrics for these paths are:
path 1: 1100
path 2: 1100
path 3: 2000
path 4: 4000
The router, by default, places traffic on both path 1 and 2. With EIGRP, you can use the variance command to instruct the router to also place traffic on paths 3 and 4. The variance is a multiplier: traffic is placed on any link that has a metric less than the best path multiplied by the variance. To load balance over paths 1, 2, and 3, use variance 2, because 1100 x 2 = 2200, which is greater than the metric through path 3. Similarly, to also add path 4, issue variance 4 under the router eigrp command. Refer to How Does Unequal Cost Path Load Balancing (Variance) Work in IGRP and EIGRP? for more information.
How does the router divide the traffic between these paths? It divides the metric through each path into the largest metric, rounds down to the nearest integer, and uses this number as the traffic share count.
router#show ip route 10.1.4.0 Routing entry for 10.1.4.0/24 Known via "igrp 100", distance 100, metric 12001 Redistributing via igrp 100, eigrp 100 Advertised by igrp 100 (self originated) eigrp 100 Last update from 10.1.2.2 on Serial1, 00:00:42 ago Routing Descriptor Blocks: * 10.1.2.2, from 10.1.2.2, 00:00:42 ago, via Serial1 Route metric is 12001, traffic share count is 1 Total delay is 20010 microseconds, minimum bandwidth is 1000 Kbit Reliability 1/255, minimum MTU 1 bytes Loading 1/255, Hops 0
For this example, the traffic share counts are:
for paths 1 and 2: 4000/1100 = 3
for path 3: 4000/2000 = 2
for path 4: 4000/4000 = 1
The router sends the first three packets over path 1, the next three packets over path 2, the next two packets over path 3, and the next packet over path 4. The router restarts when it sends the next three packets over path 1 and continues this pattern.
Note: Even with variance configured, EIGRP does not send traffic over an unequal cost path if the reported distance is greater than the feasible distance for that particular route. Refer to the Feasible Distance, Reported Distance, and Feasible Successors section for more information.
When you initially configure EIGRP, remember these two basic rules if you attempt to influence EIGRP metrics:
The bandwidth must always be set to the real bandwidth of the interface; multipoint serial links and other mismatched media speed situations are the exceptions to this rule.
The delay must always be used to influence EIGRP routing decisions.
Because EIGRP uses the interface bandwidth to determine the rate at which to send packets, it is important that these be set correctly. If it is necessary to influence the path EIGRP chooses, always use delay to do so.
At lower bandwidths, the bandwidth has more influence over the total metric; at higher bandwidths, the delay has more influence over the total metric.
External administrative tags can break the redistribution of routing loops between EIGRP and other protocols. If you tag the route when it is redistributed into EIGRP, you can block redistribution from EIGRP into the external protocol. It is not possible to modify the administrative distance for a default gateway that was learned from an external route because, in EIGRP, the modification of the administrative distance only applies for internal routes. In order to raise the metric, use a route-map with prefix-list; do not change the administrative distance. A basic example to configure these tags is next, but this example does not show the entire configuration used to break the redistribution loops.
Figure 17
Router Three, which redistributes routes connected into EIGRP, shows:
three#show run .... interface Loopback0 ip address 172.19.1.1 255.255.255.0 ! interface Ethernet0 ip address 172.16.1.1 255.255.255.0 loopback no keepalive ! interface Serial0 ip address 172.17.1.1 255.255.255.0 .... router eigrp 444 redistribute connected route-map foo network 172.17.0.0 default-metric 10000 1 255 1 1500 .... access-list 10 permit 172.19.0.0 0.0.255.255 route-map foo permit 10 match ip address 10 set tag 1 .... three#show ip eigrp topo IP-EIGRP Topology Table for process 444 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 172.17.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0 via Redistributed (2169856/0) P 172.16.1.0/24, 1 successors, FD is 281600 via Redistributed (281600/0) P 172.19.1.0/24, 1 successors, FD is 128256, tag is 1 via Redistributed (128256/0)
Router Two, which redistributes routes from EIGRP into RIP, shows:
two#show run .... interface Serial0 ip address 172.17.1.2 255.255.255.0 ! interface Serial1 ip address 172.18.1.3 255.255.255.0 .... router eigrp 444 network 172.17.0.0 ! router rip redistribute eigrp 444 route-map foo network 10.0.0.0 network 172.18.0.0 default-metric 1 ! no ip classless ip route 10.10.10.10 255.255.255.255 Serial0 route-map foo deny 10 match tag 1 ! route-map foo permit 20 .... two#show ip eigrp topo IP-EIGRP Topology Table for process 444 Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status P 172.17.1.0/24, 1 successors, FD is 2169856 via Connected, Serial0 P 172.16.1.0/24, 1 successors, FD is 2195456 via 172.17.1.1 (2195456/281600), Serial0 P 172.19.1.0/24, 1 successors, FD is 2297856, tag is 1 via 172.17.1.1 (2297856/128256), Serial0
Notice the tag 1 on 172.19.1.0/24.
Router One, which receives the RIP routes redistributed by Router 2, shows:
one#show run .... interface Serial0 ip address 172.18.1.2 255.255.255.0 no fair-queue clockrate 1000000 router rip network 172.18.0.0 .... one#show ip route Gateway of last resort is not set R 172.16.0.0/16 [120/1] via 172.18.1.3, 00:00:15, Serial0 R 172.17.0.0/16 [120/1] via 172.18.1.3, 00:00:15, Serial0 172.18.0.0/24 is subnetted, 1 subnets C 172.18.1.0 is directly connected, Serial0
Notice that 172.19.1.0/24 is gone.
This command is used to display information about EIGRP named configurations and EIGRP autonomous-system (AS) configurations. The output of this command shows the information that has been exchanged between the adjacent EIGRP router. An explanation of each output field is after the table.
show ip eigrp traffic |
Hellos sent/received shows the number of hello packets sent and received (sent -1927/received - 1930).
Updates sent/received displays the number of update packets sent and received (sent-20/received-39).
Queries sent/received means the number of query packets sent and received (sent-10/received-18).
Replies sent/received shows the number of reply packets sent and received (sent-18/received-16).
Acks sent/received stands for the number of acknowledgment packets sent and received (sent-66/received-41).
SIA-Queries sent/received means number of stuck in active query packets sent and received (sent-0/received-0).
SIA-Replies sent/received displays the number of stuck in active reply packets sent and received (sent-0/received-0).
Hello Process ID is the hello process identifier (270).
PDM Process ID stands for protocol-dependent module Cisco IOS process identifier (251).
Socket Queue displays the IP to EIGRP Hello Process socket queue counters (current-0/max-2000/highest-1/drops-0).
Input Queue shows the EIGRP Hello Process to EIGRP PDM socket queue counters (current-0/max-2000/highest-1/drops-0).
This command only displays feasible successors. To display all entries in the topology table, use the show ip eigrp topology all-links command. An explanation of each output field is after the table.3+
show ip eigrp topology |
Configuration Explanations
A means active. This could also show a P, which means passive.
10.2.4.0/24 is the destination or mask.
0 successors shows how many successors (or paths) are available for this destination; if successors is capitalized, the route is in transition.
FD is 512640000 shows the feasible distance, which is the best metric to reach this destination or the best metric known when the route went active.
tag is 0x0 can be set and/or filtered with route maps with the set tag and match tag commands.
Q means a query is pending. This field can also be: U, which means the update is pending; or R, which means a reply is pending.
1 replies shows the number of outstanding replies.
active 00:00:01 shows how long this route has been active.
query origin: Local origin shows this route originated the query. This field can also be Multiple origins, which means that multiple neighbors have sent queries on this destination, but not the successor; or Successor origin, which means the successor originated the query.
via 10.1.2.2 shows that this route was learned from a neighbor whose IP address is 10.1.2.2. This field can also be: Connected, if the network is directly connected to this router; Redistributed, if this route is redistributed into EIGRP on this router; or Summary, if this is a summary route generated on this router.
(Infinity/Infinity) shows the metric to reach this path through this neighbor in the first field, and the reported distance through this neighbor in the second field.
r shows that this neighbor has been queried and wait for a reply.
Q is the send flag for this route, which means there is a query pending. This field can also be U, which means the update is pending; or R, which means a reply is pending.
Serial1 is the interface through which this neighbor is reachable.
Via 10.1.1.2 shows the neighbor is queried and expects a reply.
r shows this neighbor was queried about the route and has not yet received a reply.
Serial0 is the interface through which this neighbor is reachable.
Via 10.1.2.2 (512640000/128256), Serial1 shows that this route is used (indicates which path the next path/destination takes when there are multiple routes of equal cost).
This command displays all entries in the topology table for this destination, not just feasible successors. An explanation of each output field is after the table.
show ip eigrp topology network |
2 Successor(s) means there are two feasible paths to this network.
Routing Descriptor Blocks Each of these entries describes one path to the network.
10.1.1.2 (Ethernet1) is the next hop to the network and the interface that next hop is reached through.
from 10.1.2.2 is the source of this path information.
Send flag is:
0x0: If there are packets that need to be sent in relation to this entry, this indicates the type of packet.
0x1: This router has received a query for this network and needs to send a unicast reply.
0x2: This route is active, and a multicast query must be sent.
0x3: This route has changed, and a multicast update must be sent.
Composite metric is (307200/281600) shows the total calculated costs to the network. The first number in the parentheses is the total cost to the network through this path, along with the cost to the next hop. The second number in the parentheses is the reported distance, or, in other words, the cost the next hop router uses.
Route is Internal means this route was originated within this EIGRP autonomous system (AS). If the route was redistributed into this EIGRP AS, this field would indicate that the route is External.
Vector metric shows the individual metrics used by EIGRP to calculate the cost to a network. EIGRP does not propagate total cost information throughout the network; the vector metrics are propagated, and each router computes the cost and reported distance individually.
Minimum bandwidth is 10000 Kbit shows the lowest bandwidth on the path to this network.
Total delay is 2000 microseconds shows the sum of the delays on the path to this network.
Minimum MTU is 1500 This field is not used in metric calculations.
Hop count is 2 This is not used in metric calculations, but does limit the maximum size of an EIGRP AS. The maximum number of hops that EIGRP accepts is 100 by default, although the maximum can be configured to 220 with metric maximum hops.
If the route is external, this information is included. An explanation of each output field is after the table.
External Route |
Originating Router shows that this is the router that injected this route into the EIGRP AS.
External AS shows the Autonomous System this route came from (if there is one).
External Protocol shows the protocol this route came from (if there is one).
external metric shows the internal metric in the external protocol.
Administrator Tag can be set and/or filtered with route maps with the set tag and match tag commands.
Same output format as show ip eigrp topology , but it also shows some portion of the topology table.
Same output format as show ip eigrp topology , but it also shows all links in the topology table, rather than just feasible successors.
Revision | Publish Date | Comments |
---|---|---|
4.0 |
31-Aug-2023 |
Recertification 2023 |
3.0 |
12-Jul-2022 |
Republished for Improvements. Recertification. 7/12/2022 |
2.0 |
30-Jun-2022 |
Recertification update
Remove all PII frm text and figures.
Update style requirements, machine translation, gerunds and other formatting. |
1.0 |
03-Jan-2002 |
Initial Release |