questions

profileidrisniyi94
NetworkingEssentialsCompanionGuide.docx

Title: Networking Essentials Companion Guide

Author: Cisco Networking Academy

PUBLISHED BY: Cisco Press

PUBLICATION DATE: March 2022

PRINT LENGTH:544 pages

Chapter 20

Troubleshoot Common Network Problems

Objectives

Upon completion of this chapter, you will be able to answer the following questions:

· What are some of the approaches used to troubleshoot networks?

· What is the process of detecting physical layer problems?

· What network utilities can you use to troubleshoot networks?

· How do you troubleshoot a wireless network problem?

· What are some common Internet connectivity problems?

· What outside sources and Internet resources are available for troubleshooting?

Key Terms

There are no key terms in this chapter.

Introduction (20.0.1)

Congratulations! You‛ve made it to the final chapter in Networking Essentials. While learning about networking in this course, you‛ve likely developed skills you didn‛t even know you needed. Was the purpose of this whole course learning how to set up a simple network? Of course, network setup is important, but it‛s just part of your learning.

What do you do when your network doesn‛t work? This is your real test as a network administrator—to be able to figure out what is wrong, fix it, (and here‛s the tricky part) and not accidentally create a whole new problem. Get good at troubleshooting, and you will always be in demand.

The Troubleshooting Process (20.1)

Troubleshooting is the process of identifying, locating, and correcting problems. Experienced individuals often rely on instinct to troubleshoot. However, you can use structured techniques to determine the most probable cause and solution to problems.

Network Troubleshooting Overview (20.1.1)

When troubleshooting, you must maintain proper documentation. This documentation should include as much information as possible about the following:

· The problem encountered

· Steps taken to determine the cause of the problem

· Steps to correct the problem and ensure that it will not reoccur

You must document all steps taken in troubleshooting, even the ones that did not solve the issue. This documentation becomes a valuable reference should the same or a similar problem occur again. Even in a small home network, good documentation saves hours of trying to remember how a problem was fixed in the past.

Gather Information (20.1.2)

When a problem is first discovered in the network, it is important to verify the problem and determine how much of the network is affected by it. After the problem is confirmed, the first step in troubleshooting is to gather information. The following checklist provides some of the important information you should check:

· Nature of Problem

· End-user reports

· Problem verification report

· Equipment

· Manufacturer

· Make/model

· Firmware version

· Operating system version

· Ownership/warranty information

· Configuration and Topology

· Physical and logical topology

· Configuration files

· Log files

· Previous Troubleshooting

· Steps taken

· Results achieved

One of the first ways to gather information is to question the individual who reported the problem, as well as any other affected users. Questions can include end-user experiences, observed symptoms, error messages, and information about recent configuration changes to devices or applications.

Next, collect information about any equipment that may be affected. This information can be gathered from documentation. A copy of all log files and a listing of any recent changes made to equipment configurations are also necessary. Log files are generated by the equipment itself and can usually be obtained through the management software. Other information on the equipment includes the manufacturer, make, and model of devices affected, as well as ownership and warranty information. The version of any firmware or software on the device is also important because there may be compatibility problems with particular hardware platforms.

Information about the network can also be gathered using network monitoring tools. These tools are complex applications often used on large networks to continually gather information about the state of the network and network devices. They may not be available for smaller networks.

After all necessary information is gathered, you start the troubleshooting process.

Structured Troubleshooting Methods (20.1.3)

Several structured troubleshooting approaches can be used. Which one you use depends on the situation. Each approach has its advantages and disadvantages. Here, you‛ll learn methods and guidelines for choosing the best method for a specific situation.

Bottom-Up

In bottom-up troubleshooting, you start with the physical layer and the physical components of the network, as shown in Figure 20-1, and move up through the layers of the OSI model until the cause of the problem is identified.

Figure 20-1 Bottom-Up Troubleshooting

Bottom-up troubleshooting is a good approach to use when the problem is suspected to be a physical one. Most networking problems reside at the lower levels, so implementing the bottom-up approach is often effective.

The disadvantage with the bottom-up troubleshooting approach is that it requires you to check every device and interface on the network until the possible cause of the problem is found. Remember that each conclusion and possibility must be documented, so a lot of paperwork can be associated with this approach. A further challenge is to determine which devices to start examining first.

Top-Down

As shown in Figure 20-2, top-down troubleshooting starts with the end-user applications and moves down through the layers of the OSI model until the cause of the problem has been identified.

Figure 20-2 Top-Down Troubleshooting

End-user applications of an end system are tested before tackling the more specific networking pieces. You can use this approach for simpler problems or when you think the problem is with a piece of software.

The disadvantage with the top-down approach is it requires you to check every network application until the possible cause of the problem is found. Each conclusion and possibility must be documented. The challenge is to determine which application to start examining first.

Divide-and-Conquer

Figure 20-3 shows the divide-and-conquer approach to troubleshooting a networking problem. As network administrator, you select a layer and test in both directions from that layer.

Figure 20-3 Divide-and-Conquer Troubleshooting

