Вы находитесь на странице: 1из 127

Enhanced Interior Gateway Routing Protocol

H
i
e
r
a
r
c
h
i
c
a
l

N
a
v
i
g
a
t
i
o
n


Downloads
• Enhanced Interior Gateway Routing
Protocol

• • •• •
Feedback: Help us help
you
P Document ID: 16406
l
e
a
s Interactive: This document offers
e customized analysis of your Cisco device.

r
a
t Contents
e
Introduction
t EIGRP Theory of Operation
h Major Revisions of the Protocol
i Basic Theory
s Neighbor Discovery and Maintenance
Building the Topology Table
d EIGRP Metrics
o Feasible Distance, Reported Distance, and
c Feasible Successor
u Deciding if a Path is Loop-Free
m Split Horizon and Poison Reverse
e Startup Mode
n Topology Table Change
t Queries
. Stuck In Active Routes
Troubleshooting SIA Routes
Redistribution
Redistribution Between Two EIGRP
Autonomous Systems
Redistribution Between EIGRP and IGRP
in Two Different Autonomous Systems
Redistribution Between EIGRP and IGRP
in the Same Autonomous System
Redistribution To and From Other Protocols

Redistribution of Static Routes to Interfaces


Summarization
Auto-Summarization
Manual Summarization
Auto-Summarization of External Routes
Query Processing and Range
How Summarization Points Affect the
Query Range
How Autonomous System Boundaries
Affect the Query Range
How Distribution Lists Affect the Query
Range
Pacing Packets
Default Routing
Load Balancing
Using the Metrics
Using Administrative Tags in
Redistribution
Understanding EIGRP Command
Output
show ip eigrp topology
show ip eigrp topology <network>
show ip eigrp topology [active | pending |
zero-successors]
show ip eigrp topology all-links
Cisco Support Community - Featured
Conversations
Related Information

Introduction
Enhanced Interior Gateway Routing Protocol
(EIGRP) is an interior gateway protocol suited for
many different topologies and media. In a well
designed network, EIGRP scales well and provides
extremely quick convergence times with minimal
network traffic.
EIGRP Theory of Operation
Some of the many advantages of EIGRP are:

• very low usage of network resources during


normal operation; only hello packets are
transmitted on a stable network

• when a change occurs, only routing table


changes are propagated, not the entire
routing table; this reduces the load the
routing protocol itself places on the network

• rapid convergence times for changes in the


network topology (in some situations
convergence can be almost instantaneous)
EIGRP is an enhanced distance vector protocol,
relying on the Diffused Update Algorithm (DUAL)
to calculate the shortest path to a destination within
a network.

Major Revisions of the Protocol


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 explanations in this paper may not
apply to that earlier version. We highly recommend
using the later version of EIGRP, as it includes
many performance and stability enhancements.

Basic Theory
A typical distance vector protocol saves the
following information when computing 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 are running Routing
Information Protocol (RIP). Router Two chooses
the path to Network A by examining the hop count
through each available path.
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). Not including any hold-
down time, it will take between 90 and 120 seconds
for Router Two to switch the path from Router One
to Router Three.
EIGRP, instead of counting on full periodic updates
to re-converge, builds a topology table from each of
its neighbor's advertisements (rather than
discarding the data), and converges by either
looking for a likely loop-free route in the topology
table, or, if it knows of no other route, by querying
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, finding a
feasible successor, begins using 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 of determining 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 for querying neighbors to find


paths to lost destinations
We will cover each of these requirements in turn.

Neighbor Discovery and Maintenance


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.
The basic problem with sending only routing
updates is that you may not know when a path
through a neighboring router is no longer available.
You can not time out routes, expecting to receive a
new routing table from your neighbors. EIGRP
relies on neighbor relationships to reliably
propagate routing table changes throughout the
network; two routers become neighbors when they
see each other's 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 subinterfaces,
and ATM point-to-point
subinterface

• 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 will consider a neighbor alive without
receiving 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 that 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.

E
x
c
e
l
l
e
n
t

G
o
o
d

A
v
e
r
a
g
e

F
a
i
r

P
o
o
r

T
h
i
s

d
o
c
u
m
e
n
t

s
o
l
v
e
d

m
y

p
r
o
b
l
e
m
.

Y
e
s
N
o

J
u
s
t

B
r
o
w
s
i
n
g

S
u
g
g
e
s
t
i
o
n
s

t
o

i
m
p
r
o
v
e
t
h
i
s

d
o
c
u
m
e
n
t
.

(
5
1
2

c
h
a
r
a
c
t
e
r

l
i
m
i
t
)

I
f

y
o
u
h
a
v
e

p
r
o
v
i
d
e
d

s
u
g
g
e
s
t
i
o
n
,

p
l
e
a
s
e

e
n
t
e
r

y
o
u
r
f
u
l
l

n
a
m
e

a
n
d

e
-
m
a
i
l

a
d
d
r
e
s
s
.

T
h
i
s

i
n
f
o
r
m
a
t
i
o
n

i
s

o
p
t
i
o
n
a
l

a
n
d

a
l
l
o
w
s

u
s

t
o

c
o
n
t
a
c
t

y
o
u

i
f
n
e
c
e
s
s
a
r
y
.

N
a
m
e
:
E
-
m
a
i
l
:
Note:

• EIGRP does not build peer relationships over secondary addresses. All EIGRP
traffic is sourced from the primary address of the interface.

• When configuring EIGRP over a multi-access Frame Relay network (point-to-


multipoint, and so on), configure the broadcast keyword in the frame-relay map
statements. Without the broadcast keyword the adjacencies would not establish
between two EIGRP routers. Refer to Configuring and Troubleshooting Frame
Relay for more information.

• There are no limitations on the number of neighbors that EIGRP can support. The
actual number of supported neighbors depends on the capability of the device,
such as:

• memory capacity

• processing power

• amount of exchanged information, such as the number of routes sent

• topology complexity

• network stability

Building the Topology Table


Now that these routers are talking to each other, what are they talking 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 running 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, including:

• 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)


Feasible and reported distance are discussed later in this section.
If you have the output of a show ip eigrp topology command from your Cisco device,
you can use Output Interpreter ( registered customers only) to display potential issues and
fixes. To use Output Interpreter, you must have JavaScript enabled.

EIGRP Metrics
EIGRP uses the minimum bandwidth on the path to a destination network and the total
delay to compute routing metrics. Although you can configure other metrics, we do not
recommend it, as 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 below, Router One is computing the best path to Network A.
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.
Let us compute the metrics. EIGRP calculates the total metric by scaling the bandwidth
and delay metrics. EIGRP uses the following 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 the following formula to scale
EIGRP uses the following 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. Throughout this paper, we use
delay as it is configured and shown 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)]
Note: These K values should be used after careful planning. Mismatched K values
prevent a neighbor relationship from being built, 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].
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 follows:
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:
In this example, the total cost through Router Four is:
minimum 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
So to reach Network A, Router One chooses the route through Router Three.
Note the bandwidth and delay values we 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, Reported Distance, and Feasible Successor


Feasible distance is the best metric along a path to a destination network, including the
metric to the neighbor advertising 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:
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 that in each case EIGRP calculates the reported distance from the router advertising
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, using 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.
Let us look at a more complex scenario, shown in 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 Four with a metric of 20307200. Router
One chooses the lower of these two metrics as its route to Network A, and this metric
becomes the feasible distance. Next, let us 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 (using show ip eigrp
topology), you would only see one entry for Network A - through Router Four. (In reality
there are two entries in the topology table at Router One, but only one will be a feasible
successor, so the other will not be displayed in show ip eigrp topology; you can see the
routes that are not feasible successors using show ip eigrp topology all-links).
Let us suppose that the link between Router One and Router Four 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 Four, it accepts this route through Router Two to Network A.

Deciding if a Path is Loop-Free


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).
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 for determining feasible successors, it will
never use these paths as alternates. Let us 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 remaining 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.

Split Horizon and Poison Reverse


In the previous example, we assumed that split horizon was not in effect to 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 dealing with the details of how EIGRP uses split horizon,
let us review what 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 will 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.
Poison reverse is another way of avoiding routing loops. Its rule states:

• Once you learn of a route through an interface, advertise it as unreachable back


through that same interface.
Let us say 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 (exchanging topology tables for the first time)

• advertising a topology table change

• sending a query
Let us examine each of these situations.

Startup Mode
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).

Topology Table Change


In Figure 5, Router One uses variance to balance the traffic destined to Network A
between the two serial links - the 56k link between Routers Two and Four, and the 128k
link between Routers Three and Four (see the Load Balancing section for a discussion of
variance).
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 should never advertise a
route out 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 a 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
Queries result in a split horizon only when a router receives a query or update from the
successor it is using for the destination in the query. Let us take a look at the network in
Figure 6.
Router Three receives a query concerning 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.

Stuck In Active Routes


In some circumstances, it takes a very long time for a query to be answered. So long, in
fact, that the router that issued the query gives up and clears its connection to the router
that is not answering, effectively restarting 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 is recording a large number of SIA routes from Router Two.
Stuck In Active Routes
In some circumstances, it takes a very long time for a query to be answered. So long, in
fact, that the router that issued the query gives up and clears its connection to the router
that is not answering, effectively restarting 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 is recording a large number of SIA routes from Router Two.
After some investigation, the problem is narrowed down to the delay over the satellite
link between Routers Two and Three. There are two possible solutions to this type of
problem. The first is to increase the amount of time the router waits after sending a query
before declaring the route SIA. This setting can be changed using 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. Query range in itself, however, is not a common reason for reported SIA routes.
More often, some router on the network can not answer a query for one of the following
reasons:

• the router is too busy to answer the query (generally due to high CPU utilization)

