Tải bản đầy đủ
[Chapter 9] 9.4 A BOOTP Server

[Chapter 9] 9.4 A BOOTP Server

Tải bản đầy đủ

[Chapter 9] 9.4 A BOOTP Server

You should define all network services, including BOOTP, in the /etc/services file. Add the following lines to your
/etc/service file when bootpd is installed:
bootps
bootpc

67/udp
68/udp

# bootp server
# bootp client

Finally, make sure that you include bootpd in the /etc/inetd.conf file as shown earlier in this section. Once it is
included and inetd is reloaded with a SIGHUP signal, you are ready to run.
Installing the daemon is only the beginning. The real challenge of managing a BOOTP server is providing the
configuration information that clients need. The package found on Linux systems and in the bootp-DD2.4.3.tar file is
the BOOTP daemon from Carnegie Mellon University (CMU). It has its own unique configuration commands. Other
BOOTP server implementations use other configuration commands. However, the type of information provided by
BOOTP is the same regardless of the implementation.
The CMU server reads its configuration from the /etc/bootptab file. The syntax used in this file is very similar to the
syntax of the /etc/termcap and the /etc/printcap files. Each bootpd configuration parameter is two characters long and
is separated from the other parameters by a colon. The general format of a bootptab entry is:
hostname:pa=value:pa=value:pa=value...
Where hostname is the hostname of the client, pa is the two character parameter name, and value is the value assigned
to that parameter for this client.
Newline characters separate each client's entry. If an entry spans multiple lines, the newline character at the end of
each line must be escaped with a backslash (\). Comments in the bootptab file begin with a sharp sign (#). Table 9.3
contains a list of the bootptab configuration parameters.
Table 9.3: bootptab Configuration Parameters
Parameter Description
bf
Bootfile
bs
Bootfile size
cs
Cookie servers list
df
Dump file
dn
Domain name
ds
Domain name servers list
ef
Vendor extension file
gw
Gateways list
ha
Hardware address
hd
Bootfile directory
hn
Send hostname boolean
ht
Hardware type
im
Impress servers list
ip
Host IP address
lg
Log servers list
lp
LPR servers list
ns
IEN-116 name servers list

Example
:bf=null
:bs=22050
:cs=172.16.3.7
:df=/var/tmp/bootp_db.dump
:dn=nuts.com
:ds=172.16.35.5
:ef=/usr/local/xyz.extensions
:gw=128.2.13.1
:ha=7FF8100000AF
:hd=/usr/boot
:hn
:ht=ethernet
:im=172.16.8.12
:ip=172.16.11.1
:lg=172.16.12.1
:lp=172.16.6.6
:ns=172.16.12.6

file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (2 of 7) [2001-10-15 09:18:32]

[Chapter 9] 9.4 A BOOTP Server

nt
ra
rl
sa
sm
sw
Tn
tc
td
to
ts
vm
yd
ys

Network Time Protocol server list :nt=172.16.50.30
Reply address list
:ra=172.16.12.255
Resource location servers
:rl=172.16.99.35
TFTP server
:sa=172.16.12.1
Subnet mask
:sm=255.255.255.0
Swap server
:sw=172.16.12.56
Vendor extension n
:T132="12345927AD3B"
Template continuation
:tc=default1
Secure TFTP directory
:td=/tftpboot
Time offset
:to=18000
Time servers list
:ts=172.16.12.1
Vendor magic cookie selector
:vm=auto
NIS domain name
:yd=nuts
NIS server
:ys=172.16.12.1

Every parameter in Table 9.3 that has the word "list" in its description accepts a list of whitespace-separated values.
For example, the name server list is defined using the ds parameter in this format: :ds=172.16.12.1 172.16.7.3:. One
parameter in the table, hn, is a Boolean. If it is specified, the server sends the hostname from the bootptab entry to the
client. As a Boolean hn does not take any values, but all the other parameters do.
Use these parameters to configure TCP/IP for each client on your network. The following sample bootptab file defines
the domain name, name servers, the default routers, the Ethernet addresses, the hostnames, the IP addresses, the print
servers, and the subnet masks for three different systems. (Don't worry about the details yet; each command will be
explained later.)
# /etc/bootptab file for nuts.com
acorn:\
:hd=/usr/boot:bf=null:\
:ds=172.16.12.1 172.16.3.5:\
:sm=255.255.255.0:\
:lp=172.16.12.1:\
:gw=172.16.3.25:\
:ht=1:ha=0080c7aaa804:\
:dn=nuts.com:hn:ip=172.16.3.4:
peanut:\
:hd=/usr/boot:bf=null:\
:ds=172.16.12.1 172.16.3.5:\
:sm=255.255.255.0:\
:lp=172.16.12.1:\
:gw=172.16.12.1:\
:ht=1:ha=0800200159C3:\
:dn=nuts.com:hn:ip=172.16.12.2:
hickory:\
:hd=/usr/boot:bf=null:\
:ds=172.16.12.1 172.16.3.5:\
:sm=255.255.255.0:\
:lp=172.16.12.1:\
:gw=172.16.3.25:\
:ht=1:ha=0000c0a15e10:\
:dn=nuts.com:hn:ip=172.16.3.16
file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (3 of 7) [2001-10-15 09:18:32]

[Chapter 9] 9.4 A BOOTP Server

Notice that much of the information is repetitive. All of the clients use the same domain name, name servers, subnet
masks, and print servers. Systems on the same subnets also use the same default routers. It is possible to define
repetitive information in templates that are then referenced in individual client configurations. The following example
uses a global template that defines the domain name, name servers, subnet mask, and print servers. The template is
then referenced in each of the subsequent configurations by using the tc parameter.
# /etc/bootptab file for nuts.com
defaults:\
:hd=/usr/boot:\
:dn=nuts.com:ds=172.16.12.1 172.16.3.5:\
:sm=255.255.255.0:\
:lp=172.16.12.1:\
:hn:
acorn:\
:tc=defaults:\
:bf=null:\
:gw=172.16.3.25:\
:ht=1:ha=0080c7aaa804:\
:ip=172.16.3.4:
peanut:\
:tc=defaults:\
:bf=null:\
:gw=172.16.12.1:\
:ht=1:ha=0800200159C3:\
:ip=172.16.12.2:
hickory:\
:tc=defaults:\
:bf=null:\
:gw=172.16.3.25:\
:ht=1:ha=0000c0a15e10:\
:ip=172.16.3.16:
The first entry, defaults, is the template. The remaining entries are client entries. The template defines information used
by all of the hosts and the specific client entries define information unique to those hosts. Looking at the template and
at one of the host entries shows a full configuration. First, let's examine the meaning of each parameter in the defaults
template:
defaults:\
The name by which this template is referenced is defaults. A template can be assigned any name as long as it
doesn't conflict with any hostname in the bootptab file.
:hd=/usr/boot:\
The first line of the defaults template defines the boot directory (hd). BOOTP clients can be diskless systems
that boot from the server. The value provided by hd is used by a diskless system to retrieve the boot image. This
directory is not used by our clients, but could be needed if a terminal server, router, or other diskless device was
added to the network.
:dn=nuts.com:ds=172.16.12.1 172.16.3.5:\
This line defines the domain name and the addresses of the domain name servers. The dn parameter defines the
domain name as nuts.com. The ds parameter defines the IP addresses of the name servers used on this network.
:sm=255.255.255.0:\
file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (4 of 7) [2001-10-15 09:18:32]

[Chapter 9] 9.4 A BOOTP Server

The sm parameter defines this network's subnet mask.
:lp=172.16.12.1:\
This parameter defines the IP address of an lpr server that is available to every system on the network.
:hn:
The hn parameter tells the server to send the hostname to the client. When this parameter is incorporated in the
peanut entry as part of this template, the server sends the name peanut to the client. When it is incorporated in
the entry for acorn, the name acorn is sent. Because this is the last line in the defaults template, it does not end
with a backslash.
Now let's look at the parameters in a client entry:
acorn:\
The hostname associated with this client entry is acorn.
:tc=defaults:\
This tc parameter tells bootpd to incorporate all of the information defined in the defaults template into this
client entry. To use multiple templates in a client entry, include multiple tc parameters. Exclude an individual
parameter from a template by specifying the parameter preceded by an at-sign (@). For example, to exclude the
lpr server parameter provided by the defaults template from inclusion in the acorn configuration, we could have
added :@lp: to the acorn entry.
:bf=null:\
The bf parameter defines the name of the boot file for diskless systems. In the sample, the parameter
intentionally points to a file that does not exist because the client has a disk and we want it to boot from its local
disk. When a client has its own disk, a value is not required in this field. However, in this case, the value is
commonly set to "null" to ensure that if the client accidently has a boot file value in its BOOTREQUEST
packet, the value will be overwritten by the server.
:gw=172.16.3.25:\
The default gateway for this subnet is 172.16.3.25.
:ht=1:ha=0080c7aaa804:\
The ht parameter identifies the type of hardware used for the client's network interface. The hardware type is
identified by a number or by a keyword. There are several possible values but only two are meaningful: ht will
be either 1 for Ethernet or 6 for Token Ring. See the bootptab manpage if you're interested in the other, rarely
used, values.
The ha parameter defines the physical hardware address associated with the client's network interface. The
example shows an Ethernet address. The type of address provided must be consistent with the hardware type
defined by the ht parameter. These two parameters always appear together in a bootptab file.
:ip=172.16.3.4:\
The IP address for this client is 172.16.3.4.
With only three clients in the example, the benefit of using templates may not be immediately clear. The benefits of
saving time, reducing typing, and avoiding errors are clearer when a large number of systems are involved.
It is possible to configure a BOOTP server to handle a very large number of clients. However, if a large number of
file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (5 of 7) [2001-10-15 09:18:32]

[Chapter 9] 9.4 A BOOTP Server

clients rely on a single boot server and all of the clients attempt to boot at one time, the server can be overwhelmed.
This might happen in the case of a power outage. There are two mitigating fators: Because most clients cache the
configuration provided by the server in a local disk file, they are not completely dependent on the server; and the
BOOTP protocol includes back-off algorithms that avoid contention problems. Still, it is possible for an overloaded
server to cause a significant delay when booting its clients. One way to avoid problems is to have several boot servers.
One server for each subnet is a good design because it eliminates the need to pass BOOTP information through a
router, which requires a special configuration.

9.4.1 BOOTP gateway
Normally a BOOTREQUEST packet is not forwarded between networks because it is transmitted from the client using
the limited broadcast address - 255.255.255.255. According to the RFCs, the limited broadcast address should not be
forwarded, though it is possible to configure some routers to do so. The CMU BOOTP software provides a BOOTP
gateway program that eliminates the need to create a special router configuration and allows you to put the
configuration server on a different subnet from the BOOTP clients. The BOOTP gateway is bootpgw.
If your system includes BOOTP software, you may already have bootpgw. Linux includes bootpgw. If your system
doesn't have it, it will when you download and install the bootp-2.4.3.tar file.
bootpgw is run as an alternative to bootpd. Both of these programs listen to the same port. The inetd.conf entry for
bootpgw is:
bootps

dgram

udp

wait

root

/usr/sbin/bootpgw bootpgw 172.16.12.1

inetd listens to the bootps port and starts the bootpgw program when data is received on that port. (Adding the bootps
port to /etc/services is covered above in the bootpd installation.) When bootpgw starts, it reads the hostname or
address of the BOOTP server from the command line. In the example, the remote BOOTP server is 172.16.12.1. If the
data received on the bootps port is a BOOTREQUEST packet, bootpgw retransmits the BOOTREQUEST as a unicast
packet addressed directly to the remote configuration server.
At least one system on each subnet must run either bootpd or bootpgw to either reply to BOOTREQUEST packets or
to forward them to a system that will. It is not possible to run both bootpd and bootpgw on one system and there is no
reason to try. If the subnet has a local BOOTP server up and running, there is no need to forward BOOTREQUEST
packets to another network. Use bootpgw on very small subnets that do not justify a local configuration server. On all
other subnets, use a local BOOTP server.

9.4.2 BOOTP extensions
As described in Chapter 3, Dynamic Host Configuration Protocol (DHCP) is based on the Bootstrap Protocol
(BOOTP). As you might expect, the DHCP enhancements are included in the bootp-2.4.3.tar file. Set the DDYNAMIC option in the Makefile to compile the DHCP extensions into bootpd. The DHCP extensions add the
following /etc/bootptab configuration parameters:
:T254=number
The number of addresses that can be dynamically assigned, written in hex.
:T253=mode
The mode in which dynamic addresses are written into the updated bootptab file. If the mode is 0, addresses are
written as IP addresses. If the mode is 1, addresses must be written as hostnames. If a hostname can't be found
for a dynamically assigned address, the address assignment is not made when the mode is set to 1. If the mode

file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (6 of 7) [2001-10-15 09:18:32]

[Chapter 9] 9.4 A BOOTP Server

is 2, the dynamic address is written to the bootptab file as a hostname if there is a valid hostname for the
address. If there is not, the IP address is used. Mode 2 is the default and usually should not be changed.
:T250=string
The string contains any additional configuration settings that should be provided to the DHCP clients in the
form of bootptab parameters.
:dl=time
The amount of time that the client can keep the address. The client must renew its request for the address
before the amount of time specified with the dl parameter has elapsed. If the client does not renew its lease on
the address, the server is free to assign the address to another client. If the dl parameter is not used, the address
is permanently assigned.
To use these parameters in the bootptab file, create a special entry in the file that begins with the string .dynamic-n. n
in this string is a number from 1 to 32767. An example should make this clear. Assume that we want to automatically
assign the addresses from 172.16.12.64 to 172.16.12.192, and that we want to manually assign the other addresses. We
might enter the following in the bootptab file:
.dynamic-1:ip=172.16.12.64:T254=0x80:T250="gw=172.16.12.1:ds=172.16.12.3"
This defines a dynamic address group starting at 172.16.12.64. The group contains 128 (80 hex) available addresses.
Tell clients assigned an address from this group to use 172.16.12.3 as a name server and to use 172.16.12.1 as a
gateway.
When bootpd receives an address request from a client it creates an entry for the client using the information defined
above, and physically appends that new entry to the end of the bootptab file. The first client request adds the following
entry to the end of the bootptab file:
172.16.12.64:ha=0080c7aaa804:gw=172.16.12.1:ds=172.16.12.3
To assign the client a hostname instead of just an IP address, add hostnames to the domain server database for all of the
addresses in the address group.
These extensions help bootpd provide services to DHCP clients. There are also software packages available that have
been designed from the beginning to be DHCP servers.

Previous: 9.3 Network
Information Service
9.3 Network Information
Service

TCP/IP Network
Administration
Book Index

Next: 9.5 DHCP
9.5 DHCP

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_04.htm (7 of 7) [2001-10-15 09:18:32]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm

Previous: 9.4 A BOOTP
Server

Chapter 9
Configuring Network Servers

Next: 9.6 Managing
Distributed Servers

9.5 DHCP
Dynamic Host Configuration Protocol provides three important features:
Backward compatibility with Bootstrap Protocol (BOOTP)
A DHCP server can support BOOTP clients. Properly configured, a DHCP server can support
all of your clients.
Full configurations
A DHCP server provides a complete set of TCP/IP configuration parameters. (See Appendix
D, A dhcpd Reference, for a full list.) The network administrator can handle the entire
configuration for her users.
Dynamic address assignments
A DHCP server can provide permanent addresses manually, permanent addresses
automatically, and temporary addresses dynamically. The network administrator can tailor the
type of address to the needs of the network and the client system.
In this section we configure a DHCP server that supports BOOTP clients, performs dynamic address
allocation, and provides a wide range of configuration parameters for its clients.
Several implementations of DHCP are available for UNIX systems. Some are commercial packages
and some run on a specific version of UNIX. We use the Internet Software Consortium (ISC)
Dynamic Host Configuration Protocol Daemon (dhcpd). It is freely available over the Internet and
runs on a wide variety of UNIX systems, including both our Linux and Solaris sample systems. (See
Appendix D for information on downloading and compiling dhcpd.) If you use different DHCP
server software, it will have different configuration commands, but it probably performs the same
basic functions.

9.5.1 dhcpd.conf
dhcpd reads its configuration from the /etc/dhcpd.conf file. The configuration file contains the
instructions that tell the server what subnets and hosts it services, and what configuration information
file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm (1 of 6) [2001-10-15 09:18:33]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm

it should provide them. dhcpd.conf is an ASCII text file that I find more readable than the bootptab
file. The easiest way to learn about the dhcpd.conf file is to look at a sample.
# Define global values that apply to all systems.
default-lease-time 86400;
max-lease-time 604800;
get-lease-hostnames true;
option subnet-mask 255.255.255.0;
option domain "nuts.com";
option domain-name-servers 172.16.12.1, 172.16.3.5;
option lpr-servers 172.16.12.1;
option interface-mtu 1500;
# Identify the subnet served, the options related
# to the subnet, and the range of addresses that
# are available for dynamic allocation.
subnet 172.16.3.0 netmask 255.255.255.0 {
option routers 172.16.3.25;
option broadcast-address 172.16.3.255;
range 172.16.3.50 172.16.3.250;
}
subnet 172.16.12.0 netmask 255.255.255.0 {
option routers 172.16.12.1;
option broadcast-address 172.16.12.255;
range 172.16.12.64 172.16.12.192;
range 172.16.12.200 172.16.12.250;
}
# Identify each BOOTP client with a host statement
group {
use-host-decl-names true;
host acorn {
hardware ethernet 00:80:c7:aa:a8:04;
fixed-address 172.16.3.4;
}
host peanut {
hardware ethernet 08:80:20:01:59:c3;
fixed-address 172.16.12.2;
}
host hickory {
hardware ethernet 00:00:c0:a1:5e:10;
fixed-address 172.16.3.16;
}
file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm (2 of 6) [2001-10-15 09:18:33]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm

}
This sample configuration file is similar to the example used above for bootptab. It defines a server
that is connecting to, and serving, two separate subnets. It assigns IP addresses dynamically to the
DHCP clients on each subnet and supports a few BOOTP clients. All of the lines that begin with a
sharp sign (#) are comments. The first real configuration line defines a parameter for the server.
We begin the dhcpd.conf file with a set of parameters and options that apply to all of the subnets and
clients served. The first three lines are parameters, which provide direction to the server. All three of
the sample parameters define some aspect of how dhcpd should handle dynamic address assignments.
default-lease-time
Tells the server how many seconds long a default address lease should be. The client can
request that the address be leased for a specific period of time. If it does, it is assigned the
address for that period of time, given some restrictions. Frequently, clients do not request a
specific lifetime for an address lease. When that happens, the default-lease-time is used. In the
example, the default lease is set to one day (86400 seconds).
max-lease-time
Sets the upper limit for how long an address can be leased. Regardless of the length of time
requested by the client, this is the longest address lease that dhcpd will grant. The life of the
lease is specified in seconds. In the example, it is one week.
get-lease-hostname
Directs dhcpd to provide a hostname to each client that is assigned a dynamic address. Further,
the hostname is to be obtained from DNS. This parameter is a Boolean. If it is set to false,
which is the default, the client receives an address but no hostname. Looking up the hostname
for every possible dynamic address adds substantial time to the startup. Set this to "false". Only
set this to true if the server handles a very small number of dynamic addresses.
We will use a few more parameters in this configuration. All of the parameters are documented in
Appendix D.
The next four lines are options. The options all start with the keyword option. The keyword is
followed by the name of the option and the value assigned to the option. Options define configuration
values that are used by the client.
The meaning of the sample options is easy to deduce. The option names are very descriptive. We are
providing the clients with the subnet mask, domain name, domain server addresses, and print server
address. These values parallel those in the bootptab example shown earlier in this chapter.
DHCP, however, can do more than BOOTP. For sake of illustration we also define the maximum
transmission unit (MTU). The sample interface-mtu option tells the client that the MTU is 1500
bytes. In this case the option is not needed because 1500 bytes is the default for Ethernet. However, it
file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm (3 of 6) [2001-10-15 09:18:33]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm

illustrates the point that DHCP can provide a very complete set of configuration information.
The subnet statements define the networks that dhcpd will serve. The identity of each network is
determined from the address and the address mask, both of which are required by the subnet
statement. dhcpd provides configuration services only to clients that are attached to one of these
networks. There must be a subnet statement for every subnet to which the server physically connects even if some subnets do not contain any clients. dhcpd requires the subnet information to complete its
startup.
The options and parameters defined in a subnet statement apply only to the subnet and its clients. The
meaning of the sample options is clear. They tell the clients what router to use and what broadcast
address to use. The range parameter is more interesting, as it goes to the heart of one of DHCP's key
features.
The range parameter defines the scope of addresses that are available for dynamic address allocation.
It always occurs in association with a subnet statement, and the range of addresses must fall within the
address space of the subnet. The scope of the range parameter is defined by the two addresses it
contains. The first address is the lowest address that can be automatically assigned and the second
address is the highest address that can be assigned. The first range parameter in the example identifies
a contiguous group of addresses from 172.16.12.50 to 172.16.12.250 that are available for dynamic
assignment. Notice that the second subnet statement has two range parameters. This creates two
separate groups of dynamic addresses. The reason for this might be that some addresses were already
manually assigned before the DHCP server was installed. Regardless of the reason, the point is that
we define a noncontiguous dynamic address space with multiple range statements.
If a range parameter is defined in a subnet statement, any DHCP client on the subnet that requests an
address is granted one as long as addresses are available. If a range parameter is not defined, dynamic
addressing is not enabled.
To provide automatic address assignment for BOOTP clients, add the dynamic-bootp argument to the
range parameter. For example:
range dynamic-bootp 172.16.8.10 172.16.8.50;
By default, BOOTP clients are assigned permanent addresses. It is possible to override this default
behavior with either the dynamic-bootp-lease-cutoff or the dynamic-bootp-lease-length parameter.
However, BOOTP clients do not understand address leases and they do not know that they should
renew an address. Therefore the dynamic-bootp-lease-cutoff and the dynamic-bootp-lease-length
parameters are only used in special circumstances. If you're interested in these parameters, see
Appendix D.
Each BOOTP client should have an associated host statement that is used to assign the client
configuration parameters and options. It can be used to manually assign the client a permanent, fixed
address. The sample configuration file ends with three host statements: one for acorn, one for peanut,
and one for hickory. Each host statement contains a hardware parameter that defines the type of
file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm (4 of 6) [2001-10-15 09:18:33]

file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm

network hardware (ethernet) and the physical network address (e.g., 08:80:20:01:59:c3)
used by the client. The hardware parameter is required in host statements for BOOTP clients. The
Ethernet address is used by dhcpd to identify the BOOTP client. DHCP clients can also have
associated host statements. For DHCP clients, the hardware parameter is optional because a DHCP
client can be identified by the dhcp-client-identifier option. However, it is simpler for a DHCP client
connected via Ethernet to be identified by its Ethernet address.
A wide variety of parameters and options can be defined in the host statement. For example, adding to
each host statement an option similar to the following one assigns each client a hostname:
option host-name acorn;
It is often easier, however, to define options and parameters at a higher level. Global options apply to
all systems. Subnet options apply to every client on the subnet, but the options defined inside of a host
statement only apply to a single host. The host-name option shown above would need to be repeated
with a different hostname in every host statement. An easier way to define a parameter or option for a
group of hosts is to use a group statement.
A group statement groups together any other statements. The sole purpose of the group statement is
to apply parameters and options to all members of the group. That is exactly what we do in the
example. The group statement in the sample configuration groups all of the host statements together.
The use-host-decl-names parameter in the group statement applies to every host in the group. This
particular parameter tells dhcpd to assign each client the hostname that is declared on the host
statement associated with that client, which makes the hostname option unnecessary for this
configuration.
Given the sample dhcpd.conf file shown earlier, when dhcpd receives a BOOTREQUEST packet
from a client with the Ethernet address 08:80:20:01:59:c3, it sends that client:










The address 172.16.12.2
The hostname peanut
The default router address 172.16.12.1
The broadcast address 172.16.12.255
The subnet mask 255.255.255.0
The domain name nuts.com
The domain name server addresses 172.16.12.1 and 172.16.3.5
The print server address 172.16.12.1
The MTU for an Ethernet interface

The client receives all global values, all subnet values and all host values that are appropriate. Clearly
DHCP can provide a complete configuration.
Your DHCP configuration, though larger in the number of systems supported, probably is simpler
than the example. Some commands appear in the sample primarily for the purpose of illustration. The
biggest difference is that most sites do not serve more than one subnet with a single configuration
file:///C|/mynapster/Downloads/warez/tcpip/ch09_05.htm (5 of 6) [2001-10-15 09:18:33]