J2P and P2J Ver 1

You have either reached a page that is unavailable for viewing or reached your viewing Iimit for this book.

You have either reached a page that is unavailable for viewing or reached your viewing Iimit for this book.

You have either reached a page that is unavailable for viewing or reached your viewing Iimit for this book.

Senior Project EditorTonya Simpson

Copy EditorMike Henry

IndexerTim Wright

ProofreaderKathy Ruiz

Publishing CoordinatorRomny French

Book DesignerLouisa Adair

CompositorBronkella PublishingLibrary of Congress Cataloging-in-Publication Data is onfil e.Copyright 20 IO Pearson Education, Inc.All rights reserved . Printed in the United States of America. This publi cation is protected by copyright, and permission must be obtained from the publisherprior to any prohibited reproduction, storage in a retrievalsystem , or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write toPearson Education, IncRights and Contracts Departm ent 50I BoylstonStreet, Suite 900

Contents at a Glance

I n trod u ctionCha pter 1 : Using the OSI Model Cha pter 2: Cop per Med ia Chapter 3: Fiber-Optic MediaCha pte r 4: Media Access Con trol Layer Cha pter 5: Data Lin k LayerCha pter 6: Networ k Layer Cha pter 7: Tra ns por t La yerChapter 8: Preventing Problems Cha pter 9: Trou bleshootin gCha pter 1 0: Tro u bleshootin g Media Cha pter 1 1 : Networ k Trou bleshootingA ppen d ix A: Coppe r Test Failu re Ca use Tables A ppen dix B: W aveform Decodin g ExerciseA ppen d ix C: Au to-Negotia tionA ppend ix D: Discover in g Device BehaviorA ppen d ix E: Techniq ues for Trou bleshootin g Switches A ppen d ix F: Simple Netwo r k Ma nagem ent ProtocolA ppen d ix G: Trou bleshooting wit h a Protocol A n alyzerA ppen d ix H: Networ k Dia gnostic Prod ucts Used in This Book Appen dix I: Answers to Chapter Review QuestionsInd ex

Contents

I n trod u ctionBound a r iesMed ia Sta nda rds Developm ent Term sPhy sical Lay erMedia Access Control (MAC) Layer Withi n the Data Link Layer Logi cal Link Control (LLC) Layer Within the Data Link Layer Network LayerTransport Layer Help DeskNetwork Technician Network Engi neer Network ManagerOrganizationTechnical DetailsConventions Used in This Book Suppleme ntal MaterialsCha pter 1 : Using the OSI Model Qu ick Tou r of t h e OSI Mod elSeven Layers of the OSI ModelLay er 7: Applicati on Layer Layer 6 : Presentation Lay er Layer 5 : Session Lay er

Layer 4 : Transport Layer Layer 3 : Network Layer Layer 2 : Data Link Layer Layer 1: Physical LayerNetworking Devices and the OSI ModelRepeaters Bri dges Routers SwitchesSwitch Forwardi ng Techni quesCommon Networking Tools Network Management Tools Protocol AnalyzersHandheld Network Analyzers Cabl e TestersFlow ProtocolsSu m m a ryCha pter Review Questions Ch apter 2: Copper MediaSta n dardsBasic Cable Uses Test Pa ra m etersBasi c Tests and Parameters Requi red for In -Channel Testi n gBasic Frequency-Based Test Parameters Rel ated to In-Channel Testi ngAdvanced Freq uency-Based Test Parameters Related to In-Channel and External Testing

Other Com m only Referenced Test Parameters Test ConfigurationsW ha t Should Be Tested ?Gro u nd in g and Shielding Ca ble Sum maryChapter Review Questions Chapter 3: Fiber Optic MediaSafety

Light GlassStand ardsFiber Optic Cable DesignFiber Cable Construction Cable Constructi on Connector TypesTest Para m etersFiel d Testing ParametersLig ht BehaviorDispersionModal Bandwidth Criti cal Angl e Bending Fi ber Graded IndexLi ght Sources Launch Conditions Mandrels

Mode Conditi oni ng AbsorptionFresnel Reflecti onsFiber Termination PolishFiber Alignment Errors and Manufacturing FlawsTestin g Practices and ToolsTest Methods ToolsLevels of TestingTier 1 Tier 2Precauti ons for Measurem ent and Testi ngSu m ma ryChapter Review Questions