• the router is having 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 - enough packets are getting
through to keep the neighbor relationship up, but some queries or replies are
getting lost between the routers

• unidirectional links (a link on which traffic can only flow in one direction because
of a failure)

Troubleshooting SIA Routes


Troubleshooting SIA routes is generally a three-step process:
Find the routes that are consistently being reported as SIA.
Find the router that is consistently failing to answer queries for these routes.
Find the reason that router is not receiving or answering queries.
The first step should be fairly easy. If you are logging console messages, a quick perusal
of the log indicates which routes are most frequently marked 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). Note that these neighbors may not show up in the Remaining
replies section; they may 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 are not
responding to queries (or which interfaces seem to have a lot of unanswered queries).
Examine this neighbor to see if it is consistently waiting for replies from any of its
neighbors. Repeat this process until you find the router that is consistently not answering
queries. You can look for problems on the link to this neighbor, memory or CPU
utilization, or other problems with this neighbor.
If you run into a situation where it seems that the query range is the problem, it is always
best to reduce the query range rather than increasing the SIA timer.

Redistribution
This section examines different scenarios involving redistribution. Please note that the
examples below 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, please see "Avoiding Problems Due to
Redistribution" in Redistributing Routing Protocols.

Redistribution Between Two EIGRP Autonomous Systems


In Figure 8, the routers are configured as follows:
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 is advertising the network 10.1.2.0/24 to Router Two through autonomous
system 1000; Router Two is redistributing this route into autonomous system 2000 and
advertising it to Router One.
Note: The routes from EIGRP 1000 are tagged 1000 before redistributing them 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.
On Router One, we see:
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:
20.1.1.1 (Serial0), from 20.1.1.1, 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 10.1.2.1
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 redistributing between two EIGRP autonomous
systems.

Redistribution Between EIGRP and IGRP in Two Different


Autonomous Systems
In Figure 9, we have changed the configurations as follows:
Router One
router eigrp 2000
network 172.16.1.0
Router Two
router eigrp 2000
redistribute igrp 1000 route-map to-eigrp2000
network 172.16.1.0
!
router igrp 1000
redistribute eigrp 2000 route-map to-igrp1000
network 10.0.0.0
!

route-map to-igrp1000 deny 10


match tag 1000
!
route-map to-igrp1000 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 igrp 1000
network 10.0.0.0
The configuration for Router One is shown below:
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:
20.1.1.1 (Serial0), from 20.1.1.1, 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 1
External data:
Originating router is 10.1.1.1
AS number of route is 1000
External protocol is IGRP, external metric is 180671
Administrator tag is 1000 (0x000003E8)
IGRP metrics are preserved when routes are redistributed into EIGRP with a different
autonomous system, but they are scaled by multiplying the IGRP metric by the constant
256. There is one caveat to redistribution between IGRP and EIGRP that should be noted.
If the network is directly connected to the router doing the redistribution, it advertises the
route with a metric of 1.
For example, the network 10.1.1.0/24 is directly connected to Router Two, and IGRP is
routing for this network (there is a network statement under router IGRP that covers this
interface). EIGRP is not routing for this network, but is learning about this directly-
connected interface through redistribution from IGRP. On Router One, the topology table
entry for 10.1.1.0/24 shows:
one# show ip eigrp topology 10.1.1.0 255.255.255.0
IP-EIGRP topology entry for 10.1.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is
2169856
Routing Descriptor Blocks:
20.1.1.1 (Serial0), from 20.1.1.1, Send flag is 0x0
Composite metric is (2169856/1), Route is External

Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20000 microseconds
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20000 microseconds
Reliability is 0/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
External data:
Originating router is 10.1.1.1
AS number of route is 1000
External protocol is IGRP, external metric is 0
Administrator tag is 1000 (0x000003E8)
Note that the reported distance from Router Two, which is bolded, is 1."

Redistribution Between EIGRP and IGRP in the Same Autonomous


System
The following changes are made to the router configurations in Figure 10:
Router One
router eigrp 2000
network 172.16.1.0
Router Two
router eigrp 2000
network 172.16.1.0
!
router igrp 2000
network 10.0.0.0
Router Three
router igrp 2000
network 10.0.0.0
And Router One is configured as follows:
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:
20.1.1.1 (Serial0), from 20.1.1.1, 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 1
External data:
Originating router is 10.1.1.1
AS number of route is 2000
External protocol is IGRP, external metric is 180671
Administrator tag is 0 (0x00000000)
This configuration looks amazingly like the earlier output when we were redistributing
between two different autonomous systems running IGRP and EIGRP. The directly
attached 10.1.1.0/24 network is handled the same way in both scenarios:
one# show ip eigrp topology 10.1.1.0 255.255.255.0
IP-EIGRP topology entry for 10.1.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is
2169856
Routing Descriptor Blocks:
20.1.1.1 (Serial0), from 20.1.1.1, Send flag is 0x0
Composite metric is (2169856/1), Route is External
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 20000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
External data:
Originating router is 10.1.1.1
AS number of route is 2000
External protocol is IGRP, external metric is 0
Administrator tag is 0 (0x00000000)
So this network, which is directly connected to Router One, is redistributed from IGRP to
EIGRP with a metric of 1 - the same metric we see when redistributing between two
different autonomous systems.
There are two caveats with EIGRP/IGRP redistribution within the same autonomous
system:

• Internal EIGRP routes are always preferred over external EIGRP or IGRP routes.

• External EIGRP route metrics are compared to scaled IGRP metrics (the
administrative distance is ignored).
Let us examine these caveats in Figure 11:
Router One advertises 10.1.4.0/24 in IGRP autonomous system 100; Router Four
advertises 10.1.4.0/24 as an external in EIGRP autonomous system 100; Router Two runs
both EIGRP and IGRP in autonomous system 100.
If we ignore the EIGRP route advertised by Router Four (by shutting down the link
between Routers Two and Four, for instance), Router Two shows:
two# 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.1.2 on Serial1, 00:00:42 ago
Routing Descriptor Blocks:
* 10.1.1.2, from 10.1.1.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
Note the administrative distance is 100. When we add the EIGRP route, Router Two
shows:
two# show ip route 10.1.4.0
Routing entry for 10.1.4.0/24
Known via "eigrp 100", distance 170, metric 3072256, type
external
Redistributing via igrp 100, eigrp 100
Last update from 10.1.2.2 on Serial0, 00:53:59 ago
Routing Descriptor Blocks:
* 10.1.2.2, from 10.1.2.2, 00:53:59 ago, via Serial0
Route metric is 3072256, 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 1
Note the metrics for these two routes are the same after being scaled from IGRP to
EIGRP (see the Metrics section):

• 12001 x 256 = 3072256


where 12001, an IGRP metric, is through Router One; and 3072256, an EIGRP metric, is
through Router Four.
Router Two prefers the EIGRP external route with the same metric (after scaling) and a
higher administrative distance. This is true whenever automatic redistribution occurs
between EIGRP and IGRP within the same autonomous system. The router always
prefers the path with the lowest cost metric and ignores the administrative distance.
Redistribution To and From Other Protocols
Redistribution between EIGRP and other protocols - RIP and OSPF, for example - works
in the same way as all redistribution. It is always best to use the default metric when
redistributing between protocols. You should be aware of the following two issues when
redistributing 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.

Redistribution of Static Routes to Interfaces


When you install a static route to an interface, and configure a network statement using
router eigrp, which includes the static route, EIGRP redistributes this route as if it were
a directly connected interface. Let us look at the network in Figure 12.
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:

Redistribution of Static Routes to Interfaces


When you install a static route to an interface, and configure a network statement using
router eigrp, which includes the static route, EIGRP redistributes this route as if it were
a directly connected interface. Let us look at the network in Figure 12.
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 is not redistributing static routes,
because EIGRP considers this a directly attached network. On Router Two, this looks as
follows:
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
Note the route to 172.16.1.0/24 appears as an internal EIGRP route on Router Two.

Summarization
There are two forms of summarization in EIGRP: auto-summaries and manual
summaries.

