You are previewing Network Warrior, 2nd Edition.

Network Warrior, 2nd Edition

Cover of Network Warrior, 2nd Edition by Gary A. Donahue Published by O'Reilly Media, Inc.
  1. Network Warrior
    1. Preface
      1. Who Should Read This Book
      2. Conventions Used in This Book
      3. Using Code Examples
      4. We’d Like to Hear from You
      5. Safari® Books Online
      6. Acknowledgments
    2. 1. What Is a Network?
    3. 2. Hubs and Switches
      1. Hubs
      2. Switches
    4. 3. Autonegotiation
      1. What Is Autonegotiation?
      2. How Autonegotiation Works
      3. When Autonegotiation Fails
      4. Autonegotiation Best Practices
      5. Configuring Autonegotiation
    5. 4. VLANs
      1. Connecting VLANs
      2. Configuring VLANs
    6. 5. Trunking
      1. How Trunks Work
      2. Configuring Trunks
    7. 6. VLAN Trunking Protocol
      1. VTP Pruning
      2. Dangers of VTP
      3. Configuring VTP
    8. 7. Link Aggregation
      1. EtherChannel
      2. Cross-Stack EtherChannel
      3. Multichassis EtherChannel (MEC)
      4. Virtual Port Channel
    9. 8. Spanning Tree
      1. Broadcast Storms
      2. MAC Address Table Instability
      3. Preventing Loops with Spanning Tree
      4. Managing Spanning Tree
      5. Additional Spanning Tree Features
      6. Common Spanning Tree Problems
      7. Designing to Prevent Spanning Tree Problems
    10. 9. Routing and Routers
      1. Routing Tables
      2. Route Types
      3. The IP Routing Table
      4. Virtual Routing and Forwarding
    11. 10. Routing Protocols
      1. Communication Between Routers
      2. Metrics and Protocol Types
      3. Administrative Distance
      4. Specific Routing Protocols
    12. 11. Redistribution
      1. Redistributing into RIP
      2. Redistributing into EIGRP
      3. Redistributing into OSPF
      4. Mutual Redistribution
      5. Redistribution Loops
      6. Limiting Redistribution
    13. 12. Tunnels
      1. GRE Tunnels
      2. GRE Tunnels and Routing Protocols
      3. GRE and Access Lists
    14. 13. First Hop Redundancy
      1. HSRP
      2. HSRP Interface Tracking
      3. When HSRP Isn’t Enough
      4. Nexus and HSRP
      5. GLBP
    15. 14. Route Maps
      1. Building a Route Map
      2. Policy Routing Example
    16. 15. Switching Algorithms in Cisco Routers
      1. Process Switching
      2. Interrupt Context Switching
      3. Configuring and Managing Switching Paths
    17. 16. Multilayer Switches
      1. Configuring SVIs
      2. Multilayer Switch Models
    18. 17. Cisco 6500 Multilayer Switches
      1. Architecture
      2. CatOS Versus IOS
      3. Installing VSS
    19. 18. Cisco Nexus
      1. Nexus Hardware
      2. NX-OS
      3. Nexus Iconography
      4. Nexus Design Features
    20. 19. Catalyst 3750 Features
      1. Stacking
      2. Interface Ranges
      3. Macros
      4. Flex Links
      5. Storm Control
      6. Port Security
      7. SPAN
      8. Voice VLAN
      9. QoS
    21. 20. Telecom Nomenclature
      1. Telecom Glossary
    22. 21. T1
      1. Understanding T1 Duplex
      2. Types of T1
      3. Encoding
      4. Framing
      5. Performance Monitoring
      6. Alarms
      7. Troubleshooting T1s
      8. Configuring T1s
    23. 22. DS3
      1. Framing
      2. Line Coding
      3. Configuring DS3s
    24. 23. Frame Relay
      1. Ordering Frame Relay Service
      2. Frame Relay Network Design
      3. Oversubscription
      4. Local Management Interface
      5. Configuring Frame Relay
      6. Troubleshooting Frame Relay
    25. 24. MPLS
    26. 25. Access Lists
      1. Designing Access Lists
      2. ACLs in Multilayer Switches
      3. Reflexive Access Lists
    27. 26. Authentication in Cisco Devices
      1. Basic (Non-AAA) Authentication
      2. AAA Authentication
    28. 27. Basic Firewall Theory
      1. Best Practices
      2. The DMZ
      3. Alternate Designs
    29. 28. ASA Firewall Configuration
      1. Contexts
      2. Interfaces and Security Levels
      3. Names
      4. Object Groups
      5. Inspects
      6. Managing Contexts
      7. Failover
      8. NAT
      9. Miscellaneous
      10. Troubleshooting
    30. 29. Wireless
      1. Wireless Standards
      2. Security
      3. Configuring a WAP
      4. Troubleshooting
    31. 30. VoIP
      1. How VoIP Works
      2. Small-Office VoIP Example
      3. Troubleshooting
    32. 31. Introduction to QoS
      1. Types of QoS
      2. QoS Mechanics
      3. Common QoS Misconceptions
    33. 32. Designing QoS
      1. LLQ Scenario
      2. Configuring the Routers
      3. Traffic-Shaping Scenarios
    34. 33. The Congested Network
      1. Determining Whether the Network Is Congested
      2. Resolving the Problem
    35. 34. The Converged Network
      1. Configuration
      2. Monitoring QoS
      3. Troubleshooting a Converged Network
    36. 35. Designing Networks
      1. Documentation
      2. Naming Conventions for Devices
      3. Network Designs
    37. 36. IP Design
      1. Public Versus Private IP Space
      2. VLSM
      3. CIDR
      4. Allocating IP Network Space
      5. Allocating IP Subnets
      6. IP Subnetting Made Easy
    38. 37. IPv6
      1. Addressing
      2. Simple Router Configuration
    39. 38. Network Time Protocol
      1. What Is Accurate Time?
      2. NTP Design
      3. Configuring NTP
    40. 39. Failures
      1. Human Error
      2. Multiple Component Failure
      3. Disaster Chains
      4. No Failover Testing
      5. Troubleshooting
    41. 40. GAD’s Maxims
      1. Maxim #1
      2. Maxim #2
      3. Maxim #3
    42. 41. Avoiding Frustration
      1. Why Everything Is Messed Up
      2. How to Sell Your Ideas to Management
      3. When to Upgrade and Why
      4. Why Change Control Is Your Friend
      5. How Not to Be a Computer Jerk
    43. Index
    44. About the Author
    45. Colophon
