Advanced PING usage on Cisco, Juniper, Windows, Linux, and Solaris
As a network engineer, one of the most common utilities I use is the ping command. While in its simplest form it is a very valuable tool, there is much more knowledge that can be gleaned from it by specifying the right parameters.
Ping on Cisco routers
On modern Cisco IOS versions the ping tool has quite a few options, however, this was not always the case.
Compare the options to ping in IOS 12.1(14)
EXRTR1#ping ip 4.2.2.1 ?
<cr>
EXRTR1#ping ip 4.2.2.1
To that in IOS 12.4(24)T
plunger#ping ip 4.2.2.1 ?
data specify data pattern
df-bit enable do not fragment bit in IP header
repeat specify repeat count
size specify datagram size
source specify source address or name
timeout specify timeout interval
validate validate reply data
<cr>
plunger#ping ip 4.2.2.1
When I am running a basic connectivity test between two points on a network I will generally not specify any options to ping (i.e. “ping 4.2.2.1”), however, once I have verified connectivity I will most often then want to verify what MTU size the path will support without fragmentation, and then also run an extended ping process with a thousand or more pings to test the reliability/bandwidth/latency characteristics of the link.
Here is an example of the most basic form. Note that by default it is sending 100 byte frames:
plunger#ping 4.2.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.2.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/28 ms plunger#
If I am working on an Ethernet network (or PPP link), it is most common that my target goal is for 1500 byte frames to make it through. I will use the “size” parameter to force ping to generate 1500 byte frames (note that in Cisco land this means 1472 byte ICMP payloads plus 8 bytes ICMP header and 20 bytes IP header). I also use the df-bit flag to set the DO NOT FRAGMENT bit on the generated packets. This will allow me to ensure that the originating router (or some other router in the path), is not fragmenting the packets for me.
plunger#ping 4.2.2.1 size 1500 df-bit
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 4.2.2.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/26/28 ms
plunger#
If the first ping command worked, but the command above did not, then try backing down the size until you find a value that works. Note that one common example of a smaller MTU is 1492 which is caused by the 8 bytes of overhead in PPPoE connections.
The next command to try is to send a large number of pings of the maximum MTU your link can support. This will help you identify packet loss issues and is just a good way to generate traffic on the link to see how much bandwidth you can push (if your monitoring the link with another tool). I have frequently identified bad WAN circuits using this method. Note that looking at the Layer 1/2 error statistics before doing this (and perhaps clearing them), and then looking at them again afterwards (on each link in the path!) is often a good idea.
plunger#ping 192.168.0.10 size 1500 df-bit repeat 1000
Type escape sequence to abort.
Sending 1000, 1500-byte ICMP Echos to 192.168.0.10, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/2/4 ms
plunger#
Now the final ping parameter I often end up using is the “source” option. A good example is when you have a router with a WAN connection on one side that has a /30 routing subnet on it, plus then an Ethernet connection with a larger subnet for your users devices. Say that users on the Ethernet are reporting that they can not ping certain locations on the WAN, though you can ping it just fine from the router. This is often because the return path from the device you are pinging back to your users subnet on the Ethernet is not being routed properly, but the IP your router has on the /30 WAN subnet is being routed correctly. The key here is that by default a Cisco router will originate packets from the IP of the Interface it is going to be sending the traffic out (based on it’s routing tables).
To test from the interface your router has in the users subnet, use the source command like this:
plunger#ping 4.2.2.1 source fastEthernet 0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.2.2.1, timeout is 2 seconds:
Packet sent with a source address of 173.50.158.74
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
plunger#
Note that you can also use these command together depending on what you are trying to do:
plunger#ping 192.168.0.10 size 1500 df-bit source FastEthernet 0/0 repeat 100
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 192.168.0.10, timeout is 2 seconds:
Packet sent with a source address of 173.50.158.74
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms
plunger#
Ping on Juniper routers
The options to ping on Juniper (version 9.3R4.4 in this case) are quite extensive:
root@INCSW1> ping ?
Possible completions:
<host> Hostname or IP address of remote host
bypass-routing Bypass routing table, use specified interface
count Number of ping requests to send (1..2000000000 packets)
detail Display incoming interface of received packet
do-not-fragment Don't fragment echo request packets (IPv4)
inet Force ping to IPv4 destination
inet6 Force ping to IPv6 destination
interface Source interface (multicast, all-ones, unrouted packets)
interval Delay between ping requests (seconds)
logical-system Name of logical system
+ loose-source Intermediate loose source route entry (IPv4)
no-resolve Don't attempt to print addresses symbolically
pattern Hexadecimal fill pattern
rapid Send requests rapidly (default count of 5)
record-route Record and report packet's path (IPv4)
routing-instance Routing instance for ping attempt
size Size of request packets (0..65468 bytes)
source Source address of echo request
strict Use strict source route option (IPv4)
+ strict-source Intermediate strict source route entry (IPv4)
tos IP type-of-service value (0..255)
ttl IP time-to-live value (IPv6 hop-limit value) (hops)
verbose Display detailed output
vpls Ping VPLS MAC address
wait Delay after sending last packet (seconds)
root@INCSW1> ping
While there are a lot more options here, I am generally trying to test the same types of things. A very important note however is that in the Juniper world, the size parameter is the payload size and does not include the 8 byte ICMP header and 20 byte IP header. The command below is the same as specifying 1500 bytes in Cisco land.
root@INCSW1> ping 4.2.2.1 size 1472 do-not-fragment
PING 4.2.2.1 (4.2.2.1): 1472 data bytes
1480 bytes from 4.2.2.1: icmp_seq=0 ttl=53 time=25.025 ms
1480 bytes from 4.2.2.1: icmp_seq=1 ttl=53 time=24.773 ms
1480 bytes from 4.2.2.1: icmp_seq=2 ttl=53 time=24.757 ms
1480 bytes from 4.2.2.1: icmp_seq=3 ttl=53 time=25.045 ms
1480 bytes from 4.2.2.1: icmp_seq=4 ttl=53 time=24.911 ms
1480 bytes from 4.2.2.1: icmp_seq=5 ttl=53 time=25.152 ms
^C
--- 4.2.2.1 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.757/24.944/25.152/0.145 ms
root@INCSW1>
Here is an example of sending lots of pings quickly on the Juniper to test link reliability:
root@INCSW1> ping 10.0.0.1 size 1472 do-not-fragment rapid count 100
PING 10.0.0.1 (10.0.0.1): 1472 data bytes
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
--- 10.0.0.1 ping statistics ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.230/2.429/5.479/1.228 ms
root@INCSW1>
Ping on Windows XP/Vista/2003/2008
While not as full featured, the Windows ping tool can at least set the packet size and the do-not-fragment bit:
Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\eric.rosenberry>ping ?
^C
C:\Users\eric.rosenberry>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] [-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).
-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).
-S srcaddr Source address to use.
-4 Force using IPv4.
-6 Force using IPv6.
C:\Users\eric.rosenberry>
So your basic ping in Windows claims to send 32 bytes of data (I have not verified this), but I suspect that is 32 bytes of payload, plus 8 bytes ICMP, and 20 bytes of IP for a total of 60 bytes.
C:\Users\eric.rosenberry>ping 4.2.2.1
Pinging 4.2.2.1 with 32 bytes of data:
Reply from 4.2.2.1: bytes=32 time=27ms TTL=53
Reply from 4.2.2.1: bytes=32 time=25ms TTL=53
Reply from 4.2.2.1: bytes=32 time=28ms TTL=53
Reply from 4.2.2.1: bytes=32 time=27ms TTL=53
Ping statistics for 4.2.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 28ms, Average = 26ms
C:\Users\eric.rosenberry>
So a common set of flags I use will be to create full 1500 byte frames (note that it takes 1472 as the parameter for this) and then tell it not to fragment (-f) and to repeat until stopped (-t).
C:\Users\eric.rosenberry>ping 4.2.2.1 -l 1472 -f -t
Pinging 4.2.2.1 with 1472 bytes of data:
Reply from 4.2.2.1: bytes=1472 time=29ms TTL=53
Reply from 4.2.2.1: bytes=1472 time=30ms TTL=53
Reply from 4.2.2.1: bytes=1472 time=31ms TTL=53
Reply from 4.2.2.1: bytes=1472 time=29ms TTL=53
Reply from 4.2.2.1: bytes=1472 time=30ms TTL=53
Reply from 4.2.2.1: bytes=1472 time=28ms TTL=53
Reply from 4.2.2.1: bytes=1472 time=29ms TTL=53
Ping statistics for 4.2.2.1:
Packets: Sent = 7, Received = 7, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 31ms, Average = 29ms
Control-C
^C
C:\Users\eric.rosenberry>
Ping on Linux
Hey look, it is a ping command that is not ambiguous about what size frames it is generating!!! It clearly shows that the payload is 56 bytes, but that the full frame is 84. Note that this is from an Ubuntu 2.6.27-7-generic kernel box.
ericr@eric-linux:~$ ping 4.2.2.1
PING 4.2.2.1 (4.2.2.1) 56(84) bytes of data.
64 bytes from 4.2.2.1: icmp_seq=1 ttl=52 time=21.8 ms
64 bytes from 4.2.2.1: icmp_seq=2 ttl=52 time=21.4 ms
64 bytes from 4.2.2.1: icmp_seq=3 ttl=52 time=21.4 ms
64 bytes from 4.2.2.1: icmp_seq=4 ttl=52 time=21.6 ms
64 bytes from 4.2.2.1: icmp_seq=5 ttl=52 time=21.8 ms
64 bytes from 4.2.2.1: icmp_seq=6 ttl=52 time=21.8 ms
^C
--- 4.2.2.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5019ms
rtt min/avg/max/mdev = 21.435/21.700/21.897/0.190 ms
ericr@eric-linux:~$
To set the packet size use the -s flag (it is asking for payload size, so 1472 will create a 1500 byte frame). Now if you want to turn off fragmentation by setting the do-not-fragment bit (DF), the parameter is a bit more obscure “-M on”. Here is an example using both:
ericr@eric-linux:~$ ping 4.2.2.1 -s 1472 -M do PING 4.2.2.1 (4.2.2.1) 1472(1500) bytes of data. 1480 bytes from 4.2.2.1: icmp_seq=1 ttl=52 time=23.8 ms 1480 bytes from 4.2.2.1: icmp_seq=2 ttl=52 time=24.1 ms 1480 bytes from 4.2.2.1: icmp_seq=3 ttl=52 time=31.4 ms 1480 bytes from 4.2.2.1: icmp_seq=4 ttl=52 time=23.7 ms 1480 bytes from 4.2.2.1: icmp_seq=5 ttl=52 time=23.5 ms ^C --- 4.2.2.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4017ms rtt min/avg/max/mdev = 23.589/25.369/31.469/3.057 ms ericr@eric-linux:~$
And there is another highly useful parameter that we have not seen yet in any of our previous ping utilities. The linux ping has a “flood” option that will send pings as fast as the machine can generate them. This is great for testing network links capacity, but can make for unhappy network engineers if you use it inappropriately. Note that you must be root to use the -f flag. Output is only shown when packets are dropped:
ericr@eric-linux:~$ sudo ping 10.0.0.1 -s 1472 -M do -f
PING 10.0.0.1 (10.0.0.1) 1472(1500) bytes of data.
.^C
--- 10.0.0.1 ping statistics ---
2763 packets transmitted, 2762 received, 0% packet loss, time 6695ms
rtt min/avg/max/mdev = 2.342/2.374/3.204/0.065 ms, ipg/ewma 2.424/2.384 ms
ericr@eric-linux:~$
Ping on Solaris
Here is the ping options from a Solaris 10 box (I forget what update this super-secret kernel number decodes too):
SunOS dbrd02 5.10 Generic_125100-07 sun4v sparc SUNW,Sun-Fire-T200
I find the basic ping command in Solaris to be annoying:
[erosenbe: dbrd02]/export/home/erosenbe> ping 4.2.2.1 4.2.2.1 is alive [erosenbe: dbrd02]/export/home/erosenbe>
I want Ping to tell me something more useful than that a host is alive. Come on Sun, like round trip time at least? Maybe send a few additional pings than just one? The -s command makes this operate more like the ping command in other OS’s:
[erosenbe: dbrd02]/export/home/erosenbe> ping -s 4.2.2.1 PING 4.2.2.1: 56 data bytes 64 bytes from vnsc-pri.sys.gtei.net (4.2.2.1): icmp_seq=0. time=21.6 ms 64 bytes from vnsc-pri.sys.gtei.net (4.2.2.1): icmp_seq=1. time=21.5 ms 64 bytes from vnsc-pri.sys.gtei.net (4.2.2.1): icmp_seq=2. time=21.6 ms 64 bytes from vnsc-pri.sys.gtei.net (4.2.2.1): icmp_seq=3. time=21.4 ms 64 bytes from vnsc-pri.sys.gtei.net (4.2.2.1): icmp_seq=4. time=21.1 ms ^C ----4.2.2.1 PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 21.1/21.5/21.6/0.22 [erosenbe: dbrd02]/export/home/erosenbe>
With the Solaris built in Ping tool you can specify the packet size, but it is very annoying that you can’t set the do-not-fragment bit. Come on SUN, didn’t you like invent networking??? So in this example I had it send multiple pings, and I told it to use a size of 1500 but I could not set the DF bit so the OS must have fragmented the packets before sending. I got responses back that claim to be 1508 bytes which I am assuming means that the 1500 bytes specified was the payload amount and the returned number of bytes includes the 8 byte ICMP header, but not the 20 byte IP header… Go SUN.
[erosenbe: dbrd02]/export/home/erosenbe> ping -s 4.2.2.1 1500 PING 4.2.2.1: 1500 data bytes 1508 bytes from vnsc-pri.sys.gtei.net (4.2.2.1): icmp_seq=0. time=36.7 ms 1508 bytes from vnsc-pri.sys.gtei.net (4.2.2.1): icmp_seq=1. time=23.2 ms ^C ----4.2.2.1 PING Statistics---- 2 packets transmitted, 2 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 23.2/30.0/36.7/9.6 [erosenbe: dbrd02]/export/home/erosenbe>
Conclusion
Well, I hope this rundown on a number of different ping tools is useful to folks out there and as always, if you have any comments/questions/corrections please leave a comment!
-Eric