Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Solaris DHCP Implementation

News

See also

Books Recommended Links RFCs FAQs
Configuring Solaris DHCP server Solaris DHCP Client DHCP security  Network problems troubleshooting Humor Quiz

Summary

Solaris has separate daemons for DHCP client ( dhcpagent ) and DHCP server (in.dhcpd ). Solaris DHCP daemon is started automatically during bootup if file /etc/dhcp.interface exists for at lest one interface Only interfaces with a corresponding /etc/dhcp.interface file are automatically configured during boot.

DHCP is a client-server protocol. There are two separate ports associated with DHCP:

DHCP client listen for messages from server on port 68. The DHCP server listens for messages on port 67.

When a DHCP client computer is booted, DHCP messages are exchanged between client computer and server as follows:

  1. The DHCP client computer broadcasts a DHCPDISCOVER message. In a routed environment, the broadcast is limited to the physical subnet. If there is no DHCP server on the physical subnet, one or more of the routers should be configured to forward the (BOOTP) message to a known DHCP server location.The DHCPDISCOVER message can include options that request specific values for the network address and lease duration.
  2. Each DHCP server that is configured to respond to the client computer's subnet should respond with a DHCPOFFER message. The DHCPOFFER message has a (presumably) available IP address as well as other configuration information. According to the IETF standard, the DHCP server should first grope the target subnet with an ICMP ECHO request to confirm that the address is available.
  3. The DHCP client computer receives one or more DHCPOFFER messages from the DHCP server(s). The client computer selects one of the DHCPOFFER messages.
  4. The DHCP client computer broadcasts a DHCPREQUEST message that includes a server identifier option to indicate which server it has selected. This DHCPREQEST message can include requests for specific configuration information.
  5. All DHCP servers that responded to the client computer's original DHCPREQUEST broadcast should receive the second DHCPREQUEST message broadcast. The DHCP server(s) that were not selected by the client computer take no further action.
  6. The selected DHCP server commits the IP address for the client computer to its list of client computers, IP addresses, and leases. It then sends a DHCPACK message that includes the (requested) configuration parameters for the DHCP client computer.
  7. If the selected DHCP server cannot comply with the DHCPREQUEST message from the client computer (usually because the requested IP address is not available), the server sends a DHCPNAK message to the client computer.
  8. The DHCP client computer receives the DHCPACK message from the server. The client computer normally performs a final validation of the configuration information and saves the address lease duration specified in the DHCPACK message. The client computer is configured.

Like DNS there can be primary and secondary DHCP servers but secondary DHCP servers are not a requirement and they are not that common. Primary and secondary DHCP servers must have access to the exact same data. Copies cannot be used. This can be achieved by via NIS and NFS. Both run in.dhcpd daemon:

There are two alterative ways (command line based and GUI-based) to configure DHCP servers (and BOOTP relay servers) on Solaris:

Use the dhtadm utility to manage the DHCP service configuration table, dhcptab. You can specify one of the following option flags:

The pntadm utility performs three main functions: :

Introduction

The Dynamic Host Configuration Protocol (DHCP) permits centralization of IP-addresses assignment in a centralized location. The concept of dynamically assigning Internet Protocol (IP) addresses is fairly new and became common only in late 90th. DHCP is the dominant application-layer TCP/IP protocol that does the job. All major OSes now provide a DHCP client. Most provide DHCP server too. There is also free reference implementation from Internet consortium. For all major commercial Unixes the DHCP protocol engine has been updated to RFC 2131, but is still compatible with RFC 1541. (The server can also process options as defined in RFC 2132.) The protocol engine uses the database to determine what information should be returned to the client. Solaris has separate daemons for DHCP client ( dhcpagent ) and DHCP server (in.dhcpd ). The DHCP server in Solaris is threaded. To maintain high throughput, database operations (including save operations) are thread efficient.

DHCP doesn't just provide IP addresses to clients, it is used to manage a large percentage of an installation's configuration information. The service interacts with other critical network infrastructure such as the Domain Name System. In DHCP environment, hosts may be added to the network or moved between networks without the need for manual configuration.

DHCP is based on BOOTP protocol and it extends BOOTP transport standards for passing a variety of configuration information (known as options) to clients:

Routers can be configured to act as a BOOTP relay agent. Support is available for clients that need to boot over a network, effectively replacing the need for RARP and the bootparams file.

DHCP is a client-sever protocol. There are two separate ports associated with DHCP:

DHCP client listen for messages from server on port 68. The DHCP server listens for messages on port 67.

There are nine types of messages used by DHCP:

No Packet Type Description
1 DHCPDISCOVER Client computer broadcast message. Used to discover available DHCP servers.
2 DHCPOFFER BOOTREPLY message that is a response from DHCP server to a client broadcast message offering configuration information.
3 DHCPREQUEST BOOTREQUEST message that requests configuration information in response to a DHCPOFFER message, confirming an IP address that was previously assigned or extending the lease on an assigned IP address.
4 DHCPACK Sent by the DHCP server to the client computer. This message contains the IP address assigned to the client computer and any other configuration parameters that the DHCP server is allocated to the client computer request.
5 DHCPNAK Server to the client computer indicating that the client computer's notion of the network address is incorrect (for example, the client computer has moved to a new subnet) or the client computer's lease has expired.
6 DHCPDECLINE The DHCP standard requires that DHCP client computers "defend" their respective IP address. This message is used by the client computer to inform the server that the network address is already in use.
7 DHCPRELEASE The DHCP client computer sends this message to the DHCP server to relinquish its IP address and cancel the balance of the lease on that IP address.
8 DHCPINFORM Request message from the DHCP client computer that asks only for local (scope or subnet) configuration parameters because the DHCP client computer already has externally

The configuration parameters managed by DHCP are valid for a period of time called a lease. The duration of the lease is set when the client accepts a configuration offer from a DHCP server. Although the protocol provides a method for a client to request a specific length for the lease, there is actually no negotiation of lease terms. The client either accepts or rejects the parameters offered by a server.

