Chapter 13 - Review

Network+ Guide to Networks, Chapter 13 Review

Troubleshooting Network Problems

By now, you know how networks should work. Like other complex systems, however, they don’t always work as planned. Many things can go wrong on a network, just as many things can go wrong with your car, your house, or a project at work. In fact, a network professional probably spends more time fixing network problems than designing or upgrading a network. Some breakdowns (such as an overtaxed processor) come with plenty of warning, but others (such as a hard disk controller failure) can strike instantly. The best defense against problems is prevention. Just as you maintain your car regularly, you should monitor the health of your network regularly. Of course, even a well-monitored network will sometimes experience unexpected problems. For example, a utility company could dig a new hole for its cable and accidentally cut your dedicated link to the Internet. In such a situation, your network performance can go from perfect to disastrous in an instant. In this chapter, you will learn how to diagnose and solve network problems in a logical, step-by-step fashion, using a variety of tools.

Troubleshooting Methodology

Successful troubleshooters proceed logically and methodically. This section introduces a basic troubleshooting methodology, leading you through a series of general problem solving steps.

Following are steps for troubleshooting network problems as recommended by CompTIA.

You should be familiar with these steps to demonstrate Network+ mastery:

·         Identify the problem.

o   Gather information.

o   Identify symptoms.

o    users.

o   Determine if anything has changed.

·         Establish a theory of probable cause.

o    the obvious.

·         Test the theory to determine cause.

o   Once the theory is confirmed, determine the next steps to resolve the problem.

o   If the theory is not confirmed, reestablish a new theory or escalate.

·         Establish a plan of action to resolve the problem and identify potential effects.

·         Implement the solution or escalate as necessary.

·         Verify full system functionality and, if applicable, implement preventive measures.

·         Document findings, actions, and outcomes.

Bear in mind that experience in your network environment may prompt you to follow the steps in a different order or to skip certain steps entirely. For example, if you know that one segment of your network is poorly cabled, you might try replacing a section of cable in that area to solve a connectivity problem before attempting to verify the physical and logical integrity of the workstation’s NIC. In general, however, it’s best to follow each step in the order shown. Such a logical approach can save you from undertaking wasteful, time-consuming efforts such as unnecessary software or hardware replacements.

In addition to the organized method of troubleshooting described in this section, a good, general rule for troubleshooting can be stated as follows: Pay attention to the obvious!

Although some s might seem too simple to bother asking, don’t discount them. You can often save much time by checking cable connections first. Many networking professionals can tell a story about spending half a day trying to figure out why a computer wouldn’t connect to the network, only to discover that the network cable was not plugged into the wall jack or the device’s NIC.

Identify the Problem and Its Symptoms

When troubleshooting a network problem, your first step is to identify the problem and its symptoms. Only after that can you can begin to deduce their cause. For example, suppose a user complains that he cannot save a file to a network drive. That’s a symptom of a problem, which might be that his client cannot access the network drive. At that point, you can list several potential causes, including a faulty NIC, cable, switch, or router; an incorrect client software configuration; a server failure; or a user error. On the other hand, you can probably rule out a power failure, a printer failure, an Internet connectivity failure, an e-mail server failure, and a host of other problems. Answering the following s may help you identify symptoms of a network problem that aren’t immediately obvious:

·         Is access to the LAN or WAN affected?

·         Is network performance affected?

·         Are data or programs affected? Or are both affected?

·         Are only certain network services (such as printing) affected?

·         If programs are affected, does the problem include one local application, one networked application, or multiple networked applications?

·         What specific error messages do users report?

·         Is one user or are multiple users affected?

·         Do the symptoms manifest themselves consistently?

One danger in troubleshooting technical problems is jumping to conclusions about the symptoms. For example, you might field 12 s from users one morning about a problem printing to the network printer in the Facilities Department. You might have already determined that the problem is an addressing conflict with the printer and be in the last stages of resolving the problem. Minutes later, when a 13th caller says, “I’m having problems printing,” you might immediately conclude that she is another Facilities staff member and that her inability to print results from the same printer addressing problem. In fact, this user may be in the Administration Department, and her inability to print could represent a symptom of larger network problem. In another case, you might be dealing with multiple problems that present different, unrelated symptoms. Take time to pay attention to the users, system and network behaviors, and any error messages. Treat each symptom as unique, but potentially related to others. In this way, you avoid the risk of ignoring problems or—even worse—causing more problems.

Take note of the error messages reported by users. If you aren’t near the users, ask them to read the messages to you directly off their screens or, better yet, save an image of the screens that contain the error messages. For example, on computers running a Windows operating system, the Snipping Tool (accessed by clicking the Start button, pointing to All Programs, pointing to Accessories, and then clicking Snipping Tool) enables you to capture and save a screen image. On computers running Macintosh OS X, a variety of key combinations will capture a screen image, including Comand-Shift-3, which saves the image to the desktop.

Several third-party screen capture utilities are available for all operating systems. After the user saves a screen image, keep it with your other troubleshooting notes for that problem for future reference.

Determine the Problem’s Scope

If a problem is not immediately obvious and requires further investigation, find out how many users or network segments are affected. For example, do the symptoms apply to:

·         One user or workstation?

·         A workgroup?

·         A department?

·         One location within an organization?

·         An entire organization?

In addition, it is useful to narrow down the time frame during which the problem occurred.

The following s can help you determine the chronological scope of a problem:

·         When did the problem begin?

·         Has the network, server, or workstation ever worked properly?

·         Did the symptoms appear in the last hour or day?

·         Have the symptoms appeared intermittently for a long time?

·         Do the symptoms appear only at certain times of the day, week, month, or year?

Similar to identifying symptoms, narrowing down the area affected by a problem can eliminate some causes and point to others. In particular, it can help distinguish workstation (or user) problems from network problems. If the problem affects only a department or floor of your organization, for example, you probably need to examine that network segment, its router interface, its cabling, or a server that provides services to those users. Or, you might trace a problem to a single user in that area—for example, an employee who watches video news reports from the Internet on his lunch hour, thereby consuming much of that segment’s shared bandwidth. If a problem affects users at a remote location, you should examine the WAN link or its router interfaces. If a problem affects all users in all departments and locations, a catastrophic failure has occurred, and you should assess critical devices such as central switches and backbone connections. With all network problems, including catastrophic ones, you should take the time to troubleshoot them correctly by asking specific s designed to identify their scope. For example, suppose a user complains that his mail program isn’t picking up e-mail. You should begin by asking when the problem began, whether it affects only that user or everyone in his department, and what error message the user receives when he attempts to retrieve mail. In answering your s, he might say, “The problem began about 10 minutes ago. Both my neighbors are having problems with e-mail, too. And as a matter of fact, a network technician was working on my machine this morning and installed a new graphics program.” As you listen to the user’s response, you might need to politely filter out information that is unlikely to be related to the problem. In this situation, the user relayed two significant pieces of information: (1) The scope of the problem includes a group of users, and (2) the problem began 10 minutes ago. With this knowledge, you can then delve further in your troubleshooting. In this example, you would proceed by focusing on the network segment rather than on one workstation. Discovering the time or frequency with which a problem occurs can reveal more subtle network problems. For example, if multiple users throughout the organization experience poor performance when attempting to log on to the server at 8:05 a.m., you might deduce that the server needs additional resources to handle the processing burden of accepting so many requests. If a network fails at noon every Tuesday, you might be able to correlate this problem with a test of your building’s power system, which causes a power dip that affects the servers, routers, and other devices. Identifying the affected area of a problem leads you to your next troubleshooting steps.

The path might not always be clear-cut, but as the flowcharts in Figures 13-1 and 13-2 illustrate, some direction can be gained from narrowing both the demographic (or geographic) and the chronological scopes of a problem. Notice that these flowcharts end with the process of further troubleshooting. In the following sections, you will learn more about these subsequent troubleshooting steps. One fascinating example of troubleshooting that began with determining a problem’s chronological scope was experienced by a wireless networking engineer working on a small metropolitan area network. His spread-spectrum RF network links, which connected businesses to a carrier’s facility via a transmitter and receiver on a hospital’s roof, worked perfectly all day, but failed when the sun went down. When the sun came up the next morning, the wireless links worked again. The engineer confirmed that the equipment was fully operational, as he suspected, then talked with the hospital personnel. The hospital’s director informed him that the hospital had installed security cameras on the outside of the building. The cameras used the same RF frequency as the network’s wireless links. When the security cameras were activated at sunset, their signals interfered with the wireless network’s signals, preventing data from reaching its destination.

 Users

You have probably experienced a moment in your dealings with computers in which you were certain you were doing everything correctly, but still couldn’t access the network, save a file, or retrieve your e-mail. For example, you might have typed your case-sensitive network password without realizing that the Caps Lock function was turned on. As a result, even though you were certain that you typed the right password, you received a “password incorrect” error message each time you tried to enter it. All users experience such problems from time to time. It’s natural for human beings to make mistakes. Thus, as a troubleshooter, one of your first steps is to ensure that human error is not the source of the problem. This approach saves you time and worry. In fact, a problem caused by human error is usually simple to solve. It’s much quicker and easier to assist a user in remapping a network drive, for example, than to perform diagnostics on the file server. One task that is commonly affected by user error is logging on to a network. Users become so accustomed to typing their passwords every morning and logging on to the network that, if something changes in the logon process, they don’t know what to do. In fact, some users might never log off, so they don’t know how to log on properly. Although these kinds of problems might seem simple to solve, unless a user receives training in the proper procedures and understands what might go wrong, she will never know how to solve a logon problem without assistance. Even if the user took a computer class that covered logging on, she might not remember what to do in unfamiliar situations. The best way to verify that a user is performing network tasks correctly is to watch the user. If this isn’t practical, the next best way is to connect to her computer using remote desktop software that allows you to view everything that appears on the user’s screen or even control the computer from afar. Software can be controlled by the user, so she must consent to and cooperate in your troubleshooting efforts. If remote desktop software can’t be used, talk with the user by phone while she tries to replicate the error. At every step, calmly ask the user to explain what appears on the screen and what, exactly, she is doing. Remind her to proceed slowly, according to your prompts, so that she doesn’t rush ahead. After every keystroke or command, ask the user again what appears on the screen. With this methodical approach, you will have a good chance at catching user-generated mistakes. At the same time, if the problem does not result from human error, you will gain important clues for further troubleshooting.

Determine If Anything Has Changed

As you begin troubleshooting, you should be aware of any recent changes to your network. The following s could help you pinpoint a problem that results from a network change:

·         Did the operating system or configuration on a server, workstation, or connectivity device change?