Auto-Summarization
EIGRP performs an auto-summarization each time it crosses a border between two
different major networks. For example, in Figure 13, 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.
On Router One, this looks like the following:
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.1 (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. Note that 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 doing 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 the following:
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 20.1.1.1 (46354176/45842176), Serial0
P 10.1.2.0/24, 1 successors, FD is 11049472
via 20.1.1.1 (11049472/10537472), Serial0
P 10.1.1.0/24, 1 successors, FD is 11023872
via 20.1.1.1 (11023872/10511872), Serial0
P 172.16.1.0/24, 1 successors, FD is 2169856
via Connected, Serial0
There are some caveats when dealing with the summarization of external routes that are
covered later in the Auto-Summarization of External Routes section.

Manual Summarization
EIGRP allows you to summarize internal and external routes on virtually any bit
boundary using manual summarization. For example, in Figure 14, Router Two is
summarizing the 192.1.1.0/24, 192.1.2.0/24, and 192.1.3.0/24 into the CIDR block
192.1.0.0/22.
The configuration on Router Two is shown below:
two# show run
....
!
interface Serial0
ip address 10.1.50.1 255.255.255.0
ip summary-address eigrp 2000 192.1.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.1.1.0/24, 1 successors, FD is 10511872
via Connected, Serial1
P 192.1.0.0/22, 1 successors, FD is 10511872
via Summary (10511872/0), Null0
P 192.1.3.0/24, 1 successors, FD is 10639872
via 192.1.1.1 (10639872/128256), Serial1
P 192.1.2.0/24, 1 successors, FD is 10537472
via 192.1.1.1 (10537472/281600), Serial1
Note the ip summary-address command under interface Serial0, and the summary route
via Null0. On Router One, we see this 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.1.0.0/22, 1 successors, FD is 11023872
via 10.1.50.1 (11023872/10511872), Serial0

Auto-Summarization of External Routes


EIGRP will not auto-summarize external routes unless there is a component of the same
major network that is an internal route. To illustrate, let us look at Figure 15.
Router Three is injecting external routes to 192.1.2.0/26 and 192.1.2.64/26 into EIGRP
using the redistribute connected command, as shown in the configurations below.
Router Three
interface Ethernet0
ip address 192.1.2.1 255.255.255.192
!
interface Ethernet1
ip address 192.1.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.1.2.0/26 is subnetted, 1 subnets
D EX 192.1.2.0 [170/11049472 begin_of_the_skype_highlighting
170/11049472 end_of_the_skype_highlighting] via 10.1.50.2,
00:00:53, Serial0
D EX 192.1.2.64 [170/11049472 begin_of_the_skype_highlighting
170/11049472 end_of_the_skype_highlighting] via 10.1.50.2,
00:00:53, Serial0
Although auto-summary normally causes Router Three to summarize the 192.1.2.0/26
and 192.1.2.64/26 routes into one major net destination (192.1.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.1.2.128/26, and add network statements for this network on
Routers Two and Three, the 192.1.2.0/24 auto-summary is then generated on Router
Two.
Router Three
interface Ethernet0
ip address 192.1.2.1 255.255.255.192
!
interface Ethernet1
ip address 192.1.2.65 255.255.255.192
!
interface Serial0
ip address 192.1.2.130 255.255.255.192
!
router eigrp 2000
network 192.1.2.0
Now Router Two generates the summary for 192.1.2.0/24:
two# show ip route
....
D 192.1.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.1.2.0/24 [90/11023872] via 10.1.50.2, 00:00:36, Serial0

Query Processing and Range


When a router processes a query from a neighbor, the following rules apply:
Query from

Query Processing and Range


When a router processes a query from a neighbor, the following rules apply:
Query Route
Action
from state
neighbo
r (not
the reply with current successor
passive
current information
success
or)
attempt to find new successor; if
successful, reply with new
success information; if not successful, mark
passive
or destination unreachable and query all
neighbors except the previous
successor
no path
through
any
this
neighbo reply with best path currently known
neighbor
r
before
query
not
any
known reply that the destination is
neighbo
before unreachable
r
query
neighbo
r (not
if there is no current successor to this
the
active destinations (normally this would be
current
true), reply with an unreachable
success
or)
if there is a good successor, reply
with the current path information
attempt to find new successor; if
successful, reply with new
success information; if not successful, mark
active
or destination unreachable and query all
neighbors except the previous
successor
The actions in the table above impact the range of the query in the network by
determining 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
handled, let us look at the network in Figure 16, which is running under normal
conditions.
We can expect the following to happen regarding 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. What activity can we expect to see on this network?
Figures 16a through 16h illustrate the process.
Router Five marks 192.168.3.0/24 as unreachable, and queries Router Four:
Router Four, upon receiving a query from its successor, 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:
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:
For simplicity, let us 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 will all have the same final result.
Router One replies to both queries with unreachables; Router One is now passive for
192.168.3.0/24:
Routers Two and Three reply to the query from Router Four; Routers Two and Three are
now passive for 192.168.3.0/24:
Router Five, upon receiving the reply from Router Four, 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 remaining routers.
It is important to understand that although there may be other query paths or processing
orders, all routers in the network process a query for network 192.168.3.0/24 when that
link goes down. Some routers may end up processing 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 end up processing three or four queries. This is a good example of an unbounded
query in an EIGRP network.

How Summarization Points Affect the Query Range


Now let us 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 are autosummarizing 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).
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:
Router Two, on receiving the query from Router One, marks the route as unreachable
(because the query is from its successor) and then queries Routers Four and Three:
Router Two, on receiving the query from Router
One, marks the route as unreachable (because the
query is from its successor) and then queries
Routers Four and Three:
Router Three, when it receives the query from
Router One, marks the destination as unreachable
and queries Routers Two and Four:
Router Four, when it receives the queries from
Routers Two and Three, replies that 10.1.1.0/24 is
unreachable (note that Router Four has no
knowledge of the subnet in question, since it only
has the 10.0.0.0/8 route):
Routers Two and Three reply to each other that
10.1.1.0/24 is unreachable:
Since Routers Two and Three now have no
outstanding queries, they both reply to Router
One that 10.1.1.0/24 is unreachable:
The query, in this case, is bounded by the
autosummarization 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.

How Autonomous System Boundaries


Affect the Query Range
If a router is redistributing routes between two
EIGRP autonomous systems, it replies to the
query within the normal processing rules 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:
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:
Router One replies to Router Two, and the route
goes passive:
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 technique may help to
prevent stuck in active (SIA) problems in a
network by limiting the number of routers a query
must pass through before being answered, but it
does not solve the overall problem that each
router must process the query. In fact, this method
of bounding a query may worsen the problem by
preventing 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).

How Distribution Lists Affect the Query


Range
Rather than block the propagation of a query,
distribution lists in EIGRP mark any query reply
as unreachable. Let us use Figure 19 as an
example.
In the figure above:

• 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.
Router Three marks the route as unreachable, then
queries Router Two:
Router Two examines its topology table and finds
that it has a valid connection to Network A. Note
the query was not affected by the distribution list
in Router Three:
Router Two replies that Network A is reachable;
Router Three now has a valid route:
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:

Pacing Packets
Some routing protocols consume all of the
available bandwidth on a low bandwidth link
while they are converging (adapting to a change
in the network). EIGRP avoids this congestion by
pacing the speed at which packets are transmitted
on a network, thereby using 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
the following command:
router(config-if)# ip bandwidth-
percent eigrp 2 ?
<1-999999> Maximum bandwidth
percentage that EIGRP may use
Essentially, each time EIGRP queues a packet to
be transmitted on an interface, it uses the
following formula to determine how long to wait
before sending the packet:

• (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 be transmitted on this link
before EIGRP sends its packet. The pacing timer
determines when the packet is sent, and is
typically expressed in milliseconds. The pacing
time for the packet in the above example is
0.1463 seconds. There is a field in show ip eigrp
interface that displays the pacing timer, as shown
below:
router# 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.

Default Routing
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 is effective for advertising 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. Refer to Configuring a Gateway
of Last Resort for further information.
Summarizing to a default route is effective only
when you want to provide remote sites with a
default route. Since summaries are configured per
interface, you do not need to worry about using
distribute-lists or other mechanisms to prevent the
default route from being propagated 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 using this
method is to configure a static route to 0.0.0.0/0.
(Beginning in Cisco IOS Software 12.0(4)T, you
can also configure an administrative distance on
the end of the summary-address 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

Load Balancing
EIGRP puts up to four routes of equal cost in the
routing table, which the router then load-balances.
The type of load balancing (per packet or per
destination) depends on the type of switching
being done in the router. EIGRP, however, can
also load-balance over unequal cost links.
Note: Using max-paths, you can configure
EIGRP to use up to six routes of equal cost.
Let us say 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. Using 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 will be 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 then restarts by sending the next
three packets over path 1, and so on.
Note: Even with variance configured, EIGRP will
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.

Using the Metrics


When you initially configure EIGRP, remember
these two basic rules if you are attempting to
influence EIGRP metrics:

• The bandwidth should 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 should 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.

Using Administrative Tags in


Redistribution
External administrative tags are useful for
breaking redistribution routing loops between
EIGRP and other protocols. By tagging 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 of configuring these tags follows,
but this example does not show the entire
configuration used for breaking redistribution
loops.
Router Three, which is redistributing 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 is redistributing 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 1.1.1.1 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
Note the tag 1 on 172.19.1.0/24.
Router One, which is receiving 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
Note that 172.19.1.0/24 is missing.

Understanding EIGRP
Command Output
show ip eigrp topology
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 follows the
table.
show ip eigrp topology

Configuration Explanations
A means active. This could also show a P,
meaning 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 using route
maps with the set tag and match tag commands.
Q means a query is pending. This field can also
be: U, for update pending; or R, for reply
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, meaning that multiple neighbors
have sent queries on this destination, but not the
successor; or Successor origin, meaning the
successor originated the query.
via 10.1.2.2 shows that we learned of this route
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 being 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 we have queried this neighbor and
are waiting for a reply.
Q is the send flag for this route, meaning there is
a query pending. This field can also be: U,
meaning there is an update pending; or R,
meaning there is a reply pending.
Serial1 is the interface through which this
neighbor is reachable.
Via 10.1.1.2 shows the neighbor from which we
are waiting for a reply.
r shows that we have queried this neighbor about
the route and have not yet received a reply.
Serial0 is the interface through which this
neighbor is reachable.
Via 10.1.2.2 (512640000/128256), Serial1 shows
we are using this route (indicates which path the
next path/destination will take when there are
multiple routes of equal cost).

show ip eigrp topology <network>


This command displays all entries in the topology
table for this destination, not just feasible
successors. An explanation of each output field
follows the table.
show ip eigrp topology network

Configuration Explanations
State is Passive means the network is in passive
state, or, in other words, we are not looking for a
path to this network. Routes are almost always in
a passive state in stable networks.
Query origin flag is 1 If this route is active, this
field provides information on who originated the
query.

• 0: This route is active but no query has


been originated for it (we are searching for
a feasible successor locally).

• 1: This router originated the query for this


route (or the route is passive).

• 2: Multiple diffusing computations for this


query. This router has received more than
one query for this route from more than
one source.

• 3: The router that we learned the path to


this network from is querying for another
route.

• 4: Multiple query sources for this route,


including the router through which we
learned this route. Similar to 2, but it also
means there is a query origin string which
describes the queries outstanding for this
path.
2 Successor(s) means there are two feasible paths
to this network.
FD is 307200 shows the best current metric to this
network. If the route is active, this indicates the
metric of the path we were previously using to
route packets to this network.
Routing Descriptor Blocks Each of the
following 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 should be sent.

• 0x3: This route has changed, and a


multicast update should 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, including 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.

• Reliability is 0/255 shows a reliability


factor. This number is calculated
dynamically, but is not used by default in
metric calculations.

• Load is 1/255 indicates the amount of


load the link is carrying. This number is
calculated dynamically, and is not used by
default when EIGRP calculates the cost to
use this path.

• 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 will accept is
100 by default, although the maximum can
be configured to 220 with metric
maximum hops.
If the route is external, the following information
is included. An explanation of each output field
follows the table.
External Route

Configuration Explanations
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
using route maps with the set tag and match tag
commands.

show ip eigrp topology [active | pending


| zero-successors]
Same output format as show ip eigrp topology ,
but it also shows some portion of the topology
table.

show ip eigrp topology all-links


Same output format as show ip eigrp topology ,
but it also shows all links in the topology table,
rather than just feasible successors.

Cisco Support Community -


Featured Conversations
Cisco Support Community is a forum for you to
ask and answer questions, share suggestions, and
collaborate with your peers. Below are just some
of the most recent and relevant conversations
happening right now.
Want to see more? Join us by clicking here

• routed and routing protocolHYPERLINK


"https://supportforums.cisco.com/people/i
qbalkhan"iqbalkhan3 Replies4 years, 6
months ago
Hi can anyone easily describe with
example of basic difference routed and
routing protocol . Thanks Biplob
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/2
8291"Reply

• Re: routed and routing


protocolHYPERLINK
"https://supportforums.cisco.com/p
eople/pkhatri"pkhatri4 years, 6
months ago
Hi, A routed protocol is one that
has addressing that can be used to
transmit its packets from one
network segment to another via an
interconnected system of layer 3
routing devices. Examples of this
include IP, IPX, CLNS. These
protocols use addresses that
indicate where each host carrying
that address is located. On the
basis of that, packets can be
forwarded to the correct location.
A routing protocol, on the...
Reply

• Re: routed and routing


protocolHYPERLINK
"https://supportforums.cisc
o.com/people/balajitvk"bal
ajitvk4 years, 6 months ago
Hi, Routed protocols are
protocols that are routed
over an internetwork.
Examples of such protocols
are the Internet Protocol
(IP), DECnet, AppleTalk,
Novell NetWare, OSI,
Banyan VINES, and Xerox
Network System (XNS).
Routing protocols, on the
other hand, are protocols
that implement routing
algorithms. Put simply,
routing protocols are used
by intermediate systems to
build tables used in
determining path selection
of routed...
Reply

• Re: routed and routing


protocolHYPERLINK
"https://supportforums.cisco.com/p
eople/iqbalkhan"iqbalkhan4 years,
6 months ago
HI Thanks for clear the issue.
Biplob
Reply

• Customized gateway for


VLANHYPERLINK
"https://supportforums.cisco.com/people/
YvesGattegno"YvesGattegno3 Replies7
months, 2 weeks ago
Hello I am using a Catalyst 3750. Cisco
IOS Software, C3750 Software (C3750-
IPSERVICESK9-M), Version
12.2(25)SED1, RELEASE SOFTWARE
(fc1) I have several VLans on that catalyst
and I'd like one of said VLans to used a
specific default gateway, which will not be
the "regular/standard" default gateway.
IOW, whenever a packet is sent by some
host on the VLAN in question, with an
"unknown" destination, I want it to be
routed to a specific IP address, which is
not the "defauklt gateway". I tried to play
with static routes, but I did not find how I
could set the incoming interface Thanks in
advance - Yves Gattegno
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/2
004770"Reply

• Re: Customized gateway for


VLANHYPERLINK
"https://supportforums.cisco.com/p
eople/jon.marshall"jon.marshall7
months, 3 weeks ago
YvesGattegno wrote: Hello I am
using a Catalyst 3750. Cisco IOS
Software, C3750 Software
(C3750-IPSERVICESK9-M),
Version 12.2(25)SED1, RELEASE
SOFTWARE (fc1) I have several
VLans on that catalyst and I'd like
one of said VLans to used a
specific default gateway, which
will not be the "regular/standard"
default gateway. IOW, whenever a
packet is sent by some host on the
VLAN in question, with an
"unknown" destination, I...
Reply
• Re: Customized gateway for
VLANHYPERLINK
"https://supportforums.cisco.com/p
eople/tdistlists"tdistlists7 months,
3 weeks ago
Hey, Depending on how much
inter-vlan traffic you have, VRF-
lite can be of help. On the vlan
interface that you want a different
default gateway, you can put it in a
different VRF. This will consult a
different routing table than the
global routing table -- so you can
have a different gateway of last
resort. Then, for whatever
segments you want communication
between the two routing tables,
you can use a number of...
Reply

• Re: Customized gateway for


VLANHYPERLINK
"https://supportforums.cisco.com/p
eople/YvesGattegno"YvesGattegn
o7 months, 2 weeks ago
Thanks for the answers !
Reply

• Routing to multiple Default


GatewaysHYPERLINK
"https://supportforums.cisco.com/people/d
avidjknapp"davidjknapp11 Replies7
months, 2 weeks ago
This may be a simple process, but I can
not find a difinity answer. Hope someone
can help. I am designing a template that
allows for multiple sites to connect to an
MPLS network as well as support a
separate isolated network at each site. the
isolated network will need to route to
some of the subnets so I need to point the
gateway to the core (3750). The MPLS
connected network will also be pointed to
its respective vlan ip on the core switch
for the site. The issue I have is I need the
isolated network to utilize a local internet
connection while the MPLS side of the
house will be connected up to the primary
hub via the MPLS. In the example below
VLAN 100 and 120 will be routed to the
MPLS via the switches default gateway;
VLAN 200 and 220 need to be routed to
the local gateway (10.2.4.1). So if my
default route is as configured below, how
do I redirect LANS 200 and 220? interface
GigabitEthernet1/0/1 description Network
1 switchport access vlan 100 ! interface
GigabitEthernet1/0/2 description Network
2 switchport access vlan 120 ! interface
GigabitEthernet1/0/3 description Network
3 switchport access vlan 200 ! interface
GigabitEthernet1/0/4 description Network
4 switchport access vlan 220 ! interface
Vlan100 description LAN1 ip address
10.100.100.1 255.255.255.0 ! interface
Vlan120 description LAN2 ip address
10.4.123.254 255.255.255 ! interface
Vlan200 description LAN3 ip address
10.100.200.1 255.255.255.0 ! interface
Vlan220 description LAN4 ip address
10.2.4.254 255.255.255.0 ! Route 0.0.0.0
0.0.0.0 10.4.123.1
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/2
005112"Reply

• Re: Routing to multiple Default


GatewaysHYPERLINK
"https://supportforums.cisco.com/p
eople/jon.marshall"jon.marshall7
months, 3 weeks ago
davidjknapp wrote: This may be a
simple process, but I can not find a
difinity answer. Hope someone can
help. I am designing a template
that allows for multiple sites to
connect to an MPLS network as
well as support a separate isolated
network at each site. the isolated
network will need to route to some
of the subnets so I need to point
the gateway to the core (3750).
The MPLS connected network will
also be...
Reply

• Re: Routing to multiple


Default
GatewaysHYPERLINK
"https://supportforums.cisc
o.com/people/davidjknapp"
davidjknapp7 months, 3
weeks ago
Thanks for the fast follow-
up. This is exactly what I
need. Do to the fact that
there will be a third vlan
(Call it VLAN300) that
will be able to
communicated to either
network, VRF will not
work. But great to know for
other circumstatnces. I will
investigate Policy Based
Routing and attempt to
impliment in a lab
enviorment.
Reply

• Re: Routing to
multiple Default
GatewaysHYPERLI
NK
"https://supportforu
ms.cisco.com/peopl
e/jon.marshall"jon.
marshall7 months, 3
weeks ago
davidjknapp wrote:
Thanks for the fast
follow-up. This is
exactly what I need.
Do to the fact that
there will be a third
vlan (Call it
VLAN300) that will
be able to
communicated to
either network,
VRF will not work.
But great to know
for other
circumstatnces. I
will investigate
Policy Based
Routing and attempt
to impliment in a
lab enviorment.
David No problem.
glad to have helped.
Just for...
Reply

• Re: Routing
to multiple
Default
GatewaysH
YPERLINK
"https://supp
ortforums.ci
sco.com/peo
ple/davidjkn
app"davidjk
napp7
months, 2
weeks ago
I have
Attempted
to setup a
lab using
two 3750's
and IPs from
10.1 .1.0/24
- 10.1.5.0/24
I have a
client using
10.1.1.5
(port 1) and
another at
10.1.2.5
(port 47). I
want to
route the
10.1.1.0 to
the default
gateway of
10.1.3.254
and the
network
10.1.2.0 to
the gateway
10.1.4.254.
Both of
those ip's are
the second
switch witch
also has the
netowork
10.1.5.0.
When I
traceroute
from either
client I see
the default
gateway...
Reply

• Re:
Rout
ing
to
multi
ple
Defa
ult
Gate
ways
HYP
ERL
INK
"http
s://su
pport
foru
ms.ci
sco.c
om/p
eople
/jon.
mars
hall"j
on.m
arsha
ll7
mont
hs, 2
week
s ago
davi
djkn
app
wrot
e: ! !
interf
ace
Vlan
100
descr
iptio
n
LAN
1 ip
addr
ess
10.1.
1.1
255.
255.
255.
0!
interf
ace
Vlan
200
descr
iptio
n
LAN
3 ip
addr
ess
10.1.
2.1
255.
255.
255.
0!
interf
ace
Vlan
300
descr
iptio
n
LAN
3 ip
addr
ess
10.1.
3.1
255.
255.
255.
0!
interf
ace
Vlan
400
descr
iptio
n
LAN
4 ip
addr
ess
10.1.
4.1
255.
255.
255.
0!!
ip
route
0.0.0
.0
0.0.0
.0
10.1.
3.25
4!!
acces
s-list
10
perm
it
10.1.
1.5
acces
s-list
20
perm
it
10.1.
2.5 !
route
-map
LAB
perm
it 10
matc
h
ip...
Repl
y

•R

I
di
d
se
e
th
at
th
e
's
et
ip
de
fa
ul
ne
xt
-
h
o
p"
ru
ns
as
a
p
os
t
ro
ut
in
g
ta
bl
e
so
lu
ti
o
n
-
w
hi
ch
is
h
o
w
I
w
an
t
it.
If
th
er
e
is
an
in
te
rn
al
ro
ut
e
-I
w
an
t
it
to
us
e
it,
h
o
w
ev
er
it
th
er
e
is
n
ot
in
te
rn
al
ro
ut
e
(I
nt
er
ne
t
b
o
u
n
d
tr
af
fi
c)
th
en
g
o
to
th
is
ro
ut
e.
F
or
th
e
la
b
I
di
d
n
ot
us
in
g
ro
ut
in
g
pr
ot
oc
al
s
to
pr
ev
en
t
th
e
ro
ut
es
fr
o
m
ge
tti
n
g
tr
an
s
m
itt
ed
...
I
ju
st
st
uc
k
to
st
at
ic
ro
ut
es
.I
di
d
en
te
re
d
th
e
ex
ac
t
co
m
m
an
ds
,
an
d
th
ey
di
d
n
ot
...
R
ep
ly


davidjkna
pp wrote:
http://ww
w.cisco.c
om/en/U
S/tech/tk
364/techn
ologies_c
onfigurati
on_exam
ple09186
a0080213
5d3.shtml
David
Did you
enable
the
routing
template
ie. "sdm
prefer
routing"
Jon
Reply

• Re:
Rout
ing
to
multi
ple
Defa
ult
Gate
ways
HYP
ERL
INK
"http
s://su
pport
foru
ms.ci
sco.c
om/p
eople
/davi
djkn
app"
davi
djkn
app7
mont
hs, 2
week
s ago
I
have
got
the
lab
work
ing.
What
was
need
ed
was
to
enter
"SD
M
prefe
r
routi
ng"
then
reloa
d.
After
whic
hI
had
to
remo
ve
the "
set ip
defa
ult
next-
hop
10.1.
4.25
4"
and
exch
ange
it for
"set
ip
next-
hop
10.1.
4.25
4"
( the
3750
does
not
supp
ort
defa
ult
next-
hop )
.
http:/
/ww
w.cis
co.co
m/en
/US/
docs/
switc
hes/l
an/ca
talyst
3750
e_35
60e/s
oftw
are/r
eleas
e/12.
2_37
_se/c
onfig
urati
on/g
uide/
swun
cli.ht
ml I
do
have
a
quest
ion
relat
ed
to...
Repl
y

•R

D
av
id
G
la
d
y
o
u
g
ot
it
w
or
ki
n
g.
A
s
fo
r
di
re
ct
in
g
tr
af
fi
c
th
e
ke
y
th
in
g
to
be
a
w
ar
e
of
is
th
at
o
nl
y
tr
af
fi
c
m
at
ch
ed
in
th
e
ac
l
w
ill
be
se
nt
to
th
e
ne
xt
-
h
o
p
sp
ec
ifi
ed
in
y
o
ur
ro
ut
e-
m
ap
.
A
n
d
so
it'
s
al
la
q
ue
sti
o
n
of
co
nf
ig
ur
in
g
y
o
ur
ac
l
pr
o
pe
rl
y
so
le
ts
y
o
u
w
an
te
d
a
h
os
t
(1
9
2.
1
6
8.
5.
1)
to
g
o
ac
ro
ss
th
e
M
P
L
S
ne
t
w
or
k
to
th
e
an
ti
vi
ru
s
se
rv
er
b
ut
o
ut
th
e
ot
he
r
li
n
k
fo
r
ht
tp
tr
af
fi
c
ac
ce
ss
-
lis
t
1
0
1
de
n
y
ip
h
os
t
1
9
2.
1
6
8.
5.
1.
..
R
ep
ly


Once
again,
Jon
straitens
me out!!
- Cisco
does not
allow
"Deny"
ACL's on
the 3750
Platform,
however,
I can do
it the
other way
and tell
the ACL
to ignore
anything
on local
lan by
using :
access-
list 120
permit ip
10.1.2.0
0.0.0.255
10.0.0.0
0.255.25
5.255 -
concideri
ng our
entire
network
sits in the
10.0.0.0
range and
no
internet
traffic
should be
there.
Thanks
Again!!
Reply
• More Replies

• Best interior routing..HYPERLINK


"https://supportforums.cisco.com/people/b
mumby"bmumby1 Reply8 years, 9
months ago
I have 2 7206's, each with a DS3 of
different sizes, and a Catalyst 4006 with
the L3 card. Should I bother with the Cat
using it as a default gateway for the
workstations? Or should i have everyone
point at the cat and then have the cat pick
the best router? Any ideas? Anyone got
any useful URLs about this sort of
network design?
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/1
2871"Reply

• Re: Best interior


routing..HYPERLINK
"https://supportforums.cisco.com/p
eople/bsivasub"bsivasub8 years, 9
months ago
I think you can use L3 card. One of
your 7206 can provide backup with
HSRP configured on them. i think
it may be better idea since 4232
has two GIG connections to the
backplane. 7206 probably has 100
MB bottleneck for the traffic to
and fro. You would get better
performance with L3 doing the
routing.
Reply

• ASK THE EXPERT INTERIOR


DYNAMIC ROUTING...HYPERLINK
"https://supportforums.cisco.com/people/c
iscomoderator"ciscomoderator44 Replies2
years, 2 months ago
Welcome to the Cisco Networking
Professionals Ask the Expert conversation.
This is an opportunity to get an update on
the interior dynamic routing protocols,
RIPv2, OSPF and EIGRP with Cisco
expert Edison Ortiz. Edison is a Network
Consulting Engineer with the Advanced
Services team. His team concentrates on
supporting the New York Financial
companies in terms of network design,
deployment and troubleshooting.
Remember to use the rating system to let
Edison know if you have received an
adequate response. Edison might not be
able to answer each question due to the
volume expected during this event. Our
moderators will post many of the
unanswered questions in other discussion
forums shortly after the event. This event
lasts through August 8, 2008. Visit this
forum often to view responses to your
questions and the questions of other
community members.
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/1
36303"Reply

• Re: ASK THE EXPERT


INTERIOR
DYNAMIC...https://supportforums
.cisco.com/people/joe
%40affirmedsystems.com2 years,
2 months ago
Hello Edison and thank you for
taking the time to host this "ask the
experts" forum. I have two
questions related to OSPF. 1. How
do large enterprises often handle
the placement of Area 0
(backbone)? I have heard differing
opinions from engineers who have
worked on larger OSPF networks
than I have had a chance to. Such
suggestions include making the
WAN area 0, as it could possibly
be the only central area capable of
being...
Reply

• Re: ASK THE EXPERT


INTERIOR
DYNAMIC...HYPERLINK
"https://supportforums.cisc
o.com/people/ediortiz"edio
rtiz2 years, 2 months ago
Hi Joe, Good to see you
here other than
groupstudy :) 1. Area 0
placement is often driven
by customer requirement. If
the WAN service is reliable
and fast, extending Area 0
to the remote WAN router
interface is often
recommended. This router
can act as ABR with its
LAN interface running a
non-zero area so
summarization and filtering
can be perform there. If the
WAN service isn't reliable,
Area 0 is often limited to...
Reply

• Re: ASK THE EXPERT


INTERIOR
DYNAMIC...HYPERLINK
"https://supportforums.cisco.com/p
eople/faisal_ghaus"faisal_ghaus2
years, 2 months ago
Hi Recently one of our service
provider has started to provide us
high speed E1 links on MPLS
network .Our network is running
OSPF as a routing protocol with
area 0 ip addressing 10.175.x.x
what the SP is asking us to create a
new AREA 0 for super AREa 0 for
MPLS can you please advise some
easy and best practise to make this
possible
Reply

• Re: ASK THE EXPERT


INTERIOR
DYNAMIC...HYPERLINK
"https://supportforums.cisc
o.com/people/ediortiz"edio
rtiz2 years, 2 months ago
Hi Faisal, I hope you are
doing well. Your query is
more inclined towards
MPLS Best Practice and
I'm afraid I'm not such an
expert on MPLS at the
moment :) However, I've
been reading a little bit on
MPLS and MPLS VPN
superbackbone can be
accomplished with OSPF
Sham Link . I hope this
URL
http://www.cisco.com/en/U
S/docs/ios/12_2t/12_2t8/fe
ature/guide/ospfshmk.html
can offer some idea
regarding the ISP
requirement....
Reply

