BINLD containers

Edit online

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

The last example in BINLD configuration 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.