| Chapter 9. Basic network troubleshooting | ||
|---|---|---|
|
 |
|
| Chapter 9. Basic network troubleshooting | ||
|---|---|---|
|
|
|
|
Table of Contents
In order to troubleshoot our network we need to make use of a couple of tools. First and probably the most important tool we'll learn by is the PING command.
PING stands for Passive Internet Groper and its job is to be able to essentially send an echo request to some device on the network.
If that device is alive, it will send an echo reply back.
Now this is probably one of the most important commands that you'll use with troubleshooting but often switches put very low priority on "ping packets" and so what can and often does happen is that the ping packets get blocked even though they are a valid packet, and even though there is a reply from PING the packets get dropped.
Nevertheless, let's not concern ourselves with what modern technology is doing, the issue is that there's a request sent by yourself to a device on the network and that device, if it's alive, if it's up, it routes an echo reply.
If I just leave the PING running it tells us a good number of things.
riaan@debian:~> ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.411 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.369 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=0.375 ms
...
|
Firstly, it tells us that 64 bytes were sent and that 64 bytes were received. And if we look at this, the 64 bytes that were sent was the echo request and the 64 bytes received was the echo reply. The second thing it tells us is that you've got a reply from the client or from the device being pinged.
The sequence number is called the ICMP sequence and that number increments for every PING that's received, that number increments and you will get consecutive numbers.
The next field is the TTL (Time To Live), and that would be set to something like 255. Every packet on the network has a time to circulate, once the time expires the packet evaporates from the network.
The last field in the report is the time, and this is the response time to send the packet to the workstation, and receive the reply.
This will show us how fast the network is and the time will often be in milliseconds (can move to seconds if the network is slow).
If you then push control-C to break this ping, to break out of the command, you'll see a summary of statistics of the packets that we sent.
riaan@debian:~> ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.411 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.369 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=0.375 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=255 time=0.383 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=255 time=0.378 ms
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.369/0.383/0.411/0.019 ms
riaan@debian:~>
|
The first thing you will see is that the number of packets sent and the number of packets received. These should be almost equal if not equal. If you send more than you received then there is clearly some packets lost and that's the next line that is displayed on the output.
A percentage packets loss. Packets loss can occur for a number of reasons, it could be that the network was busy, it could be that there's a physical failure somewhere on the network and its packet's getting corrupt or packets getting lost so its packets lost indicator.
On the next line you will see your round-trip time and within that you should see a minimum time, an average time, a maximum time and sometimes they will give you the standard deviation time. In my case, the minimum time is 0.369ms; the average time was 0.383ms, the maximum time being 0.411ms. Obviously these vary from machine to machine or network to network. The final one is the standard deviation time of 0.019ms.
If you run the command "ping -c10" to the opposite workstation, ping sends 10 x 64 byte packets and then stops. (Take note of the statistics for this transmission.)
This can be quite useful when we need to do troubleshooting.
To further this example, let us send a 5 packet transmission -we know that the maximum transmission unit for Ethernet is 1500 bytes, so if we sent a packet of 2400 bytes that would really mean that every packet has to be split up. This time I'm going to send a packet with size of 2400 bytes and you'll see it sends that packet size of 2408, an extra 8 bytes because of headers.
If you then compare the report from sending a packet size of 64 bytes and one of 2400 bytes you will see a difference in speed with which it can transmit large packets.
In my case, the average time went up from 0.1ms to 1.2ms to transmit a large packet size.
There are other options that can be used with ping; you could for example ping every 10 seconds instead of every second.
riaan@debian:~> ping -help
Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
[-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
[-M mtu discovery hint] [-S sndbuf]
[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination
riaan@linux:~> ping -i10 -c10 -s 2400 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 2400(2428) bytes of data.
2408 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=6.02 ms
2408 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=4.93 ms
2408 bytes from 192.168.1.1: icmp_seq=3 ttl=255 time=4.90 ms
2408 bytes from 192.168.1.1: icmp_seq=4 ttl=255 time=4.92 ms
2408 bytes from 192.168.1.1: icmp_seq=5 ttl=255 time=4.92 ms
2408 bytes from 192.168.1.1: icmp_seq=6 ttl=255 time=4.91 ms
2408 bytes from 192.168.1.1: icmp_seq=7 ttl=255 time=4.93 ms
2408 bytes from 192.168.1.1: icmp_seq=8 ttl=255 time=4.91 ms
2408 bytes from 192.168.1.1: icmp_seq=9 ttl=255 time=4.91 ms
2408 bytes from 192.168.1.1: icmp_seq=10 ttl=255 time=4.92 ms
--- 192.168.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 90009ms
rtt min/avg/max/mdev = 4.905/5.031/6.023/0.343 ms
riaan@debian:~>
|
Essentially there are 2 types of things that would happen when we ping something.
1.We could ping the device and get a response
2.or we would not be able to ping it at all, getting no response. In this case the device would not know how to get back to us.
Ping uses a protocol called ICMP protocol (Internet Control Message Protocol) for in fact this protocol has any number of responses.
Some examples of ICMP messages would be:
"destination host is unreachable"
Respond with nothing at all
"ICMP re-direct"
ICMP time-outs if the device is not responding.
So ICMP can provide a whole number of responses depending on the state of the device it is attempting to reach.
If we try and PING something that's not available we will get no response whatsoever, and this could then mean that the device is down.
If we try and PING a device we might get an ICMP re-direct, in other words, the PING responses don't go to that particular machine, they get re-directed to some other machine.
|
|
 |
|
| Using smbclient |  |
IP Address and Name resolution problems |