From owner-freebsd-net Fri May 11 14:20:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 085B537B424 for ; Fri, 11 May 2001 14:20:49 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f4BMXAb09127; Fri, 11 May 2001 17:33:11 -0500 (CDT) (envelope-from nick@rogness.net) Date: Fri, 11 May 2001 17:33:10 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Jun-ichiro itojun Hagino Cc: freebsd-net@FreeBSD.ORG Subject: Re: gif tunnel woes In-Reply-To: <20010511201628.133D47D4@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 12 May 2001, Jun-ichiro itojun Hagino wrote: > hello, regarding to the note on: > > > http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+2538+/usr/ > local/www/db/text/2001/freebsd-net/20010506.freebsd-net First off thanks a million for the response. > >the symptom is repeatable. however, it seems to me that the multi >destination mode is poorly documented, and needs certain (strange) >configuration to work properly. i have no idea how can it be useful. The reason I was experimenting in it was because using bi-directional gif tunnels, the number of them has to be staticlly compiled in ther kernel and has no way of growing the actual number of gif interfaces dynamically. So my options were to build N number of gif interfaces for every machine, or use nos-tun. The multi-destination tunnels could have been a work around...if they would have worked right. >the destination tunnel gateway address is taken from rt_gateway, >so i guess you'd need to set routing table like this: > >% route add -inet 192.168.10.0 24.27.51.59 >% route change -inet 192.168.10.0 24.27.51.59 -ifp gif0 > >which seems very counter-intuitive to me (NOTE: i did not test this). > >my preference is to dropp support for multi-destination mode >from gif(4), as the multi-destination behavior is violating network >layering (rt_gateway is in inner header, and gif(4) multi-destination > mode uses it to determinte outer header). Which would be fine. It would be nice to have a way to grow these gif tunnels on the fly, then nos-tun could be strapped as well. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message