Basic troubleshooting
Basic troubleshooting
We've heard from a lot of people who tell us not to forget the basics. Many of us are so busy that we would just jump in and start troubleshooting, forgetting the basic steps.For example, from Hong Kong we received this tip:Record the fault symptoms, method of discovery and solutions for each fault to a file (for example, *.xls). This file can then be your fault troubleshooting manual and quick reference guidebook for future problem solving efforts.Always build and troubleshoot your network from the lower levels up. Don't try to troubleshoot network layer protocols if there is a potential cable or ATM specification or SONET mismatch. Most people associate connectivity with IP, and there is a lot more to it than just connectivity. --Submitted by Gaetan Legault, a network engineer at AlcatelWe also received a tip regarding network slowness:Recently, we had complaints from users of "network slowness" on our local LAN. We went through the basic troubleshooting steps you've listed with no "results."I decided to go LOOK at the hubs and switches in the data center during an occurrence of the problem, and SAW 100MB switch ports (AdvanceStack switches of course) totally busied out. I was able to trace back through the switch and hub (AdvanceStack of course) configurations and status information to determine that this was caused by a new version of a client/server application that was TOTALLY hogging the bandwidth between the client and the server. We were then easily able to isolate the client(s) and server on unique switch ports, and relieve the congestion on the rest of the network.Moral of the story: Look at the physical indicators on the network, don't just sit at your desk and try to "sniff" it out. Sometimes your eyes and brain are better than all the phone calls in the world. (Obviously, a product like Keysight advisor could have further shortened the process.) --Submitted by Kevin Chaney, Manager of Technical Services at Interstate BrandsRestart a device after a change:In general, it is good advice to restart a device after a change has been made to it. Otherwise, it is possible that a change might cause a problem that pops up only after another user restarts the device later. To avoid this sort of delayed unpleasant surprise, make sure you restart and check the device immediately to make sure that everything works as planned. --Submitted by Othmar Kyas, Marketing Manager for the Network Systems Test Division of Keysight TechnologiesPoor Network PerformanceDoes your switch-connected workstation, server, etc., exhibit poor network performance or fail to provide any connectivity at all? If so, you may want to reconfigure the device and/or switch port by changing from auto-negotiating the speed and duplex setting to hard-coding a specific speed and duplex setting. We occasionally encounter NICs that don't want to play well with our switches. --Submitted by Clint Stevens, a Network Design Analyst with the Florida Department of Transportation OhmmeterBefore connecting the Terminator to the T Connector in a 10Base2 Coax Thinnet, use an Ohmmeter to make sure that the resistor in the Terminator does have a 50 Ohm resistance. --Submitted by Farrukh Rashid, a student at GIK Institute in PunjabShared ResourcesIf users are unable to connect to your shared resources and you have determined that connectivity between computers is not a problem, it is possible that the users have been denied access because of the permissions set for the shared resource or for the files themselves if located on an NTFS partition. --Submitted by a Manager dealing with PC's