Configuration question..
Keith.Neufeld at wichita.edu
Keith.Neufeld at wichita.edu
Tue Sep 12 18:04:24 UTC 2006
> with this config I get a WARNING now when I restart my dhcpd..
Yes, code has recently been added to the server to produce a warning about
this very topic.
David Hankins: Was the warning possibly added for hosts inside subnet
declarations, but inadvertently overlooked for hosts within pool
declarations?
> I have a host dilvish in my 192.168.1.0 subnet::pool,
> I move that to the 10.0.0.0 subnet::pool, and remove the routers
option..
>
> restart dhcpd, have the win2k box relase and then renew it's IP, it gets
> the same 192.168.1.250 IP but it gets all the things associated w/ the
> 10. (I think this is what you were saying would happen.. )
Yes. The "gets all the things associated with the 10" is a part that has
only recently become widely understood. See below for my attempt at
explaining it further.
> When I comment out the entry (now existing only in the 10 subnet) and
> then restart dhcpd and then have the client renew it gets an ip in the
> 192.168.1.22 range. (I am not sure if you said this would happen.. )
I didn't mention that, but that's exactly right. It's no longer "known,"
so it gets an address from your unknown pool.
> This is understandable.. (sort of) as this host is coming to the dhcpd
> server on the 192.168.1.x subnet, and like you said "..known (listed
> anywhere in the configuration).. ".
Yes, that's it. "known" means there's a host declaration for it
_anywhere_. "unknown" means there isn't.
> What I am looking for is that when hosts come in through the dhcp-relay
> on the router that they get routed to the right subnet and follow the
> correct known/unknown settings that I have provided for them.
The DHCP server automatically handles matching the relay's gateway address
to the subnets you've defined in order to give an appropriate address to
the client. You don't have to do anything special, other than fully and
accurately describe your subnet and shared-network layout to the server
(including the subnet(s) the server is attached to, *even if it's not
serving any clients there*). The known and unknown configurations, you
also seem to have a good handle on.
Okay, here's an attempt at explaining where to put different configuration
settings.
* If you want settings to apply to all clients everywhere, at least
as default values that can be overridden elsewhere in the configuration,
place those settings in the global scope, outside of all other blocks.
* If you want settings to apply to all clients on a VLAN (again, at
least as a default for that VLAN), place those settings in the
shared-network declaration for that VLAN, outside of the subnet
declarations.
* If you want settings to apply to all clients in a particular IP
subnet (which may coexist with other logical subnets on the same VLAN),
place those settings in that subnet declaration (which may be inside a
shared-network declaration along with other subnet declarations, or may
stand alone if the logical subnet is alone in that VLAN).
* If you want settings to apply to _some_ clients *when they operate
in a particular IP subnet,* create a means to identify those clients
(known/unknown, class/rule, class/subclass) and pools that allow/deny
clients identified in that fashion, then place those settings in the pool
declarations that allow those clients.
* If you want settings to apply to some clients *no matter where
they operate,* either place those settings inside the host declarations
for those clients (if there are only one or two such clients), or create a
group declaration enclosing those clients' host declarations and place the
settings inside the group declaration.
* Always place host declarations at the global scope, outside of all
other blocks, except possibly for group declarations enclosing the host
declarations. (+)
(+) The recent thread on the mailing list about host declaration
placement has illuminated the behavior that a host declared inside a
subnet or pool declaration inherits attributes from the subnet/pool even
when it travels elsewhere. Thus carefully-crafted configurations may take
advantage of this, in contrast with my suggestion always to place
host/group declarations at the global scope. However, this inheritance
mechanism is IMHO more likely to cause confusion for the casual reader,
and the consensus seems to be that it's simpler and safer to declare
hosts/groups globally.
--
Keith Neufeld
Lead Network Engineer
Wichita State University
More information about the dhcp-users
mailing list