The DHCP client can be on six different stages:

  1. INIT The client has not had a lease and is locating a DHCP server.
  2. INIT-REBOOT The client has had a lease and is restarting its IP interface.
  3. SELECTING The client has received lease offers from one or more DHCP servers.
  4. BOUND The client has been successfully configured and has a valid lease.
  5. RENEWING The client is attempting to renew the lease with the same DHCP server.
  6. REBINDING The client could not renew the lease with the original server and is attempting find another DHCP server

At each of those stages the client can send/receive certain types of messages. See DHCP messages. The process of obtaining the initial information (initial lease) consists of several stages.

On the first stage the client broadcast the request using the address 255.255.255.255 to discover a server. If a router is present and configured to behave as a BOOTP relay agent, the request can be passed to other DHCP servers on different subnets. Otherwise only local subnet is involved. The client's broadcast includes its unique ID, which in the Solaris DHCP implementation, is derived from the client's MAC address.

After any server returns an offer of address, the subsequent process, as described in Designing a Windows 2000 Network Infrastructure Developing DHCP Strategies , is somewhat similar to "DHCP handshake" of client with the server:

When a DHCP client computer is booted, DHCP messages are exchanged between client computer and server as follows:

  1. The DHCP client computer broadcasts a DHCPDISCOVER message. In a routed environment, the broadcast is limited to the physical subnet. If there is no DHCP server on the physical subnet, one or more of the routers should be configured to forward the (BOOTP) message to a known DHCP server location.The DHCPDISCOVER message can include options that request specific values for the network address and lease duration.
  2. Each DHCP server that is configured to respond to the client computer's subnet should respond with a DHCPOFFER message. The DHCPOFFER message has a (presumably) available IP address as well as other configuration information. According to the IETF standard, the DHCP server should first grope the target subnet with an ICMP ECHO request to confirm that the address is available.
  3. The DHCP client computer receives one or more DHCPOFFER messages from the DHCP server(s). The client computer selects one of the DHCPOFFER messages.
  4. The DHCP client computer broadcasts a DHCPREQUEST message that includes a server identifier option to indicate which server it has selected. This DHCPREQEST message can include requests for specific configuration information.
  5. All DHCP servers that responded to the client computer's original DHCPREQUEST broadcast should receive the second DHCPREQUEST message broadcast. The DHCP server(s) that were not selected by the client computer take no further action.
  6. The selected DHCP server commits the IP address for the client computer to its list of client computers, IP addresses, and leases. It then sends a DHCPACK message that includes the (requested) configuration parameters for the DHCP client computer.
  7. If the selected DHCP server cannot comply with the DHCPREQUEST message from the client computer (usually because the requested IP address is not available), the server sends a DHCPNAK message to the client computer.
  8. The DHCP client computer receives the DHCPACK message from the server. The client computer normally performs a final validation of the configuration information and saves the address lease duration specified in the DHCPACK message. The client computer is configured.
  9. If the DHCP client computer determines that the address is already in use, it sends a DHCPDECLINE message to the server and then begins the DHCP configuration process again with a DHCPREQUEST broadcast.
  10. If the DHCP client computer does not receive a DHCPACK or a DHCPNAK message within a specified period of time, it resends the DHCPREQUEST message.
  11. The client computer can relinquish its IP address lease by sending a DHCPRELEASE message to the DHCP server.

After that the behavior of the client is bound by the lease it obtained:

The DHCP server assigns addresses based on keys. While usage of MAC address is standard de facto, the server can use several different keys to map an address and a set of configuration options to the client.

These keys can be used by the configuration either singularly or in combinations. If multiple keys are provided by the client and multiple addresses can be assigned, only one is chosen, and the option set is derived from the chosen key first. Again, the most common key is MAC address (that is transmitted as client ID).

The other piece of the picture is a BOOTP relay agent. A relay agent is needed so initial broadcasts from the client can leave the local network. The relay agents act as forwarding agents for DHCP and BOOTP packets.

The database is used to track clients and addresses and for access control (for example, allowing certain clients on some networks but not others or disabling BOOTP clients on a particular network). Options are also stored in the database for retrieval and delivery to clients.

The configuration of the address pools have some configuration options that affect the state machine. For example, the DHCP server pings addresses before it hands them out. The amount of time the server waits for a response is now configurable for each address pool.

To use this protocol, the network administrator needs to set up a DHCP server and configure BOOTP relay agents on links that do not have a DHCP server. Advance planning can reduce DHCP load on the network. For example, one server can be configured to handle all your clients, but all packets must be passed through it. If you have a single router between two large networks, it may be wiser to place two servers in your network, one on each link.

Another aspect to consider is that DHCP implies a pattern of traffic. For example, if you set your default lease time to fewer than two days and your machines are powered off for the weekend, Monday morning will be a period of high DHCP traffic. Although DHCP traffic does not cause huge overhead for the network, it needs to be considered when deciding where to place DHCP servers on a network and how many to use.

Historically DHCP evolved from the bootstrap protocol (BOOTP).

DHCP is based on BOOTP and maintains some backward compatibility. The main difference is that BOOTP was designed for manual pre-configuration of the host information in a server database, while DHCP allows for dynamic allocation of network addresses and configurations to newly attached hosts. Additionally, DHCP allows for recovery and reallocation of network addresses through a leasing mechanism.

RARP is a protocol used by Sun and other vendors that allows a computer to find out its own IP number, which is one of the protocol parameters typically passed to the client system by DHCP or BOOTP. RARP doesn't support other parameters and using it, a server can only serve a single LAN. DHCP and BOOTP are designed so they can be routed.

DHCP provides the following additional functionality:

DHCP reduces the cost of managing networks by eliminating the need to manually assign or change IP addresses. DHCP also reclaims IP addresses that are no longer needed or if the lease has expired. DHCP also makes it easier to renumber the network if the IP range changed.

