From owner-freebsd-stable Wed May 29 14:15:24 2002 Delivered-To: freebsd-stable@freebsd.org Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by hub.freebsd.org (Postfix) with ESMTP id F0DE437B400 for ; Wed, 29 May 2002 14:15:15 -0700 (PDT) Received: from blossom.cjclark.org ([12.234.91.48]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020529211514.MRVN29266.sccrmhc01.attbi.com@blossom.cjclark.org>; Wed, 29 May 2002 21:15:14 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g4TLFC013288; Wed, 29 May 2002 14:15:12 -0700 (PDT) (envelope-from crist.clark@attbi.com) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 29 May 2002 14:15:12 -0700 From: "Crist J. Clark" To: Steve Watt Cc: stable@FreeBSD.ORG, mikem@wmis.net Subject: Re: 4.6-PRERELASE fxp alias woes Message-ID: <20020529141512.C12700@blossom.cjclark.org> Reply-To: "Crist J. Clark" References: <5.1.0.14.2.20020513142059.03741410@127.0.0.1> <200205240009.g4O09Kb2081251@wattres.Watt.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205240009.g4O09Kb2081251@wattres.Watt.COM>; from steve@Watt.COM on Thu, May 23, 2002 at 05:09:20PM -0700 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, May 23, 2002 at 05:09:20PM -0700, Steve Watt wrote: > In article <5.1.0.14.2.20020513142059.03741410@127.0.0.1> you write: > >network_interfaces="fxp0 lo0" > >ifconfig_fxp0="inet 216.109.194.4 netmask 255.255.255.0" > >ifconfig_fxp0_alias0="inet 216.109.194.8 netmask 255.255.255.0" > > As everyone has pointed out, the kernel is now enforcing netmasks on > same-subnet aliases. There has always been an error generated when one tried to overwrite the route from the previous entry. Now, however, the error is not masked. > But I've got a really simple question: Why, if it is so easy to detect > programatically, do we not just *fix* it automagically? Is there *ever* > a case where it is useful to have a same-subnet alias with a different > subnet mask (besides the obvious point of it doesn't work with the > current code). It does to work. You cannot try to configure two addresses on the _exact same network_ (that is the same network number and mask). When you change the netmask to 255.255.255.255, you are changing the subnet mask so things do work (it's on a different network now). > In other words, is there some useful future behavior that such a change > would make unpleasant/undoable? I think people need to understand better where the error occurs. When you try to configure the interface the second time with the same network, you are trying to overwrite the existing entry for that network in the routing table. This is an error, the call fails, and ifconfig(8) errors out. In the past, the alias got added to the interface, but what happened to the route was ambigious, does the old route stay or do we clobber it? The problem with "fixing" this again is that we need to decide which is correct, tossing out the new route or clobbering the old. In the boot process, you would probably like the first ifconfig(8) to stick. However, when the administrator uses ifconfig(8) interactively, he might very well want and expect his new ifconfig(8) commands to overwrite the old route. The current approach is that neither the rc-scripts or the interactive administrator should worry about clobber or no-clobber, but just configure the interfaces properly in the first place. ifconfig(8) should just flag the error when they try to overwrite the route. Or at least... that's what I seem to recall was happening. Hmmm. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message