How to Check Connections between Junos Devices Using Ping
The first thing most people do after configuring their device is check to see whether they can send traffic across links to other nodes within the network. This initial test is where the ping command comes into play.
From the Junos OS command prompt, you can issue the ping command. Log in to the device you want to start from and send a ping to an address on the remote host; that is, to the address you expect to have a path to through the network.
For example, you might log in to router1. From there, you want to ensure that you have connectivity to router7. So you pick any network address on router7 (any of the interface addresses, or even the loopback address will work) and issue a ping command:
user@router1> ping 10.0.24.2 PING 10.0.24.2: 56 data bytes 64 bytes from 10.0.24.2: icmp_seq=0 ttl=62 time=0.520 ms 64 bytes from 10.0.24.2: icmp_seq=1 ttl=62 time=0.417 ms 64 bytes from 10.0.24.2: icmp_seq=2 ttl=62 time=0.497 ms 64 bytes from 10.0.24.2: icmp_seq=3 ttl=62 time=0.424 ms 64 bytes from 10.0.24.2: icmp_seq=4 ttl=62 time=0.501 ms ^C --- 10.0.24.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.417/0.472/0.520/0.043 ms
After you issue the command, the router sends packets to the remote address. When the remote node receives these packets, it generates a response packet and sends that packet back to the original sender.
Upon receipt of this response packet, the router records a successful ping and measures the time between sending the original request and receiving the response. This process happens over and over until you stop the command by pressing Ctrl+C.
You may notice that in the ping output, each ping has an Internet Control Message Protocol (ICMP) sequence number associated with it. Each request and response is flagged with this sequence number so that the devices know which response goes with which request.
If you know that you sent request 3 at a certain time, you can check the time that you receive response 3 and record the time it took for the entire roundtrip.
The ping command gives you a wealth of information. First, you know the remote address that you chose is up and responsive because the command yielded some output. Second, if you examine the summary data at the bottom of the output, you can see important statistics about the path.
For example, notice that five packets were transmitted and five responses were received. This information tells you that all the ping requests were received by the remote device. If the network is having issues or the packets are lost, you will see that not all packets transmitted resulted in a received response packet. The packet loss is an indicator that something is wrong in the network.
Additionally, the summary output shows the minimum, maximum, average, and standard deviations for the response times. In this example, the round-trip transit time for the ping and response is on the order of .500 milliseconds, which is exceptionally fast. If the round-trip time exceeds 150 or 200 milliseconds, you probably want to take a look at the network to determine where the latency is originating.
You may wonder what happens if there is no path to router7 from router1. The ping command reveals that information as well:
user@router1> ping router7 PING router7 (192.168.24.1): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ^C --- router7 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss
In this case, router7 isn’t reachable from router1. The ping fails, and one hundred percent of the packets sent are lost, meaning that there’s no response. To find out whether the lack of response means the router is down or whether a problem occurred somewhere between router1 and router7, you can issue a traceroute command.