System Management Guide: Communications and Networks

Boot Image Negotiation Layer Daemon (BINLD)

The Boot Image Image Negotiation Layer daemon (BINLD) server is the third stage of contact for preboot execution environment (PXE) clients. After communicating with the DHCP server to obtain an IP address, and after communication with the PXE Proxy DHCP server to obtain the location of the boot server, the boot server is contacted to get the filename and location from which to download the boot image. The PXE client can return to communicate with the boot server multiple times in the course of booting if the client requires multiple files in its boot process.

The final stage in the PXE network boot is to download the boot image given by the boot server. The location of the TFTP server and the filename that is to be downloaded is given by the boot server to the PXE client.

The BINLD Server

Beginning with AIX 4.3.3 update, the BINLD 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 BINLD Database

The db_file.dhcpo database is used to generate the options that respond to a client's REQUEST packet. The options returned by the database depend on the type of server chosen. Options are set using the keyword pxeservertype in the binld.cnf file.

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

The BINLD Protocol Engine

The PXED protocol engine is based on the 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.

BINLD Threaded Operations

The last piece of the BINLD server is actually a set of operations that are used to keep things running. Since the BINLD 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 to port 4011. Each can handle a request from a client.

Configuring BINLD

By default, the BINLD server is configured by reading the /etc/binld.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 BINLD server is usually the hardest part of using BINLD in your network. First, figure out what networks you need to have PXE clients on. The following example configures a BINLD server to run on the same machine as the DHCP server:

pxeservertype       binld_on_dhcp_server

subnet default
{
    vendor pxe
    {
                bootstrapserver  9.3.149.6      #TFTP server IP address
                pxebootfile   1   2   1   window.one   1   0
                pxebootfile   2   2   1   linux.one    2   3
                pxebootfile   1   2   1   hello.one    3   4
                client 6 10005a8ad14d any
                {
                   pxebootfile   1   2   1   aix.one     5   6
                   pxebootfile   2   2   1   window.one  6   7
        }
     }
}

Given the above configuration, the BINLD server listens for client's unicast packets on port 4011 and Multicast packets on port 4011 if BINLD gets the Multicast Address from the dhcpsd/pxed. The BINLD server responds to client REQUEST/INFORM packets with the bootfile name and TFTP server's IP address. If BINLD does not find the bootfile with a matching Layer specified by the client, then it tries to find a bootfile for the next layer. The BINLD does not respond when there is no boot file that matches the client requirements (Type, SystemArch, MajorVers, MinorVers, and Layer).

The following example configures BINLD to run on a separate machine (that is, DHCP / PXED is not running on the same machine).

subnet 9.3.149.0 255.255.255.0
{

     vendor pxe
     {

     bootstrapserver        9.3.149.6      # TFTP server ip address.
     pxebootfile    1    2    1   window.one    1   0
     pxebootfile    2    2    1   linux.one     2   3
     pxebootfile    1    2    1   hello.one     3   4
     client 6 10005a8ad14d any
       {
       pxebootfile    1    2    1   aix.one      5   6
       pxebootfile    2    2    1   window.one   6   7
       }
     }
}

In the above example, the pxeservertype is not set, so the default servertype is binld_only. The BINLD server listens for client's unicast packets on port 4011, broadcast & unicast packets on port 67, and Multicast packets on port 4011 if BINLD gets the Multicast Address from the dhcpsd/pxed. The bootfile name and TFTP server IP address is sent to a PXE client only if the client's IP address is in the subnet's IP address range (9.3.149.0 through 9.3.149.255).

The following example configures BINLD to run on the same machine as the PXED server:

pxeservertype       binld_on_proxy_server
subnet default
{
     vendor
     {
     bootstrapserver        9.3.149.6          # TFTP server ip address.
     pxebootfile    1    2    1   window.one    1    0
     pxebootfile    2    2    1   linux.one     2    3
     pxebootfile    1    2    1   hello.one     3    4
     client 6 10005a8ad14d any
       {
       pxebootfile    1    2    1   aix.one     5   6
       pxebootfile    2    2    1   window.one  6   7
       }
     }
}

In this configuraton, the BINLD server only listens on port 4011 for Multicast packets only if BINLD gets Multicast address from the dhcpsd/pxed. If it does not receive any multicast address, then BINLD exits and an error message is logged to the log file.

The database db_file 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. PXE Vendor Container Suboptions describes the currently supported and known suboptions. See BINLD 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 PXED 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 matches, including regular expression matching.

There is also an implicit container, the global container. Options and modifiers placed 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 may or may 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 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 may 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 may 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.

BINLD 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.

BINLD 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 keyword 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 and PXE Vendor Container Suboptions.