·         Were new components added to a server, workstation, or connectivity device?

·         Were old components removed from a server, workstation, or connectivity device?

·         Were new users or segments added to the network?

·         Was a server, workstation, or connectivity device moved from its previous location to a new location?

·         Was a server, workstation, or connectivity device replaced?

·         Was software installed or modified on a server, workstation, or connectivity device?

·         Was old software removed from a server, workstation, or connectivity device?

If you suspect that a network change has generated a problem, you can react in two ways:

You can attempt to correct the problem that resulted from the change, or you can attempt to reverse the change and restore the hardware or software to its previous state. Both options come with hazards. Of the two, reverting to a previous state is probably less risky and might take less time. However, correcting the problem is sometimes the best solution. For example, if you immediately suspect that a change-related problem can be fixed easily, try correcting the problem first. If it is impossible to restore a software or hardware configuration to its previous state, your only choice is to solve the problem.

Before changing a network device or configuration, develop a plan and gather the proper resources for reversing the change in case things go wrong. For example, if you upgrade the memory module in a server, you should keep the old memory module handy in case the new one has flaws. In another situation, you might keep a backup of device or application configurations—perhaps by making a copy of the directory that stores the target configuration.

To track what has changed on a network, you and your colleagues in the IT Department should keep complete network change records. The more precisely you describe a change, its purpose, and the time and date when it occurred in your records, the easier your troubleshooting will be if the change subsequently causes problems.

In addition to keeping thorough records, you must make them available to staff members who might need to reference them. For example, you might want to keep a record of changes in a database on a file server, and then use a Web-based form to retrieve and submit information from and to the database. That way, no matter where a network technician works in the organization, she can retrieve the information from any Web-enabled workstation. A simpler alternative is to keep a clipboard in the computer room with notes about changes. Often, network changes cause unforeseen problems. For example, if you have narrowed a connectivity problem to a group of six users in the Marketing Department, you might refer to your network’s change log and find that a switch in the Marketing Department’s telecommunications closet was recently moved from one end of the closet to another. Reviewing the record of this change can help you more quickly pinpoint the switch as a possible cause of the problem. Perhaps the switch was incorrectly reconnected to the backbone after the move, or perhaps it became damaged in the move or lost its configuration.

Establish a Theory of Probable Cause

After you have identified the scope of the problem, ed users, and analyzed recent changes to the network, you are close to determining the problem’s cause. The following sections provide techniques on how to zero in on the most likely cause among several plausible scenarios.

Re-Create the Symptoms

An excellent way to learn more about the causes of a problem is to try to re-create the symptoms yourself. If you cannot reproduce the symptoms, you might suspect that a problem was a one-time occurrence or that a user performed an operation incorrectly. For example, suppose a user complains that he could edit a particular spreadsheet in the Accounting directory on the file server on Friday, but was unable to open the file on Monday. When you visit his workstation, you verify this sequence of events while logged on with his username. When you then log on as Administrator, however, you are able to open and edit the file. The difference in your experiences points to a user rights problem. At that point, you should check the user’s privileges—especially whether they have changed since he could last retrieve the file. Perhaps someone removed him from a group that had Read and Modify rights to the Accounting directory. Answering the following s may help you determine whether a problem’s symptoms are truly reproducible and, if so, to what extent:

·         Can you make the symptoms recur every time or at all times? If symptoms recur, are they consistent?

·         Can you make the symptoms recur some of the time?

·         Do the symptoms happen only under certain circumstances? For example, does a WAN connection experience significant latency only if it follows a certain route?

·         In the case of software malfunctions, are the symptoms consistent no matter how many and which programs or files the user has open?

·         Do the symptoms ever happen when you try to repeat them?

When attempting to reproduce the symptoms of a problem, you should follow the same steps that the person reporting the symptoms followed. To reproduce a symptom reliably, ask the user precisely what she did before the error appeared.

For example, if a user complains that her network connection mysteriously drops when she’s in the middle of surfing the Web, try to replicate the problem at her workstation. Also, find out what else was running on the user’s workstation or what kind of Web sites she was surfing.

Use good judgment when attempting to reproduce problems. In some cases, reproducing a problem could wreak havoc on the network, its data, and its devices; you should not attempt to reproduce such a problem. An obvious example involves a power outage in which your backup power source failed to supply power. After your network equipment comes back online, you would not cut the power again simply to verify that the problem derived from a faulty backup power source.

Verify Physical Layer Connectivity

By some estimates, more than half of all network problems occur at the Physical layer of the OSI model, which includes cabling and network adapters. The Physical layer also controls signaling—both wired and wireless. Because Physical layer faults are so common and are often easily fixed, you should be thoroughly familiar with the symptoms of such problems.

Symptoms of Physical Layer Problems

Often, physical connectivity problems manifest as a continuous or intermittent inability to connect to the network and perform network related functions. Causes of unreliable network connectivity can include the following:

·         Segment or network lengths that exceed the IEEE maximum standards (for example, an Ethernet 100Base-TX segment that exceeds 100 meters).

·         Noise affecting a wireless or wire-bound signal (from EMI sources, improper grounding, or cross talk).

·         Improper terminations, faulty connectors, loose connectors, or poorly crimped connections.

·         Damaged cables (for example, crushed, bent, nicked, or partially severed)

·         Faulty NICs, GBICs, or SFPs.

Physical connectivity problems do not typically result in software application anomalies, the inability to use a single application, poor network performance, protocol errors, software licensing errors, or software usage errors. Occasionally, however, software errors do point to a physical connectivity problem. For example, a user might be able to log on to his file server without problems. When he chooses to run a query on a database, however, his report software might produce an error message indicating that the database is unavailable or not found. If the database resides on a separate server, this symptom could point to a physical connectivity problem with the database server.

Diagnosing Physical Layer Problems

Answering the following s may help you identify a problem pertaining to physical connectivity:

·         Is the device turned on?

·         Is the NIC properly inserted?

·         In the case of wireless NICs, is the antenna turned on?

·         Is a device’s network cable properly (that is, not loosely) connected to both its NIC and the wall jack?

·         Do patch cables properly connect punch-down blocks to patch panels and patch panels to switches?

·         Is the router or switch properly connected to the backbone?

·         Are all cables in good condition, without signs of wear or damage?

·         Are all connectors (for example, RJ-45) in good condition and properly seated?

·         Do maximum network and segment lengths conform to the IEEE 802 specifications?

·         Are all devices configured properly to work with your network type or speed?

A first step in verifying the physical integrity of a connection is to follow the cabling from one endpoint on the network to the other. For example, if a workstation user cannot log on to the network, and you have verified that he is typing his password correctly, check the physical connectivity from his workstation’s NIC and patch cable. Follow his connection all the way through the network to the server that he cannot reach. Recently moved computers, recently recabled workgroups or nodes, and computers with cables in busy areas that could be unseated by bumping or pulling are prime candidates for errors caused by faulty connections.

In addition to verifying the connections between devices, you must verify the soundness of the hardware used in those connections. A sound connection means that cables are inserted firmly in ports, NICs, and wall jacks; NICs are seated firmly in the system board; connectors are not broken; and cables are not damaged. Damaged or improperly inserted connectivity elements may result in only occasional (and, therefore, difficult-to-troubleshoot) errors. The flowchart in Figure 13-3 illustrates how logically assessing Physical layer elements can help you solve a network problem. The steps in this flowchart apply to a typical problem: a user’s inability to log on to the network. They assume that you have already ruled out user error and that you have successfully reproduced the problem under both your and the user’s logon ID.

Verify Logical Connectivity

After you have verified the physical connections, you must examine the firmware and software configurations, settings, installations, protocols, routes, and privileges. Depending on the type of symptoms, you might need to investigate networked applications, the network operating system, or hardware configurations. All of these elements belong in the category of “logical connectivity.” Answering the following s may help you identify a problem with logical connectivity:

·         Do error messages reference damaged or missing files or device drivers?

·         Do error messages reference malfunctioning or insufficient resources (such as memory)?

·         Has an operating system, configuration, or application been recently changed, introduced, or deleted?

·         Does the problem occur with only one application or a few, similar applications?

·         Does the problem happen consistently?

·         Does the problem affect a single user, a group of users, or all users?

As you learned in Chapter 4, a quick way to confirm that a node’s network interface is responding and that its core TCP/IP protocols are properly installed is to ping the loopback address, 127.0.0.1. To perform this test on a host running IPv4, type ping 127.0.0.1 and press Enter at a command prompt. To perform this test on a host running IPv6, type ping -6 ::1 and press Enter at a command prompt. If you receive a positive response, you can expand the scope of your troubleshooting. If not, you need to determine why the node’s network interface doesn’t respond. Other troubleshooting utilities, such as traceroute, netstat, and dig are described in Chapter 9.

Logical connectivity problems often prove more difficult to isolate and resolve than physical connectivity problems because they can be more complex. For example, a user might complain that he has been unable to connect to the network for the last two hours. Some possible software-based causes for this include, but are not limited to, the following: an improperly configured NIC, improperly installed or configured client software, and improperly installed or configured network protocols or services. Suppose that, after you go to his workstation and confirm that it won’t allow you or him to connect to the network, you check the functionality of his wireless NIC and its antenna. The NIC responds when you attempt to ping the loopback address, the antenna is on, and his workstation has associated with an access point. Next, you might ask the user whether anything changed on his machine approximately two hours ago. He tells you that he didn’t do a thing to the machine—it just stopped working. At this point, you would probably examine the TCP/IPv4 configuration for his NIC. In doing so, you might determine that the incorrect DHCP server has been selected.

This could happen with a wireless client, for example, if a rogue access point running the DHCP service is introduced on the network. After you change the DHCP setting, his workstation can communicate with the network. Determining a likely cause is a process of narrowing down possibilities. Even after recreating the problem and answering s related to physical and logical connectivity, you might identify several plausible theories about the problem’s cause. To further limit the possibilities, the next step is to pick a likely theory and test it.

Test the Theory to Determine Cause

In the case of simple network problems, testing your theory—for example, plugging in a disconnected patch cable—may also be the solution to the problem. However, given complicated problems, testing your theory will require more effort and analysis.

Test Physical Layer Theories

·         If you suspect a problem lies with a faulty network component, you can assess the component individually to determine if it is the source of the problem. Examples of testing Physical layer theories include the following:

·         Using a cable testing tool as described later in this chapter to test a cable’s ability to transmit and receive data reliably.

·         Viewing the LED indicators on an interface to determine whether it is on and exchanging data.