In divide-and-conquer troubleshooting, you start by collecting user experiences of the problem, document the symptoms, and then using that information, make an informed guess as to which OSI layer to start your investigation. When a layer is verified to be functioning properly, it can be assumed that the layers below it are functioning. You can work up the OSI layers. If an OSI layer is not functioning properly, you can work down the OSI layer model.

For example, if users cannot access the web server but can ping the server, the problem is above Layer 3. If pinging the server is unsuccessful, the problem is likely at a lower OSI layer.

Follow-the-Path

Follow-the-path is one of the most basic troubleshooting techniques. The approach first discovers the traffic path all the way from source to destination. The scope of troubleshooting is reduced to just the links and devices that are in the forwarding path. The objective is to eliminate the links and devices that are irrelevant to the troubleshooting task at hand. This approach usually complements one of the other approaches.

Substitution

The substitution approach is also called swap-the-component because you physically swap the problematic device with a known, working one. If the problem is fixed, the problem is with the removed device. If the problem remains, the cause may be elsewhere.

In specific situations, this can be an ideal method for quick problem resolution, such as with a critical single point of failure. For example, a border router goes down. In this case, simply replacing the device and restoring service may be more beneficial than troubleshooting the issue.

If the problem lies within multiple devices, you might not be able to correctly isolate the problem.

Comparison

The comparison approach, also called the spot-the-differences approach, attempts to resolve a problem by changing the nonoperational elements to be consistent with the working ones. You compare configurations, software versions, hardware, or other device properties, links, or processes between working and nonworking situations and spot significant differences between them.

The weakness of this method is that it might lead to a working solution without clearly revealing the root cause of the problem.

Educated Guess

The educated guess approach is also called the shoot-from-the-hip troubleshooting approach. This less-structured troubleshooting method uses an educated guess based on the symptoms of the problem. Success of this method varies based on your troubleshooting experience and ability. Seasoned technicians are more successful because they can rely on their extensive knowledge and experience to decisively isolate and solve network issues. With less-experienced network administrators, this troubleshooting method might be too random to be effective.

Guidelines for Selecting a Troubleshooting Method (20.1.4)

To quickly resolve network problems, take the time to select the most effective network troubleshooting method. Figure 20-4 illustrates the methods that could be used when certain types of problem are discovered.

Figure 20-4 Selecting a Troubleshooting Method

For instance, software problems are often solved using a top-down approach, whereas hardware-based problems are solved using the bottom-up approach. New problems may be solved by an experienced technician using the divide-and-conquer method. Otherwise, the bottom-up approach may be used.

Troubleshooting is a skill that you develop by doing it. Every network problem you identify and solve adds to your skill set.

Physical Layer Problems (20.2)

A large proportion of networking problems are related to physical components or problems with the physical layer. Physical problems are concerned mainly with the hardware aspects of computers and networking devices, and the cables that interconnect them. Physical problems do not include the logical (software) configuration of devices.

Common Layer 1 Problems (20.2.1)

Remember, the physical layer (Layer 1) deals with the physical connectivity of the network devices. Some of the more common Layer 1 problems include the following:

· Device power turned off

· Device power unplugged

· Loose network cable connection

· Incorrect cable type

· Faulty network cable

· Faulty wireless access point (AP)

To troubleshoot at Layer 1, you first check that all devices have the proper power supplied and that the devices are turned on. This solution might seem to be obvious, but many times the person reporting the problem may overlook a device that is within the network path from source to destination. Then you ensure that no errors show on any LEDs that display the connectivity status. If you‛re on site, visually inspect all network cabling and reconnect cables to ensure a proper connection. If the problem is with wireless, verify that the wireless access point is operational and that wireless settings are configured correctly.

The Sense of Sight

Vision is used to detect problems such as improperly connected or poorly constructed cables:

· Cables that are not connected

· Cables connected to the wrong port

· Loose cable connections

· Damaged cables and connectors

· Use of the wrong type of cable

Vision also enables you to view the condition and function of various network devices with LEDs.

The Senses of Smell and Taste

Smell can alert you to components that are overheating when you‛re troubleshooting. The smell of burning insulation or components is distinct and is a sure sign that something is seriously wrong.

The sense of taste is directly related to the sense of smell because both use the same receptors. You may also taste the acridness of something burning.

The Sense of Touch

When troubleshooting, you can use touch to feel for overheated components as well as to detect mechanical problems with devices such as cooling fans. These devices usually create a small vibration in the component that can be detected using touch. The absence of this vibration or the presence of excessive amounts of vibration can indicate that the cooling fan has failed or is about to do so.

The Sense of Hearing

Hearing is used to detect major problems such as electrical issues and the proper operation of cooling fans and disk drives. All devices have characteristic sounds, and any change from the normal sounds usually indicates a problem of some sort.

Wireless Router LEDs (20.2.2)

Regardless of whether the fault is present on a wireless or wired network, one of the first steps in a bottom-up strategy of troubleshooting should be to examine the LEDs, which indicate the current state or activity of a piece of equipment or connection. LEDs may change color or flash to convey information. The exact configuration and meaning of LEDs varies between manufacturers and devices. Figure 20-5 shows a typical wireless router with LEDs indicating power, system, WLAN, wired ports, and Internet (labeled WAN), USB, and Quick Security Setup (QSS, also known as Wi-Fi Protected Setup [WPS]).

