Setting a host lease time via OMAPI

[Julien Semaan]

Hello all,

I am an engineer part of the PacketFence (http://packetfence.org/) team which already actively uses the ISC DHCP server.

Due to the nature of our product, we need to have a lease time of 30 seconds in our DHCP scopes.

What we would like to do, is to be able to make this lease time higher for specific hosts dynamically without restarting the DHCP server.

We already integrate with the OMAPI to get the current lease for a MAC address, so I thought I would give it a shot for this also.

When I try to create the host with the default-lease-time and max-lease-time attributes, it throws an error : can't open object: unknown attribute

Now, is it me not using the right names when setting the variables or is it that what I am trying to do is impossible ?

Here is a pastebin of my omshell session : http://pastebin.com/rbkdPqCP

If it is not possible to do this via the OMAPI, is there an alternate way to accomplish what we want to do ?

Thanks !



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

[Simon Hobson]

Julien Semaan <[hidden email]> wrote:

> Due to the nature of our product, we need to have a lease time of 30 seconds in our DHCP scopes.
>
> What we would like to do, is to be able to make this lease time higher for specific hosts dynamically without restarting the DHCP server.

Will that help ?
The client will still come back to renew according to the lease length it was originally given, and won't the new lease it's given get reset to the current default lease time configured - or a length requested by the client, and subject to max and min limits ?

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

[Julien Semaan]

Hi Simon,

Thanks for taking the time to answer.

Now, the goal of this is not to affect the current lease but to affect
future leases.

Maybe a bit of context will help.

We have a network which is used for captive portal registration, when
you are done registering, you leave this network (through a VLAN change).
The lease time is set to 30 seconds so that the device tries to renew
its IP in the new network fast (and then fail, and get the proper IP)

Now, some devices connect to the network and stay there for days, months
without doing anything else than getting DHCP and without trying to
register.
We would like these devices to have a lease length that is higher than
the other ones so that it reduces the load on the DHCP server.

This above is determined at runtime since the detection occurs after the
DHCP server has started, thus the need for it to occur dynamically
through the OMAPI or another mean.

Regards,

- Julien

On 16-03-03 04:33 PM, Simon Hobson wrote:

> Julien Semaan <[hidden email]> wrote:
>
>> Due to the nature of our product, we need to have a lease time of 30 seconds in our DHCP scopes.
>>
>> What we would like to do, is to be able to make this lease time higher for specific hosts dynamically without restarting the DHCP server.
> Will that help ?
> The client will still come back to renew according to the lease length it was originally given, and won't the new lease it's given get reset to the current default lease time configured - or a length requested by the client, and subject to max and min limits ?
>
> _______________________________________________
> 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]

Julien <[hidden email]> wrote:

> Now, the goal of this is not to affect the current lease but to affect future leases.

I guessed that

> Maybe a bit of context will help.
>
> We have a network which is used for captive portal registration, when you are done registering, you leave this network (through a VLAN change).
> The lease time is set to 30 seconds so that the device tries to renew its IP in the new network fast (and then fail, and get the proper IP)
>
> Now, some devices connect to the network and stay there for days, months without doing anything else than getting DHCP and without trying to register.
> We would like these devices to have a lease length that is higher than the other ones so that it reduces the load on the DHCP server.
>
> This above is determined at runtime since the detection occurs after the DHCP server has started, thus the need for it to occur dynamically through the OMAPI or another mean.

As I wrote, I'm not sure that this will help. I'd suggest setting up a test lab and try it - my feeling is that when a client renews, the lease length it's given will depend on the rules for assigning lease lengths, not the length of it's current lease. So when you've lengthened a lease, the client renews, the longer lease is "forgotten about" and a replacement is done for 30s again.

Could you use classes instead. Assign these devices to a specific class (via OMAPI) and configure that class to have longer leases ?
Or perhaps re-assign the client to a "never never land" VLAN with different lease length rules (but still stuck behind the registration portal) ?

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

[Julien Semaan]

Just re-tested in lab the principle behind it using the configuration,
so without the OMAPI :
   host testing {
     hardware ethernet 00:11:22:33:44:55;
     default-lease-time 30;
     max-lease-time 30;
   }

The device effectively gets a 30 seconds lease.

The switching the configuration to :
   host testing {
     hardware ethernet 00:11:22:33:44:55;
     default-lease-time 300;
     max-lease-time 300;
   }

Makes it that when the device renews, it gets a 5 minute lease.

I will try out the class approach you defined and report if it works.
I may need help for that too, but I'll at least start by giving it a try.