·         Checking to make sure a NIC (whether on-board or peripheral), GBIC, or SFP is seated firmly in its slot.

·         Measuring cabling distance to ensure segments do not exceed length limits.

·         Using a wireless analyzer as described later in this chapter to confirm that all of an access point’s clients are within its range

·         Following cables from one node through connectivity devices to another node to verify end-to-end physical connectivity between them

Another way to determine whether a physical component is at fault is to exchange it for one that you know is functional. In many cases, such a swap resolves the problem very quickly, so you should try this tactic early in your troubleshooting process. It won’t always work, of course, but with experience you will learn what types of problems are most likely caused by component failure. For example, if a user cannot connect to the network, and you have checked to make sure all the connections are secure, the NIC is functional, and the logical connectivity elements are sound, you might consider swapping the user’s network cable with a new one. As you know, network cables must meet specific standards to operate properly. If one becomes damaged (for example, by a chair repeatedly rolling over it); it will cause performance problems or prevent a user from connecting to the network. Swapping an old network cable with a new one is a quick test that could save you further troubleshooting. In addition to swapping network cables, you might need to change a patch cable from one port in a switch to another, or from one data jack to another. Ports, data jacks, and SFP modules can be operational one day and faulty the next. You might also swap a network adapter from one machine to another, or try installing a new network adapter, making sure it’s compatible with the client. Obviously, it’s more difficult to swap a switch or router because of the number of nodes serviced by these components and the potentially significant configuration they require; if network connectivity has failed for an entire segment or network, however, this approach may provide a quicker answer than attempting to troubleshoot the faulty device. A better—albeit more expensive—alternative to swapping parts is to build redundancy into your network; For example, you might have a server that contains two network adapters, allowing one network adapter to take over for the other if one adapter should fail.

If properly installed and configured, this arrangement results in no downtime; in contrast, swapping parts requires at least a few minutes of service disruption. In the case of swapping a router, the downtime might last for several hours. Before swapping any network component, make sure that the replacement has the same specifications as the original part. By installing a component that’s different from the original device, you risk thwarting your troubleshooting efforts because the new component might not work in the environment. In the worst case, you may damage existing equipment by installing a component that isn’t rated for it.

Test Logical Connectivity Theories

As with testing theories about physical connectivity problems, testing a theory about logical connectivity problems may end up solving the problem. For example, if you suspect a client’s NIC driver is outdated, you can install the new driver to test your theory and the problem might be solved. More complicated logical connectivity problems, however, may require you to perform more sleuthing. Some examples of testing logical connectivity theories include the following:

Viewing a switch configuration to determine which nodes are included in VLANs.

·         Investigating user permissions on a server.

·         Examining a NIC’s configuration to check that the correct protocols (for example, TCP/IPv4 and/or TCP/IPv6) are installed and that the correct gateway, DHCP server, and name server are identified.

·         Reading a routing table to determine if any static entries point to routers that no longer exist.

·         Reviewing a router’s access list or a firewall’s policies to find out if legitimate traffic is being blocked.

·         Using tools such as ping, netstat, route, or traceroute to establish the condition of an interface or route.

·         Checking to make sure a wireless client’s settings, including security method and passphrase, channel, and network type match those of its access point.

As with Physical layer sleuthing, tools exist to help you test theories about logical connectivity problems. Later in this chapter, you will learn about protocol analyzers and network monitoring programs that enable you to examine network traffic and pinpoint a problem’s cause.

Escalate If Necessary

If you’re unable to establish a cause despite your best efforts to test likely theories, you might need to escalate the issue to a colleague with more experience or specialized knowledge. Many staff members can contribute to troubleshooting a network problem. Often, the division of duties is formalized, with a help desk acting as a single point of contact for users. A help desk is typically staffed with help desk analysts—people proficient in basic (but not usually advanced) workstation and network troubleshooting. Larger organizations might group their help desk analysts into teams based on their expertise. For example, a company that provides users with word processing, spreadsheet, project planning, scheduling, and graphics software might assign different technical support personnel at the help desk to answer s pertaining to each application. The help desk analysts are often considered first-level support because they provide the first level of troubleshooting. When a user calls with a problem, a help desk analyst typically creates a record for the incident and attempts to diagnose the problem. The help desk analyst might be able to solve a common problem over the phone within minutes by explaining something to the user.

In the case of an extremely rare or complex problem, the first-level support analyst will refer, or escalate, the problem to a second-level support analyst. A second-level support analyst is someone with specialized knowledge in one or more aspects of a network. For example, if a user complains that she can’t connect to a server, and the first-level support person narrows down the problem to a failed file server, that first-level support analyst would then refer the problem to the second-level support person. Some organizations also have third-level support personnel who are highly skilled in one area of networking. Second-level analysts escalate only the most severe or complex issues to third-level support personnel. Such staff are typically not part of the help desk, but specialists in another area, such as routing and switching, server management, or security. In addition to having first- and second-level support analysts, most help desks include a help desk coordinator. The help desk coordinator ensures that analysts are divided into the correct teams, schedules shifts at the help desk, and maintains the infrastructure to enable analysts to better perform their jobs. They might also serve as third-level support personnel, taking responsibility for troubleshooting a problem when the second-level support analyst is unable to solve it. When you’re part of a troubleshooting team, you need to know when and how to escalate problems. For guidance, you might turn to a procedure that lists specific conditions under which escalation is critical. For example, suppose you work for an ISP with one large corporate customer whose income depends largely on Internet sales that are handled by servers and connections in your data center. Your organization might deem that anytime one of that company’s servers fails to respond, a second-level support analyst is assigned to troubleshoot it. In other cases, you will have to use your judgment to determine whether a situation warrants escalation. You’ll base your decision on several factors, including the number of users affected, the importance of the access or service affected, the familiarity of the problem, and your technical skills.

Establish a Plan of Action to Resolve the Problem

After you have thoroughly analyzed a network problem and identified its likely cause, you will be able to devise an action plan for solving it. First, however, you must consider how your solution might affect users and network functionality.

Scope

One of the most important aspects to consider is the scope of your change. For example, replacing a cable that connects a workstation to a switch may affect only one user, but replacing a cable that connects a server to a switch affects all users who access that server. Assess the breadth of your solution—whether it is a single workstation, a workgroup, a location, or the entire network—before implementing that solution. If the problem does not pose an emergency, wait until no one is on the network before implementing solutions that affect many users. That way, you will have time to judge the solution’s effects systematically and fix any new problems that might arise.

Trade-Offs

Along with the scope, another factor to consider is the trade-off your solution might impose. In other words, your solution might restore functionality for one group of users, but remove it for others. For example, let’s say you are a network technician at a stationery company that uses specialized software to program custom logos and control its embossing machines. When you add a group of new Windows 7 workstations to your network, you discover that these new workstations can’t run the embossing control software properly. The software vendor tells you that to be compatible with Windows 7 you must install a new, Windows 7-compatible version of the software on your file server. You might be thrilled to hear of such a simple solution and install the updated embossing control software immediately.

In the next half hour, you receive numerous phone calls from employees using Windows XP workstations who cannot properly use the embossing control software. Now, you have solved one problem, but created another. In this situation, it would have been wise to ask the software vendor about their upgrade’s compatibility with all the other operating systems your company uses. If the vendor told you about a problem with Windows XP workstations, you could have kept the old installation on the server for these users, and then installed a separate instance of the new version of the software for use by Windows 7 users.

Security

Be aware of the security implications of your solution because it might inadvertently result in the addition or removal of network access or resource privileges for a user or group of users. One consequence might be that a user can no longer access a data file or application he is accustomed to accessing. But a worse consequence is that you could create a security vulnerability that allows unauthorized people to access your network. Before installing a software upgrade or patch, for example, be sure to understand how it could change access for both authorized and unauthorized users.

Scalability

Also consider the scalability of the solution you intend to implement. Does it position the network for additions and enhancements later on, or is it merely a temporary fix that the organization will outgrow in a year? Ideally, your solution would be perfectly suited to your network and allow for future growth. But a temporary fix is not necessarily wrong, depending on the scenario. For example, suppose you walk into the office one day to find that none of your users can access the network. You track down the problem as an internal hardware problem with your Internet gateway. Because the gateway is under warranty, you quickly call the manufacturer to get the gateway replaced or fixed immediately. The manufacturer tells you that although they don’t have the identical gateway available in their local office, they can substitute a different, smaller model to get your users reconnected today, and meanwhile order the identical gateway that you can install when you have more time. In this situation, it’s probably preferable to take the temporary gateway and restore functionality than to wait for the ideal solution.

Cost

Another factor to consider when implementing your solution is cost. Obviously, replacing one patch cable or faulty SFP is a fairly inexpensive proposition, and you don’t need to analyze cost in these cases. But if the solution you have proposed requires significant dollars for either software or hardware, weigh your options carefully. For example, suppose you discover a problem with performance on your network. After some investigation, you determine that the best solution is to replace all 400 workstations’ network adapters with newer, faster network adapters. If you purchase quality NICs, this solution could cost over $5000 for the hardware alone, not to mention the time it will take technicians to replace the devices, which would cost more. Also you should consider when these workstations will be replaced and if you will have to either discard or remove the network adapters you just installed. It might be more prudent to identify where the network’s performance is poor and address those areas separately—for example, by adding a switch to a busy segment or adding a more powerful server for a heavily used application.

Use Vendor Information

Some networking professionals pride themselves in being able to install, configure, and troubleshoot devices without reading the instructions—or at least exhausting all possibilities before they submit to reading a manual. Although some manufacturers provide better documentation than others, you have nothing to lose by referring to the manual, except a little time.

Chances are you will find exactly what you need—configuration commands for a router or switch, recommendations for remote access server setup, or troubleshooting tips for a network operating system function, to name a few examples. In addition to the documentation that comes with hardware and software, most vendors provide free online troubleshooting information. For example, Microsoft, Red Hat, and Apple offer searchable databases in which you can type your error message or a description of your problem and receive lists of possible solutions. Reputable equipment manufacturers, such as 3Com, HP, Cisco, IBM, and Intel, also offer sophisticated Web interfaces for troubleshooting their equipment. If you cannot find the documentation for a networking component, you should try looking for information on the Web. Call the vendor’s technical support phone number only after you have read the product documentation and searched the vendor’s Web page. With some manufacturers, you can talk to a technical support agent only if you have established and paid for a support agreement. With others, you must pay per phone call. Each vendor has a different pricing structure for technical support, so before you agree to pay for technical support, you should find out whether the vendor charges on a per-hour or per-problem basis.

