This chapter covers the following topics that you will need to master as a CCNA:

•

This section covers the details of distance

vector routing protocol logic, including split horizon, holddown timers, and route

poisoning. Link-state and balanced hybrid routing protocols are covered briefly.

•

This section covers RIP Versions 1 and 2, plus

IGRP configuration details. EXEC commands used to examine the IP routing table are

also examined.

•

This section covers the concepts and configuration for

IPX, with focus on IPX RIP and SAP. Key initialization flows are outlined as well.

•

This section discusses the use of tunnel interfaces for encapsulating a

protocol for transport across an IP network. Configuration for tunnel interfaces is also

covered.

•

This section provides a description of the meaning

of the term

.

Cisco expects CCNAs to demonstrate a comfortable understanding of the logic behind the

routing of packets and the logic behind a routing protocol. This chapter focuses on

, the protocols used to discover routes. To fully appreciate the nuances of routing

protocols, you need a thorough understanding of routing (the process of forwarding

packets). If you have not yet reviewed the section on Layer 3 in Chapter 3, “OSI Reference

Model & Layered Communication,” and the sections on IP and IPX in Chapter 5, “Network

Protocols,” then you might want to review those sections before proceeding with this

chapter.

The CCNA exam requires you to know the nuances and details of distance vector logic,

which is covered in the first section of this chapter. This is the logic used by the Routing

Information Protocol (RIP) and Interior Gateway Routing Protocol (IGRP), as well as IP

RIP. In fact, some distance vector concepts even are applied to the NetWare Service

Advertising Protocol (SAP), even though SAP does not distribute routing information.

Along the way, alternative routing protocol algorithms (link-state and Diffusing Update

Algorithm [DUAL]) are mentioned briefly.

Implementation details of RIP (Version 1 and Version 2) and IGRP are covered next.

Because EIGRP configuration is similar to IGRP, it is also covered briefly. As you’ll find

on the CCNA exam, knowledge and skills for routing protocol configuration and

troubleshooting are topics required of CCNAs.

Implementation of IPX RIP and SAP is another topic for which Cisco expects CCNAs to

be prepared. The flows required to connect a client to a server, including the Get Nearest

Server (GNS) protocol, also are important when troubleshooting IPX problems. As

mentioned in the introduction and Chapter 1, “All About the Cisco Certified Network

Associate Certification,” Cisco definitely wants to reward CCNA candidates who have

good hands-on troubleshooting skills; knowledge of connection sequences for IPX and IP

is vital for being ready for any unexpected questions.

By taking the following steps, you can make better use of your study time:

•

Keep your notes and the answers for all your work with this book in one place, for

easy reference.

Chapter 6: Routing

•

Take the “Do I Know This Already?” quiz, and write down your answers. Studies show

that retention is significantly increased through writing down facts and concepts, even if

you never look at the information again.

•

Use the diagram in Figure 6-1 to guide you to the next step.

The purpose of the “Do I Know This Already?” quiz is to help you decide what parts of this

chapter to use. If you already intend to read the entire chapter, you do not necessarily need to

answer these questions now.

This 16-question quiz helps you choose how to spend your limited study time. The quiz is

sectioned into four smaller four-question “quizlets” that are used to help you select the sections

of the chapter on which to focus. Figure 6-1 outlines suggestions on how to spend your time in

this chapter. Use Table 6-1 to record your score.

“Do I Know This Already?” Quiz

Define what split horizon means to the contents of a routing update. Does this apply to

both the distance vector algorithm and the link-state algorithm?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Does IPX RIP use Split Horizon?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Describe the purpose and meaning of route poisoning.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Describe the meaning and purpose of triggered updates.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

1 Distance Vector Routing Protocols 1 to 4

2 Configuration of RIP and IGRP 5 to 8

3 IPX RIP, SAP, and GNS 9 to 12

4 Tunneling

Integrated Routing Protocols

13 to 16

All questions 1 to 16

Chapter 6: Routing

Write down the steps you would take to migrate from RIP to IGRP in a router whose

current RIP configuration includes only

, followed by a

command.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

How does the IOS designate a subnet in the routing table as a directly connected network?

What about a route learned with IGRP or a route learned with RIP?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

From a router’s user mode, without using debugs or privileged mode, how can you

determine what routers are sending you routing updates?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

If the command

followed by

, with no other

commands, was configured in a router that has an Ethernet0 interface with IP address

168.10.1.1, would RIP send updates out Ethernet0?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

Describe the metric(s) used by IPX RIP in a Cisco router.

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

What does GNS stand for? Who creates GNS requests, and who creates GNS replies?

__________________________________________________________________

__________________________________________________________________

__________________________________________________________________

“Do I Know This Already?” Quiz

If Serial0 has a

interface subcommand and Serial1 has a

interface subcommand, what metric will IPX RIP associate with each interface?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

What

commands list IPX RIP metric values in a Cisco router?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Define the term integrated multiprotocol routing in the context of the Cisco IOS and

Novell IPX.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

What routing protocols support integrated multiprotocol routing?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Identify two reasons for using tunneling.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

What tunneling transport protocol is used by the IOS?

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

Chapter 6: Routing

The answers to the “Do I Know This Already?” quiz are found in Appendix A, “Answers to the

‘Do I Know This Already?’ Quizzes and Q&A Sections,” on page 745. The suggested choices

for your next step are as follows:

•

—Read the entire chapter. This includes the “Foundation Topics”

and “Foundation Summary” sections, the Q&A section, and the scenarios at the end of the

chapter.

•

—Review the subsection(s) of the “Foundation Topics” part of

this chapter, based on Table 6-1. Then move into the “Foundation Summary” section, the

quiz, and the scenarios at the end of the chapter.

•

—Begin with the “Foundation Summary,” and then go to the Q&A

section and the scenarios at the end of the chapter.

•

—If you want more review on these topics, skip to the

“Foundation Summary,” and then go to the Q&A section and the scenarios at the end of

the chapter. Otherwise, move to the next chapter.

Distance Vector Routing Protocols

The CCNA exam requires that you be able to describe the logic behind distance vector routing

protocols, as well as describe the operation of two distance vector routing protocols, RIP and

IGRP. Configuration on a Cisco router is left until the next section.

Terminology relating to routing protocols is often misunderstood; this confusion is a direct

result of inconsistent use of terminology by authors. The terminology relating to routing

protocols and routing in this book is consistent with the courses in the Cisco CCNA training

path, as well as with most Cisco documentation. The first term that needs to be defined is

. This term can be contrasted with

. Chapter 3 provides a silly,

but I hope a memorable, story (the “Ted and Ting” story) that can help distinguish between the

first two terms. Three definitions follow:

•

A

fills the routing table with routing information. Examples include RIP

and IGRP.

•

A

is a protocol that has an OSI Layer 3 equivalent specification, which

defines logical addressing and routing. The packets defined by the network layer (Layer

3) portion of these protocols can be routed. Examples of protocols include IP and IPX.

•

The term

might appear on questions remaining from the older CCNA exam,

640-407. This term refers to the type of routing protocol—for instance, link-state.

IP routing protocols fill the IP routing table with valid, (hopefully) loop-free routes. (As you

will see later, distance vector routing protocols have many features that prevent loops, none of

which guarantees to prevent loops.) Each route includes a subnet number, the interface out

which to forward packets so that they are delivered to that subnet, and the IP address of the next

router that should receive packets destined for that subnet (if needed). An analogy to routing is

the process a stubborn man might use when taking a trip to somewhere he has never been. He

might look for a road sign referring to the destination town and pointing him to the next turn.

By repeating the process at each intersection, he should eventually make it to the correct town,

at last. Of course, if a routing loop occurs (in other words, he’s lost!) and he stubbornly never

asks for directions, he could loop forever—or at least until he’s out of gas!

Before discussing the underlying logic, the goals of a routing protocol should be considered.

The goals documented in the following list are common for any IP routing protocol, regardless

of its underlying logic type:

•

To dynamically learn and fill the routing table with a route to all subnets in the network.

•

If more than one route to a subnet is available, to place the best route in the routing table.

Chapter 6: Routing

•

To notice when routes in the table are no longer valid, and to remove those routes from the

routing table.

•

If a route is removed from the routing table and another route through another neighboring

router is available, to add the route to the routing table. (Many people view this goal and

the previous one as a single goal.)

•

To add new routes, or to replace lost routes with the best currently available route, as

quickly as possible. The time between losing the route and finding a working replacement

route is called

time.

•

To prevent routing loops.

Several routing protocols for TCP/IP exist. IP’s long history and continued popularity have

called for the specification and creation of several different competing options. So, classifying

IP routing protocols based on their differences is useful—and also is a fair topic for exam

questions.

One major classification of IP routing protocols is whether they are optimized for creating

routes inside one organization or routes between two or more interconnected organizations.

Exterior routing protocols are optimized for use between routers from different organizations.

Border Gateway Protocol (BGP) and Exterior Gateway Protocol (EGP) are the two options for

exterior routing protocols; BGP is the most popular and the more recently developed of the two.

(EGP is not technically a routing protocol but is a “reachability” protocol; it is obsolete.)

The CCNA exam focuses on interior routing protocols. If you are interested in pursuing CCIEISP,

CCIE-R/S, or CCNP certification, understanding exterior routing protocols is very

important. An excellent learning tool and reference to IP routing and routing protocols is the

Cisco Press book

, by Jeff Doyle.

is the term used to describe the programs and processes used to exchange and

learn routing information. Other documents call these same programs and processes

. Personally, I prefer the term

, yet a third term for the same

concept. Terminology counts; for the CCNA exam, remember all three terms.

One type of routing protocol is the

. Link-state protocols use a topological

database that is created on each router; entries describing each router, each router’s attached

links, and each router’s neighboring routers are included in the database. Each router builds a

complete map of the network. The topology database is processed by an algorithm called the

algorithm for choosing the best routes to add to the routing

table. This detailed topology information along with the Dijkstra algorithm helps link-state

protocols avoid loops and converge quickly.

Distance Vector Routing Protocols

A second type of routing protocol is the

. Balanced hybrid is a term

created by Cisco to describe the inner workings of EIGRP, which uses the Diffusing Update

Algorithm (DUAL) for calculating routes. A balanced hybrid protocol exchanges more

topology information than does a distance vector routing protocol, but it does not require full

topology and does not require the computationally intensive Dijkstra algorithm for computing

loop-free routes.

is the other type of routing protocol and will be discussed in much detail in the

next subsection.

Several different implementations of distance vector and link-state routing protocols could be

covered on the CCNA exam; only RIP Version 1 (RIP-1) and IGRP should be covered in-depth.

RIP-1 and IGRP are similar in most details, with the big exception being that IGRP uses a much

more robust metric. Both RIP-1 and IGRP are covered in more detail later in this chapter.

Some routing protocols are less likely to be covered on the CCNA exam, including RIP Version

2 (RIP-2). RIP-2 includes many improvements over RIP-1. Most notably, the subnet mask

associated with each advertised route is included in the routing update. The mask allows routers

to use features such as variable-length subnet masks (VLSMs) and route summarization, both

features sure to be covered on the CCNP exams.

Enhanced IGRP (EIGRP) is another balanced hybrid routing protocol, but it uses more

advanced features to avoid loops and speed convergence. (EIGRP is also unlikely to be covered

on the CCNA exam but is fair game for the CCNP.) The underlying algorithm is called the

DUAL defines a method for each router to not only

calculate the best current route to each subnet, but to also calculate alternative routes that could

be used if the current route fails. An alternate route, using what DUAL defines as a neighboring

, is guaranteed to be loop-free, so convergence can happen quickly.

EIGRP also transmits the subnet mask for each routing entry. Therefore, features such as VLSM

and route summarization are easily supported.

Open Shortest Path First (OSPF) is a link-state routing protocol used for IP. Link-state protocols

avoid routing loops by transmitting and keeping more detailed topology information, which

allows the protocol to use calculations that prevent loops. With OSPF, the subnet mask

information is also transmitted, allowing features such as VLSM and route summarization.

Table 6-2 lists interior IP routing protocols and their types. A column referring to whether the

routing protocol includes subnet mask information in the routing updates is listed for future

reference.

Chapter 6: Routing

CCNAs deal with routing problems on a daily basis; some of these problems are a result of the

logic behind distance vector routing protocols. To understand what distance vector routing

means is to understand how a routing protocol accomplishes the following goals:

The following list summarizes the behavior of a router that uses the RIP-1 or IGRP distance

vector routing protocols:

neighboring routers.

routers can learn routes via the single broadcast or multicast update.

if multiple routes to the same subnet are learned, the lower metric route is used.

information.

RIP-1 Distance vector Holddown timer, split

horizon

No

RIP-2 Distance vector Holddown timer, split

horizon

Yes

IGRP Distance vector Holddown timer, split

horizon

No

EIGRP Balanced hybrid DUAL and feasible

successors

Yes

OSPF Link-state Dijkstra SPF algorithm

and full topology

knowledge

Yes

interval. Failure to receive updates from a neighbor in a timely manner results in the

removal of the routes previously learned from that neighbor.

“infinite” distance. This route is considered unusable. Infinity is defined by each routing

protocol to be some very large metric value. For instance, RIP’s infinite metric is 16

because RIP’s maximum valid hop count is 15.

Figure 6-2 demonstrates how Router A’s directly connected subnets are advertised to Router B.

In this case, Router A advertises two directly connected routes.

162.11.5.0 S0 162.11.8.1

162.11.7.0 E0

162.11.8.0 S0

162.11.9.0 S0 162.11.8.1

The two directly connected routes on Router B do not have a Next Router field because packets

to those subnets can be sent directly to hosts in those subnets. The Next Router field for the

routes learned from Router A show Router A’s IP address as the next router, as described

previously. (A route learned from a neighboring router is assumed to be through that router.)

Router B typically learns Router A’s IP address for these routes by simply looking at the source

IP address of the routing update.

Metric values are cumulative. A subnet learned via an update from a neighbor is advertised, but

with a higher metric. For example, an update received on serial 1 lists a subnet with metric 5.

Before advertising that subnet in an update sent out some other interface, the router adds to the

metric, based on a value associated with serial 1. With RIP, because hop count is the metric, the

advertised metric would be 6, in this case. Figure 6-3 and Table 6-4 illustrate the concept.

162.11.5.0 S0 162.11.8.1

162.11.7.0 E0

162.11.8.0 S0

162.11.9.0 S0 162.11.8.1

162.11.10.0 S0 162.11.8.1

Figure 6-3 demonstrates the seven distance vector routing protocol behaviors previously listed,

with the exception of periodic updates and failed routes. The metric describing subnet

162.11.10.0, received from Router C, was incremented by 1 before advertising about that

subnet to Router B. This metric value represents hop count, which is used by RIP. (IGRP uses

a different metric, which will be discussed later.) The route to 162.11.10.0 that Router B adds

to its routing table refers to Router A as the next router because Router B learned the route from

Router A; Router B knows nothing about the network topology on the “other side” of Router A.

Distance vector routing protocols doubt the validity of routing information that they learned

from a neighboring router if that neighboring router quits sending routing updates. Periodic

routing updates are sent by each router. A routing update timer determines how often the

updates are sent. The timer should be equal on all routers, although the timers can be configured

for different values, causing unpredictable (and bad) results. The absence of routing updates for

a preset number of routing timer intervals results in the removal of the routes previously learned

from the router that has become silent.

Several issues exist related to loops and convergence required when using distance vector

routing protocols. Most of the issues with distance vector routing protocols arise when working

with networks with multiple paths because loops are very difficult when there is only one path

possible to get to a subnet. Table 6-5 summarizes these issues and lists the names of the

solutions, which are explained in the upcoming text.

Multiple routes to same subnet,

with equal metric

Implementation options involve either using the first route learned

or putting multiple routes to the same subnet in the routing table.

Routing loops occurring due to

updates passing each other over a

single link

interface only if they were not learned from updates entering that

interface.

advertises all routes out an interface, but those learned from

earlier updates coming in that interface are marked with infinite

distance metrics.

Routing loops occurring due to

updates passing each other over

alternate paths

advertised with an infinite distance metric.

failed, a router waits a certain period of time before believing any

other routing information about that subnet.

waiting on the update timer to expire when a route has failed.

Used in conjunction with route poisoning, this ensures that all

routers know of failed routes before any holddown timers can

