hoelzle@neon.stanford.edu (Urs Hoelzle) (07/27/90)
On our network we see the following phenomenon: whenever a connection to a remote host is built, the first connection attempt will fail, giving the message "connect: Host is unreachable". If retried within a couple of minutes, it will always work. This happens with mail, ftp, telnet, rlogin etc. The behavior is reproducible and is the same on all our machines (Sun3/4s, SunOS 4.0.3, some diskless, one name/yp server). Typical example: otis> telnet next.com Trying 129.18.1.2 ... telnet: connect: Host is unreachable <-- this msg comes w/no delay telnet> quit otis> !! telnet next.com Trying 129.18.1.2 ... Connected to next.com. Subsequent connects will work if made within a couple of minutes of a successful connect. What is happening here? It seems that inetd (or something else) times out too quickly during the connect, but why? Any help is greatly appreciated. -Urs
jimc@math.ucla.edu (Jim Carter) (07/31/90)
In article <10306@brazos.Rice.edu>, hoelzle@neon.stanford.edu (Urs Hoelzle) writes: |> On our network we see the following phenomenon: whenever a connection to a |> remote host is built, the first connection attempt will fail, giving the |> message "connect: Host is unreachable". If retried within a couple of |> minutes, it will always work. This happens with mail, ftp, telnet, rlogin The symptoms are wierd, and it's hard to be sure without hands on the affected system, but I can give a plausible scenario. Your machine lacks a default route, but has the netmask set to attempt local delivery to the whole world. You do your telnet (etc) and a broadcast ARP packet goes out. Your gateway trustingly forwards the thing and it rattles around Stanford bothering people and causing network storms. A nearby gateway answers with an "unreachable" ICMP error code and you get your user-level error message. Shortly after, your local gateway decides to do a proxy ARP response saying "send it to me". It's too late for the initial connection but subsequent attempts use the cached Ethernet address, bypassing the ARP broadcast, until the cache entry times out (about 20 minutes if I remember right). Why the gateway is slow with the proxy ARP is unclear. Maybe it's too busy sending "unreachable" packets to you. Suggestions: Use a conventional routing setup, assuming that this is possible at Stanford (I've heard strange things about networking there). /etc/ifconfig le0 `hostname` netmask 0xffffff00 /etc/route add default name.of.gateway 2 /etc/arp -a (to print out the ARP cache for diagnosis) Turn off broadcast packet forwarding and maybe forget about proxy ARP. How you do this depends on the gateway. Suns never forward broadcasts, and need a kernel hack to produce proxy ARP. Note, if your YP server (if any) is beyond the gateway (not a wise move) you can't turn off broadcast forwarding. Some obsolete equipment that can't handle routing relies on the gateway's proxy ARP, so be alert for obsolete stuff breaking if you turn it off. James F. Carter (213) 825-2897 UCLA-Mathnet; 6221 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90024-1555 Internet: jimc@math.ucla.edu BITNET: jimc%math.ucla.edu@INTERBIT UCP:...!{ucsd,ames,ncar,gatech,purdue,rutgers,decvax,uunet}!math.ucla.edu!jimc