[Kea-users] DHCH NAK through relay

perl-list perl-list at network1.net
Thu Sep 30 12:58:53 UTC 2021


I don't know if that is possible, but it sounds like a hack to me if it is.  I would suggest looking into your relay agent.  Some of them allow the "hiding" of the real server such that the end client never sees what IP the actual server has (ie: relay agent swaps out dhcp-server-identifier value for its own IP in the OFFER and ACK).  It appears to the client as if the server is the relay agent.  Cisco calls this DHCP Proxy, I believe.  That way you could ensure that your renews all pass through the relay agent and all have the correct information attached.  Its more of an ISP feature, so it depends what purpose your equipment was intended for whether it exists there.

----- Original Message -----
> From: "egor grijuc" <egor.grijuc at orange.com>
> To: "kea-users" <kea-users at lists.isc.org>
> Sent: Wednesday, September 29, 2021 10:50:55 AM
> Subject: [Kea-users] DHCH NAK through relay

> Hello.

> My setup is the following:

> I have 2 client classes:

> "client-classes": [

> {

> "name":"LabOltMgm",

> "test":"option[82].option[150].hex == 0x6441a000"//100.65.160.0

> },

> {

> "name":"LabOltData",

> "test":"option[82].option[150].hex == 0x5cb58840" //92.181.136.64

> }

> ],

> And 2 shared subnets

> "shared-networks": [

> {

> "name":"GponManagementSubnets",

> "subnet4": [

> {

> "id": 2,

> "client-class": "LabOltMgm",

> "option-data": [{"name": "routers","data": "100.65.160.1"} ],

> "pools": [{ "pool": "100.65.160.2 - 100.65.160.100"}],

> "rebind-timer": 600,

> "renew-timer": 600,

> "subnet": "100.65.160.0/19",

> "valid-lifetime": 600

> }

> ]

> },

> {

> "name":"GponDataV4Subnets",

> "subnet4": [

> {

> "id": 3,

> "client-class": "LabOltData",

> "option-data": [{"name":
> "routers","data":"92.181.136.65"},{"name":"domain-name-servers","data":"217.12.120.2"}
> ],

> "pools": [{ "pool": "92.181.136.66 - 92.181.136.126"}],

> "rebind-timer": 600,

> "renew-timer": 600,

> "subnet": "92.181.136.64/26",

> "valid-lifetime": 600

> }

> ]

> }

> ],

> All works fine exept one moment.

> 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 dhcpdiscover, the packet goes
> broadcast through the router, router acts like dhcp relay and relays packet to
> dhcp server kea with added option 82 suboption 150.

> But when client makes dhcp renewal-packet goes unicast directly to dhcp server
> without option 82 suboption 150. 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 “failed to select a subnet for incoming
> packet, src 100.65.160.2, 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?

> _________________________________________________________________________________________________________________________

> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.

> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.

> _______________________________________________
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users


More information about the Kea-users mailing list