Extending the Design and Requirements

I mentioned "support for DHCP" as a requirement in the previous chapter, but what do we really want from it? Let's take a look at how DHCP is used in a typical organization. I will assume the ISC DHCP service, which is widely available with most Linux distributions.

When assigning addresses on a subnet, we have the following options:

• Assign the IP addresses statically, in which case we configure each device with its own IP address.

• Assign the IP addresses dynamically, depending on a set of rules using the DHCP service.

■Tip Before proceeding with this chapter, you may want to install the ISC DHCP server package. You can do that by using the package manager available with your Linux distribution (on Red Hat Linux it can be done with the command yum install dhcp). Alternatively, you can download it from the official ISC DHCP website at http://www.isc.org/software/dhcp.

Let's quickly recap what the DHCP can do and how it is configured. The ISC DHCP allows us to define very complicated sets of rules. The simplest set would contain no rule at all, in which case any request for an IP would be granted and a unique address from available pool would be assigned, assuming there are free IPs available in the address pool.

One rule commonly used is to assign IP addresses depending on a hardware MAC address. This method allows you to assign the same IP address always to the same machine, but does not require it to be configured locally on the server. We can use the DHCP group directive to configure such a host:

group {

host host001 {

hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.0.1;

A more advanced use of client grouping is DHCP client class separation, where clients are grouped into classes that satisfy some criteria. The ISC DHCP server provides many options for such separation. For example, you can use various DHCP request fields (or even parts of them) to group the nodes—such as using part of the DHCP hostname to identify what is sending the request. You can see what DHCP options are available by reading the UNIX manual page for dhcp-options. The following example uses the DHCP option vendor-class-identifier to group all Sun Ultra 5 machines into one class:

class "sun-ultra-5" {

match if option vendor-class-identifier "SUNW.Ultra-5_10";

For a second example, this code matches the beginning of a DHCP hostname and puts into a separate class if it starts with "server":

class "server" {

match if substring (option hostname, 0, 6) = "server";

For the sake of simplicity, let's assume that all subnets are on the same physical network on the DHCP server, which means we will be using the shared-network directive when defining new subnets.

As you can see, the simple process of investigation is gradually evolving into making certain design decisions. This blurring of tasks should be avoided whenever possible, and I've demonstrated it here just to show how easy is to get carried away and amend your design to accommodate limitations (or features) of any particular product.

So first of all, let's ignore everything we know about the particular DHCP server product and list all the things we want it to do. Our imaginary organization has multiple networks that are subdivided into smaller subnets, which in turn can contain even smaller subnets. Usually, if a subnet is subdivided into smaller networks, it rarely contains IP addresses for physical (or virtual) hosts. The only IPs that will be present in such a network are IP addresses of the networking devices, such as routers, switches, and load balancers—none of which get their IPs from DHCP. Therefore, we will only create DHCP-managed subnets that are right at the bottom of the subnet tree and are not subdivided into smaller networks.

Within the DHCP-managed network, we want to have the following:

• Statically assigned addresses that are completely out of DHCP server control. In other words, the DHCP server should have no knowledge about that range and should not be configured to offer any address from that range. Each IP address is configured manually on the device that uses it.

• Static addresses assigned by the DHCP server. For example, we want IP addresses to be offered depending on the requestor's MAC address.

• IP addresses assigned depending on properties of the client, such as hardware vendor, DHCP parameter values, and so on. Since we do know how many of these IPs we will need, we have to be able to assign a predefined range of addresses. We also don't want to be limited to just a set of DHCP options; we should have full control over all available options.

• IP addresses assigned to all other clients. As in the previous requirement, we need to be able to specify a range of IPs to use here.

As you can see, the listed requirements are very similar to the ones set out earlier, but they do not contain any references to any particular implementation. This approach has two major advantages: you are free to choose any product you think is the best fit for the purpose, and you can outsource implementation to other teams. As long as the result satisfies the requirements, we don't really care about technical implementation details. Also, having this list in hand helps you quickly identify and select the appropriate product.

In addition to the network management and IP allocation requirements, we have some operational ones:

• We need the configuration to be generated, but not immediately applied, so it can be reviewed and changes applied manually.

• We do not require manual changes made to the configuration file to be propagated back to the application database. For example, if we manually add a few hosts into the DHCP configuration, we do not need the application to update the database entries accordingly.

• At this stage we do not want the application to control the DHCP service; this will be done manually using standard OS commands.

Now that we have identified what is required, we can start making basic design decisions:

• We will use ISC DHCP, because it allows us to implement all listed requirements.

• We will use the same web application framework and language, because this project is an extension of another project.

• The configuration file will be generated by the same web application (that is, there are no external tools that read from the database and generate a configuration file).

Just as in the previous example, we now need to do two things: define the extended data model and create an application workflow.

Was this article helpful?

0 0

Post a comment