March 7th, 2003, 08:56 PM
Weird Tracert Results
I can't log onto my mail server right now, so I was doing a tracert and saw something I haven't seen before (doesn't mean it's not an easy, everyday thing... just new to me!).
Tracing route to myHostName [ip.add.re.ss]
What is weird to me is that hop #24 hits the correst hostname and IP, with results of 90ms, *, and *.... but the tracert continues past the apparent destination!?!?
Hops 25-29 all time out and no hostname/ip is given, then hop 30 again is the same hostname/ip that I requested (and was hit on hop 24.
Make sense to anyone?
/me braces for a lame ass answer that will want to make me put my head in a hole
March 7th, 2003, 08:59 PM
...try posting the tracert
...This Space For Rent.
March 7th, 2003, 09:03 PM
March 7th, 2003, 09:14 PM
Just a guess, but it look's like your trace is configured to do 30 hops regardless of how many it takes to get there. If this is the case then it will always attempt 30 hops.
Again, just a guess
March 7th, 2003, 09:33 PM
If I trace something in my internal network it'll stop at 1 hop. A trace to www.yahoo.com ends at 12 hops. I think the max might be 30, but it's whatever win2k tracert does automatically... I haven't cofigured anything. Any other ideas?
March 7th, 2003, 09:35 PM
Hrmm.. I thought it was going to the 30 because it didn't get an absolute final result. The * * * sometimes indicate "hidden" devices that aren't responding but passing packets on. It will stop once it hits a final device (namely whatever you are attempting to do the traceroute/tracert on).
From the looks of things there may be a device near the mail server that might be overloaded, down or looping.
March 7th, 2003, 09:48 PM
If I had to make a guess, that server is overloaded and is dropping packets. Everything along the route looks really clean, good speed, no apparent lost packets; however, as soon as it hits the server, packet loss. It is my understanding, that if a server is loaded, one of the first type of packets that will be dropped is ICMP (which tracert partly uses (it uses TTL expired, to figure out hop))...
I would put in a call to the system administrator...even if it is a LAN problem (like a malfunctioning switch, they should still be able to talk to the right people and get it fixed). Certainly appears like the problem is on their end...
There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.
(Merovingian - Matrix Reloaded)
March 7th, 2003, 10:02 PM
I could agree that the server isoverloaded. My concern is the same IP on two different hops (and maybe on 25-29 inbetween as well). It seems more like a loop (like MsM suggested) that is probably subsequently causing the overloading and lack of response.
Since I haven't studied it very extensively, what would some of the normal behaviors be? I would think that if the server responded to the first ICMP, but timed out on the second two (as can be seen on hop 24 in the tracert), wouldn't you be done right then? Isn't that the IP I wanted? I would think that one of two things should happen when a hop reaches the destination IP... either we get successfull reponse times (even if we only get one good response and two timed out responses, like the 90ms,*,* on hop 24) or we get a destination host unreachable. Am I wrong to assume that?
I think that this tracert should never have gotten to hop #25. I think something is screwy in the way they're handling the icmp which is causing it to loop and slow down their server. But that's just a rookie guess.
March 7th, 2003, 10:07 PM
Why don't you give this graphical traceroute a shot and see what results it passes back.
March 7th, 2003, 10:18 PM
Graphical Tracert shows HopOne has a loop
Very interesting. Of course my providors phone is busy right now, so I can't do jack.
In theory, though... shouldn't the non-graphical tracert done the same thing as soon as it hit one of the same machines this route hit?
For example... why does this graphical trace loop back and forth betwwen two hopone IPs while the tracert I posted earlier apparently resolved to the destination IP at a point past this trace?
Or do the different traces mean they're frantically trying to fix it and the routing is being reconfigured as I'm doing these traces?