Chapter 4: Media Access Control Layer Ether net and the OSI ModelFra m e St r u ctu r eBits to Byt esBytes to Fiel d Groupings Basic Ethernet Frame Fi el dsTheory of Opera tionInterpacket Spacing Retra nsmi ssion Error Handli ng Dupl exFrame Bursti ng

Auto-Negoti ati onPower over Ethernet (PoE) Ethernet Im pl ementation Detail s 1OMbps Versions of Ethernet 1OOMbps Versions of Ethernetl OOOMb ps Versions of Ethernet l OGbps Versions of EthernetEthernet for Sub scriber Access NetworksSumma ryCha pter Rev iew Questions Chapter 5: Data Link LayerBridgesBri dge Forwardi ng Tabl e Effect of Forwarding PrioritySpanning Tree ProtocolVLANsMAC Control Sublayer Frame Structure Slow ProtocolsLink Aggregati on Subl ayerOperations, Administration, and Maintenance (OAM) Sublay erLogical Link Control St1blayer802.2 LLC802 .2 LLC Field Definitions 802 SNAP

802 SNAP Fi el d Definiti onsNovell Raw Summa ryCha pter Review Questions Chapter 6: Network LayerRoutersOSI Model Impl icati ons: Effect of ForwardingInternet Protocol(IP)IPv4 Add ressingInternet Control Message Protocol (ICMP) IPv6 AddressingICMPv6Summa ryChapter Review Questions Chapter 7: Transport LayerTCP and UDP PortsTransm ission Control Protocol (TCP)TCP Segments and Maxim um Segment Size (MS S) TCP Sockets and ConnectionsOpening and Closing Connections Sequence and Acknowl edgment Number s Retransmissi onSelective Acknowledgment (SACK)Window Size, Wi ndow Scaling, and Sl iding Wi ndow Congesti on ControlTCP Segment Structure

User Datagra m Pr otocol (UDP)User Datagram Protocol (UDP) DatagramStructureSum m a ryCha pter Review Questions Cha pter 8: Preven ting Pro blemsSt ra tegy for Networ k Mainten ance1. Management Involvement in Network Decision Making 2. Preparati on and Planning3. Probl em Preventi on4. . Early Proble 1n Detecti on5. Quick Problem Isolation and Resolution6. Investi ng More i n Tools and Trai ni ng Rather Than Addi ti onal Staff to Accommodate Network Growth7. Qual ity Im provem ent Approach to Network Management and Mai ntenanc eDocu men tationMethodologyDiscovery and Baselini ng Design AssistanceVal idati onCreate a Server Log and Software Library Create a Network Di agramCabl e Pl ant Documentati onDevelop a BaselineTraffic MonitoringProactive Activity and Prepa red nessMonitoring the Physical and MAC Layers

Moni tori ng the Network Layer Monitoring the Transport Layer Appli cati on MonitoringSu m ma r yChapter Review Questions Cha pter 9: Trou bleshootingBest MethodProcessEigh t Key Steps to Successful Trou blesh ootin gStep1. Identify the Exact Issue Step 2. Re-create the ProblemStep 3. Localize and Isol ate the Cau seStep 4. Formulate a Pl an for Solving the Problem Step 5. Implement the PlanStep 6. Test to Verify That the Probl em Has Been Resolved Step 7. Document the Problem and Soluti onStep 8. Provide Feedback to the UserA Place to Star t Su m ma r yCha pter Review Questions

Cha pter 1 0:Tro u bleshooting Media Trou bleshootingCopper MediaToolsGeneral Testi ng and Instal l ation IssuesTrou bleshooting Fiber Optic MediaTools

General Testi ng and Instal l ation Issues Sum maryChapter Review Qu estions Chapter11: Networ k TroubleshootingTools

Cabl e Testers Protocol AnalysisNetwork Management Fl ow ProtocolsHandheld Network Analyzers Advanced Analysis ProductsTrou bleshootin g Gene raliz ed User Com plaintsProbl em : Can't ConnectProblem : Connections That Drop Probl em : Sl ow or Poor Perform anceGeneral Troubleshooting Advice Avoi d Misl eading Sym ptom s Specific Error Ty pesSome Simple GuidelinesSpecific Test Suggesti ons Su m m a ryChapter Review Questions

