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=12885&t=12191
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to