Solaris has separate daemons for DHCP client ( dhcpagent ) and DHCP server (in.dhcpd ). The DHCP server in Solaris is threaded. To maintain high throughput, database operations (including save operations) are thread efficient.

Solaris DHCP daemon is started automatically during bootup if file /etc/dhcp.interface exists for at lest one interface Only interfaces with a corresponding /etc/dhcp.interface file are automatically configured during boot.

See Configuring Solaris DHCP server for additional details


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Mar 26, 2012] What ports are used by DHCP and the DHCP clients

Requests are on UDP reversed port 68
&
Server replies on UDP reversed port 67

If the above is right, then you can allow those ports on Linux(Ubuntu) with:
sudo iptables -A OUTPUT -p udp --dport 68 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 67 -j ACCEPT

[Dec 21, 2006] Problems Detecting Rogue DHCP Servers on Linux UPDATE

Dec 21, 2006

I have finally found a tool that works for RHEL and Debian (and probably all Linuxes). It's a Perl module and accompanying script which can optionally be run as a demon and be setup to email you each time it finds a rogue server. It's called RogueDetect and is GPL. I have tested version 0.4Alpha2. I've also used this code as a basis for a Nagios plugin the code for which I'll be releasing over the next few days on this blog.

Good post bart, nice to see that windows has some decent commands relating to standard internet protocols. In the longer term, you could have a permanent method of spotting rogue dhcp servers. I found a rule for snort:

#
# DHCP Servers
#
alert udp !$DHCP_SERVERS 67 -> 255.255.255.255 any (msg: "possible rogue DHCP Server"; sid:1000001;)

I know you use nagios, I dunno if theres a plugin for that yet.

[Dec 20, 2006] Problems Detecting Rogue DHCP Servers on Linux

I am by no means shy about pointing out problems with Windows on this blog but I do try to be objective in my criticism. Today I have the rare pleasure of sharing a Windows command-line tool that I haven't been able to find an equal to on RedHat Enterprise Linux (RHEL) 4. A few weeks ago a rogue DHCP server caused us some serious problems at work so I was asked to find a simple tool for detecting rogue servers. In theory there are loads of tools for this on Linux but after having tried everything Google was able to find for me (an entire day's work) I'd still drawn a blank. Everything I tried insisted that our main DHCP server did not exist. What's more tcpdump showed responses from the DHCP server arriving at the machine but all the tools insisted they got no reply regardless. In my search I did come across dhcploc.exe, a small MicroSoft command-line tool that ships with most versions of Windows. Granted, it's not part of the default install but it is on the CD none the less and more importantly it works!

Technorati Tags: Windows, RedHat, RHEL, DHCP, Rogue DHCP Servers

To install dhcploc.exe you have to install the Support Tools which you have to look for on your Windows CD. Once you have this installed you can set it looking for rogue servers with the following command:

dhcploc 

dhcploc.exe will then run continually and display all DHCP responses it sees. It will beep each time a rogue server is seen. You can also get it to only show you rogue traffic with the -p flag.

It's rare that Windows has more powerful command-line tools than Linux but when it comes to detecting rogue DHCP servers Windows had it nailed with this simple tool that just works! I just hope this tool still exists in Vista!

Update 21 December 2006

I have finally found a tool that works for RHEL and Debian (and probably all Linuxes). It's a Perl module and accompanying script which can optionally be run as a demon and be setup to email you each time it finds a rogue server. It's called RogueDetect and is GPL. I have tested version 0.4Alpha2. I've also used this code as a basis for a Nagios plugin the code for which I'll be releasing over the next few days on this blog.

[Dec 11, 2006] Planning, Implementing, and Troubleshooting DHCP Understanding DHCP

Dec 11, 2006 (samspublishing.com) Although DHCP is typically one of the easiest of the common network services to configure and maintain, from time to time, you might encounter problems. More often than not, the DHCP-related problems that arise stem from a misconfiguration in a scope, unauthorized DHCP servers on the network, or network connectivity problems. You might also find information that has changed in some way, but the change has not been reflected in your DHCP configuration, as in the case of DHCP reservations (which are tied to MAC addresses) or a DHCP server's IP address change. The following sections examine some troubleshooting tasks you can do to quickly determine the cause of DHCP woes and get this vital network service back into proper operation.

Troubleshooting DHCP Server Authorization Problems

As discussed previously, one of the first indicators you might see of an unauthorized or rogue DHCP server is an unexpected increase in the number of DHCPNACK messages. You can monitor this statistic over time by using the Performance console. The Performance console includes several counter objects that you can use to monitor and troubleshoot your DHCP server:

Configuring the Performance console to monitor and collect data about a DHCP server is a simple process, as outlined in Step by Step 3.7.

Step By Step 3.7: Monitoring DHCP Performance

  1. Select Start, Program, Administrative Tools, Performance to open the Performance console.
  2. Click System Monitor, as shown in Figure 3.34.

    Figure 3.34

    Figure 3.34 You can view server performance statistics by using the Performance console.

  3. To create an entry in System Monitor, click the + icon. The Add Counters dialog box shown in Figure 3.35 opens, enabling you to begin adding counters.

    Figure 3.35

    Figure 3.35 You can add counters to begin monitoring DHCP server statistics.

  4. Select the DHCP Server performance object in the Performance object drop-down list box. You then see the list of counters available for selection that relate to the DHCP service. If you need to know what a counter means, select the counter and click the Explain button.
  5. When you have decided what counter you want to monitor, click Add. You can add multiple counters either by selecting each counter and clicking Add or by holding down the Ctrl key while you select all the counters you want to monitor and then clicking Add. Click Close when you are finished. Your counters are graphed like those shown in Figure 3.36.
Figure 3.36

Figure 3.36 You can monitor DHCP server statistics in real time.

NOTE

Creating server baselines If you create baselines on servers, you can compare the performance at any given time to a known value. This can be very useful in performing troubleshooting, and it also helps when configurations are being modified. To create a baseline, you create a counter log from the Counter Logs option of the Performance Logs and Alerts node, shown in Figure 3.35. The configuration and use of a counter log is nearly identical to the creation and use of System Monitor, as described in Step by Step 3.7.

