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. Al l rights reserved. No part of this book may be reproduced or transmitted 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 publi sher, 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 abou t 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. shal l 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 t echnical 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, Sa ra, 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 b ook 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@mcp.com . Please make sure to include the book title and ISBN in your message. We gre atly 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 acc uracy 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 Commerce and Quality of Service aren as. 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 f or 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 Int ernetwork 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 ont o 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 t hat 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 pri nciple 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 infor mation 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 c ategories: 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 t o 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 Development: Routing TCP/IP, Volume I focuses primarily on the intermediate- level networking professional while offering to the beginner a structured outline of fundamental information and to the expert the required challenges t o 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 leas t skim Chapter 3, "Static Routing," and Chapter 4, "Dynamic Routing Protocols." Part II covers t he 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 router s 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 f or 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 Feature s 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 Cis co - 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. Italics indicate arguments for which you supply values. Important concepts are called out in margin notes fo r 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 networki ng, 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 information, solid hands- on experience is imperative for managing, designing, and troubleshoo ting 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 signific antly help your understanding of protocol concepts, and they provide real - world examples and case studies to strengthen the theoretical concepts examined. I highly recommend that you use these books as a hands- on learning tool by duplicating the examples a nd 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 Development: Routing TCP/IP, Volume 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 t opologies 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 und erstanding of the protocol concepts and features. I recommend CCIE Professional Development: Routing TCP/IP, Volume I for any networking certification, and I believe that it also makes an excellent university networking course book. Imran Qureshi CCIE Prog ram 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 behal f 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 n eed 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 lev el, 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 whic h 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 applicat ions 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 s tep 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 furnis hes 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 service s 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 f ew 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 unshie lded), 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 share d. 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 , i s 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 Co lorado, 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 d esired 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 suf ficient 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 eve ry 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 re ally 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 addr ess 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 fra mes. 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 rea ding 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 M AC 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 R ing 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 ar e 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 mo re 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 re ason 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 d evices communicate by encapsulating the data they need to send within a virtual envelope called a frame. [...]... name implies, the length of the IP header The reason this field is included is that the Options field (described later in this section) can vary in size The minimum length of the IP header is 20 octets, and the options may increase this size up to a maximum of 24 octets This field describes the length of the header in terms of 32-bit words— five for the minimum 160-bit size and six for the maximum... link layers It is described in this section in terms of the OSI physical and data link layers Figure 2.1 The TCP/IP protocol suite The physical layer contains the protocols relating to the physical medium on which TCP/IP will be communicating Officially, the protocols of this layer fall within four categories that together describe all aspects of physical media: Electrical/optical protocols describe... format of the IP packet header, specified in RFC 791 Most fields in this packet have some importance to routing Figure 2.2 The IP packet protocol Version identifies the I P version to which the packet belongs This four-bit field is usually set to binary 0100; version 4 (IPv4) is in current, common use A newer version of the protocol, not yet in widespread deployment, is version 6 (IPv6), sometimes referred... recognizes that the station for which the packet is destined is on its directly connected Token Ring network; C encapsulates the packet in a Token Ring frame with the destination identifier of the destination station and the source identifier of its Token Ring interface The packet has been delivered The key to understanding this entire process is to notice that the frames and their related data link identifiers,... 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... This flexibility makes IP addresses more difficult to manage The basics of administering IP addresses are presented in this section, and then some more advanced techniques are introduced in Chapter 7, "Routing Information Protocol Version 2." The First Octet Rule Without putting too fine a point on it, it can be said that there are three sizes of internetworks as measured by the number of hosts: big,... it was there All these options may be invoked by using the Extended Ping on Cisco routers Record route is used in Figure 2.4, loose source routing and timestamp are used in Figure 2.6, and strict source routing is used in Figure 2.7 Figure 2.6 The Cisco Extended Ping may be used to set parameters in the Options field of the IP header In this example, loose source routing and timestamp are used Figure... 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... 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... largest decimal number that can be described with 16 bits is 65,535, the maximum possible size of an IP packet is 65,535 octets Identifier is a 16-bit field used in conjunction with the Flags and Fragment Offset fields for fragmentation of a packet Packets must be fragmented into smaller packets if the original length exceeds the Maximum Transmission Unit (MTU) of a data link through which they pass . review and series of exercises for verification and validation. CCIE Professional Development: Routing TCP/IP, Volume I focuses primarily on the intermediate-. CCIE Professional Development: Routing TCP/IP, Volume I Copyright Information Copyright© 1998 by Macmillan Technical Publishing Cisco Press logo is