Knowledgebase

Note:  This is a very simplified process for MTR trace analysis that covers most common issues and misconceptions.  We ask that you provide full MTR trace data in response to any support ticket in which is is requested -- self diagnosis using this article is a great first step, but further information can be derived from the data further down the line.

Issues on the 1st hop:  Keep in mind that more often than not, issues appearing on the first hop are caused by link saturation.  If the site has an ADSL2 connection that's syncing at 11Mbps and that capacity is being used, this may manifest as high or fluctuation latency, or packet loss on the connection.  Be sure to check the modem / router's throughput statistics before investigating further into other areas.

Step 1 - Check for flow-on packet loss

Packet loss can appear in MTR results even when a connection is perfectly healthy - this is particularly common on carrier hops.  Routers on the internet typically deal with anything up to millions of packets of traffic per second, meaning that on occasion they need to prioritize how they are using their resources.  ICMP packets directed at the router itself (such as the ones used in an MTR trace) quite often are treated with the absolute lowest priority, so although the router may be doing it's job just fine - it may drop direct ICMP requests, which an MTR trace picks up as packet loss.

Consider the following examples...

Fig 1.1 - A healthy example showing packet loss

In this example, the host Carrierhop2.carrier is showing 60% packet loss, however all subsequent hops show 0% loss.  In this instance, the connection is happy and healthy and no action is required.

A connection that does in fact have a faulty hop, will look more like this...

Fig 1.2 - A connection with a real faulty hop

Notice in this example, that carrierhop2.carrier shows loss, as does everything after it, including the last hop.  By far the most important loss figure to pay attention to is the last hop -- even if multiple prior hops show packet loss, but the last one doesn't - then there is probably nothing wrong with packet loss on the connection.

Step 2 - Check for latency fluctuations

Even on connections with no packet loss - latency fluctuations can cause interruptions to service, particularly on latency sensitive services such as VoIP and faxing.

Although an average latency figure may be a healthy 40 - 80ms, there may be peaks that are more difficult to detect using a standard ping.  This is where the data from an MTR trace can be invaluable in identifying a periodic latency fluctuation issue.

Consider the following examples...

Fig 2.1 - Fluctuation in latency (first-hop connection or contention issue)

In this example, all hops beyond the first hop (the first hop being the router accessed via LAN) have high values for "Wrst" (Worst / Highest latency).  This indicates that the latency on the internet connection at the site is spiking.  Regardless of the average, best and last values - if the worst value is consistently coming up high across multiple MTR's, there may be an issue to look in to on the connection at the site itself.  

Fig 2.2 - Fluctuation in latency (ISP, carrier, or Neural issue)

In this example, only hops further away from the site connection are showing high latency worst values.  In this instance you'll need to escalate the issue to the first hop showing the issue.  For example, if the hop belongs to your ISP, they will need to be advised - however if it's further on (a carrier or on the Control Networks' network) then you will need to advise us via our support channels.

These are the most common issues that can be identified with an MTR trace and this is by no means an extensive list, nor is it accurate in all occurrences.  If in doubt, or if requested by our support team, please be sure to send the MTR trace through in reply to your support ticket, or open a new one via ithelpdesk@controlnetworks.com.au