From owner-freebsd-net@FreeBSD.ORG Mon Nov 29 15:14:00 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C3F16A4CE for ; Mon, 29 Nov 2004 15:14:00 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A4343D46 for ; Mon, 29 Nov 2004 15:13:59 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 2184 invoked from network); 29 Nov 2004 15:05:33 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Nov 2004 15:05:33 -0000 Message-ID: <41AB3CB9.598BB2FB@freebsd.org> Date: Mon, 29 Nov 2004 16:14:01 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gleb Smirnoff References: <20041125140641.GA78210@cell.sick.ru> <20041126091316.GA84369@cell.sick.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: net@freebsd.org cc: James Subject: Re: route cacheing for gif(4) should be optional X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 15:14:00 -0000 Gleb Smirnoff wrote: > > On Thu, Nov 25, 2004 at 09:55:10PM -0500, James wrote: > J> On Thu, Nov 25, 2004 at 05:06:41PM +0300, Gleb Smirnoff wrote: > J> > Back to this problem: > J> > > J> > http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html > J> > > J> > I've found two more people who dislike this feature of gif(4). > J> > So I'd like to make it optional. > J> > > J> > We already have LINK2 flag removing sourceroute filter from gif(4), > J> > which is commonly used in asymmetrically routed networks. I suggest > J> > to use this flag also for disabling route cacheing, since asymmetricity > J> > often appears in dynamically routed networks, and if one runs dynamic > J> > routing, he probably wants to remove route cacheing, too. > J> > J> I'd think we should create a separate option for removing the route > J> cache. Sometimes, certain people want to use the tunnel at the highest > J> maximum performance possible with both sourceroute filter disabled > J> and tunneling routes allocated at their creation time. Perhaps link3 is a > J> good place for this option? > > There is no LINK3 flag :) > > However, gif(4) does not use LINK0 flag. It was used in past. We can utilize > it now. Any objections? IMO you should scrap it altogether. However there have been reasons for storing the rtentry pointer in struct gif. In the old days ip_output() required an rtentry pointer to be passed on, this is no longer the case. And it was sort of a safe-guard to make it harder to send the gif encapsulated packets back through the same gif interface. That didn't work really well and as I say it should be scapped instead of rigged on somewhere else with yet another obscure option. ;) -- Andre