Keep a list handy of the hardware and software vendors for your networking equipment; the list should include the company’s name, its technical support phone number, a contact name (if available), its technical support Web site address, its policies for technical support, and the type of agreement you currently have with the vendor. Make sure the list is updated regularly and available to all IT personnel who might need it.

If you are uncertain whether your proposed solution is the best solution, even after your thorough diagnosis and research, seek advice from others, either within or outside your organization. Colleagues or consultants might share an experience that leads you to prefer one solution to another.

Implement the Solution or Escalate as Necessary

Finally, after you have established a plan for your proposed solution, you are ready to implement the solution. This step might be very brief (such as modifying a record in a routing table) or it might take a long time (such as replacing the hard disk of a server). In either case, implementing a solution requires foresight and patience. As with finding the problem, the more methodically and logically you can approach the solution, the more efficient the correction process will be. If a problem is causing catastrophic outages, however, you should solve it as quickly as possible.

The following steps will help you implement a safe and reliable solution:

·         Alert all affected users of the planned change with as much advance notice as possible. Depending on the solution’s scope and risk, those affected might include only a few users or the whole organization.

·         Collect all the documentation you have about a problem’s symptoms from your investigation and keep it handy while solving the problem.

·         If you are reinstalling software on a device, make a backup of the device’s existing software installation. If you are changing hardware on a device, keep the old parts handy in case the solution doesn’t work. If you are changing the configuration of a program or device, take the time to print the program or device’s current configuration. Even if the change seems minor, jot down notes about the original state.

·         Perform the change, replacement, move, or addition that you believe will solve the problem. Record your actions in detail so that you can later enter the information into a database.

·         Test your solution, as described in the section that follows.

·         Before leaving the area in which you were working, clean it up. For instance, if you created a new patch cable for a telecommunications room, remove the debris left from cutting and crimping the cable.

·         If the solution fixes the problem, record the details you have collected about the symptoms, the problem, and the solution in your organization’s troubleshooting database.

·         If your solution involved a significant change or addressed a significant problem (one that affected more than a few users), revisit the solution a day or two later to verify that the problem has, indeed, been solved and that it hasn’t created additional problems.

In the case of large-scale fixes—for example, applying new configurations on a global VPN’s routers because of a security threat—it’s often best to roll out changes in stages. This approach allows you to find and correct any problem that occurs during the upgrade before it affects all users. It also allows you to test whether you’re implementing the solution in the best possible way. In the example of reconfiguring routers, you could log on to the routers and apply configurations from a remote office, but in some cases this creates additional security concerns. You might prefer instead to visit the offices and apply the changes yourself or talk to a local IT employee who can make the changes on site.

Verify Full System Functionality

After implementing your solution, you must test its result and verify that you have solved the problem properly. Obviously, the type of testing you perform depends on your solution. For example, if you replaced a patch cable between a switch port and a patch panel, a quick test of your solution would be to determine whether you could connect to the network from the device that relies on that patch cable. If the device does not successfully connect to the network, you might have to try another cable, or reconsider whether the problem stems from physical or logical connectivity or some other cause. In that case, using the hardware and software troubleshooting tools discussed later in this chapter might lead to a more efficient evaluation of your solution. Testing the results of your solution will also depend on the area affected by the problem. Suppose you replaced a switch that served four different departments in an organization. To test the result of your solution, you would need to verify connectivity from workstations in each of the four departments. Keep in mind that you might not be able to test your solution immediately. In some cases, you might have to wait days or weeks before you know for certain whether it worked. For example, suppose you discovered that a server was sometimes running out of processor capacity when handling clients’ database queries, causing users to experience unacceptably slow response times. To solve this problem, you added two processors and enabled the server’s symmetric multiprocessing capabilities. But suppose that the timing of the database usage is unpredictable, however. This means you wouldn’t find out whether the added processors eliminated the problem until a certain number of users attempted the operations that push the server to its peak processor usage. Upon testing your solution, you should be able to determine how and why the solution was successful and what effects it had on users and functionality. For example, suppose you identified a symptom of excessively slow performance when saving and retrieving files to and from a server on your LAN. You determined that all users were affected by the problem and that it had worsened steadily in the past month. Your proposed solution was to replace the server with one that contained a faster processor, more memory, greater hard disk capacity, and dual NICs.

You implemented the solution and then tested its outcome to make sure all users could save and retrieve files to and from the new server. If all went well, the effect of the solution might be an 80 percent increase in performance between clients and the server. Most important, you want to avoid creating unintended, negative consequences as a result of your solution. For example, in the process of diagnosing a problem with a user’s access to a mail directory, you might have reconfigured his mail settings to log on with your own user name to rule out the possibility of a physical connectivity error. After discovering that the problem was actually due to an IP addressing conflict, you might fix the IP addressing problem but forget that you changed the user’s e-mail configuration. Having the user test your solution would reveal this oversight—and prevent you from having to return to the workstation to solve another problem. After you verify system functionality, it’s wise to consider how similar problems can be prevented in the future. Some network problems can be averted by network maintenance, documentation, security, or upgrades. Others can be avoided by thoughtful planning. For example, to avoid problems with users’ access levels for network resources, you can comprehensively assess users’ needs, set policies for groups, create a variety of groups, and explain the necessity for these groups to those who support the network. To prevent overusing network segments, you should perform regular network health checks—perhaps even continual network monitoring, with filters that isolate anomalous occurrences. Also, you should ensure that you have the means to either redesign the network to distribute traffic or purchase additional bandwidth well before utilization reaches critical levels. With experience, you will be able to add more suggestions for network problem prevention. When planning or upgrading a network, you need to consider how good network designs and policies can prevent later problems—not to mention, make your job easier and more fun. After you have implemented and tested your solution and identified its results and effects, communicate your solution to your colleagues, thus adding to the store of knowledge about your network. The next section discusses how best to document your troubleshooting efforts and notify others of changes you’ve made.

Document Findings, Actions, and Outcomes

Whether you are a one-person network support team or one of 100 network technicians at your organization, you should always document the symptoms and cause (or causes) of a problem and your solution. Given the volume of problems you and other analysts will troubleshoot, it will be impossible to remember the circumstances of each incident. In addition, networking personnel frequently change jobs, and everyone appreciates clear, thorough documentation. An effective way to document problems and solutions is in a centrally located database to which all networking personnel have online access. For documenting problems, some organizations use a software program known as a call tracking system (also informally known as help desk software). Such programs provide user friendly graphical interfaces that prompt the user for every piece of information associated with the problem. They assign unique identifying numbers to each problem, in addition to identifying the caller, the nature of the problem, the time necessary to resolve it, and the nature of the resolution. Most call tracking systems are highly customizable, so you can tailor the form fields to your particular computing environment. For example, if you work for an oil refinery, you might add fields for identifying problems with the plant’s flow-control software. In addition, most call tracking systems allow you to enter free-form text explanations of problems and solutions. If your organization does not have a call tracking system, you should at least keep records in a simple electronic form. A typical problem record form should include at least the following fields:

·         The name, department, and phone number of the problem originator (the person who first noticed the problem.)

·         Information regarding whether the problem is software or hardware related.

·         If the problem is software related, the package to which it pertains; if the problem is hardware-related, the device or component to which it pertains.

·         Symptoms of the problem, including when it was first noticed.

·         The name and telephone number of the network support contact.

·         The amount of time spent troubleshooting the problem.

·         The resolution of the problem.

As discussed earlier in this chapter, many organizations operate a help desk staffed with personnel who have only basic troubleshooting expertise and who record problems called in by users. To effectively field network s, help desk staff must maintain current and accurate records for network support personnel. Furthermore, the IT Department should maintain a supported services list that help desk personnel can use as a reference. A supported services list is a document (preferably online) that lists every service and software package supported within an organization, plus the names of first- and second-level support contacts for those services or software packages. Increasing communication and availability of support information will expedite troubleshooting. In addition to communicating problems and solutions to your peers whenever you work on a network problem, you should follow up with the user who reported the problem. Make sure that the client understands how or why the problem occurred, what you did to resolve the problem, and whom to contact should the problem recur. This type of education helps your clients make better decisions about the type of support or training they need, and also improves their understanding of and respect for your department. After solving a particularly thorny network problem, record its resolution in your call tracking system and notify others of your solution and what, if anything, you needed to change to fix the problem. This communication serves two purposes: (1) It alerts others about the problem and its solution, and (2) it notifies others of network changes you made, in case they affect other services. Large organizations often implement change management systems to methodically track changes on the network. A change management system is a process or program that provides support personnel with a centralized means of documenting changes to the network. The system might consist of a database package complete with graphical interfaces and customizable fields tailored to the computing environment. Whatever form, a change management system takes the most important element is participation. If networking personnel do not record their changes, even the most sophisticated software is useless. The types of changes that network personnel record in a change management system include the following:

·         Adding or upgrading software on servers or connectivity devices.

·         Adding or upgrading hardware components on servers or connectivity devices.

·         Adding new hardware on the network, for example, a new firewall.

·         Changing the properties or configurations of network devices (for example, changing the IP address or host name of a server or creating a new VLAN.)

·         Increasing or decreasing rights for a group of users.

·         Physically moving networked devices/

·         Moving user accounts and their files and directories from one server to another.

·         Making changes in processes (for example, a new backup schedule or a new contact for DNS support.)

·         Making changes in vendor policies or relationships (for example, a new cloud storage supplier.)

It’s generally not necessary to record minor modifications, such as changing a user’s password, creating a new group for users, creating new directories, or changing a network drive mapping for a user.

Each organization will have unique requirements for its change management system, and analysts who record change information should clearly understand these requirements.

Troubleshooting Tools

You have already learned about some utilities that can help you troubleshoot network problems. For example, you can learn many things about a user’s workstation connection by attempting to ping different hosts on the network from that workstation. However, in some cases, the most efficient troubleshooting approach is to use a tool specifically designed to analyze and isolate network problems. Several tools are available, ranging from simple continuity testers that indicate whether a cable is faulty, to sophisticated protocol analyzers that capture and interpret all types of data traveling over the network. The tool you choose depends on the particular problem you need to investigate and the characteristics of your network. The following sections describe a variety of network troubleshooting tools, their functions, and their relative costs.

Tone Generator and Tone Locator

Ideally, you and your networking colleagues would label each port and wire termination in a telecommunications closet so that problems and changes can be easily managed. However, because of personnel changes and time constraints, a telecommunications closet might be disorganized and poorly documented. If this is the case where you work, you might need a tone generator and a tone locator to determine where one pair of wires, possibly out of hundreds, terminates. A tone generator (or toner) is a small electronic device that issues a signal on a wire pair. A tone locator (or probe) is a device that emits a tone when it detects electrical activity on a wire pair. They are sold together as a set, often called a toner and probe kit. By placing the tone generator at one end of a wire and attaching a tone locator to the other end, you can verify the location of the wire’s termination. Figure 13-4 depicts the use of a tone generator and a tone locator. Of course, you must work by trial and error, guessing which termination corresponds to the wire over which you’ve generated a signal until the tone locator indicates the correct choice. Tone generators and tone locators cannot be used to determine any characteristics about a cable, such as whether it’s defective or whether its length exceeds IEEE standards for a certain type of network. They are only used to determine where a wire pair terminates.

A tone generator should never be used on a wire that’s connected to a device’s port or network adapter. Because a tone generator transmits electricity over the wire, it could damage the device or network adapter.

Cable testing tools are essential for both cable installers and network troubleshooters, as faulty cables are often the cause of network problems. Symptoms of cabling problems can be as elusive as occasional lost packets or as obvious as a break in network connectivity. You can easily test cables for faults with specialized tools. In this section and in the ones following, you will learn about different tools that can help isolate problems with network cables. The first device you will learn about is a multimeter, a simple instrument that can measure many characteristics of an electric circuit, including its resistance and voltage. If you have taken an introductory electronics class, you are probably familiar with a voltmeter, the instrument that measures the pressure, or voltage, of an electric current. Recall that voltage is used to create signals over a network wire. Thus, every time data travel over a wire, the wire carries a small voltage. In addition, each wire has a certain amount of resistance, or opposition to electric current. Resistance is a fundamental property of wire that depends on a wire’s molecular structure and size. Every type of wire has different resistance characteristics. Resistance is measured in ohms, and the device used to measure resistance is called an ohmmeter.

Another characteristic of electrical circuits is impedance—the resistance that contributes to controlling the signal. Impedance is also measured in ohms. Impedance is the telltale factor for ascertaining where faults in a cable lie. A certain amount of impedance is required for a signal to be properly transmitted and interpreted. However, very high or low levels of impedance can signify a damaged wire, incorrect pairing, or a termination point. In other words, changes in impedance can indicate where current is stopped or inhibited. Although you could use separate instruments for measuring impedance, resistance, and voltage on a wire, it is more convenient to have one instrument that accomplishes all of these functions. The multimeter is such an instrument. Figure 13-5 shows a handheld digital multimeter. As a network professional, you might use a multimeter to do the following:

·         Verify that a cable is properly conducting electricity—that is, whether its signal can travel unimpeded from one node on the network to another.

·         Check for the presence of noise on a wire (by detecting extraneous voltage).

·         Verify that the amount of resistance presented by terminators on coaxial cable networks is appropriate, or whether terminators are actually present and functional.

·         Test for short or open circuits in the wire (by detecting unexpected resistance or loss of voltage).

Multimeters vary in their degree of sophistication and features. Some merely show voltage levels, for example, whereas others can measure the level of noise on a circuit at any moment with extreme precision. Costs for multimeters also vary; some, such as those available at any home electronics store, cost as little as $30, while others cost as much as $4000. Multimeters capable of the greatest accuracy are most useful to electronics engineers. As a network technician, you won’t often need to know the upper limit of noise on a cable within a small fraction of a decibel, for example. However, you do need to know how to check whether a cable is conducting current. Another instrument that can perform such a test is a continuity tester, which is discussed next.

Cable Continuity Testers

In troubleshooting a Physical layer problem, you may find the cause of a problem by simply testing whether your cable is carrying a signal to its destination. Tools used to make this determination are said to be testing the continuity of the cable and may be called cable checkers or continuity testers. They may also be called cable testers. The term cable tester, however, is a general term that also includes more sophisticated tools that can measure cable performance, as discussed in the following section. When used on a copper-based cable, a continuity tester applies a small amount of voltage to each conductor at one end of the cable, and then checks whether that voltage is detectable at the other end. That means that a continuity tester consists of two parts: the base unit that generates the voltage and the remote unit that detects the voltage. Most cable checkers provide a series of lights that signal pass/fail. Some also indicate a cable pass/fail with an audible tone. A pass/fail test provides a simple indicator of whether a component can perform its stated function. In addition to checking cable continuity, some continuity testers will verify that the wires in a UTP or STP cable are paired correctly and that they are not shorted, exposed, or crossed. Recall that different network models use specific wire pairings and follow cabling standards set forth in TIA/EIA 568. Make sure that the cable checker you purchase can test the type of network you use—for example, 10Base-T, 100Base-TX, or 1000Base-T Ethernet. Continuity testers for fiber-optic networks also exist. Rather than issuing voltage on a wire, however, these testers issue light pulses on the fiber and determine whether they reached the other end of the fiber. Some continuity testers offer the ability to test both copper and fiber-optic cable. Whether you make your own cables or purchase cabling from a reputable vendor, test the cable to ensure that it meets your network’s required standards.

Just because a cable is labeled “Cat 6a,” for example, does not necessarily mean that it will live up to that standard. Testing cabling before installing it could save many hours of troubleshooting after the network is in place.

Do not use a continuity tester on a live network cable. Disconnect the cable from the network, and then test its continuity.

For convenience, most continuity testers are portable and lightweight, and typically use one 9-volt battery. A continuity tester can cost between $30 and $300 and can save many hours of work. Popular manufacturers of these cable testing devices include Belkin, Fluke, and Paladin.

Cable Performance Testers

If you need to know more than whether a cable is simply carrying current, you can use a cable performance tester. The difference between continuity testers and performance testers lies in their sophistication and price. A performance tester accomplishes the same continuity and fault tests as a continuity tester, but can also perform the following tasks:

·         Measure the distance to a connectivity device, termination point, or cable fault.

·         Measure attenuation along a cable.

·         Measure near-end cross talk between wires.

·         Measure termination resistance and impedance.

·         Issue pass/fail ratings for Cat 3, Cat 5, Cat 5e, Cat 6, Cat 6a, or Cat 7 standards.

·         Store and print cable testing results or directly save data to a computer database.

·         Graphically depict a cable’s attenuation and cross talk characteristics over the length of the cable.

A sophisticated performance tester will include a TDR (time domain reflectometer). A TDR issues a signal on a cable and then measures the way the signal bounces back (or reflects) to the TDR. Connectors, crimps, bends, short circuits, cable mismatches, or other defects modify the signal’s amplitude before it returns to the TDR, thus changing the way it reflects. The TDR then accepts and analyzes the return signal, and based on its condition and the amount of time the signal took to return, determines cable imperfections. In the case of a coaxial cable network, a TDR can indicate whether terminators are properly installed and functional. A TDR can also indicate the distance between nodes and segments. In addition to performance testers for coaxial and twisted pair connections, you can also find performance testers for fiber-optic connections. Such performance testers use OTDRs (optical time domain reflectometers). Rather than issue an electrical signal over the cable as twisted pair cable testers do, an OTDR transmits light-based signals of different wavelengths over the fiber. Based on the type of return light signal, the OTDR can accurately measure the length of the fiber; determine the location of faulty splices, breaks, connectors, or bends; and measure attenuation over the cable. Because of their sophistication, performance testers for both copper and fiber-optic cables cost significantly more than continuity testers. A high-end unit could cost up to $30,000, and a low-end unit could sell for less than $4000. Figure 13-7 shows an example of a high-end cable performance tester that is capable of measuring the characteristics of both copper and fiber-optic cables.

Voltage Event Recorders

Hardware depends on a steady flow of electricity to function properly. The term voltage event refers to any condition in which voltage exceeds or drops below predefined levels. In Chapter 14, you will learn how inconsistent or insufficient power can cause problems for network devices. This section describes an instrument that allows you to monitor the electricity flowing to servers, routers, and switches. This instrument, called a voltage event recorder, collects data about power quality. Left plugged into the same outlet that will be used by a network node, it gathers data about the power that outlet will provide to the node. This data is then downloaded to a workstation and analyzed by software that comes with the voltage event recorder. The software can check for and report on any voltage anomalies that exceed preset parameters. For example, you can configure the software to highlight any occasion on which the frequency of the power supplied by an outlet dips below 60 Hz (the standard for North American electrical outlets). Voltage event recorders such as the one shown in Figure 13-8 can cost up to $5000.

Butt Set

If you have seen telephone technicians on the job, you have probably noticed the oversized telephone-like devices they carry. This device is known as a lineman’s handset, a telephone test set, or, more commonly, a butt set because it can be used to butt into a telephone conversation. A butt set is essentially a rugged and sophisticated telephone. It helps a telephone technician working in the field to determine whether a line is functioning, not only by receiving the signal, but also by picking up any noise that might affect the signal. Some sophisticated butt sets can also perform rudimentary cable testing. For the most part, however, the butt set is a simple means of detecting dial tone on a line. A butt set contains clips that fasten onto telephone transmission wires, thereby attaching to the local loop just as a telephone would. This connection can occur at the demarc, where a telephone line enters a residence, for example, or at a remote switching facility or at a CO. However, it can only function on lines that have already been demultiplexed. For example, you could not attach a butt set to the ends of a line carrying multiple channels and expect to test one of those channels.

Network Monitors

A network monitor is a software-based tool that continually monitors network traffic from a server or workstation attached to the network. Network monitors typically can interpret up to Layer 3 of the OSI model. They can determine the protocols passed by each frame, but can’t interpret the data inside the frame. By capturing data, they provide either a snapshot of network activity at one point in time or a historical record of network activity over a period of time. Some NOSs come with network monitoring tools. Microsoft’s Network Monitor is the tool that ships with Windows operating systems. In addition, you can purchase or download for free network monitoring tools developed by other software companies. Hundreds of such programs exist. After you have worked with one network monitoring tool, you will find that other products work in much the same way. Most even use very similar graphical interfaces.

To take advantage of network monitoring and analyzing tools, the network adapter installed in the machine running the software must support promiscuous mode. In promiscuous mode, a device driver directs the NIC to pick up all frames that pass over the network—not just those destined for the node served by the card. You can determine whether your network adapter supports promiscuous mode by reading its manual or checking with the manufacturer. Some network monitoring software vendors may even suggest which network adapters to use with their software.

All network monitoring tools can perform at least the following functions:

·         Continuously monitor network traffic on a segment

·         Capture network data transmitted on a segment

·         Capture frames sent to or from a specific node

·         Reproduce network conditions by transmitting a selected amount and type of data

·         Generate statistics about network activity (for example, what percentage of the total frames transmitted on a segment are broadcast frames)