expire.

Issues When Multiple Routes to the Same Subnet Exist

The first issue is straightforward and is described more easily with the example in Figure 6-4

and Tables 6-6 and 6-7.

in this example; other routes that would normally be in the routing update are omitted.

162.11.5.0 S0 162.11.8.1 1

162.11.7.0 E0 0

162.11.8.0 S0 0

162.11.9.0 S0 162.11.8.1 1

162.11.10.0 S0 162.11.8.1 2

Table 6-6 shows B’s routing table before B’s S1 interface came up; Table 6-7 shows B’s routing

table after S1 is up. One route was changed, one route was added, and one route that could have

been changed was not. The route to 162.11.10.0 was changed because the metric for the route

through Router C (metric 1) is smaller than the one from Router A (metric 2). The route to

directly connected subnet 162.11.6.0 was added, but not because of this distance vector routing

protocol; it was added by Router B because it is a directly connected subnet and because that

interface is now up. Finally, the route to subnet 162.11.9.0 is advertised with metric 1 by both

Routers A and C. In this case, the route that was already in the table is left in the table, which

is a reasonable choice. The choice of just placing one of the two equal metric routes in the table

is an implementation decision. Cisco routers can include up to six equal-cost routes in the

routing table instead of the choice shown in this example.

Split Horizon, Holddown, and Route Poisoning

Routing loops can occur when using distance vector routing protocols because bad routing

information can be propagated. Split horizon is the popular solution to the problem and works

very well in most topologies. Figure 6-5 shows an example of this problem.

in this example; other routes that would normally be in the routing update are omitted.

162.11.5.0 S0 162.11.8.1 1

162.11.6.0 S1 0

162.11.7.0 E0 0

162.11.8.0 S0 0

162.11.9.0 S0 162.11.8.1 1

162.11.10.0 S1 162.11.6.2 1

In Figure 6-5, the routing updates are sent periodically. There is no requirement to make the

updates flow from C and B at the same time; however, in this case, B and C are sending updates

at the same instant in time. This is not a problem until B advertises an infinite-distance (metric)

route to 162.11.7.0 because the subnet just failed. However, the update from C passes the update

from B on the serial link. Table 6-8 and Table 6-9 show the resulting routing table entries, with

a reference to the metric values.

162.11.6.0 S1 0

162.11.7.0 S1 2

162.11.10.0 S1 162.11.6.2 1

162.11.6.0 S1 0

162.11.7.0 S1 16

162.11.10.0 E0 1

infinite; IGRP uses a delay value of more than 4 billion to imply an infinite distance route.

Now Router C has an infinite distance route, but Router B will send packets to 162.11.7.0

through Router C. Router C claimed to have a metric 2 route to 162.11.7.0 at the same time that

Infinity is shown as the value 16 in Table 6-9, which is RIP’s value for infinity.) So, Router B

thinks 162.11.7.0 is reachable through Router C, and Router C thinks 162.11.7.0 is

unreachable. The process repeats itself with the next routing update, except Router B advertises

metric 3 and Router C advertises an infinite (bad) metric for subnet 162.11.7.0. This will

continue until both numbers reach infinity.

For those less patient, each distance vector routing protocol implementation sets a metric value

for which the number is considered to be infinite. For example, 16 is infinite for RIP, and

4,294,967,295 is infinite for IGRP.

Split horizon is the solution to the counting to infinity problem, in this case. Split horizon

includes two related concepts that affect what routes are included in a routing update:

same interface x.

For instance, in Figure 6-6, B’s route to subnet 162.11.10.0 points out Serial1, so its update sent

out Serial1 does not advertise that subnet. B’s update also does not include subnet 162.11.9.0,

presumably because B’s route to that subnet also points out Serial1. However, because B’s route

to 162.11.5.0 points out Serial0 to Router A, B advertises about that subnet out Serial1.

horizon. Instead of not advertising a route out the same interface in which the route was learned,

poison reverse means that the routes are advertised but with a poison (infinite) metric. In other

words, in Figure 6-6, Router B would also advertise routes to 162.11.6.0, 162.11.9.0, and

162.11.10.0, all with infinite metric.

infinity can occur in redundant networks (networks with multiple paths) even with split horizon

networks have multiple paths to many subnets. Split horizon does not defeat the counting to

infinity problem in all topologies. An additional solution is required, which includes a

holddown timer and a routing update feature called route poisoning. Figure 6-7 shows an

example topology showing counting to infinity.

For the scenario in Figure 6-7, subnet 162.11.10.0 fails; Router C sends updates to Router B

and Router A, as shown in Step 1 of Figure 6-7. Router A happens to send its next update out

its S1 interface to Router B just before it hears the bad news about 162.11.10.0 from Router C,

as denoted as Step 2 in Figure 6-7. Table 6-10 shows the result of these two updates entering

Router B.

Router B now thinks it has a valid route to 162.11.10.0, pointing back to Router A. On B’s next

update, the router does not advertise subnet 162.11.10.0 out S0 due to split horizon rules, but

Router B advertises 162.11.10.0 to Router C out Serial1. Router C incorrectly believes that the

route to 162.11.10.0 exists through Router B; Router C also tells Router A that it has a route to

162.11.10.0. So, counting to infinity occurs.

The solution is to enable a holddown timer. In the example in Figure 6-7, Router B’s original

route to 162.11.10.0 pointed to Router C. It was then changed to point to Router A. Holddown

would require Router B to wait for a period to learn new routes after an old one has failed, in

this case ignoring the metric 2 route learned from Router A.

information about that subnet for a time equal to the holddown timer.

With holddown enabled, Router B would not believe the metric 2 route learned in Step 1 of

Figure 6-7. During the same time, Routers C and A both would be advertising infinite metric

routes to 162.11.10.0 to Router B, which also would quickly be receiving only routing updates

for 162.11.10.0 with an infinite metric.

and typically does—define a maximum usable metric value, with any number over that being

considered infinite.)

162.11.5.0 S0 162.11.8.1 1

162.11.6.0 S1

162.11.7.0 E0

162.11.8.0 S0

162.11.9.0 S0 162.11.8.1 1

162.11.10.0 S0 162.11.8.1 2

is different than poison reverse—unfortunately, some well-known TCP/IP references have used

these terms in different ways, making things quite a mess. (The typical description in the Cisco

context follows.) When a distance vector routing protocol notices that a particular route is no

longer valid, it has two choices. One is simply to quit advertising about that subnet; the other is

to advertise that route, but with an infinite metric, signifying that the route is bad. Route

poisoning calls for the second of these options, which removes any ambiguity about whether

the route is still valid. For example, in Figure 6-7 again, a metric of 16 is used to signify infinity.

Router C is using route poisoning to ensure that Router A and Router B do not point routes for

162.11.10.0 back through Router C. (The examples in this chapter all used route poisoning—

in other words, the bad routes were advertised with an infinite metric.)

state, it immediately sends another routing update on its other interfaces rather than waiting on

the routing update timer to expire. This causes the information about the route whose status has

changed to be forwarded more quickly and starts the holddown timers more quickly as well on

the neighboring routers, as seen in Figure 6-8.

important to the description, so these other routes in the update are not listed.

Router C sends its update immediately after 162.11.10.0 fails. Routers A and B also react

immediately, sending updates to their neighbors. Because all the routers will ignore any new

information about this subnet for holddown time, fast propagation of the fact that the route

failed is not harmful. This mechanism quickly prevents packets from being unnecessarily

routed.

Table 6-11 contains a summary of the terms and concepts used by distance vector routing

protocols to help avoid loops and speed convergence.

RIP and IGRP

To pass the CCNA exam, you will need to know the particulars of how RIP and IGRP

implement distance vector logic. RIP and IGRP both use distance vector logic, so they are very

similar in many respects. A couple of major differences exist, however, and will be explained

in the upcoming text. Table 6-11 outlines the features of RIP and IGRP.

The metric with IGRP is more robust than RIP’s metric. The metric is calculated using the

bandwidth and delay settings on the interface on which the update was received. By using

bandwidth and delay, the metric is more meaningful; longer hop routes over faster links can be

considered better routes.

The metric used by IP RIP is hop count. When an update is received, the metric for each subnet

in the update signifies the number of routers between the router receiving the update and each

subnet. Before sending an update, a router increments its metric for routes to each subnet by 1.

In other words, a routing update includes metric values that tell the receiving router what its

metrics should be.

Finally, the issue of whether the mask is sent is particularly important if VLSMs in the same

network are desired. This topic is discussed in the upcoming section “Configuration of RIP and

IGRP.”

Update timer 30 seconds 90 seconds

Metric Hop count Function of bandwidth and

delay (default); can include

reliability, load, and MTU

Holddown timer 180 280

Flash (triggered) updates Yes Yes

Mask sent in update No for RIP v1; yes for RIP v2 No

Infinity metric value 16 4,294,967,295

Distance Vector Routing Protocol Summary

Distance vector routing protocols learn and advertise routes. The routes placed in the routing

table should be loop-free and should be the best known working route. Metrics are used to

choose the best route. Mechanisms such as split horizon and holddown timers are used to

prevent routing loops.

The CCNA exam requires you to understand RIP and IGRP configuration details. RIP and

IGRP configuration requires an understanding of two subtle nuances—namely, what the

than these two details, configuration is relatively easy.

Hands-on experience is the best way to fully learn the details of configuration. In lieu of that,

this section lists commands, provides examples, and points out any tricky features. Table 6-12

and Table 6-13 summarize the more popular commands used for RIP and IGRP configuration

and verification. Two configuration samples follow. The Cisco IOS documentation is an

instructor-led version of the class.

must understand the subtleties to what that really means (as explained in the next several

paragraphs.) However, what “enables” really means in this case is not obvious from Cisco IOS

people new to Cisco IOS configuration commands; therefore, routing protocol configuration,

Figure 6-9 and Example 6-1.

verify the current route to a host

Which of my interfaces have IP addresses in the same network number referenced in this

For any interfaces that have IP addresses in the same network number referenced in this

Example 6-1, network 10.0.0.0 is configured. Interfaces Ethernet0 and tokenring 0 will be

number or IP address. Furthermore, most routers will be attached to multiple subnets of that

same Class A, B, or C network. In many smaller networks, subnets of only a single network are

In Example 6-1, RIP broadcasts are sent out serial 0, ethernet 0, and tokenring 0. Likewise, RIP

updates entering those three interfaces alone are processed. Finally, each RIP update created by

this router advertises only directly connected subnets 10.1.2.0, 199.1.1.0, and 10.1.3.0, in

addition to any routes learned from other routers using RIP.

and ethernet 1. Seemingly, if no other routers are attached to that same Ethernet interface, then

there is no need to broadcast RIP/IGRP or listen for RIP/IGRP on the interface. However, three

the ethernet 1 and serial 1 interfaces, none of the RIP/IGRP updates from this router will

advertise about subnet 172.16.1.0 or network 199.1.2.0.

interface ethernet 0

ip address 10.1.2.3 255.255.255.0

interface ethernet 1

ip address 172.16.1.1 255.255.255.0

interface tokenring 0

ip address 10.1.3.3 255.255.255.0

interface serial 0

ip address 199.1.1.1 255.255.255.0

interface serial 1

ip address 199.1.2.1 255.255.255.0

!

router rip

network 10.0.0.0

network 199.1.1.0

The passive-interface Command

advertise about the connected subnet, but not to send RIP/IGRP updates on the interface. In

Example 6-2, a sample IGRP configuration causes the router to advertise about all connected

subnets, to listen on all interfaces for IGRP updates, and to advertise on all interfaces except

ethernet 1.

IGRP must use this same process-id, assuming that all routers want to exchange routing

information using IGRP.

interface ethernet 0

ip address 10.1.2.3 255.255.255.0

interface ethernet 1

ip address 172.16.1.1 255.255.255.0

interface tokenring 0

ip address 10.1.3.3 255.255.255.0

interface serial 0

ip address 199.1.1.1 255.255.255.0

interface serial 1

ip address 199.1.2.1 255.255.255.0

!

router igrp 1

network 10.0.0.0

network 199.1.1.0

network 199.1.2.0

network 172.16.0.0

passive-interface ethernet 1

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 3 subnets

C 10.1.2.0 is directly connected, TokenRing0

C 10.1.3.0 is directly connected, Ethernet0

I 10.1.4.0 [100/8539] via 10.1.2.14, 00:00:50, Ethernet0

172.16.0.0/24 is subnetted, 2 subnets

C 172.16.1.0 is directly connected, Ethernet1

I 172.16.2.0 [100/6244] via 172.16.1.44, 00:00:20, Ethernet1

C 199.1.1.0/24 is directly connected, Serial0

C 199.1.2.0/24 is directly connected, Serial1

IGRP uses a composite metric. This metric is calculated as a function of bandwidth, delay, load,

and reliability. By default, only the bandwidth and delay are considered; the other parameters

are considered only if enabled via configuration. Delay and bandwidth are not measured values

for calculating the metric for EIGRP, but with a scaling factor so that the actual metric values

are larger, allowing more granularity in the metric.)

example, the route to 10.1.4.0 shows the value [100/8539] beside the subnet number. The metric

8539 is a single value, as calculated based on bandwidth and delay. The metric is calculated (by

default) as the sum of the inverse of the minimum bandwidth, plus the cumulative delay on all

links in the route. In other words, the higher the bandwidth, the lower the metric; the lower the

cumulative delay, the lower the metric.

Split horizon and route poisoning were covered in the section “Distance Vector Routing

Protocols.” RIP and IGRP are distance vector routing protocols that implement split horizon

6-10 and Example 6-3 show a stable network with split horizon rules that affect the RIP

updates. Then Ethernet 0 on Yosemite is shut down, and Yosemite advertises an infinite distance

route to 10.1.2.0, as seen in Example 6-4.

interface ethernet 0

ip addr 10.1.1.251 255.255.255.0

interface serial 0

ip addr 10.1.4.251 255.255.255.0

interface serial 1

ip addr 10.1.6.251 255.255.255.0

!

router rip

network 10.0.0.0

_______________________________________________________________________

RIP: received v1 update from 10.1.6.253 on Serial1

10.1.3.0 in 1 hops

10.1.2.0 in 2 hops

10.1.5.0 in 1 hops

RIP: sending v1 update to 255.255.255.255 via Serial0 (10.1.4.251)

subnet 10.1.3.0, metric 2

subnet 10.1.1.0, metric 1

subnet 10.1.6.0, metric 1

RIP: sending v1 update to 255.255.255.255 via Serial1 (10.1.6.251)

subnet 10.1.2.0, metric 2

subnet 10.1.1.0, metric 1

subnet 10.1.4.0, metric 1

RIP: sending v1 update to 255.255.255.255 via Ethernet0 (10.1.1.251)

subnet 10.1.3.0, metric 2

subnet 10.1.2.0, metric 2

subnet 10.1.6.0, metric 1

subnet 10.1.5.0, metric 2

subnet 10.1.4.0, metric 1

RIP: received v1 update from 10.1.4.252 on Serial0

10.1.3.0 in 2 hops

10.1.2.0 in 1 hops

10.1.5.0 in 1 hops

Albuquerque#

(Yosemite E0 shutdown at this time...)

RIP: received v1 update from 10.1.4.252 on Serial0

10.1.3.0 in 2 hops

10.1.2.0 in 16 hops (inaccessible)

10.1.5.0 in 1 hops

RIP: sending v1 update to 255.255.255.255 via Serial0 (10.1.4.251)

subnet 10.1.3.0, metric 2

subnet 10.1.2.0, metric 16

subnet 10.1.1.0, metric 1

subnet 10.1.6.0, metric 1

RIP: sending v1 update to 255.255.255.255 via Serial1 (10.1.6.251)

subnet 10.1.2.0, metric 16

subnet 10.1.1.0, metric 1

subnet 10.1.4.0, metric 1

RIP: sending v1 update to 255.255.255.255 via Ethernet0 (10.1.1.251)

subnet 10.1.3.0, metric 2

You can see several interesting items in the configuration and debugs as highlighted in Example

6-3 and Example 6-4. RIP is enabled on all interfaces and on all routers in this example.

The RIP update sent out Albuquerque’s Ethernet0 interface advertises five routes but does

not advertise the route to 10.1.1.0 because that is the subnet of that attached Ethernet.

