Date: Mon, 28 Aug 1995 19:54:52 -0400 From: dennis@et.htp.com (dennis) To: Robert Minnear <minnear@Ipsilon.COM> Cc: hackers@freebsd.org Subject: Re: alias ( secondary IP ) for Ethernet Ifaces in FreeBSD Message-ID: <199508282354.TAA06434@mail.htp.com>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508282354.TAA06434>