Using Option 82 To Differentiate IP Ranges within Same Subnet

[Simon Hobson]

Pamuditha Abeysekara <pamuditha at n-able.biz> wrote:

> I am planning to use one Large IP subnet and segregate it to multiple IP pools (IP ranges) by matching string in the OPTION 82 and using IF MATCH statements
> 
> I am planning to use around 150 string matches and separate IP ranges. Will it be feasible? 

Is there a specific reason for doing it this way rather than splitting the network into separate routed segments ? While you can do it the way you want, the server will have to evaluate all the match statements for every request - a significant load with a lot of clients.

I assume you were planning to use constructs like :

class clients1 {
  match if ...
}

pool {
  allow members of "clients1";
  range ...
}

I believe this will work, with the extra load as mentioned above. However, from reading this list there **may** be an issue depending on the capabilities of your switches etc. AAUI (from comments made on this list), Option-82 isn't saved in the leases file, which means that if it's not been added to the packet then the server can't match it. Why can this happen, and why does it matter ?

Well, clients that are renewing a current lease will use unicast to contact the DHCP server. If the DHCP snooping in the switches (or APs, or whatever is adding Option 82) doesn't catch these then the packets won't get tagged.
If the sevrer gets a packet without Option-82 added, then it can't match it to the appropriate class and pool - so the client won't be able to renew the least properly.

On checking, there is a config  option to work around this issue :

> stash-agent-options flag;
> If the stash-agent-options parameter is true for a given client, the server will record the relay agent information options sent during the client’s initial DHCPREQUEST message when the client was in the SELECTING state and behave as if those options are included in all subsequent DHCPREQUEST messages sent in the RENEWING state. This works around a problem with relay agent information options, which is that they usually not appear in DHCPREQUEST messages sent by the client in the RENEWING state, because such messages are unicast directly to the server and not sent through a relay agent.