A ppen d ix A: Copper Test Fa ilure Cause Ta bles WiremapLengthPropaga tion Delay or Del ay Skew

In sertion Loss (Atten ua tion) NEXT and PSNEXTRetu rn LossACRF a nd PSACRF (ELFEXT and PSELFEXT) ResistanceCha racteristic Im ped ance Im pulse Noi seAlien Crosstalk Mitigation

A ppen d ix B: W aveform Decodin g ExerciseModule 1: Counting Systems and Encoding MethodsCou nti ng System sOSI Seven-Layer ModelSignaling and Encoding MethodsMod ul e 2: Decod in g a W aveform into Et her net1OMbps Transmission Process Decod i ng the WaveformMod ule 3: Using Sta nda rds Docu men ts a n d RFCsStandardsand RFCsMod ul e 4: Usin g a Protocol AnalyzerOptiVi ew Protocol Expert in Five Buttons Protocol Expert LabAppen d ix C: Au to-Negotia tion FLP Field DefinitionsBase Page Message PagesUnformattedPages

Extensions to Auto-Negotiati on forl OOOBASE-X Extensions to Auto-Negotiation for lOGBASE-TA ppen d ix D: Discover in g Device BehaviorAt What Layer Does This Device Operate?Test # 1: Basi c Functionality Test #2 : Tl1 e Gray AreaTest #3: Find Any Configured VLANsHow to Use the Test Results Collisi on Domain Broadcast DomainDi fferent Network

Appendix E: Techniques for Troubleshooting SwitchesW ha t Pro bl ems A re E ncou n tered in Switched E nviron men ts?How Do You Find Whi ch Port or Switch Has a Probl em?Techniques for Trou bleshooting a Switch Method1: Access the Switch Consol e Method 2: Connect to an Unused Port Method 3 : Configure a Mirror or Span PortMethod 4 : Connect to a Tagged or Trunk Port Method5 : Insert a Hub into the LinkMethod 6: Pl ace the Tester in Seri es Method 7: Pl ace a Tap Inline on a LinkMethod8: Use SNMP-Based Network ManagementMethod 9: Have the Switch Send Fl ow Tech nol ogy Sum maries Method10: Set Up a Syslog ServerMethod11: Use the Server (Host) Resources

Method12 : Use a Combi nati on of MethodsTroubleshootin g Methods: Conclusion

A ppen d ix F: Simpl e Networ k Ma nagem ent Protocol SNMP OperationSNMPv l SNMPv2 SNMPv3SNMP Use

Appendix G: Troubleshooting with a Protocol Analyzer U nd ersta nd ing a W eb Page Con nectionDNS QueryARP QueryTCP Connecti on Data TransferCl osing the Connection DNS FailureProtocol Analyzers and Protocol Knowledge

A ppen d ix H: Networ k Diagnostic Prod ucts Used in This Boo k What Tool to Start With?Network Operati ons Network Engi neering Network TechniciansNetwork/PCSupport Help DeskMed ia TestDTX1800 Cable Analyzer OptiFi ber Certifyi ng OTDR

Anal y zeAi r Wi-FiSpectrum AnalyzerNetwork Analysis: Hybrid HandheldsOptiVi ew EtherScope NetToolLin k.Ru nn erProtocol AnalysisCaptureBuilt-in Featu resAl arm s and Tri ggersData Storage and ReportingFlow Protocols An alysisVisual Performance Manager Visual UpTime SelectNetFl ow TrackerAppli cation Performance

Appen d ix I: A nswers to Cha pter Review Qu estions Chapter1Cha pter 2 Cha pter 3 Chapter 4 Cha pter 5 Cha pter 6 Chapter 7 Cha pter 8 Cha pter 9 Chapter10

Cha pter 1 1 Index

Acknowledgm ents

