CompTIA Network+ Certification Study Guide part 54 pptx

CHAPTER 10: Network Management 516
FIGURE 10.16B
Sample PacketTrap Perspective
capture (Permission granted by
PacketTrap Perspective)
FIGURE 10.16C
Sample Event Viewer display
Self Test 517
FIGURE 10.16D
Sample diagram of a network
When planning and establishing your local policies and procedures 14.
you have to recognize that some state and/or federal regulations
might apply to your organization. You are working at the local
county hospital; which of the following regulations should your
organization need to be aware of?
A. HIPAA
B. Sarbanes-Oxley Act of 2002
C. ISO/IEC 27002:2005
D. All of the above
You have been delegated the responsibility of creating all of your 15.
network’s documentation. As you research this topic you find out
that you must create CM documentation. What types of CM docu-
mentation must you create?
A. Wiring schematics, physical/logical network diagrams, baselines,
policies, procedures, configurations, and regulations
B. Wiring schematics, physical/logical network diagrams, load bal-
ancing, policies, procedures, configurations, and cache engines
C. Wiring schematics, technical network diagrams, baselines, poli-
cies, procedures, configurations, and regulations
D. Building schematics, physical/logical network diagrams, base-
lines, policies, procedures, configurations, and regulations

CHAPTER 10: Network Management 518
SELF TEST QUICK ANSWER KEY
A1.
D2.
C3.
D4.
B5.
C6.
A7.
A8.
B9.
D10.
B11.
D12.
C13.
D14.
A 15.
519
CHAPTER 11
EXAM OBJECTIVES IN THIS CHAPTER
A TROUBLESHOOTING METHODOLOGY 520
THE OSI MODEL 525
WINDOWS TOOLS 529
LINUX TOOLS 553
NETWARE TOOLS 557
OTHER NETWORK TROUBLESHOOTING TOOLS 558
IMPORTANCE OF NETWORK DOCUMENTATION 561
INTRODUCTION
Throughout this exam guide, we’ve talked about the fundamentals of network
protocols and network operating systems. In this chapter, we’ll bring together

that knowledge to help you in troubleshooting any errors or problems that
occur on your network. We’ll begin by talking about the overall methodology
that you’ll use to troubleshoot a network. This begins with gathering infor-
mation about a problem to try to determine its cause. You’ll then use your
understanding of networking concepts as well as your knowledge of how
your particular network is configured, to isolate the point where the problem
is occurring. By eliminating points of failure in a systematic fashion, you
can eliminate trouble spots one by one, until you’ve located the cause of the
problem. Maintaining accurate documentation of the physical layout of your
network is essential for this process, as is having a firm grasp of the layers of
the Open Systems Interconnect (OSI) model and the devices that operate at
the various layers.
To help you in troubleshooting your network, there are many software
utilities for both the Windows and Linux operating systems that will assist
you in pinpointing the exact nature of a failure. You’ll start with tools that
will test basic network connectivity to determine if two computers can
communicate with each other in any way. You can then move onto more
Network Troubleshooting Tools
CHAPTER 11: Network Troubleshooting Tools 520
detailed tools that will show you every aspect about the path that a network
packet takes to travel from one computer to another, or to gather detailed
information about name resolution issues. You also have access to a wide
range of testers for physical network components such as network cables and
wall jacks. By combining a broad understanding of networking concepts with
specific knowledge of the different troubleshooting tools available to you,
you will be able to effectively troubleshoot any issues you might face when
administering a network.
A TROUBLESHOOTING METHODOLOGY
Before we talk about specific tools and utilities that you can use to trouble-
shoot your network, it’s important that you have an overall structure in place

