Networking Guide 9 - Network Troubleshooting

This log file tracks just about every event that occurs on that computer. It is similar to NetWare’s SYS$LOG.ERR file. However, whereas the SYS$LOG.ERR file tracks many categories of errors, the System Log tracks only three main types of events:

• Information (an event occurred, especially when a service fails)
  
• Warning (an event occurred that could cause problems)
  
• Error (a component has failed and needs immediate attention)
  

In a log file, the icon that precedes the date indicates the event’s type
Note Two other types of events (Audit Success and Audit Failure) normally appear only in the Security Log (discussed later in this chapter).



This list contains several categories of information, including the date and time the event occurred, the source of the event (which process the event came from), which user (if applicable) initiated the process, the name of the computer the event happened on, and the Event ID number (in the Event column). The Event ID number is the unique error type of a particular event. For an explanation of each Event ID number, check the Help file, or go to www.microsoft.com/technet/ and search for Event ID.

The note in the Description box indicates that Windows NT found a bad disk block. Even though this is an error event, it is not serious. One bad block is not a problem, unless several disk blocks start going bad at once. The Data box lists the exact data the Event Viewer received about the error condition. This may be useful in determining the source of the problem. More than likely, if you have a serious problem that you can’t fix, this is the information that you will send to the vendor (or to Microsoft) to help troubleshoot the problem.

This log is similar to the other two logs, except that it tracks events for network services and applications (for example, SQL Server and other Back-Office products). It uses the same event types (and their associated icons) as the System Log.

To access the Application Log, in Event Viewer, choose Log - Application. The Sources column indicates which service logged which event.

All together, the log files present a picture of the general health of a Windows NT server. Generally speaking, if you see an error message, open Event Viewer and check the System Log. If you don’t see the event here, check the other two logs.

This log tracks security events specified by the domain’s Audit policy. The Audit policy is set in User Manager for Domains and specifies which security items will be tracked in Event Viewer. To set the Audit policy, follow these steps:

1. Choose Start - Programs - User Manager for Domains to open User Manager for Domains.
   
2. Choose Policy - Audit to open the Audit Policy dialog box:
   
3. Indicate the events that you want logged and check the Success or Failure check boxes to track the success and failure of those events. Since these are security settings, most often you’ll want to log failures.
   
4. Click OK, and these events will be logged for all users and systems in the domain
   

After you set the Audit policy for a domain, you can view the Security Log for any computer in that domain. Follow these steps:

1. Choose Start - Programs - Administrative Tools (Common) to open the Select Computer dialog box.
   
2. In the Computer field, enter the UNC (Universal Naming Convention) name of the computer whose events you want to view.
   
3. If you are connected to a Windows NT network over a slower link, such as a slow WAN link or a dial-up connection, click the Low Speed Connection check box to optimize Event Viewer for running over the lower-speed connection.
   
4. Click OK.
   
5. Choose Log - Security to open the Security Log for that computer
   

As you can see, this log looks similar to the System Log in most respects. The main differences are the icons and the types of events recorded here. To view the detail for an event, double-click it.

The Security Log displays two types of events:

• Success Audit (the event passed the security audit)
• Failure Audit (the event failed the security audit)

When an item fails a security audit, something security-related failed. For example, a common entry (assuming the Logon Failure check box is checked in the Audit Policy dialog box) is a Failure Audit with a value of Logon/ Logoff in the category. This means that the user failed to log on
This log is especially useful in troubleshooting when someone can’t access a resource. If your domain security policy has been set to log Failures of Use of User Rights, you can see every instance of a user not having enough rights to access a resource. The username appears in the User column of the Failure Audit event for the resource the user is trying to access.

In addition to viewing log files, you can use several types of troubleshooting tools that manufacturers make available for their network operating systems. You can use these resources to augment your own knowledge, as well as to solve those pesky problems that have no pattern or few recognizable symptoms. Each type of resource provides different information or different levels of support (some of which have been discussed in previous chapters, but their importance to troubleshooting necessitates discussing them again here). Let’s examine the most popular, including:

• README files
  
• Telephone support
  
• Technical support CD-ROM
  
• Technical support website
  

README Files

README files contain information that did not make it into the manual. The latest information released about the software can often be found in the README files. Also, they may contain tips, default settings, and installation information (so you don’t have to read the entire first chapter to install the software).

When troubleshooting application or networking software, check out the README file before you try any of the other manufacturers’ resources. It is usually found on the first installation disk or CD.


Telephone Support

Many people prefer telephone support over other forms of support. You actually get to talk to a human being from the software manufacturer about the problem. Most, if not all, software manufacturers have toll-free support numbers. The people on their end of the line can provide anything from basic how-to answers to complex, technical answers.

Unfortunately, because of their popularity, technical support phone lines are often busy. When the line is finally free, you might, however, find yourself in “voicemail hell.” We’ve all been through it: Press 1 for support for products A, B, and C. Press 2 for Products D, E, and F, and so on and so on. Most people don’t want this and hang up. They prefer to speak with a human being as soon as the call is answered. Today, phone support is often not free (the number to reach support might be, but the support itself is not), but must be purchased via either a time-limited contract or on an incidentby-incident basis. This is particularly true for network operating system software support. To solve this problem, companies have devised other methods, such as the technical support CD-ROM and website, which we will discuss next.


The Technical Support CD-ROM

With the development of CD-ROM technology, it became possible to put volumes of textual information on a readily accessible medium. The CDROM was, thus, a logical distribution vehicle for technical support information. In addition, the CD was portable and searchable. Introduced in the early 1990s, Novell’s Network Support Encyclopedia (NSE) CD-ROM was one of the first products of this kind. Microsoft’s TechNet came soon after. Both companies charge a nominal fee for a yearly subscription to these CDs (anywhere from $100–$500).

To be sure, the first editions of these products (as with the first editions of most software products) left much to be desired. Search engines were often clumsy and slow, and the CDs were released only about twice a year. As these products evolved, however, their search engines became more advanced, they included more documents, and they were released more often. And, probably most important, manufacturers began to include software updates, drivers, and patches on the CD.


The Technical Support Website

The technical support CDs were great, but people started to complain (as people are wont to do) that because this information was vital to the health of their network, they should get it for free. Well, that is, in fact, what happened. The Internet proved to be the perfect medium for allowing network support personnel access to the same information that was on the technical support CD-ROMs. Additionally, websites can be instantly updated and accessed, so they provide the most up-to-date network support information. Since websites are hosted on servers that can store much more information than CD-ROMs, websites are more powerful than their CD-ROM counterparts. Because they are easy to access and use and because they are detailed and current, websites are now the most popular method for disseminating technical support information. As examples, you can view Novell’s technical support website at http://support.novell.com/ and Microsoft’s technical support website (Tech-Net, a monthly subscription) at http://support.microsoft.com/servicedesks/technet/.

In addition to manufacturer-provided troubleshooting tools, there are a few hardware devices we can use to troubleshoot the network. These are actual devices that you can use during the troubleshooting process. Some devices have easily recognizable functions; others are more obscure. Four of the most popular hardware tools (that the Network+ exam tests you on, by the way) are:

• A crossover cable
  
• A hardware loopback
  
• A tone generator
  
• A tone locator
  

The Crossover Cable

Sometimes also called a cross cable, a crossover cable is typically used to connect two hubs, but it can also be used to test communications between two stations directly, bypassing the hub. A crossover cable is used only in Ethernet UTP installations. You can connect two workstation NICs (or a workstation and a server NIC) directly using a crossover cable.

A normal Ethernet (10BaseT) UTP cable uses four wires—two to transmit and two to receive.
The standard Ethernet UTP crossover cable used in both situations has its transmit and receive wire pairs crossed so that the transmit set on one side (hooked to pins 1 and 2) is connected to the receive set (pins 3 and 6) on the other.

Tip Be sure to label a crossover cable as such to ensure that no one tries to use it as a workstation patch cable. If it is used as a patch cable, the workstation won’t be able to communicate with the hub and the rest of the network.


You can carry a crossover cable in the tool bag along with your laptop. If you want to ensure that a server’s NIC is functioning correctly, you can connect your laptop directly to the server’s NIC using the crossover cable. You should be able to log in to the server (assuming both NICs are configured correctly).

The Hardware Loopback

A hardware loopback is a special connector for Ethernet 10BaseT NICs. It functions similarly to a crossover cable, except that it connects the transmit pins directly to the receive pins. It is used by the NIC’s software diagnostics to test transmission and reception capabilities. You cannot completely test a NIC without one of these devices.
Usually, the hardware loopback is no bigger than a single RJ-45 connector with a few small wires on the back. If a NIC has hardware diagnostics that can use the loopback, the hardware loopback plug will be included with the NIC. To use it, simply plug the loopback into the RJ-45 connector on the back of the NIC and start the diagnostic software. Select the option in your NIC’s diagnostic software that requires the loopback, and start the diagnostic routine. You will be able to tell if the NIC can send and receive data through the use of these diagnostics.

Tone Generator and Tone Locator

This combination of devices is used most often on telephone systems to locate cables. Since telephone systems use multiple pairs of UTP, it is nearly impossible to determine which set of wires goes where. Network documentation would be extremely helpful in making this determination, but if no documentation is available, you can use a tone generator and locator.

