Building the EIGRP Topology Table best cisco ccna training center in delhi

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 overall process of building the EIGRP topology table is relatively straightforward.
EIGRP defines some basic topology information about each route for each unique
prefix/length (subnet). This basic information includes the prefix, prefix length, metric information,
and a few other details. EIGRP neighbors exchange topology information, with
each router storing the learned topology information in their respective EIGRP topology
table. EIGRP on a given router can then analyze the topology table, or topology database,
and choose the best route for each unique prefix/length.
EIGRP uses much simpler topology data than does OSPF, which is a link state protocol
that must describe the entire topology of a portion of a network with its topology database.
EIGRP, essentially an advanced distance vector protocol, does not need to define
nearly as much topology data, nor do EIGRP routers need to run the complex Shortest
Path First (SPF) algorithm. This first major section examines the EIGRP topology database,
how routers create and flood topology data, and some specific issues related to
WAN links.
Seeding the EIGRP Topology Table
Before a router can send EIGRP topology information to a neighbor, that router must have
some topology data in its topology table. Routers can, of course, learn about subnets and
the associated topology data from neighboring routers. However to get the process
started, each EIGRP router needs to adds topology data for some prefixes, so it can then
advertise these routes to its EIGRP neighbors. A router’s EIGRP process adds subnets to
its local topology table, without learning the topology data from an EIGRP neighbor,
from three sources:
■ Prefixes of connected subnets for interfaces on which EIGRP has been enabled on
that router using the network command
■ Prefixes of connected subnets for interfaces referenced in an EIGRP neighbor command
■ Prefixes learned by the redistribution of routes into EIGRP from other routing protocols
or routing information sources
After a router adds such prefixes to its local EIGRP topology database, that router can
then advertise the prefix information, along with other topology information associated
with each prefix, to each working EIGRP neighbor. Each router adds any learned prefix
information to their topology table, and then that router advertises the new information to
other neighbors. Eventually, all routers in the EIGRP domain learn about all prefixes–
unless some other feature, such as route summarization or route filtering, alters the flow
of topology information.
60 CCNP ROUTE 642-902 Official Certification Guide
Key
Topic
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 61
The Content of EIGRP Update Message
EIGRP uses five basic protocol messages to do its work:
■ Hello
■ Update
■ Query
■ Reply
■ ACK (acknowledgment)
EIGRP uses two messages as part of the topology data exchange process: Update and
Ack. The Update message contains the topology information, whereas the ACK acknowledges
receipt of the update packet.
The EIGRP Update message contains the following information:
■ Prefix
■ Prefix length
■ Metric components: bandwidth, delay, reliability, and load
■ Nonmetric items: MTU and hop count
Note: Many courses and books over the years have stated that MTU is part of the EIGRP
metric. In practice, the MTU has never been part of the metric calculation, although it is
included in the topology data for each prefix.
To examine this whole process in more detail, see Figure 3-1 and Figure 3-2. Figure 3-1
shows a portion of an Enterprise network that will be used in several examples in this
chapter. Routers B1 and B2 represent typical branch office routers, each with two Frame
Relay PVCs connected back to the main site. WAN1 and WAN2 are WAN distribution
routers, each of which would normally have dozens or hundreds of PVCs.
The routers in Figure 3-1 have been configured and work. For EIGRP, all routers have been
configured with as many defaults as possible, with the only configuration related to
EIGRP being the router eigrp 1 and network 10.0.0.0 commands on each router.
Next, consider what Router B1 does for its connected route for subnet 10.11.1.0/24, which
is located on B1’s LAN. B1 matches its Fa0/0 interface IP address (10.11.1.1) due to its
network 10.0.0.0 configuration command. So as mentioned earlier, B1 seeds its own
topology table with an entry for this prefix. This topology table entry also lists the interface
bandwidth of the associated interface and delay of the associated interface. Using default
settings for FastEthernet interfaces, B1 uses a bandwidth of 100,000 Kbps (the same
as 100 Mbps) and a delay of 10, meaning 10 tens-of-microseconds. Router B1 also includes
a default setting for the load (1) and reliability (255), even though the router, using
the default K-value settings, will not use these values in its metric calculations. Finally, B1
adds to the topology database the MTU of the local interface and a hop count of zero because
the subnet is connected.
Key
Topic
www.CareerCert.info
62 CCNP ROUTE 642-902 Official Certification Guide
Note: All WAN IP addresses begin with 10.1
10.9.1.1/24
Fa0/0
10.9.1.2/24
Fa0/0
10.11.1.1
Fa0/0
10.12.1.1
Fa0/0
B1 WAN1
B2 WAN2
1.2
S0/0/0.1
2.6
S0/0/0.2
2.2
S0/0/0.2
1.6
S0/0/0.1
1.5
S0/0/0.2
2.1
S0/0/0.1
1.1
S0/0/0.1
2.5
S0/0/0.2
Figure 3-1 Typical WAN Distribution and Branch Office Design
1
2
3
Update:
Subnet 10.11.1.0/24
Delay 10
Bandwidth 100,000
(MTU, Load,
Reliability, Hops)
Update:
Subnet 10.11.1.0/24
Delay 2010
Bandwidth 1544
(MTU, Load,
Reliability, Hops)
Topology Table:
Subnet 10.11.1.0/24
Delay = 10 + 2000 = 2010
Bandwidth = Min(100,000
or 1544)
(MTU, Load, Reliability,
Hops)
! On Router B1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
B1#show ip eigrp topology 10.11.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.11.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 28160
Routing Descriptor Blocks:
0.0.0.0 (FastEthernet0/0), from Connected, Send flag is 0x0
Composite metric is (28160/0), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
! On Router WAN1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
WAN1#show ip eigrp topology 10.11.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.11.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2172416
Routing Descriptor Blocks:
10.1.1.2 (Serial0/0/0.1), from 10.1.1.2, Send flag is 0x0
Composite metric is (2172416/28160), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20100 microseconds
Chapter 3: EIGRP Topology, Routes, and Convergence 63
WAN1 also updates load (highest value), reliability (lowest value), and MTU
(lowest value) based on similar comparisons, and adds 1 to the hop count.
Step 3. WAN1 then sends an Update to its neighbors, with the metric components
listed in its own topology table.
This example provides a good backdrop to understand how EIGRP uses cumulative delay
and minimum bandwidth in its metric calculation. Note that at Step 2, router WAN1 adds
to the delay value but does not add the bandwidth. For bandwidth, WAN1 simply chooses
the lowest bandwidth, comparing the bandwidth of its own interface (S0/0/0.1) with the
bandwidth listed in the received EIGRP update.
Next, consider this logic on other routers—not shown in the figure—as WAN1 floods this
routing information throughout the Enterprise. WAN1 then sends this topology information
to another neighbor, and that router sends the topology data to another, and so on. If
bandwidth of those links was 1544 or higher, the bandwidth setting used by those routers
would remain the same, because each router would see that the routing update’s bandwidth
(1544 Kbps) was lower than the link’s bandwidth. However, each router would add
something to the delay.
As a final confirmation of the contents of this Update process, Example 2-1 shows the details
of the EIGRP topology database for prefix 10.11.1.0/24 on both B1 and WAN1.
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
The highlighted portions of output match the details shown in Figure 3-2, but with one
twist relating to the units on the delay setting. The IOS delay command, which lets you set
the delay, along with the data stored in the EIGRP topology database, use a unit of tensof-
microsecond. However, the show interfaces and show ip eigrp topology commands
list delay in a unit of microseconds. For example, WAN1’s listing of “20100 microseconds”
matches the “2010 tens-on-microseconds” shown in Figure 3-2.
The EIGRP Update Process
So far, this chapter has focused on the detailed information EIGRP exchanges with a
neighbor about each prefix. This section takes a broader look at the process.
When EIGRP neighbors first become neighbors, they begin exchanging topology information
using Update messages using these rules:
■ When a neighbor first comes up, the routers exchange full updates, meaning the
routers exchange all topology information.
■ After all prefixes have been exchanged with a neighbor, the updates cease with that
neighbor if no changes occur in the network. There is no periodic reflooding of
topology data.
■ If something changes–for example, one of the metric components change, links fail,
links recover, new neighbors advertise additional topology information–the routers
send partial updates about only the prefixes whose status or metric components have
changed.
■ If neighbors fail and then recover, or new neighbor adjacencies are formed, full updates
occur over these adjacencies.
■ EIGRP uses Split Horizon rules on most interfaces by default, which impacts exactly
which topology data EIGRP sends during both full and partial updates.
Split Horizon, the last item in the list, needs a little more explanation. Split Horizon limits
the prefixes that EIGRP advertises out an interface. Specifically, if the currently best route
for a prefix lists a particular outgoing interface, Split Horizon means that EIGRP will not
include that prefix in the Update sent out that same interface. For example, router WAN1
uses S0/0/0.1 as its outgoing interface for subnet 10.11.1.0/24, so WAN1 would not advertise
prefix 10.11.1.0/24 in its Update messages sent out S0/0/0.1.
Note: Route summarization and route filtering, as explained in Chapter 4, “EIGRP Route
Summarization and Filtering,” also affect which subsets of the topology table are flooded.
Key
Topic
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 65
To send the Updates, EIGRP uses the Reliable Transport Protocol (RTP) to send the
EIGRP updates and confirm their receipt. On point-to-point topologies such as serial
links, MPLS VPN, and Frame Relay when using point-to-point subinterfaces, the EIGRP
Update and ACK messages use a simple process of acknowledging each Update with an
ACK. On multiaccess data links, EIGRP typically sends Update messages to multicast
address 224.0.0.10 and expects a unicast EIGRP ACK message from each neighbor in reply.
RTP manages that process, setting timers so that the sender of an Update waits a reasonable
time, but not too long, before deciding whether all neighbors received the Update or
whether one or more neighbors did not reply with an ACK.
Although EIGRP relies on the RTP process, network engineers cannot manipulate how
it works.
WAN Issues for EIGRP Topology Exchange
With all default settings, after you enable EIGRP on all the interfaces in an internetwork,
the topology exchange process typically does not pose any problems. However, a few
scenarios exist, particularly on Frame Relay, which can cause problems. This section summarizes
two issues and shows the solution.
Split Horizon Default on Frame Relay Multipoint Subinterfaces
IOS support for Frame Relay allows the configuration of IP addresses on the physical serial
interface, multipoint subinterfaces, and point-to-point subinterfaces. Additionally, IP
packets can be forwarded over a PVC even when the routers on the opposite ends do not
have to use the same interface or subinterface type. As a result, many small intricacies exist
in the operation of IP and IP routing protocols over Frame Relay, particularly related to
default settings on different interface types.
Frame Relay supports several reasonable configuration options using different interfaces
and subinterfaces, each meeting different design goals. For instance, if the design includes
a few centralized WAN distribution routers, with PVCs connecting each branch router to
each distribution router, both distribution and branch routers might use point-to-point
subinterface. Such a choice makes the Layer 3 topology simple, with all links acting like
point-to-point links from a Layer 3 perspective. This choice also removes issues such as
Split Horizon.
In some cases, a design might include a small set of routers that have a full mesh of PVCs
connecting each. In this case, multipoint subinterfaces might be used, consuming a single
subnet, reducing the consumption of the IP address space. This choice also reduces the
number of subinterfaces.
Both options–using point-to-point subinterfaces or using multipoint subinterfaces–have
legitimate reasons for being used. However, when using the multipoint subinterface
option, a particular EIGRP issue can occur when the following are true:
■ Three or more routers, over Frame Relay, are configured as part of a single subnet.
■ The routers use multipoint interfaces.
■ Either permanently or for a time, a full mesh of PVCs between the routers does
not exist.
www.CareerCert.info
66 CCNP ROUTE 642-902 Official Certification Guide
No PVC
No Hellos
No Neighbors
10.11.1.0/24
B1 WAN1
S0/0/0.9
B2
10.1.1.2/29
10.1.1.3/29
1
2 Update 10.11.1.0/24 . . .
10.1.1.1/29
. . . But not here!
(Split Horizon)
10.12.1.0/24
Figure 3-3 Partial Mesh, Central Sites (WAN1) Uses Multipoint Subinterface
For example, consider Router WAN1 shown earlier in Figure 3-1 and referenced again in
Figure 3-3. In the earlier configurations, the WAN distribution routers and branch routers
all used point-to-point subinterfaces and a single subnet per VC. To see the problem raised
in this section, consider that same internetwork, but now the engineer has chosen to configure
WAN1 to use a multipoint subinterface and a single subnet for WAN1, B1, and B2,
as shown in Figure 3-3.
The first issue to consider in this design is that B1 and B2 will not become EIGRP neighbors
with each other, as noted with Step 1 in the figure. EIGRP routers must be reachable
using Layer 2 frames before they can exchange EIGRP Hello messages and become EIGRP
neighbors. In this case, there is no PVC between B1 and B2. B1 exchanges Hellos with
WAN1, and become neighbors, as will B2 with WAN1. However, routers do not forward
received EIGRP Hellos, so WAN1 will not receive a Hello from B1 and forward it to B2 or
vice versa. In short, although in the same subnet (10.1.1.0/29), B1 and B2 will not become
EIGRP neighbors.
The second problem occurs due to Split Horizon logic on Router WAN1, as noted with
Step 2 in the figure. As shown with Step 2 in the figure, B1 could advertise its routes to
WAN1, and WAN1 could advertise those routes to B2–and vice versa. However, with
default settings, WAN1 will not advertise those routes due to its default setting of Split
Horizon (a default interface subcommand setting of ip split-horizon eigrp asn.) As a
result, WAN1 receives the Update from B1 on its S0/0/0.9 subinterface, but Split Horizon
prevents WAN1 from advertising that topology data to B2 in Updates sent out interface
S0/0/0.9, and vice versa.
The solution is somewhat simple–just configure the no ip split-horizon eigrp asn command
on the multipoint subinterface on WAN1. The remote routers, B1 and B2 in this
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 67
case, still do not become neighbors, but that does not cause a problem by itself. With
Split Horizon disabled on WAN1, B1 and B2 learn routes to the other branch’s subnets.
Example 3-2 lists the complete configuration and the command to disable Split Horizon:
Note: Frame Relay configuration is considered a prerequisite because it is part of the
CCNA exam and courses. Example 3-2 uses frame-relay interface-dlci commands and
relies on Inverse ARP. However, if frame-relay map commands were used instead, disabling
Inverse ARP, the EIGRP details discussed in this example would remain unchanged.
Example 3-2 Frame Relay Multipoint Configuration on WAN1
! On Router WAN1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
interface Serial0/0/0
no ip address
encapsulation frame-relay
interface Serial0/0/0.9 multipoint
ip address 10.1.1.1 255.255.255.248
no ip split-horizon eigrp 1
frame-relay interface-dlci 103
frame-relay interface-dlci 104
!
router eigrp 1
network 10.0.0.0
Note: The [no] ip split-horizon command controls Split Horizon behavior for RIP; the
[no] ip split-horizon eigrp asn command controls Split Horizon behavior for EIGRP.
Displaying the EIGRP Split Horizon state of an interface is an unusually difficult piece of
information to find without simply displaying the configuration. By default, IOS enables
EIGRP Split Horizon. To find the setting for an interface, look for the presence or absence
of the no ip split-horizon eigrp command on the configuration. Also, the debug ip eigrp
command output displays messages stating when prefixes are not advertised out an interface
due to split horizon.
EIGRP WAN Bandwidth Control
In a multiaccess WAN, one physical link passes traffic for multiple data link layer destinations.
For example, a WAN distribution router connected to many branches using Frame
Relay might literally terminate hundreds, or even thousands, of Frame Relay PVCs.
In a nonbroadcast multiaccess (NBMA) medium such as Frame Relay, when a router needs
to send EIGRP updates, the Updates cannot be multicasted at Layer 2. So, the router must
www.CareerCert.info
68 CCNP ROUTE 642-902 Official Certification Guide
send a copy of the Update to each reachable neighbor. For a WAN distribution router with
many Frame Relay PVCs, the sheer amount of traffic sent over the Frame Relay access link
might overload the link.
The EIGRP WAN bandwidth control allows the engineer to protect a multiaccess Frame
Relay interface from being overrun with too much EIGRP message traffic. By default, a
router sends EIGRP messages out an interface but only up to 50 percent of the bandwidth
defined on the interface with the bandwidth command. The engineer can adjust this percentage
using the ip bandwidth-percent eigrp asn percent interface/subinterface subcommand.
Regardless of the percentage, IOS then limits the rate of sending the EIGRP
messages so that the rate is not exceeded. To accomplish this, IOS queues the EIGRP messages
in memory, delaying them briefly.
The command to set the bandwidth percentage is simple, but there are a few caveats to
keep in mind when trying to limit the bandwidth consumed by EIGRP:
■ The IOS default for bandwidth serial interfaces and subinterfaces is 1544 (Kbps).
■ EIGRP limits the consumed bandwidth based on the percentage of interface/
subinterface bandwidth.
■ This feature keys on the bandwidth of the interface or subinterface through which the
neighbor is reachable, so don’t set only the physical interface bandwidth and forget
the subinterfaces.
■ Recommendation: Set the bandwidth of point-to-point links to the speed of the
Committed Information Rate (CIR) of the single PVC on the subinterface.
■ General recommendation: Set the bandwidth of multipoint subinterfaces to around
the total CIR for all VCs assigned to the subinterface.
■ Note that for multipoint subinterfaces, IOS WAN bandwidth control first divides the
subinterface bandwidth by the number of configured PVCs and then determines
the EIGRP percentage based on that number.
For example, consider Figure 3-4, which shows a router with one multipoint subinterface
and one point-to-point subinterface. With the configuration shown in Example 3-3,
WAN1 uses the following bandwidth, at most, with each neighbor:
■ B1, B2, and B3: 20 Kbps (20% of 300Kbps / 3 VCs)
■ B4: 30 Kbps (30% of 100 Kbps)
Example 3-3 Configuration of WAN1, One Multipoint, One Point-to-Point
! On Router WAN1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
interface Serial0/0/0.20 multipoint
ip address 172.16.1.1 255.255.255.240
frame-relay interface-dlci 201
frame-relay interface-dlci 202
frame-relay interface-dlci 203
B1 would have calculated as its FD. Step 4 shows the same formula but with the metric
components as listed at Step 2–after the adjustments made on WAN1. Step 4 shows
WAN1’s FD calculation, which is much larger due to the much lower constraining bandwidth
plus the much larger cumulative delay.
WAN1 chooses its best route to reach 10.11.1.0/24 based on the lowest FD among all possible
routes. Looking back to the much more detailed Figure 3-1, presumably a couple of
other routes might have been possible, but WAN1 happens to choose the route shown in
Figure 3-5 as its best route. As a result, WAN1’s show ip route command lists the FD calculated
in Figure 3-5 as the metric for this route, as shown in Example 3-4.
Example 3-4 Router WAN1’s EIGRP Topology and IP Route Information for 10.11.1.0/24
! Below, note that WAN1’s EIGRP topology table lists two possible next-hop
! routers: 10.1.1.2 (B1) and 10.9.1.2 (WAN2). The metric for each route,
! the first number in parenthesis, shows that the lower metric route is the one
! through 10.1.1.2 as next-hop. Also note that the metric components
! match Figure 3-5.
!
WAN1#show ip eigrp topo 10.11.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.11.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2172416
Routing Descriptor Blocks:
10.1.1.2 (Serial0/0/0.1), from 10.1.1.2, Send flag is 0x0
Composite metric is (2172416/28160), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.9.1.2 (FastEthernet0/0), from 10.9.1.2, Send flag is 0x0
Composite metric is (2174976/2172416), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
!
! The next command not only lists the IP routing table entry for 10.11.1.0/24,
! it also lists the metric (FD), and components of the metric.
!
WAN1#show ip route 10.11.1.0
Routing entry for 10.11.1.0/24
www.CareerCert.info
72 CCNP ROUTE 642-902 Official Certification Guide
Known via “eigrp 1”, distance 90, metric 2172416, type internal
Redistributing via eigrp 1
Last update from 10.1.1.2 on Serial0/0/0.1, 00:02:42 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 10.1.1.2, 00:02:42 ago, via Serial0/0/0.1
Route metric is 2172416, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
!
! Below, the route for 10.11.1.0/24 is again listed, with the metric (FD), and
! the same next-hop and outgoing interface information.
!
WAN1#show ip route eigrp
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D 10.11.1.0/24 [90/2172416] via 10.1.1.2, 00:10:40, Serial0/0/0.1
D 10.12.1.0/24 [90/2172416] via 10.1.1.6, 00:10:40, Serial0/0/0.2
D 10.1.2.0/30 [90/2172416] via 10.9.1.2, 00:10:40, FastEthernet0/0
D 10.1.2.4/30 [90/2172416] via 10.9.1.2, 00:10:40, FastEthernet0/0
EIGRP Metric Tuning
EIGRP metrics can be changed using several methods: setting interface bandwidth, setting
interface delay, changing the metric calculation formula by configuring k-values, and even
by adding to the calculated metric using offset-lists. In practice, the most reasonable and
commonly used methods are to set the interface delay and the interface bandwidth. This
section examines all the methods, in part so you will know which useful tools exist, and in
part to make you aware of some other design issues that then might impact the routes
chosen by EIGRP.
Configuring Bandwidth and Delay
The bandwidth and delay interface subcommands set the bandwidth and delay associated
with the interface. The commands themselves require little thought, other than keeping
the units straight. The unit for the bandwidth command is Kilobits/second, and the delay
command uses a unit of tens-of-microseconds.
If a design requires that you influence the choice of route by changing bandwidth or delay,
setting the delay value is typically the better choice. IOS uses the bandwidth setting
of an interface for many other reasons: calculating interface utilization, as the basis for
several QoS parameters, and for SNMP statistics reporting. However, the delay setting has
little influence on other IOS features besides EIGRP, so the better choice when influencing
EIGRP metrics is to tune the delay.
Table 3-2 lists some of the common default values for both bandwidth and delay. As a reminder,
show commands list the bandwidth in Kbps, which matches the bandwidth command,
but lists the delay in microseconds, which does not match the tens-of-microseconds
unit of the delay command.
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 73
Note that on LAN interfaces that can run at different speeds, the bandwidth and delay
settings default based on the current actual speed of the interface.
Choosing Bandwidth Settings on WAN Subinterfaces
Frame Relay and Metro Ethernet installations often use an access link with a particular
physical sending rate–clock rate if you will–but with the contracted speed, over time, being
more or less than the speed of the link. For example, with Frame Relay, the provider
may supply a full T1 access link, so configuring bandwidth 1544 for such an interface is
reasonable. However, the subinterfaces have one or more PVCs associated with them, and
those PVCs each have Committed Information Rates (CIR) that are typically less than the
access link’s clock speed. However, the cumulative CIRs for all PVC often exceeds the
clock rate of the physical interface. Conversely, MetroE designs use Ethernet access links
of 10 Mbps, 100 Mbps, or 1 Gbps actual link speed, but often the business contract limits
the amount of traffic to some number below that link speed.
Choosing a useful interface bandwidth setting on the subinterfaces in a Frame Relay or
MetroE design requires some thought, with most of the motivations for choosing one
number or another being unrelated to EIGRP. For example, imagine the network shown in
Figure 3-6. Router WAN1 has a single T1 (1.544 Mbps) access link. That interface has one
multipoint subinterface, with three PVCs assigned to it. It also has nine other point-topoint
subinterfaces, each with a single PVC assigned.
For the sake of discussion, the design in Figure 3-6 oversubscribes the T1 access link off
RouterWAN1 by a 2:1 factor. Assume all 12 PVCs have a CIR of 256 Kbps, making the total
bandwidth for the 12 PVCs roughly 3Mbps. The design choice to oversubscribe the access
link may be reasonable given the statistical chance of all sites sending at the same time.
Now imagine that Router WAN1 has been configured with subinterfaces as shown in
the figure:
■ S0/0/0.20 - multipoint, 3 PVCs
■ S0/0/0.21 through S0/0/0.29 – point-to-point, 1 PVC each
Next, consider the options for setting the bandwidth command’s value on these 10 subinterfaces.
The point-to-point subinterfaces could be set to match the CIR of each PVC (256
Kbps in this example). You could choose to set the bandwidth based on the CIR of all
combined PVCs on the multipoint subinterface–in this case, setting bandwidth 768 on
multipoint subinterface s0/0/0.20. However, these bandwidths would total about 3
EIGRP requires that two routers’ k-values match before those routers can become neighbors.
Also note that Cisco recommends again using k-values k2, k4, and k5, because a
nonzero value for these parameters causes the metric calculation to include interface
load and reliability. The load and reliability change over time, which causes EIGRP to reflood
topology data, and may cause routers to continually choose different routes (route
flapping).
Offset Lists
EIGRP Offset Lists, the final tool for manipulating the EIGRP metrics listed in this chapter,
allow an engineer to simply add a value–an offset, if you will-to the calculated integer
metric for a given prefix. To do so, an engineer can create and enable an EIGRP Offset List
that defines the value to add to the metric, plus some rules regarding which routes should
be matched and therefore have the value added to their computed FD.
An Offset List can perform the following functions:
■ Match prefixes/prefix lengths using an IP ACL, so that the offset is applied only to
routes matched by the ACL with a permit clause
■ Match the direction of the Update message, either sent (out) or received (in)
■ Match int interface on which the Update is sent or received
■ Set the integer metric added to the calculation for both the FD and RD calculations
for the route
The configuration itself uses the following command in EIGRP configuration mode, in addition
to any referenced IP ACLs:
offset-list {access-list-number | access-list-name} {in | out} offset [interfacetype
interface-number]
For example, consider again branch office Router B1 in Figure 3-1, with its connection to
both WAN1 and WAN2 over a Frame Relay network. Formerly, WAN1 calculated a metric
of 2,172,416 for its route, through B1, to subnet 10.11.1.0/24. (Refer to Figure 3-5 for the
math behind WAN1’s calculation of its route to 10.11.1.0/24.) Router WAN1 also calculated
a value of 28,160 for the RD of that same direct route. Example 3-5 shows the addition
of an offset on WAN1, for received updates from Router B1.
Example 3-5 Inbound Offset of 3 on WAN1, for Updates Received on S0/0/0.1
WAN1(config)#access-list 11 permit 10.11.1.0
WAN1(config)#router eigrp 1
WAN1(config-router)#offset-list 11 in 3 Serial0/0/0.1
WAN1(config-router)#end
Mar 2 11:34:36.667: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2
(Serial0/0/0.1) is resync: peer graceful-restart
WAN1#show ip eigrp topo 10.11.1.0/24
IP-EIGRP (AS 1): Topology entry for 10.11.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2172416
www.CareerCert.info
Chapter 3: EIGRP Topology, Routes, and Convergence 77
Routing Descriptor Blocks:
10.1.1.2 (Serial0/0/0.1), from 10.1.1.2, Send flag is 0x0
Composite metric is (2172419/28163), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
! output omitted for brevity
The configuration has two key elements: ACL 11 and the offset-list command. ACL 11
matches prefix 10.11.1.0, and that prefix only, with a permit clause. The offset-list 11 in 3
s0/0/0.1 command tells Router WAN1 to examine all EIGRP Updates received on S0/0/0.1,
and if prefix 10.11.1.0 is found, add 3 to the computed FD and RD for that prefix.
Note: Standard ACL 11 matches prefix 10.11.1.0 in this case, regardless of prefix length.
To match the exact prefix and prefix length, use an extended ACL. When doing so, use the
destination address field to match the prefix length. For example, access-list 111 permit ip
host 10.11.1.0 host 255.255.255.0 matches 10.11.1.0/24 exactly, including the prefix
length.
The show ip eigrp topology 10.11.1.0/24 command in Example 3-4 shows that the FD
and RD, highlighted in parentheses, are now each three larger as compared with the earlier
metrics.
Next, continuing this same example, Router B1 has now been configured to add an offset
(4) in its sent updates to all routers, but for prefix 10.11.1.0/24 only.
Example 3-6 Outbound Offset of 4 on B1, for Updates Sent to All Neighbors, 10.11.1.0/24
B1(config)#access-list 12 permit 10.11.1.0
B1(config)#router eigrp 1
B1(config-router)#offset-list 12 out 4
B1(config-router)#end
B1#
! Back to router WAN1
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
www.CareerCert.info
78 CCNP ROUTE 642-902 Official Certification Guide
P 10.11.1.0/24, 1 successors, FD is 2172419
via 10.1.1.2 (2172423/28167), Serial0/0/0.1
! lines omitted for brevity
Note that the metrics, both FD and RD, are now four larger than in Example 3-4.