Troubleshooting an issue with your internet provider can try anyone’s patience. Though for me, it’s challenging because I know some of the steps they are scripted to use are not relevant. This article is a tale of how Message Analyzer cut a troubleshooting session short, and saved me valuable time.
If the internet doesn’t work, the solution is sometimes more clear. “You can’t get there”, or “you can’t do that” often directly results in “reset this” or “X Service is down”. From a network perspective, Message Analyzer can find these issues, given some simple network background. But performance issues can be more tricky and subtle. Yet some network problems can’t hide from Message Analyzer.
I think I sweat a little before I have to call for any kind of service. I’d rather try and troubleshoot things myself first. In this case, my network was working fine last Friday. Over the weekend, we tried to watch Monster Inc on Demand, but that was also having issues. Now, Monday morning, I’m having issues on my desktop machine. File transfers are slow from my VPN connection, so I disconnect it. I tried a video on a web page; it doesn’t even start. Then a Speed test, which also doesn’t start. So I now I call the dreaded ISP customer support.
They greet me and ask my problem, where I provide them, I’m guessing, a little too much information. This is where frustration starts. Without taking any account of what I said, we started through a script of which the first step is to tell me I probably need to replace my wireless router. . . a little premature I think. Next, after some simple questions, I’m required to hook up a laptop, via a wired connection, directly to the modem. I don’t know about you guys, but my wire closet is not a comfortable place to work, but I begrudgingly complied, as I knew this would rule out my Wireless network. I got my laptop connected, and now I see the same slowness with the WiFi router taken out of the picture. At this point, I expected the tech to say it’s a network problem, but now I was asked to shut off the Firewall next. Now, I’m not %100 certain that this couldn’t be a firewall issue. But that seemed like a strange suggestion to me given what we knew. So as I already had my laptop connected, and Message Analyzer was sitting right there, I fired off a Link Layer trace with the NDIS provider.
A main theme with Message Analyzer is to bubble up problems to the highest layer. This is important, because we coalesce traffic, which can hide the raw network frames. Bubbled up information is a first indication that something could be wrong. I had gone to a web page, so I filtered on HTTP, and the following is what I see:
The diagnostic data provides the evidence that there is massive packet loss. Next, I opened the Diagnosis viewer from the Message Analyzer Tool Windows drop-down, which provides a summary of all diagnosis messages. By changing the Viewpoint to TCP, I can further narrow down the diagnosis messages which come from that layer and below.
Next, I quickly created a chart to map the ratio of TCP Diagnosis messages vs the overall count. I’ll have to fill in more details with a future blog, but I started by using the Chart ribbon and devised the following grid chart. Notice that the ration is often over %50, which is pretty bad.
At this point, with the tech typing furiously on the other end, I asked if they see packet loss on their end. Within a few seconds, he came back and said, “yes I see packet loss, let’s send out a technician.”
With that piece of ammo we could blame the Cable Modem or something upstream towards the provider. Rather than wait for the technician the next day, I was able to go to the Cable company office in my town and replace the modem, which resolved the problem. Apparently they go bad sometimes. It is certainly nice to have positive proof like this with Message Analyzer, to help win battles with ISP support folks.
To learn more about some of the concepts described in this article, see the following topics in the Message Analyzer Operating Guide on TechNet:
Quick question - couldn't a ping or traceroute have shown you the massive packet loss?
Ping and Traceroute measure the response times, and traceroute shows you the route a packet takes. These will show when one of these packets are dropped. However, it's not exactly related to packet loss though could be correlated. Actually in this case, PING was one of the steps we took, which showed good response times and no losses. In this case, it seems, it took more stress to show the problem which only occurred when we did the speed test or accessed other web pages.