Figure 20-5 LED Lights on a Wireless Router

Note

WPS (or QSS) has known vulnerabilities that allow a threat actor to gain access to your network. Therefore, a security best practice is to disable this feature. Refer to documentation to learn how to disable WPS or QSS.

On some devices, a single LED may convey multiple pieces of information, depending on the current status of the device. It is important to check the equipment documentation for the exact meaning of all indicators, but some commonality does exist.

Most devices have activity LEDs, which are often called link lights. A normal condition is for these LEDs to flash, indicating that traffic is flowing through the port. A solid green light typically indicates that a device is plugged into the port, but no traffic is flowing. No light typically indicates one or more of the following:

· Nothing is plugged into the port.

· There is an issue with the wired or wireless connection.

· A device or port has failed.

· There is a cabling issue.

· The wireless router is improperly configured; for example, a port was administratively shut down.

· The wireless router has a hardware fault.

· The device does not have power.

Whether the network is wired or wireless, you should verify that the device and ports are up and functional before spending large amounts of time trying to troubleshoot other issues.

Cabling Problems (20.2.3)

If the wired client is unable to connect to the wireless router, one of the first things to check is the physical connectivity and cabling. Cabling is the central nervous system of wired networks and one of the most common issues when experiencing inactivity.

There are several issues to watch for when cabling:

· Be sure to use the correct type of cable. Two types of UTP cables are commonly encountered in networking: straight-through cables and crossover cables. Using the wrong type of cable may prevent connectivity.

· Improper cable termination is one of the main problems encountered in networks. To avoid this problem, you should terminate cables according to standards. Terminate all cables on the same network via the T568A or the T568B termination standard, not both. Avoid untwisting too much of the wire pairs during termination. Crimp connectors on the cable jacket to provide strain relief.

· Maximum cable run lengths exist based on characteristics of the different cables. Exceeding these run lengths can have a serious negative impact on network performance.

· If connectivity is a problem, verify that the correct ports are being used between the networking devices.

· Protect cables and connectors from physical damage. Support cables to prevent strain on connectors and run cable through areas that will not be in the way.

Troubleshooting Commands (20.3)

A number of software utility programs can help identify network problems.

Overview of Troubleshooting Commands (20.3.1)

Most of these utilities are provided by the operating system as CLI commands. The syntax for the commands may vary between operating systems.

Some of the available utilities include

· ipconfig—Displays IP configuration information

· ping—Tests connections to other IP hosts

· netstat—Displays network connections

· tracert—Displays the route taken to the destination

· nslookup—Directly queries the name server for information on a destination domain

The ipconfig Command (20.3.2)

When a device does not get an IP address or has an incorrect IP configuration, it cannot communicate on the network or access the Internet. On Windows devices, you can view the IP configuration information with the ipconfig command at the command prompt. The ipconfig command has several helpful options, including /all, /release, and /renew.

The ipconfig command, shown in Example 20-1, is used to display the current IP configuration information for a host. Issuing this command from the command prompt displays the basic configuration information, including IP address, subnet mask, and default gateway.

Click here to view code image

Example 20-1 The ipconfig Command

C:\> ipconfig
Windows IP Configuration
Ethernet adapter Ethernet:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix .  :
Wireless LAN adapter Wi-Fi:
   Connection-specific DNS Suffix .  : lan
   Link-local IPv6 Address . . . . . : fe80::a1cc:4239:d3ab:2675%6
   IPv4 Address. . . . . . . . . . . : 10.10.10.130
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.10.10.1
C:\>

The ipconfig /all command, shown in Example 20-2, displays additional information, including the MAC address, IP addresses of the default gateway, and the DNS servers. It also indicates whether DHCP is enabled, the DHCP server address, and lease information.

Click here to view code image

Example 20-2 The ipconfig /all Command

C:\> ipconfig/all
Windows IP Configuration
   
   Host Name . . . . . . . . . . . . : your-a9270112e3
   Primary Dns Suffix . . . . . . .  :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : lan
