Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

FIGURE 17.2

Advertised distance

We’re not done yet because the Corp router still needs to calculate its cost

to each neighbor.

Feasible distance (FD) This is the best metric among all paths to a

remote network, including the metric to the neighbor that’s advertising

the remote network. The route with the lowest FD is the route that you’ll

find in the routing table because it’s considered the best path. The metric

of a feasible distance is calculated using the metric reported by the

neighbor that’s referred to as the reported or advertised distance plus the

metric to the neighbor reporting the route. In

Figure 17.3

, the Corp router

will have the path through router SF to network 10.0.0.0 in the routing

table since it’s the lowest feasible distance. It’s the lowest true cost from

end to end.

Take a look at an EIGRP route that’s been injected into a routing table

and find the FD listed in the entry.

D 10.0.0.0/8 [90/2195456] via 172.16.10.2, 00:27:06,Serial0/0

First, the

D

means Dual, and it’s an EIGRP injected route and the route

used by EIGRP to forward traffic to the 10.0.0.0 network via its neighbor,

172.16.10.2. But that’s not what I want to focus on right now. See the

[90/2195456]

entry in the line? The first number (

90

) is the administrative

distance (AD), which is not to be confused with advertised distance (AD),

which is why a lot of people call it the reported distance! The second

number, is the feasible distance (FD), or the entire cost for this router to

get to network 10.0.0.0. To sum this up, the neighbor router sends a

reported, or advertised, distance (RD/AD) for network 10.0.0.0, and

EIGRP calculates the cost to get to that neighbor and then adds those two

numbers together to get the FD, or total cost.

FIGURE 17.3

Feasible distance

Neighbor table Each router keeps state information about adjacent

neighbors. When a newly discovered neighbor is found, its address and

interface are recorded and the information is held in the neighbor table,

stored in RAM. Sequence numbers are used to match acknowledgments

with update packets. The last sequence number received from the

neighbor is recorded so that out-of-order packets can be detected. We’ll

get into this more, later in the chapter, when we look at the neighbor

table and find out how it’s useful for troubleshooting links between

neighbor routers.

Topology table The topology table is populated by the neighbor table

and the Diffusing Update Algorithm (DUAL) calculates the best loop-free

path to each remote network. It contains all destinations advertised by

neighboring routers, holding each destination address and a list of

neighbors that have advertised the destination. For each neighbor, the

advertised metric (distance), which comes only from the neighbor’s

routing table, is recorded, as well as the FD. The best path to each remote

network is copied and placed in the routing table and then IP will use this

route to forward traffic to the remote network. The path copied to the

routing table is called a successor router—think “successful” to help you

remember. The path with a good, but less desirable, cost will be entered

in the topology table as a backup link and called the feasible successor.

Let’s talk more about these terms now.

The neighbor and topology tables are stored in RAM and

maintained through the use of Hello and update packets. While the

routing table is also stored in RAM, the information stored in the

routing table is gathered only from the topology table.

Feasible successor (FS) So a feasible successor is basically an entry in

the topology table that represents a path that’s inferior to the successor

route(s). An FS is defined as a path whose advertised distance is less than

the feasible distance of the current successor and considered a backup

route. EIGRP will keep up to 32 feasible successors in the topology table

in 15.0 code but only up to 16 in previous IOS versions, which is still a lot!

Only the path with the best metric—the successor—is copied and placed

in the routing table. The

show ip eigrp topology

command will display

all the EIGRP feasible successor routes known to the router.

A feasible successor is a backup route and is stored in the

topology table. A successor route is stored in the topology table and is

copied and placed in the routing table.

Successor A successor route—again, think “successful”—is the best

route to a remote network. A successor route is the lowest cost to a

destination and stored in the topology table along with everything else.

However, this particular best route is copied and placed in the routing

table so IP can use it to get to the remote network. The successor route is

backed up by a feasible successor route, which is also stored in the

topology table, if there’s one available. The routing table contains only

successor routes; the topology table contains successor and feasible

successor routes.

Figure 17.4

illustrates that the SF and NY routers each have subnets of

the 10.0.0.0 network and the Corp router has two paths to get to this

network.

FIGURE 17.4

The tables used by EIGRP

As shown in

Figure 17.4

, there are two paths to network 10.0.0.0 that can

be used by the Corp router. EIGRP picks the best path and places it in the

routing table, but if both links have equal-cost paths, EIGRP would load-

balance between them—up to four links, by default. By using the

successor, and having feasible successors in the topology table as backup

links, the network can converge instantly and updates to any neighbor

make up the only traffic sent from EIGRP—very clean!

Reliable Transport Protocol (RTP)

EIGRP depends on a proprietary protocol, called Reliable Transport

Protocol (RTP), to manage the communication of messages between

EIGRP-speaking routers. As the name suggests, reliability is a key

concern of this protocol, so Cisco designed this mechanism, which

leverages multicasts and unicasts, to ensure that updates are delivered

quickly and that data reception is tracked accurately.

But how does this really work? Well, when EIGRP sends multicast traffic,

it uses the Class D address 224.0.0.10, and each EIGRP router knows

who its neighbors are. For each multicast it sends out, a list is built and

maintained that includes all the neighbors who have replied. If a router

doesn’t get a reply from a neighbor via the multicast, EIGRP will then try

using unicasts to resend the same data. If there’s no reply from a

neighbor after 16 unicast attempts, that neighbor will then be declared

dead. This process is often referred to as reliable multicast.

Routers keep track of the information they send by assigning a sequence

number to each packet that enables them to identify old, redundant

information and data that’s out of sequence. You’ll get to actually see this

information in the neighbor table coming up when we get into

configuring EIGRP.

Remember, EIGRP is all about topology changes and updates, making it

the quiet, performance-optimizing protocol it is. Its ability to synchronize

routing databases at startup time, while maintaining the consistency of

databases over time, is achieved quietly by communicating only necessary

changes. The downside here is that you can end up with a corrupted

routing database if any packets have been permanently lost or if packets

have been mishandled out of order!

Here’s a description of the five different types of packets used by EIGRP:

Update An Update packet contains route information. When these are

sent in response to metric or topology changes, they use reliable

multicasts. In the event that only one router needs an update, like when a

new neighbor is discovered, it’s sent via unicasts. Keep in mind that the

unicast method still requires an acknowledgment, so updates are always

reliable regardless of their underlying delivery mechanism.

Query A Query packet is a request for specific routes and always uses

the reliable multicast method. Routers send queries when they realize

they’ve lost the path to a particular network and are searching for

alternatives.

Reply A Reply packet is sent in response to a query via the unicast

method. Replies either include a specific route to the queried destination

or declare that there’s no known route.

Hello A Hello packet is used to discover EIGRP neighbors and is sent via

unreliable multicast, meaning it doesn’t require an acknowledgment.

ACK An ACK packet is sent in response to an update and is always

unicast. ACKs are never sent reliably because this would require another

ACK sent for acknowledgment, which would just create a ton of useless

traffic!

It’s helpful to think of all these different packet types like envelopes.

They’re really just types of containers that EIGRP routers use to

communicate with their neighbors. What’s really interesting is the actual

content envelopes these communications and the procedures that guide

their conversations, and that’s what we’ll be exploring next!

Diffusing Update Algorithm (DUAL)

I mentioned that EIGRP uses Diffusing Update Algorithm (DUAL) for

selecting and maintaining the best path to each remote network. DUAL

allows EIGRP to carry out these vital tasks:

Figure out a backup route if there’s one available.

Support variable length subnet masks (VLSMs).

Perform dynamic route recoveries.

Query neighbors for unknown alternate routes.

Send out queries for an alternate route.

Quite an impressive list, but what really makes DUAL so great is that it

enables EIGRP to converge amazingly fast! The key to the speed is

twofold: First, EIGRP routers maintain a copy of all of their neighbors’

routes to refer to for calculating their own cost to each remote network.

So if the best path goes down, all it often takes to find another one is a

quick scan of the topology table looking for a feasible successor. Second,

if that quick table survey doesn’t work out, EIGRP routers immediately

ask their neighbors for help finding the best path. It’s exactly this, ahem,

DUAL strategy of reliance upon, and the leveraging of, other routers’

information that accounts for the algorithm’s “diffusing” character.

Unlike other routing protocols where the change is propagated through

the entire network, EIGRP bounded updates are propagated only as far as

needed.

Three critical conditions must be met for DUAL to work properly:

Neighbors are discovered or noted as dead within a finite time.

All transmitted messages are received correctly.

All changes and messages are processed in the order in which they’re

detected.

As you already know, the Hello protocol ensures the rapid detection of

new or dead neighbors, and RTP provides a reliable method of conveying

and sequencing messages. Based upon this solid foundation, DUAL can

then select and maintain information about the best paths. Let’s check

further into the process of route discovery and maintenance next.

Route Discovery and Maintenance

The hybrid nature of EIGRP is fully revealed in its approach to route

discovery and maintenance. Like many link-state protocols, EIGRP

supports the concept of neighbors that are formally discovered via a Hello

process and whose state is monitored thereafter. And like many distance-

vector protocols, EIGRP uses the routing-by-rumor approach, which

implies that many routers within an AS never actually hear about a route

update firsthand. Instead, these devices rely on “network gossip” to hear

about neighbors and their respective status via another router that may

have also gotten the info from yet another router and so on.

Given all of the information that EIGRP routers have to collect, it follows

that they must have a place to store it, and they do this in the tables I

referred to earlier in this chapter. As you know, EIGRP doesn’t depend on

just one table—it actually uses three of them to store important

information about its environment:

Neighbor table Contains information about the specific routers with

whom neighbor relationships have been formed. It also displays

information about the Hello transmit interval and queue counts for

unaccounted Hello acknowledgment.

Topology table Stores the route advertisements received from each

neighbor. All routes in the AS are stored in the topology table, both

successors and feasible successors.

Route table Stores the routes that are currently in use to make local

routing decisions. Anything in the routing table is considered a successor

route.

We’ll explore more of EIGRP’s features in greater detail soon, beginning

with a look at the metrics associated with particular routes. After that, I’ll

cover the decision-making process that’s used to select the best routes,

and then we’ll review the procedures followed when routes change.

Configuring EIGRP

I know what you’re thinking! “We’re going to jump in to configuring

EIGRP already when I’ve heard how complex it is?” No worries here—

what I’m about to show is basic, and I know you won’t have a problem

with it at all! We’re going to start with the easy part of EIGRP, and by

configuring it on our little internetwork, you’ll learn a lot more this way

than you would if I just continued explaining more at this point. After

we’ve completed the initial configuration, we’ll fine-tune it and have fun

experimenting with it throughout this chapter!

Okay, there are two modes for entering EIGRP commands: router

configuration mode and interface configuration mode. In router

configuration mode, we’ll enable the protocol, determine which networks

will run EIGRP, and set global factors. When in interface configuration

mode, we’ll customize summaries and bandwidth.

To initiate an EIGRP session on a router, I’ll use the

router eigrp

command followed by our network’s AS number. After that, we’ll enter

the specific numbers of the networks that we want to connect to the

router using the

network

command followed by the network number. This

is pretty straightforward stuff—if you can configure RIP, then you can

configure EIGRP!

Just so you know, we’ll use the same network I used in the previous

CCENT routing chapters, but I’m going to connect more networks so we

can look deeper into EIGRP. With that, I’m going to enable EIGRP for

autonomous system 20 on our Corp router connected to four networks.

Figure 17.5

shows the network we’ll be configuring throughout this

chapter and the next chapter. Here’s the Corp configuration:

FIGURE 17.5

Configuring our little internetwork with EIGRP

Corp#config t

Corp(config)#

router eigrp 20

Corp(config-router)#

network 172.16.0.0

Corp(config-router)#

network 10.0.0.0

Remember, just as we would when configuring RIP, we need to use the

classful network address, which is all subnet and host bits turned off. This

is another thing that makes EIGRP so great: it has the complexity of a

link-state protocol running in the background and the same easy

configuration process used for RIP!

Understand that the AS number is irrelevant—that is, as long

as all routers use the same number! You can use any number from 1

to 65,535.

But wait, the EIGRP configuration can’t be that easy, can it? A few simple

EIGRP commands and my network just works? Well, it can be and

usually is, but not always. Remember the wildcards you learned about in

your access list configurations in your preparation for the Cisco exam?

Let’s say, for example, that we wanted to advertise all the directly

connected networks with EIGRP off the Corp router. By using the

command

network 10.0.0.0

, we can effectively advertise to all subnets

within that classful network; however, take a look at this configuration

now:

Corp#

config t

Corp(config)#

router eigrp 20

Corp(config-router)#

network 10.10.11.0 0.0.0.255

Corp(config-router)#

network 172.16.10.0 0.0.0.3

Corp(config-router)#

network 172.16.10.4 0.0.0.3

This configuration should look pretty familiar to you because by now you

should have a solid understanding of how wildcards are configured. This

configuration will advertise the network connected to g0/1 on the Corp

