Local Area Network Handbook, Sixth Edition

John P. Slone, John P. Slone

• Publisher: Auerbach Publications
• Year: 2020
• ISBN:
  9781000152753
• Edition: 6
• Topic: Informatik
• Subtopic: Computernetzwerke

Today's enterprise cannot effectively function without a network, and today's enterprise network is almost always based on LAN technology. In a few short years, LANs have become an essential element of today's business environment. This time in the spotlight, while well deserved, has not come without a price. Businesses now insist that LANs deliver vast and ever-increasing quantities of business-critical information and that they do it efficiently, flawlessly, without fail, and most of all, securely. Today's network managers must consistently deliver this level of performance, and must do so while keeping up with ever changing, ever increasing demands without missing a beat. At the same time, today's IT managers must deliver business-critical information systems in an environment that has undergone radical paradigm shifts in such widely varied fields as computer architecture, operating systems, application development, and security. The Local Area Networks Handbook focuses on this collective environment, in which networking and information technology work together to create LAN-based enterprise networks. Topics have been selected and organized with this in mind, providing both depth and breadth of coverage. The handbook will provide you not only an understanding of how LANs work and how to go about selecting and implementing LAN products, but also of how to leverage LAN capabilities for the benefit of your enterprise.

Section 1

LAN Basics: Building Blocks of the Enterprise Network

Enterprise networks, no matter how large or small, must begin with the basics. To help the LAN or IT manager who needs to make sense of the sometimes bewildering array of ever-changing technology, this section of the Handbook provides an overview of a number of basic LAN technologies and standards, with an emphasis on building solid, reliable LANs, from which solid, reliable, high-performance enterprise networks can be built.

Having emerged from the laboratory little more than a decade ago, LANs have now taken center stage in most enterprise networks. As such, reliability is of paramount importance for today’s LAN managers. Chapter 1, “Building Highly Reliable Computer Networks,” investigates several factors to consider in the fault tolerance equation. In this chapter, aspects of network infrastructure component reliability are considered from the perspective of attaining fault tolerance at each of the first three layers of the OSI model.

In addition to reliability, a key design criterion in today’s LANs is performance. Although most LANs currently support transmission speeds of 10 to 100 megabits per second, today’s network designer must consider the needs of the next few years. Accordingly, Chapter 2, “Gigabit Ethernet,” discusses the application trends leading to the requirement for gigabit transmission capacity, describes in significant detail how the technology works, and assesses the technology’s status with respect to the IEEE standardization process and industry support.

While an understanding of transmission technology is essential for today’s LAN manager, it is equally important to keep in mind that the ultimate purpose of a LAN is to actually move data, most often back and forth between user workstations and servers. In building a LAN-based enterprise network, it is not sufficient to limit one’s thinking to the delivery of data to or from the server’s network interface card. Rather, it is important to also consider movement of the data inside the server. Chapters 3 and 4 provide insight into two important aspects of server architecture, each of which can play a significant role in overall LAN performance. Chapter 3, “Processor Types,” focuses on CPU architecture, illustrating why it is essential to consider more than just the CPU’s model number and clock rate when designing server systems. Chapter 4, “Server Data Bus Structures,” discusses the architecture of the data bus, providing insight into the complex relationship between CPU speed, network interface cards, and disk I/O. Together these chapters provide the LAN and IT managers with information needed to ensure that the server’s performance is optimized.

Not all LAN-related considerations have to do with reliability or speed. As such, Chapter 5, “Dynamic IP Addressing with DHCP,” addresses a topic that solves problems related to the explosion of devices connected to the global Internet coupled with the proliferation of affordable laptop computers and the resulting increase in the need to provide connectivity for mobile users. The chapter looks at the evolution of dynamic IP addressing and discusses specifics of how DHCP works in today’s networks.

Until recently, the networking market was effectively closed to small businesses. LANs and enterprise networks were the exclusive domain of larger businesses that could afford to keep seasoned networking professional on their payrolls. Due in large part to the success of the IEEE 802.3 family of standards, reliable, interoperable LAN components have become both affordable and readily available, opening this market to companies of any size. Chapter 6, “LAN Connectivity Options for the Small Business,” discusses options available for companies in the 2 to 100 user range. Many of these options are equally applicable to the home office, for telecommuters, or for small field offices needing to participate in the larger corporate network.

Since the earliest days of LANs, the ability to share printers has been both a popular and important application of LAN technology. Chapter 7 explains “LAN Printing Techniques,” including several methods of printer attachment currently available, and discusses the factors that should be considered in evaluating the basic options.

Fundamental to any enterprise network is the need to protect the information traversing it. One of the most basic means of protecting that information is through the use of encryption. Encryption, or more accurately, the science of cryptography, while not sufficient to secure a network, is certainly essential. Chapter 8, “An Overview of Cryptographic Methods,” provides a good survey of the field, providing the reader with the background necessary to understand the choices available and how to select the appropriate cryptographic mechanisms for his or her network environment.

Rounding out the section on LAN Basics is a chapter that takes a look at a serious security threat rooted in fundamental LAN management. Long regarded by LAN managers as an essential tool in the diagnostic toolbox, the sniffer has also emerged as one of the most serious threats. Chapter 9, “Assessing and Combating the Sniffer Threat,” examines the nature of this threat and proposes several steps that can be taken in response.

Chapter 1

Building Highly Reliable Computer Networks

Richard Rauscher

Highly reliable computer networks are becoming increasingly essential in industries in which real-time transactions occur. The health care industry depends on information systems not only for business operations but also for critical care: Patient monitoring systems now rely on computer networks for communications. What would happen if the nurses’ station didn’t get a message indicating that a patient was in cardiac arrest? Law enforcement and emergency services are using information systems for every part of their function: A working computer at the dispatchers’ office can be the difference between a police officer knowing if the car he just pulled over was simply committing a speeding violation or contains a wanted murderer. In these and many other instances, the computer network can be the difference between life and death.

Vendors sell products based on performance. Engineers often buy products based on performance. With the speed of common local area networks (LAN) increasing tenfold every few years, “more power” should be the slogan for the network architect of the 1990s. Does all this increased bandwidth really translate to any tangible benefit? That depends on network utilization and applications. Maintaining good utilization statistics helps the network engineer make this decision. These statistics may also indicate that there is no current requirement for more bandwidth. Budget money would be better spent elsewhere. It may be time to concentrate on making the computer network more reliable rather than faster.

If the network architect is building a network on which others’ lives will depend, she must ask herself if she would let her life depend on this network. If the answer is “no,” she needs to make immediate changes: either to the network infrastructure or to her choice of careers.

The reader may already be an expert in finding network performance bottlenecks. This chapter helps the reader to identify reliability bottlenecks. The chapter focuses strictly on network infrastructure components and only briefly mentions server and client issues. It discusses the following issues: device reliability, environmental issues, physical layer issues, link layer issues, network layer issues, and network management. The reader should have a good understanding of the functions of the Open Systems Interconnection (OSI) stack before perusing this chapter. Purchasing reliable equipment and installing redundant equipment will help the network architect build a highly reliable network.

DEVICE RELIABILITY METRICS AND RATINGS

A computer network is simply a collection of cables and electronic devices connected in a particular way to facilitate communications between two or more computers. Examining each of the components in a computer network helps readers analyze the risk (probability) of network failure.

An important but often overlooked and understudied device specification, the mean time between failures (MTBF), can be used by network planners to maximize the reliability of their design. The MTBF is the only metric supplied by the manufacturer that can be used to evaluate the expected reliability of a product. In most cases, the vendor is self-reporting this information. But even assuming that the vendor is honestly disclosing its MTBF numbers, what does this number mean? Let us first examine the ways in which vendors compute their MTBF number and then use these numbers to calculate our own MTBF odds based on the network model below.

1. To get a product to market quickly (which is necessary in the competitive marketplace), the vendor is likely to take a large number of devices and run them continuously for some predetermined period. The MTBF is calculated by taking the total, cumulative running time of each device and dividing it by the number of failures. For example, if a vendor ran 10 devices for 1,000 hours each and 2 failed during that time, the total number of hours is 10,000/2 = 5,000 MTBF.

2. Vendors often do not consider an initial “burn-in” period (the initial period that a device is powered and running).

3. Vendors may or may not consider real-world effects, such as applying and removing power on a regular basis, handling during shipping, handling during installation, and so on.

4. Vendors may or may not be computing the MTBF as a function of the combined MTBF of all the devices’ components, plus some operational probability of failure.

5. Vendors expect the unit to degrade below the stated MTBF after the period stated as its usable life has elapsed.

Exhibit 1.1. A simple network diagram

The responsible network engineer will ask vendors how they compute their MTBF ratings. The engineer should not be surprised if the salesperson needs to call headquarters to obtain this information. A few rules of thumb should apply:

1. Do not trust the vendor’s self-reported MTBF exclusively; read trade magazine articles about that vendor.

2. Allow a burn-in period for every device placed on the network; to effectively “burn-in” a new device, no activity is required—the device just needs to be turned on.

Analysis of a Simple Network

It would be helpful to examine the simple network model in Exhibit 1.1.

Exhibit 1.1 represents a simplified LAN model in which two computers are communicating via a hub. For simplicity, assume that this network is based on Ethernet. What can go wrong with this network? Ignoring the computers, the component parts of this network are the following:

1. Both cables from computer to wall.

2. Both cables from wall, through wall, to back of patch panel.

3. Both cables from patch panel to hub.

4. The hub’s internal electronics.

5. The hub’s power supply.

6. The power feeding the hub’s power supply.

Six of the nine components of this network are cables. Without any MTBF data on the rate of failing cables, common sense is necessary. Three assumptions are necessary: (1) cables that move are more likely to break than cables that do not; (2) cables that do not move and will not break; and (3) before a cable is put into production, it is tested. Given these assumptions, cables that are subject to human interaction are more likely to move; therefore, cables that are subject to human interaction are more likely to break. Therefore, the cables that connect the back-of-the-wall jack to the back-of-the-patch panel are the least likely points of failure. If we can further assume that one of these computers is a server and one is a client and that the server is seldom subject to human interaction, we can also deduce that the cable from the server to the wall jack carries a reduced probability of failure.

Given the lack of supporting data, assume that the hub has a significantly higher probability for failure than any cable in the network. This may be because the hub is an active, electromechanical device. The hub is considered mechanical because it contains (usually) an electrical fan. That fan may have been constantly accumulating dust since the day it was turned on. That dust will clog the low-power motor. Over time, that motor may slow down or shut down completely. When the fan stops, the unit operates outside its design specifications and it probably stops running. In real networks, there may be tens or hundreds of interdependent network devices at various levels of the OSI stack.

REDUNDANCY

Often the outage of a single component, device, or link in the network can cause a larger outage. Therefore, it is useful to have a second item in place to provide service in the event that the primary item fails. This use of more than one item to perform the same task is called redundancy. Although it is true that a network functions without redundancy, a redundant network, which decreases the probability of failure, is more reliable. If redundancy is properly implemented, it can protect the network from debilitating device or link failures. The following sections of this chapter discuss how to have redundancy at a variety of levels. These levels loose...