Many peopl e won't be mentioned here, mostly because this book has grown and evolved from hundreds of comm ents, corrections, short training sessions (given and received), opportunities to help troubleshoot something, and many other sources over many years. I coul d not possibly remember them all . If you taught me some of that information, thank you. Some of the significant contributors (knowingly or otherwise) I remember specifically include The volunteer NOC team at the Interop trade showthank you for regularly scheduling n etwork emergencies! Too many to name specifi cally . Coworkers at Fluke Networks, especially Hugo Draye, Tami Settergren, Dan Klimke, and Pat Donahoo (each for different types of contribution). The University of New Hampshire Interoperability lab, especially Bob Noseworthy and Ben Shultz. My reviewers, especially Nolan Fretz, who took a lot of extra time to point out where some really obscure details were wrong.

About the Author

Neal Allen is a senior staff engineer in the Technical Assistance Center (TAC) at Fluke Networks in Everett, Washington focusing on escalated issues related to Fluke Networks'server-based monitoring soluti ons. His responsibilities in TAC are the particularly difficult or obscure problems, both phoned in and at various customer sites around the world. He also works closely with the design engineers on new product or feature specifi cations and later on alpha and beta testing of the same. Previously he was a product manager for handheld network analyzers. His responsibilities in marketing were "anything the engineers don't do," including market research, writing manuals and literature, helping to specify and beta test new products and product features, attending and delivering papers at trade shows, and providing both training and sales support worldwide. Allen has been involved in network design, installation, andtroubleshooting for nearly 20 years. Although his focus has been primarily OSI Lay er 3 and below, he has also designed and taught a number of short seminars and a three-quarter introdu ctory networking course at local community colleges. Allen has been a member of the Interop trade show NOC (Network Operations Center) team since 1993 and, in addition to other responsibilities, is responsible for troubl eshooting show-floor problems at the Las Vegas and New York Interop trade shows . Allen was chosen to help support and troubleshoot the network for the1996 Atlanta Olympic Games.

How would you troubleshoot your network if denied the console password?

Introduction

Network Maintenance and Troubleshooting Guide: Field- Tested Solutionsfo r Everyday Problems is not about routers or operating systems. Fluke Networks specializes in network diagnostic and monitoring tools, so the focus this book provides is on those areas, which have not been as well served by other industry publi cations and training. Although I have noticed that many networking professionals have either forgotten or never knew much of the material, the book presents some of the knowledge and skills that are most needed by a network technician.Here's an example: I was fortunate enough to be allowed to help support the 1996 Olympi cs in Atlanta . The network engineers who deploy ed the network were very knowledgeable about architecture, design, and equipmentconfigurati on, but seemed oddly unaware of some of the basics. The following incident marked the beginning of mysuspicion that this was a common situation.Several of the competition venues were experienci ng exceptionally high levels of MAC Layer errors. Walking onto the ground s for one of the venues I observed that network cabling around the site was carefully placed up against walls and fences to protect it from being walked on. We went into the local wiring closet and looked at the errors being reported by the network infrastructure equipment . I left the network engineer checking the configuration of the routers and other gear, looking for clues to the problem.I walked around the venue following the cables. For at least half of the cable path, I found the network cable lying on top of a considerable sprawl of208- volt power lines that also followed the walls and fences to where they were needed. As I walked around the field I moved the network cables as far from the power lines as I could without placing them at risk for damage. When I returned from my walk, the engineer commented something about how the error level was pretty bad when we got there, but sort of faded away while he was troubleshooting. I related how the errors pointed to AC poweror other noise source as a likely cause of the errors, and what I had done.

To my great surprise, I had to explain the characteristi cs of each of the reported errors, and how the errors suggested the power lines as a likely cause of the problem . I since came to realize that even when peopl e I met had vastly more knowledge about many networking topics than I, it was still possibl e they had little or no knowledge about the basics presented in this book. Or justas likely, they learned this inform ation a long time ago but have since forgotten it.In order of appearance, this book is written for the following three purposes : Basic networking skills training textbook "Triage" guide for new network technicians or managers of a small network Reference for networking professionalsThis book is an introductory-level text, whi ch means "make it simple." This concept of "simple" has been challenged almost every time it was made. The most difficult job in writing the book was to decide what to condense to a few often overly simplistic statements or exclude altogether. Still, many readers will find the level of compl exity to be a chall enge with even what little was retained as "the simple version." Reading passages multiple times has been reported as an effective method for eventually grasping most of, if not all, the content.Still, be warned that although every effort was made to ensure accuracy, it is sadly true that anything printed undoubtedly has inadvertent errors, important omissions, and superseded facts . Your challenge is to learn enough to be capable of identifying them .Knowing where to obtain accurate information about networking topics is a critical skill . References are provided for many details within this book as a starting point for further reading because it was so hard to locate them in the first place.