Albuquerque’s update sent on its Serial1 interface advertises only three routes due to split

horizon rules. Finally, notice the update received on Albuquerque, entering Serial0 (from

Yosemite) after Yosemite’s Ethernet0 interface has failed. Yosemite has described subnet

10.1.2.0 with a metric 16 route, which is considered infinite by RIP.

Example 6-5 shows the configuration added to each of the three routers in Figure 6-10 to

IGRP.

subnet 10.1.2.0, metric 16

subnet 10.1.6.0, metric 1

subnet 10.1.5.0, metric 2

subnet 10.1.4.0, metric 1

RIP: received v1 update from 10.1.6.253 on Serial1

10.1.3.0 in 1 hops

10.1.2.0 in 16 hops (inaccessible)

10.1.5.0 in 1 hops

interface ethernet 0

ip addr 10.1.2.252 255.255.255.0

interface serial 0

ip addr 10.1.4.252 255.255.255.0

interface serial 1

ip addr 10.1.5.252 255.255.255.0

router rip

network 10.0.0.0

(Note: The following commands would be used on all three routers.)

no router rip

router igrp 5

network 10.0.0.0

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 6 subnets

I 10.1.3.0 [100/8539] via 10.1.6.253, 00:00:28, Serial1

I 10.1.2.0 [100/8539] via 10.1.4.252, 00:00:18, Serial0

C 10.1.1.0 is directly connected, Ethernet0

C 10.1.6.0 is directly connected, Serial1

I 10.1.5.0 [100/10476] via 10.1.4.252, 00:00:18, Serial0

[100/10476] via 10.1.6.253, 00:00:29, Serial1

C 10.1.4.0 is directly connected, Serial0

IGRP protocol debugging is on

Albuquerque#

07:43:40: IGRP: sending update to 255.255.255.255 via Serial0 (10.1.4.251)

07:43:40: subnet 10.1.3.0, metric=8539

07:43:40: subnet 10.1.1.0, metric=688

07:43:40: subnet 10.1.6.0, metric=8476

07:43:40: IGRP: sending update to 255.255.255.255 via Serial1 (10.1.6.251)

07:43:40: subnet 10.1.2.0, metric=8539

07:43:40: subnet 10.1.1.0, metric=688

07:43:40: subnet 10.1.4.0, metric=8476

07:43:40: IGRP: sending update to 255.255.255.255 via Ethernet0 (10.1.1.251)

07:43:40: subnet 10.1.3.0, metric=8539

07:43:40: subnet 10.1.2.0, metric=8539

07:43:40: subnet 10.1.6.0, metric=8476

07:43:40: subnet 10.1.5.0, metric=10476

07:43:40: subnet 10.1.4.0, metric=8476

07:43:59: IGRP: received update from 10.1.6.253 on Serial1

07:43:59: subnet 10.1.3.0, metric 8539 (neighbor 688)

07:43:59: subnet 10.1.5.0, metric 10476 (neighbor 8476)

07:44:18: IGRP: received update from 10.1.4.252 on Serial0

07:44:18: subnet 10.1.2.0, metric 8539 (neighbor 688)

07:44:18: subnet 10.1.5.0, metric 10476 (neighbor 8476)

All possible debugging has been turned off

Albuquerque#

IGRP event debugging is on

Albuquerque#

07:45:00: IGRP: sending update to 255.255.255.255 via Serial0 (10.1.4.251)

07:45:00: IGRP: Update contains 3 interior, 0 system, and 0 exterior routes.

07:45:00: IGRP: Total routes in update: 3

07:45:00: IGRP: sending update to 255.255.255.255 via Serial1 (10.1.6.251)

07:45:00: IGRP: Update contains 3 interior, 0 system, and 0 exterior routes.

07:45:00: IGRP: Total routes in update: 3

07:45:00: IGRP: sending update to 255.255.255.255 via Ethernet0 (10.1.1.251)

07:45:01: IGRP: Update contains 5 interior, 0 system, and 0 exterior routes.

07:45:01: IGRP: Total routes in update: 5

07:45:21: IGRP: received update from 10.1.6.253 on Serial1

07:45:21: IGRP: Update contains 2 interior, 0 system, and 0 exterior routes.

07:45:21: IGRP: Total routes in update: 2

07:45:35: IGRP: received update from 10.1.4.252 on Serial0

The configuration at the beginning of Example 6-5 is used to migrate from RIP to IGRP. As

router. The three routers each must use the same IGRP process-id (5, in this case), and because

is needed.

used. The metrics, the second number inside the brackets, are different. In fact, notice the two

routes to 10.1.5.0/24—one through Yosemite and one through Seville. Both routes are included

see the equal cost routes being advertised. One route is seen in the update received on serial 1;

the other route in the update is received on serial 0.

protocol. The time remaining until the next routing update is to be sent is mentioned in one of

the first messages. Also, the time since an update was received from each neighboring router is

listed at the end of the output. Each of the neighbors from which routing information has been

received is listed as well. If you are in doubt as to whether updates have been received during

07:45:35: IGRP: Update contains 2 interior, 0 system, and 0 exterior routes.

07:45:35: IGRP: Total routes in update: 2

All possible debugging has been turned off

Routing Protocol is “igrp 5“

Sending updates every 90 seconds, next due in 34 seconds

Invalid after 270 seconds, hold down 280, flushed after 630

Outgoing update filter list for all interfaces is

Incoming update filter list for all interfaces is

Default networks flagged in outgoing updates

Default networks accepted from incoming updates

IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

IGRP maximum hopcount 100

IGRP maximum metric variance 1

Redistributing: igrp 5

Routing for Networks:

10.0.0.0

Routing Information Sources:

Gateway Distance Last Update

10.1.6.253 100 00:00:23

10.1.4.252 100 00:00:08

Distance: (default is 100)

output examples in this section. As a CCNA, Cisco expects you to be able to articulate the

implications of the missing mask to the function of the routing protocol. Several subtle actions

are taken in light of the lack of mask information in the update:

network X, contain the subnet numbers of the subnets of network X but not the

corresponding masks.

network Y, are summarized into one route about the entire network Y.

receiving router assumes that the mask in use is the same mask it uses on an interface with

an address in network X.

network X, it treats the route as a route to the entire Class A, B, or C network X.

Albuquerque, Yosemite, and Seville with the effects described in the preceding list. The

network of Figure 6-10 is still in use, but the subnet on Seville’s Ethernet has been changed

from 10.1.3.0/24 to 10.1.3.192/26. Because RIP-1 does not send the mask in the update, Seville

because the update would be ambiguous.

interface ethernet 0

ip addr 10.1.1.251 255.255.255.0

interface serial 0

ip addr 10.1.4.251 255.255.255.0

interface serial 1

ip addr 10.1.6.251 255.255.255.0

!

router rip

network 10.0.0.0

_______________________________________________________________________

RIP protocol debugging is on

Albuquerque#

00:38:23: RIP: received v1 update from 10.1.4.252 on Serial0

00:38:23: 10.1.2.0 in 1 hops

00:38:23: 10.1.5.0 in 1 hops

00:38:33: RIP: sending v1 update to 255.255.255.255 via Serial0 (10.1.4.251)

00:38:33: subnet 10.1.1.0, metric 1

00:38:33: subnet 10.1.6.0, metric 1

00:38:33: RIP: sending v1 update to 255.255.255.255 via Serial1 (10.1.6.251)

00:38:33: subnet 10.1.2.0, metric 2

00:38:33: subnet 10.1.1.0, metric 1

00:38:33: subnet 10.1.4.0, metric 1

00:38:33: RIP: sending v1 update to 255.255.255.255 via Ethernet0 (10.1.1.251)

00:38:33: subnet 10.1.2.0, metric 2

00:38:33: subnet 10.1.6.0, metric 1

00:38:33: subnet 10.1.5.0, metric 2

00:38:33: subnet 10.1.4.0, metric 1

00:38:40: RIP: received v1 update from 10.1.6.253 on Serial1

00:38:40: 10.1.2.0 in 2 hops

00:38:40: 10.1.5.0 in 1 hops

undebug all

All possible debugging has been turned off

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 5 subnets

R 10.1.2.0 [120/1] via 10.1.4.252, 00:00:26, Serial0

C 10.1.1.0 is directly connected, Ethernet0

C 10.1.6.0 is directly connected, Serial1

R 10.1.5.0 [120/1] via 10.1.4.252, 00:00:27, Serial0

[120/1] via 10.1.6.253, 00:00:10, Serial1

C 10.1.4.0 is directly connected, Serial0

Albuquerque#

(Suspended telnet resumed to Seville....)

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

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

R 10.1.2.0/24 [120/1] via 10.1.5.252, 00:00:19, Serial1

R 10.1.1.0/24 [120/1] via 10.1.6.251, 00:00:22, Serial0

C 10.1.6.0/24 is directly connected, Serial0

C 10.1.5.0/24 is directly connected, Serial1

R 10.1.4.0/24 [120/1] via 10.1.6.251, 00:00:22, Serial0

[120/1] via 10.1.5.252, 00:00:19, Serial1

C 10.1.3.192/26 is directly connected, Ethernet0

Seville#

As seen in the highlighted portions of Example 6-6, subnet 10.1.3.192/26 is not advertised by

output looks exactly like it would have earlier, when subnet 10.1.3.0/24 was used on Seville’s

Ethernet, if that Ethernet was down. However, in this case, the Ethernet is up, as shown in the

Yosemite would have believed there was a problem because the subnet number is 10.1.3.192,

which is not a subnet number with the mask that Albuquerque and Yosemite think is in use

(255.255.255.0). So, RIP and IGRP simply do not advertise the route into the same network on

an interface that uses a different mask. The use of different masks in parts of the same network

is called variable-length subnet masking (VLSM). As seen in this example, VLSM is not

supported by RIP (Version 1) or IGRP.

interface ethernet 0

ip addr 10.1.2.252 255.255.255.0

interface serial 0

ip addr 10.1.4.252 255.255.255.0

interface serial 1

ip address 10.1.2.252 255.255.255.0

router rip

network 10.0.0.0

interface ethernet 0

ip addr 10.1.3.253 255.255.255.192

interface serial 0

ip addr 10.1.6.253 255.255.255.0

interface serial 1

ip address 10.1.5.253 255.255.255.0

!

router rip

network 10.0.0.0

RIP Version 2, defined by RFC 1723, is simply an improved version of RIP Version 1. Many

features are the same: Hop count is still used for the metric, it is still a distance vector protocol,

and it still uses holddown timers and route poisoning. Several features have been added, as

listed in Table 6-14.

Although all features of RIP-2 are important, certainly the one that allows RIP to continue to

be a valid option in modern networks is the support of VLSM by including the subnet mask.

For instance, the problem with RIP-1 and IGRP shown in Examples 6-6, 6-7, and 6-8 was

caused by the lack of this feature. With RIP-2, the problem is removed. The same network

diagram (Figure 6-10) is used in this case. Example 6-9 shows the RIP-2 configuration on each

Transmits subnet mask with route This feature allows VLSM by passing the mask along with each

route so that the subnet is exactly defined.

Provides authentication Both clear text (RFC-defined) and MD5 encryption (Ciscoadded

feature) can be used to authenticate the source of a

routing update.

Includes a next-hop router IP

address in its routing update

A router can advertise a route but direct any listeners to a

different router on that same subnet. This is done only when the

other router has a better route.

Uses external route tags RIP can pass information about routes learned from an external

source and redistributed into RIP.

Provides multicast routing updates Instead of sending updates to 255.255.255.255, the destination

IP address is 224.0.0.9, an IP multicast address. This reduces

the amount of processing required on non-RIP-speaking hosts

on a common subnet.

router rip

network 10.0.0.0

version 2

Albuquerque#

debug ip rip

RIP protocol debugging is on

Albuquerque#

00:36:04: RIP: received v2 update from 10.1.4.252 on Serial0

00:36:04: 10.1.2.0/24 -> 0.0.0.0 in 1 hops

00:36:04: 10.1.5.0/24 -> 0.0.0.0 in 1 hops

the specific portions of the examples referred to in the text after the example are highlighted.)

The updates sent by Albuquerque are sent to multicast IP address 224.0.0.9, as opposed to a

broadcast address; this allows the devices that are not using RIP-2 to ignore the updates and not

00:36:04: 10.1.3.192/26 -> 0.0.0.0 in 2 hops

00:36:08: RIP: sending v2 update to 224.0.0.9 via Serial0 (10.1.4.251)

00:36:08: 10.1.1.0/24 -> 0.0.0.0, metric 1, tag 0

00:36:08: 10.1.6.0/24 -> 0.0.0.0, metric 1, tag 0

00:36:08: 10.1.3.192/26 -> 0.0.0.0, metric 2, tag 0

00:36:08: RIP: sending v2 update to 224.0.0.9 via Serial1 (10.1.6.251)

00:36:08: 10.1.2.0/24 -> 0.0.0.0, metric 2, tag 0

00:36:08: 10.1.1.0/24 -> 0.0.0.0, metric 1, tag 0

00:36:08: 10.1.4.0/24 -> 0.0.0.0, metric 1, tag 0

00:36:08: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (10.1.1.251)

00:36:08: 10.1.2.0/24 -> 0.0.0.0, metric 2, tag 0

00:36:08: 10.1.6.0/24 -> 0.0.0.0, metric 1, tag 0

00:36:08: 10.1.5.0/24 -> 0.0.0.0, metric 2, tag 0

00:36:08: 10.1.4.0/24 -> 0.0.0.0, metric 1, tag 0

00:36:08: 10.1.3.192/26 -> 0.0.0.0, metric 2, tag 0

00:36:20: RIP: received v2 update from 10.1.6.253 on Serial1

00:36:20: 10.1.2.0/24 -> 0.0.0.0 in 2 hops

00:36:20: 10.1.5.0/24 -> 0.0.0.0 in 1 hops

00:36:20: 10.1.3.192/26 -> 0.0.0.0 in 1 hops

00:36:30: RIP: received v2 update from 10.1.4.252 on Serial0

00:36:30: 10.1.2.0/24 -> 0.0.0.0 in 1 hops

00:36:30: 10.1.5.0/24 -> 0.0.0.0 in 1 hops

00:36:30: 10.1.3.192/26 -> 0.0.0.0 in 2 hops

All possible debugging has been turned off

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

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

R 10.1.2.0/24 [120/1] via 10.1.4.252, 00:00:09, Serial0

C 10.1.1.0/24 is directly connected, Ethernet0

C 10.1.6.0/24 is directly connected, Serial1

R 10.1.5.0/24 [120/1] via 10.1.4.252, 00:00:09, Serial0

[120/1] via 10.1.6.253, 00:00:19, Serial1

C 10.1.4.0/24 is directly connected, Serial0

R 10.1.3.192/26 [120/1] via 10.1.6.253, 00:00:19, Serial1

Albuquerque#

Albuquerque from Seville (10.1.6.253). The subnet masks are shown in the prefix style, with

means that all the external route tags have value 0, which is the default.

Migration from RIP-1 to RIP-2 requires some planning. RIP-1 sends updates to the broadcast

address, whereas RIP-2 uses a multicast. A RIP-1 only router and a RIP-2 only router will not

succeed in exchanging routing information. To migrate to RIP-2, one option is to migrate all

routers at the same time. This might not be a reasonable political or administrative option,

however. If not, then some coexistence between RIP-1 and RIP-2 is required.

configuration tells the router whether to send RIP-1 style updates, RIP-2 style updates, or both

for each interface. Consider the familiar Figure 6-10 network, with RIP-1 still configured on all

three routers. If two of the routers are migrated—for instance, Albuquerque and Seville—then

they can communicate with RIP-2 easily. However, by default these two routers will now send

only RIP-2 updates, which Yosemite cannot understand because it is still running RIP-1. The

configurations in Examples 6-11, 6-12, and 6-13 overcome the problem by having Albuquerque

and Seville send only RIP-1 updates to Yosemite.

interface ethernet 0

ip addr 10.1.1.251 255.255.255.0

interface serial 0

ip addr 10.1.4.251 255.255.255.0

ip rip send version 1

ip rip receive version 1

interface serial 1

ip address 10.1.6.251 255.255.255.0

!

router rip

network 10.0.0.0

version 2

interface ethernet 0

ip addr 10.1.2.252 255.255.255.0

interface serial 0

