CompTIA Network+ N10-008 Exam: Basics of Network Troubleshooting

This guide covers the following official Network+ objectives:
- Explain the network troubleshooting methodology.
- Given a scenario, use the appropriate network software tools and commands.
- Given a scenario, troubleshoot general networking issues.

Topics:
Troubleshooting Steps and Procedures
Identify the Problem
Identify Symptoms
Determine Whether Anything Has Changed
Duplicate the Problem if Possible
Approach Multiple Problems Individually
Establish a Theory of Probable Cause
Test the Theory to Determine the Cause
Establish a Plan of Action
Implement the Solution or Escalate
Determine Whether Escalation Is Necessary
Verify Full System Functionality
Document Findings, Actions, Outcomes, and Lessons
Software Troubleshooting Tools
Wi-Fi Analyzer
Protocol Analyzer
Bandwidth Speed Tester
Port Scanner
iperf
NetFlow Analyzer
TFTP Server
Terminal Emulator
IP Scanner
Command-Line Tools
The Trace Route Utility (tracert/traceroute)
ping
The Destination Host Unreachable Message
The Request Timed Out Message
The Unknown Host Message
The Expired TTL Message
Troubleshooting with ping
hostname
ARP
arp ping
The netstat Command
netstat -e
netstat -a
netstat -r
netstat -s
telnet
ipconfig
ifconfig
nslookup
dig
The tcpdump Command
The route Utility
nmap
Basic Network Platform Commands
Troubleshooting General Networking Issues
Common Considerations
Common Problems to Be Aware Of
Collisions
Broadcast Storm
Multicast Flooding
Asymmetrical Routing
Switching Loops
Routing Loops
Missing Route
Low Optical Link Budget
Incorrect VLAN
DNS Issues
Incorrect Gateway
Incorrect Subnet Mask
Duplicate or Incorrect IP Address
Duplicate MAC Addresses
Expired IP Address
Rogue DHCP Server
Certificate Issues
NTP Issues/Incorrect Time
DHCP Scope Exhaustion
Blocked Ports, Services, or Addresses
Incorrect Firewall Settings
Incorrect ACL Settings
Unresponsive Service
BYOD Challenges
Licensed Feature Issues
Hardware Failure
Network Performance Issues

This guide covers CompTIA Network+ objectives 5.1, 5.3, 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. Therefore, network administrators and technicians must develop those troubleshooting skills.
This guide 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.

Tip:
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, actions, outcomes, and lessons learned.

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.
2. Gather information.
3. Question users.
4. Identify symptoms.
5. Determine if anything has changed.
6. Duplicate the problem, if possible.
7. Approach multiple problems individually.
8. Establish a theory of probable cause.
9. Question the obvious.
10. Consider multiple approaches:
11. Top-to-bottom/bottom-to-top OSI model.
12. Divide and conquer.
13. Test the theory to determine the cause: If the theory is confirmed, determine the next steps to resolve the problem.
14. If the theory is not confirmed, reestablish a new theory or escalate.
15. Establish a plan of action to resolve the problem and identify potential effects.
16. Implement the solution or escalate as necessary.
17. Verify full system functionality and, if applicable, implement preventive measures.
18. Document findings, actions, outcomes, and lessons learned.

