Scribd
Upload
99 views4 pages

Exp 8 Network Troubleshooting-1

Uploaded by

Vinayak Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
99 views4 pages

Exp 8 Network Troubleshooting-1

Uploaded by

Vinayak Gupta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Exp 8:

AIM: To verify and troubleshoot network connectivity.


THEORY:
The ping command can systematically test connectivity by looking for answers to the following
questions, in this order:

Step 1. Can an end device ping itself?

Step 2. Can an end device ping its default gateway?

Step 3. Can an end device ping the destination?

By using the ping command in this ordered sequence, you can isolate problems more quickly.
If local connectivity is not an issue—in other words, if the end device can successfully ping its default
gateway using the traceroute utility can help isolate the point in the path from source to
destination where the traffic stops.

As a first step in the testing sequence, verify the operation of the TCP/IP stack on the local host by
pinging the loopback address, 127.0.0.1, as Example- 1 demonstrates.

Example -1 Testing the TCP/IP Stack on a Windows PC

C:\> ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<1ms TTL=64


Reply from 127.0.0.1: bytes=32 time<1ms TTL=64
Reply from 127.0.0.1: bytes=32 time<1ms TTL=64
Reply from 127.0.0.1: bytes=32 time<1ms TTL=64

Ping statistics for 127.0.0.1:


Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

This test should succeed regardless of whether the host is connected to the network, so a failure
indicates a software or hardware problem on the host itself. Either the network interface is not
operating properly or support for the TCP/IP stack has been inadvertently removed from the
operating system.

Next, verify connectivity to the default gateway. Determine the default gateway address by using
ipconfig and then attempt to ping it, as in Example 2.

Example 2 Testing Connectivity to the Default Gateway on a Windows PC

C:\> ipconfig

Windows IP Configuration
Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : cisco.com


IP Address. . . . . . . . . . . .: 192.168.1.25
Subnet Mask . . . . . . . . . . .: 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

C:\> ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:

Reply from 192.168.1.1: bytes=32 time=162ms TTL=255


Reply from 192.168.1.1: bytes=32 time=69ms TTL=255
Reply from 192.168.1.1: bytes=32 time=82ms TTL=255
Reply from 192.168.1.1: bytes=32 time=72ms TTL=255

Ping statistics for 192.168.1.1:


Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 69ms, Maximum = l62ms, Average = 96ms

Failure here can indicate several problems, which must be checked in a systematic sequence. One
possible order might be the following:

Step 1. Is the cabling from the PC to the switch correct? Are link lights lit?

Step 2. Is the configuration on the PC correct according to the logical map of the network?

Step 3. Are the affected interfaces on the switch the cause of the problem?

Step 4. Is the cabling from the switch to the router correct? Are link lights lit?

Step S. Is the configuration on the router interface correct according to the logical map of the
network? Is the interface active?

Finally, verify connectivity to the destination by pinging it. Assume that you are trying to reach
a server at 192.165.3.100. Example 3 shows a successful ping test to the destination.

Example 3 Testing Connectivity to the Destination on a Windows PC


PC> ping 192.168.3.100

Pinging 192.168.3.100 with 32 bytes of data:

Reply from 192.168.3.100: bytes=32 time=200ms TTL=l26


Reply from 192.168.3.100: bytes=32 time=185ms TTL=l26
Reply from 192.168.3.100: bytes=32 time=186ms TTL=l26
Reply from 192.168.3.100: bytes=32 time=200ms TTL=126

Ping statistics for 192.168.3.100:


Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = l85ms, Maximum = 200ms, Average = l92ms

Failure here indicates a failure in the path beyond the default gateway interface because you already
successfully tested connectivity to the default gateway. From a Windows PC, the best tool to use to
find the break in the path is the tracert command (see Example 4).

NOTE: Both macOS and Linux use the traceroute command rather than tracert.

Example 4 Tracing the Route from a Windows PC


C:\> tracert 192.168.3.100

Tracing route to 192.168.3.100 over a maximum of 30 hops:


1 97 ms 75 ms 72 ms 192.168.1.1
2 104 ms 119 ms 117 ms 192.168.2.2
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 ’C

NOTE: Failure at hops 3, 4, and 5 in Example 4 could indicate that these routers areconfigured
to not send ICMP messages back to the source.

As shown in in Example 4, the last successful hop on the way to the destination was 192.168.2.2. If
you have administrator rights to 192.168.2.2, you can continue your research by remotely accessing
the command line on 192.165.2.2 and investigating why traffic will not go any further. In addition, other
devices between 192.168.2.2 and 192.165.3.100 could be the source of the problem. The point is,
you want to use your ping and tracert tests, as well as your network documentation, to proceed in
a logical sequence from source to destination.

Regardless of how simple or complex your network is, using ping and tracert from the source to
the destination is a simple yet powerful way to systematically verify end-to-end connectivity, as well
as locate breaks in a path from one source to one destination.

Troubleshoot Interface and Cable Issues


The physical layer is often the reason a network issue exists—power outage, disconnected cable, power-
cycled devices, hardware failures, and so on. This section looks at some troubleshooting tools,
in addition to the approach of actually walking ovcr to the wiring closet or network device and
“physically” checking Layer 1.

Media Issues
Besides failing hardware, common physical layer issues occur with media. Consider a few examples:

• New equipment is installed that introduces electromagnetic interference (EMI) sources into the
environment.

• Cable runs too close to powerful motors, such as an elevator.

• Poor cable management puts a strain on some RJ-45 connectors, causing one or more
wires to break.

• New applications change traffic patterns.

• When new equipment is connected to a switch, the connection operates in half-duplex mode
or a duplex mismatch occurs, which can lead to an excessive number of collisions.

Figure 3 shows an excellent troubleshooting flowchart that you can use in troubleshooting
switch media issues.

Figure 3 Troubleshooting Switch Media Issues


show
interface

Verify No
No or bad —¥ Successful
connection interface connection
status

Down Yes Yes

Fix cabling and Remove source Verify and fix


connectors of noise duplex
for damage Check cable settings
length

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy