Originally Posted by Fowler
guys I made tracert of connection to Gw server...got this results...Can any1 explain what does it mean?Something doesnt allow to connect?
http://img99.imageshack.us/my.php?image=trace2lz0.jpg |
First, here's what tracert does: It sends three pings to each node between your computer and the destination, starting with the closest node at the top, and proceeding to the farthest node at the bottom. The time (in milliseconds) it took to get a response back for each ping is then displayed. "*" is displayed instead if no response is received. If there's a response, the IP, and possibly domain, of that node is displayed. If there's no response to any of the three pings, "request timed out" is displayed, as the identity is unknown.
A couple other things to know:
(1) Some operators configure their routers not to respond to pings at all. They may be forwarding data just fine, but show up as a black hole when you ping them. Usually you can spot these as a "* * * request timed out" which is followed by normally functioning nodes below it.
(2) Almost all operators who configure their routers to respond to pings give doing so they lowest priority. That means that the times you see for ping response are almost always going to be slower than the times for pure packet forwarding (which is what you actually care about). Sometimes it also means that a router can be dropping ping requests, but still forwarding normal packets without loss (although probably rather slowly).
Reading the tracert printout:
How to tell if a speed is good or not:
Start by figuring out where each of these nodes is located. You can use whois to figure out who owns them. (Edit: You'll have to use RIPE if you're looking for European-owned addresses. You're in Armenia, right?)
Now, do some math. Light travels down fiberoptic cable at about 100 miles per millisecond. So take the distance from you to the first node, in miles, times two, divided by 100. If the results from your tracert much exceed that value, the first node is sticking some lag into the line. (I'd say +5 or 10ms beyond the time it took the light to get there demonstrates a problem; and +50ms or so demonstrates a big problem.) Figure later nodes by the distance from the previous node and the additional time beyond what the previous node took. (Sometimes you may have to account for the previous node forwarding your ping requests to successive routers faster than it answers a ping request to itself.)
A timed-out ping request usually means there's a problem. You need to use other tools to determine if there's packet loss going on, and where. The pathping command can help. Pingplotter (trial version) does a better job, but you have to install it and endure a nag screen after the trial period expires. Even 1% packet loss is unacceptable.
Reading your particular printout:
- The initial 16-18ms on the first hop is a bit sluggish. Unless you're some 800 miles from your ISP, you're getting sub-par service off the bat.
- The time-outs at hops 5 and 7 are a tiny bit worrisome. Test them more thoroughly for packet loss. It's possible, although unlikely, that all of the problems below them are caused by losses at one or both of these hops. Or these could indicate a small problem that's independent of your larger problem(s).
- Hop 9 adds some 320+ ms to the line. This is a big hop -- looks like it's from somewhere in Armenia to Kiev -- but it still shouldn't take anywhere near that long. If the hop's about 1000 miles (my rough estimate), 20ms of that 320ms is legitimate, and the other 300ms is lag. I'd say this is quite probably the source of the biggest problem.
- Hop 10 is probably not a problem, since hop 11 shows up not too much slower than hop 9, the router at 10 is probably just configured not to respond to ping requests.
- Hop 12 might have a bit of packet loss. It would bear investigation if hop 9 wasn't so obviously screwed up.
- Hop 14 is either an even bigger problem than hop 9, or a symptom of hop 9. Either hop 14 is just a black hole that's losing 100% of its packets, or hop 9 is slowing everything down so much that replies from hops 14 and beyond are getting declared lost before they can return. Can't tell from this data.
In short, your problem is probably being caused by these folks:
Originally Posted by RIPE
inetnum: 213.179.224.0 - 213.179.224.255
netname: UKRTELNET descr: Ukrtelecom IP access network in KIEV descr: JSC Ukrtelecom country: ua remarks: E-mail for SPAM and abuse [email protected] admin-c: ARM3-RIPE tech-c: ARM3-RIPE status: ASSIGNED PA "status:" definitions mnt-by: AS6849-MNT source: RIPE # Filtered person: Alexander Remiga address: JSC UKRTELECOM address: 18, Shevchenko blvd. address: 01030, Kiev, Ukraine phone: +380 (44) 246-4416 fax-no: +380 (44) 226-2586 e-mail: [email protected] nic-hdl: ARM3-RIPE source: RIPE # Filtered |
Hope that helped.