Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 May 2002 14:15:12 -0700
From:      "Crist J. Clark" <crist.clark@attbi.com>
To:        Steve Watt <steve@Watt.COM>
Cc:        stable@FreeBSD.ORG, mikem@wmis.net
Subject:   Re: 4.6-PRERELASE fxp alias woes
Message-ID:  <20020529141512.C12700@blossom.cjclark.org>
In-Reply-To: <200205240009.g4O09Kb2081251@wattres.Watt.COM>; from steve@Watt.COM on Thu, May 23, 2002 at 05:09:20PM -0700
References:  <5.1.0.14.2.20020513142059.03741410@127.0.0.1> <200205240009.g4O09Kb2081251@wattres.Watt.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020529141512.C12700>