Sunday, August 05, 2007

Producing a PathPing Log For Analysis

Many network problems that affect your use of Blogger, such as the currently obnoxious "Server Error 1-500", can be better understood, if we can understand how you are connecting to Blogger. A pathping log, similar to a traceroute log, but easier to read, is very useful in this case.

(Note): A pathping log is easier to read than a traceroute log. Pathping is a new utility, though, and may not be available on all computers. If you try to run pathping, as in the instructions below, and get an error
'pathping' is not recognized as an internal or external command, operable program or batch file.
or similar, substitute a traceroute log.

Here we have pathping targetting "www.google.com". Choose your target according to your need.
  1. Open a command window.
  2. Type
    pathping www.google.com
    at the command prompt. Observe the output (as in the sample shown below), particularly the "Computing statistics for 200 seconds...". This time period appears to vary, depending upon the complexity of the path between you and the target, for statistical accuracy.
  3. Type
    pathping www.google.com >c:\pathping.txt
    at the command prompt.
  4. Wait patiently, while pathping runs again. Having done step 2, you will know how long to expect to wait.
  5. Type
    notepad c:\pathping.txt
    at the command prompt.
  6. Copy, and paste, the entire log, as displayed in Notepad, into your email or forum post. Please don't munge, or disguise, any details.
It really is simple - when you know how. Just be generous - and precise (see the spaces in the commands?).

Here's a sample log.
C:\>pathping www.google.com

Tracing route to www.l.google.com [74.125.19.103]
over a maximum of 30 hops:
0 PChuck1.martinez.cacroll.net [192.168.1.1]
1 209-204-140-9.dsl.static.sonic.net [209.204.140.9]
2 111.at-4-0-0.gw4.200p-sf.sonic.net [208.106.28.177]
3 0.as0.gw3.200p-sf.sonic.net [64.142.0.225]
4 200.ge-1-2-0.gw2.equinix-sj.sonic.net [64.142.0.210]
5 eqixsj-google-gige.google.com [206.223.116.21]
6 209.85.252.2
7 209.85.251.94
8 74.125.19.103

Computing statistics for 200 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Dell1600.martinez.cacroll.net [192.168.203.101]
3/ 100 = 3% |
1 37ms 3/ 100 = 3% 0/ 100 = 0% 209-204-141-1.dsl.static.sonic.net [209.204.141.1]
0/ 100 = 0% |
2 33ms 3/ 100 = 3% 0/ 100 = 0% 111.at-4-0-0.gw4.200p-sf.sonic.net [208.106.28.177]
0/ 100 = 0% |
3 40ms 3/ 100 = 3% 0/ 100 = 0% 0.as0.gw3.200p-sf.sonic.net [64.142.0.225]
0/ 100 = 0% |
4 42ms 5/ 100 = 5% 2/ 100 = 2% 200.ge-1-2-0.gw2.equinix-sj.sonic.net [64.142.0.210]
0/ 100 = 0% |
5 35ms 4/ 100 = 4% 1/ 100 = 1% eqixsj-google-gige.google.com [206.223.116.21]
0/ 100 = 0% |
6 41ms 3/ 100 = 3% 0/ 100 = 0% 209.85.252.2
3/ 100 = 3% |
7 42ms 7/ 100 = 7% 1/ 100 = 1% 209.85.251.94
0/ 100 = 0% |
8 45ms 6/ 100 = 6% 0/ 100 = 0% 74.125.19.103

Trace complete.


Q: Chuck, this is nice and shiny. But what does all of this gobbledegook do for me?

A: This is similar to a traceroute log, but it's better organised. What you see above is 2 sections, and either section may be useful, depending upon your problem.
  • The top section describes the path between you and the target. By observing the physical location of each node in the path, we can get an idea of what physical connections are involved between you and the target. This is extremely valuable when looking for regional outages.
  • The bottom section statistically analyses the connection between each pair of nodes, and shows percentages of dropped packets. When there's a specific link between you and the target, that's unreliable, this section helps to isolate the unreliable link.


Combining the path, and the reliability statistics, we can see if a given problem is unique to your end of the network, to the overall Internet infrastructure, or to the network at the target (maybe Google) end. This is how network troubleshooting starts, and your contribution may help us isolate a major problem.

>> Top

2 comments:

bytehead said...

One thing. Comcast has mucked my settings. My IP has changed (not a big deal, I use DynDNS service) and the router I'm connected to won't repond to a traceroute or a pingpth! And the pingpath just stops after that point. At least the traceroute keeps going till it either hits the terminating IP or 30 steps.

I haven't played with pingpath much, so there might be a setting for that. I'm from old Unix days (and hence call it traceroute as it's known - DOS/Windows uses tracert and OS/2 uses tracerte (yes, that was a pain when I was using both OSes so I renamed the OS/2 command)).

Seeing what was going on was the only thing where I noticed my address had changed. My records showed I had my old address since Feb. 1. I normally run something at around 11PM to check, but since this is a new machine, I hadn't set that up. Till now. :/

Chuck said...

Your problem will be best addressed within an open forum - I recommend the DSLR Networking forum. Please register - it's free and the people there are very helpful.
http://www.dslreports.com/forum/sharing