Ethernet adapter Ethernet:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix .  :
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : 00-16-D4-02-5A-EC
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
Wireless LAN adapter Wi-Fi:
   Connection-specific DNS Suffix .  : lan
   Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 3165
   Physical Address. . . . . . . . . : 00-13-02-47-8C-6A
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::a1cc:4239:d3ab:2675%6(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.10.130(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Wednesday, September 2, 2020 10:03:43 PM
   Lease Expires . . . . . . . . . . : Friday, September 11, 2020 10:23:36 AM
   Default Gateway . . . . . . . . . : 10.10.10.1
   DHCP Server . . . . . . . . . . . : 10.10.10.1
   DHCPv6 IAID . . . . . . . . . . . : 98604135
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1E-21-A5-84-44-A8-42-FC-0D-6F
   DNS Servers . . . . . . . . . . . : 10.10.10.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
C:\>

How can this utility assist in the troubleshooting process? Without an appropriate IP configuration, a host cannot participate in communications on a network. If the host does not know the location of the DNS servers, it cannot translate names into IP addresses.

If IP addressing information is assigned dynamically, the ipconfig /release command, shown in Example 20-3, releases the current DHCP bindings. The ipconfig /renew command requests fresh configuration information from the DHCP server. A host may contain faulty or outdated IP configuration information, and a simple renewal of this information is all that is required to regain connectivity.

Click here to view code image

Example 20-3 The ipconfig/release and ipconfig/renew Commands

C:\> ipconfig/release
Windows IP Configuration
No operation can be performed on Ethernet while it has its media disconnected.
Ethernet adapter Ethernet:
   
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix .  :
Wireless LAN adapter Wi-Fi:
   Connection-specific DNS Suffix .  :
   Link-local IPv6 Address . . . . . : fe80::a1cc:4239:d3ab:2675%6
   Default Gateway . . . . . . . . . :
C:\> ipconfig/renew
Windows IP Configuration
No operation can be performed on Ethernet while it has its media disconnected.
Ethernet adapter Ethernet:
   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix .  :
Wireless LAN adapter Wi-Fi:
   Connection-specific DNS Suffix .  : lan
   Link-local IPv6 Address . . . . . : fe80::a1cc:4239:d3ab:2675%6
   IPv4 Address. . . . . . . . . . . : 10.10.10.130
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.10.10.1
C:\>

If, after releasing the IP configuration, the host is unable to obtain fresh information from the DHCP server, it could be that there is no network connectivity. In this case, you verify that the NIC has an illuminated link light, indicating that it has a physical connection to the network. If this does not solve the problem, the DHCP server or network connections to the DHCP server may be the issue.

Packet Tracer—Use the ipconfig Command (20.3.3)

In this activity, you will use the ipconfig command to examine IP configuration information on a host.

The ping Command (20.3.4)

Probably the most commonly used network utility is ping. Most IP-enabled devices support some form of the ping command to test whether network devices can be reached through the IP network.

If the IP configuration appears to be correctly configured on the local host, next, you can test network connectivity by using ping. The ping command can be followed by either an IP address or the name of a destination host. In Example 20-4, the user pings the default gateway at 10.10.10.1 and then pings www.cisco.com.

Click here to view code image

Example 20-4 The ping Command

C:\> ping 10.10.10.1
Pinging 10.10.10.1 with 32 bytes of data:
Reply from 10.10.10.1: bytes=32 time=1ms TTL=64
Reply from 10.10.10.1: bytes=32 time=1ms TTL=64
Reply from 10.10.10.1: bytes=32 time=1ms TTL=64
Reply from 10.10.10.1: bytes=32 time=1ms TTL=64
Ping statistics for 10.10.10.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms
C:\> ping www.cisco.com
Pinging e2867.dsca.akamaiedge.net [104.112.72.241] with 32 bytes of data:
Reply from 104.112.72.241: bytes=32 time=25ms TTL=53
Reply from 104.112.72.241: bytes=32 time=25ms TTL=53
Reply from 104.112.72.241: bytes=32 time=27ms TTL=53
Reply from 104.112.72.241: bytes=32 time=24ms TTL=53
Ping statistics for 104.112.72.241:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 24ms, Maximum = 27ms, Average = 25ms
C:\>

When a ping is sent to an IP address, a packet known as an echo request is sent across the network to the IP address specified. If the destination host receives the echo request, it responds with a packet known as an echo reply. If the source receives the echo reply, connectivity is verified by the reply from the specific IP address. The ping is not successful if a message such as request timed out or general failure appears.

If a ping command is sent to a name, such as www.cisco.com, a packet is first sent to a DNS server to resolve the name to an IP address. After the IP address is obtained, the echo request is forwarded to the IP address and the process proceeds. If a ping to the IP address succeeds but a ping to the name does not, there is most likely a problem with DNS.

Ping Results (20.3.5)

If ping commands to both the name and IP address are successful but the user is still unable to access the application, the problem most likely resides in the application on the destination host. For example, the requested service might not be running.

If neither ping is successful, network connectivity along the path to the destination is most likely the problem. If this occurs, it is common practice to ping the default gateway. If the ping to the default gateway is successful, the problem is not local. If the ping to the default gateway fails, the problem resides on the local network.

In some cases, the ping may fail, but network connectivity is not the problem. A ping may fail due to the firewall on the sending or receiving device, or a router along the path that is blocking the pings.

The basic ping command usually issues four echoes and waits for the replies to each one. It can, however, be modified to increase its usefulness. The options listed in Example 20-5 display additional features available.

Click here to view code image

Example 20-5 Options for the ping Command

C:\> ping
Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
             [-r count] [-s count] [[-j host-list] | [-k host-list]]
             [-w timeout] [-R] [-S srcaddr] [-c compartment] [-p]
             [-4] [-6] target_name
Options:
    -t                  Ping the specified host until stopped.
                        To see statistics and continue - type Control-Break;
                        To stop - type Control-C.
    -a                  Resolve addresses to hostnames.
    -n                  count Number of echo requests to send.
    -l                  size Send buffer size.
    -f                  Set Don't Fragment flag in packet (IPv4-only).
    -i                  TTL Time To Live.
    -v                  TOS Type Of Service (IPv4-only. This setting has been deprecated
                        and has no effect on the type of service field in the IP
                        Header).
    -r                  count Record route for count hops (IPv4-only).
    -s                  count Timestamp for count hops (IPv4-only).
    -j host-list        Loose source route along host-list (IPv4-only).
    -k host-list        Strict source route along host-list (IPv4-only).
    -w timeout          Timeout in milliseconds to wait for each reply.
    -R                  Use routing header to test reverse route also (IPv6-only).
                        Per RFC 5095 the use of this routing header has been
                        deprecated. Some systems may drop echo requests if
                        this header is used.
    -S srcaddr          Source address to use.
    -c compartment    Routing compartment identifier.
    -p                  Ping a Hyper-V Network Virtualization provider address.
    -4                  Force using IPv4.
    -6                  Force using IPv6.
C:\>

Packet Tracer—Use the ping Command (20.3.6)

In this activity, you will use the ping command to examine end-to-end connectivity between hosts.

Divide and Conquer with ping (20.3.7)

Connectivity problems occur on wireless networks, wired networks, and networks that use both. When you‛re troubleshooting a network with both wired and wireless connections, it is often best to troubleshoot using a divide-and-conquer technique to isolate the problem to either the wired or wireless network. The easiest way to determine if the problem is with the wired or wireless network is to do the following:

· Ping from a wireless client to the default gateway. This verifies whether the wireless client is connecting as expected.

· Ping from a wired client to the default gateway. This verifies whether the wired client is connecting as expected.

· Ping from the wireless client to a wired client. This verifies whether the wireless router is functioning as expected.

After the problem is isolated, it can be corrected.

The tracert Command (20.3.8)

Although ping is the most commonly used network troubleshooting command, other useful commands are available on Windows devices.

The ping command can verify end-to-end connectivity. However, if a problem exists and the device cannot ping the destination, the ping command does not indicate where the connection was really dropped. To find this dropped connection, you must use another command known as traceroute or tracert. Microsoft Windows uses the tracert command, whereas other operating systems commonly use the traceroute command.

The tracert utility provides connectivity information about the path a packet takes to reach the destination and about every router (hop) along the way. It also indicates how long a packet takes to get from the source to each hop and back (round-trip time). The tracert utility can help identify where a packet may have been lost or delayed due to bottlenecks or slowdowns in the network.

In Example 20-6, the user traces the path to Cisco. The path is unique to this user. Your path will have a different listing of hops and may be shorter or longer (number of hops).

Click here to view code image

Example 20-6 Tracing a Route to Cisco

C:\> tracert www.cisco.com
Tracing route to e2867.dsca.someispedge.net [104.95.63.78]
over a maximum of 30 hops:
   1     1 ms      1 ms    <1 ms 10.10.10.1
   2     *         *       *      Request timed out.
   3     8 ms      8 ms    8 ms  24-155-250-94.dyn.yourisp.net [172.30.250.94]
   4    22 ms     23 ms   23 ms  24-155-121-218.static.yourisp.net
   [172.30.121.218]
   5    23 ms     24 ms   25 ms  dls-b22-link.anotherisp.net [64.0.70.170]
   6    25 ms     24 ms   25 ms  dls-b23-link.anotherisp.net [192.168.137.106]
   7    24 ms     23 ms   21 ms  someisp-ic-341035-dls-b1.c.anotherisp.net
   [192.168.169.47]
   8    25 ms     24 ms   23 ms  ae3.databank-dfw5.netarch.someisp.com
   [10.250.230.195]
   9    25 ms     24 ms   24 ms  a104-95-63-78.deploy.static.someisptechnologies.
   com [104.95.63.78]
Trace complete.
C:\>

Note

In the output of Example 20-6, notice that the second hop failed. The reason is most likely due to a firewall configuration on that device that does not permit responding packets from the tracert command. However, the device does forward the packets to the next hop.

The basic tracert command allows only up to 30 hops between a source and destination device before it assumes that the destination is unreachable. This number can be adjusted by using the -h parameter. Other modifiers, displayed as options in Example 20-7, are also available.

Click here to view code image

Example 20-7 The Options for the tracert Command

C:\> tracert
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout]
               [-R] [-S srcaddr] [-4] [-6] target_name
Options:
    -d                  Do not resolve addresses to hostnames.
    -h maximum_hops     Maximum number of hops to search for target.
    -j host-list        Loose source route along host-list (IPv4-only).
    -w timeout          Wait timeout milliseconds for each reply.
    -R                  Trace round-trip path (IPv6-only).
    -S srcaddr          Source address to use (IPv6-only).
    -4                  Force using IPv4.
    -6                  Force using IPv6.
C:\>
The netstat Command (20.3.9)

Sometimes you need to know which active TCP connections are open and running on a networked host. The netstat command is an important network utility that you can use to verify those connections. As shown in Example 20-8, the netstat command lists the protocol in use, the local address and port number, the foreign address and port number, and the state of the connection.

Click here to view code image

Example 20-8 The netstat Command

C:\> netstat
Active Connections
  Proto  Local Address         Foreign Address         State
  TCP    10.10.10.130:58520    dfw28s01-in-f14:https   ESTABLISHED
  TCP    10.10.10.130:58522    dfw25s25-in-f14:https   ESTABLISHED
  TCP    10.10.10.130:58523    dfw25s25-in-f14:https   ESTABLISHED
  TCP    10.10.10.130:58525    ec2-3-13-132-189:https  ESTABLISHED
  TCP    10.10.10.130:58579    203.104.160.12:https    ESTABLISHED
  TCP    10.10.10.130:58580    104.16.249.249:https    ESTABLISHED
  TCP    10.10.10.130:58624    52.242.211.89:https     ESTABLISHED
  TCP    10.10.10.130:58628    24-155-92-110:https     ESTABLISHED
  TCP    10.10.10.130:58651    ec2-18-211-133-65:https ESTABLISHED
  TCP    10.10.10.130:58686    do-33:https             ESTABLISHED
  TCP    10.10.10.130:58720    172.253.119.189:https   ESTABLISHED
  TCP    10.10.10.130:58751    ec2-35-170-0-145:https  ESTABLISHED
  TCP    10.10.10.130:58753    ec2-44-224-80-214:https ESTABLISHED
  TCP    10.10.10.130:58755    a23-65-237-228:https    ESTABLISHED
C:\>

Unexplained TCP connections can pose a major security threat because they can indicate that something or someone is connected to the local host. Additionally, unnecessary TCP connections can consume valuable system resources, thus slowing down the performance of the host. netstat should be used to examine the open connections on a host when performance appears to be compromised.

Many useful options are available for the netstat command. You can view these options by typing netstat /? at the command prompt, as shown in Example 20-9.

Click here to view code image

Example 20-9 Options for the netstat Command

C:\> netstat /?
Displays protocol statistics and current TCP/IP network connections.
NETSTAT [-a] [-b] [-e] [-f] [-n] [-o] [-p proto] [-r] [-s] [-t] [-x] [-y]
    [interval]
   
    -a           Displays all connections and listening ports.
    -b           Displays the executable involved in creating each connection or
                 listening port. In some cases well-known executables host
                 multiple independent components, and in these cases the
                 sequence of components involved in creating the connection
                 or listening port is displayed. In this case the executable
                 name is in [] at the bottom, on top is the component it called,
                 and so forth until TCP/IP was reached. Note that this option
                 can be time-consuming and will fail unless you have sufficient
                 permissions.
    -e           Displays Ethernet statistics. This may be combined with the -s
                 option.
    -f           Displays Fully Qualified Domain Names (FQDN) for foreign
                 addresses.
    -n           Displays addresses and port numbers in numerical form.
    -o           Displays the owning process ID associated with each connection.
    -p proto     Shows connections for the protocol specified by proto; proto
                 may be any of: TCP, UDP, TCPv6, or UDPv6. If used with the -s
                 option to display per-protocol statistics, proto may be any of:
                 IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, or UDPv6.
    -q           Displays all connections, listening ports, and bound
                 nonlistening TCP ports. Bound nonlistening ports may or may not
                 be associated with an active connection.
    -r           Displays the routing table.
    -s           Displays per-protocol statistics. By default, statistics are
                 shown for IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP, and UDPv6;
                 the -p option may be used to specify a subset of the default.
    -t           Displays the current connection offload state.
    -x           Displays NetworkDirect connections, listeners, and shared
                 endpoints.
    -y           Displays the TCP connection template for all connections.
                 Cannot be combined with the other options.
    interval     Redisplays selected statistics, pausing interval seconds
                 between each display. Press CTRL+C to stop redisplaying
                 statistics. If omitted, netstat will print the current
                 configuration information once.
C:\>
The nslookup Command (20.3.10)

When a network device is being configured, one or more DNS server addresses are provided that the DNS client can use for name resolution. Usually, the ISP provides the addresses to use for the DNS servers. When a user application requests to connect to a remote device by name, the requesting DNS client queries the name server to resolve the name to a numeric address.

Computer operating systems also have a utility called nslookup that enables you to manually query the name servers to resolve a given host name. This utility can also be used to troubleshoot name resolution issues and to verify the current status of the name servers.

In Example 20-10, when the nslookup command is issued, the default DNS server configured for your host is displayed. The name of a host or domain can be entered at the nslookup prompt. The nslookup utility has many options available for extensive testing and verification of the DNS process.

Click here to view code image

Example 20-10 Looking Up Cisco Information with the nslookup Command

C:\Users> nslookup
Default Server: dns-sj.cisco.com
Address:  171.70.168.183
> www.cisco.com
Server:  dns-sj.cisco.com
Address:  171.70.168.183
Name:    origin-www.cisco.com
Addresses:  2001:420:1101:1::a
          173.37.145.84
Aliases: www.cisco.com
> cisco.netacad.net
Server:  dns-sj.cisco.com
Address:  171.70.168.183
Name:    cisco.netacad.net
Address:  72.163.6.223
>

Syntax Checker—The nslookup Command (20.3.11)

Practice entering the nslookup command in both Windows and Linux.

Refer to the online course to complete this activity.

Lab—Troubleshoot Using Network Utilities (20.3.12)

In this lab, you will complete the following objectives:

· Interpret the output of commonly used network command-line utilities.

· Determine which network utility can provide the necessary information to perform troubleshooting activities in a bottom-up troubleshooting strategy.

Troubleshoot Wireless Issues (20.4)

Troubleshooting a wireless LAN is similar to troubleshooting a wired LAN; however, some important differences are associated with the wireless signal and access point.

Causes of Wireless Issues (20.4.1)

If a wireless client is unable to connect to an AP, the problem may be due to wireless connectivity problems. Wireless communications rely on radio frequency (RF) signals to carry data. Many factors can affect your ability to connect hosts using RF:

· Not all wireless standards are compatible. The 802.11ac (5 GHz band) is not compatible with the 802.11b/g/n standards (2.4 GHz band). Within the 2.4 GHz band, each standard uses different technology. Unless specifically configured, equipment that conforms to one standard may not function with equipment that conforms to another. In Figure 20-6, the 2.4 GHz network is configured to support legacy devices.

Figure 20-6 Basic Wireless Settings on a Wireless Router

· Each wireless conversation must occur on a separate, nonoverlapping channel. Some AP devices can be configured to select the least congested or highest throughput channel. Although automatic settings work, manual setting of the AP channel provides greater control and may be necessary in some environments.

· The strength of an RF signal decreases with distance. If the signal strength is too low, devices are unable to reliably associate and move data. The signal may be dropped. The NIC client utility can be used to display the signal strength and connection quality.

· RF signals are susceptible to interference from outside sources, including other devices functioning on the same frequency. A site survey should be used to detect for this interference.

· APs share the available bandwidth between devices. As more devices associate with the AP, the bandwidth for each individual device decreases, causing network performance problems. The solution is to reduce the number of wireless clients using each channel.

Authentication and Association Errors (20.4.2)

Modern WLANs incorporate various technologies to help secure the data on the WLAN. Incorrect configuration of any of these can prevent communication. Some of the most common settings that are configured incorrectly include the SSID, authentication, and encryption.

· The SSID is a case-sensitive, alphanumeric string that is up to 32 characters. It must match on both the AP and client. If the SSID is broadcast and detected, this is not an issue. If the SSID is not broadcast, it must be manually entered onto the client. If the client is configured with the wrong SSID, it will not associate with the AP. Additionally, if another AP is present that has broadcasted the SSID, the client may automatically associate to it.

· On most APs, open authentication is configured by default, allowing all devices to connect. If a more secure form of authentication is configured, a key is necessary. Both the client and AP must be configured with the same key. If the keys do not match, authentication will fail, and the devices will not associate.

· Encryption is the process of altering the data so that it is not usable by anyone without the proper encryption key. If encryption is enabled, the same encryption key must be configured on both the AP and the client. If the client associates with the AP but cannot send or receive data, the encryption key may be the issue, as shown in Figure 20-7.

Figure 20-7 Failed Authentication

Packet Tracer—Troubleshoot a Wireless Connection (20.4.3)

In this activity, you will be given a scenario. You will determine the reason why a wireless client is unable to connect to a wireless router and correct the problem.

Common Internet Connectivity Issues (20.5)

Several connectivity issues can be attributed to other devices such as the DHCP server or with reaching the ISP.

DHCP Server Configuration Errors (20.5.1)

If the physical connection to the wired or wireless host appears to be connecting as expected but the host cannot communicate on remote networks or the Internet, you should check the IP configuration of the client.

The IP configuration can have a major impact on the ability for a host to connect to the network. A wireless router acts as a DHCP server for local wired and wireless clients and provides IP configuration (see Figure 20-8). This includes the IP address, subnet mask, default gateway, and commonly, the IP addresses of DNS servers. The DHCP server binds the IP address to a client MAC address and stores that information in a client table. It is usually possible to view this table using the configuration GUI included with the router.

Figure 20-8 DHCP Configuration Received from the ISP

The client table information should match the local host information, which you can see using the ipconfig /all command. Additionally, the IP address on the client must be on the same network as the LAN interface of the wireless router. The LAN interface of the wireless router should be set as the default gateway. If the client configuration information does not agree with information in the client table, the address should be released (ipconfig /release) and renewed (ipconfig /renew) to form a new binding.

In most cases, the wireless router receives its own IP address through DHCP from the ISP. Check to make sure that the router has an IP address and, if necessary, attempt to release and renew the address using the GUI utility.

Check Internet Configuration (20.5.2)

If hosts on the wired and wireless local network can connect to the wireless router and with other hosts on the local network but not to the Internet, as shown in Example 20-11 and Figure 20-9, the problem may be in the connection between the router and the ISP.

Click here to view code image

Example 20-11 A Failed Ping

C:\> ping 10.18.32.12
Pinging 10.18.32.12 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.18.32.12:
     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Figure 20-9 Sample Topology

There are many ways to verify connectivity between the router and the ISP. Using the GUI, one way to check connectivity is to examine the router status page. As shown in Figure 20-10, it should show the IP address assigned by the ISP (64.100.0.11 in this example).

Figure 20-10 ISP Configuration

If this page shows no connection, the wireless router may not be connected. In that case, check all physical connections and LED indicators. If the DSL or cable modem is a separate device, check those connections and indicators as well. If the ISP requires a login name or password, check that they are configured to match those given by the ISP. Using the GUI, password configurations can normally be located on the Setup configuration page. Next, try to reestablish connectivity by clicking the Connect, or IP Address Renew, button on the status page. If the wireless router will still not connect, contact the ISP to see whether the issue is occurring from that end.

Check Firewall Settings (20.5.3)

If Layers 1 through 3 all appear to be operating normally and you can successfully ping the IP address of the remote server, it is time to check the higher layers. For example, if a network firewall is used along the path (see Figure 20-11), it is important to check that the application TCP or UDP port is open and no filter lists are blocking traffic to that port.

Figure 20-11 Firewalls in a Small Topology

If all clients are obtaining the correct IP configuration and can connect to the wireless router but are unable to ping each other or cannot access a remote server or application, the problem may be with rules on the router. Check all settings on the router to ensure no security restrictions could be causing the issue. Verify that the local firewalls on the client devices are not preventing network functionality.

Customer Support (20.6)

Knowing where to find help when needed is an important part of being able to solve networking issues.

Sources of Help (20.6.1)

If, during the troubleshooting process, you are unable to determine the problem and its resolution, you might need to obtain assistance from outside sources. Some of the most common sources for help include these:

· Documentation—Good documentation can save you a great deal of time and effort in finding the most likely cause of the problem. It can also provide the technical information required to isolate, verify, and correct the issue. The documentation provided with many networking devices, however, often does not provide sufficient information to troubleshoot anything except the most basic issues.

· Online FAQs (Frequently Asked Questions)—Most manufacturers provide a series of FAQs about their product or technology on their website. Usually based on previous requests for help, FAQs are a good source of current information and should be consulted whenever possible.

· Internet searches—With the increased availability of support forums, you can now obtain assistance with troubleshooting from people around the world in real time.

· Colleagues—Colleagues are often a wealth of information; there is no substitute for troubleshooting experience.

When to Call for Help (20.6.2)

Sometimes you cannot solve networking issues by yourself. In this case, you might need to contact the vendor or ISP support desk for assistance, as shown in Figure 20-12. The customer support line or support desk is the first stop for end-user assistance. The support desk is a group of individuals with the knowledge and tools required to help diagnose and correct common problems. It provides assistance to determine whether a problem exists, the nature of the problem, and the solution.

Figure 20-12 A Customer Support Call

Many companies and ISPs establish support desks to assist users with networking problems. Most large IT companies run support desks for their individual products or technologies. For example, Cisco Systems offers support desk assistance for problems integrating Cisco equipment into a network or problems that may occur after installation.

There are many ways to contact a support desk, including email, live chat, and phone. Although email is good for nonurgent problems, phone or live chat is better for network emergencies. This access is especially important in organizations such as banks where small amounts of downtime can cost large amounts of money.

If necessary, the support desk can take control of a local host through remote-access software. This capability allows support desk technicians to run diagnostic programs and interact with the host and network without having to physically travel to a job site. Remote access greatly reduces the wait time for problem resolution and allows the support desk to assist more users.

Support Desk Interaction (20.6.3)

When you‛re an end user, it is important to give the support desk as much information as possible, as shown in Figure 20-13. The support desk will require information on any service or support plans that are in place along with specific details of the affected equipment. This information can include make, model, and serial number, along with the version of firmware or operating system running on the device. They may also require the IP and MAC address of the malfunctioning device. The support desk will require information specific to the problem:

Figure 20-13 Providing Information to Customer Support

· What symptoms were encountered?

· Who encountered the problem?

· When did the problem manifest?

· What steps have been taken to identify the problem?

· What were the results of steps taken?

If this is a follow-up call, you should be prepared to provide the date and time of the previous call, the ticket number, and name of the technician. Be located at the affected equipment, and be prepared to provide the support desk staff with access to the equipment if requested.

Issue Resolution (20.6.4)

A support desk is generally organized in a series of levels of experience and knowledge. If first-level support desk staff are unable to solve the problem, they may escalate the problem to a higher level. Higher-level staff are generally more knowledgeable and have access to resources and tools that the first-level support desk staff do not.

Record all information regarding the interaction with the support desk, such as

· Time/date of call

· Name/ID of technician

· Problem reported

· Course of action taken

· Resolution/escalation

· Next steps (follow-up)

When you work together with the support desk, most problems can be resolved quickly and easily. When the problems are resolved, be sure to update all documentation accordingly for future reference.

Support Desk Tickets and Work Orders (20.6.5)

When a Level 1 support desk technician receives a call, there is a process followed to gather information. There are also specific systems for storing and retrieving relevant information. It is extremely important to gather the information correctly in the event that a call has to be escalated to a Level 2 technician or require an onsite visit.

The information gathering and recording process starts as soon as the technician answers the phone. After customer identification, the technician accesses the relevant customer information. Typically, a database application is used to manage the customer information.

The information is transferred to a trouble ticket, also known as an incident report. This document can be a piece of paper in a paper filing system or an electronic tracking system designed to follow the troubleshooting process from beginning to end. Each person who works on the problem is expected to record what was done on the trouble ticket. When an onsite call is required, the trouble ticket information can be converted to a work order that the onsite technician can take to the customer site.

When a problem is resolved, the solution is documented in the customer work order (see Figure 20-14) or trouble ticket, and in a knowledge base document for future reference.