• Re: ASK THE EXPERT


INTERIOR
DYNAMIC...HYPERLINK
"https://supportforums.cisco.com/p
eople/rdanu"rdanu2 years, 2
months ago
I am in the process of deploying a
BGP core MPLS network with
OSPF LANS at 5 locations. Each
LAN location has Internet access,
also. I would like to deploy an
IPSEC tunnel to each location, via
the Internet lines, keeping the
IPSEC network OSPF 0 Area; my
dilema is to prefer the BGP
redistribution point for primary
traffic preference, not the IPsec
TUN pipes. Of course the TUN
pipes would be in place for
redundancy purposes only ...
Reply

• Re: ASK THE EXPERT


INTERIOR
DYNAMIC...HYPERLINK
"https://supportforums.cisc
o.com/people/ediortiz"edio
rtiz2 years, 2 months ago
I understand your dilemma.
The IPSec Tunnel traffic
will be preferred since they
are intra-area routes vs
external routes that are
learned via the MPLS
network. I hate being
repetitive :) but the OSPF
Sham Link addresses this
issue.
http://www.cisco.com/en/U
S/docs/ios/12_2t/12_2t8/fe
ature/guide/ospfshmk.html
I'm currently reading
MPLS Fundamentals...
Reply

• Re: ASK THE


