exclude addresses
Brian Raaen
braaen at zcorum.com
Wed Jan 9 18:14:52 UTC 2008
you can try creating a class that has that mac address in a subclass. Then
you can block that mac address in any pool you want. I have attached the
relevant part of the dhcpd.conf man page.
--
Brian Raaen
Network Engineer
braaen at zcorum.com
Tel 678-507-5000x5574
CLIENT CLASSING
Clients can be separated into classes, and treated differently
depending on what class they are in. This separation can be done either
with a conditional
statement, or with a match statement within the class declaration. It
is possible to specify a limit on the total number of clients within a
particular
class or subclass that may hold leases at one time, and it is possible
to specify automatic subclassing based on the contents of the client packet.
To add clients to classes based on conditional evaluation, you can
specify a matching expression in the class statement:
class "ras-clients" {
match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
}
Note that whether you use matching expressions or add statements (or
both) to classify clients, you must always write a class declaration for any
class that
you use. If there will be no match statement and no in-scope
statements for a class, the declaration should look like this:
class "ras-clients" {
}
SUBCLASSES
In addition to classes, it is possible to declare subclasses. A
subclass is a class with the same name as a regular class, but with a
specific submatch
expression which is hashed for quick matching. This is essentially
a speed hack - the main difference between five classes with match
expressions and one
class with five subclasses is that it will be quicker to find the
subclasses. Subclasses work as follows:
class "allocation-class-1" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
class "allocation-class-2" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
allow members of "allocation-class-1";
range 10.0.0.11 10.0.0.50;
}
pool {
allow members of "allocation-class-2";
range 10.0.0.51 10.0.0.100;
}
}
The data following the class name in the subclass declaration is a
constant value to use in matching the match expression for the class. When
class matching
is done, the server will evaluate the match expression and then look
the result up in the hash table. If it finds a match, the client is
considered a member
of both the class and the subclass.
Subclasses can be declared with or without scope. In the above
example, the sole purpose of the subclass is to allow some clients access
to one address
pool, while other clients are given access to the other pool, so
these subclasses are declared without scopes. If part of the purpose of the
subclass were
to define different parameter values for some clients, you might want
to declare some subclasses with scopes.
In the above example, if you had a single client that needed some
configuration parameters, while most didn't, you might write the following
subclass declara-
tion for that client:
subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
option root-path "samsara:/var/diskless/alphapc";
filename "/tftpboot/netbsd.alphapc-diskless";
}
In this example, we've used subclassing as a way to control address
allocation on a per-client basis. However, it's also possible to use
subclassing in ways
that are not specific to clients - for example, to use the value of the
vendor-class-identifier option to determine what values to send in the
vendor-encapsu-
lated-options option. An example of this is shown under the VENDOR
ENCAPSULATED OPTIONS head in the dhcp-options(5) manual page.
On Wednesday 09 January 2008 12:52, Ron Croonenberg wrote:
> Hello,
>
> Is it possible to 'refuse' a client by mac address ?
>
> thanks.
>
>
More information about the dhcp-users
mailing list