[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

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,

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   2    1
                                 # 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, through

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   2    1
                                 # 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"
        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

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.


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:

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:

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.


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 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:

Opt Num Default Data Type Can Specify? Description
6 Decimal number Yes PXE_DISCOVERY_CONTROL. Limit 0-16. This is a bit field. Bit 0 is the least significant bit.

bit 0
If set, disables broadcast discovery.

bit 1
If set, disables multicast discovery.

bit 2
If set, only uses/accepts servers in PXE_BOOT_ SERVERS.

bit 3
If set, and a bootfile name is present in the intial PXED offer packet, downloads the bootfile (does not prompt/menu/discover boot server).

bit 4-7
Must be 0. If this option is not supplied then client assumes all bits to be equal to 0.
7 One dotted quad Yes Multicast IP address. Boot server discovery multicast IP address. Boot servers capable of multicast discovery must listen on this multicast address. This option is required if the multicast discovery disable bit (bit 1) in the PXE_DISCOVERY_ CONTROL option is not set.
8 Boot server type(0-65535) Yes PXE_BOOT_SERVERS IP address count (0-256)

Type 0
Miscrosoft Windows IP address...IP address NT Boot Server Boot server type IP address

Type 1
Intel LCM Boot Server count IP address ...

Type 3
DOS/UNDI Boot Server IP address

Type 4
NEC ESMPRO Boot Server

Type 5
IBM WSoD Boot Server

Type 6
IBM LCCM Boot Server

Type 7
CA Unicenter TNG Boot Server.

Type 8
HP OpenView Boot Server.

Type 9 through 32767

Type 32768 through 65534
Vendor use

Type 65535
PXE API Test Server.

If IP address count is zero for a server type then the client may accept offers from any boot server of that type. Boot Servers do not respond to discovery requests of types they do not support.

9 Boot server type (0-65535) Yes PXE_BOOT_MENU "description" Boot server boot "order" is implicit in the type. "description"...menu order.
10 Timeout in seconds (0-255) Yes PXE_MENU_PROMPT "prompt" The timeout is the number of seconds to wait before auto- selecting the first boot menu item. On the client system, the prompt is displayed followed by the number of seconds remaining before the first item in the boot menu is auto-selected. If the F8 key is pressed on the client system, then a menu is displayed. If this option is provided to the client, then the menu is displayed without prompt and timeout. If the timeout is 0, then the first item in the menu is auto-selected. If the timeout is 255, the menu and prompt is displayed without auto-selecting or timeout.

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.

Keyword Form Subcontainers? Default Value Meaning
database database db type Yes None The primary container that holds the definitions for the address pools, options, and client access statements. db type is the name of a module that is loaded to process this part of the file. The only value currently available is db_file.
logging_info logging_info Yes None The primary logging container that defines the logging parameters.
logitem logitem NONE No All default to not enabled. Enables the logging level. Multiple lines are allowed.
logitem SYSERR
logitem OBJERR
logitem PROTOCOL
logitem PROTERR
logitem WARN
logitem WARNING
logitem CONFIG
logitem EVENT
logitem PARSEERR
logitem ACTION
logitem ACNTING
logitem STAT
logitem TRACE
logitem RTRACE
logitem START
numLogFiles numLogFiles n No 0 Specifies the number of log files to create. The log rotates when the first one fills. n is the number of files to create.
logFileSize logFileSize n No 0 Specifies the size of each log file in 1024-byte units.
logFileName logFileName path No None Specifies the path to the first log file. The original log file is named filename or filename.extension. The filename must be eight or fewer characters. When a file is rotated, it is renamed beginning with the base filename, then either appending a number or replacing the extension with a number. For example, if the original file name is file, the rotated file name becomes file01. If the original file name is file.log, it becomes file.01.
pxeservertype pxeservertype servertype No dhcp_only Indicates the type of dhcpsd server it is. servertype can be proxy_on_dhcp_server, which means that PXED is running on the same machine as the DHCP server and it is listening for PXE client requests on port 4011 only, or the default value of pdhcp_only, which means the PXED is running on a separate machine and it has to listen for client packets on port 67 and 4011.

PXED Server File Syntax for db_file Database


Keyword Form Subcontainers? Default Value Meaning
subnet subnet default Yes None Specifies a subnet that does not have any range. The subnet is used by the server only when it is responding to INFORM packet from the client.
subnet subnet subnet id netmask Yes None Specifies a subnet and a pool of addresses. All addresses are assumed to be in the pool unless a range is specified on the line or addresses are modified later in the container by a range or exclude statement. The optional range is a pair of IP addresses in dotted quad format separated by a dash. An optional label and priority can be specified. These are used by virtual subnets to identify and order the subnets in the virtual subnet. The label and priority are separated by a colon. These containers are only allowed at the global or database container level.
subnet subnet id netmask range
subnet subnet id netmask label:priority
subnet subnet id netmask range label:priority
subnet subnet subnet id range Yes None Specifies a subnet that goes within a network container. It defines a range of addresses that is the whole subnet unless the optional range part is specified. The netmask associated with the subnet is taken from the surrounding network container.

Note: This method is deprecated in favor of the other subnet forms.
option option number data ... No None Specifies an option to send to a client or, in the case of deny, an option to prevent from being sent to the client. The optional * deny clause means all options not specified in the current container are not to be returned to the client. option numberdeny only denies the specified option. number is an unsigned 8-bit integer. data is specific to the option (see above) or can be specified as a quoted string (indicating ASCII text) or 0xhexdigits or hex"hexdigits" or hex "hexdigits". If the option is in a vendor container, the option will be encapsulated with other options in an option 43.
option numberdeny
option * deny
exclude exclude an IP address No None Modifies the range on the container in which the exclude statement is in. The exclude statement is not valid in the global or database container levels. The exclude statement removes the specified address or range from the current range on the container. The exclude statement allows you to create non-contiguous ranges for subnets or other containers.
exclude dotted_quad-dotted_quad
range range IP_address No None Modifies the range on the container in which the range statement is in. The range statement is not valid in the global or database container levels. If the range is the first in the container that does not specify a range on the container definition line, then the range for the container becomes the range specified by the range statement. Any range statement after the first range or all range statements for a containers that specifies ranges in its definition are added to the current range. With the range statement, a single address or set of addresses can be added to the range. The range must fit inside the subnet container definition.
range dotted_quad-dotted_quad
client client hwtype hwaddr NONE Yes None Specifies a client container that denies the client specified by the hwaddr and hwtype from getting an address. If hwtype is 0, then hwaddr is an ASCII string. Otherwise, hwtype is the hardware type for the client and hwaddr is the hardware address of the client. If the hwaddr is a string, then quotes are accepted around the string. If the hwaddr is a hexstring, then the address may be specified by 0xhexdigits or hex digits. range allows the client specified by the hwaddr and hwtype to get an address in the range. Must be regular expressions to match multiple clients.
client hwtype hwaddr ANY
client hwtype hwaddr dotted_quad
client hwtype hwaddr range
class class string Yes None Specifies a class container with name string. String can be quoted or not. If quoted, the quotes are removed before comparison. Quotes are required for strings with spaces or tabs. This container is valid at any level. A range can be supplied to indicate a set of addresses to hand out to a client with this class. The range is either a single dotted quad IP address or two dotted quad IP addresses separated by a dash.
class string range
network network network id netmask Yes None Specifies a network ID using class information (for example, with a netmask of would be network This version of the network container is used to hold subnets with the same network ID and netmask. When a range is provided, all the addresses in the range are in the pool. The range must be in the network ID's network. This uses class full addressing. This is only valid in the global or database container level.

Note: The network keyword is deprecated in favor of the subnet container.
network network id
network network id range
vendor vendor vendor_id Yes None Specifies a vendor container. Vendor containers are used to return option 43 to the client. The vendor id may be specified in a quoted string or a binary string in the form 0xhexdigits or hex"digits". An optional range may be placed after the vendor id. The range is specified as two dotted quads separated by a dash. After the optional range, an optional hexstring or ASCII string can be specified as the first part of the option 43. If options are in the container, they are appended to the option 43 data. After all options are processed an End Of Option List Option is appended to the data. To return options outside of an option 43, use a regular expression client that matches all clients to specify normal options to return based on the vendor ID.
vendor vendor_id hex""
vendor vendor_id hex ""
vendor vendor_id 0xdata
vendor vendor_id ""
vendor vendor_id range
vendor vendor_id range hex""
vendor vendor_id range hex ""
vendor vendor_id range 0xdata
vendor vendor_id range ""
inoption inoption number option_data Yes None Specifies a container to be matched against any arbitrary incoming option specified by the client. number specifies the option number. option_data specifies the key to match for this container to be selected during address and option selectoin for the client. option_data is specified in expected form -- quoted string, IP address, integer value -- for well known options, or it can be optionally speicifed as a hexadecimal string of bytes if preceded by the characters 0x. For options that are not well known to the server, a hexadecimal string of bytes can be specified in the same fashion. Additionally, the option_data can indicate a regular expression to be compared against the string representation of the client's option data. Regular expressions are specified in a quoted string beginning "! (double quote followed by an exclamation mark). The string form of options not well known to the server will be a hexadecimal string of bytes NOT preceded with the characters 0x.
inoption number option_data range
virtual virtual fill id id ... No None Specifies a virtual subnet with a policy. fill means use all addresses in the container before going to the next container. rotate means select an address from the next pool in the list on each request. sfill and srotate are the same as fill and rotate, but a search is done to see if the client matches containers, vendors, or classes in the subnet. If a match is found that can supply an address, the address is taken from that container instead of following the policy. There can be as many IDs as needed. id is either the subnet ID from the subnet definition or the label from the subnet definition. The label is required if there are multiple subnets with the same subnet id.
virtual sfill id id ...
virtual rotate id id ...
virtual srotate id id ...
inorder: inorder: id id ... No None Specifies a virtual subnet with a policy of fill, which means use all addresses in the container before going to the next container. There can be as many IDs as needed. id is either the subnet ID from the subnet definition or the label from the subnet definition. The label is required if there are multiple subnets with the same subnet ID.
balance: balance: id id ... No None Specifies a virtual subnet with a policy of rotate, which means use the next address in the next container. There can be as many IDs as needed. id is either the subnet ID from the subnet definition or the label from the subnet definition. The label is required if there are multiple subnets with the same subnet ID.
bootstrapserver bootstrapserver IP address No None Specifies the server clients should use from which to TFTP files after receiving BOOTP or DHCP packets. This value fills in the siaddr field in the packet. This is valid at any container level.
giaddrfield giaddrfield IP address No None Specifies the giaddrfield for response packets.

Note: This specification is illegal in the BOOTP and DHCP protocols, but some clients require the giaddr field to be the default gateway for the network. Because of this potential conflict, giaddrfield should only be used within a client container, although it can work at any level.
bootfile bootfile path No None Specifies the bootfile to use in the file section of the response packet. This can be specified at any container level. The bootfile policy defines how items specified in the file section of the incoming packet interact with the bootfile and the home directory statements.
pxebootfile pxebootfile System Arch MajorVer MinorVer Bootfilename No None Specifies the bootfile to be given to a client. The config file parser generates an error if the number of parameters after the keyword is less than 4 and ignore if more than 4. This keyword can be used only in a container.

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

[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]