ip addr 10.1.4.252 255.255.255.0

interface serial 1

ip address 10.1.5.252 255.255.255.0

!

router rip

network 10.0.0.0

As seen in the highlighted lines of the example, with RIP-2 configured, RIP-2 updates are sent

send and receive only RIP-1 updates, the other two routers need the appropriate interface

subcommands to tell the router to send and receive RIP-1 updates to and from Yosemite. Both

Albuquerque and Seville will continue to send and (hope to) receive RIP-2 updates on all

interfaces.

The IOS is optimized to perform routing as fast as possible. Most of the Layer 3 routing

performance improvement in the brief history of routers has been through improved algorithms;

many times those improved algorithms later have been implemented in hardware to provide

additional latency improvements. Although these improvements have been a great benefit, it is

typically true that any algorithm that searches a list will run more quickly if the list is short,

compared to searching a similar list that is long. Auto summary and route aggregation (also

known as route summarization) are two IOS features that reduce the size of the IP routing table.

Auto summarization is a routing protocol feature that operates by this rule:

When advertised on an interface whose IP address is not in network X, routes about

subnets in network X will be summarized and advertised as one route. That route will be

for the entire Class A, B, or C network X.

Auto summary is a feature of RIP-1 and IGRP that cannot be disabled. For RIP-2 and EIGRP,

auto summary can be enabled or disabled. As usual, an example makes the concept much

clearer. Consider Figure 6-11, which shows two networks in use: 10.0.0.0 and 172.16.0.0.

Seville has four (connected) routes to subnets of network 10.0.0.0. Example 6-14 lists the

interface ethernet 0

ip addr 10.1.2.252 255.255.255.0

interface serial 0

ip addr 10.1.4.252 255.255.255.0

interface serial 1

ip address 10.1.5.252 255.255.255.0

ip rip send version 1

ip rip receive version 1

!

router rip

network 10.0.0.0

version 2

Notice as highlighted in Example 6-14 that Albuquerque’s received update on Serial0.2 from

Seville advertises only about the entire Class A network 10.0.0.0/8 because auto summary is

enabled on Seville (by default). The IP routing table lists just one route to network 10.0.0.0.

This works fine, as long as network 10.0.0.0 is contiguous. Consider Figure 6-12, where

02:20:42: RIP: sending v2 update to 224.0.0.9 via Serial0.2 (172.16.1.251)

02:20:42: 172.16.2.0/24 -> 0.0.0.0, metric 1, tag 0

02:20:42: RIP: sending v2 update to 224.0.0.9 via Ethernet0 (172.16.2.251)

02:20:42: 172.16.1.0/24 -> 0.0.0.0, metric 1, tag 0

02:20:42: 10.0.0.0/8 -> 0.0.0.0, metric 2, tag 0

02:20:46: RIP: received v2 update from 172.16.1.253 on Serial0.2

02:20:46: 10.0.0.0/8 -> 0.0.0.0 in 1 hops

Albuquerque#

All possible debugging has been turned off

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets

C 172.16.1.0 is directly connected, Serial0.2

C 172.16.2.0 is directly connected, Ethernet0

R 10.0.0.0/8 [120/1] via 172.16.1.253, 00:00:09, Serial0.2

Yosemite also has subnets of network 10.0.0.0 but has no connectivity to Seville other than

through Albuquerque.

is a single Class A, B, or C network for which all routes to subnets of that network pass through

that, in a single Class A, B, or C network, there is at least one case in which the only routes to

one subnet pass through subnets of a different network. An easy analogy for residents in the

Hawaii. To drive to Alaska from the contiguous 48, for example, you must drive through another

country (Canada, for the geographically impaired!), so Alaska is not contiguous with the 48

states—in other words, it is discontiguous.

Figure 6-12 breaks that rule. In this figure, there could be a PVC between Yosemite and Seville

that uses a subnet of network 10.0.0.0, but that PVC may be down, causing the discontiguous

network. The temporarily discontiguous network can be overcome with the use of a routing

protocol that transmits masks because the rule of discontiguous subnets can be ignored when

using a routing protocol that transmits masks. Consider the routing updates and routing table

on Albuquerque in Example 6-15, where auto summarization is disabled on all routers.

debug ip rip

RIP protocol debugging is on

Albuquerque#

02:48:58: RIP: received v2 update from 172.16.1.253 on Serial0.2

02:48:58: 10.1.7.0/24 -> 0.0.0.0 in 1 hops

02:48:58: 10.1.6.0/24 -> 0.0.0.0 in 1 hops

02:48:58: 10.1.5.0/24 -> 0.0.0.0 in 1 hops

02:48:58: 10.1.4.0/24 -> 0.0.0.0 in 1 hops

Notice as highlighted in Example 6-15 that the routing updates include the individual subnets.

Therefore, Albuquerque can see routes to all subnets of network 10 and can route packets to the

correct destinations in Seville and Yosemite. With auto summary enabled, Albuquerque would

think that both Seville and Yosemite had an equal-metric route to network 10.0.0.0; some

packets would be routed incorrectly.

02:49:14: RIP: received v2 update from 172.16.3.252 on Serial0.1

02:49:14: 10.1.11.0/24 -> 0.0.0.0 in 1 hops

02:49:14: 10.1.10.0/24 -> 0.0.0.0 in 1 hops

02:49:14: 10.1.9.0/24 -> 0.0.0.0 in 1 hops

02:49:14: 10.1.8.0/24 -> 0.0.0.0 in 1 hops

02:49:16: RIP: sending v2 update to 224.0.0.9 via Serial0.1 (172.16.3.251)

02:49:16: 172.16.1.0/24 -> 0.0.0.0, metric 1, tag 0

02:49:16: 172.16.2.0/24 -> 0.0.0.0, metric 1, tag 0

02:49:16: 10.0.0.0/8 -> 0.0.0.0, metric 2, tag 0

02:49:16: RIP: sending v2 update to 224.0.0.9 via Serial0.2 (172.16.1.251)

02:49:16: 172.16.2.0/24 -> 0.0.0.0, metric 1, tag 0

02:49:16: 172.16.3.0/24 -> 0.0.0.0, metric 1, tag 0

02:49:16: 10.0.0.0/8 -> 0.0.0.0, metric 2, tag 0

02:49:16: RIP: sending v2 update to 224.0.0.9 via Ethernet 0 (172.16.2.251)

02:49:16: 172.16.1.0/24 -> 0.0.0.0, metric 1, tag 0

02:49:16: 172.16.3.0/24 -> 0.0.0.0, metric 1, tag 0

02:49:16: 10.0.0.0/8 -> 0.0.0.0, metric 2, tag 0

All possible debugging has been turned off

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 3 subnets

C 172.16.1.0 is directly connected, Serial0.2

C 172.16.2.0 is directly connected, Ethernet0

C 172.16.3.0 is directly connected, Serial0.1

10.0.0.0/24 is subnetted, 8 subnets

R 10.1.11.0 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

R 10.1.10.0 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

R 10.1.9.0 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

R 10.1.8.0 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

R 10.1.7.0 [120/1] via 172.16.1.253, 00:00:03, Serial0.2

R 10.1.6.0 [120/1] via 172.16.1.253, 00:00:03, Serial0.2

R 10.1.5.0 [120/1] via 172.16.1.253, 00:00:03, Serial0.2

R 10.1.4.0 [120/1] via 172.16.1.253, 00:00:03, Serial0.2

Albuquerque#

Route summarization (also called route aggregation) works like auto summarization, except

that there is no requirement to summarize into a Class A, B, or C network. Consider the same

network in Figure 6-12. Albuquerque has eight routes to subnets of network 10.0.0.0; four of

those routes are learned from Seville. Consider the subnet, broadcast, and assignable addresses

in each of the subnets, as shown in Table 6-15.

Now consider the concept of a subnet 10.1.4.0, with mask 255.255.252.0. In this case,

10.1.4.0/22 (same subnet, written differently) would have a subnet broadcast address of

10.1.7.255 and assignable addresses of 10.1.4.1 to 10.1.7.254. Because 10.1.4.0/22 happens to

include all the assignable addresses of the original four subnets, a single route to 10.1.4.0/22

would be just as good as the four separate routes, assuming that the next-hop information

would be the same for each of the original four routes.

Route aggregation is simply a tool used to tell a routing protocol to advertise a single, larger

subnet rather than the individual smaller subnets. In this case, the routing protocol would

advertise 10.1.4.0/22 rather than the four individual subnets. Albuquerque’s routing table will

then be smaller. EIGRP and OSPF are the only interior IP routing protocols to support route

aggregation.

Route summarization of the subnets off Seville is shown in Example 6-16. Still using the

network of Figure 6-12, the routers are all migrated to EIGRP. Example 6-16 shows the EIGRP

configuration on Albuquerque, EIGRP configuration on Seville, and the resulting IP routing

table on Albuquerque. (Yosemite is migrated to EIGRP as well; the configuration is not shown

because the example shows only aggregation by Seville.)

10.1.4.0 255.255.255.0 10.1.4.255 10.1.4.1 to 10.1.4.254

10.1.5.0 255.255.255.0 10.1.5.255 10.1.5.1 to 10.1.5.254

10.1.6.0 255.255.255.0 10.1.6.255 10.1.6.1 to 10.1.6.254

10.1.7.0 255.255.255.0 10.1.7.255 10.1.7.1 to 10.1.7.254

On Seville:

Router eigrp 9

Network 10.0.0.0

Network 172.16.0.0

No auto-summary

!

interface serial 0.1 point-to-point

ip address 172.16.1.253 255.255.255.0

frame-relay interface-dlci 901

define the superset of the subnets that should be advertised. Notice the route in Albuquerque’s

routing table, which indeed shows 10.1.4.0/22, rather than the four individual subnets.

When summarizing, the superset of the original subnets could actually be smaller than the

Class A, B, or C network; larger than the network; or exactly matched to a network. For

instance, 192.168.4.0, 192.168.5.0, 192.168.6.0, and 192.168.7.0 could be summarized into

192.168.4.0/22, which represents four consecutive Class C networks. Summarization when the

Table 6-16 lists the features for summarization of the interior IP routing protocols.

ip summary-address eigrp 9 10.1.4.0 255.255.252.0

On Albuquerque:

Router eigrp 9

Network 172.16.0.0

No auto-summary

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 3 subnets

C 172.16.1.0 is directly connected, Serial0.2

C 172.16.2.0 is directly connected, Ethenet0

C 172.16.3.0 is directly connected, Serial0.1

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

D 10.1.11.0/24 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

D 10.1.10.0/24 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

D 10.1.9.0/24 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

D 10.1.8.0/24 [120/1] via 172.16.3.252, 00:00:15, Serial0.1

D 10.1.4.0/22 [90/2185984] via 172.16.1.253, 00:00:58, Serial0.2

RIP Version 1 Yes, by default Not allowed No

IGRP Yes, by default Not allowed No

RIP Version 2 Yes, by default Allowed via

configuration

No

By default, the IOS supports four equal-cost routes to the same IP subnet in the routing table at

As mentioned earlier, the packets are balanced on a per-destination address basis by default;

packets also can be balanced on a packet-by-packet basis, but at a performance penalty.

The metric formula used for IGRP (and EIGRP) poses an interesting problem when considering

equal-metric routes. IGRP can learn more than one route to the same subnet, with different

subcommand is used to define how variable the metrics can be for routes to be considered to

have equal metrics. The parameter to the command (the multiplier) is multiplied by the lowest

of the received metrics for a particular subnet. Any routes with a metric less than the product of

“best metric” times the multiplier are considered to be equal.

Some rather interesting twists in logic must be considered when deciding whether to use one or

equal-cost routes learned to each subnet is placed into the routing table. However, these could

how close the metrics must be in value to be considered equal. However, in that case, some of

the traffic will flow over the routes with the best metric, and some will flow over the route with

the worst metric. Neither situation seems to be optimal.

router to add the multiple routes to the routing table, but to send only traffic using the route with

the smallest metric. This allows all routes to each subnet to be in the routing table, which is an

advantage for faster convergence. However, all traffic goes across the lowest-metric route that

tells the router to use all the routes proportionally based on the metrics for each route.

Enhanced IGRP Yes, by default Allowed via

configuration

Yes

OSPF No, but can do

equivalent with

aggregation

Yes Yes

It is no secret that Cisco would very much like all its certification exams—CCNA included—

to be exams that prove that the test taker can build and troubleshoot live networks. Some people

work with Cisco routers daily. Others’ current job function does not allow frequent access to

routers—if this applies to you, you likely are trying to pass this certification so that you can

move into jobs that involve routers and switches.

information when troubleshooting a routing problem. With a small network, most of the options

can do will be very useful for your work with larger networks.

the options. The network is shown in Figure 6-13 and should look familiar from previous

examples. In this case, Enhanced IGRP is used between Albuquerque and Seville, and RIP-2 is

used between Albuquerque and Yosemite. There is no PVC between Yosemite and Seville. The

configurations of the three routers are listed in Examples 6-17, 6-18, and 6-19 first, followed by

Building configuration...

Current configuration:

!

version 12.0

!

hostname Albuquerque

!

no ip domain-lookup

!

interface Serial0

no ip address

no ip directed-broadcast

encapsulation frame-relay IETF

clockrate 56000

frame-relay lmi-type cisco

!

interface Serial0.1 point-to-point

ip address 172.16.3.251 255.255.255.0

no ip directed-broadcast

frame-relay interface-dlci 902

!

interface Serial0.2 point-to-point

ip address 172.16.1.251 255.255.255.0

no ip directed-broadcast

frame-relay interface-dlci 903

!

interface Serial1

no ip address

no ip directed-broadcast

shutdown

!

interface Ethernet0

ip address 172.16.2.251 255.255.255.0

no ip directed-broadcast

!

router eigrp 9

passive-interface Serial0.1

network 172.16.0.0

no auto-summary

!

router rip

version 2

passive-interface Serial0.2

network 172.16.0.0

no auto-summary

!

no ip classless

!

access-list 1 permit 10.0.0.0 0.255.255.255

Building configuration...

Current configuration:

!

version 12.0

!

hostname Yosemite

!

no ip domain-lookup

!

interface Serial0

no ip address

no ip directed-broadcast

encapsulation frame-relay IETF

no fair-queue

frame-relay lmi-type cisco

!

interface Serial0.1 point-to-point

ip address 172.16.3.252 255.255.255.0

no ip directed-broadcast

frame-relay interface-dlci 901

!

interface Serial1

no ip address

no ip directed-broadcast

shutdown

!

!

interface Ethernet0

ip address 10.1.8.253 255.255.255.0

!

interface Ethernet1

ip address 10.1.9.253 255.255.255.0

!

interface Ethernet2

ip address 10.1.10.253 255.255.255.0

!

interface Ethernet3

ip address 10.1.11.253 255.255.255.0

!

router rip

version 2

network 10.0.0.0

network 172.16.0.0

no auto-summary

!

no ip classless

Building configuration...

Current configuration:

!

version 12.0

!

hostname Seville

!

no ip domain-lookup

!

interface Serial0

no ip address

no ip directed-broadcast

encapsulation frame-relay IETF

no fair-queue

frame-relay lmi-type cisco

!

interface Serial0.1 multipoint

ip address 172.16.1.253 255.255.255.0

no ip directed-broadcast

ip summary-address eigrp 9 10.1.4.0 255.255.252.0

frame-relay interface-dlci 901

!

interface Serial1

no ip address

no ip directed-broadcast

shutdown

!

interface Ethernet0

ip address 10.1.4.253 255.255.255.0

!

interface Ethernet1

ip address 10.1.5.253 255.255.255.0

!

interface Ethernet2

ip address 10.1.6.253 255.255.255.0

!

interface Ethernet3

ip address 10.1.7.253 255.255.255.0

!

router eigrp 9

network 10.0.0.0

network 172.16.0.0

no auto-summary

!

no ip classless

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 3 subnets

C 172.16.1.0 is directly connected, Serial0.2

C 172.16.2.0 is directly connected, Ethernet0

C 172.16.3.0 is directly connected, Serial0.1

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

R 10.1.11.0/24 [120/1] via 172.16.3.252, 00:00:17, Serial0.1

R 10.1.10.0/24 [120/1] via 172.16.3.252, 00:00:17, Serial0.1

