When the DHCP server receives a request, the packet is parsed and identifying keys determine which containers, options, and addresses are extracted.
The example in PXED server 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
giaddrfield 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
chaddrfield 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
Accountingcannot 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
2. There is one class name,
Class 1, one vendor
Vendor 1, and one client name,
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
Subnet 1 with
Class 1 specified in
its option list, the DHCP server would generate the following container
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
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),
1 (at the
Class 1 level)
Subnet 2 is listed first, then
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
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
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.