Note Don’t confuse these tools with a cable tester that tests cable quality. You use the tone generator and locator only to determine which UTP cable is which.

The tone generator is a small electronic device that sends an electrical signal down one set of UTP wires. The tone locator is another device that is designed to emit a tone when it detects the signal in a particular set of wires. When you need to trace a cable, hook the generator (often called the fox) to the copper ends of the wire pair you want to find. Then move the locator (often called the hound because it chases the fox) over multiple sets of cables (you don’t have to touch the copper part of the wire pairs; this tool works by induction) until you hear the tone. A soft tone indicates that you are close to the right set of wires. Keep moving the tool until the tone gets the loudest. Bingo! You have found the wire set.

Warning Never hook a tone generator to a cable that is hooked up to either a NIC or a hub! Because the tone generator sends electrical signals down the wire, it can blow a NIC or a hub. That is why tone generators are not usually used on networks. Cable testers are used more often. We’ll discuss cable testers later in this chapter.

In addition to these hardware troubleshooting tools, you can use software programs to gain information about the current health and state of the network. These tools fall into two main categories:

• Protocol analyzers
  
• Performance-monitoring tools
  

We use the term network software diagnostics to refer to these tools.

Protocol Analyzer

Any software that can analyze and display the packets it receives can be considered a protocol analyzer. Protocol analyzers examine packets from protocols that operate at the lower four layers of the OSI model (including Transport, Network, Data Link, and Physical) and can display any errors they detect. Additionally, most protocol analyzers can capture packets and decode their contents. Capturing packets involves copying a series of packets from the network into memory and holding the copy so that it can be analyzed.

You could, for example, capture a series of packets and decode their contents to figure out where each packet came from, where it was going, which protocol sent it, which protocol should receive it, and so on. For example, you can find out:

• The nature of the traffic on your network
  
• Which protocol is used most often
  
• If users are accessing unauthorized sites
  
• If a particular network card is jabbering (sending out packets when there is no data to send)
  

Two common examples of protocol analyzers are Sniffer, a Network General product, and Novell’s LANalyzer.

Performance-Monitoring Tools

In addition to protocol analyzers, many network operating systems include tools for monitoring network performance and can display statistics such as the number of packets sent and received, server processor utilization, the amount of data going in and out of the server, and so on. NetWare comes with the MONITOR.NLM utility, and Windows NT comes with Performance Monitor. Both monitor performance statistics. You can use these utilities to determine the source of the bottleneck when users complain that the network is slow.

Note To start the MONITOR.NLM utility in NetWare, simply type LOAD MONITOR at the console prompt. To start the Performance Monitor program in Windows NT, you must first be logged in as Administrator (or a member of the Server Operators group). Once you are logged in, choose Start - Programs - Administrative Tools - Performance Monitor.

Now that we have covered the basics of network troubleshooting, we should go over a few troubleshooting tips. These tips will give you more “ammo” while you’re hunting for network problems and using the various steps of the troubleshooting model discussed earlier.

Don’t Overlook the Small Stuff

If you’ll remember, the first thing we discussed in this chapter was small stuff. Often a problem is caused by something simple, such as a power switch in the wrong position, a card or port not functioning (as indicated by a link light that’s not lit), or simply operator error. Even the most experienced administrator has forgotten to turn on the power, left a cable unplugged, or mistyped a username and password.

Finally, make sure that users get training for the systems they use. That may seem like an extra bother, but an hour or two of training goes a long way toward preventing problems. The number of incidents of EEOC will decline with a little user training.


Prioritize Your Problems

It is unlikely that as a network administrator or technician, you will receive problem calls one at a time. Typically, when you receive one call, you already have three people waiting for service. For this reason, you must learn to prioritize.

You start this process by asking some basic questions of the person reporting the problem so that you can determine its severity. If the current problem is minor and you have two more serious problems already facing you, your priorities are obvious.

You establish priorities to ensure that you spend your time wisely. The order in which you attempt to solve your networking problems, from highest priority to lowest, might look something like this:

• Total network failure (affects everyone)
  
• Partial network failure (affects small groups of users)
  
• Small network failure (affects a small, single group of users)
  
• Total workstation failure (single user can’t work at all)
  
• Partial workstation failure (single user can’t do most tasks)
  
• Minor issue (single user has problems that crop up now and again)
  

Mitigating circumstances can, of course, change the order of this list. For example, if the president of the company can’t retrieve her e-mail, you’d take the express elevator to her office as soon as you hang up from the call. Also, a minor, persistent problem might move up the ladder.