If you notice a trend of higher-than-normal DHCPNACK messages, you need to determine the source. The most common cause is a rogue DHCP server that has been set up on the network. You can also examine the DHCP lease properties of clients to determine whether any of them have different information than what you have configured in your DHCP scopes.

It's important to remember that Windows 2000 and Windows XP clients in an Active Directory environment that are configured to use DHCP do not accept leases from unauthorized DHCP servers. Older clients accept these leases and can contribute to the number of DHCPNACK messages when they attempt to renew their DHCP leases.

You can also examine the DHCP server daily audit logs, located in the %systemroot%\ sysytem32\dhcp folder, to look for rogue-detection events. The DHCP audit logs are discussed in the next section.

Using the DHCP Logs

The DHCP server daily audit logs are often overlooked as a valuable source of information. You have learned how to enable the audit logs; now let's look at what they contain. Unlike the logs the Windows 2000 Server DHCP service produces, the Windows Server 2003 daily audit logs are natively in text format; you open them simply by double-clicking them. A sample of what you might expect to find in a log is displayed here:

ID,Date,Time,Description,IP Address,Host Name,MAC Address
00,04/27/06,20:08:38,Started,,,,
55,04/27/06,20:08:39,Authorized(servicing),,lab1.area51partners.com,,
24,04/27/06,20:44:10,Database Cleanup Begin,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
24,04/27/06,21:44:12,Database Cleanup Begin,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
11,04/27/06,19:39:46,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
31,04/27/06,19:39:46,DNS Update Failed,
    192.168.0.231,xpclient01.corp.quepublishing.com,-1,
10,04/27/06,19:43:07,Assign,192.168.0.230,
    iMac01.corp.quepublishing.com,00306509D772,
30,04/27/06,19:44:14,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
31,04/27/06,19:44:14,DNS Update Failed,192.168.0.231,
    xpclient01.corp.quepublishing.com,-1,
30,04/27/06,19:47:03,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
30,04/27/06,19:47:03,DNS Update Request,
    192.168.0.231,xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,

As you can see from this example, the DHCP server cleans up the database hourly. You can also see that two clients requested leases. One of them, an Apple iMac, requested and was assigned the IP address 192.168.0.230, with no further actions. Another client, a Windows XP Professional computer, requested and received the IP address 192.168.0.231, with several failed DNS updates (evidenced by ID 31). After the DNS dynamic update account was properly configured, the DHCP server was able to make the DNS dynamic updates and generate an ID of 32. Table 3.3 explains the ID codes used in the DHCP daily audit logs.

Table 3.3. The DHCP Daily Audit Log ID Codes

ID Description
00 The log was started.
01 The log was stopped.
02 The log was temporarily paused due to low disk space.
10 A new IP address was leased to a client.
11 A client renewed a lease.
12 A client released a lease.
13 An IP address was found to be in use on the network.
14 A lease request could not be satisfied because the scope's address pool was exhausted.
15 A lease was denied.
16 A lease was deleted.
17 A lease was expired.
20 A BOOTP address was leased to a client.
21 A dynamic BOOTP address was leased to a client.
22 A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted.
23 A BOOTP IP address was deleted after a check was made to see that it was not in use.
24 The IP address cleanup operation has begun.
25 IP address cleanup statistics are provided.
30 A DNS update request to the named DNS server was made.
31 The DNS update failed.
32 The DNS update was successful.
50+ These IDs are used for Rogue Server Detection information.

In addition to the DHCP daily audit logs, events related to the DHCP service are generated and placed in the system log, as shown in Figure 3.37.

Figure 3.37

Figure 3.37 The system log contains events related to the DHCP service.

As you can see in Figure 3.38, a DHCP server on the network has not been authorized in Active Directory. The system log contains many useful log events about all aspects of a server, and this is an area you should review often.

Figure 3.38

Figure 3.38 An unauthorized DHCP server cannot start the DHCP service.

Troubleshooting DHCP Reservations

For the most part, the only problem that prevents a DHCP reservation from functioning properly is a misconfigured MAC address. If you have a misconfigured DHCP reservation, it should show up in the Address Leases node of your DHCP server with the status Reservation (Inactive). Reservations that are configured properly show the status Reservation (Active). If you look back at Figure 3.16, you'll see that the reservation we created had a bad MAC address and, thus, was the cause of the problem in Figure 3.39.

Figure 3.39

Figure 3.39 A DHCP reservation that is not active usually indicates a misconfiguration.

To verify that a reservation is configured properly, you can compare the MAC address of the component that is to have a reserved DHCP address (a print server, for example) to the MAC address entered in the reservation Properties dialog box. The vast majority of the time, this will reveal the source of the problem.

Troubleshooting the DHCP Relay Agent

The DHCP relay agent, like a DHCP reservation, typically doesn't present a problem. However, in some cases, relay services are not being provided to network clients. Some of the most common problems that you might encounter with the DHCP relay agent include the following:

[Oct 27, 2006 ] DHCP Server Security (Part 2)Detecting Rogue DHCP Servers

Finally, there are a few tools you can use to detect the presence of rogue DHCP servers on your network so you can get rid of them. These include both tools from Microsoft and from third-party sources, and we'll end by examining two of these tools.

Dhcploc.exe

Dhcploc.exe is a command-line tool that is part of the Windows Support Tools found in the \Support\Tools folder on your Windows XP product CD and it can be used to display all DHCP servers that are active on the local subnet. Dhcploc.exe has been around since Windows NT 4.0 and it works by sending out DHCPREQUEST messages and displaying the IP addresses of the DHCP servers that responded with DHCPACK. You can find the syntax of this tool in the Help file that is installed when you install the Support Tools on your machine.

dhcp_probe