Tip: You should expect questions asking you to identify the troubleshooting methodology 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 gathering information, 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.
Tip: 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.
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 (or an exhausted 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.

Duplicate the Problem if Possible
Every problem has a cause and determining the cause of a problem is key to preventing it from happening again with either this machine or another. One was to know that you have identified the cause is to be able to duplicate the problem. The sole reason for duplicating the problem should be to verify that you have, indeed, found the cause so that you can then take steps to make certain that cause never becomes an issue again. As an example, if the cause of the problem turns out to be a new patch for an application not working properly with a particular operating system, you will want to make sure that that patch/OS combination is not implemented again (steps to consider would include updating the OS, installing only some of the patch, and so on).

Approach Multiple Problems Individually
One of the toughest situations to tackle is having to deal with more than one problem (a particular workstation won’t load Application A, can’t print from Application B, and so on). When this is the case, the only way to be able to solve the problems is to address each one individually. Problems should be ranked in order of importance (based on criteria such as business necessity) and solved in that order.

Establish a Theory of Probable Cause
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 coworkers 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. Determining the correct cause of the problem might take a few tries.
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 the 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 you identify 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. Having this information 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.
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. At times like this, 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 Findings, Actions, Outcomes, and Lessons
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. The lessons learned can be just as important as 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, that person can easily be tracked down. Of course, documenting who 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.

Software Troubleshooting Tools
- Given a scenario, use the appropriate network software tools and commands.

1. What cross-platform tool is used for network performance measurement/tuning and can produce standardized performance measurements for any network?

2. What TCP/IP command can be used to troubleshoot DNS problems?

3. What is the Linux, macOS, and UNIX equivalent of the ipconfig command?

4. What utility is part of the TCP/IP suite and has the function of resolving IP addresses to MAC addresses?

Answers:

1. The iperf tool is used for network performance measurement/tuning and can produce standardized performance measurements for any network.

2. The nslookup command is a TCP/IP diagnostic tool used to troubleshoot DNS problems. On Linux, UNIX, and macOS systems, you can also use the dig command for the same purpose.

3. The ifconfig command is the Linux, macOS, and UNIX equivalent of the ipconfig command.

4. The function of arp is to resolve IP addresses to MAC addresses.

Remember that this objective begins with “Given a scenario.” This 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 guide. For the Network+ exam, you are required to have general knowledge of the software tools available and what they are designed to do.

Wi-Fi Analyzer
As the name implies, a Wi-Fi analyzer is used to identify Wi-Fi problems. It can be helpful in finding the ideal place for locating an access point or the ideal channel to use. Many software-based Wi-Fi analyzers are available, and some use the word scanner in place of analyzer. One good feature of most wireless survey tools is that they 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. They 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.

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 enables the administrator to view the network communication in English. From this communication, 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.
- Decode information: By capturing and decoding network traffic, administrators can see what exactly is going on with the network at a protocol level. This process helps find protocol errors as well as potential intruders.
Caution: Protocol analyzers enable administrators to examine the bandwidth that a particular protocol is using.

Bandwidth Speed Tester
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 allows 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.
Think of a looking-glass site as a graphical interface to routing-related information.

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.
“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.

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 ports, it is critical that administrators know which ports are open and potentially vulnerable. As mentioned, many tools and utilities are available for this purpose. 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:

ProtoLocal Address Foreign AddressState
TCP 0.0.0.0:135mike-PC:0LISTENING
TCP 0.0.0.0:10114 mike-PC:0LISTENING
TCP 0.0.0.0:10115 mike-PC:0LISTENING
TCP 0.0.0.0:20523 mike-PC:0LISTENING
TCP 0.0.0.0:20943 mike-PC:0LISTENING
TCP 0.0.0.0:49152 mike-PC:0LISTENING
TCP 0.0.0.0:49153 mike-PC:0LISTENING
TCP 0.0.0.0:49154 mike-PC:0LISTENING
TCP 0.0.0.0:49155 mike-PC:0LISTENING
TCP 0.0.0.0:49156 mike-PC:0LISTENING
TCP 0.0.0.0:49157 mike-PC:0LISTENING
TCP 127.0.0.1:5354mike-PC:0LISTENING
TCP 127.0.0.1:27015mike-PC:0LISTENING
TCP 127.0.0.1:27015mike-PC:49187 ESTABLISHED
TCP 127.0.0.1:49187mike-PC:27015 ESTABLISHED
TCP 192.168.0.100:49190 206.18.166.15:httpCLOSED
TCP 192.168.1.66:139 mike-PC:0LISTENING
TCP [::]:135mike-PC:0LISTENING
TCP [::]:445mike-PC:0LISTENING
TCP [::]:2869mike-PC:0LISTENING
TCP [::]:5357mike-PC:0LISTENING
TCP [::]:10115 mike-PC:0LISTENING
TCP [::]:20523 mike-PC:0LISTENING
TCP [::]:49152 mike-PC:0LISTENING
TCP [::]:49153 mike-PC:0LISTENING
TCP [::]:49154 mike-PC:0LISTENING
TCP [::]:49155 mike-PC:0LISTENING
TCP [::]:49156 mike-PC:0LISTENING
TCP [::]:49157 mike-PC:0LISTENING
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.
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.

iperf
The iperf tool is used for active measurements of the maximum achievable bandwidth and used for network tuning. It is open-source and cross-platform compatible and has become widely accepted thanks to its ability to produce standardized performance measurements for any network, enabling the comparison of similar numbers across all platforms.

NetFlow Analyzer
NetFlow is a proprietary Cisco protocol used for network flow analysis. A NetFlow analyzer is used to collect IP network traffic as it enters or exits an interface and can identify such values as the source and destination of traffic, class of service, and the causes of congestion. RFC 3954 (the NetFlow standard) does not specify a specific listening port and the most common port used by NetFlow is port 2055 (UDP), but other ports can also be used (such as 9555, 9995, 9025, and 9026).

TFTP Server
A Trivial File Transfer Protocol (TFTP) can be used to send files between servers and is finding new use today in applications uploading HTML pages on the HTTP server. The TFTP server uses port 69 by default.

Terminal Emulator
A terminal emulator is any software program that emulates a computer terminal. Most often, the terminal being emulated is that of a command-line window, though it need not be (if it is graphical, it is usually called a terminal window instead of a terminal emulator), allowing the running of command-line utilities. Those utilities can be running on the local machine or remotely through the use of Telnet (using port 23 and considered very insecure) or a similar utility.

IP Scanner
An IP scanner is any tool that can scan for IP addresses and related information. An administrator can use it to scan available ports, discover devices, and get detailed hardware and software information on workstations and servers to manage inventory.
Remember all of the software tools mentioned in the preceding sections. You will likely be given a scenario where you need to use the appropriate tool.

Command-Line Tools
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: Common TCP/IP Troubleshooting Tools and Their Purposes

The following sections look in more detail at these utilities and the output they produce.

Many of the utilities discussed in this guide 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.
Be prepared to identify what software tool to use in a given scenario. Remember, you might be able to use more than one tool. 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 below shows the traceroute command syntax used in various operating systems.
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: Trace Route Utility Commands

Be prepared to identify the IP tracing command syntax used with various operating systems for the exam. Review the table above for this information.
The traceroute command 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 roundtrip 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
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 percent, but device 8 might not be functioning at all. In any case, you can isolate the problem to just one or two devices.
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.
Although we have used the Windows tracert command to provide sample output in these sections, the output from traceroute on a UNIX, Linux, or macOS 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:

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
3 28 ms 27 ms 41 ms rc1wh-atm0-2-1.shawcable.net
5 41 ms 27 ms 27 ms rc2wt-pos1-0.wa.shawcable.net
6 55 ms 41 ms 27 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37]
8 55 ms 41 ms 28 ms gbr3-p40.st6wa.ip.att.net
[12.123.44.130]
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

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 guide, 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 you’re 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: ping Command Switches