Boundaries

The maj ority of the inform ation about troubleshooting OSI Layers 1-3 can be generic in nature. After you cross certain boundaries, the discussion requiresthat a probl em be fully defined before the discussion can continue. For example, application troubleshooting requires a detail ed description of the exactapplication, install ation, configuration, and usage patterns before a

troubleshooting discussion can commence . Troubleshooting data flow from a PC to a server on the same broadcast domain does not. Troubleshooting data flow betweena PC and a server separated by a router might require some additional details, depending on whether advanced functions are enabled (such as access control lists [ACLs], firewalls, or load balancing).Similarly, as soon as you depart from how data traverses a routed network and enter a discussion about how the routers should be configured, you must provide a detailed description of the routing protocols used, vendor router models and versions involved, and so on before you can effectively discuss theconfigurati on or troubleshooting of the confi guration.The topics in this book tend to stop at those boundari es. This is for the reason stated (you have to define the problem first), and also because once y ou reach those boundaries there are existing vendor training courses and vendor or industrycertifications that cover the topics more effectively . The lack of extensive details on 802. 11 wireless is perhaps the most noteworthy exampl e of what is omitted, but very good wireless certification courses are avail able.

Media Standards Development

This is a politically sensitive topic because the whole issue of cabling standards development is as much driven by politics as technology, but still bearsmention. Analysis of the general evolution of cabling standar ds suggests that the following m ay be true: The research into emerging new cable technologies is arguablypushed forward more by the Telecommunications Industry Association (TIA) than the International Organizati on for Standardization (ISO) because the TIA working groups meet more frequently . The Institute of Electrical and Electronics Engi neers (IEEE) play s an important role, too, because the new networking implementations often drive some of the changes to cabling standards. Other national standards appear to leverage the information found in the TIA and ISO standards bodies' results, and then apply additional research in specific areas or apply modifications suitabl e for the local in-countryelectrical codes and requirements.

As a result of this nonscientific determination, the cabling references in thisbook will be largely made using TIA cabling standard references. Also, Fluke Networks is more closely involved with the TIA standards and working group documents, and subject matter experts are readily available.

Terms

One of the more confu sing things about learning networking is the way terms are alway s changing. Compound this with the common practice of incorrectly using terms for the topic of discussi on, or using correct terms to describe related areas where the term is imprecise or inaccurate . Finally, acronyms have an amazing capability to look the same, despite having completely differentmeanings if the entire terms are given. There are many exampl es of a singl e networking acronym having multiple uses depending on the context.Ifcare is taken to stay with proper terminology use, the movement of data through the OSI Model is accompani ed by changes in terms as the data passes between lay ers. In common speech, this would be somewhat confusing,especi ally to someone new to networking. Understanding that terms are used very casually will greatly assist y our ability to follow the conversation without becoming confused. In general discussion, try to focus on the conversation topic and less on the terms. If the situation relates to training, hold the instructor accountabl e to present new information using the correct terminology and ask for clarificationoften.As an example, the words fr ame and packet are perhaps the most comm on terms used to describe a unit of data sent over the network. The following are listed terms taken from the standards documents used to define networking, and are thus the "correct" term used at each stage at which the unit of data travels. In a discussion,frame and packet m ay be used loosely to describe a unit of data, and might not be being used specifically to identify the OSI layer at whi ch the transfer is being discussed . It is easy to imagine that changing terms during a short discussion to maintain strict accuracy would likely prove more confusing than enlightening.

Physical LayerThe term packet describes an 802.3 Ethernet transm ission event that includes all Ethernet fields from the Preamble to the Frame Check Sequence (FCS). The Preamble and Start of Frame Delimiter (SFD) fields are timing information and are discarded later, but are included in a packet.

Media Access Control (MAC) Layer Withinthe Data Link LayerThe term.frame describes the portion of an 802.3 Ethernet transmission event after the timing inform ation has been discarded . The fields from the destination address to the FCS are counted, and tested for errors and against minimum and maximumsize limits at the MAC Layer, and are described as a.frame .

