How to Use Traceroute to Troubleshoot a Junos Network
To find out the path that packets take through intermediate hops from source to destination, you can use the traceroute command in the Junos OS.
For example, the network is running the OSPF routing protocol. OSPF calculates a path from router1 to router7 (highlighted on the topology map). If you issue a ping command from router1, the ping fails. But to try to find out exactly where the failure is (the destination router or an immediate hop), you issue the traceroute command.
user@router1> traceroute router7 traceroute to router7 (192.168.24.1), 30 hops max, 40 byte packets 1 router2 (192.168.26.1) 0.869 ms 0.638 ms 0.536 ms 2 router3 (192.168.27.1) 24.968 ms 0.727 ms 0.363 ms 3 * 4 * ^C
The traceroute command works by sending an ICMP packet from the source to the destination node with an initial hop count of one. At each hop, the packet is processed, the hop count decremented, and if the hop count is now zero, the intermediate hop sends a response back to the source letting it know that it was received but the hop count expired.
This information forms the first line of the output (from router2 in this case). Then an ICMP packet with a hop count of 2 is sent out, and makes its way to the second device, and so on until either the destination is reached, a reply to a packet is not received (*), or the hop count (30, in this case) is exceeded.
So as a traceroute process makes its way hop by hop from router1 to router7, you start to see responses showing how that packet is traversing the network. In the preceding output, the first hop along the way is router2. As part of the traceroute process, router1 sends three separate ICMP packets. router2 responds to each of these three as shown in the output.
The output shows the round-trip time for each of the three traceroute packets, which gives you an idea not only of which hops are being reached, but also how long it’s taking to send traffic back and forth between those routers. As with the ping command, you want to keep an eye on the round-trip times to identify latency issues within your network.
In this example, the output shows that responses are being received from router3, but beyond that, nothing is received. Looking at the topology, the next hop in the path is router5. Because the traceroute isn’t receiving a response from router5, you know that the problem is somewhere between router3 and router5. You still don’t know what the issue is, but at least now you know where to look.
It’s tempting to look at the traceroute output shown and say, “Aha! The problem is at router3!” After all, that’s when the good replies stop. But traceroute means that the packets are making their way just fine from router1 to router3 and back. The problem is with the link or router beyond that last good entry.