Not So Simple tools - Ping

One of the conversations that I've had many time over the years is regarding one of the most commonly used and misused tools ... ping. Each network operating system seems to handle ping differently, causing frustration for many operators. That said, there are a few things about ping that will make the tool more useful for you in your Juniper journey.


The first is size ... a major difference between Windows (Windows 7 in this case), Cisco and Juniper is what you're specifying when you type the word size. In troubleshooting, knowing the difference can help isolate a link with a misconfigured MTU

In Windows, the length specified is the ICMP Data, so the command "ping -n 1 -l 1000 thegnurd.blogspot.com" would result in a ICMP Data field of 1000 Bytes, 8 Bytes of ICMP Header, 20 Bytes of IPv4 header, and 14 Bytes of Ethernet header, giving a total of 1042 Bytes on the wire.

With Juniper (and most variants of Linux), the command "ping thegnurd.blogspot.com count 1 size 1000" would yield 1042 bytes on the wire in a slightly different way. While the Ethernet header and the IPv4 header would remain the same, with 34 Bytes of data, the ICMP header contains an 8 byte timestamp field, reducing the size of the payload by the same giving a ICMP Data field length of 992 bytes.

With Cisco, when you specify the size with the command "ping thegnurd.blogspot.com size 1000"  you wind up with 1014 Bytes on the wire, as the 1000 specified is the combination of the IPv4 header (20 bytes), ICMP Header (8 Bytes), and the ICMP data field (972 Bytes).


Now that we have the confusion cleared up about size, the next thing is source. One of Juniper's best practices involves configuring a system option known as default-address-selection. The purpose of this setting is to have all traffic sourced from the routing engine (syslog, NTP, SNMP, ping etc) use the loopback address. This is great (most of the time) but can have some unintended consequences when it comes to testing and troubleshooting a network. As you can see from the below examples, failing to source the appropriate interface can cause traffic to take a less optimal route around the network, perhaps bypassing the link that you are trying to test. If I was concerned about packet loss on the Ethernet link where the 1.1.1.0/31 network resides, and ran the first ping without record-route, I would reasonably expect that everything was fine, assuming the rest of the network were operating normally.


cstewart@router> ping 1.1.1.1 record-route count 1                         
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=7.789 ms
RR:     1.1.1.1
        1.0.0.4
        1.0.0.5
        1.0.0.6
        1.0.0.9
        1.0.0.3

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.789/7.789/7.789/0.000 ms



cstewart@router> ping 1.1.1.1 source 1.1.1.0 record-route count 1 
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=5.337 ms
RR:     1.1.1.1
        1.1.1.0

--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.337/5.337/5.337/0.000 ms

The final ping option that I want to cover in this post is rapid, which is a slightly less aggressive version of the linux "ping -f" option. The rapid option, which requires that a count be specified, allows an operator to generate a significant amount of ICMP traffic. Because of that, due caution should be exercised when using this option, especially with low bandwidth links, or on links where bandwidth is constrained. 

Enjoy!

-Chip