Logical Link Control (LLC) Layer Within the Data Link LayerThe 802.2 standar d uses protocol data unit (PDU) to describe a transmission handl ed by the LLC Layer.

Network LayerInternet Protocol (IP) (see RFC 791 for more inform ation) uses datagram to describe a transmission unit handled by the Network Layer .

Transport LayerUser Datagram Protocol (UDP) (see RFC 768) uses datagram, whereas Transmission Control Protocol (TCP) (see RFC 793) uses segment to describe a transmission unit handled by the Transport Layer.A level of imprecision also appears in rel ation to terminology used to describe a device connecting to the network. It is not uncommon to have more than one term used in the same sentence and intended to apply to the same device.At the Network Layer it is common to use host to describe any deviceparticipating in the IP protocol. At almost any layer it is just as likely to hear device, station, or a specific functional termsuch as PC, router, or sw itch to describe a device participating on the network. Again, understand that it is common to use these terms somewhat interchangeablyin discussion, and that

unless great precision is being used, any one of these terms (or others not mentioned) simply refers to a device connected to the network.Another set of terms used in this book relates to the j ob performed. Job titles carry enormous significance in some organizations and little at others. The j ob descriptions that follow are used in this text and are based on routine tasks and network access. Adapt them to your organizationas appropri ate. (See the "W hat Tool to Start With" section at the beginning of Appendix H for more detailed descriptions.)

Help DeskDaily routine involves helping users with the installed applications on their computer. A small amount of basic connectivity troubleshooting may be involved but is typically limited to obtaining link state from the network. Most activities are handled by telephone and by remote access sessions. If onsite support is appropri ate, it is typically limited to the user's workspace and does not carry beyond the first switch port.

Network TechnicianDaily routine involves interacting with Help Desk staff to carry problem resolution beyond the first switch port. The j ob responsibilityof a technician is the network and not the user . Techni cians m ay have the password to switches, but typically do not have router passwords. Responsibilities are typicallyrestri cted to a site.

Network EngineerDaily routine involves configurationand maintenance of the routed infrastructure for a regi on or entire enterprise network.Some assistance is provided to techni cians as problem escalation support. Network engineers are also involved in architecture design and planning for network expansion.

Network ManagerDaily routine involves liaison activities with the company management, collaborati on with the network engineer at conceptual level, and policydevelopment for all network support activities. Depending on personal technical

qualifications, a network manager may or may not have switch and router passwords, but does not routinely change configurations even if passwordsare available.

Organization

Other than the obvious adherence to how the OSI Model is organized, it might seem odd that the first eight chapters appear as a networking tutorial and the good stuff about troubleshooting and observed network behavior does not appear until close to the end of thi s book. There is a simple reason for thi s: The troubl eshooting inform ation will not be as effective unless the theory is understood first .As a simple exampl e, the Fluke Networks support line often receives call s that go something like this:Caller: I have one of your (insert product name), and I would like some help finding the source of a broadcast storm.Support: Would you start by describing the symptoms your (product) is displaying that indicate a broadcast storm?Caller: (Product) is showing 100% broadcasts on my network. Support: And what is the network utilization?Caller: ... That's odd. There is only 0.02% utilizati on . Support: Are you connected to a switch?Caller: Yes, but why do you ask?The next few minutes are spent explaining how bridges operate. After reading this book, it is hoped that you will see humor in that support call. There are several common networking scenarios that appear in support calls and are similar in nature to the incident describedall of which are resolved byexplaining basic networking principles to the caller. They tend to fall into twocategories : a lack of understanding of the basic principles, which leads to incorrect conclusions; and a lack of understanding of the normal causes of observed symptoms, which prevents formul ation of a troubleshooting plan. One follows the other.

