System Management Guide: Communications and Networks

Preboot Execution Environment Proxy DHCP Daemon (pxed)

The PXE Proxy DHCP server behaves much like a DHCP server by listening for ordinary DHCP client traffic and responding to certain client requests. However, unlike the DHCP server, the PXE Proxy DHCP server does not administer network addresses, and it only responds to clients that identify themselves as PXE clients. The responses given by the PXE Proxy DHCP server contain the mechanism by which the client locate sthe boot servers or the network addresses and descriptions of the supported, compatible boot servers.

Using a PXE Proxy DHCP server in addition to a DHCP server provides three key features. First, you can separate the administration of network addresses from the administration of boot images. Using two different processes on the same system, you can configure the boot information managed by the PXE Proxy DHCP server without disturbing or requiring access to the DHCP server configuration. Second, you can define multiple boot servers and let the PXE client select a particular server during boot time. Each boot server can, for example, offer a different type of operating system or system configuration. Finally, using the proxy server offers the ability to configure the PXE client to use multicast IP addressing to discover the location of the compatible boot servers.

The PXE Proxy DHCP server can be configured to run on the same system that is running the DHCP server or on a different system. Also, it can be configured to run on the same system that is also running the boot server daemon or on a different system.

The PXE Proxy DHCP Server

The PXED server is segmented into three main pieces, a database, a protocol engine, and a set of service threads, each with its own configuration information.

The PXED Database

The db_file.dhcpo database is used to generate the options to be sent to the client when the client send an REQUEST packet. The options returned by the database depend on the type of server chosen. This is set using the keyword pxeservertype in the pxed.cnf file.

Using the information in the configuration file, the database is primed and verified for consistency.

The PXED Protocol Engine

For AIX 4.3.1 and later, the PXED protocol engine is based on Intel's Preboot Execution Environment (PXE) Specification Version 2.1, but is still compatible with Intel's PXE Specification Version 1.1. The protocol engine uses the database to determine what information should be returned to the client.

PXED Threaded Operations

The last piece of the PXED server is actually a set of operations that are used to keep things running. Since the PXED server is threaded, these operations are actually set up as threads that occasionally do things to make sure everything is together.

The first thread, the main thread, handles the SRC requests (such as startsrc, stopsrc, lssrc, traceson, and refresh). This thread also coordinates all operations that affect all threads and handles signals. For example,

• A SIGHUP (-1) causes a refresh of all databases in the configuration file.
• A SIGTERM (-15) causes the server to gracefully stop.

The other thread processes packets. Depending on the server type, there can one or two threads. One thread listens on port 67 and the second one listens to port 4011. Each of these can handle a request from a client.

Configuring the PXED Server

By default, the PXED server is configured by reading the /etc/pxed.cnf file, which specifies the server's initial database of options and addresses. The server is started from the Web-based System Manager, from SMIT, or through SRC commands.

Configuring the PXED server is usually the hardest part of using PXED in your network. First, figure out what networks you need to have PXE clients on. The following example configures the pxed daemon to run on the same machine as the DHCP server:

pxeservertype       proxy_on_dhcp_server
 
subnet default
{
    vendor pxe
    {
        option    6      2       # Disable Multicast boot server discovery
        option    8      1   2     9.3.4.5    9.3.4.6   2    1    9.3.149.29
                                 # The above option gives the list of bootservers
        option    9      0       "PXE bootstrap server" \
                         1       "Microsoft Windows NT Boot Server"  \
                         2       "DOS/UNDI Boot Server"
        option    10    20    "seconds left before the first item in the boot menu is auto-selected"
     }
}

The suboptions in the vendor container are sent to PXE clients only if the client's IP address is in the subnet's IP address range (for example, 9.3.149.0 through 9.3.149.255).

The following example configures the pxed daemon to run on a different machine than the DHCP server:

subnet default
{
    vendor pxe
    {
        option    6      10      # The bootfile name is present in the client's initial pxed
                                 # offer packet.
        option    8      1   2     9.3.4.5    9.3.4.6   2    1    9.3.149.29
                                 # The above option gives the list of bootservers
        option    9      0       "PXE bootstrap server" \
                         1       "Microsoft Windows NT Boot Server"  \
                         2       "DOS/UNDI Boot Server"
        option    10    20    "seconds left before the first item in the boot menu is auto-selected"
        bootstrapserver          9.3.148.65
        pxebootfile    1    2    1   window.one
        pxebootfile    2    2    1   linux.one
        pxebootfile    1    2    1   hello.one
        client 6 10005a8ad14d any
        {
           pxebootfile    1    2    1   aix.one
           pxebootfile    2    2    1   window.one
        }
    }
 
Vendor pxeserver
{
    option     7     224.234.202.202
}

The pxeservertype keyword is not set in the configuration file so the default value is taken, which is pdhcp_only, meaning the PXED server is running on a different machine than the DHCP server. Given this configuration, the PXED server listens on two ports (67 and 4011) for clients' BINLD REQUEST/INFORM packets. The option 7 is sent to the BINLD server when the PXED server receives a REQUEST/INFORM packet on port 67 from BINLD and option 60 is set to PXED server.

The db_file database clause indicates which database method to use for processing this part of the configuration file. Comments begin with a pound sign (#). From the # to the end of the line are ignored by the PXED server. Each option line is used by the server to tell the client what to do. PXED Vendor Container Suboptions describes the currently supported and known options. See PXED Server File Syntax for General Server Operation for ways to specify options that the server does not know about.

The Configuration File

The configuration file has an address section and an option definition section, which are based on the concept of containers that hold options, modifiers, and, potentially, other containers.

A container (basically, a method to group options) uses an identifier to classify clients into groups. The container types are subnet, class, vendor, and client. Currently, there is not a generic user-definable container. The identifier uniquely defines the client so that the client can be tracked if, for example, it moves between subnets. More than one container type can be used to define client access.

Options are identifiers that are returned to the client, such as default gateway and DNS address.

Containers

When the DHCP server receives a request, the packet is parsed and identifying keys determine which containers, options, and addresses are extracted

.

The previous example shows a subnet container. Its identifying key is the client's position in the network. If the client is from that network, then it falls into that container.

Each type of container uses a different option to identify a client:

• The subnet container uses the giaddr field or the interface address of the receiving interface to determine which subnet the client came from.
• The class container uses the value in option 77 (User Site Class Identifier).
• The vendor uses the value in option 60 (Vendor Class Identifier).
• The client container uses the option 61 (Client Identifier) for PXE clients and the chaddr field in the BOOTP packet for BOOTP clients.

Except for subnets, each container allows the specification of the value that it will match including regular expression matching.

There is also an implicit container, the global container. Options and modifiers in the global container apply to all containers unless overridden or denied. Most containers can be placed inside other containers implying a scope of visibility. Containers might or might not have address ranges associated with them. Subnets, by their nature, have ranges associated with them.

The basic rules for containers and subcontainers are as follows:

• All containers are valid at the global level.
• Subnets can never be placed inside other containers.
• Restricted containers cannot have regular containers of the same type within them. (For example, a container with an option that only allows a class of Accounting cannot include a container with an option that allows all classes that start with the letter "a." This is illegal.)
• Restricted client containers cannot have subcontainers.

Given the above rules, you can generate a hierarchy of containers that segment your options into groups for specific clients or sets of clients.

If a client matches multiple containers, how are options and addresses handed out? The DHCP server receives messages, it passes the request to the database (db_file in this case), and a container list is generated. The list is presented in order of depth and priority. Priority is defined as an implicit hierarchy in the containers. Strict containers are higher priority than regular containers. Clients, classes, vendors, and finally subnets are sorted, in that order, and within container type by depth. This generates a list ordered by most specific to least specific. For example:

    Subnet 1
    --Class 1
    --Client 1
    Subnet 2
    --Class 1
    ----Vendor 1
    ----Client 1
    --Client 1

The above example shows two subnets, Subnet 1 and Subnet 2. There is one class name, Class 1, one vendor name, Vendor 1, and one client name, Client 1. Class 1 and Client 1 are defined in multiple places. Because they are in different containers, their names can be the same but values inside them can be different. If Client 1 sends a message to the DHCP server from Subnet 1 with Class 1 specified in its option list, the DHCP server would generate the following container path:

Subnet 1, Class 1, Client 1

The most specific container is listed last. To get an address, the list is examined in reverse hierarchy to find the first available address. Then, the list is examined in forward hierarchy to get the options. Options override previous values unless an option deny is present in the container. Also, since Class 1 and Client 1 are in Subnet 1, they are ordered according to the container priority. If the same client is in Subnet 2 and sends the same message, the container list generated is:

Subnet 2, Class 1, Client 1 (at the Subnet 2 level), Client 1 (at the Class 1 level)

Subnet 2 is listed first, then Class 1, then the Client 1 at the Subnet 2 level (because this client statement is only one level down in the hierarchy). The hierarchy implies that a client matching the first client statement is less specific than the client matching Client 1 of Class 1 within Subnet 2.

Priority selected by depth within the hierarchy is not superseded by the priority of the containers themselves. For example, if the same client issues the same message and specifies a vendor identifier, the container list is:

Subnet 2, Class 1, Vendor 1, Client 1 (at Subnet 2 level), Client 1 (at Class 1 level)

Container priority improves search performance because it follows a general concept that client containers are the most specific way to define one or more clients. The class container holds less specific addresses than a client container; vendor is even less specific; and subnet is the least specific.

Addresses and Address Ranges

Any container type can have associated addresses ranges; subnets must have. Each range within a container must be a subset of the parent container's range and must not overlap with other containers' ranges. For example, if a class is defined within a subnet and the class has a range, the range must be a subset of the subnet's range. Also, the range within that class container cannot overlap with any other ranges at its level.

Ranges can be expressed on the container line and modified by range and exclude statements to allow for disjoint address sets associated with a container. So, if you have the top ten addresses and the second ten addresses of a subnet available, the subnet could specify these addresses by range in the subnet clause to reduce both memory use and the chance of address collision with other clients not in the specified ranges.

Once an address has been selected, any subsequent container in the list that contains address ranges is removed from the list along with its children. The reason for this is that network-specific options in removed containers are not valid if an address is not used from within that container.

Options

After the list has been culled to determine addresses, a set of options is generated for the client. In this selection process, options overwrite previously selected options unless a deny is encountered, in which case, the denied option is removed from the list being sent to the client. This method allows inheritance from parent containers to reduce the amount of data that must be specified.

Logging

Logging parameters are specified in a container like the database, but the container keyword is logging_info. When learning to configure PXED, it is advisable to turn logging to its highest level. Also, it is best to specify the logging configuration prior to any other configuration file data to ensure that configuration errors are logged after the logging subsystem is initialized. Use the logitem keyword to turn on a logging level or remove the logitem keyword to disable a logging level. Other keywords for logging allow the specification of the log filename, file size, and the number of rotating log files.

Performance Considerations

It is important to understand that certain configuration keywords and the structure of the configuration file have an effect on the memory use and performance of the PXED server.

First, excessive memory use can be avoided by understanding the inheritance model of options from parent to child containers. In an environment that supports no unlisted clients, the administrator must explicitly list each client in the file. When options are listed for any specific client, the server uses more memory storing that configuration tree than when options are inherited from a parent container (for example, the subnet, network, or global containers). Therefore, the administrator should verify whether any options are repeated at the client level within the configuration file and, if so, determine whether these options can be specified in the parent container and shared by the set of clients as a whole.

Also, when using the logItem entries INFO and TRACE, numerous messages are logged during the processing of every PXE client's message. Appending a line to the log file can be an expensive operation; therefore, limiting the amount of logging improves the performance of the PXED server. When an error with the PXED server is suspected, logging can be dynamically re-enabled using the SRC traceson command.

PXE Vendor Container Suboptions

When supporting a PXE client, the DHCP server passes the following option to the BINLD server that BINLD uses to configure itself:

PXED Server File Syntax for General Server Operation

Note: Time Units (time_units) shown in the following table are optional and represent a modifier to the actual time. The default time unit is minutes. Valid values are seconds (1), minutes (60), hours (3600), days (86400), weeks (604800), months (2392000), and years (31536000). The number shown in parentheses is a multiplier applied to the specified value n to express the value in seconds.

PXED Server File Syntax for db_file Database

Notes:

• Time Units (time_units) shown in the following table are optional and represent a modifier to the actual time. The default time unit is minutes. Valid values are seconds (1), minutes (60), hours (3600), days (86400), weeks (604800), months (2392000), and years (31536000). The number shown in parentheses is a multiplier applied to the specified value n to express the value in seconds.
• Items that are specified in one container can be overridden inside a subcontainer. For example, you could globally define BOOTP clients, but within a certain subnet allow BOOTP clients by specifying the supportBootp keywork in both containers.
• The client, class, and vendor containers allow for regular expression support. For class and vendor, a quoted string with the first character after the quote being an exclamation point (!) indicates that the rest of the string should be treated as a regular expression. The client container allows for regular expressions on both the hwtype and the hwaddr fields. A single string is used to represent both fields with the following format:

  decimal_number-data
  

  If decimal_number is zero, then data is an ASCII string. If any other number, data is hex digits.

For details about other options, see DHCP Server File Known Options.