Re: [Kea-users] DHCP NAK through relay option 82
I had hoped that someone would post a better "solution" than what I've
been using.
My topology is a Cisco SG-series switch in Level 3 mode that is
supplying DHCP (v4) relay to a dedicated subnet with the Kea hosts.
With the caveat that I have not tested this approach for robustness
under attack, what I do is check to see if the request appears to be a
valid REBIND and then select a client class based on either the VLAN
from the circuit ID or that it appears to be a directly sent rebind.
I don't recall how I decided that Kea would select the proper subnet on
these direct rebind requests. I am probably relying on undocumented
behavior. I recall not performing a match against the IP range for a
given VLAN as I didn't want to have to keep the subnet information in
sync across different files.
If anyone can improve on this, I'd appreciate the feedback.
Jeff
// Renew prefers to go direct to the issuing server
// so there is no circuit identifier or topology
//
// Kea doesn't check the existing leases and its
// KNOWN selector appears to be related to the client
// having a reservation.
//
// Select based on it being a Request (renew) packet
// that went direct with matching Ip addresses
{
"name": "is_request",
"test": "option[53].hex == 0x3"
},
{
"name": "is_direct",
"test": "pkt4.giaddr == 0.0.0.0"
},
{
"name": "addresses_match",
"test": "pkt4.ciaddr == pkt.src"
},
{
"name": "is_direct_rebind",
"test": "member('is_request') and member('is_direct') and
member('addresses_match')"
},
// Try just the combination of relay circuit check or rebind
{
"name": "VLAN_84",
"test": "member('circuit_84') or member('is_direct_rebind')"
},
[continues for other VLANs in use]
On 3/28/24 10:40 AM, brazda.li...@seznam.cz wrote:
Hi, I am trying to start kea dhcp with client classification using
option 82 through dhcp relay server.
When client tries to do renew of ip address, tries to prolongate his
lease, kea response with NAK.
The problem is that when client makes simple dhcp discover, the packet
goes broadcast through the router, router acts like dhcp relay and
relays packet to dhcp server kea with added option 82.
But when client makes dhcp renewal-packet goes unicast directly to
dhcp server without option 82. As I understand, this causes kea to
response with NAK, because packet doesn't match to subnet rule
criteria. In the logs I see message "ailed to select a subnet for
incoming packet, src 100.64.1.1, type DHCPREQUEST"
Is there a way to configure kea to accept renewal requests if lease
already exists and mac address of a client corresponds to stores lease?
Full log - https://pastebin.com/yviEFneL
Full config - https://pastebin.com/2DxfQKb6
Thanks for any advice
Libor
--
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
Re: [Kea-users] DHCP6 host reservation
Ciao, I was unable to use option 79 on relay agent so I’ve just made a test with both the client and server on the same VLAN ( no relay agent ) and “hw-address” seems to work, I will made more test just to be sure. Regarding the DUID, maybe I wrong ,in the DHCPv6 lease file ( server side ) I’ve seen different DUID if I use NetworkManager - service restart - o dhclient to get the IPv6 … I will evalute pros and cons of whether to use DUID o hw-address for host reservations Thanks everyone for the advice Regards, Cristina PS: if anyone has the recipe to use hw-address also with a relay agent please let me know :-) > On 2 Apr 2024, at 16:06, Francis Dupont wrote: > >> Of course in that case you could probably also configure the DHCPv6 >> client to send the hw-address as well :-) > > => in fact you can't: there is no direct way to carry the hardware address > in DHCPv6. BTW the opposite exists: RFC 4361 specifies a way to use > a DUID in DHCPv4. Of course you can find it in DHCPv6 messages, the problem > is usually there are many ways which are not guaranted to return a value > or the same value. > See 'MAC/Hardware Addresses in DHCPv6' section in the ARM... > > Regards > > Francis Dupont > -- > 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
Re: [Kea-users] different lease times
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
Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Darren,
Thank you for the explanation. Let me investigate further.
Best Regards,
Yu
From: Darren Ankney
Date: Wednesday, April 3, 2024 at 9:06 AM
To: Kea user's list
Cc: Xiao, Yu (CCI-Atlanta)
Subject: Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Yu,
Look in your logs for messages containing
HA_COMMUNICATION_INTERRUPTED_CLIENT4_UNACKED. These messages indicate
how many clients are still needed before the failover will occur.
Your settings specify:
"max-ack-delay": 300,
"max-unacked-clients": 5,
max-ack-delay is specified in milliseconds so pretty much every client
that reaches one in the "elapsed time" option in DHCPv6 will meet the
criteria of an "unacked" client. Once the sixth client shows up,
failover should occur. That log message should repeat with each new
client being tracked giving statistics about how many more are needed.
Thank you,
Darren Ankney
On Tue, Apr 2, 2024 at 12:39 PM Xiao, Yu (CCI-Atlanta) via Kea-users
wrote:
>
> Hi experts,
>
>
>
> I have tested further in my lab and found the answers to my questions. HA
> works when I don’t enable the control agent. As for the debug log, I think
> there’s a potential document bug for 2.4.1 document. Cause you can’t assign
> the log to /var/log folder, you need to assign it to /tmp/ folder.
>
>
>
> I found a problem on myside on firewall, after I fixed it. Now seems the HA
> is working. But still having one problem. When I used “systemctl stop
> kea-dhcp6” on the primary, for example, kea01, then the standby DHCPv6 server
> kea03 won’t process the DHCP packets from clients. I waited for more time,
> but the behaviors won’t change. The standby server just drop those DHCP
> packets from clients due to “dropping query to be processed by another
> server”.
>
>
>
> According to Kea documentation, this happens when:
>
>
>
> “%1: dropping query to be processed by another server
>
>
>
> This debug message is issued when the received DHCPv6 query is dropped by
> this server because it should be served by another server. This is the case
> when the remote server was designated to process the packet as a result of
> load balancing or because it is a primary server in the hot standby
> configuration. The argument provides client identification information
> retrieved from the query.”
>
>
>
> But now since the primary service is down, so the standby server should
> become the primary one, right? But seems not the case. Also from the debug
> logs, I can’t see the current status of the remaining server, technically we
> should be able to see its status changed from standby to primary, right? But
> I only see the role information from the logs before I shut down the kea
> service on primary server.
>
>
>
> Config:
>
> # HA related hooks configuration
>
> "hooks-libraries": [{
>
> "library": "/usr/lib64/kea/hooks/libdhcp_lease_cmds.so",
>
> "parameters": { }
>
> }, {
>
> "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
>
> "parameters": {
>
> "high-availability": [{
>
> "this-server-name": "kea_home3",
>
> "mode": "hot-standby",
>
> "heartbeat-delay": 100,
>
> "max-response-delay": 200,
>
> "max-ack-delay": 300,
>
> "max-unacked-clients": 5,
>
> "peers": [{
>
> "name": "kea_home1",
>
> "url":
> https://urldefense.com/v3/__http://192.168.100.197:8000/__;!!Hit2Ag!yteZar1VMg4V2QncUrW9qHJR12Fao76aOPAzxE4bRwaXFdrveqPfJanYcIlzufpSJtigEMc_AtWEvY8Qy6Ik$
> ,
>
> "role": "primary",
>
> "auto-failover": true
>
> }, {
>
> "name": "kea_home3",
>
> "url":
> https://urldefense.com/v3/__http://192.168.100.70:8000/__;!!Hit2Ag!yteZar1VMg4V2QncUrW9qHJR12Fao76aOPAzxE4bRwaXFdrveqPfJanYcIlzufpSJtigEMc_AtWEvU0f5KAX$
> ,
>
> "role": "standby",
>
> "auto-failover": true
>
> }]
>
> }]
>
> }
>
> }],
>
>
>
>
>
> Logs:
>
> 2024-04-02 12:03:41.696 DEBUG [kea-dhcp6.http/15314.139903918055424]
> HTTP_CLIENT_REQUEST_SEND_DETAILS detailed information about request sent to
> https://urldefense.com/v3/__http://192.168.100.197:8000/__;!!Hit2Ag!yteZar1VMg4V2QncUrW9qHJR12Fao76aOPAzxE4bRwaXFdrveqPfJanYcIlzufpSJtigEMc_AtWEvY8Qy6Ik$
> :
>
> POST / HTTP/1.1
>
> Host: 192.168.100.197
>
> Content-Length: 53
Re: [Kea-users] [EXTERNAL] Re: kea-2.4.1 // Strange HA related errors
Hi Yu,
Look in your logs for messages containing
HA_COMMUNICATION_INTERRUPTED_CLIENT4_UNACKED. These messages indicate
how many clients are still needed before the failover will occur.
Your settings specify:
"max-ack-delay": 300,
"max-unacked-clients": 5,
max-ack-delay is specified in milliseconds so pretty much every client
that reaches one in the "elapsed time" option in DHCPv6 will meet the
criteria of an "unacked" client. Once the sixth client shows up,
failover should occur. That log message should repeat with each new
client being tracked giving statistics about how many more are needed.
Thank you,
Darren Ankney
On Tue, Apr 2, 2024 at 12:39 PM Xiao, Yu (CCI-Atlanta) via Kea-users
wrote:
>
> Hi experts,
>
>
>
> I have tested further in my lab and found the answers to my questions. HA
> works when I don’t enable the control agent. As for the debug log, I think
> there’s a potential document bug for 2.4.1 document. Cause you can’t assign
> the log to /var/log folder, you need to assign it to /tmp/ folder.
>
>
>
> I found a problem on myside on firewall, after I fixed it. Now seems the HA
> is working. But still having one problem. When I used “systemctl stop
> kea-dhcp6” on the primary, for example, kea01, then the standby DHCPv6 server
> kea03 won’t process the DHCP packets from clients. I waited for more time,
> but the behaviors won’t change. The standby server just drop those DHCP
> packets from clients due to “dropping query to be processed by another
> server”.
>
>
>
> According to Kea documentation, this happens when:
>
>
>
> “%1: dropping query to be processed by another server
>
>
>
> This debug message is issued when the received DHCPv6 query is dropped by
> this server because it should be served by another server. This is the case
> when the remote server was designated to process the packet as a result of
> load balancing or because it is a primary server in the hot standby
> configuration. The argument provides client identification information
> retrieved from the query.”
>
>
>
> But now since the primary service is down, so the standby server should
> become the primary one, right? But seems not the case. Also from the debug
> logs, I can’t see the current status of the remaining server, technically we
> should be able to see its status changed from standby to primary, right? But
> I only see the role information from the logs before I shut down the kea
> service on primary server.
>
>
>
> Config:
>
> # HA related hooks configuration
>
> "hooks-libraries": [{
>
> "library": "/usr/lib64/kea/hooks/libdhcp_lease_cmds.so",
>
> "parameters": { }
>
> }, {
>
> "library": "/usr/lib64/kea/hooks/libdhcp_ha.so",
>
> "parameters": {
>
> "high-availability": [{
>
> "this-server-name": "kea_home3",
>
> "mode": "hot-standby",
>
> "heartbeat-delay": 100,
>
> "max-response-delay": 200,
>
> "max-ack-delay": 300,
>
> "max-unacked-clients": 5,
>
> "peers": [{
>
> "name": "kea_home1",
>
> "url": http://192.168.100.197:8000/,
>
> "role": "primary",
>
> "auto-failover": true
>
> }, {
>
> "name": "kea_home3",
>
> "url": http://192.168.100.70:8000/,
>
> "role": "standby",
>
> "auto-failover": true
>
> }]
>
> }]
>
> }
>
> }],
>
>
>
>
>
> Logs:
>
> 2024-04-02 12:03:41.696 DEBUG [kea-dhcp6.http/15314.139903918055424]
> HTTP_CLIENT_REQUEST_SEND_DETAILS detailed information about request sent to
> http://192.168.100.197:8000/:
>
> POST / HTTP/1.1
>
> Host: 192.168.100.197
>
> Content-Length: 53
>
> Content-Type: application/json
>
>
>
> { "command": "ha-heartbeat", "service": [ "dhcp6" ] }
>
> 2024-04-02 12:03:41.696 DEBUG [kea-dhcp6.http/15314.139903754057472]
> HTTP_BAD_SERVER_RESPONSE_RECEIVED bad response received when communicating
> with http://192.168.100.197:8000/: Connection refused
>
> 2024-04-02 12:03:41.696 WARN [kea-dhcp6.ha-hooks/15314.139903754057472]
> HA_HEARTBEAT_COMMUNICATIONS_FAILED failed to send heartbeat to kea_home1
> (http://192.168.100.197:8000/): Connection refused
>
> 2024-04-02 12:03:41.696 WARN [kea-dhcp6.ha-hooks/15314.139903754057472]
> HA_COMMUNICATION_INTERRUPTED communication with kea_home1 is interrupted
>
> 2024-04-02 12:03:41.773 DEBUG [kea-dhcp6.packets/15314.139903918055424]
> DHCP6_BUFFER_RECEIVED received buffer from fe80::c40b:ebff:fed1:7298:546 to
> ff02::1:2:0 over interface ens18
>
> 2024-04-02 12:03:41.773 DEBUG [kea-dhcp6.callouts/15314.139903787628288]
> HOOKS_CALLOUTS_BEGIN begin all callouts for hook buffer6_receive
>
> 2024-04-02 12:03:41.773 DEBUG [kea-dhcp6.ha-hooks/15314.139903787628288]
> HA_BUFFER6_RECEIVE_NOT_FOR_US
>
Re: [Kea-users] different lease times
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
