Classified as: {OPEN}
Hi Darren,
Thanks for your reply. Sorry, I am new for Kea. Could you please explain it in
detail? Thanks in advance. You are appreciated.
In my old dhcp configuration, there is common for all supported network
(1)
allow unknown-clients;
I could configure unknown-clients to allow/deny/ignore ...
Now if convert to Kea, you mean, have to use special classes KNOWN and UNKNOWN
https://kea.readthedocs.io/en/kea-2.4.0/arm/classify.html#built-in-client-classes
I read it, I am totally lost.
what look like in Json format for this client class ? like below ? could you
give a sample ?
(2)
client-updates
I could configure this common parameter "client-updates" to allow/deny/ignore
...
Now if convert to Kea, you mean have to use ddns-override-client-update
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#supported-parameters
from the table: List of DHCPv4 parameters supported by the Configuration Backend
Parameter Global Client-Class Shared-Network
Subnet Pool
ddns-override-client-update yes n/a yes
yes n/a
this "ddns-override-client-update" configuration backend parameters can be
supported in Global,
this is same as my old dhcp configuration context.
But again, how it is look like in Json format?
(3) in fact, I have other parameters the online migration tools cannot process,
could you confirm it ?
ddns-update-style, I can configure it as
ad_hoc/interim/dhcp_standard/none/unknown
but tools convert to
"dhcp-ddns": {
"enable-updates": false // if old dhcp configure "none"
},
or
"dhcp-ddns": {
"enable-updates": true,
"qualifying-suffix": "" // what's this qualifying-suffix ? can I
leave it empty
},
update-static-leases // tools say: an obsolete feature, right ? I
can remove it in Kea, right ?
update-conflict-detection // tools say: not support, so I can remove it in
Kea, right ?
use-host-decl-names on // tools say: always on, so kea doesn't need to
configure this
(3) in old dhcp common part, I also have below, when it convert to Kea, it
comment out (IP address is hidden by myself), could you give me a hint ?
key rndc-key {
algorithm hmac-md5;
secret XXXXX;
}
# Zones déclarations.
zone test_1 {
primary xx.yy.zz.aa;
secondary aa.bb.cc.dd;
}
// "statement": {
// "tsig-keys": [
// {
// "name": "rndc-key",
// "algorithm": "hmac-md5.SIG-ALG.REG.INT.",
// "secret": "XXXXX"
// }
// ]
// },
// # Zones déclarations.
// "statement": {
// "zone": {
// "name": "test_1.",
// "primary": [
// "xx.yy.zz.aa"
// ],
// "secondary": [
// "aa.bb.cc.dd"
// ]
// }
// },
With Best Regards,
Chris LIU
{OPEN}
-----Original Message-----
From: Darren Ankney <[email protected]>
Sent: Saturday, September 23, 2023 4:36 AM
To: LIU Chris <[email protected]>
Cc: [email protected]
Subject: Re: [Kea-users] Migration to Kea
[You don't often get email from [email protected]. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
Hi Chris,
The equivalent to allow unknown-clients in Kea are the special classes KNOWN
and UNKNOWN. See:
https://kea.readthedocs.io/en/kea-2.4.0/arm/classify.html#built-in-client-classes
for information on this concept in Kea.
The equivalent to allow client-updates is "ddns-override-client-update" in Kea.
See here:
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#supported-parameters
for further information about this parameter.
Thank you,
Darren Ankney
On Fri, Sep 22, 2023 at 5:16 PM LIU Chris via Kea-users
<[email protected]> wrote:
>
> Classified as: {OPEN}
>
>
>
> Hi support,
>
>
>
> Now I am migrating to Kea from isc dhcp
>
> Old dhcp.conf:
>
>
>
> allow unknown-clients;
>
> allow client-updates;
>
>
>
> when I use online migration tools to generate Json format, it comment out,
> why ?
>
> "Dhcp4": {
>
> // "statement": {
>
> // "config": {
>
> // "value": "allow",
>
> // "name": "boot-unknown-clients",
>
> // "code": 6
>
> // }
>
> // },
>
> // "statement": {
>
> // "config": {
>
> // "value": "allow",
>
> // "name": "client-updates",
>
> // "code": 40
>
> // }
>
> // },
>
>
>
> With Best Regards,
>
>
>
> Chris LIU
>
>
>
> {OPEN}
>
> Thales is in the process of carving out its Transportation activity (GTS)
> from other Thales’ activities. In order to prepare this internal
> restructuring, a new e-mail address has been adopted and your GTS contacts
> now use urbanandmainlines.com. Please note that their Thales e-mail address
> remains also valid.
>
> --
> 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
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-users
Thales is in the process of carving out its Transportation activity (GTS) from
other Thales’ activities. In order to prepare this internal restructuring, a
new e-mail address has been adopted and your GTS contacts now use
urbanandmainlines.com. Please note that their Thales e-mail address remains
also valid.
--
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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
