Server level option data is sent instead of subnet level option data
Describe the bug Given a DHCP4 configuration where a client option is defined at the server level, and also at the subnet level, the client is receiving the option data from the server level first, and then after forcing the client to renew, it receives the value from the subnet level.
To Reproduce
- Kea DHCP4
- Boot a Windows 10 client
- Client receives domain-name-servers option data defined at the server level
- Run ipconfig /renew Ethernet on the client and now it receives the correct domain-name-servers option data defined at the subnet level
- Reboot the client and it now has the server level domain-name-servers option data again.
Expected behavior The Kea DHCP4 server should send the option data defined at the subnet level to which the host reservation is mapped.
Environment:
- Kea version:
- 1.4.0-P1
- tarball
- linked with:
- log4cplus 1.1.2
- OpenSSL 1.1.0f 25 May 2017
- database:
- PostgreSQL backend 4.0, library 90610
- Memfile backend 2.0
- OS: Debian Stretch (Raspbian)
- Which features were compiled in (in particular which backends): "--with-pgsql --enable-shell"
- If/which hooks where loaded in: libdhcp_lease_cmds.so
Additional Information
-
The intent here is to define common option data at level that reduces redundancy, while overriding it at the subnet level when required.
-
Configuration excerpt:
"option-data": [
{
"name": "domain-name",
"code": 15,
"data": "mydomain.com"
},
{
"name": "domain-name-servers",
"code": 6,
"data": "172.20.0.1"
},
{
"name": "ntp-servers",
"code": 42,
"data": "172.20.0.1"
}
],
"hooks-libraries": [
{
// Lease hooks library for Kea Anterius
"library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [
{
"name": "Home",
"subnet4": [
{
// Networking Devices
"subnet": "172.20.0.0/24",
"id": 1,
"pools": [ { "pool": "172.20.0.3 - 172.20.0.8" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.0.1"
}
]
},
{
// Host Management
"subnet": "172.20.1.0/24",
"id": 2,
"pools": [
{ "pool": "172.20.1.2 - 172.20.1.4" },
{ "pool": "172.20.1.6/32" }
],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.1.1"
}
]
},
{
// Non-Domain Servers
"subnet": "172.20.3.0/24",
"id": 4,
"pools": [ { "pool": "172.20.3.4 - 172.20.3.4" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.3.1"
}
]
},
{
// Known Clients
"subnet": "172.20.4.0/24",
"id": 5,
"pools": [ { "pool": "172.20.4.2 - 172.20.4.5" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.4.1"
},
{
"name": "domain-name-servers",
"code": 6,
"data": "172.20.2.3,172.20.2.4,172.21.0.10,172.20.2.5,172.20.0.1"
}
]
},
Describe the solution you'd like A fix for the options data hierarchy behavior in the product.
Describe alternatives you've considered The only other alternative I have is to remove the common options data and repeat it, over and over, for each of the subnets that use it.
Contacting you How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.