that will help you perform that troubleshooting. Unfortunately, networking
technologies haven’t advanced to the point that a router will flash up an
error message like, “My default gateway is misconfigured, please correct
this.” Instead, it is up to you to determine what a problem is before you’ll be
able to go about fixing it. When you’re troubleshooting a problem relating to
network connectivity, you need to have an understanding of your network
as a whole so that you can determine where the trouble is occurring. One of
the key factors in network troubleshooting is isolating the issue to figure out
whether it’s being caused by a single workstation or cable, or if it’s a larger
issue affecting numerous users on your network.
You can break down the troubleshooting process into two major steps:
Gathering information
Analyzing the information you’ve gathered
Gathering Information About a Problem
To troubleshoot a problem, you first need to identify the problem. This
can be a challenge when you’re trying to gather information from different
users on your network, especially if you’re dealing with a situation where
you’re receiving reports of multiple problems at the same time. You need to
determine which component of your network is causing the issue; this can
be a physical component like a network cable, or a logical component like the
Internet Protocol (IP) configuration for a particular network interface card
(NIC). You’ll use the information you gather to determine which component
of your network has failed or is misconfigured.
A Troubleshooting Methodology 521
Your first step should be to gather information from your users about the
nature of the problem. Some questions you’ll probably want to ask include
the following:
1. What is the exact nature of the problem? Try to be as specific as
possible when making this determination. For example, you may
get a report that your users are unable to browse external hosts

on the Internet. To get a better understanding of the problem,
you need to determine if they have lost all physical connectivity
to the outside world, or if it’s only a specific application that
isn’t functioning. Your troubleshooting steps will be different if
a user can ping outside hosts, but not connect to a specific Web
server, versus not being able to connect to the outside world in
any way.
2. How many computers are affected by this problem? If the
issue is isolated to a single computer, it is likely that the cause
of the problem will be related to the computer itself. If it is
affecting all computers on a particular subnet or those connected
to a particular hub or switch, you can use this information to
help you in the troubleshooting process. You can probably tell
from this that your troubleshooting will be far more successful if
you have detailed information about your network’s physical
topology. Because of this, one of the most critical documents
you can have on hand when troubleshooting, is a network dia-
gram detailing the physical layout of your network. You should
also maintain some type of database containing the IP address
configuration of your routers, switches, servers, and worksta-
tions.
3. When did the problem begin to occur? More specifically, you
should find out what changed on the network when the issues
first began. If your users began to experience connectivity
issues after you installed a new router, your first step will be to
check the configuration of the router. Sometimes this can take
a certain amount of investigation, as you may not be aware
of everything that’s being administered or modified on a large
network. Your Internet Service Provider (ISP) might have made
some changes that you’re not aware of, which might be caus-

ing the connectivity failures.
CHAPTER 11: Network Troubleshooting Tools 522
Analyzing and Responding to a Problem
Now that you’ve collected information about the problem, you need to
analyze all of it to determine the cause. You should examine every layer
in the OSI model starting at Layer 1. Check your physical layer connec-
tivity, such as cables, patch panels, wall jacks, and hubs. Work your way
up to Layer 2, verifying that any switches or switch ports are configured
properly. At Layer 3 you’ll verify that your routers are configured and func-
tioning properly, and then move onto troubleshooting the actual application
itself at the transport layer and beyond. In almost all cases, it’s best to start
at the physical layer and work your way up so that you’re eliminating the
lowest common denominator as a potential issue before moving onto more
complex troubleshooting problems. If two computers aren’t communicating
simply because a cable is unplugged, you can save yourself quite a bit of time
by starting with the physical layer and working up from there.
You’ll then want to determine the proper troubleshooting tool to use.
We’ll spend the majority of this chapter talking about the different tools
available for your use, but as a rule you should start with basic connectivity
tools like ping, moving on to other tools once you’ve determined that basic
connectivity is in place. The reason we start with ping is because it is simple
to use and lets you determine at a glance if two nodes on your network are
able to communicate with each other at the most basic level. It also very
effectively slices the OSI model in half for you in terms of troubleshooting,
because ping operates at the network layer. For example, if you are able to
ping a remote host but you cannot File Transfer Protocol (FTP) to it, then
you know that the issue lies somewhere above the network layer, because
otherwise ping would not be successful. If the ping is unsuccessful, then you
know that the issue lies in the network, data link, or physical layers.
In Exercise 11.1, we’ll look at a common situation where you might use

