Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

FIGURE 17.6

Discontiguous networks

Let’s take a look at the routing tables on the NY and SF routers to find out

what they’re seeing:

SF>

sh ip route

[output cut]

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

C 172.16.10.0/30 is directly connected, Serial0/0/0

D 172.16.10.0/24 [90/2681856] via 172.16.10.1, 00:54:58,

Serial0/0/0

D 172.16.0.0/16 is a summary, 00:55:12, Null0

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

D 10.0.0.0/8 is a summary, 00:54:58, Null0

C 10.10.20.0/24 is directly connected, FastEthernet0/0

C 10.10.30.0/24 is directly connected, Loopback0

SF>

NY>

sh ip route

[output cut]

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

C 172.16.10.4/30 is directly connected, Serial0/0/1

D 172.16.0.0/16 is a summary, 00:55:56, Null0

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

D 10.0.0.0/8 is a summary, 00:55:26, Null0

C 10.10.40.0/24 is directly connected, FastEthernet0/0

C 10.10.50.0/24 is directly connected, Loopback0

NY>

ping 10.10.10.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

NY>

The confirmed answer is that our network isn’t working because we’re

discontiguous and our classful boundaries are auto-summarizing. We can

see that EIGRP is injecting summary routes into both the SF and NY

routing tables.

We need to advertise our subnets in order to make this work, and here’s

how we make that happen, starting with the Corp router:

Corp#

config t

Corp(config)#

router eigrp 20

Corp(config-router)#

no auto-summary

Corp(config-router)#

*Feb 25 18:29:30%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor

172.16.10.6 (Serial0/1)

is resync: summary configured

*Feb 25 18:29:30%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor

172.16.10.2 (Serial0/0)

is resync: summary configured

Corp(config-router)#

Okay—our network still isn’t working because the other routers are still

sending a summary. So let’s configure the SF and NY routers to advertise

subnets:

SF#

config t

SF(config)#

router eigrp 20

SF(config-router)#

no auto-summary

SF(config-router)#

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

(Serial0/0/0) is resync: summary configured

NY#

config t

NY(config)#

router eigrp 20

NY(config-router)#

no auto-summary

NY(config-router)#

*Jun 26 21:31:08%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor

172.16.10.5 (Serial0/0/1)

is resync: summary configured

Let’s take a look at the Corp router’s output now:

Corp(config-router)#

do show ip route

[output cut]

172.16.0.0/30 is subnetted, 2 subnets

C 172.16.10.4 is directly connected, Serial0/1

C 172.16.10.0 is directly connected, Serial0/0

10.0.0.0/24 is subnetted, 6 subnets

C 10.10.10.0 is directly connected, GigabitEthernet0/0

C 10.10.11.0 is directly connected, GigabitEthernet0/1