You will likely be asked about ping, its switches, and how it can be used in a troubleshooting scenario.
The ping command 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, if the -t switch is used, 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.
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 message 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.
Ping statistics for 169.76.54.3:
Packets: Sent = 4, Received = 0, Lost = 4 (100%

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
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=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),
Minimum = 27ms, Maximum = 69ms, Average = 33ms
In this example, three packets were lost. If this command 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:
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.
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.

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.
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.
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.
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.
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.
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.

hostname
Sometimes all you really want to know is the hostname assigned to a particular host. When that is the case, you can use the hostname command to provide that information. It reports back the character string that refers to the name of the host the command was entered on.

The following example illustrates the command in action:
C:\> hostname
LOUIS1508

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.
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: arp Switches

arp ping
Earlier in this guide 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.
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.
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:  netstat Switches

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
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
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
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

telnet
The telnet utility is used for remote access to a host via the Telnet service. This utility was mentioned in previous chapters, and the same caveat that accompanies it there must be given here: because it is an older utility that lacks security features, it is highly recommended that it not be used and other utilities—such as SSH—which provide the same functionality be used in its place.

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. . . . . . . . . . : Thursday, January 28, 2021 6:00:54 AM
Lease Expires . . . . . . . . . . : Friday, January 29, 2021 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.

The Table below  lists some of the most common troubleshooting symptoms, along with where to look for clues about solving them in the ipconfig /all output.
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: Common Troubleshooting Symptoms that ipconfig Can Help Solve

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. They include the switches listed in the Table below.
ipconfig and its associated switches are widely used by network administrators and therefore should be expected to make an appearance on the exam.

TABLE: ipconfig Switches

Tip: The ipconfig /release and ipconfig /renew commands work only when your system is using DHCP.
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 macOS 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
The nslookup utility is 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 enables you to specify further queries. This is known as interactive mode.

TABLE: nslookup Switches

Instead of using interactive mode, you can execute nslookup requests directly at the command prompt.

The following sample 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: The dig command is used on a Linux, UNIX, or macOS 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 macOS 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. The figure below shows the output from a route print command on a Windows system.



The output from a route print command on a Windows system

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
the Table below. 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: Switches for the route Command in Windows

nmap
The nmap utility 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.

Basic Network Platform Commands
When you’re working with routers, one of the most useful troubleshooting command-line tools is show. This Cisco-based utility takes a plethora of options after it and can be used to view almost any variable or value. 

TABLE: Three Popular Options for the show Command

Know the three options for the command shown in the above Table for the Network+ exam.

Troubleshooting General Networking Issues
- Given a scenario, troubleshoot general networking issues.

1. What one, hard-coded 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.

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.
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 Considerations
There are a number of things to take into consideration when trying to troubleshoot a problem—mainly, whether you can isolate what you are trying to find and the extent of the issue. Five broad considerations are outlined in the table below.

TABLE: Common Considerations

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 other sections have looked at problems in particular areas, pay special attention to those that fall within this section as you study for the exam.