EXPERT
INTERIOR
DYNAMIC...HYPE
RLINK
"https://supportforu
ms.cisco.com/peopl
e/rdanu"rdanu2
years, 2 months ago
Thank you for your
prompt response!
The links will solve
my requirement!
Richard
Reply

• Re: ASK
THE
EXPERT
INTERIOR
DYNAMIC.
..HYPERLI
NK
"https://supp
ortforums.ci
sco.com/peo
ple/ediortiz"
ediortiz2
years, 2
months ago
Richard, I'm
glad I was
able to help.
Feel free to
come back if
you have
any other
questions.
Regards, __
Edison.
Reply

• Re:
ASK
THE
EXP
ERT
INT
ERI
OR
DYN
AMI
C...H
YPE
RLI
NK
"http
s://su
pport
foru
ms.ci
sco.c
om/p
eople
/dha
nase
kara
n.r"d
hana
sekar
an.r2
years
,2
mont
hs
ago
Hi
Edis
on,
Rece
ntly
we
instal
led
AT
M to
fram
e-
relay
link
on
3845
route
r
with
12.4(
17).
The
EIG
RP
did
not
estab
lish.
We
were
aske
d to
chan
ge
the
MT
U
size
to
1500
and
EIG
RP
starte
d
work
ing.
Can
you
pleas
e
help
me
to
unde
rstan
d the
logic
,
why
we
need
to
chan
ge
MT
U
size
Repl
y

•R
H
i
D
ha
na
se
ka
ra
n,
It'
s
ve
ry
o
d
d
th
at
y
o
u
en
co
u
nt
er
ed
a
pr
o
bl
e
m
w
it
h
M
T
U
an
d
EI
G
R
P
as
th
e
ro
ut
in
g
pr
ot
oc
ol
.
EI
G
R
P,
u
nl
ik
e
O
S
P
F,
d
oe
s
n
ot
us
e
M
T
U
fo
r
ne
ig
h
b
or
ad
ja
ce
nc
y.
I
tri
ed
to
la
b
it
u
p
an
d
se
e
if
it
br
ea
ks
an
d
I
u
na
bl
e
to
d
u
pl
ic
at
e
y
o
ur
pr
o
bl
e
m
.I
co
nf
ig
ur
ed
2
ro
ut
er
s
in
Fr
a
m
e-
R
el
ay
an
d
ch
an
ge
d
th
e
IP
M
T
U
an
d
in
te
rf
ac
e
M
T
U
si
ze
o
n
R
1,
se
e
be
lo
w
:
in
te
rf
ac
e
S
er
ia
l1
/0
m
tu
1
4
0
0
ip
ad
dr
es
s
1
9
2.
1
6
8.
1
2.
1.
..
R
ep
ly

• More Replies

• 2 WAN links/1 default gateway-


ASA...HYPERLINK
"https://supportforums.cisco.com/people/
wpinberlin"wpinberlin2 Replies10
months, 4 days ago
Hi Community, hoping you can help here.
We currently have an ASA in place with a
single outside interface (public ip address)
used for our Site-to-Site VPNs, our
Dynamic VPN Clients, our publicly
reachable servers and, of course, our
outgoing traffic. This outside interface has
a default route to our gateway router
which connects up to the ISP. Due to
congestion issues (internet traffic slowing
our Site-to-Site VPN traffic) we ordered a
VDSL link from our ISP (as a PPPoE
interface with a dynamic address). We
would like to use this link for all our
internet traffic, while keeping our VPN
traffic on the slower speed, staticly
addressed link. Initially we configured the
new VDSL link on an ASA interface,
using the PPPoE 'setroute' option to install
a default route into the ASA with the next
hop provided by the ISP. We then created
static routes to our gateway router for the
remote endpoints of our Site-to-Site VPN
tunnels. We were very pleased with our
improved access to the remote sites as
well as our speedy new internet
connection....and then... We found our
dynamic VPN connections broken - of
course - as they were using the staticly
addressed interface for their tunnel
endpoint but the return traffic was going
out VDSL interface to the default
gateway. The same problem held true for
our externably available resources -
requests came down the staticly addressed
link and responses went out the VDSL
link. Traffic behaviour as expected if not
as desired So now we are seeking a
solution and have come up with the
following bright ideas: 1) keep the router
on the WAN side of the ASA and attach
the VDSL link there, using it as before as
the default gateway for outgoing traffic.
This would result in all inbound VPN
traffic reaching the ASA on its single,
outside interface which would keep the
publicly reachable static addresses.
However we would have to do some sort
of NAT or source routing for dynamic
VPN traffic. The more i think about this
option the less it looks like a solution. 2)
keep everything in the ASA (this is our
'preferred path') but somehow arrange for
source routing, or session establishment
parameters, to allow us to send traffic out
the interface it arrived on. So that if traffic
arrived on the VPN, or publicly addressed
interface, responses would be send back
out that same interface. a cursory
examination of the ASA material has not
yielded the information so while i
continue searching i thought i'd pose the
question to the community as i am certain
someone has seen this sort of set up
before. thanks in advance, William
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/3
45169"Reply

• Re: 2 WAN links/1 default


gateway-ASA...HYPERLINK
"https://supportforums.cisco.com/p
eople/Collin_Clark"Collin_Clark1
0 months, 4 days ago
William- What you want to do is
Policy Based Routing. Not the
prettiest thing in the world, but it
works. Unfortunately it's not
supported on the ASA (yet), so
your only PBR option is on the
router. You can search CCO for
policy based routing or PBR for
more info. Hope it helps.
Reply

• Re: 2 WAN links/1 default


gateway-
ASA...HYPERLINK
"https://supportforums.cisc
o.com/people/wpinberlin"w
pinberlin10 months, 4 days
ago
Thanks Collin, so that
would mean doing PBR on
the WAN side router to
direct the desired traffic out
the fixed 2Mb link, and
then doing NAT on the
VDSL link for the rest of
the traffic such that it has
the source address of the
PPPoE interface. Otherwise
we will end up once again
with all the response traffic
clogging up the 2Mb link
on its way back, as that is
how the provider will be
routing traffic down to our
publicly addressed...
Reply

• PIX and OSPFHYPERLINK


"https://supportforums.cisco.com/people/j
oemarr_brodart"joemarr_brodart1 Reply5
years, 4 months ago
I have 1 router configured with BGP that
is then connected to a PIX. IP Block A is a
class C that is has a /27 subnet used for
loopback and numbered link addressing. A
portion of the block is used on my PIX for
static NAT translations. I have OSPF
configured on the PIX and the router. IP
block is statically routed to NULL with a
metric of 254 (for BGP announcements)
on the router. I have a static route on the
PIX pointing the entire class C to the
outside interface. This route is
redistributed into OSPF with a metric of
200. The intention of this is so that the
router would see the announcement from
the PIX, keeping me from putting a 2nd
static route on the router pointing it to the
PIX. My problem is that when I reboot the
pix and it comes backup, internal hosts
can not reach the /27 network and external
hosts cannot reach the nat translated
addresses. My question, What is the
proper way of "routing" nat translated IPs?
I guess they are currently being proxy
arped by the PIX. I would prefer that I use
OSPF to get the traffic from the router to
the PIX, but maybe this isn't feasible.
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/7
0862"Reply

• Re: PIX and OSPFHYPERLINK


"https://supportforums.cisco.com/p
eople/didyap"didyap5 years, 4
months ago
PIX doesn't allow broadcast and
multicast traffic to pass through it.
Therefore, we can't use an Interior
Gateway Protocol (IGP) such as
Open Shortest Path First (OSPF),
Enhanced Interior Gateway
Routing Protocol (EIGRP), or
Routing Information Protocol
(RIP), all of which use broadcast
and multicast packets to exchange
routing information.
Reply

• Cisco SA540 - Classical Routing


Problem...HYPERLINK
"https://supportforums.cisco.com/people/s
ysadminkxen"sysadminkxen11 Replies8
months, 4 weeks ago
Hello, I'm a little newbie with Routing
Device, I had several Public IP I had a
Cisco Pix 501and want to replace it by a
Cisco SA540 my Wan IP on Pix 501 is
195.68.x.z my Lan IP on Pix 501 is
62.23.a.b (and 62.23.a.c ,...) My Pix 501
Translation rules is : inside interface|
inside:any:0.0.0.0|outside interface| same
as orginal address My Pix 501 Static route
: outside |Ip address 0.0.0.0|Netmask
0.0.0.0|Gateway IP 195.168.x.y|Metric 1
So when a computer with 62.23.a.X want
to acces to internet the static route tell it to
throuw the Gateway IP 195.168.x.y (as I
undestand) I have to replicate this config
to my SA540 So via the Web GUI, I
configure the Wan and Lan IP , then in
routing menu I check "Classical Routing"
then I go to Static Menu in order to add
the same route as in my Pix 501, but I
can't put 0.0.0.0 in iP address nor in IP
Subnet Mask. Can anyone help me ?
Thanks a lot.
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/2
018857"Reply

