Re: Trace failure indication [7:12191]
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 (l
Re: Trace failure indication [7:12191]
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, sen
RE: Trace failure indication [7:12191]
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=7i=12430t=12191 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Trace failure indication [7:12191]
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# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=12264t=12191 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Trace failure indication [7:12191]
When I trace from a cisco router to another Cisco router I get a timeout failure every other probe on the last hop It fails on every type of cisco router I have tried, 7513,25xx abd 36xx. I think that it must be normal but I cannot find anything in the archives here or at the Cisco site that says it is normal? See following where I do a trace between two routers on connected interfaces. * 4 msec * 4 msec * 8 msec * 8 msec r1#trace Protocol [ip]: Target IP address: 192.168.10.1 Source address: 192.168.10.1 % Invalid source address r1#trace Protocol [ip]: Target IP address: 192.168.10.1 Source address: 192.168.10.2 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.1 1 192.168.10.1 4 msec 4 msec * 8 msec * 4 msec * 4 msec * 4 msec * 8 msec * 4 msec * r1# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=12191t=12191 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Trace failure indication [7:12191]
Have you checked duplex? Sometimes speed and duplex settings have a similar effect. Things seem to work properly, but you are dropping packets which slows the application down. Obviously if you have one end at 10 and the other is at 100, you will run into major issues, but sometimes autonegotiation is flakey. If you are using auto on both devices, check the interface for speed and duplex it auto'd to. If this is across a serial link, what is the bandwidth? Also, is this a core router that stays fairly busy? what is it's utilization? Sometimes routers will drop pings if they are busy. -Patrick JHIGGINS 07/12/01 04:01PM When I trace from a cisco router to another Cisco router I get a timeout failure every other probe on the last hop It fails on every type of cisco router I have tried, 7513,25xx abd 36xx. I think that it must be normal but I cannot find anything in the archives here or at the Cisco site that says it is normal? See following where I do a trace between two routers on connected interfaces. * 4 msec * 4 msec * 8 msec * 8 msec r1#trace Protocol [ip]: Target IP address: 192.168.10.1 Source address: 192.168.10.1 % Invalid source address r1#trace Protocol [ip]: Target IP address: 192.168.10.1 Source address: 192.168.10.2 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.1 1 192.168.10.1 4 msec 4 msec * 8 msec * 4 msec * 4 msec * 4 msec * 8 msec * 4 msec * r1# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=12192t=12191 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Trace failure indication [7:12191]
Hi, I think you'll find this is quite normal. The device exist #msecs , port non-existent *, device exists #msecs and so on. Basically the device exists but the socket you are attempting is not open. Spot on trace I'd say Just a thoought Teunis, Hobart, Tasmania Australia On Thursday, July 12, 2001 at 04:19:43 PM, Patrick Ramsey wrote: Have you checked duplex? Sometimes speed and duplex settings have a similar effect. Things seem to work properly, but you are dropping packets which slows the application down. Obviously if you have one end at 10 and the other is at 100, you will run into major issues, but sometimes autonegotiation is flakey. If you are using auto on both devices, check the interface for speed and duplex it auto'd to. If this is across a serial link, what is the bandwidth? Also, is this a core router that stays fairly busy? what is it's utilization? Sometimes routers will drop pings if they are busy. -Patrick JHIGGINS 07/12/01 04:01PM When I trace from a cisco router to another Cisco router I get a timeout failure every other probe on the last hop It fails on every type of cisco router I have tried, 7513,25xx abd 36xx. I think that it must be normal but I cannot find anything in the archives here or at the Cisco site that says it is normal? See following where I do a trace between two routers on connected interfaces. * 4 msec * 4 msec * 8 msec * 8 msec r1#trace Protocol [ip]: Target IP address: 192.168.10.1 Source address: 192.168.10.1 % Invalid source address r1#trace Protocol [ip]: Target IP address: 192.168.10.1 Source address: 192.168.10.2 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.1 1 192.168.10.1 4 msec 4 msec * 8 msec * 4 msec * 4 msec * 4 msec * 8 msec * 4 msec * r1# -- www.tasmail.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=12210t=12191 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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# Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=12244t=12191 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Trace failure indication [7:12191]
Even the example at http://www.cisco.com/warp/public/105/ext_ping_trace.html shows this failure but provides no explanation. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=12246t=12191 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