router as well as the two WAN links. Still, all we accomplished with this

configuration was to stop the g0/0 interface from being placed into the

EIGRP process, and unless you have tens of thousands of networks

worldwide, then there is really no need to use wildcards because they

don’t provide any other administrative purpose other than what I’ve

already described.

Now let’s take a look at the simple configuration needed for the SF and

NY routers in our internetwork:

SF(config)#

router eigrp 20

SF(config-router)#

network 172.16.0.0

SF(config-router)#

network 10.0.0.0

000060:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor

172.16.10.1 (Serial0/0/0) is up:

new adjacency

NY(config)#

router eigrp 20

NY(config-router)#

network 172.16.0.0

NY(config-router)#

network 10.0.0.0

*Jun 26 02:41:36:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor

172.16.10.5 (Serial0/0/1) is up: new adjacency

Nice and easy—or is it? We can see that the SF and NY router created an

adjacency to the Corp router, but are they actually sharing routing

information? To find out, let’s take a look at the number that I pointed

out as the autonomous system (AS) number in the configuration.

EIGRP uses ASs to identify the group of routers that will share route

information. Only routers that have the same AS share routes. The range

of values we can use to create an AS with EIGRP is 1–65535:

Corp(config)#

router eigrp ?

<1-65535> Autonomous System

WORD EIGRP Virtual-Instance Name

Corp(config)#

router eigrp 20

Notice that I could have used any number from 1 to 65,535, but I chose to

use 20 because it just felt good at the time. As long as all routers use the

same number, they’ll create an adjacency. Okay, now the AS makes sense,

but it looks like I can type a

word

in the place of the AS number, and I can!

Let’s take a look at the configuration:

Corp(config)#

router eigrp Todd

Corp(config-router)#

address-family ipv4 autonomous-system 20

Corp(config-router-af)#

network 10.0.0.0

Corp(config-router-af)#

network 172.16.0.0

What I just showed you is not part of the Cisco exam objectives, but it’s

also not really necessary for any IPv4 routing configuration in your

network. The previous configuration examples I’ve gone through so far in

this chapter covers the objectives and work just fine, but I included this

last configuration example because it’s now an option in IOS 15.0 code.

VLSM Support and Summarization

Being one of the more sophisticated classless routing protocols, EIGRP

supports using variable length subnet masks. This is good because it

allows us to conserve address space by using subnet masks that map to

specific host requirements in a much better way. Being able to use 30-bit

subnet masks for the point-to-point networks that I configured in our

internetwork is a great example. Plus, because the subnet mask is

propagated with every route update, EIGRP also supports the use of

discontiguous subnets, giving us greater administrative flexibility when

designing a network IP address scheme. Another versatile feature is that

EIGRP allows us to use and place route summaries at strategically

optimal locations throughout the EIGRP network to reduce the size of the

routing table.

Keep in mind that EIGRP automatically summarizes networks at their

classful boundaries and supports the manual creation of summaries at

any and all EIGRP routers. This is usually a good thing, but by checking

out the routing table in the Corp router, you can see the possible

complications that auto-summarization can cause:

Corp#

sh ip route

[output cut]

172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks

C 172.16.10.4/30 is directly connected, Serial0/1

C 172.16.10.0/30 is directly connected, Serial0/0

D 172.16.0.0/16 is a summary, 00:01:37, Null0

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C 10.10.10.0/24 is directly connected, GigabitEthernet0/0

D 10.0.0.0/8 is a summary, 00:01:19, Null0

C 10.10.11.0/24 is directly connected, GigabitEthernet0/1

Now this just doesn’t look so good—both 172.16.0.0 and 10.0.0.0/8 are

being advertised as summary routes injected by EIGRP, but we have

multiple subnets in the 10.0.0.0/8 classful network address, so how

would the Corp router know how to route to a specific network like

10.10.20.0? The answer is, it wouldn’t. Let’s see why in

Figure 17.6

.

The networks we’re using make up what is considered a discontinuous

network because we have the 10.0.0.0/8 network subnetted across a

different class of address, the 172.16.0.0 network, with 10.0.0.0/8

subnets on both sides of the WAN links.

You can see that the SF and NY routers will both create an automatic

summary of 10.0.0.0/8 and then inject it into their routing tables. This is

a common problem, and an important one that Cisco really wants you to

understand (by including it in the objectives)! With this type of topology,

disabling automatic summarization is definitely the better option.

Actually, it’s the only option if we want this network to work.