Remember also that some simple problems may take more effort than larger problems. You may be able to bring up a crashed server in a matter of minutes, but a user who doesn’t know how to make columns line up in Microsoft Word may take up to an hour or longer to train. The latter of these problems might get relegated toward the bottom of the list because of the time involved. It is more efficient to solve problems for a larger group of people than to fix this one user’s problem immediately.

Some network administrators list all network service requests on a chalkboard or a whiteboard. They then prioritize them based on the previously discussed criteria. Some larger companies have written support-call tracking software whose only function is to track and prioritize all network and computer problems. Use whatever method makes you comfortable, but prioritize your calls.

Often, network problems can be traced to software configuration (as with our DNS configuration example earlier in this chapter). When you are checking for software problems, don’t forget to check configuration, including the following:

• DNS configuration
  
• WINS configuration
  
• HOSTS file
  
• AUTOEXEC.BAT (DOS and Windows)
  
• CONFIG.SYS (DOS and Windows)
  
• STARTUP.NCF, AUTOEXEC.NCF, and server parameter settings (NetWare)
  
• The Registry (Windows 95/98 and NT)
  

Software configuration settings love to hide in places like these and can be notoriously hard to find (especially in the Registry).

Additionally, in text configuration files, look for lines that have been commented out (either intentionally or accidentally). A command such as REM or REMARK or the asterisk or semicolon characters indicate comment lines in a file.

Tip The HOSTS file uses a # (pound sign) to indicate a comment line, as does NetWare’s NCF files.

Don’t Overlook Physical Conditions

You want to make sure that from a network design standpoint, the physical environment for a server is optimized for placement, temperature, and humidity. When troubleshooting an obscure network problem, don’t forget to check the physical conditions under which the network device is operating. Check for problems such as the following:

• Excessive heat
• Excessive humidity (condensation)
• Low humidity (leads to ESD problems)
• EMI/RFI problems
• ESD problems
• Power problems
• Unplugged cables
  

Don’t Overlook Cable Problems

Cables, generally speaking, work fine once they are installed properly. Rarely is the cabling system the problem, unless someone has made some change to it. If you suspect that the cabling system is the problem, try replacing the patch cables at the workstation and hub first. These are easiest to get to (and replace). If that solves the problem, you know the problem was related to the patch cable. It was either faulty or the wrong type.

If the patch cable isn’t the problem, use a cable tester (not a tone generator and locator) to find the source of the problem. Wires that are moved can be prone to breaking or shorting. A short can happen when the wire conductor comes in contact with another conductive surface, changing the path of the electrical signal. The signal will go someplace else instead of to the intended recipient. You can use cable testers to test for many types of problems, including:

• Broken cables
• Incorrect connections
• Interference levels
• Total cable length (for length restrictions)
• Cable shorts
• Connector problems

Note As a matter of fact, cable testers are so sophisticated that they can even indicate the exact location of a cable break, accurate to within 6 inches or better.

Check for Viruses

Many troubleshooters overlook virus scanning because they assume that the network virus-checking software should have picked up any viruses. We’re reminded by the network virus-scanning software of the bio-filters in the transporter on Star Trek: The Next Generation. They work great as long as the computer has the latest information on what the virus is and how to eliminate it. On many occasions, though, the ship’s doctor or engineer had to reprogram the bio-filters to recognize some new virus that the crew of the Enterprise had come across.

The same thing happens with network virus-scanning software; to be effective, it must be kept up-to-date. Updates are made available almost daily. As we Guide 9 - “Fault Tolerance and Disaster Recovery,” you must run the virus definition update utility to keep the virus definition file current.

If you are having strange, unusual, irreproducible problems with a workstation, try scanning it with an up-to-date virus scan utility. You’d be surprised how many times people have spent hours and hours troubleshooting a strange problem, only to run a virus scan utility, find and clean one or more viruses, and have the problem disappear.

Summary

In this guide , you learned about the proper methods of troubleshooting-network problems. In the first section, you learned the proper method to start to fix any network problem by eliminating what the problem is not. You learned how to narrow the problem down to its essentials and therefore further define it.

Next, you learned a systematic approach to troubleshooting, using an eight-step troubleshooting model to troubleshoot almost any problems you may encounter on your network. After that, you learned about several resources that you can use to help you during the troubleshooting process. You learned about the websites and other support tools available for most vendors’ products.

Finally, you learned a few troubleshooting tips that will help make the troubleshooting process go more smoothly. As you venture out into the “real world,” keep these tips in mind, as they will help make you an expert troubleshooter.

Gud One
Thanks

thank you boss..

Hi This is really good. Am i missing something in Networking Guide Part - 4&5