The OSI Model presents a common framework for how similar or dissimilar networks may be described and interconnected. The model further provides boundari es where certain types of inform ation is handed off under specific conditions. This model is a critical part of learning networking, although most beginning students see it as a boring waste of time. Because the OSI Model is the roadmap for all of networking, it is presented first. Without the OSI Model, it is parti cularly difficult to integrate networking theory and specific product information into an internally understood flow or process that will help you do y our j ob.Following the OSI Model you will find what amounts to the theory of operation for cabling, Ethernet, bridging and related protocols, and so on, up to OSI Layer 4. As menti oned earlier, it is not possible to cover everything . Look on this book as an introduction to networking, which uses TCP/IP and Ethernet operatingover either twisted-pair or fiber optic cable system s as the example .The troubl eshooting section (Chapters 9-11) attempts to follow the same OSI Model order, although the m ateri al in Chapter 11 is separated into severaldifferent approaches or views. Troubl eshooting is largely limited to ensuring that there was end-to-end delivery across the network infrastructure.Troubl eshooting of higher-layer problems (OSI Layer 5 and higher), and modifications to end-to-end delivery, such as quality of service and security , are all outside the scope of this book.At one time or another, most experts comment that "the more I learn, the more I realize I don't know." It is hoped that when you reach the end of a section or chapter you will realize that there is a lot which was not covered . When y ou reach the end of a chapter you should be full of unanswered questions. Enough references are cited that you should have an idea of where begin looking for answers.

Technical Details

There is a strong presence of protocol and frame detail in this book . There are two reasons for this substantial addition to the book: Most of the protocols listed in thi s book are unknown to the average user, and only a few fields are known

to many technicians. Having a simplified summary makes reading the standards easier.One of the ways to learn how things work and behave is to learn how vari ous categories of devices talk to other categories of devices on the network. If you know how the conversationor negoti ation is supposed to go, and which conversati ons are expected between like and unlike device categories, it is a lot easier to discover what is wrong when the conversati on or negotiation is not producing the desired results.Success with protocol analysis often comes down to knowing a lot about each specific protocol, and protocol analyzers are one of the four fundamental tool groups used to support networks. As a result, a lot of basic protocol and field details are presented in this text to serve as a reference for networki ng professionals, as well as a source of instruction for novices. These details are carefully presented in context and by the correct OSI Layer where they appear.In at least one place in this text the level of detail far exceeds that which an average network technician or engineer would use in the course of supporting a network. The level of detail in the Ethernet implementations section wasprovided because it is not commonly described anywhere else (except the hard to-read 802.3 standard), and it helps the reader to understand why the media test standards are as stringent as they are. There is a statement immedi ately prior to the excessively detailed section advising the casual reader to skip much of it.

Conventions Used in This Book

This book is straightforward, with justa few conventi ons to watch for: See references. Throughout many sections within each chapter, you'll see cross-references to other documentati on, which look like this: [See 802. lD]. If the topic is of special interest, if ambiguity remains after reading the section (much was summ arized or skipped), or if detailed questions remain, the cited standar d or other docum ent represents a good place for further reading about that topic. In most cases the cited reference provides either the most appropriate starting place or the most complete descripti on for the topic located during my research.

Each chapter closes with the section, "Chapter Review Questions," which give you hands-onpractice with the chapter's content. Here is a general legendthat indicates the anticipateddifficulty of each question:

Concept reinforcement. This is supposed to be extremely easy.

The concepts were presented, but you must apply them to answer this question.

Challenge question. If you understood the inform ation presented, it ispossible to answer this questi on.

Supplemental Materials

Visit this book's website at www .informit .com/titl e/978032 1647412 for supporting materials, including suppl emental charts and graphs.

Chapter 1. Using the OSI Model

This book, and most other things related to networking, is best understood when aligned with or compared to the Open Systems Interconnection (OSI) Model for network communications.Infact, it is exceptionally frustrating to troubleshoot today's networks without understandingexactly which layer(s) each of the network infrastructure devices operate at and how that affects the flow of traffic and errors.

Quick Tour of the OSI Model

The OSI seven-layer basic reference model (see Fi gure 1-1) was created by the Internati onal Organization for Standardization (ISO) as standard ISO/IEC 7498. At the time of its creation the various networking protocols available were proprietary and offered little or no interoperability. The OSI seven-layer model has since becom e the most common reference point used when discussing network protocols, features, and hardware.Figure 1-1.0SJ seven-layer model comp ared to various interconnect device jun ctions and media access protocols

(.!_) Logical Llnk Control Sublayer 1.ile