Darren,
I take that back (partially)...
At least one of
"client-classes": [
{
"name": "long-lease",
"valid-lifetime": 604800
},
{
"name": "short-lease",
"test": "member('KNOWN') and not member('long-lease')"
}
],
... Is still needed to define the alternate lease time. Although I could be
explicit:
"client-classes": [
{
"name": "long-lease",
"valid-lifetime": 604800
},
{
"name": "short-lease",
"valid-lifetime": 300
"test": "member('KNOWN') and not member('long-lease')"
}
],
I do wonder if I can leave the test condition out of short-lease, again because
I define who gets a short-lease and a long-lease explicitly.
Jason.
________________________________
From: Kea-users <kea-users-boun...@lists.isc.org> on behalf of Jason Keltz
<j...@yorku.ca>
Sent: Friday, April 5, 2024 3:49 PM
To: Kea user's list <kea-users@lists.isc.org>
Subject: Re: [Kea-users] different lease times
Hi Darren,
Thanks. I have this working now! Excellent...
Since each host defines a mac address, and whether it's in short-lease or
long-lease, then is this:
"client-classes": [
{
"name": "long-lease",
"valid-lifetime": 604800
},
{
"name": "short-lease",
"test": "member('KNOWN') and not member('long-lease')"
}
],
Still needed?
Each reservation includes a mac address and :
"client-classes": [ "long-lease"] or
"client-classes": [ "short-lease"]
Is that not enough to build the client classes for long-lease and short-lease?
The definitions at the top include everyone by default, but I don't want them
to include everyone..
Jason.
________________________________
From: Kea-users <kea-users-boun...@lists.isc.org> on behalf of Darren Ankney
<darren.ank...@gmail.com>
Sent: Friday, April 5, 2024 3:31 PM
To: Kea user's list <kea-users@lists.isc.org>
Subject: Re: [Kea-users] different lease times
Hi Jason,
Here you go. Not 100% sure it will work, however. Decided to make
the default lease 300 and set the long lease time in the class that
reserved clients are added to. Also note that I moved the reservation
inside the subnet. This was to avoid any situation where you might
need to use "early-global-reservations-lookup" to make things work
properly.
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"calculate-tee-times": true,
"option-data": [
{
"name": "domain-name-servers",
"data": "10.0.0.1"
}
],
"valid-lifetime": 300,
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100-10.1.2.200",
"client-class": "short-lease"
}
],
"reservations": [
{
"hw-address": "00:00:00:11:11:11",
"ip-address": "10.1.2.12",
"client-classes": [
"long-lease"
]
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "DEBUG",
"debuglevel": 99,
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
Thank you,
Darren Ankney
On Fri, Apr 5, 2024 at 2:17 PM Jason Keltz <j...@yorku.ca> wrote:
>
> Hi Darren,
>
> I tries this, but no success. When I restart kea it complains that the class
> long-lease doesn't exist. You defined short-lease as being known and not in
> long-lease, but how do you define long-lease?
>
> In the actual reservations, I tried both defining client-class of long-lease,
> and when the failed, I tried client-classes of long-lease, but kea still
> wants long-lease defined.
>
> The format of my configuration with reservations (in "pseudo-code")
>
> subnet4--
> define subnet id 1
> define pool for subnet id 1
> include subnet id 1 reservations file - these reservations all define
> ip-address
>
> define subnet id 2
> define pool for subnet id 2
> include subnet id 2 reservations file - these reservations all define
> ip-address
> ...
>
> Include global reservations file (reservations specifying hw-address,
> hostname, and some option-data for each host) - no ip
>
> The goal is: hosts that get an IP from any pool have a shorter lease time,
> and hosts that have an ip-address reserved for them get a much longer lease
> time
>
> Jason.
>
> ________________________________
> From: Kea-users <kea-users-boun...@lists.isc.org> on behalf of Darren Ankney
> <darren.ank...@gmail.com>
> Sent: Friday, April 5, 2024 5:53 AM
> To: Kea user's list <kea-users@lists.isc.org>
> Subject: Re: [Kea-users] different lease times
>
> Hi Jason,
>
> Ahh yes. I failed to remember the goal here. All clients would be in
> that class. I assume you have reservations for these static clients?
> You could, in these reservations add them to another class
> ("long-lease"). Then you could alter the test line in short lease:
>
> "test": "member('KNOWN') and not member('long-lease')",
>
> I'm not entirely sure that will work. It depends on where your
> reservations are set. You may have to experiment with:
> "early-global-reservations-lookup"
>
> FYI, if you'd like to see a change to "valid-lifetime" (such as
> allowing use inside a pool), then you could add a comment indicating
> your support of: https://gitlab.isc.org/isc-projects/kea/-/issues/953
> Be sure and describe, in detail, your use case for this change.
>
> Thank you,
> Darren Ankney
>
> On Thu, Apr 4, 2024 at 12:33 PM Jason Keltz <j...@yorku.ca> wrote:
> >
> > Hi Darren,
> >
> > I tried your suggestion, but unfortunately, it didn't quite work.
> > I modified my kea configuration as you specified. My default
> > valid-lifetime is 4000.
> > In short-lease, I defined valid-lifetime to be 300 (exactly as yours is
> > specified).
> > In the pool used by my test host, I added the client-class for
> > short-lease as you specified.
> > I restarted kea dhcp server to ensure it re-read the configuration.
> > I checked for any existing lease from my test host "jastest", and there
> > was none.
> > I booted...
> > The lease was registered, and was for 300 seconds...
> >
> > [ { "arguments": { "leases": [ { "client-id": "01:ac:24:11:5f:be:b7",
> > "cltt": 1712245568, "fqdn-fwd": false, "fqdn-rev": false, "hostname":
> > "jastest", "hw-address": "ac:24:11:5f:be:b7", "ip-address":
> > "130.63.XX.YY", "state": 0, "subnet-id": 6, "valid-lft": 300 } ] },
> > "result": 0, "text": "1 IPv4 lease(s) found." } ]
> >
> > So good, so far, right?
> >
> > I then assigned my test host an IP, cleared the DHCP lease for it, and
> > booted... the host got the proper IP outside of the pool, but it ALSO
> > had valid-lifetime 300 and not 4000!
> >
> > Is this because:
> >
> > "client-classes": [
> > {
> > "name": "short-lease",
> > "test": "member('KNOWN')",
> > "valid-lifetime": 300
> > }
> > ],
> >
> > ... automatically adds "short-lease" to any member of KNOWN?
> >
> > I just wish that ISC made it so that valid-lifetime could be configured
> > in pool.
> >
> > Jason.
> >
> > On 4/4/24 05:34, Darren Ankney wrote:
> > > Hi Jason,
> > >
> > > Something like this might work:
> > >
> > > "client-classes": [
> > > {
> > > "name": "short-lease",
> > > "test": "member('KNOWN')",
> > > "valid-lifetime": 300
> > > }
> > > ],
> > > ...
> > > "subnet4": [
> > > {
> > > "subnet": "10.1.2.0/24",
> > > "id": 1,
> > > "option-data": [
> > > {
> > > "name": "routers",
> > > "data": "10.1.2.1"
> > > }
> > > ],
> > > "valid-lifetime": 300,
> > > "pools": [
> > > {
> > > "pool": "10.1.2.100-10.1.2.200",
> > > "client-class": [ "short-lease" ]
> > > }
> > > ]
> > > }
> > > ],
> > >
> > > On Wed, Apr 3, 2024 at 10:56 AM Jason Keltz <j...@yorku.ca> wrote:
> > >> Hi Darren,
> > >>
> > >> Yes - "lease-lifetime" was my error - I meant "valid-lifetime".
> > >> I understand that I cannot apply "valid-lifetime" to a pool (although I
> > >> feel like I should be able to).
> > >> I already define client-class as "KNOWN" in all my pools so that unknown
> > >> hosts can't get an IP, and I understand that I can't use a second
> > >> client-class of "short-lease" in each pool.
> > >> I looked in the Kea code where options are defined, and thought I would
> > >> be able to add:
> > >>
> > >> {
> > >> "name": "dhcp-lease-time",
> > >> "data": "300"
> > >> }
> > >>
> > >> ... to "option-data" section for each host, but this didn't work
> > >> either. I see that in the Kea docs, all-options.json skips from code 49
> > >> to code 52, thereby skipping over code 51 which is lease time.
> > >>
> > >> I tried adding "code": 51, to the section to my option above, but it
> > >> didn't make any difference.
> > >>
> > >> I tried adding "valid-lifetime" to the "reservations" section to see if
> > >> that would work, but it would not.
> > >>
> > >> Therefore, I'm still not sure how to implement different lease times for
> > >> pools.
> > >>
> > >> Jason.
> > >>
> > >> On 4/3/24 06:35, Darren Ankney wrote:
> > >>> Hi Jason,
> > >>>
> > >>>
> > >>>> would it be valid syntax to also set lease-lifetime in the pool
> > >>>> instead of using the class?
> > >>>>
> > >>>> "pools": [
> > >>>> {
> > >>>> "pool": "10.1.2.100-10.1.2.200",
> > >>>> "lease-lifetime": "300"
> > >>>> }
> > >>>> ]
> > >>> I cannot find evidence of a parameter called "lease-lifetime" but
> > >>> "valid-lifetime" cannot be set inside a pools [] block.
> > >>>
> > >>>> I already assign the pools to "client-class": "KNOWN" - can I specify
> > >>>> multiple classes? "client-class": "KNOWN", "short-lease"?
> > >>>> If I use a class to do this, is the "valid-lifetime": 300 inside the
> > >>>> subnet definition necesary? It is repeated in both the subnet and the
> > >>>> client-class short-lease.
> > >>> The "valid-lifetime" inside the subnet was a mistake. That was a
> > >>> relic of some earlier testing. You cannot specify multiple classes on
> > >>> a client-class line. I don't know if you can have both client-class
> > >>> and client-classes as I've never tried. "client-class" does not do
> > >>> the same thing that "client-classes" does.
> > >>>
> > >>> Thank you,
> > >>> Darren Ankney
> > >> --
> > >> ISC funds the development of this software with paid support
> > >> subscriptions. Contact us at https://www.isc.org/contact/ for more
> > >> information.
> > >>
> > >> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > >>
> > >> Kea-users mailing list
> > >> Kea-users@lists.isc.org
> > >> https://lists.isc.org/mailman/listinfo/kea-users
> >
> >
> > --
> > Jason Keltz
> > Computer Development Manager
> > Department of Electrical Engineering and Computer Science
> > York University
> > Toronto, Ontario Canada
> > Tel: (416) 736-2100 x. 33570
> > Fax: (416) 736-5872
> >
> > --
> > ISC funds the development of this software with paid support subscriptions.
> > Contact us at https://www.isc.org/contact/ for more information.
> >
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> >
> > Kea-users mailing list
> > Kea-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/kea-users
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
