Date: Wed, 29 May 2002 14:47:24 -0700 From: steve@Watt.COM (Steve Watt) To: "Crist J. Clark" <cjc@FreeBSD.ORG> Cc: stable@FreeBSD.ORG, mikem@wmis.net Subject: Re: 4.6-PRERELASE fxp alias woes Message-ID: <200205292147.g4TLlOd5037142@wattres.Watt.COM> In-Reply-To: "Crist J. Clark" <crist.clark@attbi.com> "Re: 4.6-PRERELASE fxp alias woes" (May 29, 14:15)
next in thread | previous in thread | raw e-mail | index | archive | help
On May 29, 14:15, "Crist J. Clark" wrote: } Subject: Re: 4.6-PRERELASE fxp alias woes } On Thu, May 23, 2002 at 05:09:20PM -0700, Steve Watt wrote: } > 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). What I'm proposing is that if one adds an *alias* that, if you search down the list of IP addresses and netmasks, matches a (masked) IP network already on the interface, force the netmask to 255.255.255.255. Maybe I'm missing an interaction with the routing table, but this would seem (to me) to be a case of "liberal in what you accept". Yeah, I know that really applies to protocols, but it seems like a polite thing everywhere except security. } > 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 information in that route, if I'm not mistaken, is only what the source IP address applied to packets that are routed out that interface without an explicit IP address, right? The packet will match the network/mask, and go out the same pipe either way. } 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. So if the administrator is adding an alias and *wants* to have a seamless IP address change, there doesn't appear to be any way to accomplish that. You have to add the alias with a "funny" (non-intuitive) netmask, change the netmask on the primary address, switch the netmask on the alias, and then remove the primary. Can you remove the primary? I suppose I should go try it. Yeah, it seems to do the right thing, more or less. It blows away (as one would expect with the "unusual" netmasks) existing routes through the interface, though. So remove all of "primary" and "alias" from the discussion above and replace with "address". } 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. I can't think of any sensible except "last one wins", just like when you reconfigure an interface with a normal (non-alias) address. Except that I guess that'll confuse those who want to distinguish "primary" and "secondary" in their heads, which ain't real. } Or at least... that's what I seem to recall was happening. Hmmm. Hm. Well, I can see *why* the decision was made, after much more thought, but it still feels like a POLA violation... -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... 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?200205292147.g4TLlOd5037142>