Some network monitoring tools can also perform the following functions:

·         Discover all network nodes on a segment

·         Establish a baseline, or a record of how the network operates under normal conditions, including its performance, collision rate, utilization rate, and so on

·         Store traffic data and generate reports

·         Trigger alarms when traffic conditions meet preconfigured conditions (for example, if usage exceeds 50 percent of capacity)

How can capturing data help you solve a problem? Imagine that traffic on a segment of the network you administer suddenly grinds to a halt one morning at about 8:00. You no sooner step in the door than everyone from the help desk calls to tell you how slowly the network is running. Nothing has changed on the network since last night, when it ran normally, so you can think of no obvious reasons for problems. At the workstation where you have previously installed a network monitoring tool, you capture all data transmissions for approximately five minutes. You then sort the frames in the network monitoring software, arranging the nodes in order based on the volume of traffic each has generated. You might find that one workstation appears at the top of the list with an inordinately high number of bad transmissions. Or, you might discover that a server has been compromised by a hacker and is generating a flood of data over the network.

Before adopting a network monitor or protocol analyzer, you should be aware of some of the data errors that these tools can distinguish. The following list defines some commonly used terms for abnormal data patterns and packets, along with their characteristics:

·         Local collisions—Collisions that occur when two or more stations are transmitting simultaneously. A small number of collisions are normal on an Ethernet network. Excessively high collision rates within the network usually result from cable or routing problems.

·         Late collisions—Collisions that take place outside the window of time in which they would normally be detected by the network and redressed. Late collisions are usually caused by one of several problems, including (1) a defective station (for example, a card or transceiver) that is transmitting without first verifying line status, (2) mismatched duplex settings between a sending and receiving node, or (3) failure to observe the configuration guidelines for cable length, which results in collisions being recognized too late.

·         Runts—Packets that are smaller than the medium’s minimum packet size. For instance, any Ethernet packet that is smaller than 64 bytes is considered a runt. Runts are often the result of collisions.

·         Giants—Packets that exceed the medium’s maximum packet size. For example, an Ethernet packet larger than 1518 bytes is considered a giant.

·         Jabber—A device that handles electrical signals improperly, usually affecting the rest of the network. A network analyzer will detect a jabber as a device that is always retransmitting, effectively bringing the network to a halt. A jabber usually results from a bad NIC. Occasionally, it can be caused by outside electrical interference.

·         Negative frame sequence checks—The result of the CRC (cyclic redundancy check) generated by the originating node not matching the checksum calculated from the data received. It usually indicates noise or transmission problems on the LAN interface or cabling. A high number of negative CRCs usually result from excessive collisions or a station transmitting bad data.

·         Ghosts—Frames that are not actually data frames, but aberrations caused by a device misinterpreting stray voltage on the wire. Unlike true data frames, ghosts have no starting delimiter.

Network monitors are typically simple tools to master. The following section describes a similar type of tool that provides even more information about a network’s traffic.

Protocol Analyzers

Similar to a network monitor, a protocol analyzer (or network analyzer) captures traffic. But a protocol analyzer can also analyze frames, typically all the way to Layer 7 of the OSI model. For example, it can identify that a frame uses TCP/IP and, more specifically, that it is an ARP request from one particular workstation to a server. Analyzers can also interpret the payload portion of frames, translating from binary or hexadecimal code to human-readable form. As a result, network analyzers can capture passwords going over the network, if their transmission is not encrypted. Some protocol analyzer software packages can run on a standard workstation, but others require computers equipped with special network adapters and operating system software. As with network monitoring software, a variety of protocol analyzer software is available. One popular example is the free program called Wireshark. You used this program in the Hands-On Projects in Chapters 5 and 11 to capture and view frames. Essentially, a protocol analyzer performs the same features as the network monitor software discussed previously, plus a few extras. It can also generate traffic in an attempt to reproduce a network problem and monitor multiple network segments simultaneously. Protocol analyzers typically support a multitude of protocols and network topologies. Those programs with graphical interfaces are especially helpful for revealing the traffic flow across the network. Figure 13-10 illustrates the distribution of traffic captured by a protocol analyzer. Before many companies developed protocol analyzing software, a hardware device dedicated to this task, sold by the company Sniffer Technologies and known under the brand name Sniffer, was popular. Just as the brand name Kleenex has become a substitute for the term facial tissue, network engineers today might call any protocol analyzer tool a sniffer or packet sniffer. And now, even the company that bought Sniffer Technologies, NetScout, only sells software-based protocol analyzers. Protocol analyzers offer a great deal of versatility in the type and depth of information they can reveal. The danger in using this type of tool is that it could collect more information than you or the machine can reasonably process, thus rendering your exercise futile. To avoid this problem, you should set filters on the data gathered. For example, if you suspect that a certain workstation is causing a traffic problem, you should filter the data collection to accept only frames to or from that workstation’s MAC address. If you suspect that you have a gateway-related TCP/IP problem, you should set a filter to capture only TCP/IP frames and to ignore other protocols from the gateway’s MAC address.

Recall that using a switch logically separates a network into different segments. If a network is fully switched (that is, if every node is connected to its own switch port), your protocol analyzer can capture only frames destined for the port to which your node is connected. The increasing use of switches has made network monitoring more difficult, but not impossible. One solution to this problem is to reconfigure the switch to reroute the traffic so that your network analyzer can pick up all traffic—that is, to set up port mirroring.

Before using a network monitor or protocol analyzer on a network, it’s important to know what traffic on your network normally looks like. To obtain this information, you can run the program and capture data for a period of time on a regular basis—for example, every weekday between 8:00 a.m. and noon. You’ll generate a lot of data, but you’ll also learn a lot about your network. From this data, you can establish a baseline to use as a comparison with future traffic analyses.

Wireless Network Testers

Cable continuity and performance testers, of course, will tell you nothing about the wireless connections, stations, or access points on a network. For that, you need tools that contain wireless NICs and run wireless protocols. In fact, you can learn some things about a wireless environment by viewing the wireless network connection properties on your workstation, as you learned in Chapter 8. However, viewing the status of the wireless connection on your workstation tells you only a little about your wireless environment—and this information only applies to one workstation. Many programs exist that can scan for wireless signals over a certain geographical range and discover all the access points and wireless stations transmitting in the area. This is useful for determining whether an access point is functioning properly, whether it is positioned correctly so that all the stations it serves are within its range, and whether stations and access points are communicating over the proper channels within a frequency band. Some programs can also capture the data transmitted between stations and access points. This information is useful for troubleshooting wireless connection problems (for example, poor performance or intermittent faults) after you’ve verified that connectivity is present. And some programs contain a spectrum analyzer, a tool that can assess the quality of the wireless signal. Spectrum analysis is useful, for example, to ascertain where interference is greatest.

Software that can perform wireless network assessment is often available for free and may be provided by the access point’s manufacturer. Following is a list of specific capabilities common to wireless network testing tools:

·         Identify transmitting access points and stations and the channels over which they are communicating

·         Measure signal strength from and determine the range of an access point

·         Indicate the effects of attenuation, signal loss, and noise

·         Interpret signal strength information to rate potential access point locations

·         Ensure proper association and reassociation when moving between access points

·         Capture and interpret traffic exchanged between wireless access points and stations

·         Measure throughput and assess data transmission errors

·         Analyze the characteristics of each channel within a frequency band to indicate the clearest channels

Some companies have created testing instruments whose sole purpose is to assess the status of wireless networks. These tools can perform the same detection, data capture, and spectrum analysis functions as the software tools described previously.

One advantage to using such devices, however, is that they are typically more portable than a laptop or desktop workstation. Second, they come installed with all the wireless network analysis tools you’ll need, and these are usually accessible from one simple, graphical interface. A third advantage is that most wireless testing tools contain more powerful antennas than a workstation NIC. A more powerful antenna could mean the difference between assessing the wireless network for an entire building from your desk versus walking around to each floor with your laptop. Figure 13-11 shows one example of such a wireless network testing tool.

Chapter Summary

■ The key to solving network problems is to approach them methodically and logically, using your experience to inform your decisions and knowing when to ask for someone else’s help.

■ The first step in troubleshooting is identifying the problem and its symptoms. Symptoms can include error messages, the inability to perform certain functions on the network, performance issues with connections or devices, or the inability to connect to a network. Record what you learn about symptoms.

■ Part of identifying the problem is defining the affected area. In general, a network problem may be limited to one user; all users on a segment; all users on a network; certain types of users, departments, or locations; or certain times of the day or week. Also,  the user to make sure he is performing all functions correctly.

■ At each point in the troubleshooting process, stop to consider what kind of changes have occurred on the network that might have created a problem. Changes pertaining to hardware may include the addition of a new device, the removal of an old device, a component upgrade, a cabling upgrade, or an equipment move. Changes pertaining to software may include an operating system upgrade, a device driver upgrade, a new application, or a changed configuration.

■ After gathering information about a problem and its symptoms, attempt to re-create the problem and then assess physical and logical connectivity related to it. These steps help establish a theory of probable cause for the problem.

■ Next, test your theory to determine whether it truly is the problem’s cause. For example, check or try replacing physical components. Review client, server, and device configurations. Use tools such as ping and traceroute to test physical and logical connectivity.

■ Establish a plan of action to resolve the problem. Assess the scope, trade-offs, security implications, scalability, and cost of your plan. Refer to vendor documentation. If necessary, review your plan with a more experienced colleague to be sure it is sound.

■ Implement the solution or escalate the troubleshooting process. That is, decide whether you and other first-level support personnel can solve the problem or whether it should be transferred to second- or third-level support personnel. Whether or not the problem is escalated, you or the appropriate troubleshooting personnel should alert all users who might be affected by any changes. Keep notes about your troubleshooting handy and create ways of backing out of the change if something goes wrong (for example, store a copy of a switch’s configuration before you make significant changes to it).

■ After implementing a solution, verify full system functionality to ensure that you solved the problem and haven’t created new problems. The type of testing you perform will depend on your solution. If the solution required significant network changes, revisit the solution a day or two after you implement it to verify that it has truly worked and not caused additional problems.

■ Finally, document findings, actions, and outcomes. Some organizations use a software program for documenting problems, known as a call tracking system (or help desk software). These programs provide a user-friendly graphical interface that prompts the user for every piece of information associated with the problem.

■ A tone generator and tone locator are used to identify the terminating location of a wire pair.

■ A multimeter is a simple device that can measure the voltage, resistance, impedance, and other characteristics of an electrical circuit. On a network, it can, among other things, verify proper cable terminations and detect noise that might adversely affect a connection.

