Found the explanation eventually. I'm quite chuffed with how close I got to
it. Unusual I know. Maybe I'm learning this Cisco stuff, but probably just
lucky.
There is a rate limit on replies of ICMP port unreachable of 500ms for
prevention of DOS attacks.
http://www.cisco.com/warp/public/105/traceroute.shtml#unreach
Quite a handy URL for Traceroute in general.
Gaz
""Gareth Hinton"" wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hi Tony / All,
>
> I've been having a think about this and not really got an answer yet, but
a
> little info from some traces.
> I've attached two 2500 router ethernets directly (crossover) and they act
as
> previously described. i.e. One response, one failed, one response, one
> failed, on the final destination router.
> I connected a hub in between and put a sniffer on.
>
>
> 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, even though it waits 3 seconds for it.
> CiscoA then sends the third UDP packet with destination port 33436 and
gets
> a response.
>
> This seems to point at some sort of time out on the destination router,
> rather than the fact that the port may not be responding. It is after all
a
> different port each time, and the port is not responding anyway.
>
> To test the timeout, I copied the packet sent from CiscoA, and generated
it
> at varying intervals from my laptop.
> Round about 500ms seems to be the cut off. If I put a delay of 500ms, all
> packets are replied to.
> If I put a delay of 450ms, every other packet is not replied to.
> As the round trip time is around 1ms, this should be fairly accurate.
>
> The extended trace does not seem to give the option of send delay. It only
> seems to allow a timeout value (which is what is allowing alternate
> replies).
> I have not been able to find any configurable value for any kind of hold
> down time for ICMP port unreachable. I am guessing that this is some sort
of
> DOS attack prevention method?
>
> Incidentally, the problem is the same for ICMP Host Unreachable responses.
> The ICMP TTL exceeded in transit response does not seem to have the same
> hold down time, which explains why all but the final router give full
> responses.
>
>
>
> Does anybody know what this timer is, and whether it can/should be
> changed???????????
>
> As far as I am concerned, if I can confirm that this is what's really
> happening, I'm happy to leave it be.
>
>
> Thanks,
>
> Gaz
>
>
>
>
>
>
>
>
> ""Tony van Ree"" wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Hi,
> >
> > This is Normal behavior. The device exists the port does not.
> >
> > On Friday, July 13, 2001 at 09:43:11 AM, Hire. Ejay wrote:
> >
> > > Pardon my ignorance, but would you happen to be using unnumbered
> interfaces
> > > to connect theses routers?
> > >
> > > -E
> > >
> > > -----Original Message-----
> > > From: Joseph Higgins [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, July 13, 2001 1:24 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Trace failure indication [7:12191]
> > >
> > >
> > > This problem shows up on any cisco router that I have tried, about 20
> > > routers. It appears from a debug packet and debug icmp on the final
> > > destination router that the final destination router still has the
port
> > open
> > > while it is handling the previous trace probe. I want to know if
anyone
> > can
> > > get this to work correctly and if not where is this normal error
> indication
> > > documented. Following is a trace with a probe count of 15. I have
> > included
> > > the debug output from the destination router.
> > >
> > > termsvr#trace
> > > Protocol [ip]:
> > > Target IP address: 192.168.10.2
> > > Source address:
> > > Numeric display [n]:
> > > Timeout in seconds [3]:
> > > Probe count [3]: 15
> > > Minimum Time to Live [1]:
> > > Maximum Time to Live [30]:
> > > Port Number [33434]:
> > > Loose, Strict, Record, Timestamp, Verbose[none]:
> > > Type escape sequence to abort.
> > > Tracing the route to 192.168.10.2
> > >
> > > 1 192.168.10.2 16 msec * 20 msec * 20 msec * 20 msec * 20 msec *
> 20
> > > msec
> > > * 20 msec * 20 msec
> > > termsvr#
> > >
> > >
> > > Result of debug packet and ICMP on 192.168.10.2
> > >
> > > 01:26:14: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:14: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:14: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > 01:26:14: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:17: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:17: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:17: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > 01:26:17: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:20: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:20: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:20: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > 01:26:20: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:23: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:23: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:23: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > 01:26:23: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:26: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:26: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:26: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > 01:26:26: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:29: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:29: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:29: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > 01:26:29: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:32: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:32: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:32: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > 01:26:32: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:35: IP: s=192.168.10.1 (Serial0), d=192.168.10.2, len 28, rcvd 0
> > > 01:26:35: ICMP: dst (192.168.10.2) port unreachable sent to
192.168.10.1
> > > 01:26:35: IP: s=192.168.10.2 (local), d=192.168.10.1 (Serial0), len
56,
> > > sending
> > > r1#
> > --
> > www.tasmail.com
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=12896&t=12191
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
