This chapter describes the Dynamic Host Configuration Protocol (DHCP) client.
The DHCP client resides on the client host and dynamically sets the network configuration. The TCPware DHCP client communicates with a DHCP server to get an IP address and other configuration information. It uses this information to configure the network parameters of the host and to start up the network.
When the network starts on the host, the DHCP client communicates dynamically and automatically with the DHCP server in case reconfiguration is needed. The configuration information the client uses is defined by the policy stored in the DHCP server.
For more general DHCP information, see RFC2132 and RFC2131. Also, see Chapter 4 of this guide for general DHCP process and TCPware DHCP server information.
Beginning with TCPware 6.0, TCPware supplies two clients: v3 and v4. Only one can be run at any given time.
Because the DHCP client supports a single network interface on the host, you can only use it to configure a single network line in TCPware.
Process Software recommends that you do not use the DHCP client with other TCPware components that usually need a static IP address on the same host, such as DHCP server, authoritative DNS server, and GateD.
If this is your first time using a DHCP client on the host, you need to create a configuration file for it (TCPWARE:DHCLIENT.CONF). If you have been running the DHCP V3 client and want to change to running the DHCP V4 client, you can use the same configuration file.
If you need to create a configuration file, there are template configuration files available for both the DHCP V4 client (DHCLIENT) and the DHCP V4 client (DHCLIENT4) in the TCPWARE common directory.
To create a configuration file from one of the templates, do the following. For DHCLIENT:
$ COPY TCPWARE:DHCLIENT_CONF.TEMPLATE TCPWARE:DHCLIENT.CONF
Or for DHCLIENT4:
$ COPY TCPWARE:DHCLIENT4_CONF.TEMPLATE TCPWARE:DHCLIENT.CONF
The DHCP client configuration file should now be edited to specify the name of your host. Talk to your network administrator: the administrator may want to assign you a host name.
To specify a host name, edit the configuration file to replace this line:
#send host-name “testing”;
with this line:
send host-name “any hostname you want”;
To configure your local host to use the DHCP client, run the TCPware configuration utility CNFNET. To use the V3 DHCP client, you can run CNFNET in one of two ways:
$ @TCPWARE:CNFNET
$ @TCPWARE:CNFNET DHCLIENT
To use the V4 DHCP client, you must configure it individually:
$ @TCPWARE:CNFNET DHCLIENT4
CNFNET can also be used to disable the DHCP client on the host. If you have been running the V3 DHCP client and want to change to the V4 DHCP client, run CNFNET to disable DHCLIENT then run CNFNET again to enable DHCLIENT4.
After you configure the local host to use a DHCP client, you can run STARTNET to start TCPware:
$ @TCPWARE:STARTNET
Here are two examples:
Using CNFNET
$ @TCPWARE:CNFNET
TCPware (R) for OpenVMS Version 6.1-0 Network Configuration procedure for:
TCP/IP Services:
FTP-OpenVMS
NFS-OpenVMS Client
NFS-OpenVMS Server
SMTP-OpenVMS
TELNET-OpenVMS
Kerberos Services
SSH-OpenVMS Server
This procedure helps you define the parameters needed to get
TCPware (R) for OpenVMS running on this system.
This procedure creates the
configuration data file,
TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM, to reflect your
system’s configuration.
Type Return to continue... Return
... ...
... ...
You need to supply the following information for each line:
- The internet
address for the line
- The name for the line (same as the host name if single
line host, fully qualified domain name if using DNS)
- The subnet mask for the line
- The line specific information (depends on the line)
If there is a DHCP server running on the network and this is a single line
host, you may get the information from DHCP server automatically. To do so,
please select 2.
1. Configure Internet address and related items manually.
2. Configure Internet address and related items automatically
Continue with selection [1]: 2
Configure line SVA-0:
Set DHCP client Host Name
You can press Enter to let the system choose a host name. Or you can specify a
name you would like to use for the host. However, the final name for the host
will be up to the DHCP server to decide, it may not be the name you specify.
Host Name (Return to end) []: Return
You need to specify local time zone information. Time zone maybe specified as fixed value which must be manually set for the daylight savings time change, or you can use NTP (Network Time Protocol) Daemon to change the system clock and time offset automatically.
Do you want to have NTP set the time and time offset automatically [NO]?
... ...
... ...
Using CNFNET DHCLIENT
$ @TCPWARE:CNFNET DHCLIENT
TCPware(R) for OpenVMS Version 6.0-0 Network Configuration procedure for:
TCP/IP
Services:
FTP-OpenVMS
NFS-OpenVMS Client
NFS-OpenVMS Server
SMTP-OpenVMS
TELNET-OpenVMS
Kerberos Services
SSH-OpenVMS Server
This procedure helps you
define the parameters needed to get
TCPware(R) for OpenVMS running on this system.
This procedure creates the configuration data file, TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM, to reflect your system's configuration.
Type Return to continue... Return
Configuring the Dynamic Host Configuration Protocol (DHCP) Client:
Do you want to use the DHCP Client [YES]: Return
Set the DHCP client host name.
You can press Enter to let the system choose a host name. Or you can specify a name you would like to use for the host. However, the final name for the host will be up to the DHCP server to decide. It may not be the name you specify.
Host Name (press Return to end [ ]: RETURN
The DHCP Client can perform error and debug message logging to OPCOM and a
log file.
Do you want to enable logging [NO]: Return
Do you want to restart DHCLIENT [NO]: Return
$
The DHCP client is started as a VMS detached process when TCPware is started up.
When the client starts, it configures the network interface (the line) with an IP address of "0.0.0.0", and then sends a DHCP discover packet to contact any DHCP server on the net. After getting an IP address and other net configuration information back from a DHCP server, it restarts the network interface with the IP address and configures TCPware on the host with the information it received. That information may include the default gateway, DNS domain name, host name, DNS servers’ IP addresses, and other things. After the network interface is configured and started, the DHCP client goes to sleep and waits for specified events (lease expired, renewal time reached) to wake it up again for possible re-configuration.
When the DHCP client is enabled, the logical TCPWARE_DHCP_CLIENT is equal to 1.
If the DHCP client cannot get the information it needs from the DHCP server, it may re-try until it succeeds. The re-try frequency can be controlled by the configuration file.
The DHCP client process sets the following items only when configuring the network interface, if it received the appropriate information from the DHCP server:
· IP address of the network interface
· Host name of the network interface
· Domain Name
· DNS client (Resolver)
· Routes/Gateway
It may change or set the following TCPware logicals:
· TCPWARE_DOMAINNAME
· TCPWARE_NAMESERVERS
It may change the following related OpenVMS logicals:
· UCX$BIND_DOMAIN
· UCX$BIND_SERVER00x
· UCX$INET_HOST
· UCX$BIND_SERVER000
· UCX$INET_DOMAIN
· UCX$INET_HOSTADDR
The TCPware DHCP client uses the configuration file TCPWARE:DHCLIENT.CONF to control the behavior of the client. You can use one of the supplied template files to start with, as described above.
To explore more configuration possibilities, read the following dhclient.conf descriptions. The descriptions were edited based on the ISC's descriptions for the Unix version of the DHCP client configuration file. The original documents can be found in the ISC's website at http://www.isc.org.
The dhclient.conf file is a free-form ASCII text file. The file may contain extra tabs and new lines for formatting purposes. Keywords in the file are case-insensitive. Comments begin with the # character and end at the end of the line and may be placed anywhere within the file (except within quotation marks). You can use the dhclient.conf file to configure the behavior of the client in the following ways:
· Protocol timing
· Information requested from the server
· Information required of the server
· Defaults to use if the server does not provide certain information
· Values with which to override information provided by the server
· Values to prepend or append to information provided by the server
The configuration file can also be preloaded with addresses to use on networks that do not have DHCP servers.
The timing behavior of the client need not be configured by the user. If no timing configuration is provided by the user, a reasonable timing behavior will be used by default - one which results in timely updates without placing an inordinate load on the server. The following statements can be used to adjust the timing behavior of the DHCP client, if required, however.
|
Statement |
Description |
|
backoff-cutoff time; |
The client uses an exponential back off algorithm with some randomness, so that if many clients try to configure themselves at the same time, they will not make their requests in lockstep. The backoff-cutoff statement determines the maximum amount of time that the client is allowed to back off. The actual value is set randomly between one-half to one and a half times the time specified. The default is two minutes (for V3) or fifteen seconds (for V4). |
|
initial-delay time; (V4 only) |
The initial-delay statement sets the maximum time the client can wait after starting before commencing its first transmission. Previous versions of the ISC DHCP client waited up to 5 seconds. Version 4 has no initial delay by default, to avoid an adverse impact on system startup time. To restore the old behavior, set initial-delay to 5. |
|
initial-interval time; |
The initial-interval statement sets the amount of time between the first attempt to reach a server and the second attempt to reach a server. Each time a message is sent, the interval between messages is incremented by twice the current interval multiplied by a random number between zero and one. If it is greater than the backoff-cutoff amount, it is set to that amount. The default is ten seconds. |
|
reboot time; |
When the client is restarted, it first tries to reacquire the last address it had. This is called the INIT-REBOOT state. This is the quickest way to get started if it is still attached to the same network it was attached to when it last ran. The reboot statement sets the time that must elapse after the client first tries to reacquire its old address before it gives up and tries to discover a new address. The reboot timeout default is ten seconds. |
|
retry time; |
The retry statement determines the time that must pass after the client has determined that there is no DHCP server present before it tries again to contact a DHCP server. By default, this is 60 seconds (for V3) or 5 minutes (for V4). |
|
select-timeout time; |
It is possible to have more than one DHCP server serving any given network. It is also possible that a client may receive more than one offer in response to its initial lease discovery message. It may be that one of these offers is preferable to the other (e.g., one offer may have the address the client previously used, and the other may not). The select-timeout is the time after the client sends its first lease discovery request at which it stops waiting for offers from servers, if it has received at least one such offer. If no offers have been received by the time the select-timeout has expired, the client will accept the first offer that arrives. By default, the select-timeout is zero seconds - that is, the client will take the first offer it sees. |
|
timeout time; |
The timeout statement determines the amount of time that must pass between the time that the client begins to try to determine its address and the time it decides that it is not going to be able to contact a server. The default is sixty (60) seconds. After the timeout has passed, if there are any static leases defined in the configuration file, or any leases remaining in the lease database that have not yet expired, the client loops through these leases attempting to validate them. If it finds one that appears to be valid, it uses that lease's address. If there are no valid static leases or unexpired leases in the lease database, the client restarts the protocol after the defined retry interval. |
The DHCP protocol allows the client to request the server to send it specific information, and not send it other information that it is not prepared to accept. The protocol also allows the client to reject offers from servers if they do not contain information the client needs, or if the information provided is not satisfactory. There is a variety of data contained in offers that DHCP servers send to DHCP clients. The DHCP client can request any of the DHCP options. See the DHCP Server chapter in this guide for a list of DHCP options.
|
Statement |
Description |
|
request [option] [, ... option];
(V4 only) |
The request statement causes the client to request that any server responding to the client send the client its values for the specified options. Only the option names should be specified in the request statement, not option parameters. For example,
request subnet-mask, routers;
(V4 only) By default the V4 client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, and host-name options. Note that if you specify a request statement, you override these defaults and these options will not be requested.
In some cases, it may be desirable to send no parameter request list at all. To do this, simply write the request statement but specify no parameters:
request;
In most cases, it is desirable to simply add one option to the request list which is of interest to the client in question. In this case, it is best to 'also request' the additional options:
also request static-routes; |
|
require [option] [, ... option];
(V4 only) |
The require statement lists options that must be sent for an offer to be accepted. Offers that do not contain all the listed options are ignored. There is no default require list. |
|
send { [option declaration]
|
The send statement causes the client to send the specified options to the server with the specified values. These are full option declarations. Options that are always sent in the DHCP protocol should not be specified here. The one exception is that the client can specify a requested-lease-time option other than the default requested lease time, which is two hours. The other obvious use for this statement is to send information to the server that allows it to differentiate between this client and other clients or kinds of clients. For example,
send host-name “my-name”; |
The V4 DHCP client contains a prototype implementation with very limited support for doing DNS updates when a lease is acquired. Its use is not recommended. No further information is provided here. By default, the DHCP client will not do DNS updates.
In some cases, a client may receive option data from the server that is not appropriate for that client, or may not receive information that it needs, and for which a useful default value exists. It may also receive information that is useful, but needs to be supplemented with local information. To handle these needs, these option modifiers are available.
|
Statement |
Description |
|
append [option declaration]; |
Use the append statement if the client should use the values supplied by the server followed by a value you supply. The append statement can only be used for options that allow more than one value to be given. This restriction is not enforced. If you ignore it, the behavior is unpredictable. |
|
default [option declaration]; |
Use the default statement to specify a default value if no value was supplied by the server. |
|
prepend [option declaration]; |
Use the prepend statement if the client should use a value you supply followed by the values supplied by the server. The prepend statement can only be used for options that allow more than one value to be given. This restriction is not enforced. If you ignore it, the behavior is unpredictable. |
|
supersede [option declaration]; |
Use the supersede statement if the client should always use a locally configured value or values rather than whatever is supplied by the server. |
A lease statement consists of the lease keyword, followed by a left curly brace ( { ), followed by one or more lease declaration statements, followed by a right curly brace ( } ).
lease { lease-declaration [ ... lease-declaration ] }
The DHCP client may decide after some period of time (see Protocol Timing)
that it is not going to succeed in contacting a server. At that time, it
consults its own database of old leases and tests each one that has not yet
timed out by pinging the listed router for that lease to see if that lease
could work. It is possible to define one or more fixed leases in the client
configuration file for networks where there is no DHCP or BOOTP service, so
that the client can still configure automatically its address. This is done
with the lease statement.
|
Note: The lease statement is also used in the dhclient.db (v3) or dhclient.leases (v4) file in order to record leases that have been received from DHCP servers. Some of the syntax for leases as described below is only needed in the dhclient.db/dhclient.leases file. Such syntax is documented here for completeness.
|
The following lease declarations are possible:
|
Declaration |
Description |
|
bootp; |
The bootp statement indicates that the lease was acquired using the BOOTP protocol rather than the DHCP protocol. It is never necessary to specify this in the client configuration file. The client uses this syntax in its lease database file. |
|
filename "string"; |
The filename statement specifies the name of the boot filename to use. This is not used by the standard client configuration script, but is included for completeness. |
|
fixed-address ip-address; |
The fixed-address statement sets the IP address of a particular lease. This is required for all lease statements. The IP address must be specified as a dotted quad (e.g., 12.34.56.78). |
|
interface "string"; |
The interface statement indicates the interface on which the lease is valid. If set, this lease will be tried only on a particular interface. When the client receives a lease from a server, it always records the interface number on which it received that lease. If predefined leases are specified in the dhclient.conf file, the interface should also be specified, although this is not required. |
|
option option-declaration; |
The option statement specifies the value of an option supplied by the server, or, in the case of predefined leases declared in dhclient.conf, the value that the user wants the client configuration script to use if the predefined lease is used. |
|
renew date; rebind date; expire date; |
The renew statement defines the time at which the DHCP client should begin trying to contact its server to renew a lease that it is using.
The rebind statement defines the time at which the DHCP client should begin to try to contact any DHCP server to renew its lease.
The expire statement defines the time at which the DHCP client must stop using a lease if it has not been able to contact a server to renew it.
These declarations are set automatically in leases acquired by the DHCP client, but must be configured in predefined leases: a predefined lease whose expiration time has passed will not be used by the DHCP client.
Dates are specified as follows:
weekday year/month/day hour:minute:second
W YYYY/MM/DD HH:MM:SS
W is the day of the week, from zero (Sunday) to
six (Saturday). For predefined leases, this can always be set to 0.
The time is always in Greenwich Mean Time, not local time.
(V4 only) The V4 DHCP client can specify dates in two formats. The software will output times in one of these two formats depending on the setting of the db-time-format configuration parameter: default or local. The default format is the one described above. The local format is as follows:
epoch seconds-since-epoch;
The seconds-since-epoch is set according to the system's local clock (often referred to as "UNIX time").
Note that when defining a static lease, you may use either time format, and need not include the comment or values after it.
If the time is infinite in duration, then the date is never instead of an actual date. |
|
server-name "string"; |
The server-name statement specifies the name of the boot server name to use. This is not used by the standard client configuration script. |
|
script "script-name"; |
The script statement specifies the file name of the DHCP
client configuration script. This script is used by the DHCP client to set
the interface's initial configuration prior to requesting an address, to test
the address once it has been offered, and to set the interface's final
configuration once a lease has been acquired. If no lease is acquired, the
script is used to test predefined leases, if any, and also called once if no
valid lease can be identified. The default value for script-name
is |
|
vendor option space "name"; |
(V4 only) The vendor option space statement is used to specify which option space should be used for decoding the vendor-encapsulate-options option, if one is received. The dhcp-vendor-identifier can be used to request a specific class of vendor options from the server. |
(V4 only) The alias declaration resembles a lease declaration, except that options other than the subnet-mask option are ignored by the client configuration script, and expiry times are ignored. A typical alias declaration includes an interface declaration, a fixed-address declaration for the IP alias address, and a subnet-mask option declaration.
alias { lease-declaration [ ... lease-declaration ] }
Some DHCP clients may require that in addition to the lease they may acquire via DHCP, their interface also be configured with a predefined IP alias so that they can have a permanent IP address even while roaming. The DHCP V4 client doesn't support roaming with fixed addresses directly, but in order to facilitate such experimentation, the DHCP client can be set up to configure an IP alias using the alias declaration.
The below table lists all of the other DHCP client declarations that are supported by TCPware. There are other declarations in the ISC DHCP V4 client which are not supported by TCPware and are not mentioned here.
|
Declaration |
Description |
|
db-time-format [default | local]; |
(V4 only) The db-time-format option determines which of two output methods are used for printing times in leases files. The default format provides day-and-time in UTC, whereas local uses a seconds-since-epoch to store the time value, and helpfully places a local time zone time in a comment on the same line. The formats are described in detail above. |
|
reject ip-address;
reject cidr-ip-address
|
The reject statement causes the DHCP client to reject offers from servers whose server identifier matches the specified hosts or subnets. This can be used to avoid being configured by rogue or mis-configured DHCP servers, although it should be a last resort; better to track down the bad DHCP server and fix it.
(V4 only) The cidr-ip-address configuration type is of the form ip-address[/prefixlen], where ip-address is a dotted quad IP address, and prefixlen is the CIDR prefix length of the subnet, counting the number of significant bits in the netmask starting from the leftmost end. Example configuration syntax:
reject 192.168.0.0/16, 10.0.0.5;
The above example would cause offers from any server identifier in the entire RFC 1918 "Class C" network 192.168.0.0/16, or the specific single address 10.0.0.5, to be rejected. |
This is the template configuration for the V4 DHCP client:
# you can specify a host name here
#send host-name "testing";
#
# you can specify the length of the lease for the client
#send dhcp-lease-time 7200;
#
# you can request certain options from the server
# note: these are the options that are looked at by the tcpware client
request subnet-mask, broadcast-address, routers, static-routes,
domain-name, domain-name-servers, host-name;
#
# you can require certain options
require subnet-mask;
#
# you can modify options received from the server using
prepend/append/supersede
#prepend domain-name-servers 127.0.0.1;
#
# you can supply defaults for options not sent by the server
#default domain-name-servers 127.0.0.1;
#
# you can reject offers from certain servers
#reject 10.10.10.10;
#
# client configuration script
#script "tcpware:dhclient-script.com";
How do I know the DHCP client has configured my network successfully?
Check if the TCPWARE_DHCP_CLIENT logical is equal to 1, you can do:
$ SHOW LOGICAL TCPWARE_DHCP_CLIENT
"TCPWARE_DHCP_CLIENT" = "1" (LNM$SYSTEM_TABLE)
$
Then run the NETCU SHOW NET command to check if the line is assigned with an IP address.
$ NETCU SHOW NET
Line Local Address
Subnet Mask MTU Xmits Errs Recvs Errs RBU
---- ------------- ----------- --- ----- ---- ----- ---- ---
SVA-0 10.10.10.10 255.255.255.0 1500 49 0 3999 0 0
LPB-0 127.0.0.1 255.0.0.0 64512 64 0 64 0 0
4191 IP datagrams were transmitted, of which
0 were
fragmented
0 were forwards
0 were IGMP reports
115244 IP datagrams/fragments were received, of which
0 were fragments
0 were forwarded
1397 were IGMP queries/reports
61785 IP datagrams were delivered to receivers.
$
What if I cannot ping an IP address on the internet?
If you can ping the same IP address from another host and the network interface has been configured by the DHCP client, check the gateway and route configuration on the host.
What if I can ping a host by its IP address but not by its name?
· The DNS client on the host may not be configured right. Type:
$ show logical TCPWARE_NAMESERVERS
and
$ show logical TCPWARE_DOMAINNAME
to make sure the DNS client information is correct.
• The DNS server may be down.
• The DNS client may be down. Check if the TCPware_DNS process exists.
Why is the local address 0.0.0.0 when I use netcu show net?
The DHCP client has failed to allocate an IP address. The possible reasons and solutions are:
|
Reason |
Solution |
|
There is no DHCP server on the net. |
Set up a DHCP server. |
|
The DHCP server is not configured correctly. |
Modify the DHCP server configuration. |
|
The DHCP client is configured to reject the DHCP server. |
Reconfigure the DHCP client to not reject the DHCP server. |
|
The hostname selection process failed. |
Use another host name. |
|
There are no IP addresses available in the DHCP server. |
Increase the IP address on the DHCP pool server. |
Where can I find the status information of the DHCP client?
• The file TCPWARE:DHCLIENT-SCRIPT-ENV.TMP contains the most recent environment variables used by the DHCP client script file to configure the network.
• The file TCPWARE:DHCLIENT.DB (V3) or TCPWARE:DHCLIENT.LEASES (V4) contains the DHCP client lease history.
• The file TCPWARE:DHCLIENT.LOG contains information about the DHCP client process.
|
Note: The TCPWARE:DHCLIENT.LOG file is not created by the default setting of the DHCP client. To create this log file, configure the DHCP client to enable the error and debug logging using the command:
$ @tcpware:cnfnet dhclient
or
$ @tcpware:cnfnet dhclient4
|