The Network Systems Group at Princeton University's Office of Information Technology has developed a tool called dhcp_probe that tries to discover DHCP and BOOTP servers on a directly-attached Ethernet network. The existing build runs on Solaris 8 on SPARC with gcc and there is patch for it to work on Linux also, so if you have either of those platforms you can try using this tool to detect any rogue DHCP servers that might be running on your network. You can find the Network Systems Group's tools page here and can download dhcp_probe directly from here.

DHCP for Windows 2000 Managing the Dynamic Host Configuration Protocol Chapter 4 Designing a DHCP Infrastructure

Internet Connection Sharing

Internet Connection Sharing (ICS) is a new feature found in Windows 2000 Professional and Windows 2000 Server that permits a single computer to host an Internet connection for a network.

For example, if you have a small network with 15 computers, only one of the computers (running Windows 2000 and ICS) requires a connection to the Internet. This computer, known as the ICS server, hosts the Internet connection via a dial-up line, cable modem, or xDSL. The remaining 14 computers are ICS clients that access the Internet via the ICS server.

ICS provides network address translation (NAT), IP address allocation via DHCP, and name resolution services via DNS for all ICS clients. Clients can use Internet applications (e.g., Internet Explorer and Outlook) just as though the computers themselves were connected to the Internet.

The ICS server can also be configured to terminate the Internet connection when not needed. If one of the ICS clients attempts access when the Internet connection is down, ICS automatically dials the ISP and establishes a connection. The client is then able to access the requested resource.

The ICS server needs two network connections: one for the internal network (i.e., the connection for ICS clients in the office) and one for the connection to the Internet.

By enabling ICS, the computer automatically becomes a DHCP server for the office network. DHCP automatically assigns IP addresses to the hosts on the office network along with TCP/IP configuration information such as DNS servers.

When ICS is enabled, the computer acting as the ICS server is configured with a static IP address 192.168.0.1 and subnet mask 255.255.255.0. ICS's internal DHCP server is configured with a scope of 192.168.0.2 through 192.168.0.254.

Note that these default settings cannot be modified, nor can any particular service such as DHCP or DNS Proxy be disabled. If you are already running a DHCP server on your network, the ICS internal DHCP server and your network DHCP server will both attempt to honor DHCP client requests, resulting in NACKs (negative acknowledgments). In this case you cannot utilize ICS on your network. Consider using Windows 2000's Network Address Translating

DHCP

This protocol is used to assign IP addresses to hosts or workstations on the network. Usually a DHCP server on the network performs this function. Basically it "leases" out address for specific times to the various hosts. If a host does not use a given address for some period of time, that IP address can then be assigned to another machine by the DHCP server. When assignments are made or changed, the DHCP server must update the information in the DNS server.

As with BOOTP, DHCP uses the machine's or NIC ethernet (MAC) or hardware address to determine IP address assignments. The DHCP protocol is built on BOOTP and replaces BOOTP. DHCP extends the vendor specific area in BOOTP to 312 bytes from 64. RFC 1541 defines DHCP.

DHCP RFCs are 1533, 1534, 1541, and 1542. Sent from DHCP server:

DHCP Lease Stages

  1. Lease Request - The client sends a broadcast requesting an IP address
  2. Lease Offer - The server sends the above information and marks the offered address as unavailable. The message sent is a DHCPOFFER broadcast message.
  3. Lease Acceptance - The first offer received by the client is accepted. The acceptance is sent from the client as a broadcast (DHCPREQUEST message) including the IP address of the DNS server that sent the accepted offer. Other DHCP servers retract their offers and mark the offered address as available and the accepted address as unavailable.
  4. Server lease acknowledgement - The server sends a DHCPACK or a DHCPNACK if an unavailable address was requested.

DHCP discover message - The initial broadcast sent by the client to obtain a DHCP lease. It contains the client MAC address and computer name. This is a broadcast using 255.255.255.255 as the destination address and 0.0.0.0 as the source address. The request is sent, then the client waits one second for an offer. The request is repeated at 9, 13, and 16 second intervals with additional 0 to 1000 milliseconds of randomness. The attempt is repeated every 5 minutes thereafter.

The client uses its own port 68 as the source port with port 67 as the destination port on the server to send the request to the server. The server uses its own port 67 as the source port with port 68 as the destination port on the client to reply to the client. Therefore the server is listening and sending on its own port 67 and the client is listening and sending on its own port 68. This can be confusing when you consider which way the message is going. To be clear on this, I quote RFC 1531 which states "DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68)"

DHCP Lease Renewal

After 50% of the lease time has passed, the client will attempt to renew the lease with the original DHCP server that it obtained the lease from using a DHCPREQUEST message. Any time the client boots and the lease is 50% or more passed, the client will attempt to renew the lease. At 87.5% of the lease completion, the client will attempt to contact any DHCP server for a new lease. If the lease expires, the client will send a request as in the initial boot when the client had no IP address. If this fails, the client TCP/IP stack will cease functioning.

One DHCP scope is required for each subnet.

DHCP Relay Agents

May be placed in two places:

Client Reservation

Client Reservation is used to be sure a computer gets the same IP address all the time. Therefore since DHCP IP address assignments use MAC addresses to control assignments, the following are required for client reservation:

Exclusion Range

Exclusion range is used to reserve a bank of IP addresses so computers with static IP addresses, such as servers may use the assigned addresses in this range. These addresses are not assigned by the DHCP server.

Sample DCHP Configuration File

In Linux, a sample configuration file is:

subnet 192.168.199.0 netmask 255.255.255.0 {
# --- default gateway
	option routers			192.168.199.1;
	option subnet-mask		255.255.255.0;

	option nis-domain		"mynet.net";
	option domain-name		"mynet.net";
	option domain-name-servers	192.168.199.1;

	option time-offset		-5;	# Eastern Standard Time
#	option ntp-servers		192.168.199.1;
#	option netbios-name-servers	192.168.199.1;
# --- Selects point-to-point node (default is hybrid). Don't change this unless
# -- you understand Netbios very well
#	option netbios-node-type 2;

	default-lease-time 1209600;  # 2 weeks
	max-lease-time 1814400;		# 3 weeks

	range 192.168.199.10 192.168.199.250;

	# we want the nameserver to appear at a fixed address
	host nameserver {
		next-server nameserver.mynet.net;
		hardware ethernet 00:10:4b:ca:db:b5;
		fixed-address 192.168.199.1;
	}
}