D 10.10.20.0 [90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

D 10.10.30.0 [90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

D 10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:29,

Serial0/1

D 10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:30,

Serial0/1

Corp#

ping 10.10.20.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.20.1, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4

ms

Wow, what a difference compared to the previous routing table output!

We can see all the subnets now. It would be hard to justify using auto-

summarization today. If you want to summarize, it should definitely be

done manually. Always typing in

no auto-summary

under RIPv2 and

EIGRP is common practice today.

The new 15.x code auto-summarization feature is disabled by

default, as it should be. But don’t think that discontiguous networks

and disabling auto-summary are no longer topics in the Cisco exam

objectives, because they most certainly are! When troubleshooting

EIGRP on the exam, verify the code version, and if it is 15.x code, then

you can assume that auto-summary is not a problem.

Controlling EIGRP Traffic

But what if you need to stop EIGRP from working on a specific interface?

Maybe it’s a connection to your ISP, or where we didn’t want to have the

g0/0 interface be part of the EIGRP process as in our earlier example. All

you need to do is to flag the interface as passive, and to do this from an

EIGRP session, just use this command:

passive-interface interface-type interface-number

This works because the

interface-type

portion defines the type of

interface and the

interface-number

portion defines the number of the

interface. The following command makes interface serial 0/0 into a

passive interface:

Corp(config)#

router eigrp 20

Corp(config-router)#

passive-interface g0/0

What we’ve accomplished here is to prevent this interface from sending

or reading received Hello packets so that it will no longer form

adjacencies or send or receive route information. But this still won’t stop

EIGRP from advertising the subnet of this interface out all other

interfaces without using wildcards. This really illustrates the reason you

must understand why and when to use wildcards as well as what the

passive-interface

command does. This knowledge really helps you to

make an informed decision on which command you need to use to meet

your specific business requirements!

The impact of the

passive-interface

command depends upon

the routing protocol under which the command is issued. For

example, on an interface running RIP, the

passive-interface

command will prohibit sending route updates but will permit

receiving them. An RIP router with a passive interface will still learn

about the networks advertised by other routers. This is different from

EIGRP, where an interface configured with the ​

passive-interface

command will neither send nor read received Hellos.

Typically, EIGRP neighbors use multicast to exchange routing updates.

You can change this by specifically telling the router about a particular

neighbor, which will ensure that unicast packets will only be used for the

routing updates with that specific neighbor. To take advantage of this

feature, apply the

neighbor

command and execute it under the EIGRP

process.

I’m going to configure the Corp router with information about routers SF

and NY:

Corp(config)#

router eigrp 20

Corp(config-router)#

neighbor 172.16.10.2

Corp(config-router)#

neighbor 172.16.10.6

Understand that you don’t need to use the preceding commands to create

neighbor relationships, but they’re available if you need them.

EIGRP Metrics

Unlike many other protocols that use a single element to compare routes

and select the best possible path, EIGRP uses a combination of these four

factors:

Bandwidth

Delay

Load

Reliability

It’s worth noting that there’s a fifth element, maximum transmission unit

(MTU), which has never been used in EIGRP metrics calculations though

it’s still a required parameter in some EIGRP-related commands—

especially those involving redistribution. The value of the MTU element

represents the smallest MTU value encountered along the path to the

destination network.

Also good to know is that there’s a mathematical formula that combines

the four main elements to create a single value representing just how

good a given route actually is. The higher the metric associated with it,

the less desirable the route. Here’s that formula:

The formula’s components break down like this:

By default, K

1

= 1, K

2

= 0, K

3

= 1, K

4

= 0, K

5

= 0.

Delay equals the sum of all the delays of the links along the path.

Delay = [Delay in 10s of microseconds] × 256.

Bandwidth is the lowest bandwidth of the links along the path.

Bandwidth = [10000000 / (bandwidth in Kbps)] × 256.

By default, metric = lowest bandwidth along path + sum of all delays

along path.

If necessary, you can adjust the constant K values on a per-interface

basis, but I would recommend that you only do this under the direction of

the Cisco Technical Assistance Center (TAC). Metrics are tuned to change

the manner in which routes are calculated. The K values can be seen with

a

show ip protocols

output:

Corp#

sh ip protocols

*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 1"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Default networks flagged in outgoing updates

Default networks accepted from incoming updates

EIGRP-IPv4 Protocol for AS(1)

Metric weight K1=1, K2=0, K3=1, K4=0, K5=0

Notice that that the K1 and K3 values are enabled by default—for

example, K1 = 1.

Table 17.1

shows the relationship between each constant

and the metric it affects.

Each constant is used to assign a weight to a specific variable, meaning

that when the metric is calculated, the algorithm will assign a greater

importance to the specified metric. This is very cool because it means that

by assigning a weight, you get to specify the factor that’s most important

to you. For example, if bandwidth is your priority, you would assign K1 to

weight it accordingly, but if delay is totally unacceptable, then K3 would

be assigned a greater weight. A word of caution though: Always

remember that any changes to the default values could result in

instability and convergence problems, particularly if delay or reliability

values are constantly changing! But if you’re looking for something to do

on a rainy Saturday, it’s an interesting experiment to pass some time and

gain some nice networking insight!

TABLE 17.1

Metric association of K values

Constant Metric

K1

Bandwidth (B

e

)

K2

Load (utilization on path)

K3

Delay (D

c

)

K4

Reliability (r)

K5

MTU

Maximum Paths and Hop Count

By default, EIGRP can provide equal-cost load balancing across up to 4

links. RIP and OSPF do this too. But you can have EIGRP actually load-

balance across up to 32 links with 15.0 code (equal or unequal) by using

the following command:

Corp(config)#

router eigrp 10

Corp(config-router)#

maximum-paths ?

<1-32> Number of paths

As I mentioned, pre–15.0 code routers allowed up to 16 paths to remote

networks, which is still a lot!

EIGRP has a default maximum hop count of 100 for route update

packets, but it can be set up to 255. Chances are you wouldn’t want to

ever change this, but if you did, here is how you would do it:

Corp(config)#

router eigrp 10

Corp(config-router)#

metric maximum-hops ?

<1-255> Hop count

As you can see from this router output, EIGRP can be set to a maximum

of 255 hops. Even though it doesn’t use hop count in the path metric

calculation, it still uses the maximum hop count to limit the scope of the

AS.

Route Selection

Now that you’ve got a good idea how EIGRP works and also how easy it

actually is to configure, it’s probably clear that determining the best path

simply comes down to seeing which one gets awarded the lowest metric.

But it’s not the winning path that really sets EIGRP apart from other

protocols. You know that EIGRP stores route information from its

neighbors in its topology table and that as long as a given neighbor

remains alive, it will rarely throw out anything it has learned from that

neighbor. This makes EIGRP able to flag the best routes in its topology

table for positioning in its local routing table, enabling it to flag the next-

best routes as alternatives if the best route goes down.

In

Figure 17.7

, you can see that I added another Fast Ethernet link

between the SF and NY routers. This will give us a great opportunity to

play with the topology and routing tables!

FIGURE 17.7

EIGRP route selection process

First, let’s take another look at the routing table on the Corp router before

I bring up the new interfaces:

172.16.0.0/30 is subnetted, 2 subnets

C 172.16.10.4 is directly connected, Serial0/1

C 172.16.10.0 is directly connected, Serial0/0

10.0.0.0/24 is subnetted, 6 subnets

C 10.10.10.0 is directly connected, GigabitEthernet0/0

C 10.10.11.0 is directly connected, GigabitEthernet0/1

D 10.10.20.0 [90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

D 10.10.30.0 [90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

D 10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:29,

Serial0/1

D 10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:30,

Serial0/1

We can see the three directly connected interfaces as well as the other

four networks injected into the routing table by EIGRP. Now I’ll add the

network 192.168.10.0/24 between the SF and NY routers, then enable the

interfaces.

And let’s check out the routing table of the Corp router now that I’ve

configured that link:

D 192.168.10.0/24 [90/2172416] via 172.16.10.6, 00:04:27,

Serial0/1

172.16.0.0/30 is subnetted, 2 subnets

C 172.16.10.4 is directly connected, Serial0/1

C 172.16.10.0 is directly connected, Serial0/0

10.0.0.0/24 is subnetted, 6 subnets

C 10.10.10.0 is directly connected, GigabitEthernet0/0

C 10.10.11.0 is directly connected, GigabitEthernet0/1

D 10.10.20.0 [90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

D 10.10.30.0 [90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

D 10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:29,

Serial0/1

D 10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:30,

Serial0/1

Okay—that’s weird. The only thing different I see is one path to the

192.168.10.0/24 network listed first. Glad it is there, which means that

we can route to that network. Notice that we can reach the network from

the Serial0/1 interface, but what happened to my link to the SF router—

shouldn’t we have an advertisement from that router and be load-

balancing? Let’s take a look the topology table to find out what’s going on:

Corp#

sh ip eigrp topology

IP-EIGRP Topology Table for AS(20)/ID(10.10.11.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.10.10.0/24, 1 successors, FD is 128256

via Connected, GigbitEthernet0/0

P 10.10.11.0/24, 1 successors, FD is 128256

via Connected, GigbitEthernet0/1

P 10.10.20.0/24, 1 successors, FD is 2300416

via 172.16.10.6 (2300416/156160), Serial0/1

via 172.16.10.2 (3200000/128256), Serial0/0

P 10.10.30.0/24, 1 successors, FD is 2300416

via 172.16.10.6 (2300416/156160), Serial0/1

via 172.16.10.2 (3200000/128256), Serial0/0

P 10.10.40.0/24, 1 successors, FD is 2297856

via 172.16.10.6 (2297856/128256), Serial0/1

via 172.16.10.2 (3202560/156160), Serial0/0

P 10.10.50.0/24, 1 successors, FD is 2297856

via 172.16.10.6 (2297856/128256), Serial0/1

via 172.16.10.2 (3202560/156160), Serial0/0

P 192.168.10.0/24, 1 successors, FD is 2172416

via 172.16.10.6 (

2172416/28160), Serial0/1

via 172.16.10.2 (

3074560/28160), Serial0/0

P 172.16.10.4/30, 1 successors, FD is 2169856

via Connected, Serial0/1

P 172.16.10.0/30, 1 successors, FD is 3072000

via Connected, Serial0/0

Okay, we can see there are two paths to the 192.168.10.0/24 network, but

it’s using the next hop of 172.16.10.6 (NY) because the feasible distance

(FD) is less! The advertised distance from both routers is 28160, but the

cost to get to each router via the WAN links is not the same. This means

the FD is not the same, meaning we’re not load-balancing by default.

Both WAN links are a T1, so this should have load-balanced by default,

but EIGRP has determined that it costs more to go through SF than

through NY. Since EIGRP uses bandwidth and delay of the line to

determine the best path, we can use the

show interfaces

command to

verify our stats like this:

Corp#

sh int s0/0

Serial0/0 is up, line protocol is up

Hardware is PowerQUICC Serial

Description: <>

Internet address is 172.16.10.1/30

MTU 1500 bytes, BW 1000 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation HDLC, loopback not set Keepalive set (10 sec)

Corp#

sh int s0/1

Serial0/1 is up, line protocol is up

Hardware is PowerQUICC Serial

Internet address is 172.16.10.5/30

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation HDLC, loopback not set Keepalive set (10 sec)

I highlighted the statistics that EIGRP uses to determine the metrics to a

next-hop router: MTU, bandwidth, delay, reliability, and load, with

bandwidth and delay enabled by default. We can see that the bandwidth

on the Serial0/0 interface is set to 1000 Kbit, which is not the default

bandwidth. Serial0/1 is set to the default bandwidth of 1544 Kbit.

Let’s set the bandwidth back to the default on the s0/0 interface and we

should start load-balancing to the 192.168.10.0 network. I’ll just use the

no bandwidth

command, which will set it back to its default of 1544 Mbps:

Corp#

config t

Corp(config)#

int s0/0

Corp(config-if)#

no bandwidth

Corp(config-if)#

^Z

Now let’s take a look at the topology table and see if we’re equal.

Corp#

sh ip eigrp topo | section 192.168.10.0

P 192.168.10.0/24, 2 successors, FD is 2172416

via 172.16.10.2 (2172416/28160), Serial0/0

via 172.16.10.6 (2172416/28160), Serial0/1

Since the topology tables can get really huge in most networks, the

show

ip eigrp topology | section

network

command comes in handy because

it allows us to see information about the network we want to look into in

a couple of lines.

Let’s use the

show ip route

network

command and check out what is

going on there:

Corp#

sh ip route 192.168.10.0

Routing entry for 192.168.10.0/24

Known via "eigrp 20", distance 90, metric 2172416, type internal

Redistributing via eigrp 20

Last update from 172.16.10.2 on Serial0/0, 00:05:18 ago

Routing Descriptor Blocks:

* 172.16.10.6, from 172.16.10.6, 00:05:18 ago, via Serial0/1

Route metric is 2172416, traffic share count is 1

Total delay is 20100 microseconds, minimum bandwidth is 1544

Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

172.16.10.2, from 172.16.10.2, 00:05:18 ago, via Serial0/0

Route metric is 2172416, traffic share count is 1

Total delay is 20100 microseconds, minimum bandwidth is 1544

Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

Lots of detail about our routes to the 192.168.10.0 network! The Corp

route has two equal-cost links to the 192.168.10.0 network. And to reveal

load balancing even better, we’ll just use the plain, ever useful

show ip

route

command:

Corp#

sh ip route

[output cut]

D 192.168.10.0/24 [90/2172416] via 172.16.10.6, 00:05:35,

Serial0/1

[90/2172416] via 172.16.10.2, 00:05:35,

Serial0/0

Now we can see that there are two successor routes to the 192.168.10.0

network. Pretty sweet! But in the routing table, there’s one path to

192.168.20.0 and 192.168.30.0, with the link between the SF and NY

routers being feasible successors. And it’s the same with the 192.168.40.0

and 192.168.50.0 networks. Let’s take a look at the topology table to

examine this more closely:

Corp#

sh ip eigrp topology

IP-EIGRP Topology Table for AS(20)/ID(10.10.11.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.10.10.0/24, 1 successors, FD is 128256

via Connected, GigabitEthernet0/0

P 10.10.11.0/24, 1 successors, FD is 128256

via Connected, GigabitEthernet0/1

P 10.10.20.0/24, 1 successors, FD is 2297856

via 172.16.10.2 (2297856/128256), Serial0/0

via 172.16.10.6 (2300416/156160), Serial0/1

P 10.10.30.0/24, 1 successors, FD is 2297856

via 172.16.10.2 (2297856/128256), Serial0/0

via 172.16.10.6 (2300416/156160), Serial0/1

P 10.10.40.0/24, 1 successors, FD is 2297856

via 172.16.10.6 (2297856/128256), Serial0/1

via 172.16.10.2 (2300416/156160), Serial0/0

P 10.10.50.0/24, 1 successors, FD is 2297856

via 172.16.10.6 (2297856/128256), Serial0/1

via 172.16.10.2 (2300416/156160), Serial0/0

P 192.168.10.0/24, 2 successors, FD is 2172416

via 172.16.10.2 (2172416/28160), Serial0/0

via 172.16.10.6 (2172416/28160), Serial0/1

P 172.16.10.4/30, 1 successors, FD is 2169856

via Connected, Serial0/1

P 172.16.10.0/30, 1 successors, FD is 2169856

via Connected, Serial0/0

It is nice that we can see that we have a successor and a feasible successor

to each network, so we know that EIGRP is doing its job. Let’s take a close

look at the links to 10.10.20.0 now and dissect what it’s telling us:

P 10.10.20.0/24, 1 successors, FD is 2297856

via 172.16.10.2 (2297856/128256), Serial0/0

via 172.16.10.6 (2300416/156160), Serial0/1

Okay—first, we can see that it’s passive (P), which means that it has found

all the usable paths to the network 10.10.20.0 and is happy! If we see

active (A), that means that EIGRP is not happy at all and is querying its

neighbors for a new path to that network. The

(2297856/128256)

is the

FD/AD, meaning that the SF router is advertising the 10.10.20.0 network

as a cost of 128256, which is the AD. The Corp router adds the bandwidth

and delay of the line to get to the SF router and then adds that number to

the AD (128256) to come up with a total cost (FD) of 2297856 to get to

network 10.10.20.0.

To become a CCNA R/S, you must understand how to read a

topology table!