Date: Wed, 07 Aug 2002 16:30:01 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Crist J. Clark" <cjc@FreeBSD.ORG> Cc: Brad Laue <brad@brad-x.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: ifconfig alias and the 0xffffffff netmask Message-ID: <3D51AD79.C07ECB0F@mindspring.com> References: <3D4F7539.2090201@brad-x.com> <3D4F7F4F.97609D75@mindspring.com> <20020807174324.GB71991@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Crist J. Clark" wrote:
> I've seen you say this before, Terry, and I'm not sure I understand
> exactly what you are saying is broken. This,
>
> ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> inet 172.16.0.1 netmask 0xffff0000 broadcast 172.16.255.255
> inet 172.16.255.254 netmask 0xffffffff broadcast 172.16.255.254
> inet 172.16.2.128 netmask 0xffffff00 broadcast 172.16.2.255
> ether 00:20:af:17:0f:11
> media: Ethernet 10baseT/UTP
>
> Works fine for me. What do you mean by, "you can't have a different
> netmask from that of the real IP address?" In the case of a
> 255.255.255.255 netmask, you have a different netmask from the "real"
> IP address. That's the whole point of using the all-ones mask after
> all.
There's a situation that can result in an "EEXIST" from the
routing code, after the association of the IP address, on a
non-"all bits lit" netmask on an alias.
I ran into this on a system where I was running a lot of jails;
the insidious part was that an ifconfig would show the IP as
having been assigned, but you couldn't really use it.
The only fix was to use an all 1's netmask for alias addresses.
This was on FreeBSD 4.2; I believe subsequent versions of
ifconfig have supressed the error message (but not the error).
It was my understanding from the FreeBSD-net mailing list
responses I received at the time that this was an artifact
of a clone for a route of a non-existant entry.
I think the way you have to work at triggering it is to do
the ifconfig before a default route is defined (or intentionally
not have a default route).
It may be that this is falling into the cloning case in RT_ADD
these days, but that doesn't make the behaviour in that case
correct:
/*
* Uh-oh, we already have one of these in the tree.
* We do a special hack: if the route that's already
* there was generated by the protocol-cloning
* mechanism, then we just blow it away and retry
* the insertion of the new one.
*/
Basically, the way Cisco and other networking equipment
vendors handle this case is by virtualizing the interface,
rather than the route.
If you *really* need it, I could revert the configuration on
the system where this was a problem, and reproduce the error,
since the configurations for that machine are under version
control. A better thing to do would be to look for the terms
"netmask" and "alias" on the FreeBSD-net mailing list archives
around October/November of 2000.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D51AD79.C07ECB0F>