This demonstrates that the IP addresses are based on lease times to the various clients. If they are not used within the period of their lease time by the client, those IP addresses are freed up for use by other clients.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

FAQs

FAQ for Windows 2000

DHCP FAQ

Recommended Papers

DHCP for Windows 2000 Managing the Dynamic Host Configuration Protocol Chapter 4 Designing a DHCP Infrastructure

Designing a Windows 2000 Network Infrastructure Developing DHCP Strategies

Network Access Control for DHCP Environment Kazumasa Kobayashi <[email protected]>
Suguru Yamaguchi <[email protected]> Nara Institute of Science and Technology Japan

RFCs

Dynamic Host Configuration Protocol (RFC 1531) (96192 bytes) obsoleted by RFC 1541

RFC 2131 Dynamic Host Configuration Protocol

RFC 2132 DHCP Options and BOOTP Vendor Extensions

DHCP Options and BOOTP Vendor Extensions (RFC 1533) (50919 bytes) obsoletes RFC 1497/ obsoleted by RFC 2131,RFC 2132
Interoperation Between DHCP and BOOTP (RFC 1534) (6966 bytes)
Clarifications and Extensions for the Bootstrap Protocol (RFC 1532) (51545 bytes) obsoletes RFC 951/ obsoleted by RFC 1542
Dynamic Host Configuration Protocol (RFC 1541) (96950 bytes) obsoletes RFC 1531/ obsoleted by RFC 2131
Clarifications and Extensions for the Bootstrap Protocol (RFC 1542) (52948 bytes) obsoletes RFC 1532
Dynamic Host Configuration Protocol (RFC 2131) (113738 bytes) obsoletes RFC 1533,RFC 1541/ updated by RFC 3396,RFC 4361
DHCP Options and BOOTP Vendor Extensions (RFC 2132) (63670 bytes) obsoletes RFC 1533/ updated by RFC 3442,RFC 3942,RFC 4361
Netware/IP Domain Name and Information (RFC 2242) (10653 bytes)
DHCP Options for Novell Directory Services (RFC 2241) (8419 bytes)
DHCP Option for The Open Group's User Authentication Protocol (RFC 2485) (7205 bytes)
Procedure for Defining New DHCP Options (RFC 2489) (10484 bytes) obsoleted by RFC 2939
DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (RFC 2563) (17838 bytes)
DHCP Options for Service Location Protocol (RFC 2610) (10859 bytes)
Procedure for Defining New DHCP Options and Message Types (RFC 2939) (13631 bytes) obsoletes RFC 2489
The Name Service Search Option for DHCP (RFC 2937) (8368 bytes)
The User Class Option for DHCP (RFC 3004) (10423 bytes)
The Subnet Selection Option for DHCP (RFC 3011) (13967 bytes)
DHCP Relay Agent Information Option (RFC 3046) (30633 bytes)
DHC load balancing algorithm (RFC 3074) (19374 bytes)
Authentication for DHCP Messages (RFC 3118) (35536 bytes)
DHCP reconfigure extension (RFC 3203) (11857 bytes)
The DOCSIS Device Class DHCP Relay Agent Information Sub-option (RFC 3256) (8551 bytes)
Encoding Long Options in DHCPv4 (RFC 3396) (18779 bytes) updates RFC 2131
The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (RFC 3442) (19370 bytes) updates RFC 2132
Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (RFC 3495) (26817 bytes)
Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (RFC 3527) (16831 bytes)
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 3315) (231402 bytes) updated by RFC 4361
PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option (RFC 3594) (12521 bytes)
DNS Configuration Options for DHCPv6 (RFC 3646) (13312 bytes)
IPv6 Prefix Options for DHCPv6 (RFC 3633) (45308 bytes)
KDC Server Address Sub-option (RFC 3634) (13163 bytes)
Unused DHCP Option Codes (RFC 3679) (13804 bytes)
Stateless DHCP Service for IPv6 (RFC 3736) (18510 bytes)
NIS Configuration Options for DHCPv6 (RFC 3898) (13955 bytes)
Vendor-Identifying Vendor Options for DHCPv4 (RFC 3925) (17999 bytes)
Reclassifying DHCPv4 Options (RFC 3942) (13996 bytes) updates RFC 2132
RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option (RFC 4014) (15416 bytes)
DHCP Subscriber ID Suboption for the DHCP Relay Agent Option (RFC 3993) (13938 bytes)
Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (RFC 4039) (22297 bytes)
The Authentication Suboption for the DHCP Relay Agent Option (RFC 4030) (34332 bytes)
Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (RFC 4075) (9424 bytes)
Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 4076) (15745 bytes)
The IPv4 Dynamic Host Configuration Protocol (DHCP) Options for the Internet Storage Name Service (RFC 4174) (29485 bytes)
Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (RFC 4242) (14759 bytes)
Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (RFC 4280) (23001 bytes)
Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (RFC 4243) (14342 bytes)
Node-Specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (RFC 4361) (28009 bytes) updates RFC 2131,RFC 2132,RFC 3315
Dynamic Host Configuration Protocol (DHCP) Leasequery (RFC 4388) (63914 bytes)
Detecting Network Attachment in IPv4 (DNAv4) (RFC 4436) (35991 bytes)
Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (RFC 4477) (30440 bytes)
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (RFC 4580) (10937 bytes)
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (RFC 4649) (10940 bytes)

IETF-Drafts:

