[TriLUG] Trying to get (too) fancy with dhcpd.conf
Aaron Joyner
aaron at joyner.ws
Thu Aug 11 13:16:11 EDT 2005
Steve Hoffman wrote:
>I'd like to use DHCP to assign two ip addresses to one network
>card...I know it's possible to do by hand, but I'd like to automate
>the process. I have already got several clients (win and linux)
>getting a fixed-address, but only one. I thought about creating
>virtual adapter in linux (eth0:0) but I see the MAC is the same as the
>real card and I guess I'd expect it would be. But I would like this
>to work on the Windows machines as well. The main reson I'm looking
>into this is because $BOSS has decided he wants a public IP address
>for his laptop in addition to the private IP he needs to access may
>features in the office. Naturally he also wants it to just work when
>he gets home (using DHCP as well). I setup the alternate
>configuration on his machine running XP, he gets a DHCP assigned
>private...and no public...
>
>Can this be done with dhcpd?
>
>Thanks,
>Steve
>
>
This isn't really a DHCP server problem, it's a client / protocol
problem (ie. you're trying to do something that won't work the way you
expect out of the box). First, let's understand how the protocol
works. Your client says, "I am this MAC address, I would like to lease
a DHCP address". The server then has been given that one bit of
information to work with, a MAC address. It can send a response of,
"You may have this lease", and that lease must contain some options such
as the time the lease is valid, and may contain some other options, such
as an IP address, default gateway, subnet mask, dns servers, time
servers, etc, ad nauseum.
Now, consider what the DHCP server has to work with, the MAC address.
In practice, ISC-DHCPd will then turn around and look at it's config
file, and attempt to find a match for the MAC address. It also has one
other bit of information, it knows where the packet came from. It knows
that the packet came in on, for example, eth0, or eth1. That's
expressed as being part of a subnet, that DHCP is listening for requests
on. So it looks in that subnet statement in it's config file, for the
closest MAC address match. When found, it returns the statements
associated with that config, usually just "fixed-address x.x.x.x", as
well as anything inherited from the global config (usually the rest of
the stuff such as gateway, dns, etc).
So, how can you assign two IP addresses? Well, the DNS server could
technically stuff two fixed-address statements in the response packet to
the client, but the client wouldn't understand that and would either
consider it invalid, or choose one at random, or choose the first one,
or some other not-ideal implementation-specific thing. Another option
would be for the client to request two leases, either from different MAC
addresses, or on different paths to the server (i.e. different VLANs
perhaps, or various other ways) but if you're using the same MAC address
for those calls, it's likely to confuse the server anyway, as it will
have trouble determining where to send the response (the scope of why is
beyond this email). Neither of these solutions really works well. If
you've got two network cards and two separate subnets and two separate
paths between the client and the server, the configuration can work, but
isn't all that confusing, and we probably wouldn't be having this
conversation. :)
In short, I think you're probably going about this the wrong way.
Having two IP addresses on the client (unless there are two actual
network connections involved) is not likely to give you the behavior you
think it will. Can you describe your network, in brief? I.e. something
like: "I've got a Linux box, connected to a cable modem, which has an
external and internal set of IP addresses, and I want the boss to have
one of each", or "I have three T1s terminated on a multi-homed Linux
gateway via BGP, and we have a private internal LAN as well as public
address space for workstations", or something in between? Perhaps we
can cook up an appropriate solution for your given situation, that will
meet your boss's needs as well as function properly from a network
perspective. Perhaps a short description of how you've had it working
by hand would also be useful.
Aaron S. Joyner
More information about the TriLUG
mailing list