open source software ab technical analysis dhcp · familiar with a command line, a strong knowledge...

OPEN SOURCE SOFTWARE LAB TECHNICAL ANALYSIS: DHCP

DOCUMENT NUMBER: RELEASE/REVISION: RELEASE/REVISION DATE: AUTHORS 1 REL 1.0 6/30/2006 Daniel Simonton

1 REL1.1 7/13/06 Anandeep Pannu

Abstract: The Microsoft Open Source Software Lab is a key advocate within Microsoft for interoperability with Open Source technologies. In order to drive discussions and engineering plans around interoperability, we need to initially build a core knowledge base in the particular technology which we can share with product and field teams. This paper is the first in a four part series on Linux networking technologies: DHCP, IPSEC/VPN, RADIUS, and DNS. The capabilities of a leading Open Source DHCP software package, ISC DHCP Server, are the focus of this document. The analysis concentrates on the manageability aspects of the ISC DHCP server and provides an overview from the point of view of the Open Source Software Lab, where the DHCP Server was installed, configured and tested. The intent of the document is to pass on the hands on experience gained from the installation, configuration and testing experience.

of 16

Microsoft makes no representations about the suitability of the information contained in this document. The document is provided "as is" without warranty of any kind. Microsoft hereby disclaims all warranties and conditions with regard to this information, including all warranties and conditions of merchantability, whether express, implied or statutory, fitness for a particular purpose, title and non-infringement. In no event shall Microsoft be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of information available from this document. The information contained in this document represents the current view of Microsoft on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented herein. The document could include technical inaccuracies or typographical errors. Changes may be periodically added to the information herein. © 2006 Microsoft Corporation. All rights reserved.

Microsoft is a registered trademark or trademark of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

of 16

ISC DHCP Analysis

Index of topics

Introduction………………………………………….. 3 Shipped Materials………………………..................... 3 Installation Experience…………………..................... 3, 4 Upgrade and Clean Install………………...................... 6 Minimum Configuration Settings……………………. 7 Configuration Import/Export Tools……………………. 7 Configuration Backup/Restore………………………… 7 Form Factor Options / Appliance …………………… 7

• Management And User Experience Management Interface Options....…………………….. 7 Interface & GUI ……………………………………… 7 CLI Scriptability ……………………………………… 8 Remote Administration Capabilities …………………. 8 Management Interface / Target User ………………….. 8 IT Admin Roles and Access Rights…………………… 8 Centralized Management of Multiple Machines………. 8

• Protocol / Technology Support DHCP Message Authentication………………………. 8 IPv6……………………………………………………. 8

• Features And Scenarios Unique Features……………………………………….. 8 Feature Set ……………………..……………………… 8 Configuring Scopes……………………………………. 8-9 Central Scope Distribution…………………………….. 9 Configuring Exclusions………………………………… 9 Configuring Lease Durations…………………………... 9 Configuring Reservations………………………………. 9 Configuring Options……………………………………. 7, 9 Static Address Management……………………………. 9 Server Logs and Reporting………………………………... 9

IP Conflict Detection…………………………………… 9 Network Data Correlation……………………………… 9 DHCP Server Authentication………………………….. 10

of 16

DHCP Authentication………………………………….. 10 Rogue DHCP Server Detection…………………………. 10 DNS Integration………………………………………… 10 Dynamic DNS Updates………………………………… 10 DHCP Relay……………………………………………. 10 Policy Definition……………………………………….. 11 Scalability………………………………………………. 11 Backup and Redundancy……………………………….. 11 Failover…………………………………………………. 11, 12 Directory Service Integration…………………………… 12 Configuration Rollback…………………………………. 12 Troubleshooting, Diagnostics, and Monitoring…………. 12 SDK Extensibility, API Support………………………… 12 Patching & Updates……………………………………… 12 Historical and Trend Analysis………………………….. 13

• Performance Address Allocation……………………………………… 13 Hardware Requirements………………............................ 13 Performance Monitoring……………………………….. 13

• Help And Support

Documentation………………………………………….. 14 Support……………………………………….…………. 14, 15

of 16

I. Introduction This paper is an overview of the ISC (Internet Systems Consortium) DHCP Server (http://www.isc.org/index.pl). This document includes a detailed analysis of the features that are supported by the server as well as an analysis of the configuration, management and overall usability of the system. Much of the analysis was done on a Fedora Core 4 (FC4) system using the vendor-supplied DHCP server package, which at the time of writing is version 3.0.2-34. .

II. DHCP Server

II.a Configuration and Setup Experience

• The DHCPD server software is freely available for download, either as a tarball or vendor supplied package (rpm, deb, or otherwise). No additional hardware peripherals or cabling are necessary. Build configurations are done on the command line although all necessary features are enabled when building from source and the software is installed in a very standard path. Modifications to the build configuration are not recommended.

• DHCPD is currently supported under: Linux, xBSD, SCO, HP-UX, ULTRIX,

NeXTSTEP, and Solaris

• Fee-based support is available from the Internet Systems Consortium on 3 different levels:

Premium Plus Basic Hours of Coverage 24x7 12x7 (8 ET) 9x5 (M-F 9-6) Critical Incident Response Time

2 hrs 4 hrs 8 Business hrs

Regular Response Time 4 hrs 8 hrs Next business day

Method Email & Phone

Email & Phone

Email Only

Patch Notification Yes Yes Yes Preventative Consulting 8 hrs 4 hrs 1 hr Support Contacts 4 2 2

Advance Security Notification & Software Guild Membership

Yes Yes Yes

of 16

II.b Special Features

• The server should be setup by someone with at the very least, a base familiarity with the protocol itself, it purpose, and functions. It is recommended that they have an understanding of the UNIX/Linux command line and related text editors.

• If building from an rpm or other binary distribution, it is always considered best

practice to use a vendor-supplied package whenever installing or upgrading. However, the source package can be obtained from the Internet Systems Consortium Website: http://ftp.isc.org/isc/dhcp/dhcp-3.0.4.tar.gz

gunzip dhcp-3.0.4.tar.gz tar -vxf dhcp-3.0.4.tar

From here, the source can be compiled within the dhcp-3.0.4 directory and installed via:

./configure make make install

Alternately, an rpm can be built via: rpm –ivh dhcp-3.0.4.rpm

• Configuration is performed most commonly using a console text editor such as vi.

With the exception of Yast (Yet another setup tool) under Suse Linux, and “Webmin” there are no graphical tools or “wizards” to configure DHCPD

of 16

• Likewise, there is “Webmin”, which is a GPL product written in Perl, available

from http://www.webmin.com . With this tool, nearly all configuration options (for DHCP and other services) can be toggled on/off or otherwise defined. One should use caution with Webmin in that if access to the utility is compromised, the entire server becomes vulnerable.

of 16

• Within these tools, there is no differentiation in available configuration options or “Modes”. All of the options available in the software are freely available for anyone who wishes to use them. Likewise, all available options can be set in the dhcpd.conf file from a console text editor. Alternatively, creating a script to generate a configuration would be relatively simple as the /etc/dhcpd.conf file is written in plaintext.

• While these tools do simplify some aspects of the configuration for someone less

familiar with a command line, a strong knowledge of TCP/IP, DHCP and the networking protocols that go with it is highly recommended.

• The upgrade process is fairly identical to the initial install. You may either build

the new source tarball package using the same process you would to install. If you are running DHCP on a server with a means of auto-updating software such as with Yellowdog Updater Modified (yum), you may simply run:

yum update (package name)

Conversely, the rpm package may be updated (if you have downloaded it) via:

• rpm –Uvh dhcp-(version number).rpm

of 16

• The bare minimum configuration for DHCP would require the following options set: Domain name, gateway address, subnet mask, broadcast address, dns server, leased segment of address space, and lease time

option domain-name "somedomain.com"; option domain-name-servers 192.168.1.1; option subnet-mask 255.255.255.0; default-lease-time 600; max-lease-time 7200; # DHCP 100-200 subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.128 192.168.1.200; option domain-name-servers 192.168.1.1; option domain-name "somedomain.com"; option routers 192.168.1.1; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; default-lease-time 600; max-lease-time 7200; }

• There are currently no backwards-compatibility issues with DHCP and the

configuration settings may be migrated to a new server simply by copying the configuration file to the working directory on the new machine and starting the service. It should be noted likewise however that DHCP does not maintain any internal mechanism for the backup and restoring of its configuration. Automating the storage of backups could be performed with a simple cron job however.

• DHCP services are available as a feature of many routers and switches by

commercial vendors. To create one from scratch using the Internet Systems Consortium DHCPD server is not considered standard practice.

II.c Server Management Experience

• The same graphical tools listed above (Webmin and Yast), as well as a text editor from the console may be used to update the service configuration. The configuration of these tools would require some code modification to “tailor” the feel of the application. As seen above, all of the configuration options are made available to the administrator from within the utilities.

• Remote management can be performed via either remote ssh into the machine, a

remote vnc / xwindows session, or through Webmin (an http-based configuration utility). The only limitation of administering the server remotely would be that if a mistake occurred which rendered the machine unreachable, this could potentially create a very large network service interruption.

of 16

There is no built-in mechanism for a rollback to a previous configuration. A backup copy of the previous configuration should be made when changes are applied. Rolling the configuration back to a previous state from here would simply be a matter of applying the old configuration file and restarting the service.

• As with building and configuring the server, it is recommended that anyone

maintaining the server have a base knowledge of the protocol. Some command-line and networking skill is recommended to maintain the server properly.

• As the controlling configuration file is text based and plainly formatted, scripting

out maintenance of the server would be straightforward for anyone with enough knowledge of Perl or shell scripting to do so.

• There aren’t built-in access restrictions for configuration, however administrative

access to the server can be restricted via sudo access, POSIX permissions, or restricting user and group access within Webmin. The primary limitation of this method being that administrative rights are pretty much all-or-nothing. There aren’t any standard tools at this time for managing multiple servers.

II.d Protocol Support

• Per http://www.ietf.org/html.charters/dhc-charter.html (last updated 3/30/2006) there is neither support for IPv6 or message authentication in the current releases of the Internet Systems Consortium DHCP server. Both are as of yet in the development phase.

II.e Product Features and Scenarios

• Unlike other distributions of the DHCP server released by commercial vendors, all of the source code is freely available and redistributable. All of the features in the Internet Systems Consortium DHCP server are available in all current version releases to anyone who wishes to use it without regard for organization or network size.

• A range of leased address space or, “scope” can easily be created with the “range”

option, designating the starting and ending IP address. Example: subnet 10.2.0.0 netmask 255.255.0.0 range 10.2.3.0 10.2.3.200; It is important to note that this designation is terminated with a semi-colon. This example states that 10.2.3.0-10.2.3.200 on the 10.2.0.0 subnet with a netmask of 255.255.0.0 will be leased out to clients.

of 16

Lease durations are managed with the options: default-lease-time 6000; #6000 seconds max-lease-time 7200; #7200 seconds Reservations are defined as follows:

host sample-client-hostname { hardware ethernet EE:EE:EE:EE:EE:EE; # client mac address fixed-address 10.0.0.12; #client ip address }

• Any IP space not explicitly accounted for in the configuration is not managed by

the DHCP server. Exclusions are essentially defined implicitly.

• One could setup a script to store and deliver dhcp.conf files to any number of hosts. The main limitation would be that the files would still need to be manually maintained.

• IP assignment conflicts (and all other messages) are reported and logged, typically in /var/log/messages.

Jun 12 10:16:23 coco dhcpd: DHCPREQUEST for 192.168.200.194 from 00:04:75:ca:4b:b2 (equipo3) via eth1 Jun 12 10:16:23 coco dhcpd: DHCPACK on 192.168.200.194 to 00:04:75:ca:4b:b2 (equipo3) via eth1 Jun 12 10:17:09 coco dhcpd: DHCPREQUEST for 192.168.200.195 from 00:04:75:ca:4b:3b (equipo1) via eth1 Jun 12 10:17:09 coco dhcpd: DHCPACK on 192.168.200.195 to 00:04:75:ca:4b:3b (equipo1) via eth1 Jun 12 10:17:16 coco dhcpd: DHCPREQUEST for 192.168.200.199 from 00:07:e9:aa:85:b9 (publico2) via eth1 Jun 12 10:17:16 coco dhcpd: DHCPACK on 192.168.200.199 to 00:07:e9:aa:85:b9 (publico2) via eth1

The most obvious limitation to this feature being that without a 3rd party log analyzer with notification capabilities (such as Nagios and others), this could make timely identification of IP address conflicts difficult. No other diagnostic tools, apart from system log reporting are included with the software.

• One of the shortcomings of the ISC DHCP package is that there are currently no

authentication methods supported within the Internet Systems Consortium DHCP server as noted from the ISC website: http://www.isc.org/index.pl?/sw/dhcp/dhcp-freenix.php

of 16

A man named Brian Masney however, HAS apparently written an LDAP patch for DHCP. While this is recognized by and linked from the DHCP website, this is not part of the released distribution. His project page is located at http://home.ntelos.net/~masneyb/

Likewise, there is no inherent capability in The Internet Systems Consortium DHCP server to detect rogue DHCP servers; however, there are 3rd party products available for this task, such as “rogue detect”. http://freshmeat.net/projects/roguedetect/

• Setting up a DNS server within the dhcpd.conf file is quite simple. It is done by

adding a single line specification of “option domain-name-servers” and specifying the IP addresses (comma-seperated) of the dns servers:

option domain-name-servers <server1>, <server2>

Dynamic DNS updates are enabled by default. They can be disabled merely by adding a parameter to the dhcpd.conf file: ddns-update off The biggest limitation of this feature is that the setting applies to all scopes.

• DHCP-relay is supported and runs as a separate process. It is typically invoked as

/usr/bin/dhcrelay with the following options:

Argument Description

-i Names of the network interfaces to configure. If no interface is specified, all network interfaces will be configured, eliminating non-broadcast interfaces if it can.

-p Port on which dhcrelay should listen. The DHCP Relay Agent transmits requests to the servers on this port and transmits responses to the clients on the port one greater than this port.

-d Force dhcrelay to run in the foreground always.

-q Disable printing the network configuration of dhcrelay on startup.

Invoking the program is fairly simple, but is run separately and from the command line. A cron job could be written however to maintain the process if desired.

• There are a few methods of access control. The first of which would be as noted above for “exclusion ranges,” adding a host declaration for a mac address, but with a non-routable ip address. There are a few options offered to deny or permit access to “unknown clients”. It should be noted that once this option is set to “deny” or “ignore”, all hosts wishing to use the network must have a

of 16

corresponding host entry with their mac address. This option is used in one of three varieties:

allow unknown-clients; deny unknown-clients; ignore unknown-clients;

• Servers may be added as needed. However, it is generally a bad idea to have more

than one DHCP server leasing addresses for the same range of IP space except as a failover, as this can create conflicts.

• A secondary DHCP server may be configured as follows to assume lease of

address space for a different network with the following configuration. The first configuration is defined on the primary server

subnet 192.168.200.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option broadcast-address 192.168.200.255; option routers 192.168.200.1; option domain-name-servers 192.168.200.1; pool { failover peer "dhcp-failover"; max-lease-time 1800; # 30 minutes range 192.168.200.100 192.168.200.254; }

} The following configuration would be placed on the secondary server:

authoritative; ddns-update-style none; failover peer "dhcp-failover" { secondary; # declare this to be the secondary server address 192.168.200.3; port 520; peer address 192.168.200.2; peer port 520; max-response-delay 30; max-unacked-updates 10; load balance max seconds 3; } subnet 192.168.200.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; option broadcast-address 192.168.200.255; option routers 192.168.200.1;

of 16

option domain-name-servers 192.168.200.1; pool { failover peer "dhcp-failover"; max-lease-time 1800; # 30 minutes range 192.168.200.100 192.168.200.254; }

• As previously noted, there is LDAP support for DHCP, available as a patch, however it is not presently a part of the distribution. Enabling this is quite involved and goes beyond the scope of this documentation. There are no other forms of “Account Databases” supported.

• Many commercial management products are available to manage DHCPD;

Tivoli and InterStructures as an example for both monitoring and management. Documentation for OpenView as a management tool is inconclusive; however it can certainly be used as a monitoring tool for the ISC DHCP server.

• All source code is included with the source package, so ostensibly the

code could be customized to any competent developer’s liking. There is a developer’s forum on the ISC.org website where patches and other extended code releases are shared. https://secure.isc.org/index.pl?/sw/guild/df/application.php

• Software updates can be applied via the same manner as the installation.

As previously stated, it is always best practice to use a vendor-supplied update, if the original install was from a vendor supplied package. However, from the source install, patches may be applied from the root directory of the source, with the appropriate patch file by issuing the following command:

patch –p0 dhcp-patch.diff

• Aside from auditing log files, pattern-matching, etc there are no built in mechanisms for user activity auditing. The limitation of this is that auditing can be very tedious in nature. If you wanted a list of every IP address attempting to request an address, use:

grep DHCPREQUEST /var/log/messages|grep | uniq

The grep command will print every line from /var/log/messages matching the pattern, “DHCPREQUEST”, the pipe will redirect the output to uniq which will strip duplicates

There are several commercial utilities that can monitor DHCP performance such as OpenView, Tivoli, InterStructures, and several other

of 16

3rd party applications. None of these require any additional configuration from within the /etc/dhcpd.conf file itself. The vendor documentation should have information on how to integrate these into the server.

II.f Performance

• While there are no “built-in” restrictions to how many IP addresses may be allocated per minute, or how fast they may be assigned, this can be designated per class within the configuration:

class "limited-1" { lease limit 4; }

• The basic hardware for DHCP is a network interface of some sort and the proper cabling to connect to the server. The more traffic the aforementioned interface and cabling can handle, as well as the processing power of the machine itself, the higher throughput it will be able to handle.

II.g Documentation and Support

• The included documentation is provided in the form of Man pages and RFC files. Also, there are numerous documents available from the ISC website (http://www.isc.org/index.pl?/sw/dhcp/dhcp-freenix.php). Community support can also be obtained from the ISC mailing lists as well (http://www.isc.org/index.pl?/sw/dhcp/dhcp-lists.php).

• Although the website maintains that the product is not supported, as it is not a commercial product, fee-based support is available as noted previously on page one and two.

Per: http://www.isc.org/sw/dhcp/dhcpv3-README.php#support

“The Internet Systems Consortium DHCP server is not a commercial product, and is not supported by the ISC. However, it has attracted a fairly sizable following on the Internet, which means that there are a lot of knowledgeable users who may be able to help you if you get stuck. These people generally read the [email protected] mailing list.”

• The Internet Systems Consortium is a non-profit organization. As such It

has no partnerships outside of the contributors to it’s own ongoing development projects

of 16

• DHCPD is licensed as free software through the Internet Systems Consortium as indicated in the software bundle available through the website.

Copyright (c) 2004-2006 by Internet Systems Consortium, Inc. ("ISC")Copyright (c) 1995-2003 by Internet Software Consortium Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063

open source software ab technical analysis dhcp · familiar with a command line, a strong knowledge...

Documents