Re: [pim] TTL for PORT
Toerless Eckert <eckert@cisco.com> Tue, 08 February 2011 13:50 UTC
Return-Path: <eckert@cisco.com>
X-Original-To: pim@core3.amsl.com
Delivered-To: pim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40F73A7135 for <pim@core3.amsl.com>; Tue, 8 Feb 2011 05:50:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1w8Pu4FlxGF for <pim@core3.amsl.com>; Tue, 8 Feb 2011 05:50:53 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C03B43A6D8A for <pim@ietf.org>; Tue, 8 Feb 2011 05:50:53 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Feb 2011 13:51:00 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p18Dp0nW003264; Tue, 8 Feb 2011 13:51:00 GMT
Received: from mcast-linux1.cisco.com (mdt-linux4 [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id p18Doxrf032179; Tue, 8 Feb 2011 05:51:00 -0800
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id p18Dox5B032178; Tue, 8 Feb 2011 05:50:59 -0800
Date: Tue, 08 Feb 2011 05:50:59 -0800
From: Toerless Eckert <eckert@cisco.com>
To: Pekka Savola <pekkas@netcore.fi>
Message-ID: <20110208135059.GI22898@cisco.com>
References: <7C362EEF9C7896468B36C9B79200D8350CFB23EB01@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110205091629.GT27034@cisco.com> <7C362EEF9C7896468B36C9B79200D8350CFB23EB25@INBANSXCHMBSA1.in.alcatel-lucent.com> <4D50385F.90202@venaas.com> <alpine.LRH.2.02.1102080814280.15008@netcore.fi> <20110208094958.GZ22898@cisco.com> <alpine.LRH.2.02.1102081204260.20119@netcore.fi> <7C362EEF9C7896468B36C9B79200D8350CFB2F6C3C@INBANSXCHMBSA1.in.alcatel-lucent.com> <20110208115709.GE22898@cisco.com> <alpine.LRH.2.02.1102081359480.22186@netcore.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.02.1102081359480.22186@netcore.fi>
User-Agent: Mutt/1.4.2.2i
Cc: Yiqun Cai <ycai@cisco.com>, "pim@ietf.org" <pim@ietf.org>
Subject: Re: [pim] TTL for PORT
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pim>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2011 13:50:54 -0000
On Tue, Feb 08, 2011 at 02:06:58PM +0200, Pekka Savola wrote: > With ping, you can also check the sender side TTL. I've yet to see a > difference between a physical and loopback IP -- but maybe there > exists a device which actually assigns physical IPs on linecards and > not the central processor and acts differently with this regard. Can't find a ttl option in ping *sigh*, but at least when trying a telnet from a routers loopback interface you seem to be right, the ttl is still 255. Which also answers my other question: 255 seems to also be a good default now, even for telnet ;-) > Just to make it clear, normally when a router originates a packet, it > does not decrement the TTL as it is not forwarding the packet. I guess the question is always how you model a loopback interface. If you want a packet to be routed then this routing should normally decrement the TTL. Of course, in this case it's better to not do this, but i am not sure there is any good definition what must happen when you use loopback interfaces. Just maybe common practice. > One thing that you did not comment on but which could be possible is > that both the loopback IP and physical IP are decremented (if the > control plane and forwarding plane are decoupled very strongly). I > haven't seen this either, though. Well, what is very common are PSA modules that are really just devices internally connected in routers to an internal ethernet. Any packets from / such modules does of course get TTL decremented by the router. But logically this is not different from a process sending/receiving a loopback interface. Or for example, in IOS we have an internal virtual interface where a feature acts like a small packet-rewriter. YOu send packets out that interface, it gets rewritten and then when it's sent back into the router then of course the TTL gets decremented because it behaves like a real interface. The way it looks to me, processes using loopback interfaces just behave differently and do not decrement the TTL. I really did never bother in before about this detail. I just sounded like an illogical expectation to me to rely on this. > >Of course, you can work around that in routers, but IMHO it's a hack which > >is why i was asking if other protocols, eg: BGP do this (eg: in iBGP or the > >like). > > Protocols such as BGP are burdened by their history. Their TTL > behaviour was designed before TTL=255 checking was invented and for > backward compatibility reasons cannot change the default behaviour. > When designing a new protocol, we should look at current models. > There may be more recent (TCP) protocols on the field that > successfully employ TTL=255. Sure. Cheers Toerless
- [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Yiqun Cai
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Eric Rosen
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Jeff Tantsura
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Eric Rosen
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Toerless Eckert
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Bhatia, Manav (Manav)
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Jeff Tantsura
- Re: [pim] TTL for PORT Pekka Savola
- Re: [pim] TTL for PORT Stig Venaas
- Re: [pim] TTL for PORT Jeff Tantsura
- Re: [pim] TTL for PORT Stig Venaas