CCIE Professional Development: Routing TCP/IP pot

CCIE Professional Development: Routing TCP/IP, Volume I

Copyright Information

Copyright© 1998 by Macmillan Technical Publishing

Cisco Press logo is a trademark of Cisco Systems, Inc.

All rights reserved. No part of this book m ay be reproduced or transm itted in any form

or by any means, electronic or mechanical, including photocopying, recording, or by

any information storage and retrieval system, without written permission from the

publisher, except for the inclusion of brief quotations in a review.

Printed in the United States of America 2 3 4 5 6 7 8 9 0

Library of Congress Cataloging-in-Publication Number 98-84220

Warning and Disclaimer

This book is designed to provide information about TCP/IP. Every effort has been

made to make this book as complete and as accurate as possible, but no warranty or

fitness is implied.

The information is provided on an "as is" basis. The author, Macmillan Technical

Publishing, and Cisco Systems, Inc. shall have neither liability nor responsibility to any

person or entity with respect to any loss or damages arising from the information

contained in this book or from the use of the discs or programs that may accompany

it. The opinions expressed in this book belong to the author and are not necessarily

those of Cisco Systems, Inc.

Dedications

This book would not have been possible without the concerted efforts of many

dedicated people. I would like to thank the following people for their contributions:

First, thanks to Laurie McGuire, development editor, who not only improved the book

but improved me as a writer.

Thanks to Jenny DeHaven Carroll and Mike Tibodeau for their careful technical editing.

I would also like to thank the following people, who provided technical advice or

reviews on selected sections of the book: Howard Berkowitz, Dave Katz, Burjiz

Pithawala, Mikel Ravizza, Russ White, and Man-Kit Yueng.

I would like to thank the following people at Macmillan Technical Publishing: Tracy

Hughes and Lynette Quinn, who managed the project, and Julie Fairweather, the

Executive Editor. In addition to being highly competent, they are three of the nicest

people anyone could hope to work with. Also, thanks to Jim LeValley, Associate

Publisher, who first approached me about writing this book.

Thanks to Wandel & Golterman, and to Gary Archuleta, W&G's Regional Sales

Manager in Denver, for arranging the use of one of their excellent protocol analyzers

for the length of the project.

Finally, I want to thank my wife, Sara, and my children: Anna, Carol, James, and

Katherine. Their patience, encouragement, and support were critical to the completion

of this book.

Feedback Information

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each

book is crafted with care and precision, undergoing rigorous development that involves the unique

expertise of members from the professional technical community.

Readers' feedback is a natural continuation of this process. If you have any comments regarding

how we could improve the quality of this book, or otherwise alter it to better suit your needs, you

can contact us at ciscopress@m cp.com . Please make sure to include the book title and ISBN in your

message.

We greatly appreciate your assistance.

Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have been

appropriately capitalized. Macmillan Technical Publishing or Cisco Systems, Inc. cannot attest to the

accuracy of this information. Use of a term in this book should not be regarded as affecting the

validity of any trademark or service mark.

About the Reviewers

Jennifer DeHaven Carroll is a principal consultant for International Network Services. She is CCIE

number 1402. Jennifer has planned, designed and implemented many IP networks over the past 10

years, utilizing RIP version 2, IGRP, E-IGRP, OSPF and BGP. She has also developed and taught

theory and Cisco implementation classes on all IP routing protocols.

Michael Tibodeau is a Systems Engineer for Cisco Systems. Over the past two years, Michael has

specialized in security technologies for both his own customers and Networkers audiences. He also

focuses on the Electronic Com m erce and Quality of Service arenas. Michael holds a Bachelor's

degree in Systems Engineering from the University of Virginia and holds a Master's degree in

Systems Engineering and Management, concentrating on telecommunications.

I ntroduction

Routing is an essential element of all but the smallest data communications networks. At one level,

routing and the configuration of routers are quite simple. But as internetworks grow in size and

complexity, routing issues can become at once both large and subtle. Perversely, perhaps, I am

grateful for the difficult problems large-scale routing can present—as a network systems consultant,

these problems are my bread and butter. Without them, the phrase "You want fries with that?" could

be an unfortunate part of my daily vocabulary.

Cisco Certified Internetwork Experts are widely recognized for their ability to design, troubleshoot,

and manage large internetworks. This recognition comes from the fact that you cannot become a

CCIE by attending a few classes and then regurgitating some memorized facts onto a written test. A

CCIE has proven his or her expertise in an intense, famously difficult hands-on lab exam.