that you’re troubleshooting a connectivity problem between Computer A,
with an IP address of 192.168.1.1 and subnet mask of 255.255.255.0,
and Computer B with an IP address of 192.168.2.5 and a subnet mask of
255.255.255.0 – this is illustrated in Figure 11.1. These two computers
FIGURE 11.1 Connectivity Diagram.
ping to investigate a connectivity problem between two computers. Let’s say
A Troubleshooting Methodology 523
were able to communicate with each other yesterday, but the two comput-
ers haven’t been able to connect because some changes were made on the
network.
EXERCISE 11.1 Troubleshooting a Connectivity Issue
Examine Figure 11.1. The two workstations depicted in the diagram are not
able to communicate. They were able to communicate yesterday, but some
changes have been made on the network and they are no longer able connect
to each other.
The first thing you should do is go to Computer A and check 1.
things out for yourself. Use Computer A to ping 192.168.2.5, the
IP address of Computer B, to confirm that the two computers are
unable to communicate.
If you don’t receive a response from Computer B, you need to 2.
isolate where the failure is taking place. So your next step is
to ping the loopback address, 127.0.0.1. You should remember
from that the loopback address is a virtual IP address that’s used
for troubleshooting the Transmission Control Protocol/Internet
Protocol (TCP/IP) installation on a local PC. If you are unable to
ping the loopback address, then TCP/IP is either not installed or has
become corrupted on the local computer. If this ping is successful,
the problem does not lie in the TCP/IP stack of Computer A.
Next, try pinging another machine on the same network segment 3.
as Computer A, such as 192.168.1.2. If you get a response from

another machine on the same segment, you know that your local
machine’s TCP/IP stack is functioning properly, and that Computer
A is able to connect to other computers on the same subnet – this
rules out a malfunctioning NIC or network cable at the physical
layer. Next, ping the default gateway for Computer A to determine
if the default gateway is functioning.
If your default gateway responds, try pinging another host on 4.
the same network segment as Computer B, the computer that’s
failing to respond. If you get a response from another computer
on Computer B’s network segment, you know that there are no
problems related to Computer B’s network segment itself.
If all of your tests thus far have been successful, but you are still 5.
unable to contact Computer B, then you have isolated the problem to
CHAPTER 11: Network Troubleshooting Tools 524
Computer B itself. Perhaps the network cable connecting Computer
B to the network has gone bad, its network card has failed or needs a
new driver installed or its IP configuration is incorrect.
By approaching the problem systematically, you were able to trace the
network connectivity from one end of the path (Computer A) to the other
(Computer B). Testing at each step of the journey allowed you to isolate
exactly where the problem was occurring.
CONFIGURING AND IMPLEMENTING
Prioritizing Multiple Issues
Sometimes, you’ll encounter a troubleshooting situ-
ation where you have several problems happening
all at once. In fact, this is not uncommon because
multiple problems will often be created by the same
root cause. When multiple problems occur simulta-
neously, it’s important to focus on the problem that
has the greatest impact on users. For example, if

some of your users are reporting a complete inability
to access any resources, and others are reporting
that their network access is only slightly slow, the
two problems may or may not be related. You should
troubleshoot the computers that are experiencing a
total lack of network access first, because restoring
network connectivity is more critical than removing
the occasional occurrence of lag on an otherwise
working connection.
Network Discovery
Now, in a perfect world you’ll be administering a network that someone
has already created detailed configuration diagrams for, so that you’ll know
exactly what you’re working with when you need to troubleshoot a problem.
In reality, though, we’re usually not that lucky, and network administrators
often find themselves taking over networks that have little or no documen-
tation in place, or documentation that hasn’t been kept up to date. Luckily,
there are a number of tools that you can use to perform network discovery,
which will help you to automatically generate documentation about the
devices on your network and how they are configured. These network dis-
covery tools will examine a single IP address or an entire subnet and gather
as much information about the devices on that subnet as possible, including
their IP addresses, Media Access Control (MAC) addresses, what type of
operating system the device is running, and even what types of applications
are installed on the device if it is a server or a workstation computer.
There are a number of products available that will perform network dis-
covery for you, though the majority of them are paid commercial software and
The OSI Model 525
are not available as free downloads. One such product is Lan MapShot from
Fluke Networks and another suite of tools is from SolarWinds that includes
an IP Network Browser to perform automatic network discovery, as shown in

Figure 11.2. If you are taking over a network that has poor or nonexistent net-
work documentation in place, it’s strongly advisable to invest in one of these
network discovery tools; the amount of time it will save you in troubleshoot-
ing network connectivity issues will more than pay for the cost of the tool.
THE OSI MODEL
As you have learned, the OSI model creates a framework that defines how
networking protocols like TCP/IP communicate. Network packets are passed
from the physical layer up to the application layer, with each layer adding its
FIGURE 11.2 SolarWinds IP Network Browser.