From owner-freebsd-hackers Mon Aug 28 16:54:12 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA01627 for hackers-outgoing; Mon, 28 Aug 1995 16:54:12 -0700 Received: from mail.htp.com (mail.htp.com [199.171.4.2]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA01621 for ; Mon, 28 Aug 1995 16:54:07 -0700 Received: from et.htp.com (et.htp.com [199.171.4.228]) by mail.htp.com (8.6.5/8.6.5) with SMTP id TAA06434; Mon, 28 Aug 1995 19:54:52 -0400 Date: Mon, 28 Aug 1995 19:54:52 -0400 Message-Id: <199508282354.TAA06434@mail.htp.com> X-Sender: dennis@mail.htp.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Minnear From: dennis@et.htp.com (dennis) Subject: Re: alias ( secondary IP ) for Ethernet Ifaces in FreeBSD Cc: hackers@freebsd.org Sender: hackers-owner@freebsd.org Precedence: bulk >> I've talked to some of the >> gateD-people but they are pretty adamant about their design. I made some >> suggestions about how they should make gateD more generic because many of >> the supported UNIX platforms are becoming more diverse internally and it >> will become more and more difficult to keep everything working as time goes >> on. Complex interfaces (frame relay, X.25, atm, SMDS, etc) do not work with >> gated unless they are implemented in a particular way, and frankly the way >> that they must be implemented would make for a very poor product. Needless >> to say I received a rather nasty scolding for my efforts. >> >> I also have a serious problem with an application that dictates how a kernel >> subsystem has to be implemented....theres something wrong with the picture >> in general. > >I have just started looking at the gated internals and would interested >in hearing more about your suggestions to make gated more generic. I would >also be interested in understanding how complex interfaces must be implemented >in order to work with gated. I would appreciate it if you have the time >and understand it if you don't... > We're in the process of looking at it ourselves, but in summary this is how it goes.... gateD does "interface scans" to gather information about the running system, It basically looks at the ifnet structures and builds a profile for the system. The problem is that the kernel must look the way gated expects it to look, and the model that they use for multi-channel interfaces is poor and in some cases defective. Another problem with this method it that policy changes within the O/S ( that should be application transparent) can make gated not work. My proposal is simply to give gated a static topology of the network (as in a configuration file) instead of the "learning" method (ie the interface definitions, the attributes, the peer info). This would add much flexibility and very little if anything would be lost. All gated would have to query from the interfaces themselves would be status (up/down) info. A mechanism would have to be developed to tell gated about dynamic connections...but that really needs to be done anyway. Dennis