The DHCP Client FQDN Option (38241 bytes)
Resolution of FQDN Conflicts among DHCP Clients (30459 bytes)
DHCP Server Identifier Override Suboption (15450 bytes)
Subnet Allocation Option (53997 bytes)
Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol (DHCPv4)" (113062 bytes)
Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis (50598 bytes)
DHCP Options for the Intel Preboot eXecution Environment (PXE) (14072 bytes)
DHCP Option for Proxy Server Configuration (17156 bytes)
The DHCPv6 Client FQDN Option (33042 bytes)
Clarifications on DHCPv6 Authentication (30658 bytes)
DHCP options for PANA Authentication Agents (14496 bytes)
Domain Suffix Option for DHCPv6 (8666 bytes)
DHCPv6 Relay Agent Assignment Notification (RAAN) Option (14204 bytes)
A Timezone Option for DHCP (21191 bytes)
DHCPv4 Relay Agent Flags Suboption (13963 bytes)
PXELINUX Use of 'Site Local' Option Space (26621 bytes)
Rebind Capability in DHCPv6 Reconfigure Messages (7671 bytes)
DHCPv6 Leasequery (38309 bytes)

Books

Beyond Dhcp - Work Your Tcp/Ip Internetwork With Dynamic Ip by IBM Redbooks (Paperback - Jan 2000)

The DHCP Handbook (2nd Edition) Books Ralph Droms,Ted Lemon

DHCP for Windows 2000 Books Neall Alcott

DHCP: A Guide to Dynamic TCP/IP Network Configuration by Berry Kercheval (Hardcover - Jan 15, 1999)

Troubleshooting

Planning, Implementing, and Troubleshooting DHCP Understanding DHCP

Although DHCP is typically one of the easiest of the common network services to configure and maintain, from time to time, you might encounter problems. More often than not, the DHCP-related problems that arise stem from a misconfiguration in a scope, unauthorized DHCP servers on the network, or network connectivity problems. You might also find information that has changed in some way, but the change has not been reflected in your DHCP configuration, as in the case of DHCP reservations (which are tied to MAC addresses) or a DHCP server's IP address change. The following sections examine some troubleshooting tasks you can do to quickly determine the cause of DHCP woes and get this vital network service back into proper operation.

Troubleshooting DHCP Server Authorization Problems

As discussed previously, one of the first indicators you might see of an unauthorized or rogue DHCP server is an unexpected increase in the number of DHCPNACK messages. You can monitor this statistic over time by using the Performance console. The Performance console includes several counter objects that you can use to monitor and troubleshoot your DHCP server:

Configuring the Performance console to monitor and collect data about a DHCP server is a simple process, as outlined in Step by Step 3.7.

Step By Step 3.7: Monitoring DHCP Performance

  1. Select Start, Program, Administrative Tools, Performance to open the Performance console.
  2. Click System Monitor, as shown in Figure 3.34.

    Figure 3.34

    Figure 3.34 You can view server performance statistics by using the Performance console.

  3. To create an entry in System Monitor, click the + icon. The Add Counters dialog box shown in Figure 3.35 opens, enabling you to begin adding counters.

    Figure 3.35

    Figure 3.35 You can add counters to begin monitoring DHCP server statistics.

  4. Select the DHCP Server performance object in the Performance object drop-down list box. You then see the list of counters available for selection that relate to the DHCP service. If you need to know what a counter means, select the counter and click the Explain button.
  5. When you have decided what counter you want to monitor, click Add. You can add multiple counters either by selecting each counter and clicking Add or by holding down the Ctrl key while you select all the counters you want to monitor and then clicking Add. Click Close when you are finished. Your counters are graphed like those shown in Figure 3.36.
Figure 3.36

Figure 3.36 You can monitor DHCP server statistics in real time.

NOTE

Creating server baselines If you create baselines on servers, you can compare the performance at any given time to a known value. This can be very useful in performing troubleshooting, and it also helps when configurations are being modified. To create a baseline, you create a counter log from the Counter Logs option of the Performance Logs and Alerts node, shown in Figure 3.35. The configuration and use of a counter log is nearly identical to the creation and use of System Monitor, as described in Step by Step 3.7.

If you notice a trend of higher-than-normal DHCPNACK messages, you need to determine the source. The most common cause is a rogue DHCP server that has been set up on the network. You can also examine the DHCP lease properties of clients to determine whether any of them have different information than what you have configured in your DHCP scopes.

It's important to remember that Windows 2000 and Windows XP clients in an Active Directory environment that are configured to use DHCP do not accept leases from unauthorized DHCP servers. Older clients accept these leases and can contribute to the number of DHCPNACK messages when they attempt to renew their DHCP leases.

You can also examine the DHCP server daily audit logs, located in the %systemroot%\ sysytem32\dhcp folder, to look for rogue-detection events. The DHCP audit logs are discussed in the next section.

Using the DHCP Logs

The DHCP server daily audit logs are often overlooked as a valuable source of information. You have learned how to enable the audit logs; now let's look at what they contain. Unlike the logs the Windows 2000 Server DHCP service produces, the Windows Server 2003 daily audit logs are natively in text format; you open them simply by double-clicking them. A sample of what you might expect to find in a log is displayed here:

ID,Date,Time,Description,IP Address,Host Name,MAC Address
00,04/27/06,20:08:38,Started,,,,
55,04/27/06,20:08:39,Authorized(servicing),,lab1.area51partners.com,,
24,04/27/06,20:44:10,Database Cleanup Begin,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
24,04/27/06,21:44:12,Database Cleanup Begin,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
11,04/27/06,19:39:46,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
31,04/27/06,19:39:46,DNS Update Failed,
    192.168.0.231,xpclient01.corp.quepublishing.com,-1,
10,04/27/06,19:43:07,Assign,192.168.0.230,
    iMac01.corp.quepublishing.com,00306509D772,
30,04/27/06,19:44:14,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
31,04/27/06,19:44:14,DNS Update Failed,192.168.0.231,
    xpclient01.corp.quepublishing.com,-1,
30,04/27/06,19:47:03,DNS Update Request,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
30,04/27/06,19:47:03,DNS Update Request,
    192.168.0.231,xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
    xpclient01.corp.quepublishing.com,00E07DC13E70,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
    xpclient01.corp.quepublishing.com,,