R 10.1.9.0/24 [120/1] via 172.16.3.252, 00:00:17, Serial0.1

R 10.1.8.0/24 [120/1] via 172.16.3.252, 00:00:17, Serial0.1

D 10.1.4.0/22 [90/2185984] via 172.16.1.253, 00:28:01, Serial0.2

Hostname or A.B.C.D Network to display information about or hostname

bgp Border Gateway Protocol (BGP)

connected Connected

egp Exterior Gateway Protocol (EGP)

eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)

igrp Interior Gateway Routing Protocol (IGRP)

isis ISO IS-IS

list IP Access list

odr On Demand stub Routes

ospf Open Shortest Path First (OSPF)

profile IP routing table profile

rip Routing Information Protocol (RIP)

static Static routes

summary Summary of all routes

supernets-only Show supernet entries only

traffic-engineering Traffic engineered routes

<cr>

Routing entry for 10.1.4.0/22

Known via “eigrp 9“, distance 90, metric 2185984, type internal

Redistributing via eigrp 9

Last update from 172.16.1.253 on Serial0.2, 00:28:36 ago

Routing Descriptor Blocks:

* 172.16.1.253, from 172.16.1.253, 00:28:36 ago, via Serial0.2

Route metric is 2185984, traffic share count is 1

Total delay is 20630 microseconds, minimum bandwidth is 1544 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

of some of the more important bits of the output is in order; most comments refer to a

highlighted portion of an example. First, the legend at the beginning of Example 6-20 defines

the letter codes that identify the source of the routing information—for instance, C for

connected routes, R for RIP, and I for IGRP. Each of the Class A, B, and C networks is listed,

along with each of the subnets of that network. If a static mask is used within that network, then

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

R 10.1.11.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

R 10.1.10.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

R 10.1.9.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

R 10.1.8.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

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

D 10.1.4.0/22 [90/2185984] via 172.16.1.253, 00:29:42, Serial0.2

172.16.0.0/24 is subnetted, 3 subnets

C 172.16.1.0 is directly connected, Serial0.2

C 172.16.2.0 is directly connected, Ethernet0

C 172.16.3.0 is directly connected, Serial0.1

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

R 10.1.11.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

R 10.1.10.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

R 10.1.9.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

R 10.1.8.0/24 [120/1] via 172.16.3.252, 00:00:22, Serial0.1

D 10.1.4.0/22 [90/2185984] via 172.16.1.253, 00:29:58, Serial0.2

Route Source Networks Subnets Overhead Memory (bytes)

connected 0 3 156 420

static 0 0 0 0

rip 0 4 208 560

eigrp 9 0 1 52 140

internal 2 2320

Total 2 8 416 3440

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

the mask is shown only in the line referring to the network (as is the case in Example 6-20,

network 172.16.0.0). If the network uses VLSM, as network 10.0.0.0 appears to do because of

the route summarization done by Seville, then the mask information is listed on the lines

referring to each of the individual subnets.

Each routing entry lists the subnet number and the outgoing interface. In most cases, the nexthop

router’s IP address is also listed. The outgoing interface is needed so that the router can

choose the type of data link header to use to encapsulate the packet before transmission on that

interface. The next-hop router’s IP address is needed on interfaces for which the router needs

the IP address so that it can find the associated data link address to put in the newly built data

link header. For instance, knowing the next-hop IP address of 172.16.3.252, Yosemite’s IP

address on the Frame Relay VC allows Albuquerque to find the correlated DLCI in the Frame

Relay map.

number in brackets represents the metric value for this route. The first number defines the

administrative distance.

Administrative distance is important only if multiple IP routing protocols are in use in a single

router. When this is true, both routing protocols can learn routes to the same subnets. Because

their metric values are different (for example, hop count or a function of bandwidth and delay),

there is no way to know which routing protocol’s routes are better. So, Cisco supplies a method

of defining which routing protocol’s routes are better. The IOS implements this concept using

Administrative distance is an integer value; a value is assigned to each source of routing

information. The lower the administrative distance, the better the source of routing information.

IGRP’s default is 100, OSPF’s is 110, RIP’s is 120, and Enhanced IGRP’s is 90. The value 100

routes is 100—in other words, the default value is in use. So, if RIP and IGRP are both used,

and if both learn routes to the same subnets, only IGRP’s routing information for those subnets

will be added to the routing table. If RIP learns about a subnet that IGRP does not know about,

that route will be added to the routing table.

to the routes learned by a particular routing protocol can be accomplished by referring to that

routing protocol. Likewise, the output can be limited to just show connected routes.

address as the last parameter. This tells the router to perform routing table lookup, just as it

a set of messages, the first of which identifies the route to 10.1.4.0/22 as the route matched in

the routing table. The route that is matched is listed so that you can always know the route that

would be used by this router to reach a particular IP address.

6-20. Access list 1 is configured so that any route about network 10.0.0.0 is matched (permitted

output will be filtered, showing only a portion of the routes. This is particularly useful when

there are many routes in the routing table.

troubleshooting in larger networks.

The CCNA exam requires you not only to know the differences between IPX RIP and IP RIP,

but to also know two other NetWare protocols used by the router: Service Advertisement

Protocol (SAP) and Get Nearest Server (GNS). Because IPX RIP and IP RIP were originally

based on the same protocol (XNS RIP), the two are very similar. SAP and GNS have no

equivalent feature in TCP/IP. RIP for IPX works in a similar manner to IP RIP. The most

obvious difference is that IPX RIP advertises IPX network numbers, not IP subnet numbers.

Table 6-17 lists the similarities and differences.

IPX RIP uses two metrics: ticks and hops. Ticks are 1/18 of 1 second; the metric is an integer

counter of the number of ticks delay for this route. By default, a Cisco router treats a link as

having a certain number of ticks delay. LAN interfaces default to one tick and WAN interfaces

default to six ticks. The number of hops is considered only when the number of ticks is a tie.

By using ticks as the primary metric, better routes can be chosen instead of just using hop count.

For example, a three-hop, three-tick route that uses three Ethernets will be chosen over a twohop,

eight-tick route that uses two Ethernets and a serial link.

Service Advertisement Protocol (SAP) is one of the more important parts of the NetWare

protocol specification, but it is also one of the biggest challenges when trying to scale an IPX

Uses distance vector Uses distance vector

Is based on XNS RIP Is based on XNS RIP

Uses 60-second update timer (default) Uses 30-second update timer (default)

Uses timer ticks as primary metric, hop count as

secondary metric

Uses hop count as only metric

network. SAP is used by servers to propagate information that describes their services. CCNAs

are expected to be very familiar with SAP and the routers’ roles in forwarding SAP information.

The SAP process works very much like the process used by a distance vector routing protocol.

In fact, SAP uses a concept similar to split horizon to stop a node from advertising SAP

information it learned on an interface with updates sent out that same interface. Each server

sends SAP updates by default every 60 seconds that include the IPX address, server name, and

service type. Every other server and router listens for these updates but does not forward the

SAP packet(s). Instead, the SAP information is added to a SAP table in the server or router; then

the packets are discarded. When that router or server’s SAP timer expires, new SAP broadcasts

are sent. As with IPX RIP for routing information, IPX SAP propagates service information

until all servers and routers have learned about all servers.

Client initialization flows provide some insight into why routers need to learn SAP information.

Consider Figure 6-14, which includes the use of the Get Nearest Server (GNS) request and

shows a typical startup with a client configured with a preferred server of Server 2.

The overall goal of Client 1 is to log in to its preferred server, Server 2. The first step is to

connect to some server that has a full SAP table so that the client can learn the IPX address of

its preferred server. (The preferred server name is configured on the client, not the IPX address

of the preferred server.) The router might know the preferred server’s name and IPX address in

its SAP table, but no IPX message defined allows the client to query the router for name

resolution. However, an IPX broadcast message asking for any nearby server is defined by IPX:

the GNS request. The router can supply the IPX address of some nearby server (Step 2, in

Figure 6-14) because the router has a SAP table.

Next, the client needs to learn which router to use to forward packets to the server discovered

by its GNS request. RIP requests and replies are used by the client to learn the route from any

router (or server) on the same LAN, as seen in Steps 3 and 4 in Figure 6-14. As a result,

Client 1 knows to use the LA router to deliver packets to network 1001.

After connecting to Server 1, the client learns the IPX address of Server 2, its preferred server

(Steps 5 and 6, in Figure 6-14). The client needs to know the best route to the preferred server’s

network; therefore, a RIP request and reply to learn the best next-hop router to network 1002 is

shown in Steps 7 and 8, in Figure 6-14. Finally, packets are sent between the client and Server

2 so that the client can log in; the intervening routers are simply routing the packets.

IPX clients create their own IPX address using the network number in the source address field

of the GNS reply. The GNS reply is always sent by a router or server on the same network as

the client. The client examines the source IPX address of the GNS reply to learn its own IPX

network number. The complete client IPX address is formed by putting that network number

with the MAC address of the client’s LAN interface.

implies that RIP and SAP updates should be sent and listened for on those interfaces. Router

Yosemite has been configured for RIP and SAP (see Figure 6-15). The command output in

forget—the CCNA exam will ask questions about what commands can be used to view certain

details.)

Codes: C - Connected primary network, c - Connected secondary network

S - Static, F - Floating static, L - Local (internal), W - IPXWAN

R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate

s - seconds, u - uses

7 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.

No default route known.

C 2 (SAP), E0_

C 1012 (HDLC), Se0

C 1023 (HDLC), Se1

R 1 [07/01] via 1012.0000.aaaa.aaaa, 14s, Se0

R 3 [07/01] via 1023.0200.cccc.cccc, 1s, Se1

R 1001 [08/03] via 1023.0200.cccc.cccc, 1s, Se1

R 1013 [12/01] via 1023.0200.cccc.cccc, 1s, Se1

Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail

1 Total IPX Servers

Table ordering is based on routing and server info

Type Name Net Address Port Route Hops Itf

P 4 Server1 1001.0000.0000.0001:0451 8/03 3 Se1

IPX routing debugging is on

Yosemite#

IPXRIP: positing full update to 2.ffff.ffff.ffff via Ethernet0 (broadcast)

IPXRIP: src=2.0200.bbbb.bbbb, dst=2.ffff.ffff.ffff, packet sent

network 1, hops 2, delay 8

network 1001, hops 4, delay 9

network 1012, hops 1, delay 2

network 3, hops 2, delay 8

network 1013, hops 2, delay 8

network 1023, hops 1, delay 2

IPXRIP: positing full update to 1012.ffff.ffff.ffff via Serial0 (broadcast)

IPXRIP: src=1012.0200.bbbb.bbbb, dst=1012.ffff.ffff.ffff, packet sent

network 1001, hops 4, delay 14

network 3, hops 2, delay 13

network 1013, hops 2, delay 13

network 1023, hops 1, delay 7

network 2, hops 1, delay 7

IPXRIP: update from 1012.0200.aaaa.aaaa

1013 in 1 hops, delay 7

1 in 1 hops, delay 7

1001 in 4 hops, delay 14

3 in 2 hops, delay 13

IPXRIP: 1023 FFFFFFFF not added, entry in table is static/connected/internal

1023 in 2 hops, delay 13

IPXRIP: update from 1023.0200.cccc.cccc

1 in 2 hops, delay 13

1001 in 3 hops, delay 8

3 in 1 hops, delay 7

1013 in 1 hops, delay 7

IPXRIP: positing full update to 1023.ffff.ffff.ffff via Serial1 (broadcast)

IPXRIP: src=1023.0200.bbbb.bbbb, dst=1023.ffff.ffff.ffff, packet sent

network 1, hops 2, delay 13

network 1012, hops 1, delay 7

network 2, hops 1, delay 7

Some of the more important portions of the output are highlighted in the example. These

metric values in brackets; the number of ticks is listed before the hop count. The number of

seconds listed at the end of each line for RIP-derived routes is the time since the routing

information was heard; the ticks metric shows only as a number of ticks, never as a number of

seconds. For example, in Example 6-21, Yosemite lists a route to network 3, with the numbers

[7,1] shown beside the IPX network number. Seven is the number of ticks, which in this case is

the sum of six ticks for the serial link to Seville, and one tick for the Ethernet in Seville. The

one in brackets represents the hop count.

there are thousands of SAP entries. The name of the server and the SAP type are listed; SAP

type will be important for SAP filters. The IPX address and socket used by the server for this

service also are listed; the socket may be important when filtering IPX packets. The metric

information handy, good choices for GNS replies can be made easily. In Example 6-21, Server1

is listed with SAP type 4, which is File Servers; its IPX address is 1001.0000.0000.0001, and

it uses IPX port 0451. The route to network 1001 has a metric of eight ticks and three hops;

when packets are sent to Server1, they are sent out Yosemite’s interface Serial1.

received. The number of ticks on LAN interfaces defaults to 1 and on WAN interfaces defaults

to 6. Although Albuquerque and Yosemite have coded a bandwidth parameter of 56 on the serial

IPX service debugging is on

IPXSAP: positing update to 1012.ffff.ffff.ffff via Serial0 (broadcast) (full)

IPXSAP: Update type 0x2 len 96 src:1012.0200.bbbb.bbbb

dest:1012.ffff.ffff.ffff(452)

type 0x4, “Server1“, 1001.0000.0000.0001(451), 4 hops

IPXSAP: Response (in) type 0x2 len 96 src:1012.0200.aaaa.aaaa

dest:1012.ffff.ffff.ffff(452)

type 0x4, “Server1“, 1001.0000.0000.0001(451), 4 hops

IPXSAP: positing update to 1023.ffff.ffff.ffff via Serial1 (broadcast) (full)

IPXSAP: suppressing null update to 1023.ffff.ffff.ffff

IPXSAP: Response (in) type 0x2 len 96 src:1023.0200.cccc.cccc

dest:1023.ffff.ffff.ffff(452)

type 0x4, “Server1“, 1001.0000.0000.0001(451), 3 hops

IPXSAP: positing update to 2.ffff.ffff.ffff via Ethernet0 (broadcast) (full)

IPXSAP: Update type 0x2 len 96 src:2.0000.3089.b170 dest:2.ffff.ffff.ffff(452)

type 0x4, “Server1“, 1001.0000.0000.00011(451), 4 hops

enables output describing every SAP update sent and received. Notice the update Yosemite

wants to send out network 1023; it is time to send a SAP broadcast, but the SAP update is null.

This is because the only SAP in the table (Server1, SAP type 4) was learned from Seville over

network 1023, so Yosemite is using split horizon rules to not send information about this SAP

back to Seville.

Only one route to each network is allowed in the routing table, by default. Looking back

to the beginning of Example 6-20, notice that the route to network 1013, metric [7/1],

points to next hop 1023.0200.cccc.cccc (Seville), out Yosemite’s Serial 1 interface. However,

1012.0200.aaaa.aaaa (Albuquerque) is sending RIP updates describing a route to network 1013,

with seven ticks and one hop into Yosemite’s S0 interface (see RIP debug output). Yosemite

global command had been configured on Yosemite, both routes would be included. Unlike with

IP, when two routes are in the IPX routing table, per-packet load balancing across these paths

occurs, even if fast switching is enabled.

are in the routing table may not be desired because packets can arrive out of order. By having

the router send all packets to an individual IPX address over the same route every time, those

disables per-packet balancing and enables balancing based on the destination address. Of

course, the penalty is that the traffic will not be completely balanced, based on the numbers of

packets to each destination.

Tunneling is the process whereby a router encapsulates one Layer 3 protocol inside another

protocol (typically IP) for transport across a network to another router. The receiving router

de-encapsulates the packet, leaving the original protocol. Each intermediate router that is used

between the endpoints of the tunnel is unaware of the protocol being encapsulated. Figure 6-16

shows the basic process and the physical and logical view of an example network.

Although tunneling can encapsulate any Layer 3 protocol, the example in Figure 6-16 shows

IPX being encapsulated. The incoming Ethernet frame on the left of the figure is processed as

normal, up to a point—the Ethernet header is discarded, and a routing decision is made to

D to represent the function of tunneling. When the routing logic directs the packet out the tunnel

interface, the encapsulation logic described in Figure 6-16 takes over, resulting in an IP packet.

After the IP packet is created, routing logic is repeated by Router A, this time for the new IP

packet. Router A routes the IP packet based on the IP routing table, as does Router B and then