■ Basic cable continuity testers determine whether your cabling can provide connectivity.

In the case of copper-based cables, they apply a small voltage to each conductor at one end of the cable, and then check whether that voltage is detectable at the other end.

A good cable checker will also verify that the wires are paired correctly and that they are not shorted, exposed, or crossed.

■ A cable performance tester accomplishes the same continuity and fault tests as a continuity tester, but also ensures that the cable length is not too long, measures the distance to a cable fault, measures attenuation along a cable, measures near-end cross talk between wires, measures termination resistance and impedance, issues pass/fail ratings for Cat 3, Cat 5, Cat 5e, Cat 6, Cat 6a, and Cat 7 standards, and stores and prints test results.

■ A voltage event recorder captures information about power quality. The data captured by the voltage event recorder can then be analyzed using the accompanying software. Analyzing the data allows you to pinpoint any power anomalies, such as excessive current or drops in voltage.

■ A butt set is a common term for a telephone test set or lineman’s handset, a tool that resembles an oversized telephone and allows technicians to access and test a local loop telephone connection.

■ A network monitor is a software-based tool that monitors network traffic from a server or workstation attached to the network. Network monitors typically can interpret up to Layer 3 of the OSI model. They can determine the protocols passed by each packet, but can’t interpret the data inside the packet.

■ Protocol analyzers can typically interpret data up to Layer 7 of the OSI model. They can also interpret the payload portion of packets, translating from binary or hexadecimal code to human-readable form. Protocol analyzers may be software programs or devices dedicated to protocol analysis.

■ Wireless network testing tools can be dedicated instruments or software that runs on a workstation (usually a laptop). They can discover wireless access points and stations, measure signal strength and interference, capture and interpret wireless data, measure throughput and identify data errors, and ensure proper association and reassociation between stations and access points.

Key Terms

·         baseline - A record of how a network operates under normal conditions (including its performance, collision rate, utilization rate, and so on). Baselines are used for comparison when conditions change.

·         butt set - A tool for accessing and testing a telephone company’s local loop. The butt set, also known as a telephone test set or lineman’s handset, is essentially a telephone handset with attached wires that can be connected to local loop terminations at a demarc or switching facility.

·         cable checker - See continuity tester.

·         cable performance tester - A troubleshooting tool that tests cables for continuity, but can also measure cross talk, attenuation, and impedance; identify the location of faults; and store or print cable testing results.

·         cable tester - A device that tests cables for one or more of the following conditions: continuity, segment length, distance to a fault, attenuation along a cable, near-end cross talk, and termination resistance and impedance. Cable testers may also issue pass/fail ratings for wiring standards or store and print cable testing results.

·         call tracking system - A software program used to document technical problems and how they were resolved (also known as help desk software).

·         change management system - A process or program that provides support personnel with a centralized means of documenting changes made to the network.

·         continuity tester - An instrument that tests whether voltage (or light, in the case of fiber-optic cable) issued at one end of a cable can be detected at the opposite end of the cable. A continuity tester can indicate whether the cable will successfully transmit a signal.

·         escalate - In network troubleshooting, to refer a problem to someone with deeper knowledge about the subject. For example, a first-level support person might escalate a router configuration issue to a second- or third-level support person.

·         first-level support - In network troubleshooting, the person or group who initially fields requests for help from users.

·         ghost - A frame that is not actually a data frame, but rather an aberration caused by a device misinterpreting stray voltage on the wire. Unlike true data frames, ghosts have no starting delimiter.

·         giant - A packet that exceeds the medium’s maximum packet size. For example, any Ethernet packet that is larger than 1518 bytes is considered a giant.

·         help desk analyst - A person who is proficient in basic (but not usually advanced) workstation and network troubleshooting. Help desk analysts are part of first-level support.

·         help desk coordinator - A person who ensures that help desk analysts are divided into the correct teams, schedules shifts at the help desk, and maintains the infrastructure to enable analysts to better perform their jobs. They might also serve as third-level support personnel, taking responsibility for troubleshooting a problem when the second-level support analyst is unable to solve it.

·         jabber - A device that handles electrical signals improperly, usually affecting the rest of the network. A network analyzer will detect a jabber as a device that is always retransmitting, effectively bringing the network to a halt. A jabber usually results from a bad NIC. Occasionally, it can be caused by outside electrical interference.

·         late collision - A collision that takes place outside the normal window in which collisions are detected and redressed. Late collisions are usually caused by a defective station (such as a card, or transceiver) that is transmitting without first verifying line status or by failure to observe the configuration guidelines for cable length, which results in collisions being recognized too late.

·         lineman’s handset - See butt set.

·         local collision - A collision that occurs when two or more stations are transmitting simultaneously. Excessively high collision rates within the network can usually be traced to cable or routing problems.

·         multimeter - A simple instrument that can measure multiple characteristics of an electric circuit, including its resistance and voltage.

·         negative frame sequence check - The result of the CRC (cyclic redundancy check) generated by the originating node not matching the checksum calculated from the data received. It usually indicates noise or transmission problems on the LAN interface or cabling. A high number of (nonmatching) CRCs usually results from excessive collisions or a station transmitting bad data.

·         network analyzer - See protocol analyzer.

·         network monitor - A software-based tool that monitors traffic on the network from a server or workstation attached to the network. Network monitors typically can interpret up to Layer 3 of the OSI model.

·         Network Monitor - A network monitoring program from Microsoft that comes with Windows operating systems.

·         ohmmeter - A device used to measure resistance in an electrical circuit.

·         optical time domain reflectometer - See OTDR.

·         OTDR (optical time domain reflectometer) - A performance testing device for use with fiber-optic networks. An OTDR works by issuing a light-based signal on a fiber-optic cable and measuring the way in which the signal bounces back (or reflects) to the OTDR. By measuring the length of time it takes the signal to return, an OTDR can determine the location of a fault.

·         packet sniffer - See protocol analyzer.

·         probe - See tone locator.

·         promiscuous mode - The feature of a network adapter that allows it to pick up all frames that pass over the network - not just those destined for the node served by the card.

·         protocol analyzer - A software package or hardware-based tool that can capture and analyze data on a network. Protocol analyzers are more sophisticated than network monitoring tools, as they can typically interpret data up to Layer 7 of the OSI model.

·         second-level support - In network troubleshooting, a person or group with deeper knowledge about a subject and to whom first-level support personnel escalate problems.

·         sniffer - See protocol analyzer.

·         spectrum analyzer - A tool that assesses the characteristics (for example, frequency, amplitude, and the effects of interference) of wireless signals.

·         supported services list - A document that lists every service and software package supported within an organization, plus the names of first- and second-level support contacts for those services or software packages.

·         TDR (time domain reflectometer) - A high-end instrument for testing the qualities of a cable. It works by issuing a signal on a cable and measuring the way in which the signal bounces back (or reflects) to the TDR. Many performance testers rely on TDRs.

·         telephone test set - See butt set.

·         third-level support - In network troubleshooting, a person or group with deep knowledge about specific networking topics to whom second-level support personnel escalate challenging problems.

·         time domain reflectometer - See TDR.

·         tone generator - A small electronic device that issues a signal on a wire pair. When used in conjunction with a tone locator, it can help locate the termination of a wire pair.

·         tone locator - A small electronic device that emits a tone when it detects electrical activity on a wire pair. When used in conjunction with a tone generator, it can help locate the termination of a wire pair.

·         toner - See tone generator.

·         voltage event - Any condition in which voltage exceeds or drops below predefined levels.

·         voltage event recorder - A device that, when plugged into the same outlet that will be used by a network node, gathers data about the power that outlet will provide the node.

·         voltmeter - A device used to measure voltage (or electrical pressure) on an electrical circuit.

Review Questions

1.   Which of the following symptoms may point to a faulty switch port?

a.   A group of users consistently experiences delays on the network only at 8:00 a.m. on weekdays.

b.   A user can save files to a network drive, but receives errors when trying to save files on his hard disk.

c.   Twelve users in one department complain that they cannot log on to the network.

d.   A user can send e-mail but can't pick it up.

2.   You are helping a user who cannot connect to the Internet from her wireless workstation on your company's LAN. After determining that she is the only user having this problem, and that user error is not the problem's cause, what is the next thing you check?

a.   Her workstation's wireless connection configuration

b.   The cabling between her department's switch and the LAN backbone

c.   Her workgroup's access point

d.   Her segment's router interface

3.   You are working at the help desk and take a call from a user who cannot log on to the network. After verifying that this user is the only person affected, you ask for his username and password and try replicating the problem. When you can successfully log onto the network with his user name and password from your help desk workstation, which of the following causes can you rule out?

a.   User error

b.   Faulty cabling between the user's workstation and the wall jack c.   Improper protocol configuration on his workstation

d.  None of the above

4. As a help desk analyst, or first-level support technician, which of the following calls are you most likely to escalate to second-level support personnel?

a.   A user from the Accounting Department complains that she can't log onto the company's file server.

b.   A user from the Research Department complains that for the last five hours he has not been able to send or receive e-mail from his smartphone.

c.   A manager in the Sales Department complains that none of her 112 sales people across the country can connect to the company's VPN.

d.   A manager in the Human Resources Department complains that all the document templates he saved to the file server appear to be missing.

5.   To help you identify the area affected by a problem, which of the following s might provide the answers you need?

a.   When did the problem first occur?

b.   How frequently does the problem occur?

c.   How many users have similar symptoms?

d.   Does the problem occur at the same time every day?

6.  You have recently resolved a problem in which a user could not print to a particular shared printer by upgrading her workstation's client software. Which of the following might be an unintended consequence of your solution?

a.   The user complains that word-processing files on her hard disk take longer to open.

b.  The user is no longer able to log on to the network.

c.   The shared printer no longer allows users to print double-sided documents.

d.   The shared printer no longer responds to form-feed commands from the print server.

7.   You are troubleshooting a problem that you suspect is caused by an Internet gateway failure. Assuming your organization relies on only one Internet gateway, which of the following symptoms would lead you to focus on that gateway as the source of the problem?

a.   All users on a network are unable to retrieve e-mail.

b.   Workstations on one segment are experiencing slow response when using collaboration software on the LAN.

c.   Some users on a segment are receiving errors when they attempt to print to any printer.

d.   Some workstations on a segment cannot run the same application from the fileserver.

8.   Which of the following is an example of a network change that could cause only one group of workstations out of the dozen workgroups in your organization to lose connectivity to a local file server?

a.   The organization changes its main Internet connection from one carrier to another.

b.  The configuration on a switch in the telecommunications closet is upgraded.

