This chapter begins with a quick review of cabling practices. If your cabling isn't adequate, that's the first thing you need to address. Next, there is a lengthy discussion of using ping to test connectivity along with issues that might arise when using ping, such as security problems. Next, I describe alternatives to ping. Finally, I discuss alternatives that run on Microsoft Windows platforms.
Although this is a book about software tools, not cabling, the topics are not unrelated. If you have a cabling problem, you may need to turn to the tools described later in this chapter to pinpoint the problem. Conversely, to properly use these tools, you can't ignore cabling, as it may be the real source of your problems.
If a cable is damaged, it won't be difficult to recognize the problem. But intermittent cabling problems can be a nightmare to solve. The problem may be difficult to recognize as a cabling problem. It may come and go, working correctly most of the time. The problem may arise in cables that have been in use for years. For example, I once watched a technician try to deal with a small classroom LAN that had been in use for more than five years and would fail only when the network was heavily loaded, i.e., if and only if there was a scheduled class in the room. The problem took weeks before what proved to be a cabling problem was resolved. In the meantime, several classes were canceled.
A full discussion of cabling practices, standards, and troubleshooting has been the topic of several books, so this coverage will be very selective. I am assuming that you are familiar with the basics. If not, several references in Appendix B, "Resources and References" provide a general but thorough introduction to cabling.
With cabling, as with most things, it is usually preferable to prevent problems than to have to subsequently deal with them. The best way to avoid cabling problems is to take a proactive approach. While some of the following suggestions may seem excessive, the costs are minimal when compared to what can be involved in solving a problem.
Cabling is usually a large investment. Correcting cabling problems can be very costly in lost time both for diagnosing the problem and for correcting the problem. Also, cabling must conform to all applicable building and fire codes. For example, using nonplenum cabling in plenum spaces can, in the event of a fire, greatly endanger the safety of you and your fellow workers. (Plenum cabling is cabling designed to be used in plenum spaces, spaces used to recirculate air in a building. It uses materials that have low flame-spread and low smoke-producing properties.)
Cabling can also be very sensitive to its physical environment. Cable that runs too near fluorescent lights or large motors, e.g., elevator motors, can be problematic. Proximity to power lines can also cause problems. The network cable acts like an antenna, picking up other nearby electrical activity and introducing unwanted signals or noise onto the network. This can be highly intermittent and very difficult to identify. Concerns such as these should be enough to discourage you from doing the job yourself unless you are very familiar with the task.
Unfortunately, sometimes budget or organizational policies are such that you will have no choice but to do the job yourself or use internal personnel. If you must do the job yourself, take the time to learn the necessary skills before you begin. Get formal training if at all possible. Invest in the appropriate tools and test equipment to do the job correctly. And make sure you aren't violating any building or fire codes.
If the wiring is handled by others, you will need to evaluate whether those charged with the task really have the skill to complete the job. Most electricians and telephone technicians are not familiar with data cabling practices. Worse still, many don't realize this. So, if asked, they will reassure you they can do the job. If possible, use an installer who has been certified in data cabling. Once you have identified a likely candidate, follow up on her references. Ask for the names of some past customers and call those customers. If possible, ask to see some of her work.
When planning a project, you should install extra cable whenever feasible. It is much cheaper to pull extra cable as you go than to go back and install new cable or replace a faulty cable. You should also consider technologies that will support higher speeds than you are currently using. For example, if you are using 10-Mbps Ethernet to the desktop, you should install cable that will support 100 Mbps. In the past it has been a common recommendation to install fiber-optic cables to the desk as well, even if you aren't using fiber technologies at the desk at this time. Recent developments with copper cables have made this more of a judgment call. Certainly, you will want to pull spare fiber to any point your backbone may eventually include.
If at all feasible, cabling should be certified. This means that each cable is tested to ensure that it meets appropriate performance standards for the intended application. This can be particularly important for spare cabling. When it is time to use that cable, you don't want any nasty surprises.
Adequate documentation is essential. Maintenance will be much simpler if you follow cabling standards and use one of the more common structured cable schemes. More information can be found in the sources given in Appendix B, "Resources and References".
The first step in cable management is knowing which cable is which and where each cable goes. Perhaps the most important tool for the management and troubleshooting of cabling is a good label maker. Even if you weren't around when the cable was originally installed, you should be able, over time, to piece together this information. You will also want to collect basic information about each cable such as cable types and lengths.
You will want to know which of your cables don't meet standards. If you have one of the more sophisticated cable testers, you can self-certify your cabling plant. You probably won't want to do either of these tasks all at once, but you may be able to do a little at a time. And you will definitely want to do it for any changes or additions you make.
Labeling CablesThis should be a self-explanatory topic. Unfortunately for some, this is not the case. I have very vivid memories of working with a wiring technician with years of experience. The individual had worked for major organizations and should have been quite familiar with labeling practices.
We were installing a student laboratory. The laboratory has a switch mounted in a box on the wall. Cabling went from the box into the wall and then through cable raceways down the length of the room. Along the raceway, it branched into raceways built into computer tables going to the individual computers. The problem should be clear. Once the cable disappears into the wall and raceways, it is impossible to match the end at the switch with the corresponding end that emerges at the computer.
While going over what needed to be done, I mentioned, needlessly I thought, that the cable should be clearly labeled. This was just one part of my usual lengthy litany. He thought for a moment and then said, "I guess I can do that." Then a puzzled expression came over his face and he added in dead earnest, "Which end do you want labeled?" I'd like to think he was just putting me on, but I don't think so.
You should use some method of attaching labels that is reasonably permanent. It can be very discouraging to find several labels lying on the floor beneath your equipment rack. Also, you should use a meaningful scheme for identifying your cables. TIA/EIA-606 Administration Standard for Telecommunications Infrastructure of Commercial Buildings provides one possibility. (See Appendix B, "Resources and References" for more information of TIA/EIA standards.) And, at the risk of stating the obvious, unless you can see the entire cable at the same time, it should be labeled at both ends.
Many devices have additional indicators that give you more information. It is not uncommon to have a transmit light that blinks each time a packet is sent, a receive light that blinks each time a packet is received, and a collision light that blinks each time the device detects a collision. To get an idea of what is normal, look at the lights on other computers on the same network.
Typically, you would expect to see the receive light blinking intermittently as soon as you connect the device to an active network. Generally, anomalous behavior with the receive light indicates a problem somewhere else on your network. If it doesn't ever light, you may have a problem with your connection to the network. For example, you could be plugged into a hub that is not connected to the network. If the light is on all or most of the time, you probably have an overloaded network.
The transmit light should come on whenever you access the network but should remain off otherwise. You may be surprised, however, how often a computer will access the network. It will almost certainly blink several times when your computer is booted. If in doubt, try some basic networking tasks while watching for activity. If it does not light when you try to access the network, you have problems on that computer. If it stays lit, you not only have a problem but also are probably flooding the network with packets, thereby causing problems for others on the network as well. You may want to isolate this machine until the problem is resolved.
In the ideal network, from the user's perspective at least, the collision light should remain relatively inactive. However, excessive collision light flashing or even one that remains on most of the time may not indicate a problem. A collision is a very brief event. If the light only remained on for the length of the event, the flash would be too brief to be seen. Consequently, these lights are designed to remain on much longer than the actual event. A collision light that remains on doesn't necessarily mean that your network is saturated with collisions. On the other hand, this is something you'll want to investigate further.
For any of the cases in which you have an indication of a network overload, unless your network is completely saturated, you should be able to get some packets through. And you should see similar problems on every computer on that network segment. If your network is completely saturated, then you may have a malfunctioning device that is continuously transmitting. Usually, this can be easily located by turning devices off one at a time until the problem suddenly disappears.
If you have an indication of a network overload, you should look at the overall behavior and structure of your network. A good place to start is with netstat as discussed in Chapter 4, "Path Characteristics". For a more thorough discussion of network performance monitoring, turn to Chapter 8, "Performance Measurement Tools".
WARNING: One last word of warning -- you may see anomalous behavior with any of these lights if your interface is misconfigured or has the wrong driver installed.
The better cable testers may be preprogrammed with appropriate values for different types of cable, allowing you to quickly identify parameters that are out of specification. A good tester should also allow you to print or upload measurements into a database. This allows you to easily compare results over time to identify changes.
If the cable in question is not installed in the wall, you can try to test it by swapping it with a cable known to be good. However, it is usually better to replace a working cable with a questionable cable and see if things continue to work rather than the other way around. This method is more robust to multiple failures. You will immediately know the status of the questionable cable. If you replace a questionable cable with a good cable and you still have problems, you clearly have a problem other than the cable. But you don't know if it is just a different problem or an additional problem. Of course, this approach ties up more systems.
Remember, electrical connectivity does not equate to network connectivity. I've seen technicians plug different subnets into the same hub and then wonder why the computers can't communicate.
|2.3. Microsoft Windows||3.2. Testing Adapters|
Copyright © 2002 O'Reilly & Associates. All rights reserved.