Router C. Routers B and C have no knowledge that there is an IPX packet inside the IP packet.

When the packet arrives at Router D, D notices that the destination address is one of its own

immediately after the IP header, the router knows that this is a tunneled packet, so Router D

strips off the encapsulation header, which leaves the IPX packet, in this case. The IPX packet

then is routed, which sends the packet out the Ethernet interface.

Three important terms are used to describe the three parts of the entity that is sent between the

two tunneling routers:

passenger protocol.

used. You can think of this additional header as another place to include a field such as the

data link layer’s type, DSAP, or protocol field. The IP header defines that one of these

encapsulating protocol headers follows IP, and the encapsulation protocol identifies the

type of Layer 3 passenger protocol that follows it.

network. IP is the only choice in the IOS.

For each packet of the encapsulated (passenger) protocol, there is the additional overhead of

applying the packet header of the encapsulating (transport) protocol. By adding more bytes of

overhead, you certainly reduce the efficiency. So why even use tunneling in the first place?

There are several reasons:

limitations

The reduction of overhead and the capability to have an IP-only backbone are the two most

compelling reasons to use tunneling. Consider the previous Figure 6-16, which shows a

network with a pocket of Novell hosts on each end of the network, but with no Novell hosts in

the center of the network. One alternative would have been to configure IPX on all four routers.

If tunneling is used in that case, Routers B and C do not need to perform IPX routing. RIP and

SAP updates are sent once per timer over the tunnel and are not processed by Routers B and C.

The amount of overhead from these protocols is greatly reduced, particularly when nonbroadcast

multiaccess (NBMA) networks such as Frame Relay are in use. So, the backbone of

the WAN network can remain IP only, and when there are only pockets of the different

passenger protocols, these protocols can be forwarded using tunnels.

As cited in the previous list, one reason for using tunnels is VPNs. Consider Figure 6-17, with

the cloud representing a VPN service from a service provider.

Routers A1 and A2 are owned by Company A, and Routers B1 and B2 are owned by Company

B. The two companies do not want their traffic intermingled. If the service provider simply set

up routing protocols to each company’s sites and advertised all the routes into the service

provider network, a couple of undesirable situations will occur. First, route filtering would be

required to keep Company A from learning routes to Company B, and vice versa. Also, if either

company wanted to use private IP addresses, then the intermingling of IP routes would be

disastrous. For instance, if both Company A and Company B decided to use network 10.0.0.0,

subnets would overlap and only some of the traffic would be delivered correctly.

The benefit of tunneling for VPNs is that the service provider network does not learn routes

about Company A or Company B. The tunnels use addresses in the service provider network.

The routing protocol on Routers A1 and A2 send updates to each other over the tunnel, so these

two routers think they are logically adjacent. Likewise, Routers B1 and B2 send updates to each

other; these updates do not need to be processed by the service provider routers. Also, because

the customer routes are not learned by the service provider, there is no need for route

redistribution or route filtering.

Tunneling configuration is not very complicated if you remember the framing with the

transport, encapsulation, and passenger protocols. A tunnel interface is created on each router

at the ends of the tunnel. To accommodate the transport protocol, an IP address is used at the

endpoints of the tunnel; these IP addresses are used as the source and destination IP addresses

of the encapsulated packets. The type of encapsulation protocol is configured; there are six

alternatives. Finally, the tunnel interface is configured just like any other interface to enable the

desired passenger protocols. Examples 6-22 and 6-23 show the configuration of Routers A and

D, respectively, from Figure 6-16.

ipx routing

!

interface serial 0

ip address 10.1.2.1 255.255.255.0

interface ethernet 0

ip address 10.1.1.1 255.255.255.0

ipx network 1

!

interface tunnel 0

tunnel source ethernet 0

tunnel destination 10.1.5.4

ipx network 3

!

router igrp 9

network 10.0.0.0

ipx routing

!

interface token 0

ip address 10.1.4.4 255.255.255.0

interface ethernet 0

ip address 10.1.5.4 255.255.255.0

The configuration is simplified if you concentrate on the transport, encapsulation, and

passenger protocols. First, as highlighted in Example 6-22, IP is enabled on all interfaces except

on the interface; this IP address is used as the source for all packets sent out the tunnel interface.

out each tunnel interface. IP is enabled by default.

The encapsulation protocol in this case has defaulted to generic route encapsulation (GRE). If

the protocol. (While the details of the encapsulation protocols are likely to be beyond the CCNA

requirements, the other types are aurp, cayman, dvmrp, eon, ipip, iptalk, and nos.)

The passenger protocol is enabled on the tunnel interface, just as it would be for any other

Router A’s serial 0 interface and Router D’s Token Ring interface. Because there are no Novell

nodes in the center of the network, there is no need to enable IPX on these interfaces.

So far, all the routing protocol functions discussed in this book fall under the classification of

order. Consider Figure 6-18, which should remind you of one such concept.

As discussed in Chapter 3, the router determines what type of Layer 3 packet is inside the

received frame. There is a separate routing table for each routable or routed protocol. (If you

previously skipped Chapter 3, you may want to review the generalized routing algorithm, or the

“Ting and Ted” story.) The routing decision is therefore dependent on a routing table specific

for that one Layer 3 protocol. This process is called multiprotocol routing.

Routing protocols fill the routing tables of the various Layer 3 protocols. Although not covered

elsewhere in this book, AppleTalk uses yet another derivative of XNS RIP, called the Routing

Table Maintenance Protocol (RTMP), as its routing protocol. Consider the simple network in

Figure 6-19 and the routing updates that are sent out S0 by Router1.

ipx network 2

!

interface tunnel 3

tunnel source 10.1.5.4

tunnel destination 10.1.1.1

ipx network 3

!

router igrp 9

network 10.0.0.0

separate routing updates sent by the respective routing protocols. Each separate routable

protocol (IP, IPX, and AppleTalk) uses a separate routing protocol. (IP uses RIP, IPX uses RIP,

and AppleTalk uses RTMP.)

Many similarities exist among IP, IPX, and AppleTalk; these similarities allow integrated

multiprotocol routing to exist. In particular, if Router1’s E0 interface failed, then IP subnet

10.1.1.0/24, IPX network 1, and AppleTalk Cablerange 1-1 would all be inaccessible. In fact,

the key similarity is that all three Layer 3 protocols use the same concept of grouping devices;

that is, a group consists of all interfaces attached to the same medium. In fact, the following

statement can be made about this similarity:

Events that could cause a router’s directly connected IP route to fail will often cause the

directly connected IPX and AppleTalk routes associated with that same data link to fail.

A failure of Router1’s E0 interface would cause IP RIP, IPX RIP, and AppleTalk RTMP to

advertise that the associated subnet/network/cablerange was not accessible. Each routing

protocol would send its own updates, as diagrammed in Figure 6-20.

Integrated multiprotocol routing uses a single routing protocol to propagate routing information

for multiple routable protocols. EIGRP performs integrated multiprotocol routing for IP, IPX,

and AppleTalk. (EIGRP and Integrated IS-IS can also do integrated multiprotocol routing for

IP and OSI CLNS.) Figure 6-21 diagrams the basic idea behind integrated multiprotocol

routing.

Table 6-18 summarizes the key concepts behind separate and integrated multiprotocol routing.

Multiple routing tables, one each for IP, IPX, and

AppleTalk

Multiple routing tables, one each for IP, IPX, and

AppleTalk

Multiple routing updates, one per routing protocol One routing update combined for all three routed

protocols

Table 6-19 lists the EXEC commands covered in this chapter.

Table 6-20 lists interior IP routing protocols and their types. A column referring to whether the

routing protocol includes subnet mask information in the routing updates is listed for future

reference.

neighboring routers using the routing protocol, and timers.

interface. Also identifies the source of routing information.

interface. Also identifies the source of routing information.

SAP type.

RIP-1 Distance vector Holddown timer, split

horizon

No

RIP-2 Distance vector Holddown timer, split

horizon

Yes

IGRP Distance vector Holddown timer, split

horizon

No

EIGRP Balanced hybrid DUAL and feasible

successors

Yes

OSPF Link-state Dijkstra SPF algorithm

and full topology

knowledge

Yes

Most of the issues with distance vector routing protocols arise when working with networks

with multiple paths. Two of these issues are not obvious. Table 6-21 summarizes these issues,

and each is explained in succession.

Table 6-22 outlines the features of RIP and IGRP.

Multiple routes to same subnet, with

equal metric

Implementation options include either using the first route

learned or putting multiple routes to the same subnet in the

routing table.

Routing loops occurring due to updates

passing each other over a single link

an interface only if they were not learned from updates

entering that interface.

advertises all routes out an interface, but those learned from

earlier updates coming in that interface are marked with

infinite distance metrics.

Routing loops occurring due to updates

passing each other over alternate paths

subnet is advertised with an infinite distance metric.

has failed, a router waits a certain period of time before

believing any other routing information about that subnet.

an update rather than waiting on the update timer to expire

when a route has failed. Used in conjunction with route

poisoning, this ensures that all routers know of failed routes

before any holddown timers can expire.

Update timer 30 seconds 90 seconds

Metric Hop count Function of bandwidth and

delay (default); can include

reliability, load, and MTU

Holddown timer 180 280

Flash (triggered) updates Yes Yes

Mask sent in update No for RIP-1, yes for RIP-2 No

Infinity metric value 16 4,294,967,295

Table 6-23 and Table 6-24 summarize the more popular commands used for RIP and IGRP

configuration and verification.

RIP-2, defined by RFC 1723, is simply an improved version of RIP Version 1. Many features

are the same: Hop count is still used for the metric, it is still a distance vector protocol, and it

still uses holddown timers and route poisoning. Several features have been added; the features

are listed in Table 6-25.

values

connectivity

to verify the current route to a host

Transmits subnet mask with route This feature allows VLSM by passing the mask along with

each route so that the subnet is exactly defined.

Table 6-26 lists the features for summarization of the interior IP routing protocols.

Table 6-27 lists the similarities and differences between IP RIP and IPX RIP.

Table 6-28 summarizes the key concepts behind separate and integrated multiprotocol routing.

Uses authentication Both clear text (RFC-defined) and MD5 encryption (Ciscoadded

feature) can be used to authenticate the source of a

routing update.

Uses next-hop router IP address in

routing update

A router can advertise a route but direct any listeners to a

different router on that same subnet. This is done only when

the other router has a better route.

Uses external route tags RIP can pass information about routes learned from an

external source and can be redistributed into RIP.

Provides multicast routing updates Instead of sending updates to 255.255.255.255, the

destination IP address is 224.0.0.9, an IP multicast address.

This reduces the amount of processing required on non-

RIP-speaking hosts on a common subnet.

RIP Version 1 Yes, by default Not allowed No

IGRP Yes, by default Not allowed No

RIP Version 2 Yes, by default Allowed via configuration No

EIGRP Yes, by default Allowed via configuration Yes

OSPF No, but can do equivalent

with aggregation

Yes Yes

Uses distance vector Uses distance vector

Is based on XNS RIP Is based on XNS RIP

Uses 60-second update timer (default) Uses 30-second update timer (default)

Uses timer ticks as primary metric and hop count

as secondary metric

Uses hop count as only metric

Figure 6-22 includes the use of the Get Nearest Server (GNS) request and shows a typical

startup with a client configured with a preferred server of Server 2.

Multiple routing tables, one each for IP, IPX, and

AppleTalk

Multiple routing tables, one each for IP, IPX, and

AppleTalk

Multiple routing updates, one per routing protocol One routing update combined for all three routed

protocols

Table 6-29 lists several definitions of terms covered throughout the chapter.

Link-state protocol A type of logic used by a routing protocol, characterized by exchanges

of full topology information, which is processed with the Dijkstra

algorithm to form a shortest-path tree to determine routes. OSPF is an

example.

Distance vector A type of logic used by a routing protocol, characterized by exchange

of a vector consisting of the destination network and a metric. IP RIP,

IPX RIP, and IGRP are examples of distance vector routing protocols.

Route poisoning A distance vector feature of advertising routes that were previously

good but that are now failed, with a metric value that is considered to

be infinite. This is a loop-prevention feature.

Flash updates A distance vector feature of sending new or changed routing

information in an update immediately rather than waiting on the next

update timer to expire.

Triggered updates Another term for flash updates.

Update timer A distance vector feature that defines the interval between sending

routing updates. A neighboring router will believe that a neighboring

router has failed if updates are not received after some multiple of the

update timer (usually 3).

Holddown timer A distance vector feature that defines how long to wait to update a

route for a particular subnet, after hearing that the route that was

previously in the routing table has failed.

Split horizon A distance vector feature that prevents the routing protocol from

advertising routes out an interface if the routes were learned from

updates entering that interface.

Split horizon with poison

reverse

A variation of split horizon. Routes learned via updates entering an

interface are advertised in updates sent out that same interface, except

that these routes are given an infinite distance metric.

As mentioned in Chapter 1, the questions and scenarios in this book are more difficult than what

you should experience on the actual exam. The questions do not attempt to cover more breadth

or depth than the exam; however, they are designed to make sure that you know the answer.

Rather than allowing you to derive the answer from clues hidden inside the question itself, the

questions challenge understanding and recall of the subject. Questions from the “Do I Know

This Already?” quiz from the beginning of the chapter are repeated here to ensure that you have

mastered the chapter’s topic areas. Hopefully, these questions will help limit the number of

exam questions on which you narrow your choices to two options and then guess.

The answers to these questions can be found in Appendix A, on page 748.

both the distance vector algorithm and the link-state algorithm?

command.

What about a route learned with IGRP and a route learned with RIP?

10.1.1.1, e1 using 224.1.2.3, s0 using 10.1.2.1, and s1 using 199.1.1.1. Use process ID 5.

200.1.1.1, e0 using 128.1.3.2, s0 using 192.0.1.1, and s1 using 223.254.254.1.

determine what routers are sending you routing updates?

of the two be enabled in a router? If false, what commands enable each protocol globally

in a router?

Novell IPX.

interface subcommand, what metric will IPX RIP associate with each interface?

interfaces in which no SAP packets have been received in the last 60 seconds.

Novell IPX.

were configured in a router that has an Ethernet0 interface with IP address 168.10.1.1,

would RIP send updates out Ethernet0?

an Ethernet0 interface with IP address 168.10.1.1, would IGRP advertise about

168.10.0.0?

an Ethernet0 interface with IP address 168.10.1.1, mask 255.255.255.0, would this router

have a route to 168.10.1.0?

routes to be added to the routing table? If not, how close in value do the metrics have to be?

that can be added to the routing table at the same time? What is the maximum number of

equal-cost routes to the same destination that can be included in the IP routing table at

once?

that can be added to the routing table at the same time? What is the maximum number of

equal-cost routes to the same destination that can be included in the IP routing table at

once?

(VLSM)?

router configured for only support of RIP-2?

protocol.

Which of these protocols allows auto summary to be disabled using a configuration

command?

mask information only on the line that lists network 172.16.0.0, but not show mask

information on each route for each subnet?

updates.

destination network. If more than one route to a particular subnet is learned, and if each

route has the same metric value, which route is placed into the routing table if the routing

protocol uses distance vector logic?

Your job is to deploy a new network. The network engineering group has provided a list of

addresses and a network diagram, as shown in Figure 6-23 and Table 6-30.

Assuming the details established in Figure 6-23 and Table 6-30 for Scenario 6-1, complete or

answer the following:

appropriate.

interfaces are up but no routing protocols or static routes have been configured.

with other hosts in this network.

Your job is to deploy a new network. The network engineering group has provided a list of

addresses and a network diagram, with Frame Relay global DLCIs, as shown in Figure 6-24

and Table 6-31.

Ethernet off router in

Albuquerque

255.255.255.0 148.14.1.0

Ethernet off router in Yosemite 255.255.255.0 148.14.2.0

Ethernet off router in Seville 255.255.255.0 148.14.3.0

Serial between Albuquerque

and Yosemite

255.255.255.0 148.14.4.0

Serial between Albuquerque

and Seville

255.255.255.0 148.14.5.0

Serial between Seville and

Yosemite

255.255.255.0 148.14.6.0

Assuming the details established in Figure 6-24 and Table 6-31 for Scenario 6-2, complete or

answer the following:

protocol.

contents of the RIP update from Atlanta to Charlotte.