Objectives

This book is the first in a series designed to aid you in becoming a Cisco Certified Internetwork

Expert and the first of two volumes that focuses on TCP/IP routing issues. Early in the project, Kim

Lew, Cisco Systems program manager, said, "Our objective is to make CCIEs, not to make people

who can pass the CCIE lab." I entirely agree with that statement and have used it as a guiding

principle throughout the writing of this book. Although the book includes many case studies and

exercises to help you prepare for the CCIE lab, my primary objective is to increase your

understanding of IP routing—both on a generic level and it is implemented on Cisco routers.

Audience

The audience for this book is any network designer, administrator, or engineer who needs a full

understanding of the interior routing protocols of TCP/IP. Although the practical aspects of the book

focus on Cisco's IOS, the information is applicable to any routing platform.

The book is not only for readers who plan to become Cisco Certified Internetwork Experts, but for

anyone who wishes to advance his or her knowledge of TCP/IP routing. These readers will fall into

one of three categories:

The "beginner" who has some basic networking knowledge and wishes to begin a deep study

of internetworking

The intermediate-level networking professional who has experience with routers, Cisco or

otherwise, and plans to advance that experience to the expert level

The highly experienced networking expert. This individual has extensive hands-on expertise

with Cisco routers and is ready to take the CCIE lab; however, he or she wants a structured

review and series of exercises for verification and validation. CCIE Professional Developm ent: Routing TCP/ IP, Volum e I focuses prim arily on the interm ediate￾level networking professional while offering to the beginner a structured outline of fundam ental

inform ation and to the expert the required challenges to hone his or her skills.

Organization

The fourteen chapters of the book are divided into three parts.

Part I examines the basics of networks and routing. Although more advanced readers may wish to

skip the first two chapters, I recommend that they at least skim Chapter 3, "Static Routing," and

Chapter 4, "Dynamic Routing Protocols."

Part II covers the TCP/IP Interior Gateway Protocols. Each protocol-specific chapter begins with a

discussion of the mechanics and parameters of the protocol. This general overview is followed by

case studies on configuring and troubleshooting the protocol on Cisco routers in various network

topologies.

The Exterior Gateway Protocols, as well as such topics as multicast routing, Quality of Service

routing, router security and management, and routing IPv6 will be covered in Volume II.

Part III examines the tools available for creating and managing interoperability with multiple IP

routing protocols, as well as such tools as default routes and route filtering. These chapters, like the

ones in Part II, begin with concepts and conclude with case studies.

Conventions and Features

Most chapters conclude with a set of review questions, configuration exercises, and troubleshooting

exercises. The review questions focus on the theoretical aspects of the chapter topic, whereas the

configuration and troubleshooting exercises address Cisco-specific aspects of the chapter topic.

Also at the end of each chapter is a table with a brief description of all important Cisco IOS

commands used in that chapter. The conventions used to present these commands are the same

conventions used in the IOS Command Reference. The Command Reference describes these

conventions as follows:

Vertical bars (|) separate alternative, mutually exclusive, elements.

Square brackets [] indicate optional elements.

Braces {} indicate a required choice.

Braces within square brackets [{}] indicate a required choice within an optional element.

Boldface indicates commands and keywords that are entered literally as shown.

I talics indicate arguments for which you supply values.

I m portant concepts are called out in m argin notes for quick reference.

Figure I.1 shows the conventions used in the illustrations throughout the book.

Figure I.1. Illustration conventions used in this book.

All protocol analyzer displays shown in the book are taken from a Wandel & Goltermann DA-320

DominoLAN Internetwork Analyzer.

Foreword

In today's world of networking, mission-critical networks are being designed for data, voice, and

video. Due to different traffic patterns and the quality of service required by each type of

inform ation, solid hands-on experience is imperative for managing, designing, and troubleshooting

these networks.

Attaining a strong degree of hands-on experience translates into in-depth understanding of the

concepts, scalability, and deployment issues of today's networks. Such experience also builds the

expertise to analyze traffic patterns and the knowledge of when, where, and how to apply protocol

and bandwidth features to enhance performance.

To help further your hands-on experience, Cisco Press is publishing the CCIE Professional

Development series of books. Books in this series will significantly help your understanding of

protocol concepts, and they provide real-world examples and case studies to strengthen the

theoretical concepts exam ined. I highly recom m end that you use these books as a hands-on

learning tool by duplicating the exam ples and case studies using Cisco products. You can even take

this further by tweaking the configuration parameters to see which changes each network goes

through by using the extensive debugging features provided in each Cisco product.

In the first book of the CCIE Professional Development series, CCIE Professional Developm ent:

Routing TCP/ IP, Volum e I , Jeff Doyle does a fantastic job of building the TCP/IP concepts, from IP

address classes to analyzing protocol metrics. Each chapter contains examples, network topologies

with IP addresses, packet analysis, and Cisco debugging outputs. In my opinion, the best parts are

the case studies, in which Jeff compares different features of the protocol by using more or less the

similar topology. This generates a strong understanding of the protocol concepts and features.

I recommend CCIE Professional Developm ent: Routing TCP/ IP, Volum e I for any networking

certification, and I believe that it also makes an excellent university networking course book.

Imran Qureshi

CCIE Program Manager

Part I: Routing Basics

Chapter 1 Basic Concepts: Internetworks, Routers, and Addresses

Chapter 2 TCP/IP Review

Chapter 3 Static Routing

Chapter 4 Dynamic Routing Protocols

Chapter 1. Basic Concepts: Internetworks, Routers, and

Addresses

Bicycles with Motors

Data Link Addresses

Repeaters and Bridges

Routers

Network Addresses

Once upon a time, computing power and data storage were centralized. Mainframes were locked away in

climate-controlled, highly secure rooms, watched over by a priesthood of IS administrators. Contact with

a computer was typically accomplished by bringing a stack of Hollerith cards to the priests, who

interceded on our behalf with the Big Kahuna.

The advent of the minicomputer took the computers out of the IS temple of corporations and universities

and brought them to the departmental level. For a mere $100K or two, engineering and accounting and

any other department with a need for data processing could have their own machines.

Following on the heels of the minicomputers were microcomputers, bringing data processing right to the

desktop. Affordability and accessibility dropped from the departmental level to the individual level,

making the phrase personal computer part of everyone's vocabulary.

Desktop computing has evolved at a mind-boggling pace, but it was certainly not an immediate

alternative to centralized, mainframe-based computing. There was a ramping-up period in which both

software and hardware had to be developed to a level where personal computers could be taken seriously.

Bicycles with Motors

One of the difficulties of decentralized computing is that it isolates users from one another and from the

data and applications they may need to use in common. When a file is created, how is it shared with Tom,

Dick, and Harriet down the hall? The early solution to this was the storied SneakerNet: Put the file on

floppy disks and hand carry them to the necessary destinations. But what happens when Tom, Dick, and

Harriet modify their copies of the file? How does one ensure that all information in all versions are

synchronized? What if those three coworkers are on different floors or in different buildings or cities?

What if the file needs to be updated several times a day? What if there are not three coworkers, but 300

people? What if all 300 people occasionally need to print a hard copy of some modification they have

made to the file?

The local-area network, or LAN, is a small step back to centralization. LANs are a means of pooling and

sharing resources. Servers enable everyone to access a common copy of a file or a common database; no

more "walkabouts" with floppies, no more worries about inconsistent information. E-mail furnishes a

compromise between phone calls, which require the presence of the recipient, and physical mail service,

which is called snail mail for a good reason. The sharing of printers and modem pools eliminates the need

for expensive, periodically used services on every desk.

Of course, in their infancy, LANs met with more than a little derision from the mainframe manufacturers.

A commonly heard jibe during the early years was, "A LAN is like a bike with a motor, and we don't

make Mopeds!" What a difference a few years and a few billion dollars would make.

NOTE

Data link

Physically, a LAN accomplishes resource pooling among a group of devices by connecting them to a

common, shared medium, or datalink. This medium may be twisted-pair wires (shielded or unshielded),

coaxial cable, optical fiber, infrared light, or whatever. What matters is that all devices attach commonly

to the data link through some sort of network interface.

A shared physical medium is not enough. Rules must govern how the data link is shared. As in any

community, a set of rules is necessary to keep life orderly, to ensure that all parties behave themselves,

and to guarantee that everyone gets a fair share of the available resources. For a local-area network, this

set of rules, or protocol, is generally called a Media Access Control (MAC). The MAC, as the name

implies, dictates how each machine will access and share a given medium.

So far, a LAN has been defined as being a community of devices such as PCs, printers, and servers

coexisting on a common communications medium and following a common protocol that regulates how

they access the medium. But there is one last requirement: As in any community, each individual must be

uniquely identifiable.

Data Link Addresses

In a certain community in Colorado, two individuals are named Jeff Doyle. One Jeff Doyle frequently

receives telephone calls for the person with whom he shares a name—so much so that his clever wife has

posted the correct number next to the phone to redirect errant callers to their desired destination. In other

words, because two individuals cannot be uniquely identified, data is occasionally delivered incorrectly

and a process must be implemented to correct the error.

Among family, friends, and associates, a given name is usually sufficient for accurately distinguishing

individuals. However, as this example shows, most names become inaccurate over a larger population. A

more unique identifier, such as a United States Social Security number, is needed to distinguish one

person from every other.

NOTE

Frame

Devices on a LAN must also be uniquely and individually identified or they, like humans sharing the

same name, will receive data not intended for them. When data is to be delivered on aLAN , it is

encapsulated within an entity called a frame, a kind of binary envelope. Think of data encapsulation as

being the digital equivalent of placing a letter inside an envelope, as in Figure 1.1[1] . A destination address

and a return (source) address are written on the outside of the envelope. Without a destination address, the

postal service would have no idea where to deliver the letter. Likewise, when a frame is placed on a data

link, all devices attached to the link "see" the frame; therefore, some mechanism must indicate which

device should pick up the frame and read the enclosed data. [1] As will be seen later, creating a data link layer frame is really more like putting an envelope inside a larger envelope.

Figure 1.1. Encapsulation means putting data into a frame—a kind of digital "envelope" for delivery.

Figure 1.2 shows the format of most common LAN frames. Notice that every case includes a destination

address and a source address. The format of the address depends on the particular MAC protocol, but all

the addresses serve the same purpose: to uniquely identify the machine for which the frame is destined

and the device from which it was sent.

Figure 1.2. The frame format of a few common LAN data link frames.

The three most common data links currently used in LANs are Ethernet, Token Ring, and FDDI.

Although each link is drastically different from the others, they share a common format for addressing

devices on the network. This format, originally standardized by Xerox's Palo Alto Research Center

(PARC)[2] and now administered by the Institute of Electrical and Electronics Engineers (IEEE), is

variously called the burned-in address,[3] the physical address, the machine address, or most commonly,

the MAC address.

[2] The full name, as reading any modern text on networking will tell you, is The Now Famous Xerox PARC. [3] The address is usually permanently programmed, or burned in, to a ROM on the network interface.

The MAC address is a 48-bit number, which, as Figure 1.3 shows, is designed so that every device

anywhere on the planet should be uniquely identifiable. Most everyone has heard the legends of large

batches of network interface cards being turned out with identical burned-in addresses by unscrupulous

"cloning" companies or as the result of "stuck" programming code. Although most of those stories are

nothing more than legends, one can imagine what would happen if all devices on a LAN had the same

MAC address: Imagine a town in which every resident is named Wessvick Smackley. Men, women,

children, dogs, and cats all named Wessvick Smackley. Everyday communication, not to mention the

career of the town gossip, would be unimaginably difficult.[4]

[4] In real life, duplicate MAC addresses on a network are most likely to occur as the result of network administrators using locally administered addresses. This occurrence is common enough on Token Ring networks that one step of the Token Ring insertion process is a duplicate address

check.

Figure 1.3. A MAC address.

Although the MAC addresses are by convention referred to as "addresses," they are really names. Think

about it: Because the identifier is burned in, or permanently assigned, to a device, it is a part of that device

and goes wherever the device goes.[5]

[5] Although some data link addresses may be or must be administratively configured, the point is that they are identifiers, unique within a

network.

Most adults have several street addresses through their lives, but few have more than one given name. A

name identifies an entity—whether a person or a PC. An address describes where that person or PC is

located.

In the interest of clarity, this book uses the term data link identifier or MAC identifier instead of MAC

address. The reason for making such a distinction will soon be clear.

Repeaters and Bridges

The information presented so far may be distilled into a few brief statements:

A data communication network is a group of two or more devices connected by a common, shared

medium.

These devices have an agreed-upon set of rules, usually called the Media Access Control, or

MAC, that govern how the media is shared.

Each and every device has an identifier, and each identifier is unique to only one device.

Using these identifiers, the devices communicate by encapsulating the data they need to send

within a virtual envelope called a frame.

So here's this wonderful resource-sharing tool called a LAN. It's so wonderful, in fact, that everyone

wants to be connected to it. And herein is the rub. As a LAN grows, new problems present themselves.

The first problem is one of physical distance. Figure 1.4 shows that three factors can influence an

