Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
The previous major section of this chapter focused on how EIGRP calculates metrics and
how to change that metric calculation. However, that section discussed only one motivation
for changing the metric: to make a router pick one route instead of another. This section,
which focuses on optimizing the EIGRP convergence process, discusses another
reason for choosing to manipulate the EIGRP metric calculations: faster convergence.
EIGRP converges very quickly, but EIGRP does not achieve the most optimal fast convergence
times in all conditions. One design goal might be to tune EIGRP configuration settings
so that EIGRP uses the faster convergence methods for as many routes as possible,
and when not possible, that EIGRP converge as quickly as it can without introducing routing
loops. As a result, routers might converge in some cases in a second instead of tens of
seconds (from the point of a router realizing that a route has failed).
For those of you who have not thought about EIGRP convergence before now, you must
first get a comfortable understanding of the concept of EIGRP Feasible Successors–the
first topic in this section. Following that, the text examines the EIGRP query process. This
section ends with EIGRP load balancing, which both allows spreading the load across multiple
routes in addition to improving EIGRP convergence.
Fast Convergence to Feasible Successors
Earlier in this chapter, under the heading “Calculating the Metrics: Feasible Distance and
Reported Distance,” the text explains how a router, for each possible route, calculates two
metric values. One value is the feasible distance (FD), which is the metric from that
router’s perspective. The other metic is the reported distance (RD), which is the integer
metric from the perspective of the next-hop router.
EIGRP routers use the RD value when determining if a possible route can be considered to
be a loop-free backup route called a feasible successor. This section explains the concepts
and shows how to confirm the existence or nonexistence of such routes.
Successor and Feasible Successor Concepts
For each prefix/prefix length, when multiple possible routes exist, the router chooses the
route with the smallest integer metric (smallest FD). EIGRP defines each such route as the
successor route for that prefix, and EIGRP defines the next-hop router in such a route as
the successor. EIGRP then creates an IP route for this prefix, with the successor as the
next-hop router, and places that route into the IP routing table.
If more than one possible route exists for a given prefix/prefix length, the router examines
these other (non-successor) routes and asks this question: Can any of these routes be used
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 79
immediately if the currently best route fails, without causing a routing loop? EIGRP runs
a simple algorithm to identify which routes could be used without causing a routing loop,
and EIGRP keeps these loop-free backup routes in its topology table. Then, if the successor
route (the best route) fails, EIGRP then immediately uses the best of these alternate
loop-free routes for that prefix.
EIGRP calls these alternative, immediately usable, loop-free routes feasible successor
routes, because they can feasibly be used as a new successor route when the current successor
route fails. The next-hop router of such a route is called the feasible successor.
Note: In general conversation, the term successor may refer to the route or specifically to
the next-hop router. Likewise, the term feasible successor may refer to the route, or the
next-hop router, of an alternative route.
A router determines if a route is a feasible successor based on the feasibility condition,
defined as follows:
If a non-successor route’s RD is less than the FD, the route is a feasible successor route.
Although technically correct, the preceding definition is much more understandable with
an example as shown in Figure 3-8. The figure illustrates how EIGRP figures out which
routes are feasible successors for Subnet 1.
In Figure 3-8, Router E learns three routes to Subnet 1, from Routers B, C, and D. After
calculating each route’s metric, Router E finds that the route through Router D has the
lowest metric. Router E adds this successor route for Subnet 1 to its routing table, as
shown. The FD in this case for this successor route is 14,000.
EIGRP decides if a route can be a feasible successor if the reported distance for that route
(the metric as calculated on that neighbor) is less than its own best computed metric (the
FD). When that neighbor has a lower metric for its route to the subnet in question, that
route is said to have met the feasibility condition.
Key
Topic
Subnet 1 Metric 15,000
Route Through Router B — 19,000
Route Through Router C — 17,500
Route Through Router D — 14,000
Subnet 1 Metric 13,000
Subnet 1
Subnet 1 Metric 10,000
80 CCNP ROUTE 642-902 Official Certification Guide
For example, Router E computes a metric (FD) of 14,000 on its successor route (through
Router D). Router C’s computed metric–E’s RD for this alternate router through Router
C–is 13,000, which is lower than E’s FD (14,000). As a result, E knows that C’s best route
for this subnet could not possible point toward router E, so Router E believes that its
route, to Subnet 1, through Router C, would not cause a loop. As a result, Router E marks
its topology table entry for the route through Router C as a feasible successor route.
Conversely, E’s RD for the route through Router B, to Subnet 1, is 15,000, which is larger
than Router E’s FD of 14,000. So, this alternative route does not meet the feasibility condition,
so Router E does not consider the route through Router B a feasible successor route.
If the route to Subnet 1 through Router D fails, Router E can immediately put the route
through Router C into the routing table without fear of creating a loop. Convergence
occurs almost instantly in this case. However, if both C and D fail, E would not have a feasible
successor route, and would have to do additional work, as described later in the section
“Converging by Going Active,” before using the route through Router B.
By tuning EIGRP metrics, an engineer can create feasible successor routes in cases where
none existed, improving convergence.
Verification of Feasible Successors
Determining which prefixes have both successor and feasible successor routes is somewhat
simple if you keep the following in mind:
■ The show ip eigrp topology command does not list all known EIGRP routes, but instead
lists only successor and feasible successor routes.
■ The show ip eigrp topology all-links command lists all possible routes, including
those that are neither successor nor feasible successor routes.
For example, consider Figure 3-9, which again focuses on Router WAN1’s route to Router
B1’s LAN subnet, 10.11.1.0/24. The configuration on all routers has reverted back to defaults
for all settings that impact the metric: default bandwidth and delay, no offset lists,
and all interfaces are up.
Figure 3-9 shows the three topologically possible routes to reach 10.11.1.0/24, labeled 1, 2,
and 3. Route 1, direct to Router B1, is the current successor. Route 3, which goes to another
branch router, back to the main site, and then to Router B1, is probably a route you
would not want to use anyway. However, route 2, through WAN2, would be a reasonable
back-up route.
If the PVC between WAN1 and B1 failed, WAN1 would converge to route 2 from the
figure. However, with all default settings, route 2 is not an FS route, as demonstrated in
Example 3-7.
A quick comparison of the two commands show that the show ip eigrp topology command
shows only one next-hop address (10.1.1.2), whereas the show ip eigrp topology alllinks
command shows two (10.1.1.2 and 10.9.1.2). The first command lists only successor
and feasible successor routes, so in this case, only one such route for 10.1.1.0/24 exists—
the successor route, direct to B1 (10.1.1.2).
The output of the show ip eigrp topology all-links command is particularly interesting in
this case. It lists two possible next-hop routers: 10.1.1.2 (B1) and 10.9.1.2 (WAN2). It does
www.CareerCert.info
82 CCNP ROUTE 642-902 Official Certification Guide
not list the route through Router B2 (10.1.1.6) at all, because B2’s current successor route
for 10.11.1.0/24 is through WAN1. EIGRP Split Horizon rules tell B2 to not advertise
10.11.1.0/24 to WAN1.
Next, focus on the route labeled as option 2 in Figure 3-9, the route from WAN1, to
WAN2, then to B1. Per the show ip eigrp topology all-links command, this route has an
RD of 2,172,416–the second number in parenthesis as highlighted toward the end of
Example 3-6. WAN1’s successor route has an FD of that exact same value. So, this one
possible alternate route for 10.11.1.0/24, through WAN2, does not meet the feasibility
condition–but just barely. To be an FS route, the route’s RD must be less than the FD, and
in this example, the two are equal.
To meet the design requirement for quickest convergence, you could use any method to
manipulate the metrics such that eitherWAN2’s metric for 10.11.1.0 is lower, orWAN1’s
metric for its successor route is higher. Example 3-8 shows the results of simply adding
back the offset-list onWAN1, as seen in Example 3-5, which increasesWAN1’s metric by 3.
Example 3-8 Increasing WAN1’s Metric for 10.11.1.0/24, Creating an FS Route
WAN1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
WAN1(config)#access-list 11 permit 10.11.1.0
WAN1(config)#router eigrp 1
WAN1(config-router)#offset-list 11 in 3 s0/0/0.1
WAN1(config-router)#^Z
WAN1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.9.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.11.1.0/24, 1 successors, FD is 2172419
via 10.1.1.2 (2172419/28163), Serial0/0/0.1
via 10.9.1.2 (2174976/2172416), FastEthernet0/0
! lines omitted for brevity; no other lines of output pertain to 10.11.1.0/24.
Note that now WAN1’s successor route FD is 2,172,419, which is higher than WAN2’s
(10.9.1.2’s) RD of 2,172,416. As a result, WAN1’s route through WAN2 (10.9.1.2) now meets
the feasibility condition. Also, the show ip eigrp topology command, which lists only
successor and feasible successor routes, now lists this new feasible successor route. Also
note that the output still states “1 successor,” so this counter indeed counts successor
routes and does not include FS routes.
When EIGRP on a router notices that a successor route has been lost, if a feasible successor
exists in the EIGRP topology database, EIGRP places that feasible successor route into
the routing table. The elapsed time from noticing that the route failed, until the route is replaced,
is typically less than 1 second. (A Cisco Live conference presentation asserts this
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 83
convergence approaches 200 milliseconds.) With well-tuned EIGRP Hold Timers and with
feasible successor routes, convergence time can be held low.
Converging by Going Active
When EIGRP removes a successor route and no FS route exists, the router begins a
process by which the router discovers if any loop-free alternative routes each reach that
prefix. This process is called going active on a route. Routes for which the router has a
successor route, and no failure has yet occurred, remain in a passive state. Routes for
which the successor route fails, with no feasible successor routes, move to an active state,
as follows:
■ Change the state, as listed in the show ip eigrp topology command, from passive (p)
to active (a).
■ Send EIGRP Query messages to every neighbor except the neighbor in the failed
route. The Query asks a neighbor whether that neighbor has a loop-free route for the
listed prefix/length.
■ The neighbor considers itself to have a loop-free route if that neighbor is passive for
that prefix/length. If so, the neighbor 1) sends an EIGRP Reply message, telling the
original router that it does indeed have a loop-free route and 2) does not forward
the Query.
■ If the neighbor itself is active on this route, that neighbor 1) floods EIGRP Query
messages to its neighbors and 2) does not immediately send an EIGRP Reply back to
the original router–instead waiting on replies to its own set of Query messages.
■ When a router has received Reply messages from all neighbors to which it sent any
Query messages, that router can then send a Reply message to any of its neighbors as
necessary.
■ When a router has received a Reply for all its Query messages, that router may safely
use the best of the routes confirmed to be loop free.
Key
Topic
Note: The EIGRP convergence process when going active on a route is sometimes also
referenced by the name of the underlying algorithm, named Diffusing Update Algorithm
(DUAL).
The process can and does work well in many cases, often converging to a new route in less
than 10 seconds. However, in internetworks with many remote sites, with much redundancy,
and with a large number of routers in a single end-to-end route, convergence when
going active can be inefficient. For example, consider the internetwork in Figure 3-10. The
figure shows five branch routers as an example, but the internetwork has 300 branch
routers, each with a PVC connected to two WAN routers, WAN1 and WAN2. When
Router WAN1 loses its route for the LAN subnet at branch B1, without an FS route, the
Query process can get out of hand.
The arrowed lines showWAN1’s Query messages and the reaction by several other routers
to forward the Query messages. Although only 5 branch routers are shown,WAN1 would
forward Query messages to 299 branch routers.WAN2 would do the same, assuming its
route to B1’s LAN also failed. These branch routers would then send Query messages back
to theWAN routers. The network would converge, but more slowly than if an FS route
existed.
Note: EIGRP sends every Query and Reply message using RTP, so every message is
acknowledged using an EIGRP ACK message.
By configuring EIGRP so that a router has FS routes for most routes, the whole Query
process can be avoided. However, in some cases, creating FS routes for all routes on all
routers is impossible, so engineers should take action to limit the scope of queries. The
next two sections discuss two tools—stub routers and route summarization—that help reduce
the work performed by the DUAL algorithm and the scope of Query messages.
The Impact of Stub Routers on Query Scope
Some routers, by design, should not be responsible for forwarding traffic between different
sites. For example, consider the familiar internetwork shown throughout this chapter,
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 85
most recently in Figure 3-10, and focus on the branch routers. If WAN2’s LAN interface
failed, and WAN1’s PVC to B1 failed, then a route still exists from the core to branch B1’s
10.11.1.0/24 subnet: WAN1–B2–WAN2–B1. (This is the same long route shown as route 3
in Figure 3-9.) However, this long route consumes the link bandwidth between the core
and branch B2, and the traffic to/from B1 will be slower. Users at both branches will suffer,
and these conditions may well be worse than just not using this long route.
Route filtering could be used to prevent WAN1 from learning such a route. However, using
route filtering would require a lot of configuration on all the branch routers, with
specifics for the subnets–and it would have to change over time. A better solution exists,
which is to make the branch routers stub routers. EIGRP defines stub routers as follows:
A router that should not forward traffic between two remote EIGRP-learned subnets.
To accomplish this goal, the engineer configures the stub routers using the eigrp stub
command. Stub routers do not advertise EIGRP-learned routes from one neighbor to
other EIGRP neighbors. Additionally, and possibly more significantly, nonstub routers
note which EIGRP neighbors are stub routers, and the nonstub routers do not send Query
messages to the stub routers. This action greatly reduces the scope of Query messages
when a route goes active, in addition to preventing the long, circuitous, and possibly
harmful route.
The eigrp stub command has several options. When issued simply as eigrp stub, the
router uses default parameters, which are the connected and summary options. (Note that
IOS adds these two parameters onto the command as added to the running-config.) Table
3-3 lists the eigrp stub command options and explains some of the logic behind using
them.
Note that stub routers still form neighborships, even in receive-only mode. The stub router
simply performs less work and reduces the Query Scope because neighbors will not send
these routes any Query messages.
For example, Example 3-9 shows the eigrp stub connected command on Router B2, with
the results being noticable on WAN1 (show ip eigrp neighbors detail).
Key
Topic
Key
Topic
Table 3-3 Parameters on the eigrp stub Command
Option This router is allowed to...
Connected Advertise connected routes but only for interfaces matched with a network
command.
Summary Advertise auto-summarized or statically configured summary routes.
Static Advertises static routes, assuming the redistribute static command is configured.
Redistributed Advertises redistributed routes, assuming redistribution is configured.
Receive-only Does not advertise any routes. This option cannot be used with any other
option.
www.CareerCert.info
86 CCNP ROUTE 642-902 Official Certification Guide
Example 3-9 Evidence of Router B2 as an EIGRP Stub Router
B2#configure terminal
B2(config)#router eigrp 1
B2(config-router)#eigrp stub connected
B2(config-router)#
Mar 2 21:21:52.361: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.9.1.14
(FastEthernet0/0.12) is down: peer info changed
! A message like the above occurs for each neighbor.
! Moving to router WAN1 next
WAN1#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.9.1.2 Fa0/0 11 00:00:04 7 200 0 588
Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 8
2 10.1.1.6 Se0/0/0.2 13 00:21:23 1 200 0 408
Version 12.4/1.2, Retrans: 2, Retries: 0, Prefixes: 2
Stub Peer Advertising ( CONNECTED ) Routes
Suppressing queries
0 10.9.1.6 Fa0/0.4 12 00:21:28 1 200 0 175
Version 12.2/1.2, Retrans: 3, Retries: 0, Prefixes: 6
The Impact of Summary Routes on Query Scope
In addition to EIGRP stub routers, route summarization also limits EIGRP Query scope
and therefore improves convergence time. The reduction in Query scope occurs due to the
following rule:
If a router receives an EIGRP Query for a prefix/prefix length, does not have an exactly
matching (both prefix and prefix length) route, but does have a summary route that includes
the prefix/prefix length, that router immediately sends an EIGRP Reply and does
not flood the Query to its own neighbors.
For example, consider Figure 3-11. Multilayer Switches C1 and C2 sit in the core of the
network shown in various other figures in this chapter, and both C1 and C2 run EIGRP.
The IP subnetting design assigns all branch office LAN subnets from the range
10.11.0.0/16 and 10.12.0.0/16. As such, Routers WAN1 and WAN2 advertise summary
routes for these ranges, rather than for individual subnets. So, under normal operation,
ignoring the whole Query scope issue, C1 and C2 would never have routes for individual
branch subnets like 10.11.1.0/24 but would have routes for 10.11.0.0/16 and 10.12.0.0/16.
The figure highlights three steps:
Step 1. WAN1 and WAN2 advertise summary routes, so that C1, C2, and all other
routers in the core have a route for 10.11.0.0/16 but not a route for 10.11.1.0/24.
Step 2. Some time in the future, WAN1 loses its route for 10.11.1.0/24, so WAN1
sends a Query for 10.11.1.0/24 to C1 and C2.
with features like stub routers and route summarization in use, convergence can still happen
in a reasonable amount of time even when going active. The next feature, load sharing,
takes convergence to another level, giving instantaneous convergence, while reaching other
goals as well.
IOS allows routing protocols to place multiple routes into the routing table for an individual
prefix/length. IOS then balances traffic across those routes, by default balancing
traffic on a per-destination IP address basis.
Load balancing, sometimes called load sharing, provides a primary benefit of making use
of the available bandwidth, rather than using some links as simply backup links. For
example, with the two-PVC designs repeatedly shown in this chapter (Figures 3-1, 3-9, and
3-10), without load sharing, a branch router would send traffic over one PVC, but not
both. With load sharing, some traffic would flow over each PVC.
A useful secondary benefit–faster convergence–occurs when using load balancing. By
placing multiple routes into the routing table for a single prefix, convergence happens
essentially instantly. For example, if a branch router has two routes for each data center
subnet—one using each PVC that connects the branch to the core—and one of the routes
fails, the other route is already in the routing table. In this case, the router does not need
to look for FS routes nor go active on the route. The router uses the usual EIGRP convergence
tools only when all such routes are removed from the routing table.
The load balancing configuration requires two commands, one of which already defaults
to a reasonable setting. First, you need to define the number of allowed routes for each
prefix/prefix length using the maximum-paths number EIGRP subcommand. The default
setting of 4 is often big enough, because most internetworks do not have enough redundancy
to have more than four possible routes.
Note: The maximum number of paths varies based on IOS version and router platform.
However, for the much older IOS versions, the maximum was 6 routes, with later versions
typically supporting 16 or more.
The second part of the load balancing configuration overcomes a challenge introduced by
EIGRP’s metric calculation. The EIGRP integer metric calculation often results in 8-to-10-
digit integer metrics, so the metrics of competing routes are seldom the exact same value.
Calculating the exact same metric for different routes for the same prefix is statistically
unlikely.
IOS includes the concept of EIGRP variance to overcome this problem. Variance lets you
tell IOS that the EIGRP metrics can be close in value and still be considered worthy of being
added to the routing table—and you can define how close.
The variance multiplier EIGRP router subcommand defines an integer between 1 and
128. The router then multiplies the variance times the successor route’s FD–the metric of
the best route to reach that subnet. Any FS routes whose metric is less than the product of
the variance times the FD are considered to be equal routes and may be placed into the
routing table, up to the number of routes defined by the maximum-paths command.
www.CareerCert.info
90 CCNP ROUTE 642-902 Official Certification Guide
Subnet 1
Metric 50
R4 R2
R3
R1
Metric 120
Metric 90
Metric 30
Metric 60
Metric 40
Figure 3-13 Example of the Use of Variance
Table 3-4 Example of Routes Chosen as Equal Due to Variance
Nexthop
Metric RD Added to Routing
Table at Variance 1?
Added to
Routing Table at
Variance 2?
Added to Routing
Table at Variance 3?
R1 50 30 Yes Yes Yes
R2 90 40 No Yes Yes
R3 120 60 No No No
For example, consider the example as shown in Figure 3-13 and Table 3-4. In this example,
to keep the focus on the concepts, the metrics are small easy-to-compare numbers,
rather than the usual large EIGRP metrics. The example focuses on R4’s three possible
routes to reach Subnet 1. The figure shows the RD of each route next to Routers R1, R2,
and R3, respectively.
Before considering the variance, note that in this case the route through R1 is the successor
route because it has the lowest metric. This also means that the FD is 50. The route
through R2 is an FS route because its RD of 40 is less than the FD of 50. The route
through R3 is not an FS route, because R3’s RD of 60 is more than the FD of 50.
At a default variance setting of 1, the metrics must be exactly equal to be considered
equal, so only the successor route is added to the routing table (the route through R1).
With variance 2, the FD (50) is multiplied by the variance (2) for a product of 100. The
route through R2, with FD 90, is less than 100, so R4 will add the route through R2 to the
routing table as well. The router can then load balance traffic across these two routes.
Table 3-4 summarizes these cases, plus one other, which is described after the table.
In the third case, with variance 3, the product of the FD (50) times 3 results equals 150.
All three routes’ calculated metrics (their FD values) are less than 150. However, the route
through R3 is not an FS route, so it cannot be added to the routing table for fear of
causing a routing loop. So, R4 adds only the routes through R1 and R2 to its IP routing
table. (Note that the variance and maximum-paths settings can be verified by using the
show ip protocols command.)
The following list summarizes the key points about variance:
■ The variance is multiplied by the current FD (the metric of the best route to reach the
subnet).
■ Any FS routes whose calculated metric is less than or equal to the product of
variance times FD are added to the IP routing table, assuming the maximum-paths
setting allows more routes.
■ Routes that are neither successor nor feasible successor can never be added to the IP
routing table, regardless of the variance setting.
When the routes have been added to the routing table, the router supports a couple of
methods for how to load balance traffic across the routes. The router can balance the traffic
proportionally with the metrics, meaning that lower metric routes send more packets.
Also, the router can send all traffic over the lowest-metric route, with the other routes just
being in the routing table for faster convergence in case the best route fails.
No comments:
Post a Comment