Using Option 82 To Differentiate IP Ranges within Same Subnet

[Pamuditha Abeysekara]

Hi All, 

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? 

Regards,

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Pamuditha Abeysekara <[hidden email]> 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.


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Pamuditha Abeysekara]

Hi Simon, 

Thanks a lot for the explanatory response.

The reason behind this is to separate multiple routable network segments, I have to create different VLANs which is operationally difficult to manage. 

In this case do I have something similar to else statement. If all the if statements failed can I define default IP pool to issue client IPs. ? 

Regards,

On Thu, Aug 23, 2018 at 11:05 PM, Simon Hobson <[hidden email]> wrote:

Pamuditha Abeysekara <[hidden email]> 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.


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Pamuditha Abeysekara <[hidden email]> wrote:

> The reason behind this is to separate multiple routable network segments, I have to create different VLANs which is operationally difficult to manage.

I would strongly suggest you take another look at that - because what you are proposing won't be easy to administer either (especially when it goes wrong !) What sort of network is it ?
One issue you'll find is having an enormous broadcast domain - so in principle any device will be capable of sending a broadcast packet to every other device. The prevent that you'll have to put in place L2 filtering - but that would also break neighbour discovery and so you'd need to add ARP proxying to fix the breakage that the broadcast filtering causes.
And presumably you'll also have to have L2 filtering (alongside DHCP snooping) to prevent devices (I'm guessing that this is a public access network) spoofing another address. If this fails then the scope for spoofing is network wide - whilst in a routed network it's restricted to a single subnet.

> In this case do I have something similar to else statement. If all the if statements failed can I define default IP pool to issue client IPs. ?

AFAIK there is no "match if the client isn't in any other class" type of construct, so you can't have a pool with 'allow members of "everything else"'. What you'd need to do is have a pool for "everything else", with something like :

pool {
  deny members of "clients1";
  deny members of "clients2";
  ...
  deny members of "clientsnnn";
  range ...
}

So plenty of scope for mistakes to creep in there - anything not listed in a deny statement will be allowed. You'll probably have to machine generate the config, and by the time you've done that, you may find it's as much work as building a proper network.

Plus, if something isn't working properly, then all you'll see in the logs is "no free leases" which really means "I have no lease that the config allows me to offer to this client". You then start having to figure out what class the client should match to, and then why it's not matching - good luck !

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users