electrical signal. These factors may decrease or eliminate any intelligence the signal represents:

Figure 1.4. Attenuation, interference, and distortion prevent a signal from arriving in the same shape it was

in when it left. Attenuation (a) is a function of the resistance of the wire. A certain amount of signal energy

must be spent "pushing past" the resistance. Interference (b) is a function of outside influences—noise—

which adds characteristics to the signal that should not be there. Distortion (c) is a function of the wire

impeding different frequency components of the signal in different ways.

Attenuation

Interference

Distortion

As the distance the signal must travel down the wire increases, so do the degrading effects of these three

factors. Photonic pulses traveling along an optical fiber are much less susceptible to interference but will

still succumb to attenuation and distortion.

Repeaters are added to the wire at certain intervals to alleviate the difficulties associated with excessive

distance. A repeater is placed on the media some distance from the signal source but still near enough to

be able to correctly interpret the signal (see Figure 1.5). It then repeats the signal by producing a new,

clean copy of the old degraded signal. Hence, the name repeater. Figure 1.5. By placing a repeater in the link at a distance where the original signal can still be recognized,

despite the effects of attenuation, interference, and distortion, a fresh signal can be generated and the

length of the wire extended.

A repeater may be thought of as part of the physical medium. It has no real intelligence, but merely

regenerates a signal; a digital repeater is sometimes facetiously called a "bit spitter" for this reason.

The second problem associated with growing LANs is congestion. Repeaters are added to extend the

distance of the wire and to add devices; however, the fundamental reason for having a LAN is to share

resources. When a too-large population tries to share limited resources, the rules of polite behavior begin

to be violated and conflicts erupt. Among humans, poverty, crime, and warfare may result. On Ethernet

networks, collisions deplete the available bandwidth. On Token Ring and FDDI networks, the token

rotation time and timing jitter may become prohibitively high.

Drawing boundaries between populations of LAN devices is a solution to overcrowding. This task is

accomplished by the use of bridges.[6]

[6] If you cut through the marketing hype surrounding modern Ethernet and Token Ring switches, you'll find that these very useful tools are

merely high-performance bridges.

Figure 1.6 shows the most common type of bridge: a transparent bridge. It performs three simple

functions: learning, forwarding, and filtering. It is transparent in that end stations have no knowledge of

the bridge.

Figure 1.6. The transparent bridge segments network devices into manageable populations. A bridging

table tracks the members of each population and manages communication between the populations.

The bridge learns by listening promiscuously on all its ports. That is, every time a station transmits a

frame, the bridge examines the source identifier of the frame. It then records the identifier in a bridging

table, along with the port on which it was heard. The bridge therefore learns which stations are out port 1,

which are out port 2, and so on.

In Figure 1.6, the bridge uses the information in its bridging table to forward frames when a member of

one population—say, a station out port 1—wants to send a frame to a member of another population: a

station out port 2.

A bridge that only learns and forwards would have no use. The real utility of a bridge is in the third

function, filtering. Figure 1.6 shows that if a station out port 2 sends a frame to another station out port 2,

the bridge will examine the frame. The bridge consults its bridging table and sees that the destination

device is out the same port on which the frame was received and will not forward the frame. The frame is

filtered.

Bridges enable the addition of far more devices to a network than would be possible if all the devices

were in a single population, contending for the same bandwidth. Filtering means that only frames that

need to be forwarded to another population will be, and resources are conserved. Ethernet networks are

divided into collision domains; Token Ring and FDDI networks are divided into multiple rings.

Figure 1.7 illustrates two perspectives of a transparent bridge. It is transparent because the end stations

have no knowledge of it. At the same time, a transparent bridge has no real knowledge of the topology of

a network; the bridge only knows which identifiers are heard on each of its ports.

Figure 1.7. Two perspectives of a transparent bridge.

Some other types of bridges are source-route bridges, source-route/transparent bridges, translating

bridges, and encapsulating bridges. For a complete discussion of bridge issues and functionality, see

Perlman [1992], cited in the recommended reading list at the end of this chapter.

The third problem posed by LAN growth is one of locality. Repeaters allow the distance of a LAN to be

extended, but only within certain geographic limitations. Extending a LAN across the city or across the

continent presents prohibitive costs in physical materials, engineering and construction, and legal issues

such as rights-of-way. Such distances require the use of a wide-area network, or WAN.[7] Table 1.1

compares and contrasts LANs and WANs. [7] A third term, which is falling into general disuse, is metropolitan-area network, or MAN. It is just as well that this term is dying off; it grays

