Traceroute is a core diagnostic program for testing connectivity across interconnected IP protocol networks. It does exactly what it says on the tin, and traces the route through the interconnected networks that a packet gets routed, from source to destination, and how long it takes to get between each "Stop". Basically, you can imagine your packet of data as being like a letter being sent to some other address. When you put it in your mailbox with the flag up, the mailman picks it up, and takes it to the local post office, where it is scanned, and sorted for outbound transport to another post office further down the line. Much like tracking which post offices the letter goes through, and how long it takes between each stop, the traceroute command traces the route a packet takes between routers on its way to a destination, and how long it takes for it to get there.
Here's how to run a traceroute session.
On windows, fire up a CMD session.
Start->Run->CMD.EXE
This will give you a DOS like prompt.
On the command line, type:
tracert X.X.X.X
Where X.X.X.X is the IP address of the remote host. You can also just type the address, if you dont know the raw IP, eg, "tracert
www.google.com".
The result will be a table of addresses, usually in a long dotted name format, like this:
The first stop in the example, is the local router. "192.168.1.1". That is the thing that my counterpart claims is "A plastic box filled with rocks." I dont doubt this assessment, but as long as it is passing data through to the next router in the hop list, we know it isn't the problem.
Next on the above sample, the packet filters its way through the local ISP's local distribution tree, which apparently doesnt like traceroute queries, or isnt configured to respond to them. (Not surprising- see previous post about ISPs being dickweeds.) It first passes through "219.88.64.1", with a nameserver ident string indicating it is from the ISP "Jetstream", where it gets passed around that network's netblock (210.x.x.x-219.x.x.x). It runs into a router that doesnt want to report traceroute data, where the request for tracking times out. The next hop is more polite, and actually responds to the query. The next hop is inside a different network, (202.x.x.x), where it bounces around in there, before being passed to the next network (198.x.x.x -199.x.x.x), "Gnaps", then to the next network, "gbr", (207.x.x.x-209.x.x.x), which has a direct connection to what looks to be a class C commercial private IP as the destination.
Because the packet can be seen crossing several networks before getting to the destination, we know that not only is the above person's local router being a good little box of rocks, their ISP isnt being total dillholes either, and is actually routing their packet like a good little dumb pipe.
A traceroute that fails, will show nothing but timeouts after the network that drops the packet. This lets you know where in the "Between A and B" the packet gets boot stomped. This can happen for a number of reasons, including congestion of the link, making the packet's "Time to live" expire, and thus, for the directing router to deep 6 the packet as too stale to deliver, (Each packet is blessed with a maximum life expectency when it is created and shipped out called the
Time to Live. This is the maximum number of milliseconds that can elapse from creation to delivery before the packet is considered too stale to deliver, and gets the deep-six. This is a safety mechanism for automatically reconfiguring TCP/IP networks, like the internet-- which update and change routes based on congestion and deliverability thresholds, and prevents a packet from getting "The run around" between routers who insist that "The other guy" knows how to deliver the packet, when they really don't. When the packet gets bounced around enough times, it is simply discarded, to avoid it being passed around indefinitely while the network reconfigures its routes with the APT protocol, and disrupting the network for other users. While having your packets time out is an annoyance some times, it is considerably better than having zombie packets clogging up the pipes, left undelivered from 1980!) If the router takes too long to process and ship out the packet, the time to live will elapse, and the packet will be discarded. Traceroute lets us determine if, and where, this is happening.
If the traceroute comes back consistently healthy, then we need to start suspecting shenanigans from the ISP. Doing a wireshark packet capture and analysis is not for the layman, as it is a pretty advanced network tool. (Unlike traceroute, or ping.) It also doesn't come stock on windows OR linux, and requires manual installation. Most users will never have a real need to use something like wireshark, unless they are also managing a multi-router domain, like inside a massively huge office building-- which again, makes them not a normal user. It is however, the only way to catch the ISP doing the nasty to your packet stream, as it will collect and log the complete packet correspondence between two communicating hosts, and much much more if you set it up to do so. Interpreting the resulting data requires a pretty complex education in network protocols, and networks in general. In short, its an expert tool, made for use by experts.
I personally *AM* a trained network administrator, (Previous field of employment was IT.) and am able to read such packet traces. I dont really want to read somebody else's packet traces, as I changed careers for a reason.
If the packet is being lost outside your local router, then fiddling with your local router wont fix the problem. The traceroute will show you where the timeout is occuring. If the timeout is happening before it leaves your ISP, then your ISP is being a bunch of assholes, performing
"Traffic shaping". That's the "Polite" way of saying "We are slowing your shit down so some other traffic we think is more important can get routed first (like from our streaming movie service, or VOiP telephone box traffic!), and we dont care if this causes your packets to time out. In fact, we actually WANT your packets to time out, so you wont try to use that kind of service anymore, because it costs us money." Comcast is NOTORIOUS for its traffic shaping efforts.
So, again, I would perform a traceroute to the host that is having timeout problems, to see where the timeout is occurring.
Author
Topic: Tech support! This one website keeps timing out. (Read 3067 times)