As you can see from this example, the DHCP server cleans up the database hourly. You can also see that two clients requested leases. One of them, an Apple iMac, requested and was assigned the IP address 192.168.0.230, with no further actions. Another client, a Windows XP Professional computer, requested and received the IP address 192.168.0.231, with several failed DNS updates (evidenced by ID 31). After the DNS dynamic update account was properly configured, the DHCP server was able to make the DNS dynamic updates and generate an ID of 32. Table 3.3 explains the ID codes used in the DHCP daily audit logs.

Table 3.3. The DHCP Daily Audit Log ID Codes

ID Description
00 The log was started.
01 The log was stopped.
02 The log was temporarily paused due to low disk space.
10 A new IP address was leased to a client.
11 A client renewed a lease.
12 A client released a lease.
13 An IP address was found to be in use on the network.
14 A lease request could not be satisfied because the scope's address pool was exhausted.
15 A lease was denied.
16 A lease was deleted.
17 A lease was expired.
20 A BOOTP address was leased to a client.
21 A dynamic BOOTP address was leased to a client.
22 A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted.
23 A BOOTP IP address was deleted after a check was made to see that it was not in use.
24 The IP address cleanup operation has begun.
25 IP address cleanup statistics are provided.
30 A DNS update request to the named DNS server was made.
31 The DNS update failed.
32 The DNS update was successful.
50+ These IDs are used for Rogue Server Detection information.

In addition to the DHCP daily audit logs, events related to the DHCP service are generated and placed in the system log, as shown in Figure 3.37.

Figure 3.37

Figure 3.37 The system log contains events related to the DHCP service.

As you can see in Figure 3.38, a DHCP server on the network has not been authorized in Active Directory. The system log contains many useful log events about all aspects of a server, and this is an area you should review often.

Figure 3.38

Figure 3.38 An unauthorized DHCP server cannot start the DHCP service.

Troubleshooting DHCP Reservations

For the most part, the only problem that prevents a DHCP reservation from functioning properly is a misconfigured MAC address. If you have a misconfigured DHCP reservation, it should show up in the Address Leases node of your DHCP server with the status Reservation (Inactive). Reservations that are configured properly show the status Reservation (Active). If you look back at Figure 3.16, you'll see that the reservation we created had a bad MAC address and, thus, was the cause of the problem in Figure 3.39.

Figure 3.39

Figure 3.39 A DHCP reservation that is not active usually indicates a misconfiguration.

To verify that a reservation is configured properly, you can compare the MAC address of the component that is to have a reserved DHCP address (a print server, for example) to the MAC address entered in the reservation Properties dialog box. The vast majority of the time, this will reveal the source of the problem.

Troubleshooting the DHCP Relay Agent

The DHCP relay agent, like a DHCP reservation, typically doesn't present a problem. However, in some cases, relay services are not being provided to network clients. Some of the most common problems that you might encounter with the DHCP relay agent include the following:

Quiz

Q1. Which protocol allows automation of the IP assignment process ?

A: DHCP

Q2. DHCP stands for _____________________ ?

A: Dynamic Host Configuration Protocol

Q3. You have a team of several network administrators. They work independently. Often, they end up assigning same IP to multiple machine. Would using DHCP solve this problem ?

A: Yes

Q4. How many DHCP IP address pools are supported ?

A: 21

Q5. True/Flase: Same DHCP server can support multiple subnets .

A: True

Q6. which command releases and removed DHCP leases ?

A: dhcpagent

Q7. Which command displays value of parameters received through DHCP ?

A: dhcpinfo

Q8. What does a secondary dhcp server do when the primary server is unable to respond ?

A: confirms existing configuration supplied by primary

Q9. Which command will initialize the dhcptab ?

A: dhcpconfig

Q10. where does dhcptab reside ?

A: /var/dhcp/dhcptab

Q11. Where would you find DHCP information about supported network 128.251.144.0 ?

A: /var/dhcp/128_251_144_0

Q12. Which file contains information related to client (dhcp) configuration ?

A: dhcptab

Q13. Which 2 commands modifies the dhcptab file ?

A: pntadm and dhtadm

Q14. Which value of "Flags" in the DHCP network database denotes a permanent lease ?

A: 1

Q15. What are entries in the DHCP network database ?

A: Client ID , Flags, Client IP, Server IP, Lease, Macro, Comments

Q16. Which value in the "flags" field in the DHCP network database denotes that the evaluation of the DHCP lease is turned on ?

A: 0

Q17. True/False: Each record in the DHCP network database has an associated to DHCP zone IP address .

A: True

Q18. What does the "Lease" field hold in the dhcp network database ?

a. how long the client has the lease for (length)

b. how long remains of the lease

c. absolute time when the lease expires

A: C

Q19. Which comamnd will yield the current dhcp information on the DHCP server ?

A: dhtadm –P

Q20. which file tells the dhcp daemon where to find its configuration?

A: /etc/inet/dhcpsvc.conf

Q21. which command will show you the entry for the host fred from the "hosts" administrative database ?

A: getent hosts fred

Q22. How can you start the DHCP daemon ?

A: /etc/init.d/dhcp start

Q23. How do you shutdown the DHCP daemon ?

A: /etc/init.d/dhcp stop

Q24. Which option of the dhtadm command creates the DHCP service configuration table, dhcptab ?

A: -C

Q25. Which option of the dhtadm command adds a symbol or macro definition to dhcptab ?

A: -A

Q26. Which option of the dhtadm command modifies an entry in the dhcptab table ?

A: -M

Q27. Which option of the dhtadm command removes symbol or macro definition from dhcptab ?

A: -D

Q28. Which option of the dhtadm command deletes the dhcptab table entirely ?

A: -R

Q28: Put the DHCP client and DHCP server interaction steps into the appropriate sequence:

  1. DHCPREQUEST

  2. DHCPOFFER

  3. DHCPDISCOVER

  4. DHCPACK

A: c,b,a,d


Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last Modified: March 12, 2019