Is tracert reliable?

It's about time I ask this questions, as I have been meaning to post this a while ago. I wasn't sure if this should go in the CCXX forum. I'm a bit embarrassed that I have to ask.

TL;DR version: Can use tracert command to truly test latency and packet loss issue?

I work in a call center, and we work with VoIP customers having trouble with their phones. One of the most frequent issues is the network, which we cannot resolve, but referred them to their ISPs for packet loss, jitter, and latency issues.

Before we even refer them to the ISP, we'd run test to make sure that it's definitely at their ISP's end. My colleagues would run tracert command on Windows to see if there's a problem along the way to the customer's public IP address where their modem/router is. They'd use this to test the latency and packet loss issues, which I thought was an inappropriate use of the command since some of the hops along the way would block/discard ICMP, and doesn't accurately reflect the evidence of the issue.

I never bother using the tracert command, and I'd only ping directly to the customer's public IP if ICMP is not blocked. If this is also not the correct approach, then I'd really like to know since I have no in-depth understanding about how latency works to be honest. This is probably something a VoIP/telecommunication engineer would know. Advice and links to good resources would be helpful since we'd like to know how to get the ISP to identify the same issue customer's experiencing. I'd hate to have us keep making the same mistake, and it's time we get to the bottom of this.

Find more posts tagged with

Comments

Priston

If you ping directly to the customer's public IP and there is latency, you don't know where the latency is starting.

With tracert you will see the latency at each hop.

12 27 ms 26 ms 28 ms 64.xxx.xxx.xxx
13 39 ms 33 ms 33 ms 74.xxx.xxx.xxx
14 * * * Request timed out.
15 45 ms 35 ms 34 ms 8.8.8.8

http://www.inmotionhosting.com/support/website/how-to/read-traceroute

hiddenknight821

Right. I understand latency just that much when pinging to a single gateway, but I could never interpret the output I'm seeing as a whole. IIRC, tracert never always take the same route to the customer's network. So does that mean each hop is irrelevant and I should only be concerned with the last hop?

Priston

I edited my post with a link. Also tracert will only take different routes if a routing protocol with load balancing is in use. (like EIGRP) If the issue is with the ISP and you want to prove it's an issue with the ISP you should be concerned about the ISP hops.

hiddenknight821

That link was actually very helpful. Most articles on the web just plainly suck.

I was hoping I'd find an answer to what happen if I get too many timed out. Would a good rule of thumb is to stop the tracert after a 5th timeout line?

Russell77

You will need a lot more than ping and tracert to deal with this kind of problem. The main issue is that if you have voip running over the open internet you have no QOS and the customers ISP is only responsible for issues between the customers modem and their own routers. Beyond that it is best effort.

Ping and tracert can help some but in general testing needs to be run from the customers end pointing to the border gateway where the voip traffic is going. The way many people handle these issues is to load a network assessment on a customers pc and let it run for a few days to see when and what is going on. This in conjunction with the customer keeping logs of when and how calls are failing can at least give some idea if the issue is in the Lan or the Wan. Some ISPs have periodic congestion and getting someone to do anything about that is a big challenge. Bonded services can also be problematic. On the internal side Firewalls and Nat issues tend to be the biggest points of failure QOS should be set up internally at least but settings for each vendor and protocol can be all over the map. It is trial and error until finding the best local set ups.

I wish I could paint a rosier picture but it kind of comes down to how lucky the customer is. If they have good network and a rock solid internet pipe with enough bandwidth they will probably be ok. If they don't they will never get to where they want to be. Some deal with it and some move on.

Mike7

Since you are on Windows, you can try the pathping command. Think of this as a combination of ping and tracert.

As the previous poster mentioned, a more thorough testing is required.

negru_tudor

If you've a "tunnel" or some sort of VPN to the CPE border element, you could try something like IP SLA probes assuming you're using Cisco kit

IP SLAs Configuration Guide, Cisco IOS Release 15M&T - Configuring IP SLAs UDP Jitter Operations [Cisco IOS 15.4M&T] - Cisco
https://routerjockey.com/2011/05/06/ip-sla-basics/

They're very easy to set up and offer some pretty useful info. I've used them a couple of times in live environments and you can also test them in GNS3. The ones you're interested in are called "jitter probes".

Good luck

hiddenknight821

Russell77 wrote: »

You will need a lot more than ping and tracert to deal with this kind of problem. The main issue is that if you have voip running over the open internet you have no QOS and the customers ISP is only responsible for issues between the customers modem and their own routers. Beyond that it is best effort.

Yes, you assumed correctly. I should add that we design our own devices that isn't just voice-based, but also transmitting video. As you can see why it's important that our customers do not experience packet losses and jitters. The pictures would be terribly distorted. It's easy to refer our customers to their ISPs when the speed isn't up to par.

So if the hops that aren't the responsibility of the ISP are problematic, then that'd suck for us and the customers as it's clearly out of our control. We'd tell customers to switch ISP as last resort, which probably won't even help if the packets still end up being routed to the same place. We sometime feel bad for our customers living in the country.

I really like your network assessment suggestion, but not every customer we deal with has a computer. We've thought about suggesting our designers to incorporate the assessment software in our products but we were unable to do so since we also have business customers in public and private sectors that'd not want this feature built-in due to potential security breach.

Mike7 wrote: »

Since you are on Windows, you can try the pathping command.

Cool command. Just learned something new. Although I see this command takes time I can't afford to spare.