the distinction between a LAN and a WAN. Is a MAN a big LAN or a small WAN? Dying also is a truly bad pun, which is that bridges ensure

that no MAN is an island.

A fourth problem is one of scalability. Bridges allow a network to be segregated into smaller populations

of stations; in this way station-to-station traffic is localized. Certain types of frames cannot be localized,

though. Some applications require data to be broad cast—that is, the data must be delivered to all stations

on a network. Ethernet, Token Ring, and FDDI networks use a reserved destination identifier of all ones

(0? ffff.ffff.ffff) for broadcasting. Bridges must forward a broadcast frame out all ports to ensure that all

stations receive a copy. As a bridged network becomes larger and larger, more and more stations will be

originating broadcast traffic; soon, broadcasted frames cause the network to become congested again.

Table 1.1. Fundamental differences between LANs and WANs.

LAN WAN

Limited geographic area Citywide to worldwide geographic area

Privately owned and controlled media Media leased from a service provider

Plentiful, cheap bandwidth Limited, expensive bandwidth

NOTE

Internetwork

To manage broadcast traffic and other scaling challenges, another kind of boundary is necessary. Bridges

allow the network to be divided into populations of stations, but a way to create populations of networks

within a larger network is also needed. This network of networks is better known as an internetwork. The

device that makes internetworks possible is a router.

Routers

Routers have been known by several names. Back in ancient times when what is now the Internet was

called the ARPANET, routers were called IMPs, for interface message processors.[8] More recently,

routers were called gateways; remnants of this nomenclature can still be found in terms such as Border

Gateway Protocol (BGP) and Interior Gateway Routing Protocol (IGRP).[9] In the Open System

Interconnection (OSI) world, routers are known as Intermediate Systems (IS). [8] The parent of modern packet-switched networks was the AlohaNet, created at the University of Hawaii in the late 1960s by Norman

Abramson. Because routers at that time were called IMPs, Dr. Abramson rather impishly named his router Menehune: a Hawaiian elf. [9] The term gateway is now generally accepted to mean an application gateway, as opposed to a router, which would be a network gateway.

All of these aliases are descriptive of some aspect of what a router does. As interface message processor

implies, a router switches data messages, or packets, from one network to another. As gateway implies, a

router is a gateway through which data can be sent to reach another network. And as Intermediate System

implies, a router is an intermediary for the End System–to–End System delivery of internetwork data.

NOTE

Router

Router, as a name, is probably the most descriptive of what the modern versions of these devices do. A

router sends information along a route—a path—between two networks. This path may traverse a single

router or many routers. Furthermore, in internetworks that have multiple paths to the same destination,

modern routers use a set of procedures to determine and use the best route. Should that route become less

than optimal or entirely unusable, the router selects the next-best path. The procedures used by the router

to determine and select the best route and to share information about network reachability and status with

other routers are referred to collectively as a routing protocol. NOTE

Routing protocol

Just as a data link may directly connect two devices, a router also creates a connection between two

devices. The difference is that, as Figure 1.8 shows, whereas the communication path between two

devices sharing a common data link is a physical path, the communication path provided by routers

between two devices on different networks is a higher-level, logical path.

Figure 1.8. A router creates a logical path between networks.

NOTE

Packet

This concept is vitally important for understanding a router's function. Notice that the logical path, or

route, between the devices in Figure 1.8 traverses several types of data links: an Ethernet, an FDDI ring, a

serial link, and a Token Ring. As noted earlier, to be delivered on the physical path of a data link, data

must be encapsulated within a frame, a sort of digital envelope. Likewise, to be delivered across the

logical path of a routed internetwork, data must also be encapsulated; the digital envelope used by routers

is a packet. As noted earlier, each type of data link has its own unique frame format. The internetwork route depicted

in Figure 1.8 crosses several data links, but the packet remains the same from end to end.

How is this possible? Figure 1.9 shows how the packet is actually delivered across the route:

Figure 1.9. The frame changes from data link to data link, but the packet remains the same across the

entire logical path.

1. The originating host encapsulates the data to be delivered within a packet. The packet must then

be delivered across the host's data link to the local router—that host's default gateway—so the

host encapsulates the packet within a frame. This operation is the same as placing an envelope

inside of a larger envelope, for example, inserting an envelope containing a letter into a Federal

Express envelope. The destination data link identifier of the frame is the identifier of the interface

of the local router,[10] and the source data link identifier is the host's.