Good point!
When I looked in to it, I used a sniffer to work out what was happening, by
capturing one of the packets of a traceroute and used the traffic generator
to send the packet at different intervals.
I managed to work out that the cut-off time seemed to be around 500ms but
didn't know why at the time.
Eventually found a handy little page which described what was happening and
also included various other scenarios. Doesn't rear its head very well when
searching for traceroute, but found it while looking for icmp unreachable.
Taken me a while to sift through for it again tonight. Bookmarked it now -
it's quite handy.
Worth a look:
http://www.cisco.com/warp/public/105/traceroute.shtml#unreach
Regards,
Gaz
""Priscilla Oppenheimer"" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I agree with everything you say in your answer, Gareth. I noticed he did
> not say if he was doing a trace route to a Cisco router, however, so I
just
> wanted to add that the sending of port unreachable messages is not
reliable
> on other systems also. It's not "reliable" on Cisco routers and other
> devices because they rate limit. It's not reliable on Windows 98 because
it
> seems to simply not send the port unreachable, from my experience. Try a
> Cisco or Unix trace to a Windows 98 device. You'll hear from every router
> on the route and then you'll hear nothing until the trace times out.
>
> Note that Microsoft uses an ICMP echo instead of a UDP probe, so trace
from
> Microsoft doesn't have this problem.
>
> I haven't seen X as a result! That's a new one! Are you sure you saw X? I
> can't find that one documented anywhere, but the Cisco documentation on
> what you see as a result of ping or trace doesn't match what you really
see
> in the field.
>
> Priscilla
>
> At 06:41 PM 9/4/01, Gareth Hinton wrote:
> >One of those that you see happening for years but never really bother to
> >find out. I was on TAC support one day when a customer asked the same so
I
> >had to go and find out:
> >
> >The answer is:
> >
> >On Cisco routers, there is a rate limit on replies of ICMP port
unreachable
> >of 500ms for prevention of DOS attacks.
> >So basically this is what happens with a sequence of 3 packets to the
last
> >hop:
> >
> >CiscoA sends a UDP packet to CiscoB with destination port 33434 and gets
a
> >response, so immediately sends another UDP packet with destination port
> >33435.
> >This time there is no response because the final router will not respond
> >with another ICMP port unreachable for at least 500ms. Router A will wait
> >for 3 seconds for a reply, just in case.
> >CiscoA then sends the third UDP packet with destination port 33436 and
gets
> >a response, because router B's 500ms timeout has expired.
> >
> >The reason that this only happens on the last hop is because all other
> >responses along the way are TTL expired, as opposed to the last hop which
is
> >an ICMP port unreachable.
> >
> >If you've got an IOS of 12.1 or after you can control the timeout with:
> >
> >ip icmp rate-limit unreachable
> >no ip icmp rate-limit unreachable
> >
> >A little bit of useless (or maybe not) information, but amazing how often
> >the question crops up.
> >
> >
> >Hope this helps,
> >
> >Gareth
> >
> >""Tay Chee Yong"" wrote in message
> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > Hi,
> > >
> > > May I know why is it that whenever we do a traceroute to a
destination,
> >the
> > > last hop will sometimes have a "!X" instead of the TTL value returned?
> > > Sometimes it will also have an "*" at the last TTL value, why is this
> so??
> > >
> > > Is there any document on the net that explains the above mentioned
issue.
> > > Would appreciate some guidance. Thanks.
> > >
> > > Regards,
> > > Cheeyong
> ________________________
>
> Priscilla Oppenheimer
> http://www.priscilla.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=18534&t=18347
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
