Catchpoint's Traceroute test supports several monitor types that rely on different protocols:
- Traceroute ICMP, the protocol that Windows Traceroute uses
- Traceroute UDP, which acts like the Linux/Mac Traceroute
- Traceroute TCP
In addition to the different protocol options, another difference between a command line and a Catchpoint traceroute is the formatting. Below is an example of a Catchpoint Traceroute: 
Each row represents a separate hop indicating every router or system in the path. For every hop you can see the three round trip times (RTTs) in milliseconds (ping 1, 2, and 3), the average RTT, packet loss, IP address, name (sometimes blank if reverse DNS lookup fails to resolve it), AS number, and the status.
The round trip time (RTT) indicates how long a packet took to get from the origin (the location the traceroute was originally sent from) to the destination (the particular router or server it was sent to) and back. Sometimes, one of the three pings will be lost and have an asterisk instead of a number. This can indicate a problem at that router or the path to it from the router before it. In some cases, a hop will have all three pings timeout (asterisks), which may mean there are network issues, or possibly that the router is blocking all the traceroute packets based on the protocol they use. Some routers may block UDP traceroute and not ICMP or vice versa. It can be worth trying both sometimes. A large increase in RTT can be a sign there are issues. The network link or router potentially could be overloaded. One diagnostic option is to directly ping the router where the latency took place.
Packet loss on a particular hop can sometimes indicate there is a problem with that router, but it may also be a problem with the network connection between the previous router and the one where the packet loss is seen. Since traceroutes show the path to the destination, but not the return path, it is sometimes necessary to run a reverse traceroute from the destination to see if the packet loss is occurring on the return path.
Another element of reading traceroutes is interpreting DNS to reveal information such as physical router locations, interface types/capacities, router type/roles, and network boundaries/relationships, which can all be helpful when troubleshooting issues. Geographical locations are most commonly in the form of IATA Airport Codes and CLLI codes.
Knowing the locations of systems can help to see if the routing path is correct or optimal. It also can indicate when high latency is normal. For example, if a hop is across a large distance, locating network boundaries can be useful as this is where routing policy changes generally occur and also tend to be where capacity and routing are most difficult.
Read more about troubleshooting with Traceroutes from author Richard A. Steenbergen at A Practical Guide to (Correctly) Troubleshooting with Traceroute Book and his Traceroute book.
Follow this link to the Troubleshooting Tip on Understanding Wireless Node Testing.