c.   The organization upgrades its backbone to 1-Gigabit Ethernet.

d.   A new backup device is installed and attached to the main file server.

9.   Which of the following tools could you use to determine whether a user's workstation is transmitting packets in the proper Ethernet frame type for your network?

a.   Protocol analyzer

b.   Continuity tester

c.   Multimeter

d.   Tone generator and tone locator

10.  Suppose a user on your organization's network has changed the subnet mask value in his network interface's TCP/IP properties. Which of the following symptoms might he report when he calls the help desk?

a.   He cannot connect to the Internet.

b.   He cannot print to a shared printer on the network.

c.   He cannot save a document to the network's file server.

d.  All of the above

11.  Which of the following symptoms would probably be present if a client’s NIC was set to transmit data in half-duplex mode while the switch port to which it was attached was configured for full-duplex mode?

a.   Excessive normal collisions

b.   Giants

c.   Excessive late collisions

d.   Cross talk

12. Which of the following tools would you use to verify that your new cable meets Cat 6a standards?

a.   Continuity tester

b.   Protocol analyzer

c.   Network monitor

d.   Tone generator and tone locator

13. What function of a wireless network testing tool measures the amount of interference on a certain channel within a frequency band?

a.   Network monitor

b.  Spectrum analyzer

c.   Site selector

d.   Protocol analyzer

14. You are troubleshooting a connectivity problem that you believe is related to a faulty cable between a switch and a punch-down block. However, in the disorganized telecommunications closet, it seems impossible to determine which cable belongs to the switch by simply looking at the punch-down block. You decide to use a tone generator and locator to find the cable. Where will you issue the tone?

a.   At the punch-down block, near where you think the switch's cable might be

b.   At the end of the cable connected to the switch's management port

c.   At the end of the cable that connects the workgroup punch-down block with the entrance facility punch-down block

d.  At the end of the cable connected to the switch's uplink port

15. Which of the following frequently results in negative frame sequence checks?

a.   Noise

b.   Excessive nodes on a segment

c.   Excessive segment length

d.   Improper flow control

16. You have been asked to help solve a problem that suddenly appeared on your company's network. All data transmission has slowed to a crawl. You suspect a DOS attack or a broadcast storm. Which of the following tools would help you determine the source of either of these problems?

a.   OTDR

b.   Cable continuity tester

c.   Butt set

d.  Protocol analyzer

17. You are using your wireless LAN connection to copy documents to a shared folder on your company's file server, when suddenly the connection stalls out. You check your wireless connection status, which indicates that you are still associated with your AP. Next, you run a protocol analyzer program on your workstation, which indicates an excessive number of lost or dropped packets between your workstation and the AP. Which of the following causes could be at fault?

a.   Another user is attempting to log on under your user name.

b.   The access point has lost power.

c.   A source of excessive EMI has been introduced.

d.   Another AP has been added to the network.

18. You are troubleshooting a fiber-optic connection on your 1-Gigabit LAN backbone. You suspect one of your fiber cross-connects is dirty, resulting in poor performance over the backbone. What tool will help you determine the location of the dirty cross- connect?

a.   Multimeter

b.   Sniffer

c.   Network monitor

d.  OTDR

19. You have decided to take a break from your position at a telephone company's helpdesk and accompany a field technician to learn how to troubleshoot local loops. Which of the following tools will help you verify that a line is receiving dial tone from the CO (central office)?

a.   OTDR

b.  Butt set

c.   Sniffer

d.   TDR

20. After your Internet service provider makes some changes in the way they connect to their network service provider, your organization’s connection to a customer’s Web site becomes noticeably slower. Which of the following troubleshooting tools helps you identify the number of hops between your office and the customer’s Web site?

a.   netstat

b.   dig

c.   ping

d.  traceroute

Practice Test

1. A ____ is useful for quickly and easily verifying that a node’s NIC is transmitting and receiving signals properly.

a.       crossover cable

b.      tone generator

c.       multimeter

d.      continuity tester

 2

    A(n) ____ analyst is someone who has specialized knowledge in one or more aspects of a network.

second-level support

 3

    Some NOSs come with network monitoring tools.

    True

    False

 4

    The difference between continuity testers and performance testers lies in their sophistication and price.

    True

    False

 5

    The ____ ensures that analysts are divided into the correct teams, schedules shifts at the help desk, and maintains the infrastructure to enable analysts to better perform their jobs.

                       

    lineman's handset

                       

    help desk coordinator

                       

    protocol analyzer

                       

    OTDR

 6

    A(n) ____________________ collects data about power quality.

voltage event recorder                                                           

                                               

           

7

    In ____, a device driver directs the NIC to pick up all frames that pass over the network— not just those destined for the node served by the card.

promiscuous mode

 8

    Networking personnel should only record their changes when requested by senior management.

                       

    True

                       

    False

 9

    A ____ is a simple instrument that can measure many characteristics of an electric circuit, including its resistance and voltage.

                       

    multimeter

                       

    probe

                       

    protocol analyzer

                       

    network monitor

 10

    A multimeter can assess the quality of the wireless signal.

                       

    True

                       

    False

 11

    A(n) ____________________ is a tool that can assess the quality of the wireless signal.

spectrum analyzer

12

    Before swapping any network component, make sure that the replacement has the same specifications as the original part.

                       

    True

                       

    False

 13

    A good, general rule for troubleshooting can be stated as follows: Pay attention to the ____!

obvious

 14

    Experience in a network environment may prompt a network professional to follow the troubleshooting steps in a different order or to skip certain steps entirely.

    True

    False

 15

    One danger in troubleshooting technical problems is jumping to conclusions about the ____________________.

    symptoms

16

    A(n) ____ is a process or program that provides support personnel with a centralized means of documenting changes to the network.

change management system

 17

    To find the probable cause, you might need to ____.

                       

    Identify the symptoms and problems

                       

    Verify user competency

                       

    Determine what has changed

                       

    Determine whether escalation is necessary

 18

    When troubleshooting a network problem, you should never re-create the problem.

                       

    True

                       

    False

 19

    Physical connectivity problems often prove more difficult to isolate and resolve than logical connectivity problems because they can be more complex.

    True

    False

 20

    A(n) ____ is a document (preferably online) that lists every service and software package supported within an organization, plus the names of first- and second-level support contacts for those services or software packages.

    supported services list

                       

  

 21

    It is best to roll out changes in stages for large systems.

    True

    False

 22

    What might be the last step in troubleshooting network problems?

                       

    Verify user competency.

                       

    Implement the solution and test the result.

                       

    Document the solution and process.

                       

    Create an action plan.

Chapter Test

1. Logical connectivity problems often prove more difficult to isolate and resolve than physical connectivity problems.

    True

    False

 2

    The danger in using a ____ is that it could collect more information than you or the machine can reasonably process.

            a.        

    cable continuity tester

            b.        

    protocol analyzer

            c.        

    multimeter

            d.        

    wireless network tester

 3

    A ____ system is a process or program that provides support personnel with a centralized means of documenting changes to the network.

            a.        

    change management

            b.        

    asset management

            c.        

    change document

            d.        

    release management

 4

    A sophisticated ____________________ will include a TDR (time domain reflectometer) that issues a signal on a cable and then measures the way the signal bounces back (or reflects) to the TDR.

performance tester

 5

    Continuity testers can only be used to test copper cable.

    True

    False

 6

    ____ are often considered third-level support.

            a.        

    Help desk analysts

            b.        

    Technical specialists

            c.        

    Administrators

            d.        

    Help desk coordinators

 7

    ____ is a fundamental property of wire that depends on a wire’s molecular structure and size.

            a.        

    Resistance

            b.        

    Current

            c.        

    Impedance

            d.        

    Voltage

 8

    Before using a network monitor or protocol analyzer on a network, it is important to know what ____ on your network normally looks like.

            a.        

    jabber

            b.        

    runts

            c.        

    traffic

            d.        

    current

 9

    To take advantage of network monitoring and analyzing tools, the network adapter installed in the machine running the software must support ____ mode.

            a.        

    continuous

            b.        

    open

            c.        

    promiscuous

            d.        

    static

 10

    Network engineers today might call any protocol analyzer tool a(n) ____________________.

sniffer

 11

    An administrator should take the time to troubleshoot all network problems correctly by asking specific s designed to identify the problem ____.

            a.        

    intensity

            b.        

    focus

            c.        

    scope

            d.        

    background

 12

    ____ is the telltale factor for ascertaining where faults in a cable lie.

            a.        

    Voltage

            b.        

    Current

            c.        

    Resistance

            d.        

    Impedance

 13

    Some software errors point to a physical connectivity problem.

    True

    False

 14

    A ____ usually results from a bad NIC.

            a.        

    jabber

            b.        

    giant

            c.        

    ghost

            d.        

    runt

 15

    ____ are frames that are not actually data frames, but aberrations caused by a device misinterpreting stray voltage on the wire.

            a.        

    Ghosts

            b.        

    Jabbers

            c.        

    Giants

            d.        

    Runts

 16

    Most wireless testing tools contain more powerful antennas than a workstation NIC.

    True

    False

 17

    Rather than issue an electrical signal over the cable as twisted pair cable testers do, a(n) ____________________ transmits light-based signals of different wavelengths over the fiber.

OTDR

 18

    When used on a copper-based cable, a continuity tester applies a small amount of ____ to each conductor at one end of the cable.

            a.        

    current

            b.        

    impedance

            c.        

    voltage

            d.        

    resistance

 19

    A ____ can be used to intercept a telephone conversation.

            a.        

    butt set

            b.        

    sniffer

            c.        

    protocol analyzer

            d.        

    network monitor

 20

    ____ are often considered first-level support.

            a.        

    Network specialists

            b.        

    Administrators

            c.        

    Help desk coordinators

            d.        

    Help desk analysts

 21

    A help desk is typically staffed with ____________________ - people proficient in workstation and network troubleshooting.

help desk analysts

 22

    Tone generators and tone locators are used to determine characteristics about a cable.

    True

    False

 23

    A____ is a small electronic device that issues a signal on a wire pair.

            a.        

    probe

            b.        

    probe kit

            c.        

    tone generator

            d.        

    tone locator

 24

    A ____ can generate traffic in an attempt to reproduce a network problem and monitor multiple network segments simultaneously.

            a.        

    protocol analyzer

            b.        

    multimeter

            c.        

    cable performance tester

            d.        

    network monitor

 25

    A ____ is a tool that can assess the quality of the wireless signal.

            a.        

    spectrum analyzer

            b.        

    quality analyzer

            c.        

    function analyzer

            d.        

    signal analyzer