Setting a host lease time via OMAPI

Julien Semaan jsemaan at inverse.ca
Fri Mar 4 16:30:59 UTC 2016


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 <jsemaan at inverse.ca> 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
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users



More information about the dhcp-users mailing list