Using Option 82 To Differentiate IP Ranges within Same Subnet

[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,

*Pamuditha Abeysekara*

Telecom Network Engineer

T: (+94) 766 -243- 938 <+94%2076%20994%204524> Skype :
malith.pamuditha.abeysekara

No 36, Bristol Street, Colombo 01, Sri Lanka

*www.n-able.biz <http://www.n-able.biz/>*



On Thu, Aug 23, 2018 at 11:05 PM, Simon Hobson <dhcp1 at thehobsons.co.uk>
wrote:

> 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.
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180824/28413a7d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C2CB6F94-C68B-4220-AD17-94F8DD88C751[17].png
Type: image/png
Size: 6493 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20180824/28413a7d/attachment-0001.png>