O'Reilly logo

Chapter 1. What Is a Network?

Before we get started, I would like to define some terms and set some ground rules. For the purposes of this book (and your professional life, I hope), a computer network can be defined as “two or more computers connected by some means through which they are capable of sharing information.” Don’t bother looking for that in an RFC because I just made it up, but it suits our needs just fine.

There are many types of networks: local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), campus area networks (CANs), Ethernet networks, Token Ring networks, Fiber Distributed Data Interface (FDDI) networks, Asynchronous Transfer Mode (ATM) networks, Frame Relay networks, T1 networks, DS3 networks, bridged networks, routed networks, and point-to-point networks, to name a few. If you’re old enough to remember the program Laplink, which allowed you to copy files from one computer to another over a special parallel port cable, you can consider that connection a network as well. It wasn’t very scalable (only two computers) or very fast, but it was a means of sending data from one computer to another via a connection.

Connection is an important concept. It’s what distinguishes a sneaker net, in which information is physically transferred from one computer to another via removable media, from a real network. When you slap a USB drive (does anyone still use floppy disks?) into a computer, there is no indication that the files came from another computer—there is no connection. A connection involves some sort of addressing or identification of the nodes on the network (even if it’s just master/slave or primary/secondary).

The machines on a network are often connected physically via cables. However, wireless networks, which are devoid of obvious physical connections, are connected through the use of radios. Each node on a wireless network has an address. Frames received on the wireless network have a specific source and destination, as with any network.

Networks are often distinguished by their reach. LANs, WANs, MANs, and CANs are all examples of network types defined by their areas of coverage. LANs are, as their name implies, local to something—usually a single building or floor. WANs cover broader areas, and are usually used to connect LANs. WANs can span the globe, and there’s nothing that says they couldn’t go farther. MANs are common in areas where technology like Metropolitan Area Ethernet is possible; they typically connect LANs within a given geographical region such as a city or town. A CAN is similar to a MAN, but is limited to a campus (a campus is usually defined as a group of buildings under the control of one entity, such as a college or a single company).

One could argue that the terms MAN and CAN can be interchanged and, in some cases, this is true (conversely, there are plenty of people out there who would argue that a CAN exists only in certain specific circumstances and that calling a CAN by any other name is madness). The difference is usually that in a campus environment, there will probably be conduits to allow direct physical connections between buildings, while running private fiber between buildings in a city is generally not possible. Usually, in a city, telecom providers are involved in delivering some sort of technology that allows connectivity through their networks.

MANs and CANs may, in fact, be WANs. The differences are often semantic. If two buildings are in a campus but are connected via Frame Relay, are they part of a WAN or part of a CAN? What if the Frame Relay is supplied as part of the campus infrastructure, and not through a telecom provider? Does that make a difference? If the campus is in a metropolitan area, can it be called a MAN?

Usually, a network’s designers start calling it by a certain description that sticks for the life of the network. If a team of consultants builds a WAN and refers to it in the documentation as a MAN, the company will probably call it a MAN for the duration of its existence.

Add into all of this the idea that LANs may be connected with a CAN, and CANs may be connected with a WAN, and you can see how confusing it can be, especially to the uninitiated.

The point here is that a lot of terms are thrown around in this industry, and not everyone uses them properly. Additionally, as in this case, the definitions may be nebulous; this, of course, leads to confusion.

You must be careful about the terminology you use. If the CIO calls the network a WAN, but the engineers call the network a CAN, you must either educate whoever is wrong or opt to communicate with each party using its own language. This issue is more common than you might think. In the case of MAN versus WAN versus CAN, beware of absolutes. In other areas of networking, the terms are more specific.

For our purposes, we will define these network types as follows:

LAN

A LAN is a network that is confined to a limited space, such as a building or floor. It uses short-range technologies such as Ethernet, Token Ring, and the like. A LAN is usually under the control of the company or entity that requires its use.

WAN

A WAN is a network that is used to connect LANs by way of a third-party provider. An example is a Frame Relay cloud (provided by a telecom provider) connecting corporate offices in New York, Boston, Los Angeles, and San Antonio.

CAN

A CAN is a network that connects LANs and/or buildings in a discrete area owned or controlled by a single entity. Because that single entity controls the environment, there may be underground conduits between the buildings that allow them to be connected by fiber. Examples include college campuses and industrial parks.

MAN

A MAN is a network that connects LANs and/or buildings in an area that is often larger than a campus. For example, a MAN might connect a company’s various offices within a metropolitan area via the services of a telecom provider. Again, be careful of absolutes. Many companies in Manhattan have buildings or data centers across the river in New Jersey. These New Jersey sites are considered to be in the New York metropolitan area, so they are part of the MAN, even though they are in a different state.

Terminology and language are like any protocol: be careful how you use the terms you throw around in your daily life, but don’t be pedantic to the point of annoying other people by telling them when and how they’re wrong. Instead, listen to those around you and help educate them. A willingness to share knowledge is what separates the average IT person from the good one.

The best content for your career. Discover unlimited learning on demand for around $1/day.