| The problem with manually configuring IP addresses, subnet masks, and routing information is that lots of similar information is being applied in some cases to lots of individual machines. If these machines are purely clients of network services, then why should they worry about what their IP addresses are? The answer is they probably don't care about their IP addresses. This is where RARP and DHCP come in. 15.9.1 Reverse Address Resolution Protocol: RARP The first utility we look at to provide an IP address dynamically is RARP. This protocol has two components : a client (the rarpc command) and a server (the rarpd daemon). Let's discuss the limitation of RARP before we look at an example. 15.9.1.1 RARP LIMITATIONS RARP was designed with one major client in mind: diskless workstations. When a diskless workstation boots up, it will broadcast on its network the only piece of network related information it knows : its MAC address. We hope that a RARP server will be listening for such a broadcast and will respond by furnishing (via tftp ) the diskless client with an IP address and subsequently a mini NFS-enabled kernel to boot from. The rest of the boot-up procedure is (almost) the same as any other workstation. The thing to note here is that the only IP configuration parameter supplied by RARP is the IP address of the client. All other IP parameters need to be supplied in the relevant startup configuration files. Another limitation of RARP is that it is only supported over Ethernet, 100VG, and FDDI interfaces. To supply IP addresses to RARP clients, we need a RARP server. This is a machine on the same network (broadcasts do not normally cross a router) that has been configured as a RARP server. There are two components to being a RARP server: -
Run the rarpd daemon. NOTE : There is a bug in my (and probably your) netconf file. The RARPD configuration parameter should read RARPD=1. If not, the startup script /sbin/init.d/rarpd will not start the daemon. The configuration file below has the wrong parameter name in the comment. I have amended the actual parameter to be correct. Ensure that you have the most recent patches for RARP to avoid this. root@hpeos003[] vi /etc/rc.config.d/netconf ... # # Reverse ARP daemon configuration. See rarpd(1m) # # RARP: Set to 1 to start rarpd daemon # RARPD=1 root@hpeos003[] /sbin/init.d/rarpd start rarpd root@hpeos003[] ps -ef grep rarp root 3413 1 0 17:46:02 ? 0:00 /usr/sbin/rarpd root@hpeos003[] -
Have appropriate entries in the /etc/rarpd.conf file. This file comes with some examples in it. You will need the MAC address of all your RARP clients and an associated IP address. I have updated this file with the MAC address for node hpeos001 ; I have used a different IP address for demonstration purposes. root@hpeos003[] vi /etc/rarpd.conf ... 08:00:09:BA:84:1B 192.168.0.75 We are now ready to configure a machine to be a RARP client. Here are the configuration changes I made to node hpeos001 in order for it to set RARP to obtain its IP address:
root@hpeos001[] # vi /etc/rc.config.d/netconf ... INTERFACE_NAME[0]="lan0" IP_ADDRESS[0]= RARP SUBNET_MASK[0]="255.255.255.224" BROADCAST_ADDRESS[0]="" INTERFACE_STATE[0]="" DHCP_ENABLE[0]=0
This will result in the rarpc lan0 command being run at boot time. Here's an example of running the startup script manually:
root@hpeos001[] # netstat -in Name Mtu Network Address Ipkts Opkts lan0 1500 192.168.0.64 192.168.0.67 3480 3043 lo0 4136 127.0.0.0 127.0.0.1 1306 1306 root@hpeos001[] # root@hpeos001[] # /sbin/init.d/net start root@hpeos001[] # netstat -in Name Mtu Network Address Ipkts Opkts lan0 1500 192.168.0.64 192.168.0.75 3577 3108 lo0 4136 127.0.0.0 127.0.0.1 1306 1306 root@hpeos001[] #
With its limitations in regard of the number of different configuration parameters that you can initialize, RARP will probably remain in the realms of diskless workstations. To supply an IP configuration to a machine dynamically, the most popular tool is DHCP. 15.9.2 Dynamic Host Configuration Protocol: DHCP DHCP allows us to supply a plethora of configuration options to a client machine. These range from an IP address and subnet mask to default gateway, DNS servers, and even NTP timeservers. Every set of configuration parameters given out by the DHCP server has a lease expiry time . Before this time, the DHCP client can request an extension to the lease, which is normally granted by the DHCP server. In this way, a client may actually maintain the same IP configuration over a period of time. This is purely a consequence of the way leases work. Do not expect an individual client to maintain any IP-related parameters. Remember, DHCP clients are purely clients of network services. DHCP clients can be any network devices ranging from network printers, X-Terminals, diskless workstations, or Windows-based PCs to machines running HP-UX. The client portion of the configuration is relatively simple; for each interface listed in /etc/rc.config.d/netconf , we have a DHCP_ENABLE parameter that when set to 1 will send a bootp broadcast request containing its MAC address on the local network. A DHCP server will respond and download the entire IP configuration to the client. I will configure node hpeos001 as a DHCP client:
root@hpeos001[] # vi /etc/rc.config.d/netconf ... HOSTNAME="" OPERATING_SYSTEM=HP-UX LOOPBACK_ADDRESS=127.0.0.1 ... INTERFACE_NAME[0]="lan0" IP_ADDRESS[0]="" SUBNET_MASK[0]="" BROADCAST_ADDRESS[0]="" INTERFACE_STATE[0]="" DHCP_ENABLE[0]= 1 ... ROUTE_DESTINATION[0]="" ROUTE_MASK[0]="" ROUTE_GATEWAY[0]="" ROUTE_COUNT[0]="" ROUTE_ARGS[0]=""
As we can see, we are going to obtain our entire IP configuration from our DHCP server. In fact, when the configuration is downloaded, it will be stored in a file /etc/dhcpclient.data . After every reboot, we will request from the DHCP server an extension on the lease. Let's look at setting up the DHCP server. 15.9.2.1 DHCP SERVER CONFIGURATION A DHCP server needs to be accessible to all clients in your network. Let's reconsider our small network from Figure 15-2. Using node hpeos002 as a DHCP server has limitations. If node hpeos001 makes a DHCP request, the request may not pass through our routers. Some routers are DHCP-aware, but others are not. Where a router is not DHCP-aware, we will need to utilize a node on a local network to relay the DHCP request to its eventual destination. We look at this later. It is enough to say that using a well-connected (multi- homed ) server as a DHCP server is desirable. DHCP is a superset of the older bootp protocol. As such, it uses the bootpd daemon to listen for DHCP as well as bootp requests over its networks. We need to ensure that the bootps service is active in our /etc/inetd.conf file. If not, uncomment it and remember to run inetd “c to send an HUP signal to inetd to ensure that it rereads its configuration file. Here's the default entry from /etc/inetd.conf on node hpeos004 :
root@hpeos004[] grep bootpd /etc/inetd.conf bootps dgram udp wait root /usr/lbin/bootpd bootpd root@hpeos004[]
The default configuration files used by a DHCP server are /etc/ bootptab and /etc/dhcptab . There are three types of clients to which a DHCP server can respond: You can either use SAM to configure these files or use an editor to modify the configuration files directly. There are lots of options to the IP configuration, so be sure that you know which options to use for a particular node. 15.9.2.2 DHCP: AN INDIVIDUAL NODE CONFIGURATION Individual nodes have their IP configuration specified in /etc/bootptab . After checking /etc/dhcpdeny , which would refuse access based on MAC address, this is the next configuration file the bootpd daemon examines to check that we don't have a specific entry for a specific node. Here I have created an entry in /etc/bootptab for a machine with MAC address 0x080009ba841b (node hpeos001 actually):
root@hpeos004[] cat /etc/bootptab ... client1:\ ht=ethernet:\ ha=080009ba841b:\ hn:\ gw=192.168.0.35:\ sr=192.168.0.32 192.168.0.33 :\ dn=maabof.com:\ ds=192.168.0.34:\ nt=192.168.0.34
I have chosen the following options: client1: This is an identifier for an individual entry. It can be used as the hostname for an individual client. ht= Hardware type of Ethernet. Note that FDDI is not supported. ha= Hardware address of the client. hn: A Boolean expression that means that the hostname passed back to the client is the identifier tag at the beginning of this entry. gw= This is the IP address of the default gateway. sr= These are individual static routes. dn= The domain name to be used for DNS resolution. ds= The IP address of DNS server(s). nt= The IP address of NTP time server(s). As you can see, even with these few options, there is much to consider. The order of options within individual entries is not important. The convention to have each configuration option on an individual line makes for easy reading and it is easier to identify syntax errors. I won't list all the available options here. The best place to find them is either in the /etc/bootptab itself where a list is provided in the comments at the beginning of the file or in man bootpd where a good explanation and useful examples of all the options are listed. I can continue with individual entries if I wish. This can be tedious , so we will look at setting up a pool group. 15.9.2.3 DHCP: A POOL GROUP A pool group is a group of IP addresses that can be assigned to any client on a given subnet. Because we are using a server that has multiple network connections, we can define multiple pool groups for different subnets. Again, we can edit the configuration file /etc/dhcptab directly or use SAM. Initially, most administrators will use SAM because the number of options is quite bewildering. I will not list all of them here. The manual page for bootpd is a good place to start. It is important that you create a pool group for all the subnets you are servicing . When a DHCPDISCOVER request comes in from a client, it will be on a particular subnet; we need to have a pool group with a definition for such a subnet. Here is a basic entry for clients on our 192.168.0.64 network:
root@hpeos004[] more /etc/dhcptab dhcp_pool_group:\ pool-name=64Subnet:\ addr-pool-start-address=192.168.0.82:\ addr-pool-last-address=192.168.0.94:\ lease-time=604800:\ lease-policy=accept-new-clients:\ allow-bootp-clients=FALSE:\ hn:\ subnet-mask=255.255.255.224
As you can see, the format is the same as in the /etc/bootptab file with individual elements being separated by a colon (:). The individual tags in the configuration file are quite self-explanatory. I have included some parameters with their default values just for this demonstration: dhcp_pool_group: This signifies the beginning of a pool group definition. pool-name= This is a name to identify this pool group. addr-pool-start-address= As the name suggests, this is the first IP address that is available for DHCP clients. Ensure that any machines on your network do not currently use this address. addr-pool-last-address= The last address available for DHCP clients. All addresses between and including the start-address and the last-address are available for DHCP clients unless we define a reserved-for-other parameter. lease-time= This is the number of seconds (1 week by default) that an IP configuration can be outstanding to a client. We could use the word " infinite ", which means that a lease never expires . Be careful when using this. If we have more clients than we have leases, a new client may be refused a lease because we have no leases available. We can also configure a lease-grace-period that defines how long we will wait after a lease expires before allowing that IP address to be assigned to a new client. There are other parameters that deal with when a client should request the renewal of a lease ( tr= ) and request a new lease from any server ( tv= ). Again, these parameters have default values that in most cases are adequate. lease-policy : Although the documentation states that the default for this parameter is accept-new-clients , I have found that many installations will not issue a lease without this tag added to the configuration file. allow-bootp-clients= This dictates whether the bootpd daemon will use IP addresses from our pool to bootp clients. The default is FALSE, which means that if a bootp client does not have an entry in /etc/bootptab , it will not obtain any IP configuration from this server. If we change this parameter to TRUE, then we will issue an infinite lease to this bootp client. hn : We will also send the client's hostname along with the other IP configuration parameters. Using this tag means we that will need to set up a corresponding IP address - hostname entry in our host's database. subnet-mask= This is the subnet mask to be applied to all the IP addresses in this group. This is a required field for a pool group. This is just the beginning of setting up a DHCP pool group. We will also have to trawl through all the other parameters we wish to assign along with an IP address and subnet mask. The list of parameters is the same as we saw for an individual node entry in /etc/bootptab . In fact, we could cut and paste those values that applied to an individual node into our pool group(s) if those parameters were appropriate for all the clients on that network. That is what I have done in this case. Here is the complete entry I have in /etc/dhcptab for this pool group:
root@hpeos004[] cat /etc/dhcptab dhcp_pool_group:\ pool-name=64Subnet:\ addr-pool-start-address=192.168.0.82:\ addr-pool-last-address=192.168.0.94:\ lease-time=604800:\ lease-policy=accept-new-clients:\ allow-bootp-clients=FALSE:\ hn:\ subnet-mask=255.255.255.224:\ gw=192.168.0.66:\ sr=192.168.0.32 192.168.0.65 :\ dn=maabof.com:\ ds=192.168.0.34:\ nt=192.168.0.34 root@hpeos004[]
We are not finished yet. First, we should validate the configuration with the dhcptools command:
root@hpeos004[] dhcptools -v The validate operation was successful. Results were written to the file /tmp/dhcpvalidate. root@hpeos004[] cat /tmp/dhcpvalidate # /tmp/dhcpvalidate:dhcp validation output. # # generated on Wed Sep 17 11:46:56 2003 /etc/dhcptab validated, no errors found. /etc/bootptab validated, no errors found. root@hpeos004[]
We can also use the dhcptools command to create appropriate entries in our host's database. In our case, we want an IP address range starting from 192.168.0.82 to 94, a list of 13 entries. We could add these manually to /etc/ hosts , or here is how dhcptools would do it:
root@hpeos004[] dhcptools -h fip=192.168.0.82 no=13 sm=255.255.255.224 hn=dhcp## root@hpeos004[] cat /tmp/dhcphosts # /tmp/dhcphosts:dhcptools hostgen output. # # generated on Wed Sep 17 11:53:20 2003 192.168.0.82 dhcp00 192.168.0.83 dhcp01 192.168.0.84 dhcp02 192.168.0.85 dhcp03 192.168.0.86 dhcp04 192.168.0.87 dhcp05 192.168.0.88 dhcp06 192.168.0.89 dhcp07 192.168.0.90 dhcp08 192.168.0.91 dhcp09 192.168.0.92 dhcp10 192.168.0.93 dhcp11 192.168.0.94 dhcp12 root@hpeos004[]
The wildcard # in the hostname template ( hn= ) is a single number from 0 to 9. We could also use a question mark ( ? ), which is a letter from a to z. We could use an asterisk ( * ), which is a letter from a to z or a number from 0 to 9. Personally, I would prefer it if dhcptools would allow me to use the last octet of the IP address as part of the hostname, but it doesn't. I suppose that if we have hundreds of entries in a pool group, then this is one quick way of creating entries to add to /etc/hosts , and who really cares what the hostname of a DHCP client is anyway? Let me say a quick word of caution: In my example, I have included a DNS server and domain name as part of the configuration. If you are going to use dhcptools to construct your host file entries, it might be worthwhile using the simple example I used above, without the FQDN. I then doctored this file with a little bit of awk to include the FQDN as well as an alias of just the hostname . It's up to you, but without the FQDN the following dhcptools preview command will not work.
root@hpeos004[] awk ' ~ /^dhcp/ {print "\t"".maabof.com\t"}' /tmp/dhcphosts 192.168.0.82 dhcp00.maabof.com dhcp00 192.168.0.83 dhcp01.maabof.com dhcp01 192.168.0.84 dhcp02.maabof.com dhcp02 192.168.0.85 dhcp03.maabof.com dhcp03 192.168.0.86 dhcp04.maabof.com dhcp04 192.168.0.87 dhcp05.maabof.com dhcp05 192.168.0.88 dhcp06.maabof.com dhcp06 192.168.0.89 dhcp07.maabof.com dhcp07 192.168.0.90 dhcp08.maabof.com dhcp08 192.168.0.91 dhcp09.maabof.com dhcp09 192.168.0.92 dhcp10.maabof.com dhcp10 192.168.0.93 dhcp11.maabof.com dhcp11 dhcp12.maabof.com dhcp12 root@hpeos004[] awk ' ~ /^dhcp/ {print "\t"".maabof.com\t"}' /tmp/dhcphosts >>  /etc/hosts
In the module on DNS, we discuss how to dynamically update DNS with the hostname/IP address of DHCP clients. Just to make sure our DHCP server is working as we expect, we can preview a lease being assigned to a client with the dhcptools command:
root@hpeos004[] dhcptools -p ht=ether ha=080009ba841b sn=192.168.0.64 _______________________________________________________________ Results of the Preview Command _______________________________________________________________ Command: dhcptools -p ht=ether ha=080009ba841b sn=192.168.0.64 Time: Wed Sep 17 16:02:27 2003 Response Data: hardware type = ethernet harware address length = 6 hardware address = 080009BA841B IP address = 192.168.0.84 lease time = 604800 seconds subnet mask = 255.255.255.224 bootfile = hostname = dhcp02.maabof.com number of DNS servers = 1 DNS servers = 192.168.0.34 number of NIS servers = 0 NIS servers = number of NISP servers = 0 NISP servers = number of SMTP servers = 0 SMTP servers = number of routers = 1 routers = 192.168.0.66 time offset = 0 number of X font servers = 0 X font servers = number of X display servers = 0 X display servers = _______________________________________________________________ Exit value is 0 root@hpeos004[]
We are now ready to accept DHCP requests from clients. Before we do that, let's have a few words on an infrequently used DHCP concept: a device group. 15.9.2.4 DHCP: A DEVICE GROUP A device group is very similar to a pool group except that all members of the device group are the same type of device. You would need to perform a trace on all DHCP requests coming into the system in order to identify what is known as the class-id . We can do this by performing a trace on DHCP packets coming into a server by using the dhcptools command:
root@hpeos004[] dhcptools -t ct=100 Packet tracing was started. The current packet trace count for the BOOTP/DHCP server is 100. root@hpeos004[]
We would then need to initiate a DHCP client to request a new lease. I have achieved this by using a Windows-based PC utilizing DHCP and using this command:
C:\ ipconfig /renew
Once the DHCP client has received its new lease, we can stop the trace:
root@hpeos004[] dhcptools -t ct=0 Packet tracing was stopped. The current packet trace count for the BOOTP/DHCP server is 0. root@hpeos004[]
The trace file is called /tmp/dhcptrace . From this, we can establish the DHCP class-id ; I have underlined it in this example:
root@hpeos004[] more /tmp/dhcptrace __________________________________________________________ BOOTP SERVER PACKET TRACE (packet 1) Time Stamp: Wed Sep 17 16:08:47 2003 __________________________________________________________ -------------- Start Packet -------------------------- BOOTP REQUEST packet htype: ethernet hlen: 06 hops: 0000 xid: 9112cb5b secs: 00000000 flags: 00 00 ciaddr: 192.168.0.61 yiaddr: 0.0.0.0 siaddr: 0.0.0.0 giaddr: 0.0.0.0 chaddr: (hex) 00:08:74:e5:86:be: vendor magic cookie: 99.130.83.99 boot file: "empty string" server name: "empty string" ----------------- BOOTP/DHCP Options ------------------ DHCP MESSAGE TYPE: DHCPREQUEST TAG = DHCP Client ID : len = 7 : 0x01,0x00,0x08,0x74,0xe5,0x86,0xbe, TAG = Host Name : len = 5 : "CKPC2^CM-SM-X" Tag #081 [0, 0, 0, 67, 75, 80, 67, 50, 46] TAG = DHCP Class ID : len = 8 : 0x4d,0x53,0x46,0x54,0x20,0x35,0x2e,0x30, TAG = DHCP Param. Req. list : len = 11 : 0x01,0x0f,0x03,0x06,0x2c,0x2e,0x2f,0x1 f,0x21,0xf9,0x2b, TAG = TAG_END ----------------- Raw Options Data -------------------- 63 82 53 63 35 1 3 3d 7 1 0 8 74 e5 86 be
We can then convert the hexadecimal into text: 0x4d = M 0x53 = S 0x46 = F 0x54 = T 0x20 = <space> 0x35 = 5 0x2e =. 0x30 = 0 Only if we know the class-id can we set up a device group . Here are the lines we would set up in /etc/dhcptab to identify a device group for our PC client:
dhcp_device_group:\ class-name=PCs:\ class-id:"MSFT 5.0":\
The rest of the configuration parameters are the same as in a pool group. Be sure to perform a trace on inbound DHCP packets to ensure that the class-id you specify in /etc/dhcptab is the same as in the DHCPDISCOVER packets coming from clients. If they are not the same, bootpd will not be able to identify individual clients as being members of this device group and could potentially assign them an IP address from a another device group or even a pool group, which may not be what you wanted. 15.9.2.5 BOOTING A DHCP CLIENT Everything appears to be in place in preparation for our server to start servicing DHCP requests. In our demonstration, I will add debugging to bootpd so we can capture verbose messages in syslog . It is recommended that you do this only when debugging potential problems:
root@hpeos004[] grep bootpd /etc/inetd.conf bootps dgram udp wait root /usr/lbin/bootpd bootpd d 3 root@hpeos004[] inetd -c root@hpeos004[]
I am now going to boot the node currently known as hpeos001 to ensure that our DHCP server is working as we expect. Here's the extract from syslog.log once the client boots up:
Sep 17 15:58:00 hpeos004 bootpd[3370]: Received DHCPDISCOVER creating DHCPOFFER. Request data: ha = 080009BA841B, req IP not sent, ciaddr 0.0.0.0, giaddr 0.0.0.0, broadcast reply off, server id not sent. Sep 17 15:58:00 hpeos004 bootpd[3370]: Found previously released/offered addr 192.168.0.84 to assign to request; matched 080009BA841B. Sep 17 15:58:00 hpeos004 bootpd[3370]: gethostbyaddr found name "dhcp02.maabof.com" Sep 17 15:54:20 hpeos004 bootpd[3370]: not ICMP packet Sep 17 15:58:00 hpeos004 above message repeats 15 times Sep 17 15:58:00 hpeos004 bootpd[3370]: saved offer. Sep 17 15:58:00 hpeos004 bootpd[3370]: copying options from 64Subnet Sep 17 15:58:00 hpeos004 bootpd[3370]: copying options from default client group Sep 17 15:58:00 hpeos004 bootpd[3370]: sending reply to 192.168.0.84 on port 68 Sep 17 15:58:02 hpeos004 bootpd[3370]: Received DHCPREQUEST creating DHCPACK. Request data : ha = 080009BA841B, req IP 192.168.0.84, ciaddr 0.0.0.0, giaddr 0.0.0.0, broadcast reply off, server id 192.168.0.66. Sep 17 15:58:02 hpeos004 bootpd[3370]: allocated ip: udpated dhcpdb and hash tables. Sep 17 15:58:02 hpeos004 bootpd[3370]: copying options from 64Subnet Sep 17 15:58:02 hpeos004 bootpd[3370]: copying options from default client group Sep 17 15:58:02 hpeos004 bootpd[3370]: sending reply to 192.168.0.84 on port 68
As you can see we generate an offer that is accepted by the client. Let's have a look at the client now that it has completed its bootup :
root@dhcp02[] # more /etc/rc.config.d/netconf ... HOSTNAME="dhcp02" OPERATING_SYSTEM=HP-UX LOOPBACK_ADDRESS=127.0.0.1 ... LANCONFIG_ARGS[0]=ether ROUTE_DESTINATION[0]=default ROUTE_GATEWAY[0]=192.168.0.66 ROUTE_COUNT[0]=1 ROUTE_DESTINATION[1]=192.168.0.32 ROUTE_GATEWAY[1]=192.168.0.65 ROUTE_COUNT[1]=1 root@dhcp02[] # more /etc/resolv.conf domain maabof.com nameserver 192.168.0.34 root@dhcp02[] # root@dhcp02[] # tail /etc/ntp.conf # Authentication stuff # #keys /usr/local/bin/ntp.keys # path for keys file #trustedkey 3 4 5 6 14 # define trusted keys #requestkey 15 # key (7) for accessing server variables #controlkey 15 # key (6) for accessing server variables #authdelay 0.000159 # authentication delay (SPARC4c/65 SS1+ MD5) server 192.168.0.34 driftfile /etc/ntp.drift root@dhcp02[] # root@dhcp02[] # ll /etc/dhcpclient.data -rw-r--r-- 1 root root 702 Sep 10 14:56 /etc/dhcpclient.data root@dhcp02[] # root@dhcp02[] # ps -ef grep dhcpclient root 169 1 0 14:56:08 ? 0:00 dhcpclient -m lan0 -u -l2 root@dhcp02[] #
This all looks in place and as expected. The process to keep an eye on is the dhcpclient process. This is started by /sbin/auto_parms . With the “m option, dhcpclient is maintaining our current lease. If our lease expires and we obtain a new IP configuration, we will be prompted to reboot our system. Read through /sbin/auto_parms to become more familiar with dhcpclient because there is no manual page for it. You can monitor which leases are currently active by monitoring the file /etc/dhcpdb on your DHCP server:
root@hpeos004[] cat /etc/dhcpdb C 192.168.0.64: 192.168.0.84 00 1 080009BA841B 3F71C0F1 00 dhcp02.maabof.com root@hpeos004[]
If a machine no longer requires its lease, e.g., we decide to manually configure its IP parameter, we can reclaim the lease on the DHCP server:
root@hpeos004[] dhcptools -r ip=192.168.0.84 ht=ether ha=080009BA841B _______________________________________________________________ Results of the Reclaim Command _______________________________________________________________ Command: dhcptools -r ip=192.168.0.84 ht=ether ha=080009BA841B Time: Wed Sep 17 17:39:07 2003 Response Data: The IP address was reclaimed for use by DHCP. _______________________________________________________________ Exit value is 0 root@hpeos004[]
I will let you explore other possibilities of DHCP on your own; if I were you, I would certainly test the functionality of any DHCP device groups you create. I fully tested the configuration above and all appears to be working as expected. We will move on now and look at a different aspect of basic network administration: performing a network trace. This doesn't need to be performed often, usually as a request from an HP Support engineer to provide further details in an attempt to resolve an outstanding problem. | 