• Re: Cisco SA540 - Classical


Routing...HYPERLINK
"https://supportforums.cisco.com/p
eople/stevens2"stevens29 months,
2 days ago
The PIX and SA500 work
differently and are configured
differently. Often, you don't
configure a PIX and IOS in the
same fashion because they use a
different configuration. From what
I have read that you are trying to
do. The SA540 has a default route
to go out through the WAN port. If
you look at the routing table under
the diagnostics page, I think you
will see a route with 0.0.0.0 and
subnet of 0.0.0.0 going to the...
Reply

• Re: Cisco SA540 -


Classical
Routing...HYPERLINK
"https://supportforums.cisc
o.com/people/sysadminkxe
n"sysadminkxen9 months,
23 hours ago
Thanks Steven for you
answer. So you mean , for
what I want, I don"t have to
put a static route ? because
when I check "Classical
Routing" I don't have
access to the Internet. I
think I forgot something.
Reply

• Re: Cisco SA540 -


Classical
Routing...HYPERLI
NK
"https://supportforu
ms.cisco.com/peopl
e/sysadminkxen"sys
adminkxen9
months, 7 hours ago
Whatever I set :
NAT or
CLASSICAL
ROUTE my Router
Options in
Diagnostic menu
is : Kernel IP
routing table
Destination
Gateway Genmask
Flags Metric Ref
Use Iface 127.0.0.1
localhost
255.255.255.255
UGH ...
Reply

• Re: Cisco
SA540 -
Classical
Routing...H
YPERLINK
"https://supp
ortforums.ci
sco.com/peo
ple/sysadmi
nkxen"sysad
minkxen9
months, 4
hours ago
Reply

• Re:
Cisc
o
SA5
40 -
Class
ical
Rout
ing...
HYP
ERL
INK
"http
s://su
pport
foru
ms.ci
sco.c
om/p
eople
/aliss
itz"al
issitz
9
mont
hs, 2
hour
s ago
Hell
o, I
hope
this
finds
you
doin
g
well.
Just
figur
ed I
woul
d add
a few
mino
r
thing
s
here
...
You
prob
ably
saw
this,
howe
ver ..
.
here
is the
link
to
the
SA5
00
page:
https
://w
ww.
myci
scoc
omm
unity
.com
/docs
/DO
C-
1052
6
Yes,
when
you
confi
gure
the
devic
e as
a
route
r,
then
you
have
to
confi
gure
all
the
routi
ng.
You
migh
t try
to
remo
ve
the
route
s and
read
d
them
.
Also,
a
little
off
the
subje
ct,
but if
you
want
ed
to...
Repl
y

•R

T
ha
n
k
y
o
u
A
n
dr
e
w
fo
r
y
o
ur
an
s
w
er
.I
w
ill
ch
ec
k
fo
r
th
e
A
S
A
5
5
0
5.
I
d
o
n't
ha
ve
an
y
st
at
ic
ro
ut
e,
w
ha
t
ro
ut
e
d
o
I
ha
ve
to
ad
d
?
R
ep
ly


Hello,
Yep, the
ASA
product
line is a
very
powerful
FW, and
I would
suggest
looking
at this for
any PIX
replacem
ent. Here
is the link
for the
user
guide,
look to
the
network /
routing
section:
http://ww
w.cisco.c
om/en/U
S/docs/se
curity/mu
lti_functi
on_securi
ty/multi_
function_
security_
appliance
/sa_500/a
dministra
tion/guid
e/SA_50
0_Series_
AG_OL-
19114-
01.pdf
This is a
large pdf
so it may
take a
few
minutes
to load.
Once
you...
Reply

Thanks,
Andrew , this is
my problem,
which route do I
have to add ?
Thanks for your
help
Reply


Well ... now that this is
performing classical
routing, basically you
need to add whatever
routes are needed for
connectivity. ;-) Any
internal networks will
have to be route'able and
you will also need a
default route pointing to
the uplink / service
provider. Does this
make sense? If you find
this getting a little
'fuzzy', feel free to post
follow up questions here
or call a support rep via
the link I pasted earlier...
Reply

Following your link I have


called Cisco suport and opened
a Ticket. Thanks My service
providers gateway assigned to
me is 92.103.214.165. I have set
this on my WAN settings. It
works when using NAT. But
when I use Classical Routing, it
doesn't work. On my old pix
501 I had only one Static
Route : But on my Cisco SA540
I can't add 0.0.0.0 IP.
Reply
• More Replies

• EIGRP routing protocolHYPERLINK


"https://supportforums.cisco.com/people/d
fgalrito"dfgalrito10 Replies6 years, 5
months ago
I have same questions: 1- EIGRP is a
hybrid protocol? 2- What is the default
hop count of EIGRP? 3- The hello packets
is to establish neighborship and maintain
it? Isn't RTP to exchange the update
information for the EIGRP?
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/1
895"Reply

• Re: EIGRP routing


protocolHYPERLINK
"https://supportforums.cisco.com/p
eople/arraman"arraman6 years, 6
months ago
1. Yes it is hybrid protocols, uses
the features of both link state and
distance vector protocols 2. Uses
the cost (bandwidth and delay by
default) to select the best route 3.
RTP provides a reliable way of
exchanging protocols through
sequence number and
acknowledgements. Hello is to say
the other end/neighbor that i am
still alive. Hope it clarifies!!! Arun
Reply

• Re: EIGRP routing


protocolHYPERLINK
"https://supportforums.cisc
o.com/people/omal"omal6
years, 5 months ago
Hi Arun So you mean to
say that EIGRP uses RTP
to send Hello packets?
Does it also mean that
Hello packets get an
acknoledgements as well?
Thanks! Omal.
Reply

• Re: EIGRP routing


protocolHYPERLINK
"https://supportforums.cisco.com/p
eople/jacquesd"jacquesd6 years, 6
months ago
The default hop count for EIGRP
is 100. You can change it with
(config-router)# metric maximum-
hops {1-255} Jacques
Reply

• Re: EIGRP routing


protocolHYPERLINK
"https://supportforums.cisc
o.com/people/arraman"arra
man6 years, 5 months ago
No Hello packet is not
acknowledged. Rather they
are sent with an Sequence
number of '0' which means
the sender doesn't require
any acknowledgement from
the receiver. I have a
question to Jacques.. what
is the hop count used for in
EIGRP and IGRP does it
have any significance or
affect the whey the
protocol work? Arun
Reply

• Re: EIGRP routing


protocolhttps://supp
ortforums.cisco.co
m/people/simon.har
t
%40btinternet.com6
years, 5 months ago
I believe that the
hop count is used
purely to limit the
diameter of the
network. Once you
go above a hop
limit of 100 you can
have potential
problems with
routes becoming
SIA (stuck in
active). Simon
Reply

• Re: EIGRP routing


protocolHYPERLI
NK
"https://supportforu
ms.cisco.com/peopl
e/jacquesd"jacquesd
6 years, 5 months
ago
Hi, The significance
of hop count with
EIGRP is only to
limit the size of the
AS. It does not have
anything to do with
metric. As far as I
understand, when
routes fail in a
specific AS, only
routers within that
AS have to
converge. You can
imagine if you had
10000 routers in
one AS an a route
was to fail. Major
chaos. You would
also have to have
serious processing
power and memory
if EIGRP did not
have a limitation. I
guess you could...
Reply

• Re: EIGRP
routing
protocolHY
PERLINK
"https://supp
ortforums.ci
sco.com/peo
ple/omal"om
al6 years, 5
months ago
Hi Jacques
But does
EIGRP
converge
between
***. Let's
say one
router in
AS100 is
connected to
AS200. And
a route goes
down in
AS100, then
do all the
routers in
AS200 also
converge?
Or nothing
will happen
to routers in
AS200
because they
know to get
to AS100
they have to
send the
packets to
the router
which is
connected to
both ***.
Omal
Reply

• Re:
EIG
RP
routi
ng
proto
colH
YPE
RLI
NK
"http
s://su
pport
foru
ms.ci
sco.c
om/p
eople
/Cris
coSy
stem
s"Cri
scoS
yste
ms6
years
,5
mont
hs
ago
I
don't
even
kno
w of
any
provi
sion
withi
n
EIG
RP
for
confi
gurin
g and
exch
angi
ng
AS
num
bers.
EIG
RP is
an
IGP
(Inte
rior
Gate
way
Proto
col),
mean
ing it
only
hand
les
routi
ng
infor
mati
on
inter
nal
to a
give
n
AS.
If
you
want
to
swap
route
infor
mati
on
betw
een
diffe
rent
AS's,
you
need
an
Exter
ior
Gate
way
Proto
col
confi
gure
d,
like
BGP.
Am I
right
abou
t
this?
Repl
y

•R

H
i,
N
ee
d
n
ot
be
al
w
ay
s
tr
ue
th
at
y
o
u
ne
ed
an
E
G
P
to
be
co
nf
ig
ur
ed
to
ex
ch
an
ge
ro
ut
in
g
in
fo
r
m
at
io
n
be
t
w
ee
n
di
ff
er
en
t
A
S.
Y
o
u
ca
n
al
so
us
e
re
di
st
ri
b
ut
io
n
be
t
w
ee
n
th
e
t
w
o
A
S
to
ac
hi
ev
e
th
e
sa
m
e,
if
th
e
a
m
o
u
nt
of
ro
ut
in
g
in
fo
r
m
at
io
n
is
to
o
s
m
al
l.
A
ru
n
R
ep
ly


Hi pals
Great
answers.
Thanks a
lot. Keep
up the
good
work!
Omal
Reply

• More Replies

• Catalyst 4500, supervisor II+,