As for your idea of placing people in another VLAN with a different pool
configuration, this is how we do it currently but this has the downside
of creating extra work, especially when doing it after the initial
deployment phase of the NAC solution.

Thanks !

On 03/04/2016 02:50 AM, Simon Hobson wrote:

> Julien <[hidden email]> wrote:
>
>> Now, the goal of this is not to affect the current lease but to affect future leases.
> I guessed that
>
>> Maybe a bit of context will help.
>>
>> We have a network which is used for captive portal registration, when you are done registering, you leave this network (through a VLAN change).
>> The lease time is set to 30 seconds so that the device tries to renew its IP in the new network fast (and then fail, and get the proper IP)
>>
>> Now, some devices connect to the network and stay there for days, months without doing anything else than getting DHCP and without trying to register.
>> We would like these devices to have a lease length that is higher than the other ones so that it reduces the load on the DHCP server.
>>
>> This above is determined at runtime since the detection occurs after the DHCP server has started, thus the need for it to occur dynamically through the OMAPI or another mean.
> As I wrote, I'm not sure that this will help. I'd suggest setting up a test lab and try it - my feeling is that when a client renews, the lease length it's given will depend on the rules for assigning lease lengths, not the length of it's current lease. So when you've lengthened a lease, the client renews, the longer lease is "forgotten about" and a replacement is done for 30s again.
>
> Could you use classes instead. Assign these devices to a specific class (via OMAPI) and configure that class to have longer leases ?
> Or perhaps re-assign the client to a "never never land" VLAN with different lease length rules (but still stuck behind the registration portal) ?
>
> _______________________________________________
> 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

[Julien Semaan]

As an update,

The idea provided by Simon works correctly.

I created a group in the configuration :
group parking {
   default-lease-time 3600;
   max-lease-time 3600;
}

And then via the OMAPI, I create host entries based on the MAC that set
the group to parking :
obj: host
name = "some-host"
hardware-address = 94:db:c9:38:85:5b
hardware-type = 00:00:00:01
group = "parking"

The devices then get a 1 hour lease.

Thanks a lot for your help.

- Julien

On 03/04/2016 09:36 AM, Julien Semaan wrote:

> Just re-tested in lab the principle behind it using the configuration,
> so without the OMAPI :
>   host testing {
>     hardware ethernet 00:11:22:33:44:55;
>     default-lease-time 30;
>     max-lease-time 30;
>   }
>
> The device effectively gets a 30 seconds lease.
>
> The switching the configuration to :
>   host testing {
>     hardware ethernet 00:11:22:33:44:55;
>     default-lease-time 300;
>     max-lease-time 300;
>   }
>
> Makes it that when the device renews, it gets a 5 minute lease.
>
> I will try out the class approach you defined and report if it works.
> I may need help for that too, but I'll at least start by giving it a try.
>
> As for your idea of placing people in another VLAN with a different
> pool configuration, this is how we do it currently but this has the
> downside of creating extra work, especially when doing it after the
> initial deployment phase of the NAC solution.
>
> Thanks !
>
> On 03/04/2016 02:50 AM, Simon Hobson wrote:
>> Julien <[hidden email]> wrote:
>>
>>> Now, the goal of this is not to affect the current lease but to
>>> affect future leases.
>> I guessed that
>>
>>> Maybe a bit of context will help.
>>>
>>> We have a network which is used for captive portal registration,
>>> when you are done registering, you leave this network (through a
>>> VLAN change).
>>> The lease time is set to 30 seconds so that the device tries to
>>> renew its IP in the new network fast (and then fail, and get the
>>> proper IP)
>>>
>>> Now, some devices connect to the network and stay there for days,
>>> months without doing anything else than getting DHCP and without
>>> trying to register.
>>> We would like these devices to have a lease length that is higher
>>> than the other ones so that it reduces the load on the DHCP server.
>>>
>>> This above is determined at runtime since the detection occurs after
>>> the DHCP server has started, thus the need for it to occur
>>> dynamically through the OMAPI or another mean.
>> As I wrote, I'm not sure that this will help. I'd suggest setting up
>> a test lab and try it - my feeling is that when a client renews, the
>> lease length it's given will depend on the rules for assigning lease
>> lengths, not the length of it's current lease. So when you've
>> lengthened a lease, the client renews, the longer lease is "forgotten
>> about" and a replacement is done for 30s again.
>>
>> Could you use classes instead. Assign these devices to a specific
>> class (via OMAPI) and configure that class to have longer leases ?
>> Or perhaps re-assign the client to a "never never land" VLAN with
>> different lease length rules (but still stuck behind the registration
>> portal) ?
>>
>> _______________________________________________
>> 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

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