From owner-freebsd-hackers Wed Aug 7 16:31: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1246437B401; Wed, 7 Aug 2002 16:30:56 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id A05D643E3B; Wed, 7 Aug 2002 16:30:55 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0264.cvx22-bradley.dialup.earthlink.net ([209.179.199.9] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17caGT-0006Hz-00; Wed, 07 Aug 2002 16:30:54 -0700 Message-ID: <3D51AD79.C07ECB0F@mindspring.com> Date: Wed, 07 Aug 2002 16:30:01 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Crist J. Clark" Cc: Brad Laue , freebsd-hackers@FreeBSD.ORG Subject: Re: ifconfig alias and the 0xffffffff netmask References: <3D4F7539.2090201@brad-x.com> <3D4F7F4F.97609D75@mindspring.com> <20020807174324.GB71991@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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 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