Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!bu.edu!xylogics!samsung!zaphod.mps.ohio-state.edu!ncar!boulder!daemon
From: satz@cisco.com (Greg Satz)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Dealing with remote routers
Message-ID: <24867@boulder.Colorado.EDU>
Date: 17 Aug 90 07:49:08 GMT
Sender: news@boulder.Colorado.EDU
Lines: 50

>> We are experiencing a tough problem in x-country communications. A connection
>> is set up between two unix hosts which are quite remote from each other.
>> Between them are several networks, some of which are connected by cisco
>> routers. This connection is in operation for a long period of time, then
>> suddenly disappears, killing the session and annoying the users. This
>> occurs intermittantly, >1 <20 times a day.
>> 
>> Some detective work with ping and traceroute shows that an intermediate
>> cisco router is (for no discernable reason) sending a "Host unreachable"
>> icmp message at infrequent and unpredictable intervals. Querying the 
>> router does not indicate the loss of a route,nor the toggling of an 
>> interface.
>> 
>> I've discussed this on other mailing lists, and found someone who had a
>> similar problem and solved it by turning off the icmp unreachable messages
>> on that interface. He did not understand why the messages appeared, but
>> it did solve his problem. When I discussed this solution with the owners
>> of the router, they didn't seem too enthusiastic about making such a change
>> in that it may break traceroute (that being more important than telnet ;-)).
>> 
>> So my questions are, 1) Does anybody know any other reasons for a cisco
>> router to generate this message, and 2) (the hard question) how do you
>> deal with a router many levels removed from you whose operation is having
>> a major impact on your operation?

cisco routers will return ICMP unreachables whenever a route a packet is
destined for is not in the routing table. The most common cause for this is
an interface is flapping. Using the command debug ip-routing (or debug
routing on older software versions) will print out a message when routes
enter and leave the routing table. You can configure this debugging
information to be sent to a syslog daemon to watch it over the long term.
The software will also send unreachables when an access list would prevent
your packet from being forwarded. We will send an unreachable whenever we
would drop a packet for any reason. This includes input queue overflow and
output queue overflow (both are signs of congestion and is common when
going from a fast network such as ethernet to a slow network such as a 56K
line -- show interface will give you these counts). You can also enable
debug icmp to see all ICMP messages sent and received by the router.

The real question here is why are unreachables having such a deleterious
effect on your operation? Those messages shouldn't cause any problem on a
properly functioning TCP/IP implementation. We have "fixed" the problematic
systems which reacted badly to ICMP unreachables here because we couldn't
live with that behavior.

If I can be of any further help, please drop a line to
customer-service@cisco.com.

Greg Satz
cisco