CHAPTER 11
Network Troubleshooting
This chapter covers the following official Network+ objectives:
Explain the network troubleshooting methodology.
Given a scenario, use the appropriate tool.
Given a scenario, troubleshoot common network service issues.
This chapter covers CompTIA Network+ objectives 5.1, 5.2, and 5.5. For more information on the official Network+ exam topics, see the “About the Network+ Exam” section in the Introduction.
Many duties and responsibilities fall under the umbrella of network administration. Of these, one of the most practiced is that of troubleshooting. No matter how well a network is designed and how many preventive maintenance schedules are in place, troubleshooting is always necessary. Because of this, network administrators must develop those troubleshooting skills.
This chapter focuses on all areas of troubleshooting, including troubleshooting best practices and some of the tools and utilities you can use to assist in the troubleshooting process.
Troubleshooting Steps and Procedures
Explain the network troubleshooting methodology.
CramSaver
If you can correctly answer these questions before going through this section, save time by skimming the Exam Alerts in this section and then completing the Cram Quiz at the end of the section.
1. What are the key sources from which you can gain information about a computer problem?
2. What is the final step in the network troubleshooting methodology CompTIA expects test takers to follow?
Answers
1. It is important to get as much information as possible about the problem. You can glean information from three key sources: the computer (in the form of logs and error messages), the computer user experiencing the problem, and your own observation.
2. Document the findings, the actions, and the outcomes.
Regardless of the problem, effective network troubleshooting follows some specific steps. These steps provide a framework in which to perform the troubleshooting process. When you follow them, they can reduce the time it takes to isolate and fix a problem. The following sections discuss the common troubleshooting steps and procedures as identified by the CompTIA Network+ objectives:
1. Identify the problem.
Gather information.
Duplicate the problem, if possible.
Question users.
Identify symptoms.
Determine if anything has changed.
Approach multiple problems individually.
2. Establish a theory of probable cause.
Question the obvious.
Consider multiple approaches:
Top-to-bottom/bottom-to-top OSI model.
Divide and conquer.
3. Test the theory to determine the cause:
After the theory is confirmed, determine the next steps to resolve the problem.
If the theory is not confirmed, reestablish a new theory or escalate.
4. Establish a plan of action to resolve the problem and identify potential effects.
1. Implement the solution or escalate as necessary.
2. Verify full system functionality and, if applicable, implement preventive measures.
3. Document findings, actions, and outcomes.
ExamAlert
You should expect questions asking you to identify the troubleshooting steps in exact order.
Identify the Problem
The first step in the troubleshooting process is to establish exactly what the problem is. This stage of the troubleshooting process is all about information gathering, identifying symptoms, questioning users, and determining if anything has changed. To get this information, you need knowledge of the operating system used, good communication skills, and a little patience. You need to get as much information as possible about the problem. You can glean information from three key sources: the computer (in the form of logs and error messages), the computer user experiencing the problem, and your own observation.
After you have listed the symptoms, you can begin to identify some of the potential causes of those symptoms.
ExamAlert
You do not need to know where error messages are stored on an operating system. You need to know only that the troubleshooting process requires you to read system-generated log errors.
Identify Symptoms
Some computer problems are isolated to a single user in a single location; others affect several thousand users spanning multiple locations. Establishing the affected area is an important part of the troubleshooting process, and it often dictates the strategies you use to resolve the problem.
ExamAlert
You might be provided with either a description of a scenario or a description augmented by a network diagram. In either case, you should carefully read the description of the problem, step by step. In most cases, the correct answer is fairly logical, and the wrong answers can be easily identified.
Problems that affect many users are often connectivity issues that disable access for many users. Such problems often can be isolated to wiring closets, network devices, and server rooms. The troubleshooting process for problems that are isolated to a single user often begins and ends at that user’s workstation. The trail might indeed lead you to the wiring closet or server, but that is probably not where the troubleshooting process began. Understanding who is affected by a problem can give you the first clues about where the problem exists. For example, a change in Dynamic Host Configuration Protocol (DHCP) scope by a new administrator might affect several users, whereas a user playing with the TCP/IP settings of a single computer can affect only that person.
Determine Whether Anything Has Changed
Whether there is a problem with a workstation’s access to a database or an entire network, they were working at some point. Although many people claim that their computer “just stopped working,” that is unlikely. Far more likely is that changes to the system or network have caused the problem. Look for newly installed applications, applied patches or updates, new hardware, a physical move of the computer, or a new username and password. Establishing any recent changes to a system can often lead you in the right direction to isolate and troubleshoot a problem.
ExamAlert
When approaching a problem, start by questioning the obvious. If that fails, consider ways to tackle the issue from multiple approaches. Consider using a top-to-bottom or bottom-to-top model approach (such as working through the OSI model stack) and assigning any co-workers you have to divide and conquer the problem.
A single problem on a network can have many causes, but with appropriate information gathering, you can eliminate many of them. When you look for a probable cause, it is often best to look at the easiest solution first and then work from there. Even in the most complex of network designs, the easiest solution is often the right one. For instance, if a single user cannot log on to a network, it is best to confirm network settings before replacing the network interface card (NIC). Remember, though, that at this point you need to determine only the most probable cause, and your first guess might be incorrect. It might take a few tries to determine the correct cause of the problem.
ExamAlert
Avoid discounting a possible answer because it seems too easy. Many of the troubleshooting questions are based on possible real-world scenarios, some of which do have easy or obvious solutions.
Test the Theory to Determine Cause
After questioning the obvious, you need to establish a theory. After you formulate a theory, you should attempt to confirm it. An example might be a theory that users can no longer print because they downloaded new software that changed the print drivers, or that they can no longer run the legacy application they used to run after the latest service pack was installed.
If the theory can be confirmed, you must plot a course of action—a list of the next steps to take to resolve the problem. If the theory cannot be confirmed (in the example given, no new software was downloaded and no service pack was applied), you must establish a new theory or consider escalating the problem.
Establish a Plan of Action
After identifying a cause, but before implementing a solution, you should establish a plan for the solution. This is particularly a concern for server systems in which taking the server offline is a difficult and undesirable prospect. After identifying the cause of a problem on the server, it is absolutely necessary to plan for the solution. The plan must include the details of when the server or network should be taken offline and for how long, what support services are in place, and who will be involved in correcting the problem.
Planning is an important part of the whole troubleshooting process and can involve formal or informal written procedures. Those who do not have experience troubleshooting servers might wonder about all the formality, but this attention to detail ensures the least amount of network or server downtime and the maximum data availability.
Tip
If part of an action plan includes shutting down a server or another similar event that can impact many users, it is a best practice to let users know when they will be shut out of the network. This allows them to properly shut off any affected applications and not be frustrated by not being able to access the network or other services.
With the plan in place, you should be ready to implement a solution—that is, apply the patch, replace the hardware, plug in a cable, or implement some other solution. In an ideal world, your first solution would fix the problem; however, unfortunately this is not always the case. If your first solution does not fix the problem, you need to retrace your steps and start again.
You must attempt only one solution at a time. Trying several solutions at once can make it unclear which one corrected the problem.
Implement the Solution or Escalate
After the corrective change has been made to the server, network, or workstation, you must test the results—never assume. This is when you find out if you were right and the remedy you applied worked. Don’t forget that first impressions can deceive, and a fix that seems to work on first inspection might not have corrected the problem.
The testing process is not always as easy as it sounds. If you are testing a connectivity problem, it is not difficult to ascertain whether your solution was successful. However, changes made to an application or to databases you are unfamiliar with are much more difficult to test. It might be necessary to have people who are familiar with the database or application run the tests with you in attendance.
Determine Whether Escalation Is Necessary
Sometimes the problems you encounter fall outside the scope of your knowledge. Few organizations expect their administrators to know everything, but organizations do expect administrators to fix any problem. To do this, you often need additional help.
Note
System administration is often as much about knowing whom and what to refer to in order to get information about a problem as it is about actually fixing the problem.
Technical escalation procedures do not follow a specific set of rules; rather, the procedures to follow vary from organization to organization and situation to situation. Your organization might have an informal arrangement or a formal one requiring documented steps and procedures to be carried out. Whatever the approach, general practices should be followed for appropriate escalation.
Unless otherwise specified by the organization, the general rule is to start with the closest help and work out from there. If you work in an organization that has an IT team, talk with others on your team; every IT professional has had different experiences, and someone else may know about the issue at hand. If you are still struggling with the problem, it is common practice to notify a supervisor or head administrator, especially if the problem is a threat to the server’s data or can bring down the server.
Suppose that, as a server administrator, you notice a problem with a hard disk in a RAID 1 array on a Linux server. You know how to replace drives in a failed RAID 1 configuration, but you have no experience working with software RAID on a Linux server. This situation would most certainly require an escalation of the problem. The job of server administrator in this situation is to notice the failed RAID 1 drive and to recruit the appropriate help to repair the RAID failure within Linux.
Note
When you are confronted with a problem, it is yours until it has been solved or passed to someone else. Of course, the passing on of an issue requires that both parties know that it has been passed on.
Verify Full System Functionality
At times, you might apply a fix that corrects one problem but creates another. Many such circumstances are hard to predict—but not always. For instance, you might add a new network application, but the application requires more bandwidth than your current network infrastructure can support. The result would be that overall network performance would be compromised.
Everything done to a network can have a ripple effect and negatively affect another area of the network. Actions such as adding clients, replacing hubs or switches, and adding applications can all have unforeseen results. It is difficult to always know how the changes you make to a network might affect the network’s functioning. The safest thing to do is assume that the changes you make will affect the network in some way and realize that you have to figure out how. This is when you might need to think outside the box and try to predict possible outcomes.
It is imperative that you verify full system functionality before you are satisfied with the solution. After you obtain that level of satisfaction, you should look at the problem and ascertain if any preventive measures should be implemented to keep the same problem from occurring again.
Document the Findings, Actions, and Outcomes
Although it is often neglected in the troubleshooting process, documentation is as important as any of the other troubleshooting procedures. Documenting a solution involves keeping a record of all the steps taken during the fix—not necessarily just the solution.
For the documentation to be of use to other network administrators in the future, it must include several key pieces of information. When documenting a procedure, you should include the following information:
When: When was the solution implemented? You must know the date, because if problems occur
after your changes, knowing the date of your fix makes it easier to determine whether
your changes caused the problems.
Why: Although it is obvious when a problem is being fixed why it is being done, a few
weeks later, it might become less clear why that solution was needed. Documenting
why the fix was made is important because if the same problem appears on another system,
you can use this information to reduce the time needed to find the solution.
What: The successful fix should be detailed, along with information about any changes to
the configuration of the system or network that were made to achieve the fix. Additional
information should include version numbers for software patches or firmware, as appropriate.
Results: Many administrators choose to include information on both successes and failures.
The documentation of failures might prevent you from going down the same road twice,
and the documentation of successful solutions can reduce the time it takes to get
a system or network up and running.
Who: It might be that information is left out of the documentation or someone simply wants
to ask a few questions about a solution. In both cases, if the name of the person
who made a fix is in the documentation, he or she can easily be tracked down. Of course,
this is more of a concern in environments that have a large IT staff or if system
repairs are performed by contractors instead of company employees.
Cram Quiz
1. A user reports that she can no longer access a legacy database. What should be one of the first questions you ask?
A. What has changed since the last time you accessed that database?
B. How many help calls have you placed in the past few months?
C. Who originally installed or created that database?
D. How long have you worked here?
2. You’ve spent 2 hours trying to fix a problem and then realize that it falls outside of your area of expertise and ability to fix. What should you do in most organizations?
A. Let the user immediately know that she needs to call someone else; then exit the
scene so another person can help.
B. Formulate a workaround; then document the problem and bring it up at the next meeting.
C. Escalate the issue with a supervisor or manager.
D. Continue working on the problem, trying as many solutions as you can find, until
you solve the problem.
3. You get numerous calls from users who cannot access an application. Upon investigation, you find that the application crashed. You restart the application, and it appears to run okay. What is the next step in the troubleshooting process?
A. Email the users to let them know that they can use the application again.
B. Test the application to ensure that it operates correctly.
C. Document the problem and the solution.
D. Reload the application executables from the CD, and restart it.
4. A user tells you that she is having a problem accessing her email. What is the first step in the troubleshooting process?
A. Document the problem.
B. Make sure that the user’s email address is valid.
C. Discuss the problem with the user.
D. Visit the user’s desk to reload the email client software.
5. You have successfully fixed a problem with a server and have tested the application and let the users back on to the system. What is the next step in the troubleshooting process?
A. Document the problem.
B. Restart the server.
C. Document the problem and the solution.
D. Clear the error logs of any reference to the problem.
Cram Quiz Answers
1. A. Establishing any recent changes to a system can often lead you in the right direction to isolate and troubleshoot a problem.
2. C. When a problem is outside of your ability to fix, you must escalate the issue. Unless otherwise specified by the organization, the general rule is to start with the closest help and work out from there. None of the other options are acceptable choices.
3. B. After you fix a problem, you should test it fully to ensure that the network operates correctly before you allow users to log back on. The steps described in answers A and C are valid but only after the application has been tested. Answer D is incorrect because you would reload the executable only as part of a systematic troubleshooting process. Because the application loads, it is unlikely that the executable has become corrupted.
4. C. Not enough information is provided for you to come up with a solution. In this case, the next troubleshooting step would be to talk to the user and gather more information about exactly what the problem is. All the other answers are valid troubleshooting steps but only after the information gathering has been completed.
5. C. After you have fixed a problem, tested the fix, and let users back on to the system, you should create detailed documentation that describes the problem and the solution. Answer A is incorrect because you must document both the problem and the solution. You do not need to restart the server, so Answer B is incorrect. Answer D would be performed only after the system’s documentation has been created.
Hardware and Software Troubleshooting Tools
Given a scenario, use the appropriate tool.
CramSaver
If you can correctly answer these questions before going through this section, save time by skimming the Exam Alerts in this section and then completing the Cram Quiz at the end of the section.
1. What tools are used to attach twisted-pair network cable to connectors within a patch panel?
2. What are the two parts of a toner probe?
Answers
1. Punchdown tools are used to attach twisted-pair network cable to connectors within a patch panel.
2. A toner probe has two parts: the tone generator, or toner, and the tone locator, or probe.
ExamAlert
Remember that this objective begins with “Given a scenario.” That means that you may receive a drag and drop, matching, or “live OS” scenario where you have to click through to complete a specific objective-based task.
A large part of network administration involves having the right tools for the job and knowing when and how to use them. Selecting the correct tool for a networking job sounds like an easy task, but network administrators can choose from a mind-boggling number of tools and utilities.
Given the diverse range of tools and utilities available, it is unlikely that you will encounter all the tools available—or even all those discussed in this chapter. For the Network+ exam, you are required to have general knowledge of the tools available and what they are designed to do.
Until networks become completely wireless, network administrators can expect to spend some of their time using a variety of media-related troubleshooting and installation tools. Some of these tools (such as the tone generator and locator) may be used to troubleshoot media connections, and others (such as wire crimpers and punchdown tools) are used to create network cables and connections.
The Basic Tools
Although many costly, specialized networking tools and devices are available to network administrators, the most widely used tools cost only a few dollars: the standard screwdrivers we use on almost a daily basis. As a network administrator, you can expect with amazing regularity to take the case off a system to replace a network interface card (NIC) or perhaps remove the cover from a hub or switch to replace a fan. Advanced cable testers and other specialized tools will not help you when a screwdriver is needed.
Wire Crimpers, Strippers, and Snips
Wire crimpers are tools you might regularly use. Like many things, making your own cables can be fun at first, but the novelty soon wears off. Basically, a wire crimper is a tool that you use to attach media connectors to the ends of cables. For instance, you use one type of wire crimper to attach RJ-45 connectors on unshielded twisted-pair (UTP) cable. You use a different type of wire crimper to attach British Naval Connectors/Bayonet Neill-Concelman (BNCs) to coaxial cabling.
Tip
When making cables, always order more connectors than you need; a few mishaps will probably occur along the way.
In a sense, you can think of a wire crimper as a pair of special pliers. You insert the cable and connector separately into the crimper, making sure that the wires in the cable align with the appropriate connectors. Then, by squeezing the crimper’s handles, you force metal connectors through the cable’s wires, making the connection between the wire and the connector.
When you crimp your own cables, you need to be sure to test them before putting them on the network. It takes only a momentary lapse to make a mistake when creating a cable, and you can waste time later trying to isolate a problem in a faulty cable.
Two other commonly used wiring tools are strippers and snips. Wire strippers come in a variety of shapes and sizes. Some are specifically designed to strip the outer sheathing from coaxial cable, and others are designed to work best with UTP cable. All strippers are designed to cleanly remove the sheathing from wire to make sure a clean contact can be made.
Many administrators do not have specialized wire strippers unless they do a lot of work with copper-based wiring. However, standard wire strippers are good things to have on hand.
Wire snips are tools designed to cleanly cut the cable. Sometimes network administrators buy cable in bulk and use wire snips to cut the cable into desired lengths. The wire strippers are then used to prepare the cable for the attachment of the connectors.
Note
Punchdown tools are used to attach twisted-pair network cable to connectors within a patch panel. Specifically, they connect twisted-pair wires to the insulation displacement connector (IDC).
Tone Generator and Probes
A toner probe is a device that can save a network installer many hours of frustration. This device has two parts: the tone generator, or toner, and the tone locator, or probe. The toner sends the tone, and at the other end of the cable, the probe receives the toner’s signal. This tool makes it easier to find the beginning and end of a cable. You might hear the tone generator and tone locator referred to as the fox and hound.
As you might expect, the purpose of the tone probe is to generate a signal that is transmitted on the wire you are attempting to locate. At the other end, you press the probe against individual wires. When it makes contact with the wire that has the signal on it, the locator emits an audible signal or tone.
The tone locator probe is a useful device, but it does have some drawbacks. First, it often takes two people to operate one at each end of the cable. Of course, one person could just keep running back and forth, but if the cable is run over great distances, this can be a problem. Second, using the toner probe is time consuming because it must be attached to each cable independently.
Note
Many problems that can be discovered with a tone generator are easy to prevent by taking the time to properly label cables. If the cables are labeled at both ends, you will not need to use such a tool to locate them.
Note
Toner probes are specifically used to locate cables hidden in floors, ceilings, or walls and to track cables from the patch panels to their destinations.
Loopback Adapter
A number of items fall under the loopback umbrella, and all of them serve the same purpose—they allow you to test a device/configuration/connectivity component using a dummy. The most popular loopback is the address used with ping (discussed later in this chapter), but Windows also includes a loopback adapter, which is a dummy network card (no hardware) used for testing a virtual network environment.
Various loopback adapters—actual hardware—can be purchased and used to test Ethernet jacks, fiber jacks, and so on.
Protocol Analyzer
Protocol analyzers are used to do just that—analyze network protocols such as TCP, UDP, HTTP, and FTP. Protocol analyzers can be hardware or software based. In use, protocol analyzers help diagnose computer networking problems, alert you to unused protocols, identify unwanted or malicious network traffic, and help isolate network traffic-related problems.
Like packet sniffers, protocol analyzers capture the communication stream between systems. But unlike the sniffer, the protocol analyzer captures more than network traffic; it reads and decodes the traffic. Decoding allows the administrator to view the network communication in English. From this, administrators can get a better idea of the traffic that is flowing on the network. As soon as unwanted or damaged traffic is spotted, analyzers make it easy to isolate and repair. For example, if there is a problem with specific TCP/IP communication, such as a broadcast storm, the analyzer can find the source of the TCP/IP problem and isolate the system causing the storm. Protocol analyzers also provide many real-time trend statistics that help you justify to management the purchase of new hardware.
You can use protocol analyzers for two key reasons:
Identify protocol patterns: By creating a historical baseline of analysis, administrators can spot trends in
protocol errors. That way, when a protocol error occurs, it can be researched in the
documentation to see if that error has occurred before and what was done to fix it.
Decoding information: Capturing and decoding network traffic allows administrators to see what exactly
is going on with the network at a protocol level. This helps find protocol errors
as well as potential intruders.
Caution
Protocol analyzers enable administrators to examine the bandwidth that a particular protocol is using.
Media/Cable Testers
A media tester, also called a cable tester, defines a range of tools designed to test whether a cable properly works. Any tool that facilitates the testing of a cable can be deemed a cable tester. However, a specific tool called a media tester enables administrators to test a segment of cable, looking for shorts, improperly attached connectors, or other cable faults. All media testers tell you whether the cable works correctly and where the problem in the cable might be.
Generically, the phrase line tester can be used for any device that tests a media line. Although products are available that are Ethernet line testers, fiber line testers, and so on, most often a “line tester” is used to check telephone wiring and usually includes RJ-11 plugs as well as alligator clips.
A cable certifier is a type of tester that enables you to certify cabling by testing it for speed and performance to see that the implementation will live up to the ratings. Most stress and test the system based on noise and error testing. You need to know that the gigabit cable you think you have run is actually providing that speed to the network.
TDR and OTDR
A time domain reflectometer (TDR) is a device used to send a signal through a particular medium to check the cable’s continuity. Good-quality TDRs can locate many types of cabling faults, such as a severed sheath, damaged conductors, faulty crimps, shorts, loose connectors, and more. Although network administrators will not need to use a tool such as this every day, it could significantly help in the troubleshooting process. TDRs help ensure that data sent across the network is not interrupted by poor cabling that may cause faults in data delivery.
Note
TDRs work at the physical layer of the OSI model, sending a signal through a length of cable, looking for cable faults.
Because the majority of network cabling is copper based, most tools designed to test cabling are designed for copper-based cabling. However, when you test fiber-optic cable, you need an optical tester.
An optical cable tester performs the same basic function as a wire media tester, but on optical media. The most common problem with an optical cable is a break in the cable that prevents the signal from reaching the other end. Due to the extended distances that can be covered with fiber-optic cables, degradation is rarely an issue in a fiber-optic LAN environment.
Ascertaining whether a signal reaches the other end of a fiber-optic cable is relatively easy, but when you determine that there is a break, the problem becomes locating the break. That’s when you need a tool called an optical time domain reflectometer (OTDR). By using an OTDR, you can locate how far along in the cable the break occurs. The connection on the other end of the cable might be the source of the problem, or perhaps there is a break halfway along the cable. Either way, an OTDR can pinpoint the problem.
Unless you work extensively with fiber-optic cable, you are unlikely to have an OTDR or even a fiber-optic cable tester in your toolbox. Specialized cabling contractors will have them, though, so knowing they exist is important.
You can use a light meter to certify and troubleshoot fiber. A light source is placed on one end and the light meter is used at the opposite end to measure loss.
Multimeter
One of the simplest cable-testing devices is a multimeter. By using the continuity setting, you can test for shorts in a length of coaxial cable. Or if you know the correct cable pinouts and have needlepoint probes, you can test twisted-pair cable.
A basic multimeter combines several electrical meters into a single unit that can measure voltage, current, and resistance. Advanced models can also measure temperature.
A multimeter has a display, terminals, probes, and a dial to select various measurement ranges. A digital multimeter has a numeric digital display, and an analog has a dial display. Inside a multimeter, the terminals are connected to different resistors, depending on the range selected.
Network multimeters can do much more than test electrical current:
Ping specific network devices: A multimeter can ping and test response times of key networking equipment, such as
routers, DNS servers, DHCP servers, and more.
Verify network cabling: You can use a network multimeter to isolate cable shorts, split pairs, and other
faults.
Locate and identify cable: Quality network multimeters enable administrators to locate cables at patch panels
and wall jacks using digital tones.
Documentation ability: Multimeter results can be downloaded to a PC for inspection. Most network multimeters
provide a means such as USB ports to link to a PC.
Spectrum Analyzer
A spectrum analyzer measures the magnitude of an input signal versus frequency within the full frequency range of the instrument and can be used for a wide range of signals. Today, they are commonly used with Wi-Fi to reveal Wi-Fi hotspots and detect wireless network access with LED visual feedback. Such devices can be configured to scan specific frequencies. When working with 802.11b/g/n/ac networks, you will most certainly require scanning for 2.4 GHz or 5 GHz RF signals.
Such devices can be used in the troubleshooting process to see where and how powerful RF signals are. Given the increase in wireless technologies, RF detectors are sure to continue to increase in popularity.
Packet Sniffers
Packet sniffers, also referred to as packet/network analyzers, are commonly used on networks. They are either a hardware device or software that basically eavesdrops on transmissions traveling throughout the network and can be helpful in performing packet flow monitoring. The packet sniffer quietly captures data and saves it to be reviewed later. Packet sniffers can also be used on the Internet to capture data traveling between computers. Internet packets often have long distances to travel, going through various servers, routers, and gateways. Anywhere along this path, packet sniffers can quietly sit and collect data. Given the capability of packet sniffers to sit and silently collect data packets, it is easy to see how they could be exploited.
Note
As the name implies, a packet sniffer is a program that targets packets of data transmitted over the Internet and looks for data within them. One of the dangers that disgruntled employees pose is that they are already allowed on your network and thus they have the ability to use a packet sniffer on the network. Through packet sniffing, they can intercept data far beyond what they would or should have access to.
You should use two key defenses against packet sniffers to protect your network:
Use a switched network, which most today are. In a switched network, data is sent
from one computer system and is directed from the switch only to intended targeted
destinations. In an older network using traditional hubs, the hub does not switch
the traffic to isolated users but to all users connected to the hub’s ports. This
shotgun approach to network transmission makes it easier to place a packet sniffer
on the network to obtain data.
Ensure that all sensitive data is encrypted as it travels. Ordinarily, encryption
is used when data is sent over a public network such as the Internet, but it may also
be necessary to encrypt sensitive data on a LAN. Encryption can be implemented in
a number of ways. For example, connections to web servers can be protected using the
Secure Sockets Layer (SSL) protocol and HTTPS. Communications to mail servers can
also be encrypted using SSL. For public networks, the IPsec protocol can provide end-to-end
encryption services.
Port Scanner
Port scanners are software-based security utilities designed to search a network host for open ports on a TCP/IP-based network. As a refresher, in a TCP/IP-based network, a system can be accessed through one of 65,535 available port numbers. Each network service is associated with a particular port.
Note
Chapter 3, “Addressing, Routing, and Switching,” includes a list of some of the most common TCP/IP suite protocols and their port assignments.
Many of the thousands of ports are closed by default; however, many others, depending on the OS, are open by default. These are the ports that can cause trouble. Like packet sniffers, port scanners can be used by both administrators and hackers. Hackers use port scanners to try to find an open port that they can use to access a system. Port scanners are easily obtained on the Internet either for free or for a modest cost. After it is installed, the scanner probes a computer system running TCP/IP, looking for a UDP or TCP port that is open and listening.
When a port scanner is used, several port states may be reported:
Open/listening: The host sent a reply indicating that a service is listening on the port. There was
a response from the port.
Closed or denied or not listening: No process is listening on that port. Access to this port will likely be denied.
Filtered or blocked: There was no reply from the host, meaning that the port is not listening or the port
is secured and filtered.
Note
Sometimes, an Internet service provider (ISP) takes the initiative and blocks specific traffic entering its network before the traffic reaches the ISP’s customers, or after the traffic leaves the customers and before it exits the network. This is done to protect customers from well-known attacks.
Because others can potentially review the status of our ports, it is critical that
administrators know which ports are open and potentially vulnerable. As mentioned,
many tools and utilities are available for this. The quickest way to get an overview
of the ports used by the system and their status is to issue the netstat -a command from the command line. The following is a sample of the output from the netstat -a command and active connections for a computer system:
Proto Local Address Foreign Address State TCP 0.0.0.0:135 mike-PC:0 LISTENING TCP 0.0.0.0:10114 mike-PC:0 LISTENING TCP 0.0.0.0:10115 mike-PC:0 LISTENING TCP 0.0.0.0:20523 mike-PC:0 LISTENING TCP 0.0.0.0:20943 mike-PC:0 LISTENING TCP 0.0.0.0:49152 mike-PC:0 LISTENING TCP 0.0.0.0:49153 mike-PC:0 LISTENING TCP 0.0.0.0:49154 mike-PC:0 LISTENING TCP 0.0.0.0:49155 mike-PC:0 LISTENING TCP 0.0.0.0:49156 mike-PC:0 LISTENING TCP 0.0.0.0:49157 mike-PC:0 LISTENING TCP 127.0.0.1:5354 mike-PC:0 LISTENING TCP 127.0.0.1:27015 mike-PC:0 LISTENING TCP 127.0.0.1:27015 mike-PC:49187 ESTABLISHED TCP 127.0.0.1:49187 mike-PC:27015 ESTABLISHED TCP 192.168.0.100:49190 206.18.166.15:http CLOSED TCP 192.168.1.66:139 mike-PC:0 LISTENING TCP [::]:135 mike-PC:0 LISTENING TCP [::]:445 mike-PC:0 LISTENING TCP [::]:2869 mike-PC:0 LISTENING TCP [::]:5357 mike-PC:0 LISTENING TCP [::]:10115 mike-PC:0 LISTENING TCP [::]:20523 mike-PC:0 LISTENING TCP [::]:49152 mike-PC:0 LISTENING TCP [::]:49153 mike-PC:0 LISTENING TCP [::]:49154 mike-PC:0 LISTENING TCP [::]:49155 mike-PC:0 LISTENING TCP [::]:49156 mike-PC:0 LISTENING TCP [::]:49157 mike-PC:0 LISTENING UDP 0.0.0.0:123 *:* UDP 0.0.0.0:500 *:* UDP 0.0.0.0:3702 *:* UDP 0.0.0.0:3702 *:*
As you can see from the output, the system has many listening ports. Not all these suggest that a risk exists, but the output does let you know that there are many listening ports and that they might be vulnerable. To test for actual vulnerability, you use a port scanner. For example, you can use a free online scanner to probe the system. Many free online scanning services are available. Although a network administrator might use these free online tools out of curiosity, for better security testing, you should use a quality scanner.
Caution
Administrators use the detailed information revealed from a port scan to ensure network security. Port scans identify closed, open, and listening ports. However, port scanners also can be used by people who want to compromise security by finding open and unguarded ports.
Wi-Fi Analyzer
As more networks go wireless, you need to pay special attention to issues associated with them. Wireless survey tools can be used to create heat maps showing the quantity and quality of wireless network coverage in areas. They can also allow you to see access points (including rogues) and security settings. These can be used to help you design and deploy an efficient network, and they can also be used (by you or others) to find weaknesses in your existing network (often marketed for this purpose as Wi-Fi analyzers).
Bandwidth Speed Tester and Looking Glasses
Two types of websites that can be invaluable when it comes to networking are speed test sites and looking-glass sites. Speed test sites, as the name implies, are bandwidth speed testers that report the speed of the connection that you have to them and can be helpful in determining if you are getting the rate your ISP has promised.
Looking-glass sites are servers running looking-glass (LG) software that allow you to see routing information. The servers act as a read-only
portal giving information about the backbone connection. Most of these servers will
show ping information, trace (tracert/traceroute) information, and Border Gateway Protocol (BGP) information.
ExamAlert
Think of a looking-glass site as a graphical interface to routing-related information.
Environmental Monitors
When discussing environmental monitoring, you often refer to the temperature of the server and network equipment rooms. In general, the heat tolerance range for computer equipment is surprisingly wide. For example, consider a typical server system, which can happily operate in a range between 50°F and 93°F (10° and 33.8° Celsius). That is a spread of 43°F (23.8°C), plenty of room in a normal heated environment. But the problem is that if you maintain a computer room at either the upper or lower end of these levels, the equipment will run, but for how long, no one knows.
Although no specific figures relate to the recommended temperature of server rooms, the accepted optimum is around 70° to 72°F (21° to 22°C). At this temperature, the equipment in the room should be able to operate, and those working in the room should not get too cold. Human beings generally require a higher temperature than computer equipment, which is why placing servers in an office space with staff is not ideal.
Many people assume that the biggest problem with servers and network equipment is overheating. To some extent, this is true; servers in particular generate a great deal of heat and can overheat to the point where components fail. But this is only one heat-related issue. A more significant, and more gradual, problem is that of temperature consistency.
Heat causes components to expand, and cooling causes them to contract. Even the slightest temperature shift causes the printed circuit boards and chips to shift, and if they shift too much or too often, the chance of their becoming separated from their connections is greatly increased. This is known as chip creep. Keeping the heat at a moderate and constant level reduces the expansion and contraction of the boards and increases the components’ reliability.
ExamAlert
Never wedge open a door to an environmentally controlled room, no matter how cold you get. An open door not only defeats the purpose of the controlled environment, it can damage air conditioning units.
Environmental monitors are part of how administrators keep their equipment rooms at the right temperature. The environmental monitor sits in the equipment room and constantly documents changes in room temperature and humidity. If radical changes in temperature are detected, an alert is sent to the administrator. This can sometimes occur if someone leaves a door to the server room open, the air conditioning breaks, or some piece of network hardware is producing a lot of heat. Although network environmental monitors might not often be needed, just having them installed gives administrators peace of mind.
Keeping It Cool
Fortunately, the solution to the heat problem is relatively simple. You use an air conditioning unit. The only problem is, you cannot use just any old A/C unit. Having a late-1960s window unit might be better than nothing, but you need high-quality protection.
High-quality air conditioning systems fall under the domain of industrial heating, ventilation, and air conditioning (HVAC) equipment. Server environment-specific air conditioning units are designed to maintain a constant temperature. High-quality units guarantee an accuracy of plus or minus 1° F. Most units have an audible alarm, but some also can communicate with management systems so that the server room temperature can be monitored remotely. Although the icy blast of a server room air conditioning system might not be welcomed by those who have to work in it for an extended period of time, the discomfort is far outweighed by the benefit to the server equipment.
Calculating the correct size and type of air conditioning unit can be a tricky proposition. Air conditioning systems are rated on how many cubic feet they can cool. Using this figure, and estimating the increase in temperature caused by the hardware in the room, you will have the basic information you need to choose an A/C unit. However, the calculation should take into account potential future growth. In some cases, a standby A/C unit is also installed. Whether such a system is required depends on how much fault tolerance you need and are willing to pay for.
1. While you were away, an air conditioning unit malfunctioned in a server room, and some equipment overheated. Which of the following would have alerted you to the problem?
A. Multimeter
B. Environmental monitor
C. TDR
D. OTDR
2. What tool would you use when working with an IDC?
A. Wire crimper
B. Media tester
C. OTDR
D. Punchdown tool
3. As a network administrator, you work in a wiring closet where none of the cables have been labeled. Which of the following tools are you most likely to use to locate the physical ends of the cable?
A. Toner probe
B. Wire crimper
C. Punchdown tool
D. ping
4. You are installing a new system into an existing star network, and you need a cable that is 45 feet long. Your local vendor does not stock cables of this length, so you are forced to make your own. Which of the following tools do you need to complete the task?
A. Optical tester
B. Punchdown tool
C. Crimper
D. UTP splicer
Cram Quiz Answers
1. B. Environmental monitors are used in server and network equipment rooms to ensure that the temperature does not fluctuate too greatly. In the case of a failed air conditioner, the administrator is alerted to the drastic changes in temperature. Multimeters, TDRs, and OTDRs are used to work with copper-based media.
2. D. You use a punchdown tool when working with an IDC. All the other tools are associated with making and troubleshooting cables; they are not associated with IDCs.
3. A. The toner probe tool, along with the tone locator, can be used to trace cables. Crimpers and punchdown tools are not used to locate a cable. The ping utility would be of no help in this situation.
4. C. When attaching RJ-45 connectors to UTP cables, the wire crimper is the tool you use. None of the other tools listed are used in the construction of UTP cable.
Command-Line Troubleshooting Tools
Given a scenario, use the appropriate tool.
CramSaver
If you can correctly answer these questions before going through this section, save time by skimming the Exam Alerts in this section and then completing the Cram Quiz at the end of the section.
1. What TCP/IP command can be used to troubleshoot DNS problems?
2. What is the Linux, Mac OS, and UNIX equivalent of the ipconfig command?
3. What utility is the part of the TCP/IP suite and has the function of resolving IP addresses to MAC addresses?
Answers
1. The nslookup command is a TCP/IP diagnostic tool used to troubleshoot DNS problems. On Linux,
UNIX, and Mac OS systems, you can also use the dig command for the same purpose.
2. The ifconfig command is the Linux, Mac OS, and UNIX equivalent of the ipconfig command.
3. The function of arp is to resolve IP addresses to MAC addresses.
ExamAlert
Remember that this objective begins with “Given a scenario.” That means that you may receive a drag and drop, matching, or “live OS” scenario where you have to click through to complete a specific objective-based task.
For anyone working with TCP/IP networks, troubleshooting connectivity is something that must be done. This section describes the tools used in the troubleshooting process and identifies scenarios in which they can be used.
You can use many utilities when troubleshooting TCP/IP. Although the utilities available vary from platform to platform, the functionality between platforms is quite similar. Table 11.1 lists the TCP/IP troubleshooting tools covered on the Network+ exam, along with their purpose.
TABLE 11.1 Common TCP/IP Troubleshooting Tools and Their Purposes
|
Tool |
Description |
|
|
Used to track the path a packet takes as it travels across a network. |
|
|
Performs the same function as |
|
|
Used to test connectivity between two devices on a network with IPv4. |
|
|
Used to test connectivity between two devices on a network using the IPv6 protocol in place of IPv4. |
|
|
A Windows-based utility that combines the functionality of |
|
|
Used to view and work with the IP address to MAC address resolution cache. |
|
|
Uses ARP to test connectivity between systems rather than using Internet Control Message
Protocol (ICMP), as done with a regular |
|
|
Used to view the current TCP/IP connections on a system. |
|
|
Used to configure Linux kernel firewall. |
|
|
Used to view and renew TCP/IP configuration on a Windows system. |
|
|
Used to view TCP/IP configuration on a UNIX, Linux, or Mac OS system. |
|
|
Used to perform manual DNS lookups. |
|
|
A Linux-based packet analyzer. |
|
|
Used to view and configure the routes in the routing table. |
|
|
A popular vulnerability scanner. |
The following sections look in more detail at these utilities and the output they produce.
Note
Many of the utilities discussed in this chapter have a help facility that you can
access by typing the command followed by /? or -?. On a Windows system, for example, you can get help on the netstat utility by typing netstat /?. Sometimes, using a utility with an invalid switch also brings up the help screen.
ExamAlert
Be prepared to identify what tool to use in a given scenario. Remember, there might be more than one tool that could be used. You will be expected to pick the best one for the situation described.
You will be asked to identify the output from a command, and you should be able to interpret the information provided by the command. In a performance-based question, you may be asked to enter the appropriate command for a given scenario.
The Trace Route Utility (tracert/traceroute)
The trace route utility does exactly what its name implies—it traces the route between
two hosts. It does this by using ICMP echo packets to report information at every
step in the journey. Each of the common network operating systems provides a trace
route utility, but the name of the command and the output vary slightly on each. However,
for the purposes of the Network+ exam, you should not concern yourself with the minor
differences in the output format. Table 11.2 shows the traceroute command syntax used in various operating systems.
Note
The phrase trace route utility is used in this section to refer generically to the various route-tracing applications available on common operating systems. In a live environment, you should become familiar with the version of the tool used on the operating systems you are working with.
TABLE 11.2 Trace Route Utility Commands
|
Operating System |
Trace Route Command Syntax |
|
Windows systems |
|
|
Linux/UNIX/Mac OS |
|
ExamAlert
Be prepared to identify the IP tracing command syntax used with various operating systems for the exam. Review Table 11.2 for this information.
traceroute provides a lot of useful information, including the IP address of every router connection
it passes through and, in many cases, the name of the router (although this depends
on the router’s configuration). traceroute also reports the length, in milliseconds, of the round-trip the packet made from
the source location to the router and back. This information can help identify where
network bottlenecks or breakdowns might be. The following is an example of a successful
tracert command on a Windows system:
C:\> tracert 24.7.70.37 Tracing route to c1-p4.sttlwa1.home.net [24.7.70.37] over a maximum of 30 hops: 1 30 ms 20 ms 20 ms 24.67.184.1 2 20 ms 20 ms 30 ms rd1ht-ge3-0.ok.shawcable.net [24.67.224.7] 3 50 ms 30 ms 30 ms rc1wh-atm0-2-1.vc.shawcable.net [204.209.214.193] 4 50 ms 30 ms 30 ms rc2wh-pos15-0.vc.shawcable.net [204.209.214.90] 5 30 ms 40 ms 30 ms rc2wt-pos2-0.wa.shawcable.net [66.163.76.37] 6 30 ms 40 ms 30 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37] Trace complete.
Similar to the other common operating systems covered on the Network+ exam, the tracert display on a Windows-based system includes several columns of information. The first
column represents the hop number. You may recall that hop is the term used to describe a step in the path a packet takes as it crosses the
network. The next three columns indicate the round-trip time, in milliseconds, that
a packet takes in its attempts to reach the destination. The last column is the hostname
and the IP address of the responding device.
However, not all trace route attempts are successful. The following is the output
from a tracert command on a Windows system that does not manage to get to the remote host:
C:\> tracert comptia.org Tracing route to comptia.org [216.119.103.72] over a maximum of 30 hops: 1 27 ms 28 ms 14 ms 24.67.179.1 2 55 ms 13 ms 14 ms rd1ht-ge3-0.ok.shawcable.net [24.67.224.7] 3 27 ms 27 ms 28 ms rc1wh-atm0-2-1.shawcable.net [204.209.214.19] 4 28 ms 41 ms 27 ms rc1wt-pos2-0.wa.shawcable.net [66.163.76.65] 5 28 ms 41 ms 27 ms rc2wt-pos1-0.wa.shawcable.net [66.163.68.2] 6 41 ms 55 ms 41 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37] 7 54 ms 42 ms 27 ms home-gw.st6wa.ip.att.net [192.205.32.249] 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out.
In this example, the trace route request gets to only the seventh hop, at which point it fails. This failure indicates that the problem lies on the far side of the device in step 7 or on the near side of the device in step 8. In other words, the device at step 7 is functioning but might not make the next hop. The cause of the problem could be a range of things, such as an error in the routing table or a faulty connection. Alternatively, the seventh device might be operating at 100%, but device 8 might not be functioning at all. In any case, you can isolate the problem to just one or two devices.
Note
In some cases, the owner of a router might configure it to not return ICMP traffic
like that generated by ping or traceroute. If this is the case, the ping or traceroute will fail just as if the router did not exist or was not operating.
ExamAlert
Although we have used the Windows tracert command to provide sample output in these sections, the output from traceroute on a UNIX, Linux, or Mac OS system is extremely similar.
The trace route utility can also help you isolate a heavily congested network. In
the following example, the trace route packets fail in the midst of the tracert from a Windows system, but subsequently they continue. This behavior can be an indicator
of network congestion:
C:\> tracert comptia.org Tracing route to comptia.org [216.119.103.72]over a maximum of 30 hops: 1 96 ms 96 ms 55 ms 24.67.179.1 2 14 ms 13 ms 28 ms rd1ht-ge3-0.ok.shawcable.net [24.67.224.7] 3 28 ms 27 ms 41 ms rc1wh-atm0-2-1.shawcable.net [204.209.214.19] 4 28 ms 41 ms 27 ms rc1wt-pos2-0.wa.shawcable.net [66.163.76.65] 5 41 ms 27 ms 27 ms rc2wt-pos1-0.wa.shawcable.net [66.163.68.2] 6 55 ms 41 ms 27 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37] 7 54 ms 42 ms 27 ms home-gw.st6wa.ip.att.net [192.205.32.249] 8 55 ms 41 ms 28 ms gbr3-p40.st6wa.ip.att.net [12.123.44.130] 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 69 ms 68 ms 69 ms gbr2-p20.sd2ca.ip.att.net [12.122.11.254] 14 55 ms 68 ms 69 ms gbr1-p60.sd2ca.ip.att.net [12.122.1.109] 15 82 ms 69 ms 82 ms gbr1-p30.phmaz.ip.att.net [12.122.2.142] 16 68 ms 69 ms 82 ms gar2-p360.phmaz.ip.att.net [12.123.142.45] 17 110 ms 96 ms 96 ms 12.125.99.70 18 124 ms 96 ms 96 ms light.crystaltech.com [216.119.107.1] 19 82 ms 96 ms 96 ms 216.119.103.72 Trace complete.
Generally speaking, trace route utilities enable you to identify the location of a
problem in the connectivity between two devices. After you determine this location,
you might need to use a utility such as ping to continue troubleshooting. In many cases, as in the examples provided in this chapter,
the routers might be on a network such as the Internet and therefore not within your
control. In that case, you can do little except inform your ISP of the problem.
When dealing with IPv6, the same tools exist, but are followed with -6; so, tracert becomes tracert -6, and traceroute becomes traceroute -6.
ping
Most network administrators are familiar with the ping utility and are likely to use it on an almost daily basis. The basic function of
the ping command is to test the connectivity between the two devices on a network. All the
command is designed to do is determine whether the two computers can see each other
and to notify you of how long the round-trip takes to complete.
Although ping is most often used on its own, a number of switches can be used to assist in the
troubleshooting process. Table 11.3 shows some of the commonly used switches with ping on a Windows system.
TABLE 11.3 ping Command Switches
|
Option |
Description |
|
|
Pings a device on the network until stopped |
|
|
Resolves addresses to hostnames |
|
|
Specifies the number of echo requests to send |
|
|
Records the route for count hops |
|
|
Time stamp for count hops |
|
|
Timeout in milliseconds to wait for each reply |
|
|
Pings a device on the network using IPv6 instead of IPv4 |
ExamAlert
You will likely be asked about ping, its switches used, and how ping can be used in a troubleshooting scenario.
ping works by sending ICMP echo request messages to another device on the network. If
the other device on the network hears the ping request, it automatically responds
with an ICMP echo reply. By default, the ping command on a Windows-based system sends four data packets; however, using the -t switch, a continuous stream of ping requests can be sent.
ping is perhaps the most widely used of all network tools; it is primarily used to verify
connectivity between two network devices. On a good day, the results from the ping command are successful, and the sending device receives a reply from the remote device.
Not all ping results are that successful. To use ping effectively, you must interpret the results of a failed ping command.
The Destination Host Unreachable Message
The “Destination Host Unreachable” error message means that a route to the destination computer system cannot be found. To remedy this problem, you might need to examine the routing information on the local host to confirm that the local host is correctly configured, or you might need to make sure that the default gateway information is correct. The following is an example of a ping failure that gives the “Destination Host Unreachable” message:
Pinging 24.67.54.233 with 32 bytes of data: Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Ping statistics for 24.67.54.233: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
The Request Timed Out Message
The “Request Timed Out” error message is common when you use the ping command. Essentially, this error message indicates that your host did not receive
the ping message back from the destination device within the designated time period.
Assuming that the network connectivity is okay on your system, this typically indicates
that the destination device is not connected to the network, is powered off, or is
not correctly configured. It could also mean that some intermediate device is not
operating correctly. In some rare cases, it can also indicate that the network has
so much congestion that timely delivery of the ping message could not be completed.
It might also mean that the ping is being sent to an invalid IP address or that the
system is not on the same network as the remote host, and an intermediary device is
not correctly configured. In any of these cases, the failed ping should initiate a
troubleshooting process that might involve other tools, manual inspection, and possibly
reconfiguration. The following example shows the output from a ping to an invalid
IP address:
C:\> ping 169.76.54.3 Pinging 169.76.54.3 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 169.76.54.3: Packets: Sent = 4, Received = 0, Lost = 4 (100% Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
During the ping request, you might receive some replies from the remote host that
are intermixed with “Request Timed Out” errors. This is often the result of a congested
network. An example follows; notice that this example, which was run on a Windows
system, uses the -t switch to generate continuous pings:
C:\> ping -t 24.67.184.65 Pinging 24.67.184.65 with 32 bytes of data: Reply from 24.67.184.65: bytes=32 time=55ms TTL=127 Reply from 24.67.184.65: bytes=32 time=54ms TTL=127 Reply from 24.67.184.65: bytes=32 time=27ms TTL=127 Request timed out. Request timed out. Request timed out. Reply from 24.67.184.65: bytes=32 time=69ms TTL=127 Reply from 24.67.184.65: bytes=32 time=28ms TTL=127 Reply from 24.67.184.65: bytes=32 time=28ms TTL=127 Reply from 24.67.184.65: bytes=32 time=68ms TTL=127 Reply from 24.67.184.65: bytes=32 time=41ms TTL=127 Ping statistics for 24.67.184.65: Packets: Sent = 11, Received = 8, Lost = 3 (27% loss), Approximate round trip times in milli-seconds: Minimum = 27ms, Maximum = 69ms, Average = 33ms
In this example, three packets were lost. If this continued on your network, you would need to troubleshoot to find out why packets were dropped.
The Unknown Host Message
The “Unknown Host” error message is generated when the hostname of the destination
computer cannot be resolved. This error usually occurs when you ping an incorrect hostname, as shown in the following example, or try to use ping with a hostname when hostname resolution (via DNS or a HOSTS text file) is not configured:
C:\> ping www.comptia.ca Unknown host www.comptia.ca
If the ping fails, you need to verify that the ping is sent to the correct remote
host. If it is, and if name resolution is configured, you have to dig a little more
to find the problem. This error might indicate a problem with the name resolution
process, and you might need to verify that the DNS or WINS server is available. Other
commands, such as nslookup or dig, can help in this process.
The Expired TTL Message
The Time To Live (TTL) is a key consideration in understanding the ping command. The function of the TTL is to prevent circular routing, which occurs when
a ping request keeps looping through a series of hosts. The TTL counts each hop along
the way toward its destination device. Each time it counts one hop, the hop is subtracted
from the TTL. If the TTL reaches 0, it has expired, and you get a message like the
following:
Reply from 24.67.180.1: TTL expired in transit
If the TTL is exceeded with ping, you might have a routing problem on the network. You can modify the TTL for ping on a Windows system by using the ping -i command.
Troubleshooting with ping
Although ping does not completely isolate problems, you can use it to help identify where a problem
lies. When troubleshooting with ping, follow these steps:
1. Ping the IP address of your local loopback using the command ping 127.0.0.1. If this command is successful, you know that the TCP/IP protocol suite
is installed correctly on your system and is functioning. If you cannot ping the local
loopback adapter, TCP/IP might need to be reloaded or reconfigured on the machine
you are using.
ExamAlert
The loopback is a special function within the TCP/IP protocol stack that is supplied
for troubleshooting purposes. The Class A IP address 127.x.x.x is reserved for the IPv4 loopback. Although convention dictates that you use 127.0.0.1,
you can use any address in the 127.x.x.x range, except for the network number itself (127.0.0.0) and the broadcast address
(127.255.255.255). You can also ping by using the default hostname for the local system,
which is called localhost (for example, ping localhost). The same function can be performed in IPv6 by using the address ::1.
2. Ping the assigned IP address of your local network interface card (NIC). If the ping is successful, you know that your NIC is functioning on the network and has TCP/IP correctly installed. If you cannot ping the local NIC, TCP/IP might not be correctly bound to the NIC, or the NIC drivers might be improperly installed.
3. Ping the IP address of another known good system on your local network. By doing so, you can determine whether the computer you are using can see other computers on the network. If you can ping other devices on your local network, you have network connectivity.
If you cannot ping other devices on your local network, but you could ping the IP address of your system, you might not be connected to the network correctly.
4. After you confirm that you have network connectivity for the local network, you can verify connectivity to a remote network by sending a ping to the IP address of the default gateway.
5. If you can ping the default gateway, you can verify remote connectivity by sending a ping to the IP address of a system on a remote network.
ExamAlert
You might be asked to relate the correct procedure for using ping for a connectivity problem. A performance-based question may ask you to implement
the ping command to test for connectivity.
Using just the ping command in these steps, you can confirm network connectivity on not only the local
network, but also on a remote network. The whole process requires as much time as
it takes to enter the command, and you can do it all from a single location.
If you are an optimistic person, you can perform step 5 first. If that works, all the other steps will also work, saving you the need to test them. If your step 5 trial fails, you can go to step 1 and start the troubleshooting process from the beginning.
Note
All but one of the ping examples used in this section show the ping command using the IP address of the remote host. It is also possible to ping the Domain Name Service (DNS) name of the remote host (for example, ping www.comptia.org, ping server1). However, you can do this only if your network uses a DNS server. On a Windows-based
network, you can also ping by using the Network Basic Input/Output System (NetBIOS) computer name.
When dealing with IPv6, the same tools exist, but are followed with 6 or -6; so, ping becomes ping6 or ping -6.
pathping
As great as ping is, at times you might wish for the additional information and functionality provided
by tracert. To address that need on a Windows system, you can use pathping. It combines the features of the other two tools into one.
ARP
Address Resolution Protocol (ARP) is used to resolve IP addresses to MAC addresses. This is significant because on a network, devices find each other using the IP address, but communication between devices requires the MAC address.
ExamAlert
Remember that the function of ARP is to resolve IP addresses to Layer 2 or MAC addresses.
When a computer wants to send data to another computer on the network, it must know the MAC address (physical address) of the destination system. To discover this information, ARP sends out a discovery packet to obtain the MAC address. When the destination computer is found, it sends its MAC address to the sending computer. The ARP-resolved MAC addresses are stored temporarily on a computer system in the ARP cache. Inside this ARP cache is a list of matching MAC and IP addresses. This ARP cache is checked before a discovery packet is sent to the network to determine whether there is an existing entry.
Entries in the ARP cache are periodically flushed so that the cache does not fill
up with unused entries. The following code shows an example of the arp command with the output from a Windows system:
C:\> arp -a Interface: 24.67.179.22 on Interface 0x3 Internet Address Physical Address Type 24.67.179.1 00-00-77-93-d8-3d dynamic
As you might notice, the type is listed as dynamic. Entries in the ARP cache can be added statically or dynamically. Static entries are added manually and do not expire. The dynamic entries are added automatically when the system accesses another on the network.
As with other command-line utilities, several switches are available for the arp command. Table 11.4 shows the available switches for Windows-based systems.
TABLE 11.4 arp Switches
|
Switch |
Description |
|
|
Displays both the IP and MAC addresses and whether they are dynamic or static entries |
|
|
Specifies a specific Internet address |
|
|
Displays the ARP entries for a specified network interface |
|
|
Specifies a MAC address |
|
|
Specifies an Internet address |
|
|
Deletes an entry from the ARP cache |
|
|
Adds a static permanent address to the ARP cache |
arp ping
Earlier in this chapter we talked about the ping command and how it is used to test connectivity between devices on a network. Using
the ping command is often an administrator’s first step to test connectivity between network
devices. If the ping fails, it is assumed that the device you are pinging is offline.
But this may not always be the case.
Most companies now use firewalls or other security measures that may block Internet Control Message Protocol (ICMP) requests. This means that a ping request will not work. Blocking ICMP is a security measure; if a would-be hacker cannot hit the target, he may not attack the host.
ExamAlert
One type of attack is called an ICMP flood attack (also known as a ping attack). The attacker sends continuous ping packets to a server or network system, eventually tying up that system’s resources, making it unable to respond to requests from other systems.
If ICMP is blocked, you have still another option to test connectivity with a device
on the network: the arp ping. As mentioned, the ARP utility is used to resolve IP addresses to MAC addresses.
The arp ping utility does not use the ICMP protocol to test connectivity like ping does; rather, it uses the ARP protocol. However, ARP is not routable, and the arp ping cannot be routed to work over separate networks. The arp ping works only on the local subnet.
Just like with a regular ping, an arp ping specifies an IP address; however, instead of returning regular ping results, the
arp ping responds with the MAC address and name of the computer system. So, when a regular
ping using ICMP fails to locate a system, the arp ping uses a different method to find the system. With arp ping, you can directly ping a MAC address. From this, you can determine whether duplicate
IP addresses are used and, as mentioned, determine whether a system is responding.
arp ping is not built in to Windows, but you can download a number of programs that allow
you to ping using ARP. Linux, however, has an arp ping utility ready to use.
ExamAlert
arp ping is not routable and can be used only on the local network.
The netstat Command
The netstat command displays the protocol statistics and current TCP/IP connections on the local
system. Used without any switches, the netstat command shows the active connections for all outbound TCP/IP connections. In addition,
several switches are available that change the type of information netstat displays. Table 11.5 shows the various switches available for the netstat utility.
|
Switch |
Description |
|
|
Displays the current connections and listening ports |
|
|
Displays Ethernet statistics |
|
|
Lists addresses and port numbers in numeric form |
|
|
Shows connections for the specified protocol |
|
|
Shows the routing table |
|
|
Lists per-protocol statistics |
|
|
Specifies how long to wait before redisplaying statistics |
ExamAlert
You can use the netstat and route print commands to show the routing table on a local or remote system.
The netstat utility is used to show the port activity for both TCP and UDP connections, showing
the inbound and outbound connections. When used without switches, the netstat utility has four information headings.
Proto: Lists the protocol being used, either UDP or TCP
Local address: Specifies the local address and port being used
Foreign address: Identifies the destination address and port being used
State: Specifies whether the connection is established
In its default use, the netstat command shows outbound connections that have been established by TCP. The following
shows sample output from a netstat command without using any switches:
C:\> netstat Active Connections Proto Local Address Foreign Address State TCP laptop:2848 MEDIASERVICES1:1755 ESTABLISHED TCP laptop:1833 www.dollarhost.com:80 ESTABLISHED TCP laptop:2858 194.70.58.241:80 ESTABLISHED TCP laptop:2860 194.70.58.241:80 ESTABLISHED TCP laptop:2354 www.dollarhost.com:80 ESTABLISHED TCP laptop:2361 www.dollarhost.com:80 ESTABLISHED TCP laptop:1114 www.dollarhost.com:80 ESTABLISHED TCP laptop:1959 www.dollarhost.com:80 ESTABLISHED TCP laptop:1960 www.dollarhost.com:80 ESTABLISHED TCP laptop:1963 www.dollarhost.com:80 ESTABLISHED TCP laptop:2870 localhost:8431 TIME_WAIT TCP laptop:8431 localhost:2862 TIME_WAIT TCP laptop:8431 localhost:2863 TIME_WAIT TCP laptop:8431 localhost:2867 TIME_WAIT TCP laptop:8431 localhost:2872 TIME_WAIT
As with any other command-line utility, the netstat utility has a number of switches. The following sections briefly explain the switches
and give sample output from each.
netstat -e
The netstat -e command shows the activity for the NIC and displays the number of packets that have
been both sent and received. Here’s an example:
C:\WINDOWS\Desktop> netstat -e Interface Statistics Received Sent Bytes 17412385 40237510 Unicast packets 79129 85055 Non-unicast packets 693 254 Discards 0 0 Errors 0 0 Unknown protocols 306
As you can see, the netstat -e command shows more than just the packets that have been sent and received:
Bytes: The number of bytes that the NIC has sent or received since the computer was turned
on.
Unicast packets: Packets sent and received directly by this interface.
Nonunicast packets: Broadcast or multicast packets that the NIC picked up.
Discards: The number of packets rejected by the NIC, perhaps because they were damaged.
Errors: The errors that occurred during either the sending or receiving process. As you would
expect, this column should be a low number. If it is not, this could indicate a problem
with the NIC.
Unknown protocols: The number of packets that the system could not recognize.
netstat -a
The netstat -a command displays statistics for both Transport Control Protocol (TCP) and User Datagram Protocol (UDP). Here is an example of the netstat -a command:
C:\WINDOWS\Desktop> netstat -a Active Connections Proto Local Address Foreign Address State TCP laptop:1027 LAPTOP:0 LISTENING TCP laptop:1030 LAPTOP:0 LISTENING TCP laptop:1035 LAPTOP:0 LISTENING TCP laptop:50000 LAPTOP:0 LISTENING TCP laptop:5000 LAPTOP:0 LISTENING TCP laptop:1035 msgr-ns41.msgr.hotmail.com:1863 ESTABLISHED TCP laptop:nbsession LAPTOP:0 LISTENING TCP laptop:1027 localhost:50000 ESTABLISHED TCP laptop:50000 localhost:1027 ESTABLISHED UDP laptop:1900 *:* UDP laptop:nbname *:* UDP laptop:nbdatagram *:* UDP laptop:1547 *:* UDP laptop:1038 *:* UDP laptop:1828 *:* UDP laptop:3366 *:*
As you can see, the output includes four columns, which show the protocol, the local
address, the foreign address, and the port’s state. The TCP connections show the local
and foreign destination addresses and the connection’s current state. UDP, however,
is a little different. It does not list a state status because, as mentioned throughout
this book, UDP is a connectionless protocol and does not establish connections. The
following list further explains the information provided by the netstat -a command:
Proto: The protocol used by the connection.
Local address: The IP address of the local computer system and the port number it is using. If the
entry in the local address field is an asterisk (*), the port has not yet been established.
Foreign address: The IP address of a remote computer system and the associated port. When a port has
not been established, as with the UDP connections, *:* appears in the column.
State: The current state of the TCP connection. Possible states include established, listening,
closed, and waiting.
netstat -r
The netstat -r command is often used to view a system’s routing table. A system uses a routing table
to determine routing information for TCP/IP traffic. The following is an example
of the netstat -r command from a Windows system:
C:\WINDOWS\Desktop> netstat -r Route table ===================================================================== ===================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 24.67.179.1 24.67.179.22 1 24.67.179.0 255.255.255.0 24.67.179.22 24.67.179.22 1 24.67.179.22 255.255.255.255 127.0.0.1 127.0.0.1 1 24.255.255.255 255.255.255.255 24.67.179.22 24.67.179.22 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 24.67.179.22 24.67.179.22 1 255.255.255.255 255.255.255.255 24.67.179.22 2 1 Default Gateway: 24.67.179.1 ===================================================================== Persistent Routes: None
Caution
The netstat -r command output shows the same information as the output from the route print command.
netstat -s
The netstat -s command displays a number of statistics related to the TCP/IP protocol suite. Understanding
the purpose of every field in the output is beyond the scope of the Network+ exam,
but for your reference, sample output from the netstat -s command is shown here:
C:\> netstat -s IP Statistics Packets Received = 389938 Received Header Errors = 0 Received Address Errors = 1876 Datagrams Forwarded = 498 Unknown Protocols Received = 0 Received Packets Discarded = 0 Received Packets Delivered = 387566 Output Requests = 397334 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 916 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0 ICMP Statistics Received Sent Messages 40641 41111 Errors 0 0 Destination Unreachable 223 680 Time Exceeded 24 0 Parameter Problems 0 0 Source Quenches 0 0 Redirects 0 38 Echos 20245 20148 Echo Replies 20149 20245 Timestamps 0 0 Timestamp Replies 0 0 Address Masks 0 0 Address Mask Replies 0 0 TCP Statistics Active Opens = 13538 Passive Opens = 23132 Failed Connection Attempts = 9259 Reset Connections = 254 Current Connections = 15 Segments Received = 330242 Segments Sent = 326935 Segments Retransmitted = 18851 UDP Statistics Datagrams Received = 20402 No Ports = 20594 Receive Errors = 0 Datagrams Sent = 10217
iptables
The iptables utility is used to configure the firewall in Linux. It requires elevated/administrative/root
privileges to run, and the executable itself is installed in /usr/sbin/iptables.
ipconfig
The ipconfig command is a technician’s best friend when it comes to viewing the TCP/IP configuration
of a Windows system. Used on its own, the ipconfig command shows basic information, such as the name of the local network interface,
the IP address, the subnet mask, and the default gateway. Combined with the /all switch, it shows a detailed set of information, as shown in the following example:
C:\> ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : server Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : tampabay.rr.com Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : tampabay.rr.com Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet Physical Address. . . . . . . . . : 00-25-64-8C-9E-BF DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::51b9:996e:9fac:7715%10 (Preferred) IPv4 Address. . . . . . . . . . . : 192.168.1.119(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Wednesday, January 28, 2018 6:00:54 AM Lease Expires . . . . . . . . . . : Thursday, January 29, 2018 6:00:54 AM Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.1 DHCPv6 IAID . . . . . . . . . . . : 234890596 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-2A-5B-37-00-25-64-8C-9E-BF DNS Servers . . . . . . . . . . . : 192.168.1.1 NetBIOS over Tcpip. . . . . . . . : Enabled Connection-specific DNS Suffix Search List : tampabay.rr.com
As you can imagine, you can use the output from the ipconfig /all command in a massive range of troubleshooting scenarios. Table 11.6 lists some of the most common troubleshooting symptoms, along with where to look
for clues about solving them in the ipconfig /all output.
Note
When looking at ipconfig information, you should be sure that all information is present and correct. For
example, a missing or incorrect default gateway parameter limits communication to
the local segment.
TABLE 11.6 Common Troubleshooting Symptoms that ipconfig Can Help Solve
|
Symptom |
Field to Check in the Output |
|
The user cannot connect to any other system. |
Ensure that the TCP/IP address and subnet mask are correct. If the network uses DHCP, ensure that DHCP is enabled. |
|
The user can connect to another on the same subnet but cannot connect to a remote system. |
Ensure the default gateway is configured correctly. |
|
The user is unable to browse the Internet. |
Ensure the DNS server parameters are correctly configured. |
|
The user cannot browse across remote subnets. |
Ensure the WINS or DNS server parameters are correctly configured, if applicable. |
ExamAlert
You should be prepared to identify the output from an ipconfig command in relationship to a troubleshooting scenario.
Using the /all switch might be the most popular, but there are a few others. These include the switches
listed in Table 11.7.
ExamAlert
ipconfig and its associated switches are widely used by network administrators and therefore
should be expected to make an appearance on the exam.
|
Switch |
Description |
|
|
Displays the |
|
|
Displays additional IP configuration information |
|
|
Releases the IPv4 address of the specified adapter |
|
|
Releases the IPv6 address of the specified adapter |
|
|
Renews the IPv4 address of a specified adapter |
|
|
Renews the IPv6 address of a specified adapter |
|
|
Purges the DNS cache |
|
|
Refreshes the DHCP lease and reregisters the DNS names |
|
|
Used to display the information in the DNS cache |
Tip
The ipconfig /release and ipconfig /renew commands work only when your system is using DHCP.
ExamAlert
The ipconfig command on the Windows client and Windows Server operating systems provides additional
switches and functionality geared toward Active Directory and Dynamic DNS. You do
not need to be concerned with these switches for the exam, but you can view information
on them by using the ipconfig /? command.
ifconfig
ifconfig performs the same function as ipconfig, but on a Linux, UNIX, or Mac OS system. Because Linux relies more heavily on command-line
utilities than Windows, the Linux and UNIX version of ifconfig provides much more functionality than ipconfig. On a Linux or UNIX system, you can get information about the usage of the ifconfig command by using ifconfig -help. The following output provides an example of the basic ifconfig command run on a Linux system:
eth0 Link encap:Ethernet HWaddr 00:60:08:17:63:A0 inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:911 errors:0 dropped:0 overruns:0 frame:0 TX packets:804 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 Base address:0xe400 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:18 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
Although the ifconfig command displays the IP address, subnet mask, and default gateway information for
both the installed network adapter and the local loopback adapter, it does not report
DHCP lease information. Instead, you can use the pump -s command to view detailed information on the DHCP lease, including the assigned IP
address, the address of the DHCP server, and the time remaining on the lease. You
can also use the pump command to release and renew IP addresses assigned via DHCP and to view DNS server
information.
nslookup
nslookup is a utility used to troubleshoot DNS-related problems. Using nslookup, you can, for example, run manual name resolution queries against DNS servers, get
information about your system’s DNS configuration, or specify what kind of DNS record
should be resolved.
When nslookup is started, it displays the current hostname and the IP address of the locally configured
DNS server. You then see a command prompt that allows you to specify further queries.
This is known as interactive mode. Table 11.8 lists the commands you can enter in interactive mode.
TABLE 11.8 nslookup Switches
Instead of using interactive mode, you can execute nslookup requests directly at the command prompt. The following listing shows the output from
the nslookup command when a domain name is specified to be resolved:
C:\> nslookup comptia.org Server: nsc1.ht.ok.shawcable.net Address: 64.59.168.13 Non-authoritative answer: Name: comptia.org Address: 208.252.144.4
As you can see from the output, nslookup shows the hostname and IP address of the DNS server against which the resolution
was performed, along with the hostname and IP address of the resolved host.
dig
dig is used on a Linux, UNIX, or Mac OS system to perform manual DNS lookups. dig performs the same basic task as nslookup, but with one major distinction: The dig command does not have an interactive mode and instead uses only command-line switches
to customize results.
dig generally is considered a more powerful tool than nslookup, but in the course of a typical network administrator’s day, the minor limitations
of nslookup are unlikely to be too much of a factor. Instead, dig is often the tool of choice for DNS information and troubleshooting on UNIX, Linux,
or Mac OS systems. Like nslookup, dig can be used to perform simple name resolution requests. The output from this process
is shown in the following listing:
; <<>> DiG 8.2 <<>> examcram.com ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUERY SECTION: ;; examcram.com, type = A, class = IN ;; ANSWER SECTION: examcram.com. 7h33m IN A 63.240.93.157 ;; AUTHORITY SECTION: examcram.com. 7h33m IN NS usrxdns1.pearsontc.com. examcram.com. 7h33m IN NS oldtxdns2.pearsontc.com. ;; Total query time: 78 msec ;; FROM: localhost.localdomain to SERVER: default - 209.53.4.130 ;; WHEN: Sat Oct 16 20:21:24 2018 ;; MSG SIZE sent: 30 rcvd: 103
As you can see, dig provides a number of pieces of information in the basic output—more so than nslookup. Network administrators can gain information from three key areas of the output:
ANSWER SECTION, AUTHORITY SECTION, and the last four lines of the output.
The ANSWER SECTION of the output provides the name of the domain or host being resolved, along with
its IP address. The A in the results line indicates the record type that is being resolved.
The AUTHORITY SECTION provides information on the authoritative DNS servers for the domain against which
the resolution request was performed. This information can be useful in determining
whether the correct DNS servers are considered authoritative for a domain.
The last four lines of the output show how long the name resolution request took to process and the IP address of the DNS server that performed the resolution. It also shows the date and time of the request, as well as the size of the packets sent and received.
The tcpdump Command
The tcpdump command is used on Linux/UNIX systems to print the contents of network packets. It
can read packets from a network interface card or from a previously created saved
packet file and write packets to either standard output or a file.
The route Utility
The route utility is an often-used and very handy tool. With the route command, you display and modify the routing table on your Windows and Linux systems.
Figure 11.1 shows the output from a route print command on a Windows system.
FIGURE 11.1 The output from a route print command on a Windows system
Note
The discussion here focuses on the Windows route command, but other operating systems have equivalent commands. On a Linux system,
for example, the command is also route, but the usage and switches are different.
In addition to displaying the routing table, the Windows version of the route command
has a number of other switches, as detailed in Table 11.9. For complete information about all the switches available with the route command on a Windows system, type route at the command line. To see a list of the route command switches on a Linux system, use the command route -help.
TABLE 11.9 Switches for the route Command in Windows
|
Switch |
Description |
|
|
Enables you to add a static route to the routing table. |
|
|
Enables you to remove a route from the routing table. |
|
|
Enables you to modify an existing route. |
|
|
When used with the |
|
|
Enables you to view the system’s routing table. |
|
|
Removes all gateway entries from the routing table. |
nmap
nmap is a free download for Windows or Linux used to scan ports on machines. Those scans
can show what services are running as well as information about the target machine’s
operating system. The utility can be used to scan a range of IP addresses or just
a single IP address.
Cram Quiz
1. What command can you issue from the command line to view the status of the system’s ports?
A. netstat -p
B. netstat -o
C. netstat -a
D. netstat –y
2. Which of the following tools can you use to perform manual DNS lookups on a Linux system? (Choose two.)
A. dig
B. nslookup
C. tracert
D. dnslookup
3. Which of the following commands generates a “Request Timed Out” error message?
A. ping
B. netstat
C. ipconfig
D. nbtstat
4. Which of the following commands would you use to add a static entry to the ARP table of a Windows system?
A. arp -a IP Address MAC Address
B. arp -s MAC Address IP Address
C. arp -s IP Address MAC Address
D. arp -i IP Address MAC Address
5. Which command created the following output?
Server: nen.bx.ttfc.net Address: 209.55.4.155 Name: examcram.com Address: 63.240.93.157
A. nbtstat
B. ipconfig
C. tracert
D. nslookup
Cram Quiz Answers
1. C. Administrators can quickly determine the status of common ports by issuing the netstat -a command from the command line. This command output lists the ports used by the system
and whether they are open and listening.
2. A, B. Both the dig and nslookup commands can be used to perform manual DNS lookups on a Linux system. You cannot
perform a manual lookup with the tracert command. There is no such command as dnslookup.
3. A. The ping command generates a “Request Timed Out” error when it cannot receive a reply from
the destination system. None of the other commands listed produce this output.
4. C. The command arp -s IP Address MAC Address would correctly add a static entry to the ARP table. None
of the other answers are valid ARP switches.
5. D. The output was produced by the nslookup command. The other commands listed produce different output.
Troubleshooting Common Network Service Issues
Given a scenario, troubleshoot common network service issues.
CramSaver
If you can correctly answer these questions before going through this section, save time by skimming the Exam Alerts in this section and then completing the Cram Quiz at the end of the section.
1. What one, hardcoded address must be unique on a network for networking to function properly?
2. What can you try to do to handle DHCP exhaustion if you cannot increase the scope?
3. A client has an incorrect gateway configured. What is the most likely manifestation of this error?
Answers
1. The MAC address must be unique for each network interface card and there can be no duplicates.
2. You can shorten the lease period for each client and, hopefully, recover addresses sooner for issue to other clients.
3. With an incorrect gateway, the client will not be able to access networking services beyond the local network.
ExamAlert
Remember that this objective begins with “Given a scenario.” That means that you may receive a drag and drop, matching, or “live OS” scenario where you have to click through to complete a specific objective-based task.
You will no doubt find yourself troubleshooting networking problems much more often than you would like to. When you troubleshoot these problems, a methodical approach is likely to pay off.
ExamAlert
Wiring problems are related to the cable used in a network. For the purposes of the exam, infrastructure problems are classified as those related to network devices, such as hubs, switches, and routers.
Common Problems to Be Aware Of
In the eyes of CompTIA and the Network+ exam, you should be aware of some problems more than others. Although subsequent sections look at problems in particular areas, pay special attention to those that fall within this section as you study for the exam.
Names Not Resolving
When the wrong Domain Name Service (DNS) values (typically primary and secondary) are entered during router configuration, users cannot take advantage of the DNS service. Depending on where the wrong values are given, name resolution may not occur (if all values are incorrect), or resolution could take a long time (if only the primary value is incorrect), thus giving the appearance that the web is taking a long time to load.
Make sure the correct values appear for DNS entries in the router configuration to avoid name resolution problems.
Incorrect Gateway
The default gateway configured on the router is where the data goes after it leaves
the local network. Although many routes can be built dynamically, it is often necessary
to add the first routes when installing/replacing a router. You can use the ip route command on most Cisco routers to do this from the command line, or most routers include
a graphical interface for simplifying the process.
When you have the gateways configured, use the ping and tracert/ traceroute utilities to verify connectivity and proper configuration.
ExamAlert
Know the tools to use to test connectivity.
Incorrect Netmask
When the subnet mask is incorrect, the router thinks the network is divided into segments other than how it is actually configured. Because the purpose of the router is to route traffic, a wrong value here can cause it to try to route traffic to subnets that do not exist. The value of the subnet mask on the router must match the true configuration of the network.
Duplicate IP Address
Every IP address on a network must be unique. This is true not only for every host, but for the router as well, and every network card in general. The scope of the network depends on the size of the network that the card is connected to; if it is connected to the LAN, the IP address must be unique on that LAN, whereas if it is connected to the Internet, it must be unique on it.
If there is a duplicate address, in the best scenario you will receive messages indicating duplicate IP addresses, and in the worst scenario, network traffic will become unreliable. In all cases, you must correct the problem and make certain duplicate addresses exist nowhere on your network, including the routers.
Duplicate MAC Addresses
The MAC address is hardcoded into the NIC and cannot be changed. It consists of two components—one identifying the vendor and the other a serial number so that it will be unique. Of all things on the network, this is the one value that must stay constant for ARP, RARP, and other protocols to be able to translate IP addresses to machines and have communication across the network.
Given that, the only way for a MAC address to not be unique is for someone to be trying to add a rogue device impersonating another (typically a server). If this is the case, there will be serious problems on the network, and you must find—and disable—the unauthorized device immediately.
Expired IP Address
DHCP leases IP addresses to clients and—when functioning properly—continues to renew those leases as long at the client needs them. An expired address can mean that the DHCP server is down or unavailable, and the client will typically lose its address, rendering it unable to continue communicating on the network.
Each system must be assigned a unique IP address so that it can communicate on the network. Clients on a LAN have a private IP address and matching subnet mask. Table 11.10 shows the private IP ranges. If a system has the wrong IP or subnet mask, it cannot communicate on the network. If the client system has misconfigured DHCP settings, such as an IP address in the 169.254.0.0 APIPA range, the system is not connected to a DHCP server and is not able to communicate beyond the network.
TABLE 11.10 Private Address Ranges
|
Class |
Address Range |
Default Subnet Mask |
|
A |
10.0.0.0 to 10.255.255.255 |
255.0.0.0 |
|
B |
172.16.0.0 to 172.31.255.255 |
255.255.0.0 |
|
C |
192.168.0.0 to 192.168.255.255 |
255.255.255.0 |
ExamAlert
You need to know the private address ranges in Table 11.10.
Rogue DHCP Server
A rogue DHCP server is any DHCP server on the network that was added by an unauthorized party and is not under the administrative control of the network administrators. It can be used to give false values or to set clients up for network attacks, such as man in the middle.
Untrusted SSL Certificate
An untrusted SSL certificate is usually one that is not signed or that has expired. Sometimes, this issue can be caused by a client using an older browser or one that is not widely supported. As a general rule, though, users should be instructed to stop attempting to visit a site if they see this error.
Incorrect Time
Incorrect time on a network can be more than just an annoyance, because timestamps are important in the event of trying to document an attack. Most network devices use Network Time Protocol (NTP) to keep the system time as defined by a designated server. Make sure that server has the correct time on it and is updated, patched, and secured just as you would any other network critical server.
Exhausted DHCP Scope
The DHCP scope is the pool of possible IP addresses a DHCP server can issue. If that pool becomes exhausted and not enough addresses are available for the devices needing to connect, devices will not be given the values they need (many will then resort to using APIPA addresses in the 169.254 range, as discussed earlier.
The only solution is to increase the scope and/or decrease the lease time. If you reduce the lease time from days to hours, more addresses should become available as hosts leave the network at the end of their shifts, and those values become available for use by others.
Blocked TCP/UDP Ports
As a security rule, only needed ports should be enabled and allowed on a network. Unfortunately, you don’t always have a perfect idea of which ports you need, and it is possible to inadvertently have some blocked TCP/UDP ports that you need to use.
If you find your firewall is blocking a needed port, open that port (make an exception) and allow it to be used.
Incorrect Firewall Settings
Incorrect firewall settings typically fall under the category of blocking ports that you need open (previously addressed) or allowing ports that you don’t need. From a security perspective, the latter situation is the worse because every open port represents a door that an intruder could use to access the system or at least a vulnerability. Be sure to know which ports are open, and close any that are not needed.
Incorrect ACL Settings
The purpose of an Access Control List (ACL) is to define who/what can access your system. Incorrect ACL settings could keep too many off, but typically the error is allowing too many on. Used properly, an ACL can enable devices in your network to ignore requests from specified users or systems or to grant them certain network privileges. You may find that a certain IP address is constantly scanning your network, and you can block this IP address. If you block it at the router, the IP address will automatically be rejected anytime it attempts to use your network.
Unresponsive Service
When a service does not respond, it could be due to overload, being down, or bad configuration. The first order of business is to ascertain which of these three the situation is and then decide what you need to do to fix it. If the server/service is overloaded, look for a way to increase the capacity or balance the load. If the server/service is down, investigate why and what needs to be done to bring it back up again. If the server/service is misconfigured, make the necessary changes to configure it properly.
Hardware Failure
If you are looking for a challenge, troubleshooting hardware infrastructure problems is for you. It is often not an easy task and usually involves many processes, including baselining and performance monitoring. One of the keys to identifying the hardware failure is to know what devices are used on a particular network and what each device is designed to do. Table 11.11 lists some of the common hardware components used in a network infrastructure, as well as some common problem symptoms and troubleshooting methods.
TABLE 11.11 Common Network Hardware Components, Their Functions, and Troubleshooting Strategies
ExamAlert
Be familiar with the devices listed in Table 11.11 and their failure signs.
For more information on network hardware devices and their functions, refer to Chapter 4, “Network Components and Devices.”
Cram Quiz
1. Although many routes can be built dynamically, it is often necessary to add the first routes when installing/replacing a router. Which of the following commands can you use on most Cisco routers to do this from the command line?
A. ip route
B. add route
C. first route
D. route change
2. Which of the following best describes the function of the default gateway?
A. It converts hostnames to IP addresses.
B. It converts IP addresses to hostnames.
C. It enables systems to communicate with systems on a remote network.
D. It enables systems to communicate with routers.
3. Consider the following figure. Which of the following statements is true?
A. The system cannot access the local network.
B. The system cannot access remote networks.
C. The system cannot have hostname resolution.
D. The system has the wrong subnet mask.
4. Which of the following bits of IP information are mandatory to join the network? (Choose two.)
A. Subnet mask
B. IP address
C. DNS address
D. Default gateway
Cram Quiz Answers
1. A. Although many routes can be built dynamically, it is often necessary to add the first
routes when installing/replacing a router. You can use the ip route command on most Cisco routers to do this from the command line.
2. C. The default gateway enables the system to communicate with systems on a remote network, without the need for explicit routes to be defined. The default gateway can be assigned automatically using a DHCP server or can be input manually.
3. B. The IP addresses of the client system and the default gateway are the same. This error probably occurred when the IP address information was input. In this configuration, the client system would likely access the local network and resources but not remote networks because the gateway address to remote networks is wrong. The DNS, IP, and subnet mask settings are correct.
4. A, B. Configuring a client requires at least the IP address and a subnet mask. The default gateway, DNS server, and WINS server are all optional, but network functionality is limited without them.
What’s Next?
Congratulations! You finished the reading and are now familiar with all the objectives on the Network+ exam. You are now ready for the practice exams. There are two 100 multiple-choice question exams to help you determine how prepared you are for the actual exam and which topics you need to review further.