[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Strange Network Problem (TTL?)



On Tue, 14 Mar 2000, david.cureton@nokia.com wrote:
>This is correct however this is not how it is implementing in 99% if routers
>as it is to hard and time consuming.
>
>The normal method of implementing this TTL field is to decrement this field
>by one as it passes through the router. No need to worry about checking time
>etc. IF the TTL field hit zero after the router decrements it, drop the
>packet!

The TTL must be decremented by at least one for every hop.  It's only if it's 
at the one router for a second or more that TTL works in any way other than a 
hop count.

I've just done a test of this on a network with:
Linux server ==ethernet== Linux 2.2.9 router ==PPP 33K6 modem== Linux 
workstation

I started pinging the Linux server from the workstation (120ms ping time and 
TTL of 254).  Then I started transfer of three medium sized files over the 
modem link from the server to the workstation.  Ping time went up as high as 
5570ms, but the TTL stayed at 254.  The 2.2.9 router was obviously where the 
packets were being delayed.  This is a bug in the Linux kernel, I don't have 
access to a network that allows me to test 2.2.14.  Has it been fixed?

>On Fri, 10 Mar 2000, Chris Wagner wrote:
>>At 11:41 PM 3/9/00 +0100, Paul van Empelen wrote:
>>>Time to live has nothing to do with time, although the name suggests it.
>>>It is a hop count. You start at e.g. 255. On the next hop the IP packet
>>>will have a ttl of 254 and so on.
>>
>>So it's really a max hops limit.  How did it get a name like TTL??  What
>>function does it serve?  Besides providing a mechanism to expire lost
>>packets...  What role does each host's TTL setting play in a ping or trace?
>
>If you have a packet in your network buffers for 1 second you should
>decrement the TTL.  That way a packet can survive on the net for a maximum
>of
>255 seconds.  This is why there are ~4 minute timeouts on some parts of TCP.
>
>
>Here is the relevant section from rfc791.  If you have installed the doc-rfc
>package you'll have this on your system.
>
>   Time to Live:  8 bits
>
>    This field indicates the maximum time the datagram is allowed to
>    remain in the internet system.  If this field contains the value
>    zero, then the datagram must be destroyed.  This field is modified
>    in internet header processing.  The time is measured in units of
>    seconds, but since every module that processes a datagram must
>    decrease the TTL by at least one even if it process the datagram in
>    less than a second, the TTL must be thought of only as an upper
>    bound on the time a datagram may exist.  The intention is to cause
>    undeliverable datagrams to be discarded, and to bound the maximum
>    datagram lifetime.

-- 
My current location - X marks the spot.
X
X
X


Reply to: