A Novell DHCP server automatically assigns IP addresses and other configuration information to clients upon request or when the clients are restarted. Automatic assignment of configuration information reduces the amount of work required to configure and manage a large IP network.
In addition, integrating DHCP with eDirectory enables you to enter all configuration information into one distributed database. This greatly simplifies network administration and provides for the replication of DHCP configuration information.
The Novell DHCP Service provides the following features:
All DHCP configuration is managed in eDirectory, facilitating enterprise-wide management.
DHCP options can be set at the following levels:
Shared Network level
You can deny service to unwanted devices by creating Host objects identified with the MAC address of the device and setting deny booting for the host.
The DHCP software updates dhcpd.leases file to record all address assignments to clients.
You can use Dynamic DNS (DDNS) to update DNS with information about addresses assigned and rescinded.
The DHCP software enables the server to cache addresses and other configuration information from eDirectory for quick response.
You can configure the DHCP server to ping an address to verify that no other device is using it before assigning the address to a client.
It provides fault tolerance as follows:
A server can survive a temporary local eDirectory service outage and recover automatically.
DHCP configuration is replicated like other eDirectory data.
The DHCP server can work with any DNS server.
The Failover Peer protocol support allows two DHCP servers to share a common address pool that ensures continuous availability of the network.
The import or export DHCP service is supported to transfer the DHCP service configuration from files in Linux dhcpd.conf format into eDirectory or from eDirectory to a text file in a dhcpd.conf format.
The Novell DHCP service supports the features that were previously provided by Novell Open Enterprise Server 2 Linux and supports the standards of the following RFCs:
RFC 2131: Dynamic Host Configuration Protocol
RFC 2132: DHCP Options and BOOTP Vendor Extensions
RFC 2241: DHCP Options and Novell Directory Services
RFC 2242: NetWare/IP Domain Name and Information
Novell DHCP Services also supports the BOOTP standards of the following RFCs:
RFC 1497: BOOTP Vendor Information Extensions
RFC 1534: Interoperation Between BOOTP and DHCP
RFC 1542: Clarifications and Extensions for the Bootstrap Protocol
The Novell DHCP service supports vendor options, DHCP options, and BOOTP parameters as defined in Internet RFC 2132 with a few exceptions. A table listing the option codes and names is found in Section A.3, DHCP Option Descriptions.
Novell has defined three DHCP options for eDirectory. These options eliminate the need to provide this information each time users log in.
Option 85 provides the IP address of one or more eDirectory servers for the client to contact for access to the eDirectory database. Option 86 provides the name of the eDirectory tree the client will be contacting. Option 87 provides the eDirectory context the client should use.
For detailed information about using these options in OES 2 Linux, refer to Internet ‘RFC 2241’, DHCP Options for Novell Directory Services.
Novell uses option codes 62 and 63 in the DHCP packet for NetWare/IP. Option 62 contains the NetWare/IP domain name.
Option 63, the IPX Compatibility option, contains general configuration information such as the primary DSS, the preferred DSS, and the nearest servers. Option 63 also provides additional information in the form of suboptions, listed in the table below.
Table 1-5 Suboptions Codes and Meaning
If the value of this field is 1, the client should perform a NetWare Nearest Server Query to find out its nearest NetWare/IP server.
Provides a list of up to five addresses of NetWare Domain SAP/RIP servers.
Provides a list of up to five addresses of the nearest NetWare/IP servers.
Indicates the number of times a NetWare/IP client should attempt to communicate with a given DSS server at startup.
Indicates the amount of delay in seconds between each NetWare/IP client attempt to communicate with a given DSS server at start-up.
If the value is 1, the NetWare/IP client should support NetWare/IP Version 1.1 compatibility.
Identifies the Primary Domain SAP/RIP Service server (DSS) for this NetWare/IP domain.
Refer to Internet ‘RFC 2242’ and NetWare IP Domain Name and Information for detailed information about using these NetWare/IP options.
When you select Novell DHCP Services during the OES 2 Linux installation, the eDirectory schema is extended to enable the creation of DHCP objects and the following objects are created:
dhcpLocator (Locator object)
DHCPGroup (Group object)
Only one copy of these objects exists in an eDirectory tree. The DNS servers, DHCP servers, iManager, and Management Console must have access to these objects.
The DHCPGroup object is a standard eDirectory group object. This object is used to grant the necessary rights to the eDirectory user used by the DHCP server to access the DHCP objects
The dhcpLocator object is created during the OES 2 Linux installation and has references to dhcpServer and dhcpService objects. The creator of the Locator object grants Read and Write permissions to this object to the network administrators.
The following eDirectory objects are supported in DHCP:
Figure 1-17 shows a basic configuration of the DHCP objects. This structure might be used for a small to medium-size network.
Figure 1-17 eDirectory Objects for DHCP
The DHCP Service object is a container object that contains the DHCP configuration for the entire network, a subset of the network, or a single server. It is made up of configuration details of shared networks, subnets, classes, pools and hosts. Depending on your organizational needs, there can be more than one DHCP Service object in the network.
The DHCP Server object serves one or more DHCP service objects. Each DHCP server can be associated with one or more DHCP services depending on the needs of your organization. In a typical scenario, there must be one DHCP Server object configured for every system running DHCP Service.
Keeping the DHCP server and its configuration details as separate entities provides much-needed flexibility in associating and switching between DHCP servers and configurations.
All subnets that share the same physical network can be grouped under a Shared Network object.
Some installations have physical networks on which more than one IP subnet operates. For example, if there is a site-wide requirement that 8-bit subnet masks be used, but a department with a single physical Ethernet network expands to the point where it has more than 254 nodes, it might be necessary to run two 8-bit subnets on the same Ethernet until a new physical network can be added. In this case, the subnet declarations for these two networks must be enclosed in a shared-network declaration.
A shared network object must be created under a service object.
The Subnet object enables you to distribute IP addresses and DHCP options to each network.
Because the DHCP Service object is the fundamental object of the hierarchy of the network, a subnet object must be created under a service element in the hierarchy. If your organizational setup requires the subnet object to be grouped under a shared network, create the subnet object under a service-shared network hierarchy.
The subnet statement is used to provide dhcpd with enough information to tell whether or not an IP address is on that subnet. It can also be used to provide subnet-specific parameters and to specify what addresses can be dynamically allocated to clients booting on that subnet.
The pool declaration can be used to specify a pool of addresses that are treated differently than another pool of addresses, even on the same subnet. It is also possible to set up entirely different subnets for known and unknown clients. You can create multiple pool objects under a Subnet object. The pool object must be created under a service-shared network-subnet or service-subnet hierarchy.
You can create multiple pool objects under a Subnet object.
The pool object must be created under a service-shared network hierarchy.
The Class object helps in segregating clients into classes, and these clients can be treated differently depending on the class they are in. This separation can be done either with a conditional statement, or with a match statement within the class declaration. It is also possible to create automatic subclasses based on the contents of the client packet. You can also set a limit on the number of clients within a class or subclass.A subclass is a class with the same name as a regular class, but with a specific submatch expression
To group clients into different classes based on conditional expression, you can specify a match expression within a class statement in the following manner:
match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
A subclass is a class with the same name as a regular class, but with a specific submatch expression that is hashed for quick matching. To automatically create lease-limited subclasses based on client parameters, use the spawn with statement.
The option value sent by the client is checked with the dynamically created subclasses for the specified class and if a match is found, the client will be classified under that subclass and treated accordingly.
If no match is found, the server creates a new subclass and logs the information in the lease file, and the client is classified in this new subclass. After classification, it is processed according to the rule set for the class.
The Host object represents a client in the network with statically assigned IP address. It is identified by a host name.
The DHCP Management Utility can be used to configure host objects that are manually assigned. When configuring an individual host object, you can provide specific options that override global options or those set at the subnet/service level.
The DHCP Zone object contains the references the Domain Name System (DNS).
A DHCP server uses this information to perform dynamic updates for the zone objects. A DNS server must be configured to allow updates for the zone that the DHCP server is updating.
A TSIG key is used for authenticating dynamic updates to a DNS server. TSIG uses shared secret keys as a cryptographically secure means of authenticating a DNS update.
The Failover Peer protocol allows only two DHCP servers to share a common address pool. This ensures continuous availability of the network. The process defines the role of a primary server and a secondary server.
Each server has about half of the available IP addresses in the Pool at any given time for allocation. During a prolonged failure of the primary server, the secondary server recovers all the addresses that the primary server had available for allocation, and begins to reuse them.
iManager can be used to configure and manage eDirectory-based DHCP objects and can run on any browser workstation. It does not require the Novell Client or any installed component as a prerequisite. It operates within the common iManager framework and is thus tightly integrated with OES 2 Linux.
iManager manages one eDirectory tree at a time.
When iManager is started in the browser, the first screen you see is the login screen. You are prompted to provide your username, password, eDirectory context, and the eDirectory tree whose objects you want to manage.
Administration authentication in iManager is based on the common authentication mechanism.
To manage objects in a different eDirectory tree, you must log in to the utility again, specifying the eDirectory tree you want to access. Your login identity is displayed at the top of the screen.
Figure 1-18 The DHCP iManager Interface
The main screen has three parts: a taskbar at the top of the screen that displays icons for top-level management functions; a left panel that displays roles, tasks, and other administrative functions; and a main panel that allows you to manage role-based and administrative tasks.
For more information on the iManager management interface, see the Novell iManager 2.7.4 Administration Guide.
The DHCP services have been logically organized into roles and tasks in a way that is intuitive to network administrators. Each role consists of a set of tasks arranged in a manner that is hierarchical, top-down, and easy to administer.
To view the roles, click theicon on the taskbar.
The tasks under each of these roles are logically arranged in a top-down manner with the option to configure DHCP scope settings at the head of each role. A role, depending on its current state, is preceded by a plus or a minus sign. An administrator can expand a role such as DHCP (OES Linux) to see the tasks it contains or collapse it for a more concise view.
The organization of roles and tasks follows the containership rules of object creation and manipulation in DHCP. At the top is the DHCP Scope Settings task. At the top is the DHCP Scope Settings task, which allows you to specify the location of the Locator object and the administrative scope for the session.
IMPORTANT:For improved performance, configure the DHCP scope settings before you start using iManager.
The Java Management Console can be used to configure and manage DHCP (OES Linux) objects based on eDirectory. It is an independent executable Java application. It can be launched through Windows Programs menu by clicking> > > . It can also be launched by double-clicking the DNSDHCP shortcut icon created on the desktop.
When the Java Management Console is launched, it prompts you to select a tree as the target eDirectory context.
You must log in to the desired eDirectory tree before launching the Java Management Console. To manage objects in a different eDirectory tree, you must exit the utility, change the context to the other eDirectory tree, and launch the utility again. The current eDirectory tree name is displayed in the utility's title bar.
The Java Management Console manages one tree at a time. Figure 1-19 shows the main user interface window for DHCP (OES Linux) Services.
Figure 1-19 DHCP (OES Linux) Java-based Management Console User Interface
For more information, see:
DHCP objects can be accessed via thetab. There are three panes within each tab page. The left pane displays the managed DHCP objects in tree form. The right pane displays detailed information about the object that is selected in the left or bottom pane. The bottom pane lists the Linux DHCP servers configured to provide necessary services.Resources are organized according to the object hierarchy and the implicit ordering of objects. In the left pane, all the DHCP Service objects are listed in alphanumeric order.All of the objects are created as eDirectory objects and are subject to Linux Administrator conventions. Therefore, when creating a new object, you should always name the object first in each Create dialog box.The Create dialog box for these objects has browsing capability in the eDirectory tree, so an administrator with Write or Supervisor rights can select a specific context.A newly created object's button on the toolbar is context-sensitive in relation to the selected item in either service's left tree pane. Your rights to the objects are not verified until you perform an update, delete, or create against the target objects.The DHCP objects available in the new object dialog’s creation list box depend on the selected object in the left tree pane.
After a new DHCP object has been created, the Java Management Console grants the objects Read and Write rights to the dhcpLocator object.
For fast and efficient searching, the distinguished names of newly created Service objects and Server objects are added to the corresponding attribute of the dhcpLocator object. Renaming or deleting these objects is automatically performed by eDirectory because of the built-in feature for eDirectory distinguished names.
After a new DHCP object has been created, the Java Management Console gives you the choice of staying in its current focus or setting the focus on the newly created object. The utility also displays its detailed information in the right pane. This feature is provided as a convenience to administrators and can be used by selecting thecheck box.
The Management Console offers no menu items. All functions are provided by the toolbar. The functions that are relevant for the item selected in the left tree pane or bottom server pane are highlighted to show their availability.
Figure 1-20 DHCP (OES Linux) Toolbar
If you position the cursor over the icon, the icon's name appears. The following table lists when each toolbar button is enabled in relationship to the selected object. <Include the same table and change Configured options to Custom options.>
The status bar displays in the bottom pane of the Management Console. When an object is selected, the status of that object is displayed in the status bar. Figure 1-21 displays the status bar for the Server LinuxDHCP_Japan server.
Figure 1-21 DHCP (OES Linux) Status Bar
The icon for the Linux DHCP Server does not change as it does for DNS. The icon remains the same no matter what state the server is in. Figure 1-22 shows the DHCP (OES Linux) server icon.
Figure 1-22 DHCP (OES Linux) Server icons
These are certain rules that govern the creation and manipulation of objects in the Linux DHCP object hierarchy.