stan@H1.GCY.NYTEL.COM (06/21/88)
There has recently been considerable discussion on this list about the increasing loss of network connectivity. I have not seen any discussion about TTL problems, however many of the problems that I have had to shoot with regard to loss of connectivity have been due to inappropriate TTL values. The increase in the size of the regionals and of the Internet as a whole has not been accounted for and TTL values are therefore set too low. This results in loss of connectivity, the cause of which is not readily apparent to the user. The matter is often further complicated by different TTL values for ping, ftp, tftp and telnet. Generally I have found that the highest TTL values are associated with the ping servers, so that when the user pings the host the network appears to be OK, but because ftp or telnet have a lower TTL, it is assumed that there is a problem with those servers and that they are not responding. The fact is that their TTL has gone to 0 somewhere in the network. There appears to be no consistency across vendor software implemenations, as I have seen TTL's for ftp range from 24 to 255. In my opinion, TTL for all services should be set to 255 as the network is not currently plagued with major looping problems and it seems to be more important to improve connectivity than to prevent the looping of a packet at 32 or 64 hops. Comments? Opinions? Similar experiences? Other solutions? ----------------------------------------------------------------------- Real Name : Stanfield L. Smith E-mail : stan@h1.gcy.nytel.com Company : New York Telephone Co. USmail : Room 203 LAB Phone : 516-294-7170 : 100 Garden City Plaza FAX G3 : 516-248-8489 : Garden City NY, 11530 -----------------------------------------------------------------------
jas@proteon.COM (John A. Shriver) (06/22/88)
The TCP specification specifies that the IP time to live is 60, on page 51 of RFC 793. All that the various TCP/IP vendors using 4.xBSD need to do is edit netinet/tcp_timer.h, and change the definition of TCP_TTL to 60, and recompile. It was 15 (?) on 4.2BSD, and is 30 on 4.3BSD (including the "Van Jacobsen" version). Both of these values are too small. (None of the commercial versions I have here uses 60.) I guess the vendors might be able to get this out the door in 1 year... One does NOT want to set the IP time to live higher than 60 for TCP. This breaks certain assumptions that make the three-way handshake work, and re-use of port numbers. When the Internet is over 60 hops, then we will have a problem. For now, we should follow the standards we have set for ourselves. Looking at the 4.3BSD ICMP code, the echo reply code uses the received TTL as the TTL to send. (I won't try and decide if this is the "right" thing of ICMP to do.) Ping sends through a raw socket, which uses the default TTL of 255 (defined in netinet/ip.h). Thus the range of a ping is 127 hops. I would disagree about the absence of looping problems. So long as RIP, at least in the Berkeley routed implementation, is in use, there will be transient routing loops. This problem is minimized in the IDEA004 RIP. The host RFC authors should be sure to put this in their checklist, since it is such a common bug.
eshop@saturn.ucsc.edu (Jim Warner) (06/22/88)
While we're looking at TTLs, how about setting them to SMALL numbers for packets that aren't supposed to propagate through the internet. I'm thinking of net hop routing packets (RIP) and rwho packets.
jqj@HOGG.CC.UOREGON.EDU (06/22/88)
We have seen exactly the same behavior Smith describes. We're deep in a regional (5 hops away from the NSF backbone), and have found a number of sites we could ping but could not otherwise communicate with. In one case (uunet), we contacted the vendor of their software (Sequent), and the vendor agreed that a higher initial TTL was appropriate. One more thing for the "how to write a host TCP/IP implementation" RFC?