Ping is a well known tool to check network connectivity between two IP hosts.
Ping sends very small packets to an IP host who will answer by sending packets back.
The ICMP packets sent to the host are called echo_request and the packets sent back echo_response.
CASE STUDY :
Let's examine a case study where two machines called Paris and Berlin ping a machine called "www.google.ch".
The Wireshark sniffer is located on the way between Berlin and "www.google.ch". It will be used to capture the packets content.
Paris is a Linux Ubuntu machine and Berlin a Microsoft XP Machine.
Ping from the Linux machine (Paris) to "www.google.ch":
Paris: ping www.google.ch
PING www.google.ch (209.85.135.105) 56(84) bytes of data.
64 bytes from www.google.ch(209.85.135.105): icmp_seq=1 ttl=255 time=1.19 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=2 ttl=255 time=1.25 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=3 ttl=255 time=1.26 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=4 ttl=255 time=1.29 ms
--- www.google.ch ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 1.192/1.250/1.290/0.044 ms
Ping from the Windows machine (Berlin) to "www.google.ch":
Berlin: ping www.google.ch
Pinging www.google.ch [209.85.135.105] with 32 bytes of data:
Reply from 209.85.135.105: bytes=32 time=18 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=21 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=20 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=33 ms TTL=250
Ping statistics for 209.85.135.105:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 18ms, Maximum = 33ms, Average = 23ms
What information can be learnt from the outputs above?
- Is the remote host alive? => Host reachability
- Is the network speed good? => Network congestion
- Is the remote host far? => Travel length
Let's see a summary of data captured by Wireshark
This Wireshark capture gives us the following information:
- The packets have been recognized as ICMP packets. protocol column
- Four ICMP packets have been sent (echo_request) and four ICMP packets have been received (echo_reply). info column
- A packet value of 74 bytes which is composed of the headers (42 bytes) and the ICMP data part (32 bytes by default on Windows). length column
As said in the previous section, Ping gives us three major information:
Host reachability
Network congestion
Time To Live
Host Reachability
The Ping results in the previous section show that four ICMP packets have been sent and four received. This result indicates you that the host is alive at the ICMP level. However, no other information, such as whether or not a a webserver is running, is given.
What's does it mean if I receive a negative result?
Let's see an example:
C:\>ping www.google.com
|
Pinging google.com [84.16.88.15] with 32 bytes of data:
Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 84.16.88.15: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), |
Host google.com, which has IP address 84.16.88.15, did not answer to the Ping command. It's interesting to note that the negative answer does not always mean that the recipient is not alive (in our example, it is alive and runs a webserver). In this case, the result simply means that the host just doesn't answer to ICMP request.
What could be the reason for this "no-answer" ?
It is not always possible to know the exact reason behind a "no-answer". As a matter of fact, there may be a lot of different reasons. In the following picture, we summarize the four major reasons.
In the first case, an external firewall blocks the ICMP requests. ICMP can be used as a first step in an attack because it can determine the alive hosts before attacking. In this case the network behind the firewall is hidden from the external world even it is well alive.
Blocking ICMP messages is a first security recommendation to secure a network. The external firewall is more often used to secure professional network because it is expensive and requires advanced skills for configuring.
In the second case, the workstation has a personal firewall that blocks the ICMP message. A personal firewall is recommended for home computers for the same reasons mentioned above.
In the thrid case, the "pinged" machine is not connected to the IP network, for instance, because the network cable is unplugged.
The echo_request message will be discarded on the last router of the layer 3 device before the remote host.
In the fourth case, the host is down or has its network card deactivated. Such as in the previous case, the echo_request message will die on the last router of the layer 3 device before the remote host.
-----------
If a device called Geneva can ping another called Dallas, does it mean that the opposite, in other words Dallas can ping Geneva, is always true?
The response is no. As you can see below, you can have a firewall only preventing echo_request in a single direction.
When Dallas pings Geneva, the ICMP echo_request is blocked on the firewall and Dallas receives no answer from Geneva.
When Geneva pings Dallas, the ICMP echo_request reaches Dallas and Geneva receives the echo_response in return, so the ping is successful. In this case, the ICMP packets are not blocked since the firewall only stops echo_request coming from outside. Here, we have an echo_request from inside and an echo_response from outside.
Network Congestion
Another very precious information provided by the Ping command is the time taken for a packet to reach the destination and come back. This measure is called the RTT (Round Trip Time) or "response time" and is displayed in milliseconds.
It should not be mistaken for the latency or delay defined as the one-way time taken for a packet to travel across the network between two hosts.
The response time will affect network applications performance. High response times will lead to poor performances.
When a network application is slow, a first basic troubleshooting step is to get the reponse time between the client and the server to know if the network is the reason of the slowness.
We should not forget another information related to the response time: the packet loss. A packet is declared as lost if the ICMP message has been discard on the way or if is returned after the timeout value equal to 2 seconds by default. Packet losses will lead to a high TCP retransmission rate with the consequence of a slow or interrupted network application.
In a LAN environment, there shouldn't be any packet loss.
What affects the response time and the packet loss?
- THE NETWORK PIPES
Cable type and cable quality will greatly affect the response time. For example, fiber cables will be much more efficiency than old copper cables. Poor quality or damaged cables can lead to packet loss. Wide pipes will also help ensure low response times for in case of high traffic, the packets will not slow down. This can be compared to cars in a traffic jam.
- THE NETWORK DEVICES
Processing devices along the way can slightly increase the response time if they process packets slowly. For example, packets crossing an overworked router will be delayed because it will not have enough available resources to manage the packets quickly.
- THE PHYSICAL REMOTENESS
A device far from you will get slower response time than an identical device close to you. Indeed, even with excellent pipes and routers, the physical remoteness and the number of routers to cross to arrive to destination obviously have an impact on the response time.
To give very approximate values, response time in a LAN environment is around 1 or 2 milliseconds whereas in very far remote internet VPNs this time amounts to around 300 milliseconds.
Here is an example:
A ping from Geneva/Switzerland to Google Switzerland only takes about 30 ms whereas a ping to Google Japan takes 130 ms.
- SOURCE AND DESTINATION DEVICES
People often believe that low response time or packet loss are due to network problems. This is often not the case since the problems can come from the source or destination devices that are simply overloaded or have a faulty network card.
The ping output gives the minimum, average and maximum response times, helping us know whether the response time remains constant or varies a lot.
Time-to-Live (TTL)
A timer value included in packets sent over TCP/IP-based networks that tells the recipients how long to hold or use the packet or any of its included data before expiring and discarding the packet or data.
The TTL or Time-To-Live gives you an indication of the number of routers between the source and destination.
TTL in DNS means how much time will it take for your browser to reload the new DNS information.
So, if you visit a website that has a TTL of 6 hours, your browser will not need to check for any new information for up to 6 hours. Beyond that, your browser will be forced to look up the DNS data to get the most up-to-date information.
The TTL is used to prevent an IP packet from looping inside an IP network and causing a network meltdown.
The initial TTL packet value for an IP packet is 255 and then it is decremented by 1 each time it encounters a router. When this value reaches 0, the packet is discarded by a router. The TTL value is contained in each IP packet including ICMP packets. The TTL value given by the ping command is in fact the TTL value of an echo_response packet.
By default, Windows will decrease the TTL by 128 and Ubuntu Linux by 192.
Let us study three scenarios where A pings B. B is a router (first case), a Microsoft Windows machine (case 2) and a Ubuntu Linux machine (case 3).
The TTL value is initially 255 and then decreased as described as above.
IN-DEPTH ANALYSIS
This section will provide an in-depth analysis of an echo_request and an echo_response packet.
Echo request
The first array is the Wireshark capture printscreen and the second array is the Wireshark capture text output.
- The Wireshark capture (in the grey first array) shows the different OSI layers (Ethernet - IP - IMCP).
- The packet has been recognized as ICMP in the IP layer.
- The ICMP layer is composed of an ICMP header section and ICMP data section.
- The ICMP header section is composed of the type, code, checksum, identifier and sequence numbers.
- The type has a value of 8 meaning that the packet is a echo_request packet.
- The sequence number value (here 256) is used to help match the echo request with the associated reply (echo responses).
Echo response
The first array is the Wireshark capture printscreen and the second array is the Wireshark capture text output.
- The TTL value of the echo_response packet is 251, which is also the TTL value displayed in the ping tool.
- The packet has been recognized as ICMP in the IP layer.
- The ICMP layer is composed of an ICMP header section and ICMP data section.
- The ICMP header section is composed of the type, code, checksum, identifier and sequence numbers.
- The type has a value of 0 meaning that the packet is a echo_response packet.
- The sequence number value (here 256) is used to help match the echo request with the associated reply (echo responses).
PING ARGUMENTS
Ping works the same way under windows and Linux. However there are some subtle differences in the use and presentation of the Ping command.
Default use:- Windows only sends four ICMP request whereas Linux will send these same packets indefinitely. the "Cltr + C" command will interrupt the echo_request packet sending.
- The data field of an ICMP packet is 56 bytes under Linux and 32 under windows. It means the ICMP packet total length, which includes the headers of 42 bytes, is 98 bytes under Linux and 74 under windows.
Arguments:Some arguments may be different between Linux and Windows. For example, the -l option is used to set the packet size under windows whereas under Linux, the "-s" argument is used for the same purpose.
See below for full details about the windows and Linux arguments.
Output:Linux displays another value in the ping output command called the mean deviation (mdev) that is calculated using the response time values. It basically gives an indication about the response time constancy. In other words, a low mean deviation value will say that the reponse time values given by the ping command are very similar.
ICMP HEADER
The ICMP header is composed of a:
- Type
- Code
- Header checksum
- ID
- Sequence
Below, you can find the ICMP protocol structure.
Below you can find some ICMP Types
ping -a IPAddress also shows the hostname of the corresponding system.
Q:- C:\Users\jon>ping -t yahoo.com
Pinging yahoo.com [98.138.253.109] with 32 bytes of data:
Reply from 98.138.253.109: bytes=32 time=195ms TTL=46
Reply from 98.138.253.109: bytes=32 time=230ms TTL=44
Reply from 98.138.253.109: bytes=32 time=175ms TTL=45
Reply from 98.138.253.109: bytes=32 time=208ms TTL=44
Reply from 98.138.253.109: bytes=32 time=180ms TTL=46
Reply from 98.138.253.109: bytes=32 time=206ms TTL=44
Reply from 98.138.253.109: bytes=32 time=209ms TTL=44
Reply from 98.138.253.109: bytes=32 time=173ms TTL=46
Reply from 98.138.253.109: bytes=32 time=170ms TTL=46
Reply from 98.138.253.109: bytes=32 time=224ms TTL=45
Reply from 98.138.253.109: bytes=32 time=200ms TTL=45
Reply from 98.138.253.109: bytes=32 time=172ms TTL=46
Reply from 98.138.253.109: bytes=32 time=258ms TTL=44
Ping statistics for 10.66.227.45:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 6ms, Average = 1ms
I vaguely understand the TTL value as the number of hops that the
packet traverses to reach its destination, but I don't understand how
TTL can have such a dramatic +/- 1 variance in such a short amount of
time.
Also, it seems Yahoo has some kind of rate-limiting implemented as a persistent ping will start timing out after about 20 packets. Is this normal? bing.com doesn't even reply to me! When pinging google.com the TTLs are consistent. When pinging Twitter.com sometimes I get TTL=249, but usually TTL-58.
ANS:- Most likely this is caused by load balancing across multiple
networks. Each ping will take a different path and accordingly will have
a difference TTL value.
I also read about search engine providers doing strange things with TTL, but its just going through a different route either way. TTL values are different when sourced from different operating systems:
Reply from 98.138.253.109: bytes=32 time=200ms TTL=45 Reply from 98.138.253.109: bytes=32 time=172ms TTL=46 Reply from 98.138.253.109: bytes=32 time=258ms TTL=44 Ping statistics for 10.66.227.45: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 6ms, Average = 1ms Bytes The second section displays the size of the ping in the format "bytes=32." The default size of a ping is 32 bytes. However, it is possible to change the size of the ping by typing "ping (address) -l (size)," such as "ping google.com -l 64." Time The third section displays the number of milliseconds that elapsed between sending and receiving the ping, in the format "time=73ms." This value indicates the connectivity latency between your computer and the destination computer. Latency affects services such as voice and video communication,as well as online gaming. TTL The fourth section displays the ping's time to live in the format "TTL=53." When you send a ping over the Internet, it generally goes through several computers between yours and the destination computer. A ping begins with a default TTL value such as 64. The TTL value is decreased by one each time the ping goes through a computer/Router between yours and the final destination. If the TTL reaches zero, the ping command displays the message "TTL expired in transit." This indicates a routing issue between your computer and the destination, which may not be within your control. You can change the TTL by typing "ping (address) -i (value)." Statistics The ping command displays statistics below the list of results from each individual ping. This section provides information such as the number of pings lost in transit and the average amount of time that elapsed between sending the pings and receiving replies. |
No comments:
Post a Comment