Perform the tasks and answer the questions following the upcoming figures and examples.

Figure 6-25 shows the network diagram for Scenario 6-3, and Example 6-24, Example 6-25,

record the subnet numbers and broadcast addresses as directed in the upcoming tasks.

Ethernet off router in Atlanta 255.255.255.0 10.1.1.0

Ethernet off router in Charlotte 255.255.255.0 10.1.2.0

Ethernet off router in Nashville 255.255.255.0 10.1.3.0

Ethernet off router in Boston 255.255.255.0 10.1.4.0

VC between Atlanta and

Charlotte

255.255.255.0 10.2.1.0

VC between Atlanta and

Nashville

255.255.255.0 10.2.2.0

VC between Atlanta and Boston 255.255.255.0 10.2.3.0

Ethernet off router in

Mayberry

255.255.255.0

Ethernet off router in Mount

Pilot

255.255.255.0

Ethernet off router in Raleigh 255.255.255.0

VC between Mayberry and

Mount Pilot

255.255.255.0

VC between Mayberry and

Raleigh

255.255.255.0

VC between Mount Pilot and

Raleigh

255.255.255.0

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

170.1.0.0/24 is subnetted, 4 subnets

C 170.1.1.0 is directly connected, Serial0

I 170.1.103.0 [100/8539] via 170.1.1.3, 00:00:50, Serial0

I 170.1.102.0 [100/8539] via 170.1.1.2, 00:00:32, Serial0

C 170.1.101.0 is directly connected, Ethernet0

Interface IP-Address OK? Method Status Protocol

Serial0 170.1.1.1 YES NVRAM up up

Serial1 10.1.6.251 YES NVRAM administratively down down

Ethernet0 170.1.101.1 YES NVRAM up up

IGRP protocol debugging is on

IGRP event debugging is on

Mayberry#

IGRP: received update from 170.1.1.3 on Serial0

subnet 170.1.1.0, metric 10476 (neighbor 8476)

subnet 170.1.103.0, metric 8539 (neighbor 688)

subnet 170.1.102.0, metric 10539 (neighbor 8539)

subnet 170.1.101.0, metric 10539 (neighbor 8539)

IGRP: Update contains 4 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 4

IGRP: received update from 170.1.1.2 on Serial0

subnet 170.1.1.0, metric 10476 (neighbor 8476)

subnet 170.1.103.0, metric 10539 (neighbor 8539)

subnet 170.1.102.0, metric 8539 (neighbor 688)

subnet 170.1.101.0, metric 10539 (neighbor 8539)

IGRP: Update contains 4 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 4

IGRP: sending update to 255.255.255.255 via Serial0 (170.1.1.1)

subnet 170.1.1.0, metric=8476

subnet 170.1.103.0, metric=8539

subnet 170.1.102.0, metric=8539

subnet 170.1.101.0, metric=688

IGRP: Update contains 4 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 4

IGRP: sending update to 255.255.255.255 via Ethernet0 (170.1.101.1)

subnet 170.1.1.0, metric=8476

subnet 170.1.103.0, metric=8539

subnet 170.1.102.0, metric=8539

IGRP: Update contains 3 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update:

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 47, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 38 output pkts 37 in bytes 3758

out bytes 3514 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 36 out bcast bytes 3436

pvc create time 00:17:39, last time pvc status changed 00:17:39

DLCI = 49, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 31 output pkts 31 in bytes 3054

out bytes 3076 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 31 out bcast bytes 3076

pvc create time 00:17:40, last time pvc status changed 00:16:40

Serial0 (up): ip 170.1.1.1 dlci 47(0x2F,0x8F0), dynamic,

broadcast,, status defined, active

Serial0 (up): ip 170.1.1.3 dlci 49(0x31,0xC10), dynamic,

broadcast,, status defined, active

MountPilot#

IGRP: sending update to 255.255.255.255 via Serial0 (170.1.1.2)

subnet 170.1.1.0, metric=8476

subnet 170.1.103.0, metric=8539

subnet 170.1.102.0, metric=688

subnet 170.1.101.0, metric=8539

IGRP: Update contains 4 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 4

IGRP: sending update to 255.255.255.255 via Ethernet0 (170.1.102.2)

subnet 170.1.1.0, metric=8476

subnet 170.1.103.0, metric=8539

subnet 170.1.101.0, metric=8539

IGRP: Update contains 3 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 3

IGRP: received update from 170.1.1.1 on Serial0

subnet 170.1.1.0, metric 10476 (neighbor 8476)

subnet 170.1.103.0, metric 10539 (neighbor 8539)

subnet 170.1.102.0, metric 10539 (neighbor 8539)

subnet 170.1.101.0, metric 8539 (neighbor 688)

IGRP: Update contains 4 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 4

IGRP: received update from 170.1.1.3 on Serial0

subnet 170.1.1.0, metric 10476 (neighbor 8476)

subnet 170.1.103.0, metric 8539 (neighbor 688)

subnet 170.1.102.0, metric 10539 (neighbor 8539)

subnet 170.1.101.0, metric 10539 (neighbor 8539)

IGRP: Update contains 4 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 4

%FR-5-DLCICHANGE: Interface Serial0 - DLCI 47 state changed to DELETED

MountPilot#

IGRP: received update from 170.1.1.3 on Serial0

subnet 170.1.1.0, metric 10476 (neighbor 8476)

subnet 170.1.103.0, metric 8539 (neighbor 688)

subnet 170.1.102.0, metric 10539 (neighbor 8539)

subnet 170.1.101.0, metric 10539 (neighbor 8539)

IGRP: Update contains 4 interior, 0 system, and 0 exterior routes.

IGRP: Total routes in update: 4

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default

U - per-user static route, o - ODR

Gateway of last resort is not set

170.1.0.0/24 is subnetted, 4 subnets

C 170.1.1.0 is directly connected, Serial0

C 170.1.103.0 is directly connected, Ethernet0

I 170.1.102.0 [100/8539] via 170.1.1.2, 00:00:09, Serial0

I 170.1.101.0 [100/8539] via 170.1.1.1, 00:00:42, Serial0

Interface IP-Address OK? Method Status Protocol

Assuming the details established in Figure 6-25, Table 6-32, and Example 6-24, Example 6-25,

and Example 6-26 for Scenario 6-3, complete or answer the following:

subnet numbers and broadcast addresses used in this network.

Serial0 170.1.1.3 YES NVRAM up up

Serial1 180.1.1.253 YES NVRAM administratively down down

Ethernet0 170.1.103.3 YES NVRAM up up

Routing Protocol is “igrp 4“

Sending updates every 90 seconds, next due in 56 seconds

Invalid after 270 seconds, hold down 280, flushed after 630

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

IGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

IGRP maximum hopcount 100

IGRP maximum metric variance 1

Redistributing: igrp 4

Routing for Networks:

170.1.0.0

Routing Information Sources:

Gateway Distance Last Update

170.1.1.2 100 00:00:20

170.1.1.1 100 00:00:53

Distance: (default is 100)

PVC Statistics for interface Serial0 (Frame Relay DTE)

DLCI = 47, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 36 output pkts 35 in bytes 3674

out bytes 3436 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 34 out bcast bytes 3358

pvc create time 00:22:07, last time pvc status changed 00:21:58

DLCI = 48, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0

input pkts 35 output pkts 35 in bytes 3444

out bytes 3422 dropped pkts 0 in FECN pkts 0

in BECN pkts 0 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 34 out bcast bytes 3358

pvc create time 00:22:08, last time pvc status changed 00:21:58

Mount Pilot. How many routes in Raleigh’s IGRP update are sent to Mount Pilot? How

Look at the IGRP debug output in Example 6-25 and the IP routing table in Example

6-26.)

completes, will Mayberry have a route to 170.1.1.0/24? Why or why not?

The CCNA exam includes questions that test your recollection of the details shown in various

6-33, Table 6-34, and Example 6-27, Example 6-28, and Example 6-29; performing these tasks

will help you solidify your recollection of what information is available in each command.

Interface IPX Network Encapsulation Status IPX State

Serial0 2012 HDLC up [up]

Serial1 2013 HDLC up [up]

Ethernet0 1001 SAP up [up]

-------------------------

Device ID: Yosemite

Entry address(es):

IP address: 10.1.12.2

Novell address: 2012.0200.2222.2222

Platform: Cisco 2500, Capabilities: Router

Interface: Serial0, Port ID (outgoing port): Serial0

Holdtime : 167 sec

Version :

Cisco Internetwork Operating System Software

IOS (tm) 2500 Software (C2500-AINR-L), Version 11.2(11), RELEASE SOFTWARE (fc1)

Copyright 1986-1997 by Cisco Systems, Inc.

Compiled Mon 29-Dec-97 18:47 by ckralik

-------------------------

Device ID: Seville

Entry address(es):

IP address: 10.1.13.3

Novell address: 2013.0200.3333.3333

Platform: Cisco 2500, Capabilities: Router

Interface: Serial1, Port ID (outgoing port): Serial0

Holdtime : 164 sec

Version :

Cisco Internetwork Operating System Software

IOS (tm) 2500 Software (C2500-AINR-L), Version 11.2(11), RELEASE SOFTWARE (fc1)

Copyright 1986-1997 by Cisco Systems, Inc.

Compiled Mon 29-Dec-97 18:47 by ckralik

IPX routing debugging is on

Albuquerque#

IPXRIP: positing full update to 1001.ffff.ffff.ffff via Ethernet0 (broadcast)

IPXRIP: src=1001.0000.0c35.ab12, dst=1001.ffff.ffff.ffff, packet sent

network 1003, hops 2, delay 8

network 2023, hops 2, delay 8

network 1002, hops 2, delay 8

network 2013, hops 1, delay 2

network 2012, hops 1, delay 2

IPXRIP: update from 2013.0200.3333.3333

1002 in 2 hops, delay 13

2023 in 1 hops, delay 7

1003 in 1 hops, delay 7

IPXRIP: positing full update to 2012.ffff.ffff.ffff via Serial0 (broadcast)

IPXRIP: src=2012.0200.1111.1111, dst=2012.ffff.ffff.ffff, packet sent

network 1, hops 3, delay 8

network 2, hops 3, delay 8

network 1003, hops 2, delay 13

network 2013, hops 1, delay 7

network 1001, hops 1, delay 7

IPXRIP: positing full update to 2013.ffff.ffff.ffff via Serial1 (broadcast)

IPXRIP: src=2013.0200.1111.1111, dst=2013.ffff.ffff.ffff, packet sent

network 1, hops 3, delay 8

network 2, hops 3, delay 8

network 2023, hops 2, delay 13

network 1002, hops 2, delay 13

network 2012, hops 1, delay 7

network 1001, hops 1, delay 7

IPXRIP: update from 2012.0200.2222.2222

1003 in 2 hops, delay 13

2023 in 1 hops, delay 7

1002 in 1 hops, delay 7

Codes: C - Connected primary network, c - Connected secondary network

S - Static, F - Floating static, L - Local (internal), W - IPXWAN

R - RIP, E - EIGRP, N - NLSP, X - External, A - Aggregate

s - seconds, u - uses

8 Total IPX routes. Up to 1 parallel paths and 16 hops allowed.

No default route known.

C 1002 (SAP), To0

C 2012 (HDLC), Se0

C 2023 (HDLC), Se1

R 1 [08/03] via 2012.0200.1111.1111, 32s, Se0

R 2 [08/03] via 2012.0200.1111.1111, 33s, Se0

R 1001 [07/01] via 2012.0200.1111.1111, 33s, Se0

R 1003 [07/01] via 2023.0200.3333.3333, 32s, Se1

R 2013 [07/01] via 2012.0200.1111.1111, 33s, Se0

System Traffic for 0.0000.0000.0001 System-Name: Yosemite

Rcvd: 169 total, 0 format errors, 0 checksum errors, 0 bad hop count,

8 packets pitched, 161 local destination, 0 multicast

Bcast: 160 received, 242 sent

Sent: 243 generated, 0 forwarded

0 encapsulation failed, 0 no route

SAP: 2 SAP requests, 0 SAP replies, 2 servers

0 SAP Nearest Name requests, 0 replies

0 SAP General Name requests, 0 replies

60 SAP advertisements received, 57 sent

6 SAP flash updates sent, 0 SAP format errors

RIP: 1 RIP requests, 0 RIP replies, 9 routes

98 RIP advertisements received, 120 sent

45 RIP flash updates sent, 0 RIP format errors

Echo: Rcvd 0 requests, 0 replies

Sent 0 requests, 0 replies

0 unknown: 0 no socket, 0 filtered, 0 no helper

0 SAPs throttled, freed NDB len 0

Watchdog:

0 packets received, 0 replies spoofed

Queue lengths:

IPX input: 0, SAP 0, RIP 0, GNS 0

SAP throttling length: 0/(no limit), 0 nets pending lost route reply

Delayed process creation: 0

EIGRP: Total received 0, sent 0

Updates received 0, sent 0

Queries received 0, sent 0

Replies received 0, sent 0

SAPs received 0, sent 0

NLSP: Level-1 Hellos received 0, sent 0

PTP Hello received 0, sent 0

Level-1 LSPs received 0, sent 0

LSP Retransmissions: 0

LSP checksum errors received: 0

LSP HT=0 checksum errors received: 0

Level-1 CSNPs received 0, sent 0

Level-1 PSNPs received 0, sent 0

Level-1 DR Elections: 0

Level-1 SPF Calculations: 0

Level-1 Partial Route Calculations: 0

IPX routing debugging is on

Yosemite#

IPXRIP: positing full update to 1002.ffff.ffff.ffff via Ethernet0 (broadcast)

IPXRIP: src=1002.0000.0c24.7841, dst=1002.ffff.ffff.ffff, packet sent

network 1, hops 4, delay 9

network 2, hops 4, delay 9

network 1003, hops 2, delay 8

network 1001, hops 2, delay 8

network 2013, hops 2, delay 8

network 2023, hops 1, delay 2

network 2012, hops 1, delay 2

IPXRIP: positing full update to 2012.ffff.ffff.ffff via Serial0 (broadcast)

IPXRIP: src=2012.0200.2222.2222, dst=2012.ffff.ffff.ffff, packet sent

network 1003, hops 2, delay 13

network 2023, hops 1, delay 7

network 1002, hops 1, delay 7

IPXRIP: positing full update to 2023.ffff.ffff.ffff via Serial1 (broadcast)

IPXRIP: src=2023.0200.2222.2222, dst=2023.ffff.ffff.ffff, packet sent

network 1, hops 4, delay 14

network 2, hops 4, delay 14

network 1001, hops 2, delay 13

network 2013, hops 2, delay 13

network 2012, hops 1, delay 7

network 1002, hops 1, delay 7

IPXRIP: update from 2012.0200.1111.1111

1 in 3 hops, delay 8

2 in 3 hops, delay 8

1003 in 2 hops, delay 13

2013 in 1 hops, delay 7

1001 in 1 hops, delay 7

IPXRIP: update from 2023.0200.3333.3333

1 in 4 hops, delay 14

2 in 4 hops, delay 14

1001 in 2 hops, delay 13

IPXRIP: 2012 FFFFFFFF not added, entry in table is static/connected/internal

2012 in 2 hops, delay 13

2013 in 1 hops, delay 7

1003 in 1 hops, delay 7

Serial0 is up, line protocol is up

IPX address is 2013.0200.3333.3333 [up]

Delay of this IPX network, in ticks is 6 throughput 0 link delay 0

IPXWAN processing not enabled on this interface.

IPX SAP update interval is 1 minute(s)

IPX type 20 propagation packet forwarding is disabled

Incoming access list is not set

Outgoing access list is not set

IPX helper access list is not set

SAP GNS processing enabled, delay 0 ms, output filter list is not set

SAP Input filter list is not set

SAP Output filter list is not set

SAP Router filter list is not set

Input filter list is not set

Output filter list is not set

Router filter list is not set

Netbios Input host access list is not set

Netbios Input bytes access list is not set

Netbios Output host access list is not set

Netbios Output bytes access list is not set

Updates each 60 seconds, aging multiples RIP: 3 SAP: 3

SAP interpacket delay is 55 ms, maximum size is 480 bytes

RIP interpacket delay is 55 ms, maximum size is 432 bytes

Watchdog processing is disabled, SPX spoofing is disabled, idle time 60

IPX accounting is disabled

IPX fast switching is configured (enabled)

RIP packets received 53, RIP packets sent 55

SAP packets received 14, SAP packets sent 25

Serial1 is up, line protocol is up

IPX address is 2023.0200.3333.3333 [up]

Delay of this IPX network, in ticks is 6 throughput 0 link delay 0

IPXWAN processing not enabled on this interface.

IPX SAP update interval is 1 minute(s)

IPX type 20 propagation packet forwarding is disabled

Incoming access list is not set

Outgoing access list is not set

IPX helper access list is not set

SAP GNS processing enabled, delay 0 ms, output filter list is not set

SAP Input filter list is not set

SAP Output filter list is not set

SAP Router filter list is not set

Input filter list is not set

Output filter list is not set

Router filter list is not set

Netbios Input host access list is not set

Netbios Input bytes access list is not set

Netbios Output host access list is not set

Netbios Output bytes access list is not set

Updates each 60 seconds, aging multiples RIP: 3 SAP: 3

SAP interpacket delay is 55 ms, maximum size is 480 bytes

RIP interpacket delay is 55 ms, maximum size is 432 bytes

Watchdog processing is disabled, SPX spoofing is disabled, idle time 60

IPX accounting is disabled

IPX fast switching is configured (enabled)

RIP packets received 53, RIP packets sent 62

SAP packets received 13, SAP packets sent 37

Ethernet0 is up, line protocol is up

IPX address is 1003. 0000.0cac.ab41, SAP [up]

Delay of this IPX network, in ticks is 1 throughput 0 link delay 0

IPXWAN processing not enabled on this interface.

IPX SAP update interval is 1 minute(s)

IPX type 20 propagation packet forwarding is disabled

Incoming access list is not set

Outgoing access list is not set

IPX helper access list is not set

SAP GNS processing enabled, delay 0 ms, output filter list is not set

SAP Input filter list is not set

SAP Output filter list is not set

SAP Router filter list is not set

Input filter list is not set

Output filter list is not set

Router filter list is not set

Netbios Input host access list is not set

Netbios Input bytes access list is not set

Netbios Output host access list is not set

Netbios Output bytes access list is not set

Updates each 60 seconds, aging multiples RIP: 3 SAP: 3

SAP interpacket delay is 55 ms, maximum size is 480 bytes

RIP interpacket delay is 55 ms, maximum size is 432 bytes

IPX accounting is disabled

IPX fast switching is configured (enabled)

RIP packets received 20, RIP packets sent 62

SAP packets received 18, SAP packets sent 15

Codes: S - Static, P - Periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail

2 Total IPX Servers

Table ordering is based on routing and server info

Type Name Net Address Port Route Hops Itf

P 4 Bugs 1.0000.0000.0001:0451 8/03 3 Se0

P 4 Daffy 2.0000.0000.0001:0451 8/03 3 Se0

IPX service debugging is on

Seville#

IPXSAP: Response (in) type 0x2 len 160 src:2023.0200.2222.2222

dest:2023.ffff.ffff.ffff(452)

type 0x4, “Daffy“, 2.0000.0000.0001(451), 4 hops

type 0x4, “Bugs“, 1.0000.0000.0001(451), 4 hops

IPXSAP: positing update to 1003.ffff.ffff.ffff via Ethernet0 (broadcast) (full)

IPXSAP: Update type 0x2 len 160 src:1003.0000.0cac.ab41

dest:1003.ffff.ffff.ffff(452)

type 0x4, “Daffy“, 2.0000.0000.0001(451), 4 hops

type 0x4, “Bugs“, 1.0000.0000.0001(451), 4 hops

IPXSAP: positing update to 2013.ffff.ffff.ffff via Serial0 (broadcast) (full)

IPXSAP: suppressing null update to 2013.ffff.ffff.ffff

IPXSAP: positing update to 2023.ffff.ffff.ffff via Serial1 (broadcast) (full)

IPXSAP: Update type 0x2 len 160 src:2023.0200.3333.3333

dest:2023.ffff.ffff.ffff(452)

type 0x4, “Daffy“, 2.0000.0000.0001(451), 4 hops

type 0x4, “Bugs“, 1.0000.0000.0001(451), 4 hops

IPXSAP: Response (in) type 0x2 len 160 src:2013.0200.1111.1111

dest:2013.ffff.ffff.ffff(452)

type 0x4, “Bugs“, 1.0000.0000.0001(451), 3 hops

type 0x4, “Daffy“, 2.0000.0000.0001(451), 3 hops

Given the network in Figure 6-26 and the command output in Example 6-27, Example 6-28,

and Example 6-29 for Scenario 6-4, complete or answer the following:

these network numbers. List all commands that helped you find the network numbers.

Include the numbers of routes and metrics.

be in the SAP table? What socket is Bugs using? Assuming defaults for ticks on each

router, is it possible that more than one serial link exists between Seville and Daffy?

Albuquerque E0

S0

S1

Yosemite E0

S0

S1

Seville E0

S0

S1

Refer back to the network illustrated in Figure 6-23 and Table 6-30 to establish the Scenario

6-1 design details and the context of the answers to the five tasks for this scenario.

Task 1 for Scenario 6-1 asks for completed configurations, which are shown in Example 6-30,

Example 6-31, and Example 6-32. You could have chosen different IP addresses, but your

choices must have had the same first three octets as those shown in Example 6-30.

hostname Albuquerque

!

enable secret 5 $1$ZvR/$Gpk5a5K5vTVpotd3KUygA1

!

interface Serial0

ip address 148.14.4.1 255.255.255.0

!

interface Serial1

ip address 148.14.5.1 255.255.255.0

!

Ethernet0

ip address 148.14.1.1 255.255.255.0

hostname Yosemite

enable secret 5 $1$ZvR/$Gpk5a5K5vTVpotd3KUygA1

!

interface Serial0

ip address 148.14.4.2 255.255.255.0

!

interface Serial1

ip address 148.14.6.2 255.255.255.0

!

Ethernet0

ip address 148.14.2.2 255.255.255.0

hostname Seville

enable secret 5 $1$ZvR/$Gpk5a5K5vTVpotd3KUygA1

!

interface Serial0

ip address 148.14.5.3 255.255.255.0

Task 2 for Scenario 6-1 asks for a description of the IP routing table on Seville, which is shown

in Table 6-35. This table exists before static and dynamic routes are added.

The next-hop router field is always the IP address of another router, or it is null if the route

describes a directly connected network.

Task 3 for Scenario 6-1 asks for static route configuration. The routes to allow users on LANs

to reach each other are shown in upcoming examples. However, routes to the subnets on serial

links are not shown in these examples for brevity’s sake; the users should not need to send

packets to IP addresses on the serial links’ subnets, but rather to other hosts on the LANs.

Example 6-33, Example 6-34, and Example 6-35 show the configurations on the three routers.

!

interface Serial1

ip address 148.14.6.3 255.255.255.0

!

Ethernet0

ip address 148.14.3.3 255.255.255.0

148.14.3.0 e0

148.14.5.0 s0

148.14.6.0 s1

ip route 148.14.2.0 255.255.255.0 148.14.4.2

ip route 148.14.3.0 255.255.255.0 serial1

ip route 148.14.1.0 255.255.255.0 148.14.4.1

ip route 148.14.3.0 255.255.255.0 serial1

ip route 148.14.1.0 255.255.255.0 148.14.5.1

ip route 148.14.2.0 255.255.255.0 serial1

Both valid styles of static route configuration are shown. In any topological case, the style of

static route command using the next router’s IP address is valid. If the route points to a subnet

that is on the other side of a point-to-point serial link, the static route command can simply refer

to the outgoing serial interface.

Task 4 for Scenario 6-1 asks for IGRP configuration. The same configuration is used on each

router and is listed in Example 6-36. The IGRP process-id must be the same number on each

router; if an IGRP update is received but lists a different process-id, the update will be ignored.

Task 5 for Scenario 6-1 asks for the broadcast addresses for each subnet. These are shown in

Table 6-36.

Refer back to the network illustrated in Figure 6-24 and Table 6-31 to establish the Scenario

6-2 design details and the context of the answers to the four tasks for this scenario.

router igrp 1

network 148.14.0.0

Ethernet off router in Albuquerque 255.255.255.0 148.14.1.0 148.14.1.255

Ethernet off router in Yosemite 255.255.255.0 148.14.2.0 148.14.2.255

Ethernet off router in Seville 255.255.255.0 148.14.3.0 148.14.3.255

Serial between Albuquerque and

Yosemite

255.255.255.0 148.14.4.0 148.14.4.255

Serial between Albuquerque and

Seville

255.255.255.0 148.14.5.0 148.14.5.255

Serial between Seville and

Yosemite

255.255.255.0 148.14.6.0 148.14.6.255

Task 1 for Scenario 6-2 asks for completed configurations, which are shown in Example 6-37,

Example 6-38, Example 6-39, and Example 6-40.

Hostname Atlanta

no ip domain-lookup

!

interface serial0

encapsulation frame-relay

interface serial 0.1

ip address 10.2.1.1 255.255.255.0

frame-relay interface-dlci 41

!

interface serial 0.2

ip address 10.2.2.1 255.255.255.0

frame-relay interface-dlci 42

!

interface serial 0.3

ip address 10.2.3.1 255.255.255.0

frame-relay interface-dlci 43

!

interface ethernet 0

ip address 10.1.1.1 255.255.255.0

Hostname Charlotte

no ip domain-lookup

!

interface serial0

encapsulation frame-relay

interface serial 0.1

ip address 10.2.1.2 255.255.255.0

frame-relay interface-dlci 40

!

interface ethernet 0

ip address 10.1.2.2 255.255.255.0

hostname nashville

no ip domain-lookup

!

interface serial0

encapsulation frame-relay

interface serial 0.1

ip address 10.2.2.3 255.255.255.0

frame-relay interface-dlci 40

!

interface ethernet 0

ip address 10.1.3.3 255.255.255.0

Task 2 for Scenario 6-2 asks for RIP configuration. The same configuration is used on each

router and is listed in Example 6-41.

Task 3 for Scenario 6-2 asks for the broadcast addresses for each subnet. These are shown in

Table 6-37.

hostname boston

no ip domain-lookup

!

interface serial0

encapsulation frame-relay

interface serial 0.1

ip address 10.2.3.4 255.255.255.0

frame-relay interface-dlci 40

!

interface ethernet 0

ip address 10.1.4.4 255.255.255.0

router rip

network 10.0.0.0

Ethernet off router in Atlanta 255.255.255.0 10.1.1.0 10.1.1.255

Ethernet off router in Charlotte 255.255.255.0 10.1.2.0 10.1.2.255

Ethernet off router in Nashville 255.255.255.0 10.1.3.0 10.1.3.255

Ethernet off router in Boston 255.255.255.0 10.1.4.0 10.1.4.255

VC between Atlanta and

Charlotte

255.255.255.0 10.2.1.0 10.2.1.255

VC between Atlanta and

Nashville

255.255.255.0 10.2.2.0 10.2.2.255

VC between Atlanta and

Boston

255.255.255.0 10.2.3.0 10.2.3.255

Task 4 for Scenario 6-2 requires consideration of the effects of split horizon. Split horizon logic

considers subinterfaces to be separate interfaces, in spite of the fact that several subinterfaces

share the same physical interface. Boston advertises about 10.1.4.0 in its RIP update only out

its subinterface 1. All other routes in Boston’s routing table were learned through RIP updates

from Atlanta, via updates entering that same subinterface; therefore, Boston will not advertise

about those routes in updates it sends on that same subinterface.

The RIP updates from Atlanta to Charlotte, out Atlanta’s subinterface 1, advertise about all

subnets not learned from RIP updates entering that same subinterface. All subnets except

10.1.2.0 (learned from Charlotte) and 10.2.1.0 (subinterface 1’s subnet) will be listed in

Atlanta’s RIP update to Charlotte. Subnet 10.1.4.0, learned from Boston, will indeed be

included in updates to Charlotte; split horizon considers subinterfaces as separate interfaces.

Refer back to the network illustrated in Figure 6-25 and Example 6-24, Example 6-25, and

Example 6-26 to establish the Scenario 6-3 design details and the context of the answers to the

three tasks for this scenario.

Task 1 for Scenario 6-3 asks you to complete a table with the subnet numbers and broadcast

routers in Example 6-24, Example 6-25, and Example 6-26. Table 6-38 lists the subnet numbers

and broadcast addresses requested in this task.

Ethernet off router in

Mayberry

255.255.255.0 170.1.101.0 170.1.101.255

Ethernet off router in Mount

Pilot

255.255.255.0 170.1.102.0 170.1.102.255

Ethernet off router in

Raleigh

255.255.255.0 170.1.103.0 170.1.103.255

VC between Mayberry and

Mount Pilot

255.255.255.0 170.1.1.0 170.1.1.255

Notice that the same subnet was used for all three virtual circuits; a full mesh of virtual circuits

was used and a single subnet was chosen rather than one subnet per virtual circuit.

Task 2 for Scenario 6-3 asks you to describe the contents of the IGRP update from Raleigh, sent

out its virtual circuit to Mount Pilot. Notice that there are four routes in the routing table and

four routes in the routing update. Split horizon is disabled on serial interfaces using Frame

Relay as configured without subinterfaces. Split horizon is disabled by the IOS if using Frame

Relay multipoint subinterfaces as well. Therefore, all four routes in the IP routing table are

advertised in routing updates sent out Serial0.

Mayberry still will have a route to 170.1.1.0/24, which is the subnet covering all the Frame

Relay interfaces in this scenario. Because only one VC went down and the other VC is still up,

it is reasonable to expect that the physical interface is still up. No subinterfaces are configured

in this scenario, so Mayberry still will have a connected route for each interface that’s currently

up, including 170.1.1.0/24 on serial 0.

Refer back to the network illustrated in Figure 6-26 and the command output in Example 6-27,

Example 6-28, and Example 6-29 to establish the Scenario 6-4 design details and the context

of the answers to the four tasks for this scenario.

Task 1 for Scenario 6-4 asks you to complete a table with all IPX network numbers filled in. In

addition, this task asks you to list the command(s) you use to find these network numbers. Table

VC between Mayberry and

Raleigh

255.255.255.0 170.1.1.0 170.1.1.255

VC between Mount Pilot

and Raleigh

255.255.255.0 170.1.1.0 170.1.1.255

these network numbers.

Albuquerque

Albuquerque

Yosemite

Albuquerque

Albuquerque

Albuquerque

Yosemite

Albuquerque

Albuquerque

Albuquerque

Yosemite

Task 2 for Scenario 6-4 asks you to complete a table with the IPX addresses of the three routers.

The network numbers are obtained from several sources, as seen in Task 1. The additional

requirement in Task 2 is to find the node part of the IPX addresses on each interface. The easy

such command was provided in Example 6-27, Example 6-28, and Example 6-29. The output

of the RIP and SAP debugs show the source IPX addresses of the updates sent by each router,

which supplies the rest of the answers to the question. Table 6-40 provides the completed

answers for this task.

Albuquerque E0 1001 0000.0c35.ab12

S0 2012 0200.1111.1111

S1 2013 0200.1111.1111

Yosemite E0 1002 0000.0c24.7841

S0 2012 0200.2222.2222

S1 2023 0200.2222.2222

Seville E0 1003 0000.0cac.ab41

S0 2013 0200.3333.3333

S1 2023 0200.3333.3333

Task 3 for Scenario 6-4 asks you to describe the contents of the RIP update from Yosemite sent

out its serial 0 interface, including the numbers of routes and metrics. First, just finding the

6-15 begins with the phrase “positing full update to 2012.ffff.ffff.ffff . . . .” Remembering that

Yosemite’s S0 interface uses IPX network 2012 is a key to knowing to look for that message.

Three networks are advertised: 1003, 2023, and 1002. The hop count and delay are shown in

and 2013 are left out of the update due to split horizon rules.

Furthermore, this task asks you to determine how many file servers appear to be in the SAP

table, what socket Bugs is using, and, assuming defaults for ticks on each router, whether it is

possible that more than one serial link exists in the route between Seville and Daffy. Two file

servers are listed in the SAP table: Bugs and Daffy. Both are using socket 451, as shown under

link defaults to having six ticks, there could only be one serial link between Seville and Daffy.