Overview: DHCP

Overview

A DHCP client consists of a network interface and a DHCP client program. The client negotiates with a DHCP server to acquire an IP address. Every network interface has a unique MAC address, which the server uses to identify and keep track of the client.

dhcpd configuration files

A dhcpd configuration file describes network topology and tells the server whether and how to assign an IP address to each client. It also specifies DHCP options to send to particular clients when they request an address; these options can help clients that lack persistent storage to configure themselves. For instance, Avaya VoIP phones need to be told which VLAN to operate on.

A dhcpd configuration file consists of parameters and declarations. A parameter instructs the server to behave in a certain way. For instance, the option parameter specifies information that will be sent to each client to which the parameter applies. A declaration can contain parameters and other declarations, and is generally used for grouping things. Parameters in a parent declaration apply to all of the child declarations.

A subnet or subnet6 declaration describes a subnet with a particular network address and netmask. subnet means the network is IPv4, and subnet6 means it's IPv6. A subnet or subnet6 corresponds to a Cyder network.

A pool declaration describes a pool of IP addresses that the server can assign to clients. allow and deny statements may be used to white- or blacklist particular sets of clients. A pool corresponds to a Cyder dynamic range.

A class declaration defines a set of clients. Clients can be included in a class in a variety of ways. A class can be allowed in or excluded from a pool using an allow or deny parameter in that pool. Cyder specifies class members by their MAC addresses. The relationship between Cyder objects and DHCP classes is complex; see the section "Cyder and DHCP" below for details.

A group declaration is just a container for declarations and statements. Cyder uses groups to apply DHCP parameters to sets of hosts. A group corresponds to a Cyder workgroup.

A host declaration describes a client, uniquely identifying it and optionally specifying DHCP options to pass to it whenever it requests an IP. If a client doesn't need a static IP address and doesn't need the server to send it any special DHCP options, it does not require a host declaration — the client can still be included in classes and those classes can be allowed in pools. A host corresponds to a Cyder static or dynamic interface.

Cyder and DHCP

Certain Cyder objects correspond directly or indirectly to DHCP configuration declarations or parameters. When dhcp_build is run, those objects are built into a config file. (At OSU, this file is named dhcpd.conf.data and is included into the main config file, dhcpd.conf, along with other files that aren't built by Cyder.)

Some objects have a dhcp_enabled field. If it's false, the object is omitted from the configuration file.

Certain DHCP parameters are automatically inserted into particular declarations. However, many Cyder objects that correspond to DHCP declarations allow a user to specify custom parameters via EAV objects. In Cyder terminology, an "option" is a DHCP parameter that specifies a DHCP option to send to clients to which it applies; a "statement" is a parameter that is not an "option".

Sample DHCP configuration file

Here's a sample DHCP config that Cyder might build:

class "foo:10.0.0.2:10.0.0.254" {
        match hardware;
}
subclass "foo:10.0.0.2:10.0.0.254" 1:bb:bb:bb:bb:bb:bb;
subclass "foo:10.0.0.2:10.0.0.254" 1:cc:cc:cc:cc:cc:cc;
subnet 10.0.0.0 netmask 255.255.255.0 {
        option routers 10.0.0.1;
        pool {
                range 10.0.0.2 10.0.0.254;
                allow members of "orst:10.0.0.2:10.0.0.254";
        }
}
group { #bar
        option time-servers time.example.com;
        host glub1.example.com {
                hardware ethernet bb:bb:bb:bb:bb:bb;
        }
        host glub2.example.com {
                hardware ethernet cc:cc:cc:cc:cc:cc;
        }
}

TODO: Explain

Interfaces

A Cyder interface is built into a host declaration that specifies the interface's hostname. It contains a hardware ethernet parameter specifying its MAC address. If the interface is static, the declaration also contains a fixed-address parameter specifying the interface's IP address.

Networks

A Cyder network is built into a subnet or subnet6 declaration that specifies its address and netmask. The subnet contains the following things:

• parameters built from the network's "option" and "statement" NetworkAV objects
• pools built from the network's ranges; each contains the following things:
  • a range or range6 parameter built from the range's start and end addresses
  • a set of allow or deny parameters built based on the range's allow field
    • TODO: Explain how
  • the parameter allow members of "VoIP" if the range's allow_voip_phones field is true
  • parameters built from the range's RangeAV objects whose attribute type is "option" or "statement"

Workgroups

A Cyder workgroup is built into a group. A comment after the opening brace specifies the workgroup's name. (It has no syntactic importance but is useful for humans and helps dhcp_compare and dhcp_compare2 compare DHCP configs.) The group contains the following things:

• parameters built from the workgroup's WorkgroupAV objects
• hosts built from the workgroup's static and dynamic interfaces; each is identified by a hostname and contains the following things:
  • a hardware ethernet parameter built from the MAC address of the interface
  • for a static interface, a fixed-address parameter built from the IP address of the interface

VRFs

A Cyder VRF is built into a class with the same name as the VRF; the class is accompanied by subclass parameters that cause the class to match any enabled interface in a range in a network in that VRF.

Old summary (possibly out of date)

Scopes:

• DHCP options are assigned in this order: global, subnet, workgroup, host
• there are more scopes, but we don't use them
• each scope either adds options or replaces the ones already assigned (e.g. a workgroup option can override a global option)
• for us, global options are things like nameserver
• subnet options are typically the gateway and mask
• global and subnet are NOT configurable by container admins
• so, we allow them to override by assigning a registration (mac/ip combo) to a workgroup, where they can set custom options
• use cases include things like voip phones and hosts doing PXE/wake-on-lan
• maintain also had host options but it was never heavily used, mainly because of a bug where host options generally did not work
• we can leave host options out of Cyder - i.e. all custom options that a container admin wants would then have to be in a workgroup

Classing:

• we use classes to allow hosts to get dynamic addresses in pools
• VRFs will be equivalent to classes
• in the legacy core network, we create a class for every range/container mapping and then assign those range/container classes to pools with allow statements
• in Cyder, we still need to have that legacy method BUT
• we can simply create a class for each range, and put every mac address that is assigned to that range in it, regardless of the container it lives in
• then we also need to support the MPLS/VRF way, which is: create a class for each VRF
• and in pools (ranges) configured to "allow members of VRF" simply have an allow line that allows the members of the appropriate VRF
• that implies that we will have a place where we say which VRF a range is associated with - and I think we agreed to do that via networks - i.e., a range lives in a network, and a network is assigned to one and only one VRF (but a VRF can contain many networks)