dhcp安裝
(已閱讀: 1736 次)     (來源:苗栗縣大湖鄉大南國民小學 FreeBSD 全球資訊網路架站日誌)    下載：
ftp://ftp.lab.mlc.edu.tw/UNIX/isc/dhcp/dhcp-3.0rc11.tar.gz     編譯與安裝：
./configure
make
make install     相關程式檔案安裝至/usr/sbin/     touch /var/db/dhcpd.leases     echo 255.255.255.255 For-DHCP >> /etc/hosts     route add -host For-DHCP -interface vr1(放在rc.local)
vr1：網路卡代號，如果您的主機裝有兩塊網卡，這裡的網卡代號表示DHCP要從哪一塊網卡廣播出去。
我的vr0第一塊網卡接真實IP並做為NAT。     -------------/usr/local/etc/dhcpd.conf-------------------    server-identifier gateway.nat ; # 標明此伺服器名稱
default-lease-time 21600; # 租約使用時間： 6 小時
max-lease-time 86400; # 最大租期長度： 1 天
option domain-name-servers 168.95.192.1,168.95.1.1 ; # 可用的名稱伺服器
option domain-name "nat"; # 所屬的網域名稱
option routers 192.168.1.254 ; # 子網路路由器(gateway)
option broadcast-address 192.168.1.255 ; # 廣播封包位置
option perform-mask-discovery on;
option mask-supplier on;
ddns-update-style none;    #### ------ 宣告 NAT 網域之動態IP ------ ####    group {    subnet 192.168.1.0 netmask 255.255.255.0 { # 子網路與網路遮罩
range dynamic-bootp 192.168.1.20 192.168.1.30 ; # 動態分配 IP 位置範圍
}
}    啟動 /usr/sbin/dhcpd -cf /usr/local/etc/dhcpd.conf vr1(rc.local)
/usr/sbin/dhcpd -cf 設定檔 網路卡代號    我發現這一行一定要有，因配合bind-8.2.3-REL，ddns-update-style動態更新DNS資料，設定方式有三種： 
ddns-update-style ad-hoc 
ddns-update-style interim 
ddns-update-style none     執行成功後的訊息畫面。 
Internet Software Consortium DHCP Server V3.0rc11
Copyright 1995-2001 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 0 leases to leases file.
Listening on BPF/vr1/00:50:ba:cd:08:5e/192.168.1.0
Sending on BPF/vr1/00:50:ba:cd:08:5e/192.168.1.0
Sending on Socket/fallback/fallback-net        man dhcpd.conf 
dhcpd.conf(5) dhcpd.conf(5)        NAME
dhcpd.conf - dhcpd configuration file    DESCRIPTION
The dhcpd.conf file contains configuration information for
dhcpd, the Internet Software Consortium DHCP Server.    The dhcpd.conf file is a free-form ASCII text file. It
is parsed by the recursive-descent parser built into
dhcpd. The file may contain extra tabs and newlines for
formatting purposes. Keywords in the file are case-insen-
sitive. Comments may be placed anywhere within the file
(except within quotes). Comments begin with the # char-
acter and end at the end of the line.    The file essentially consists of a list of statements.
Statements fall into two broad categories - parameters and
declarations.    Parameter statements either say how to do something (e.g.,
how long a lease to offer), whether to do something (e.g.,
should dhcpd provide addresses to unknown clients), or
what parameters to provide to the client (e.g., use gate-
way 220.177.244.7).    Declarations are used to describe the topology of the net-
work, to describe clients on the network, to provide
addresses that can be assigned to clients, or to apply a
group of parameters to a group of declarations. In any
group of parameters and declarations, all parameters must
be specified before any declarations which depend on those
parameters may be specified.    Declarations about network topology include the
shared-network and the subnet declarations. If clients
on a subnet are to be assigned addresses dynamically, a
range declaration must appear within the subnet declara-
tion. For clients with statically assigned addresses, or
for installations where only known clients will be served,
each such client must have a host declaration. If param-
eters are to be applied to a group of declarations which
are not related strictly on a per-subnet basis, the group
declaration can be used.    For every subnet which will be served, and for every sub-
net to which the dhcp server is connected, there must be
one subnet declaration, which tells dhcpd how to recognize
that an address is on that subnet. A subnet declaration
is required for each subnet even if no addresses will be
dynamically allocated on that subnet.    Some installations have physical networks on which more
than one IP subnet operates. For example, if there is a
site-wide requirement that 8-bit subnet masks be used, but
a department with a single physical ethernet network
expands to the point where it has more than 254 nodes, it
may be necessary to run two 8-bit subnets on the same eth-
ernet until such time as a new physical network can be
added. In this case, the subnet declarations for these
two networks must be enclosed in a shared-network declara-
tion.    Some sites may have departments which have clients on more
than one subnet, but it may be desirable to offer those
clients a uniform set of parameters which are different
than what would be offered to clients from other depart-
ments on the same subnet. For clients which will be
declared explicitly with host declarations, these declara-
tions can be enclosed in a group declaration along with
the parameters which are common to that department. For
clients whose addresses will be dynamically assigned,
class declarations and conditional declarations may be
used to group parameter assignments based on information
the client sends.    When a client is to be booted, its boot parameters are
determined by consulting that client's host declaration
(if any), and then consulting any class declarations
matching the client, followed by the pool, subnet and
shared-network declarations for the IP address assigned to
the client. Each of these declarations itself appears
within a lexical scope, and all declarations at less spe-
cific lexical scopes are also consulted for client option
declarations. Scopes are never considered twice, and if
parameters are declared in more than one scope, the param-
eter declared in the most specific scope is the one that
is used.    When dhcpd tries to find a host declaration for a client,
it first looks for a host declaration which has a fixed-
address parameter which matches the subnet or shared net-
work on which the client is booting. If it doesn't find
any such entry, it then tries to find an entry which has
no fixed-address parameter.    EXAMPLES
A typical dhcpd.conf file will look something like this:    global parameters...    subnet 204.254.239.0 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.10 204.254.239.30;
}    subnet 204.254.239.32 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.42 204.254.239.62;
}    subnet 204.254.239.64 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.74 204.254.239.94;
}    group {
group-specific parameters...
host zappo.test.isc.org {
host-specific parameters...
}
host beppo.test.isc.org {
host-specific parameters...
}
host harpo.test.isc.org {
host-specific parameters...
}
}    Figure 1    Notice that at the beginning of the file, there's a place
for global parameters. These might be things like the
organization's domain name, the addresses of the name
servers (if they are common to the entire organization),
and so on. So, for example:    option domain-name "isc.org";
option domain-name-servers ns1.isc.org, ns2.isc.org;    Figure 2    As you can see in Figure 2, you can specify host addresses
in parameters using their domain names rather than their
numeric IP addresses. If a given hostname resolves to
more than one IP address (for example, if that host has
two ethernet interfaces), then where possible, both
addresses are supplied to the client.    The most obvious reason for having subnet-specific parame-
ters as shown in Figure 1 is that each subnet, of neces-
sity, has its own router. So for the first subnet, for
example, there should be something like:    option routers 204.254.239.1;    Note that the address here is specified numerically.
This is not required - if you have a different domain name
for each interface on your router, it's perfectly legiti-
mate to use the domain name for that interface instead of
the numeric address. However, in many cases there may be
only one domain name for all of a router's IP addresses,
and it would not be appropriate to use that name here.    In Figure 1 there is also a group statement, which pro-
vides common parameters for a set of three hosts - zappo,
beppo and harpo. As you can see, these hosts are all in
the test.isc.org domain, so it might make sense for a
group-specific parameter to override the domain name sup-
plied to these hosts:    option domain-name "test.isc.org";    Also, given the domain they're in, these are probably test
machines. If we wanted to test the DHCP leasing mecha-
nism, we might set the lease timeout somewhat shorter than
the default:    max-lease-time 120;
default-lease-time 120;    You may have noticed that while some parameters start with
the option keyword, some do not. Parameters starting
with the option keyword correspond to actual DHCP options,
while parameters that do not start with the option keyword
either control the behavior of the DHCP server (e.g., how
long a lease dhcpd will give out), or specify client
parameters that are not optional in the DHCP protocol (for
example, server-name and filename).    In Figure 1, each host had host-specific parameters.
These could include such things as the hostname option,
the name of a file to upload (the filename parameter) and
the address of the server from which to upload the file
(the next-server parameter). In general, any parameter
can appear anywhere that parameters are allowed, and will
be applied according to the scope in which the parameter
appears.    Imagine that you have a site with a lot of NCD X-Termi-
nals. These terminals come in a variety of models, and
you want to specify the boot files for each model. One
way to do this would be to have host declarations for each
server and group them by model:    group {
filename "Xncd19r";
next-server ncd-booter;    host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
}    group {
filename "Xncd19c";
next-server ncd-booter;    host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
}    group {
filename "XncdHMX";
next-server ncd-booter;    host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
}    ADDRESS POOLS
The pool declaration can be used to specify a pool of
addresses that will be treated differently than another
pool of addresses, even on the same network segment or
subnet. For example, you may want to provide a large set
of addresses that can be assigned to DHCP clients that are
registered to your DHCP server, while providing a smaller
set of addresses, possibly with short lease times, that
are available for unknown clients. If you have a fire-
wall, you may be able to arrange for addresses from one
pool to be allowed access to the Internet, while addresses
in another pool are not, thus encouraging users to regis-
ter their DHCP clients. To do this, you would set up a
pair of pool declarations:    subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.254;    # Unknown clients get this pool.
pool {
option domain-name-servers bogus.example.com;
max-lease-time 300;
range 10.0.0.200 10.0.0.253;
allow unknown clients;
}    # Known clients get this pool.
pool {
option domain-name-servers ns1.example.com, ns2.example.com;
max-lease-time 28800;
range 10.0.0.5 10.0.0.199;
deny unknown clients;
}
}    It is also possible to set up entirely different subnets
for known and unknown clients - address pools exist at the
level of shared networks, so address ranges within pool
declarations can be on different subnets.    As you can see in the preceding example, pools can have
permit lists that control which clients are allowed access
to the pool and which aren't. Each entry in a pool's per-
mit list is introduced with the allow or deny keyword.
If a pool has a permit list, then only those clients that
match specific entries on the permit list will be eligible
to be assigned addresses from the pool. If a pool has a
deny list, then only those clients that do not match any
entries on the deny list will be eligible. If both per-
mit and deny lists exist for a pool, then only clients
that match the permit list and do not match the deny list
will be allowed access.    DYNAMIC ADDRESS ALLOCATION
Address allocation is actually only done when a client is
in the INIT state and has sent a DHCPDISCOVER message. If
the client thinks it has a valid lease and sends a DHCPRE-
QUEST to initiate or renew that lease, the server has only
three choices - it can ignore the DHCPREQUEST, send a
DHCPNAK to tell the client it should stop using the
address, or send a DHCPACK, telling the client to go ahead
and use the address for a while.    If the server finds the address the client is requesting,
and that address is available to the client, the server
will send a DHCPACK. If the address is no longer avail-
able, or the client isn't permitted to have it, the server
will send a DHCPNAK. If the server knows nothing about
the address, it will remain silent, unless the address is
incorrect for the network segment to which the client has
been attached and the server is authoritative for that
network segment, in which case the server will send a
DHCPNAK even though it doesn't know about the address.    There may be a host declaration matching the client's
identification, and that host declaration contains a
fixed-address declaration that is valid for the network
segment to which the client is connected. In this case,
the DHCP server will never do dynamic address allocation.
In this case, the client is required to take the address
specified in the host declaration. If the client is
requesting some other address, the server will respond
with a DHCPNAK.    When the DHCP server allocates a new address for a client
(remember, this only happens if the client has sent a
DHCPDISCOVER), it first looks to see if the client already
has a valid lease on an IP address, or if there is an old
IP address the client had before that hasn't yet been
reassigned. In that case, the server will take that
address and check it to see if the client is still permit-
ted to use it. If the client is no longer permitted to
use it, the lease is freed if the server thought it was
still in use - the fact that the client has sent a
DHCPDISCOVER proves to the server that the client is no
longer using the lease.    If no existing lease is found, or if the client is forbid-
den to receive the existing lease, then the server will
look in the list of address pools for the network segment
to which the client is attached for a lease that is not in
use and that the client is permitted to have. It looks
through each pool declaration in sequence (all range dec-
larations that appear outside of pool declarations are
grouped into a single pool with no permit list). If the
permit list for the pool allows the client to be allocated
an address from that pool, the pool is examined to see if
there is an address available. If so, then the client is
tentatively assigned that address. Otherwise, the next
pool is tested. If no addresses are found that can be
assigned to the client, no response is sent to the client.    If an address is found that the client is permitted to
have, and that has never been assigned to any client
before, the address is immediately allocated to the
client. If the address is available for allocation but
has been previously assigned to a different client, the
server will keep looking in hopes of finding an address
that has never before been assigned to a client.    IP ADDRESS CONFLICT PREVENTION
The DHCP server checks IP addresses to see if they are in
use before allocating them to clients. It does this by
sending an ICMP Echo request message to the IP address
being allocated. If no ICMP Echo reply is received
within a second, the address is assumed to be free. This
is only done for leases that have been specified in range
statements, and only when the lease is thought by the DHCP
server to be free - i.e., the DHCP server or its failover
peer has not listed the lease as in use.    If a response is received to an ICMP Echo request, the
DHCP server assumes that there is a configuration error -
the IP address is in use by some host on the network that
is not a DHCP client. It marks the address as abandoned,
and will not assign it to clients.    If a DHCP client tries to get an IP address, but none are
available, but there are abandoned IP addresses, then the
DHCP server will attempt to reclaim an abandoned IP
address. It marks one IP address as free, and then does
the same ICMP Echo request check described previously.
If there is no answer to the ICMP Echo request, the
address is assigned to the client.    The DHCP server does not cycle through abandoned IP
addresses if the first IP address it tries to reclaim is
free. Rather, when the next DHCPDISCOVER comes in from
the client, it will attempt a new allocation using the
same method described here, and will typically try a new
IP address.    DHCP FAILOVER
This version of the ISC DHCP server supports the DHCP
failover protocol as documented in draft-ietf-dhc-
failover-07.txt. This is not a final protocol document,
and we have not done interoperability testing with other
vendors' implementations of this protocol, so you must not
assume that this implementation conforms to the standard.
If you wish to use the failover protocol, make sure that
both failover peers are running the same version of the
ISC DHCP server.    The failover protocol allows two DHCP servers (and no more
than two) to share a common address pool. Each server
will have about half of the available IP addresses in the
pool at any given time for allocation. If one server
fails, the other server will continue to renew leases out
of the pool, and will allocate new addresses out of the
roughly half of available addresses that it had when com-
munications with the other server were lost.    It is possible during a prolonged failure to tell the
remaining server that the other server is down, in which
case the remaining server will (over time) reclaim all the
addresses the other server had available for allocation,
and begin to reuse them. This is called putting the
server into the PARTNER-DOWN state.    You can put the server into the PARTNER-DOWN state either
by using the omshell (8) command or by stopping the
server, editing the last peer state declaration in the
lease file, and restarting the server. If you use this
last method, be sure to leave the date and time of the
start of the state blank:    failover peer name state {
my state partner-down;
peer state state at date;
}    When the other server comes back online, it should auto-
matically detect that it has been offline and request a
complete update from the server that was running in the
PARTNER-DOWN state, and then both servers will resume pro-
cessing together.    It is possible to get into a dangerous situation: if you
put one server into the PARTNER-DOWN state, and then
*that* server goes down, and the other server comes back
up, the other server will not know that the first server
was in the PARTNER-DOWN state, and may issue addresses
previously issued by the other server to different
clients, resulting in IP address conflicts. Before
putting a server into PARTNER-DOWN state, therefore, make
sure that the other server will not restart automatically.    The failover protocol defines a primary server role and a
secondary server role. There are some differences in how
primaries and secondaries act, but most of the differences
simply have to do with providing a way for each peer to
behave in the opposite way from the other. So one server
must be configured as primary, and the other must be con-
figured as secondary, and it doesn't matter too much which
one is which.    FAILOVER STARTUP
When a server starts that has not previously communicated
with its failover peer, it must establish communications
with its failover peer and synchronize with it before it
can serve clients. This can happen either because you
have just configured your DHCP servers to perform failover
for the first time, or because one of your failover
servers has failed catastrophically and lost its database.    The initial recovery process is designed to ensure that
when one failover peer loses its database and then
resynchronizes, any leases that the failed server gave out
before it failed will be honored. When the failed server
starts up, it notices that it has no saved failover state,
and attempts to contact its peer.    When it has established contact, it asks the peer for a
complete copy its peer's lease database. The peer then
sends its complete database, and sends a message indicat-
ing that it is done. The failed server then waits until
MCLT has passed, and once MCLT has passed both servers
make the transition back into normal operation. This
waiting period ensures that any leases the failed server
may have given out while out of contact with its partner
will have expired.    While the failed server is recovering, its partner remains
in the partner-down state, which means that it is serving
all clients. The failed server provides no service at all
to DHCP clients until it has made the transition into nor-
mal operation.    In the case where both servers detect that they have never
before communicated with their partner, they both come up
in this recovery state and follow the procedure we have
just described. In this case, no service will be pro-
vided to DHCP clients until MCLT has expired.    CONFIGURING FAILOVER
In order to configure failover, you need to write a peer
declaration that configures the failover protocol, and you
need to write peer references in each pool declaration for
which you want to do failover. You do not have to do
failover for all pools on a given network segment. You
must not tell one server it's doing failover on a particu-
lar address pool and tell the other it is not. You must
not have any common address pools on which you are not
doing failover.    The server currently does very little sanity checking,
so if you configure it wrong, it will just fail in odd
ways. I would recommend therefore that you either do
failover or don't do failover, but don't do any mixed
pools. Also, use the same master configuration file for
both servers, and have a seperate file that con-
tains the peer declaration and includes the master file.
This will help you to avoid configuration mismatches. As
our implementation evolves, this will become less of a
problem. A basic sample dhcpd.conf file for a primary
server might look like this:    failover peer "foo" {
primary;
address anthrax.rc.vix.com;
port 519;
peer address trantor.rc.vix.com;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;
load balance max seconds 3;
}    include "/etc/dhcpd.master";    The statements in the peer declaration are as follows:    The primary and secondary statements    [ primary | secondary ];    This determines whether the server is primary or sec-
ondary, as described earlier under DHCP FAILOVER.    The address statement    address address;    The address statement declares the IP address on which
the server should listen for connections from its
failover peer, and also the value to use for the DHCP
Failover Protocol server identifier. Because this
value is used as an identifier, it may not be omitted.    The peer address statement    peer address address;    The peer address statement declares the IP address to
which the server should connect to reach its failover
peer for failover messages.    The port statement    port port-number;    The port statement declares the TCP port on which the
server should listen for connections from its failover
peer. This statement may not currently be omitted,
because the failover protocol does not yet have a
reserved TCP port number.    The peer port statement    peer port port-number;    The peer port statement declares the TCP port to which
the server should connect to reach its failover peer
for failover messages. This statement may not be
omitted because the failover protocol does not yet have
a reserved TCP port number. The port number declared
in the peer port statement may be the same as the port
number declared in the port statement.    The max-response-delay statement    max-response-delay seconds;    The max-response-delay statement tells the DHCP server
how many seconds may pass without receiving a message
from its failover peer before it assumes that connec-
tion has failed. This number should be small enough
that a transient network failure that breaks the con-
nection will not result in the servers being out of
communication for a long time, but large enough that
the server isn't constantly making and breaking connec-
tions. This parameter must be specified.    The max-unacked-updates statement    max-unacked-updates count;    The max-unacked-updates statement tells the DHCP server
how many BNDUPD messages it can send before it receives
a BNDACK from the failover peer. We don't have enough
operational experience to say what a good value for
this is, but 10 seems to work. This parameter must be
specified.    The mclt statement    mclt seconds;    The mclt statement defines the Maximum Client Lead
Time. It must be specified on the primary, and may
not be specified on the secondary. This is the length
of time for which a lease may be renewed by either
failover peer without contacting the other. The
longer you set this, the longer it will take for the
running server to recover IP addresses after moving
into PARTNER-DOWN state. The shorter you set it, the
more load your servers will experience when they are
not communicating. A value of something like 3600 is
probably reasonable, but again bear in mind that we
have no real operational experience with this.    The split statement    split index;    The split statement specifies the split between the
primary and secondary for the purposes of load balanc-
ing. Whenever a client makes a DHCP request, the DHCP
server runs a hash on the client identification. If
the hash comes out to less than the split value, the
primary answers. If it comes out to equal to or more
than the split, the secondary answers. This value
should generally be set to 128, and can only be config-
ured on the primary.    The hba statement    hba colon-seperated-hex-list;    The hba statement specifies the split between the pri-
mary and secondary as a bitmap rather than a cutoff,
which theoretically allows for finer-grained control.
In practice, there is probably no need for such fine-
grained control, however. An example hba statement:    hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;    The load balance max seconds statement    load balance max seconds seconds;    This statement allows you to configure a cutoff after
which load balancing is disabled. The cutoff is based
on the number of seconds since the client sent its
first DHCPDISCOVER or DHCPREQUEST message, and only
works with clients that correctly implement the secs
field - fortunately most clients do. We recommend set-
ting this to something like 3 or 5. The effect of this
is that if one of the failover peers gets into a state
where it is responding to failover messages but not
responding to some client requests, the other failover
peer will take over its client load automatically as
the clients retry.    CLIENT CLASSING
Clients can be seperated into classes, and treated differ-
ently depending on what class they are in. This sepera-
tion 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 would write a conditional statement to match the
clients you wanted in the class, and then put an add
statement in the conditional's list of statements:    if substring (option dhcp-client-identifier, 1, 3) = "RAS " {
add "ras-clients";
}    A nearly equivalent way to do this is to simply specify
the conditional expression as 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 state-
ments for a class, the declaration should look like this:
class "ras-clients" {
}    Also, the add statement adds the client to the class as
the client's scopes are being evaluated - after any
address assignment decision has been made. This means
that a client that's a member of a class due to an add
statement will not be affected by pool permits related to
that class - when the pool permit list is computed, the
client will not yet be a member of the pool. This is an
inconsistency that will probably be addressed in later
versions of the DHCP server, but it is important to be
aware of it at least for the time being.    SUBCLASSES
In addition to classes, it is possible to declare sub-
classes. 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. Sub-
classes 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 declara-
tion 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 sub-
classes are declared without scopes. If part of the pur-
pose 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 declaration 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 con-
trol 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 de