The Weird Solutions DHCP server is really flexible. The documentation leaves a lot to be desired, however, so it can be daunting to configure until you understand the basics of what it’s doing.
When you define a pool in the DHCP server, you always have to state the relay agent address associated with the pool. This will sometimes be the same address as the default gateway, but it doesn’t have to be if the relay agent has multiple IP addresses on its southbound interface. If there is no DHCP relay agent between the client and server, the relay agent address will be 0.0.0.0 (or :: for IPv6).
(If you enable debug logging, the server will tell you what relay agent address is being received with the device’s DHCP request)
Now suppose you want create two pools spanning two different subnets, but they both have the same relay agent address. How can you tell the DHCP server that one device should use one pool, but another device should use the other pool?
This is what we refer to as address provisioning. It’s a way of going beyond the standard checks to decide which pool a device should use. The standard checks are the basics, such as “Will this pool work on that segment?” Or “Is this pool currently enabled?”
The trick to address provisioning is to define a domain, and then put the pool and the device in that domain. The DHCP server checks to see what domains a device belongs to every time the device requests service, so if the device does not belong to the same domain as the pool, it won’t be able to use that pool.
By default, pools belong to the “All devices” domain, and so do… all devices. So everything just works out of the box. What we want, however, is to differentiate two devices, only allowing them to use specific pools, even if other pools would be considered acceptable for the device.
So let’s take an example (we assume this is a new installation, or at least not a production installation!):
Step 1: Delete the default rules (listedn under “Rules” in the GUI)
Step 2: Delete all device accounts (listed under “Devices” in the GUI)
Step 3: Create two new domains. Let’s call them “Domain A” and “Domain B”
Step 4: Create the two pools. Under “Permissions”, remove the “All devices” domain. For one pool add “Domain A”, and for the other add “Domain B”.
At this point you have two pools configured, both with the same relay agent address. One pool belongs to “Domain A” only, and the other pool belongs to “Domain B” only. So far so good.
Now, how do we tell the server that one device belongs to “Domain A”, and another device belongs to “Domain B”? There are a couple of ways to do this:
1. Create a device account for the device and make it a member of “Domain A” or “Domain B” (select the device account, choose the “Permissions” tab on the right, under “Devices”). This method requires that you type in the DHCP client id for each device. It also makes the device a member of that domain permanently.
2. The other approach is to create a rule that tells the DHCP server how to classify devices that request access. Using this method, you can also decide if you want the DHCP server to execute the rule just once, and automatically create the account for you (like the one above), or execute the rule each time the device requests service, never creating an account.
Let’s choose method two (2). In order to write a rule, we need to be able to identify something in the DHCP request that tells us what kind of device it is, or where on the network it is. Basically, we need to be able to extract something from the input packet that the server can then use to assign the device to its domain.
For this scenario we’ll use the option 82 circuit id. Lets say that we want all devices with circuit id ’01-22′ to belong to “Domain A”. And all devices with circuit id ’01-33′ should belong to “Domain B”.
We write two rules. The first rule is:
Condition: [ $RELAY.CID() == ’01-22′ ]
Result: [ “Domain A” ]
Persist: False
The second rule is:
Condition: [ $RELAY.CID() == ’01-33′ ]
Result: [ “Domain B” ]
Persist: False
Save it all and fire everything up. You should notice that devices on circuit 01-22 are only using Pool A, and devices on circuit 01-33 are only using Pool B!
A note about the “Persist” setting in a rule:
If any matching rule has “Persist” set to ‘true’, the DHCP server will gather domain results from all matching rules, create a new account for this device, and give that account access to the domains.
In this scenario, the next time the device requests service no rules are executed, because the device has an account, and that account tells the server exactly what domains the device belongs to.
This can be really useful or very aggravating depending on what you’re trying to do. For the scenario above, you should never tell the server to create device accounts. What would happen if a device moved from circuit 01-22 to circuit 01-33? The server wouldn’t care; it would find the original account, which states that the device belongs to “Domain A”, and it would use that info. So consider your use cases carefully. If you want the server to find and lock devices into domains, have the rules persist. If you want the server to allow devices to switch domains depending on where they connect, don’t have the rules persist.