[Kea-users] NAK responses getting dropped
Elton, Norman N
wnelto at wm.edu
Fri Oct 9 12:31:35 UTC 2026
>> It could be that Kea isn't sending the packet
>> perhaps, but that seems the least likely scenario so far.
You were right to be suspicious. A second packet capture shows the NAKs leaving the server. Not entirely sure why I didn’t spot them before. Apologies, and thanks for the thoughtful reply!!
A little more research has uncovered a new wrinkle. These clients are sending a L2 broadcast packet, requesting their now-invalid IP address. That is being forwarded along by our router (Juniper MX). The response appears to make it to the router, but gets dropped … under one condition. The dropped requests have the “unicast” flag set, even though they’re clearly a broadcast packet. We need to dig into the RFCs to see if that’s an acceptable behavior. The response has the same flag set, and so the router is presumably refusing to re-broadcast the response. We’ve verified this behavior by crafting specific DHCP requests with scapy.
We’ll update this thread when we find more.
Norman
From: Kea-users <kea-users-bounces at lists.isc.org> on behalf of Elton, Norman N <wnelto at wm.edu>
Date: Wednesday, October 7, 2026 at 8:49 AM
To: Kea user's list <kea-users at lists.isc.org>
Subject: Re: [Kea-users] NAK responses getting dropped
Good morning!
I’m running the packet capture on the server itself. Not entirely sure what you mean by “full logs”. I cranked the level up to DEBUG for all loggers and did not see any additional messages related to these transactions. Happy to do more digging.
I’ll paste a trimmed-down version of our configuration below. I removed all the unrelated subnets.
Thanks!!
Norman
{
"Dhcp4": {
"valid-lifetime": 86400,
"interfaces-config": {
"interfaces": [
"*"
],
"dhcp-socket-type": "udp"
},
"decline-probation-period": 3600,
"lease-database": {
"type": "memfile",
"persist": true,
"lfc-interval": 86400,
"name": "/var/lib/kea/kea-leases4.csv"
},
"hosts-database": {
"type": "mysql",
"name": "kea",
"user": "kea",
"password": "..."
},
"shared-networks": [
...
],
"subnet4": [
{
"user-context": {
"name": "STUDENT-TUCKER",
"regions": "student"
},
"subnet": "100.70.0.0/16",
"valid-lifetime": 86400,
"pools": [
{
"pool": "100.70.0.50 - 100.70.99.255",
"client-class": "HA_KEA_01"
},
{
"pool": "100.70.100.0 - 100.70.199.255",
"client-class": "HA_KEA_02"
},
{
"pool": "100.70.235.0 - 100.70.244.255",
"client-class": "HA_KEA_01"
},
{
"pool": "100.70.245.0 - 100.70.254.255",
"client-class": "HA_KEA_02"
}
],
"option-data": [
{
"name": "routers",
"data": "100.70.0.1"
}
],
"id": 1682309120
}
],
"echo-client-id": false,
"sanity-checks": {
"lease-checks": "fix"
},
"client-classes": [
{
"name": "INOVA_CLOCK",
"test": "hexstring(substring(pkt4.mac, 0, 3), ':') == '00:60:35'",
"option-data": [
{
"name": "CLOCK-INFO",
"data": "timeserver=time.example.org;timezone=-5;dst=-1 8 2 2 1 1 10 2"
}
]
},
{
"name": "JUNIPER",
"test": "substring(option[60].text, 0, 7) == 'Juniper'",
"option-data": [
{
"name": "EZ_PROVISIONING_CONFIG_FILE_NAME",
"space": "EZ_PROVISIONING_SPACE",
"data": "..."
},
{
"name": "EZ_PROVISIONING_IMAGE_TRANSFER_MODE",
"space": "EZ_PROVISIONING_SPACE",
"data": "http"
},
{
"name": "vendor-encapsulated-options",
"always-send": true
}
]
},
{
"name": "AUDIOCODES_405",
"test": "option[60].hex == '405HD' or option[77].hex == '405HD'",
"option-data": [
{
"name": "AUDIOCODES-PROVISIONING",
"data": "...",
"always-send": true
}
]
}
],
"option-def": [
{
"name": "CLOCK-INFO",
"code": 230,
"type": "string"
},
{
"name": "AUDIOCODES-PROVISIONING",
"code": 160,
"type": "string"
},
{
"name": "EZ_PROVISIONING",
"type": "empty",
"code": 43,
"encapsulate": "EZ_PROVISIONING_SPACE"
},
{
"name": "EZ_PROVISIONING_CONFIG_FILE_NAME",
"code": 1,
"space": "EZ_PROVISIONING_SPACE",
"type": "string"
},
{
"name": "EZ_PROVISIONING_IMAGE_TRANSFER_MODE",
"code": 3,
"space": "EZ_PROVISIONING_SPACE",
"type": "string"
},
{
"name": "EZ_PROVISIONING_SERVER",
"code": 150,
"type": "ipv4-address"
}
],
"option-data": [
{
"name": "domain-name-servers",
"data": "192.168.29.9, 192.168.20.9",
"always-send": true
},
{
"name": "domain-name",
"data": "example.org"
}
],
"match-client-id": false,
"host-reservation-identifiers": [
"hw-address"
],
"reservations-global": false,
"reservations-in-subnet": false,
"reservations-out-of-pool": true,
"authoritative": true,
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "syslog",
"flush": false
}
],
"severity": "INFO"
}
],
"multi-threading": {
"enable-multi-threading": true,
"thread-pool-size": 4,
"packet-queue-size": 28
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/var/run/kea/control-socket"
},
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_mysql_cb.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"this-server-name": "KEA_01",
"mode": "load-balancing",
"heartbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 5000,
"max-unacked-clients": 5,
"max-rejected-lease-updates": 10,
"delayed-updates-limit": 100,
"peers": [
{
"name": "KEA_01",
"url": "http://192.168.10.154:3000",
"role": "primary",
"auto-failover": true
},
{
"name": "KEA_02",
"url": "http://192.168.10.155:3000",
"role": "secondary",
"auto-failover": true
}
]
}
]
}
}
]
}
}
>> HI Norman,
>> Where are you capturing the packets? Directly on the Kea server or
>> somewhere else? Also, full logs and your Kea configuration would be
>> necessary to get a clearer picture of what might be happening.
>> Thank you,
>> Darren Ankney
From: Elton, Norman N <wnelto at wm.edu>
Date: Friday, October 2, 2026 at 10:52 AM
To: Kea user's list <kea-users at lists.isc.org>
Subject: NAK responses getting dropped
We have clients requesting addresses in the wrong subnet, which Kea is trying to send a NAK:
[kea-dhcp4.dhcp4.123] DHCP4_QUERY_LABEL received query: [hwtype=1 bc:9f:58:1b:cf:f3], cid=[01:bc:9f:58:1b:cf:f3], tid=0x6a744f8
[kea-dhcp4.packets.123] DHCP4_PACKET_RECEIVED [hwtype=1 bc:9f:58:1b:cf:f3], cid=[01:bc:9f:58:1b:cf:f3], tid=0x6a744f8: DHCPREQUEST (type 3) received from 100.70.0.2 to 128.239.10.154 on interface bond0.10
[kea-dhcp4.leases.123] DHCP4_INIT_REBOOT [hwtype=1 bc:9f:58:1b:cf:f3], cid=[01:bc:9f:58:1b:cf:f3], tid=0x6a744f8: client is in INIT-REBOOT state and requests address 100.69.0.173
[kea-dhcp4.packets.123] DHCP4_PACKET_SEND [hwtype=1 bc:9f:58:1b:cf:f3], cid=[no info], tid=0x6a744f8: trying to send packet DHCPNAK (type 6) from 128.239.10.154:67 to 100.70.0.2:67 on interface bond0.10
Problem is, the NAK is not being sent. When running packet captures, I see tons ACKs but no NAKs. The pkt4-nak-sent statistic is increasing. Just … no packets on the wire.
I cranked up kea-dhcp4.packets to DEBUG mode, no additional information.
Kea 2.6.4 running in load-balancing high availability mode.
Any suggestions?
Thanks,
Norman Elton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20261009/d6ad897a/attachment-0001.htm>
More information about the Kea-users
mailing list