Collisions
Generally, as more systems are added to a network, the possibility for more collisions to occur increase, and the network becomes slower. The type of collision detection used (discussed in Chapter 3) can impact performance.

Broadcast Storm
When an abnormally high number of broadcast packets are sent across the network within a short period of time, this is known as a broadcast storm, and it can degrade network performance as switches become overwhelmed with trying to keep up with the flood of packets.

Multicast Flooding
Similar to broadcast storms, multicast flooding tends to be more prevalent on VLANs and occurs when a switch receives a multicast packet that has an IP address for a group it has not learned. Since the switch does not know what to do with it, the switch floods that packet out of all ports on the VLAN. Many switches have an option to disallow this behavior, and you configure them to only forward unregistered packets to ports on a VLAN that are connected to specific ports.

Asymmetrical Routing
When a packet travels from a source to a destination in one path and takes a different path when it returns to the source, it is known as asymmetrical routing. The biggest weakness to this is the risk that packets might not arrive in the right order.
The opposite of asymmetrical routing is symmetrical routing: the network uses a single route for incoming and outgoing packets.

Switching Loops
A switching loop can occur any time there are multiple paths between two endpoints: more than one connection between two switches, for example. When there is a loop, it creates broadcast storms as broadcasts and multicasts are forwarded by switches out every port (the switch[es] will repeatedly rebroadcast the messages, thus flooding the network). Layer 2 headers do not support a time to live (TTL) value, so a frame sent into a looped topology can loop forever.

Routing Loops
Similar to switching loops, a routing loop can go on forever. This typically is a problem when the routing tables contain cyclical entries. For example, suppose router A needs to send data to router C and believes the best way to get there is to forward it first to router B. Router B gets the data, sees it is for C, and has in its own table that the best way to get there is to go through router A. In this scenario, a loop is created that can go on forever, preventing the data from reaching its destination.

Missing Route
A missing route can also prevent data from reaching its destination. Often the cause can be broken topology, reliance on static routes, or misconfiguration of the routing protocol.

Low Optical Link Budget
While it may sound like a problem with the company’s comptroller, in reality, low optical link budget refers to the optical power budget in a fiber-optic communication link. This is the allocation of available optical power considering such factors as attenuation, splice losses, and connector losses.

Incorrect VLAN
While VLANs offer a plethora of positives, problems can occur when a user moves or gets connected to the wrong one. On a regular basis, an administrator should ensure that the user system is plugged into the correct VLAN port and that there are no problems with users connecting to an interface which is not assigned to them.

DNS Issues
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 the place 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.
Know the tools to use to test connectivity.

Incorrect Subnet Mask
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 or Incorrect 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, that address 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 hard-coded into the NIC and cannot be changed. It consists of two components: one identifies the vendor, and the other identifies 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.

The table below 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: Private Address Ranges

You need to know the private address ranges in the Table above.

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 up clients for network attacks, such as on-path/man-in-the-middle attack.

Certificate Issues
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.

NTP Issues/Incorrect Time
Incorrect time on a network can be more than just an annoyance because timestamps are important if you’re trying to document an attack. Most network devices use Network Time Protocol (NTP) to keep the system time as defined by a designated server. You should 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.

DHCP Scope Exhaustion
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 Ports, Services, or Addresses
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, you should 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 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 or 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, the reason could be that it is overloaded, is down, or has 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, you can look for a way to increase the capacity or balance the load. If the server/service is down, you can investigate why and what needs to be done to bring it back up again. If the server/service is misconfigured, you can make the necessary changes to configure it properly.

BYOD Challenges
Bring-your-own-device (BYOD) challenges occur when employees are allowed to bring personally owned mobile devices (laptops, tablets, and smartphones) to their workplace and use them on the network. Good onboarding and offboarding procedures (discussed in Chapter 8, “Network Operations”) as well as MDM policies should be used to help protect network resources and still allow these devices to be used in the workplace.

Licensed Feature Issues
Many devices, such as switches, have features that are available with them only if licensed. Many times, you can enable the feature and use it on a trial basis before purchasing (a grace period, if you will), but you must purchase and install the number of licenses required for that feature before the grace period ends or the feature will disable itself. To keep legal, you should always be cognizant of licensing issues and careful to not run afoul of them.

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: Common Network Hardware Components, Their Functions, and Troubleshooting Strategies

Be familiar with the devices listed in the table above and their failure signs.
For more information on network hardware devices and their functions, refer to, “Network Implementations.”

Network Performance Issues
This guide looked at many performance issues, and most of the issues discussed in this section already have been addressed as they relate to networking. Be aware of those issues and that it is always a balancing act trying to get optimum performance from a network when working with so many disparate devices.