EIGRPHYPERLINK
"https://supportforums.cisco.com/people/
marekduba"marekduba5 Replies4 years, 2
months ago
Hi, We're bought a catalyst 4500 sup II+
with image cat4000-i9s-mz.122-
25.EWA4.bin In feature navigator isn't
anything about EIGRP in this image, but
in CLI I may configure EIGRP. How is
that possible? thx
Subscribe HYPERLINK
"https://supportforums.cisco.com/thread/1
38167"Reply

• Re: Catalyst 4500, supervisor II+,


EIGRPHYPERLINK
"https://supportforums.cisco.com/p
eople/amit-singh"amit-singh4
years, 3 months ago
Hi, You can only configure the
EIGRP stub on the Sup 2+. EIGRP
fully is not supported on sup2+.
http://www.cisco.com/univercd/cc/
td/doc/product/lan/cat4000/12_2_3
1s/conf/l3_int.htm#wp1042868
http://www.cisco.com/en/US/prod
ucts/hw/switches/ps4324/products
_data_sheet09186a0080197424.ht
ml HTH, Please rate if it does.
-amit singh
Reply

• Re: Catalyst 4500,


supervisor II+,
EIGRPHYPERLINK
"https://supportforums.cisc
o.com/people/marekduba"
marekduba4 years, 3
months ago
Yeah, i saw this about
EIGRP stub... but if I write
sh run command, there's no
line with eigrp stub in
router eigrp section. Is the
eigrp stub command on by
default? And how can I
check the stub settings?
Reply

• Re: Catalyst 4500, supervisor II+,


EIGRPHYPERLINK
"https://supportforums.cisco.com/p
eople/marekduba"marekduba4
years, 3 months ago
So, there is routing proto's that I
can configure in CLI... How is that
possible? bgp Border Gateway
Protocol (BGP) egp Exterior
Gateway Protocol (EGP) eigrp
Enhanced Interior Gateway
Routing Protocol (EIGRP) isis ISO
IS-IS iso-igrp IGRP for OSI
networks ...
Reply

• Re: Catalyst 4500,


supervisor II+,
EIGRPHYPERLINK
"https://supportforums.cisc
o.com/people/slaurin"slauri
n4 years, 3 months ago
Good morning, Your image
is IP BASE and it does not
support EIGRP to be
processed in hardware. It is
going to work, but the
switch will kick EIGRP out
of the CPU. You would
need to download an
ENHANCED L3 image to
have native EIGRP
support. Look for "is5s-
mz" in the image, for
example cat4000-i5s-
mz.122-
25.EWA6.bin>>>>ENHA
NCED L3
(OSPF,EIGRP,IS-IS)
Regards, Simon Laurin
Reply

• Re: Catalyst 4500, supervisor II+,


EIGRPHYPERLINK
"https://supportforums.cisco.com/p
eople/glen.grant"glen.grant4 years,
2 months ago
You will also see that the
commands to run ospf and even
bgp are in there and will work in a
lab situation but also are not
supported .
Reply
Subscribe HYPERLINK
"https://supportforums.cisco.com/login.jspa?
redirectURL=/choose-container!input.jspa?
contentType=1"Start A New Discussion

Related Information
• EIGRP Support Page

• ΕΙΓΡΠ Χο µ µ α ν δ
Ρεφ ε ρ ε ν χ ε Γυ ι δ ε

• ΙΠ Ρου τ ι ν γ
Συπ π ο ρ τ Πα γ ε

• Τεχ η ν ι χ α λ
Συπ π ο ρ τ − Χισ χ ο
Σψσ τ ε µ σ
Updated: Sep 09, 2005 Document ID: 16406

Solutions For
• Enterprise

• Σµα λ λ Βυσ ι ν ε σ σ

• Σερϖ ι χ ε Πρ ο ϖ ι δ ε ρ

Ηο µ ε

Industries
Contacts
• Contact Cisco

Φιν δ α Πα ρ τ ν ε ρ

News & Alerts


• News@Cisco

• Βλο γ σ

• Νεω σ λ ε τ τ ε ρ σ

• Φι ε λ δ Νο τ ι χ ε σ

Σεχ υ ρ ι τ ψ Αδϖ ι σ ο ρ ι ε σ

Support
• Downloads

∆ο χ υ µ ε ν τ α τ ι ο ν
Communities
• Collaboration

• ∆εϖ ε λ ο π ε ρ Νε τ ω ο ρ κ

• Λεα ρ ν ι ν γ Νε τ ω ο ρ κ

Συπ π ο ρ τ (Ν ε τ Π ρ ο )

About Cisco
• Investor Relations

• Χο ρ π ο ρ α τ ε Σοχ ι α λ Ρεσ π ο ν σ ι β ι λ ι τ ψ

• Ενϖ ι ρ ο ν µ ε ν τ α λ Συσ τ α ι ν α β ι λ ι τ ψ

• Ηυ µ α ν Νε τ ω ο ρ κ

Χα ρ ε ε ρ Οπ π ο ρ τ υ ν ι τ ι ε σ

Offers
• Special Offers

Φιν α ν χ ι ν γ Οπ τ ι ο ν σ

Collaboration
• Conferencing

• Χυσ τ ο µ ε ρ Χα ρ ε

• Εν τ ε ρ π ρ ι σ ε Σοχ ι α λ Σοφ τ ω α ρ ε

• ΙΠ Χο µ µ υ ν ι χ α τ ι ο ν σ

• Μεσ σ α γ ι ν γ

• Μο β ι λ ε Απ π λ ι χ α τ ι ο ν σ

Τελ ε π ρ ε σ ε ν χ ε

Solutions For
• Enterprise

• Σµα λ λ Βυσ ι ν ε σ σ

• Σερϖ ι χ ε Πρ ο ϖ ι δ ε ρ
Ηο µ ε

Industries
Contacts
• Contact Cisco

Φιν δ α Πα ρ τ ν ε ρ

Support
• Downloads

∆ο χ υ µ ε ν τ α τ ι ο ν

Communities
• Collaboration

• ∆εϖ ε λ ο π ε ρ Νε τ ω ο ρ κ

• Λεα ρ ν ι ν γ Νε τ ω ο ρ κ

Συπ π ο ρ τ (Ν ε τ Π ρ ο )

About Cisco
• Investor Relations

• Χο ρ π ο ρ α τ ε Σοχ ι α λ Ρεσ π ο ν σ ι β ι λ ι τ ψ

• Ενϖ ι ρ ο ν µ ε ν τ α λ Συσ τ α ι ν α β ι λ ι τ ψ

• Ηυ µ α ν Νε τ ω ο ρ κ

Χα ρ ε ε ρ Οπ π ο ρ τ υ ν ι τ ι ε σ

Offers
• Special Offers

Φιν α ν χ ι ν γ Οπ τ ι ο ν σ

Data Center and Virtualization


• Products and Solutions

• Χα σ ε Στυ δ ι ε σ

• ∆εσ ι γ ν Ζον ε
• Τεχη ν ο λ ο γ ψ Πα ρ τ ν ε ρ σ η ι π σ

∆α τ α Χεν τ ε ρ Σερϖ ι χ ε σ

Solutions For
• Enterprise

• Σµα λ λ Βυσ ι ν ε σ σ

• Σερϖ ι χ ε Πρ ο ϖ ι δ ε ρ

Ηο µ ε

Industries
Contacts
• Contact Cisco

Φιν δ α Πα ρ τ ν ε ρ

Support
• Downloads

∆ο χ υ µ ε ν τ α τ ι ο ν

Communities
• Collaboration

• ∆εϖ ε λ ο π ε ρ Νε τ ω ο ρ κ

• Λεα ρ ν ι ν γ Νε τ ω ο ρ κ

Συπ π ο ρ τ (Ν ε τ Π ρ ο )

About Cisco
• Investor Relations

• Χο ρ π ο ρ α τ ε Σοχ ι α λ Ρεσ π ο ν σ ι β ι λ ι τ ψ

• Ενϖ ι ρ ο ν µ ε ν τ α λ Συσ τ α ι ν α β ι λ ι τ ψ

• Ηυ µ α ν Νε τ ω ο ρ κ

Χα ρ ε ε ρ Οπ π ο ρ τ υ ν ι τ ι ε σ
Offers
• Special Offers

Φιν α ν χ ι ν γ Οπ τ ι ο ν σ

Borderless Networks
• Product Portfolio

• Αρ χ η ι τ ε χ τ υ ρ ε

• Σερϖ ι χ ε σ

• Σολ υ τ ι ο ν σ

Ινδυσ τ ρ ι ε σ

Solutions For
• Enterprise

• Σµα λ λ Βυσ ι ν ε σ σ

• Σερϖ ι χ ε Πρ ο ϖ ι δ ε ρ

Ηο µ ε

Industries
Contacts
• Contact Cisco

Φιν δ α Πα ρ τ ν ε ρ

Support
• Downloads

∆ο χ υ µ ε ν τ α τ ι ο ν

Communities
• Collaboration

• ∆εϖ ε λ ο π ε ρ Νε τ ω ο ρ κ

• Λεα ρ ν ι ν γ Νε τ ω ο ρ κ

Συπ π ο ρ τ (Ν ε τ Π ρ ο )
About Cisco
• Investor Relations

• Χο ρ π ο ρ α τ ε Σοχ ι α λ Ρεσ π ο ν σ ι β ι λ ι τ ψ

• Ενϖ ι ρ ο ν µ ε ν τ α λ Συσ τ α ι ν α β ι λ ι τ ψ

• Ηυ µ α ν Νε τ ω ο ρ κ

Χα ρ ε ε ρ Οπ π ο ρ τ υ ν ι τ ι ε σ

Offers
• Special Offers

Φιν α ν χ ι ν γ Οπ τ ι ο ν σ

Contacts | Feedback | Help | Site Map |


Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks

Вам также может понравиться