On Fri, Feb 24, 2006 at 01:51:04PM +0100, Jukka Salmi wrote:
> Hi,
> 
> I'm seeing very strange (at least to me) behaviour on two i386 systems
> running NetBSD 2.1_STABLE. They have one ethernet interface each, and
> they both use IPv4 aliases. Since the problem is the same on both
> systems, I'll describe it for only one of them.
> 
> The interface is configured as follows:
> 
> $ cat /etc/ifconfig.fxp0
> inet 212.254.26.75/28 media autoselect
> inet 212.254.26.66/32 alias
> inet 212.254.26.69/32 alias
> up
> 
> This worked fine so far, until today (uptime was about 26 days) I
> noticed that running wol(1) (a wake-on-lan tool, pkgsrc/net/wol) didn't
> work as usual: it somehow did not manage to send the magick packet,
> but did not print an error message; ifconfig(8) revealed:
> 
> $ ifconfig fxp0
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> 	address: 00:02:a5:1c:cb:58
> 	media: Ethernet autoselect (100baseTX full-duplex)
> 	status: active
> 	inet 212.254.26.66 netmask 0xffffffff broadcast 212.254.26.66
> 	inet alias 212.254.26.69 netmask 0xffffffff broadcast 212.254.26.69
> 	inet alias 212.254.26.75 netmask 0xfffffff0 broadcast 212.254.26.79
> 
> Hmm, this is not what I had expected! Notice the addresses don't match
> the configuration: 212.254.26.75 is an alias now, and 212.254.26.66
> is not an alias anymore! At least the netmasks and broadcast addresses
> did not change...

I have seen dhclient cause "aliases" and non-"aliases" to "rotate" in
this way.  I suspect '/etc/rc.d/network restart' could also rotate them.
Others have already described how BSD's aliases are deficient....

FWIW, I have patches for the kernel and for ifconfig that let me apply
a preference number to an address: for a socket bound to INADDR_ANY,
the kernel chooses a source address with the least preference number,
after it chooses the output interface.  There are other goodies in
the patch that let me set many useful IPv4 source address policies;
the policies are extensible, too.  Someday I will commit the patches;
in the mean time, they are available upon request.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933