Weird Tracert Results

[bluebeard96]

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

[[WebCarnage]]

...try posting the tracert

[bluebeard96]

Here's a screenshot

[DjM]

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

Cheers:

[bluebeard96]

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?

[MrLinus]

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.

[nebulus200]

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...

/nebulus

[bluebeard96]

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.

[DjM]

Why don't you give this graphical traceroute a shot and see what results it passes back.

Cheers:

[bluebeard96]

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?