"deny duplicates;" not working?

[Neff, Glen]

We have proprietary network devices that use rely on DHCP for configuration. We're using a standard 72 hour lease time, and we rely on the IPs to not change, so long as these devices aren't offline for much more than a reboot.

Static assignments by MAC address are not feesible for our purposes.

The problem that we are encountering is that periodically these devices must have their firmware updated and these updates are causing the UID sent in the DHCP request to be changed.

Here's an example of three entries taken from the dhcpd.leases file on the server: http://pastebin.ca/2299463

The first entry was was generated by a reboot early in the day.

The second entry was "control case" reboot made before we updated the firmware on the client device. Notice how it's identical to the first, with the exception of the times.

The third entry is after the firmware update. Notice that the MAC address remains the same, however the UID has changed, so the server issued it a new IP.

In consulting dhcpd.conf(5) I found "deny duplicates;" which sounded like a magic bullet workaround, so I added it to the subnet declaration in dhcpd.conf file, but the problem remains the same (in tests with other of the same type devices and firmware upgrade scenario).

The server version is 4.2.4, running on FreeBSD v8.2-RELEASE. It's built via the ports system: isc-dhcp42-server-4.2.4_1

There is a DHCP-relay involved - it's configured on the VLAN interface of a Cisco Nexus 7010, running NX-OS v 5.2(3a).

Any insite would be appreciated.

-G

/*
* Glen R. J. Neff
* USD Lab Operations Infrastructure Team
* ***@emc.com
*
* EMC^2 == E^2
*/

[Sten Carlsen]

On 08/01/13 19:51, Neff, Glen wrote:
> We have proprietary network devices that use rely on DHCP for
> configuration. We're using a standard 72 hour lease time, and we rely
> on the IPs to not change, so long as these devices aren't offline for
> much more than a reboot.
> Static assignments by MAC address are not feesible for our purposes.
> The problem that we are encountering is that periodically these
> devices must have their firmware updated and these updates are causing
> the UID sent in the DHCP request to be changed.
The main piece of information to identify a client is actually the UID,
so with a new UID -> a new client, obviously it can not get the same IP,
that is reserved for the old client.
You may have luck looking into classes and subclasses. Possibly with
"spawn". I have never used these features but I have a feeling they may
actually do what you need.
Use the hardware = MAC to create your subclass and that could be
independant from the UID - I think.
> Here's an example of three entries taken from the dhcpd.leases file on
> the server: http://pastebin.ca/2299463
> The first entry was was generated by a reboot early in the day.
> The second entry was "control case" reboot made before we updated the
> firmware on the client device. Notice how it's identical to the
> first, with the exception of the times.
> The third entry is after the firmware update. Notice that the MAC
> address remains the same, however the UID has changed, so the server
> issued it a new IP.
> In consulting dhcpd.conf(5) I found "deny duplicates;" which sounded
> like a magic bullet workaround, so I added it to the subnet
> declaration in dhcpd.conf file, but the problem remains the same (in
> tests with other of the same type devices and firmware upgrade scenario).
> The server version is 4.2.4, running on FreeBSD v8.2-RELEASE. It's
> built via the ports system: isc-dhcp42-server-4.2.4_1
> There is a DHCP-relay involved - it's configured on the VLAN interface
> of a Cisco Nexus 7010, running NX-OS v 5.2(3a).
> Any insite would be appreciated.
> -G
>
> /*
> * Glen R. J. Neff
> * USD Lab Operations Infrastructure Team
> * ***@emc.com
> *
> * EMC^2 == E^2
> */
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!"

[Neff, Glen]

>The main piece of information to identify a client is actually the UID, so with a new UID -> a new client, obviously it >can not get the same IP, that is reserved for the old client.
>You may have luck looking into classes and subclasses. Possibly with "spawn". I have never used these features >but I have a feeling they may actually do what you need.
>Use the hardware = MAC to create your subclass and that could be independant from the UID - I think.
Is dhcpd.conf(5) erroneous then?:

The duplicates keyword
allow duplicates;
deny duplicates;
Host declarations can match client messages based on the DHCP Client
Identifier option or based on the client's network hardware type and
MAC address. If the MAC address is used, the host declaration will
match any client with that MAC address - even clients with different
client identifiers. This doesn't normally happen, but is possible
when one computer has more than one operating system installed on it -
for example, Microsoft Windows and NetBSD or Linux.
The duplicates flag tells the DHCP server that if a request is received
from a client that matches the MAC address of a host declaration, any
other leases matching that MAC address should be discarded by the
server, even if the UID is not the same. This is a violation of the
DHCP protocol, but can prevent clients whose client identifiers change
regularly from holding many leases at the same time. By default,
duplicates are allowed.
-G

/*
* Glen R. J. Neff
* USD Lab Operations Infrastructure Team
* ***@emc.com
*
* EMC^2 == E^2
*/

[Sten Carlsen]

How is your configuration? do you specifically use the MAC or is it the
default (which is UID)?

On 08/01/13 20:13, Neff, Glen wrote:
> >The main piece of information to identify a client is actually the
> UID, so with a new UID -> a new client, obviously it >can not get the
> same IP, that is reserved for the old client.
> >You may have luck looking into classes and subclasses. Possibly with
> "spawn". I have never used these features >but I have a feeling they
> may actually do what you need.
> >Use the hardware = MAC to create your subclass and that could be
> independant from the UID - I think.
> Is dhcpd.conf(5) erroneous then?:
>
> The duplicates keyword
> allow duplicates;
> deny duplicates;
> Host declarations can match client messages based on the
> DHCP Client
> Identifier option or based on the client's network hardware
> type and
> MAC address. If the MAC address is used, the host
> declaration will
> match any client with that MAC address - even clients with
> different
> client identifiers. This doesn't normally happen, but is
> possible
> when one computer has more than one operating system installed
> on it -
> for example, Microsoft Windows and NetBSD or Linux.
> The duplicates flag tells the DHCP server that if a request is
> received
> from a client that matches the MAC address of a host
> declaration, any
> other leases matching that MAC address should be discarded
> by the
> server, even if the UID is not the same. This is a
> violation of the
> DHCP protocol, but can prevent clients whose client
> identifiers change
> regularly from holding many leases at the same time. By
> default,
> duplicates are allowed.
> -G
>
> /*
> * Glen R. J. Neff
> * USD Lab Operations Infrastructure Team
> * ***@emc.com
> *
> * EMC^2 == E^2
> */
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Best regards

Sten Carlsen

No improvements come from shouting:
"MALE BOVINE MANURE!!!"

[Neff, Glen]

I guess i'm using the default, which is UID, so I guess I have to specify a class?

How do I specify a class that includes all MAC addresses?

-G

/*
* Glen R. J. Neff
* USD Lab Operations Infrastructure Team
* ***@emc.com
*
* EMC^2 == E^2
*/

________________________________
From: dhcp-users-bounces+glen.neff=***@lists.isc.org [dhcp-users-bounces+glen.neff=***@lists.isc.org] On Behalf Of Sten Carlsen [***@s-carlsen.dk]
Sent: Tuesday, January 08, 2013 3:49 PM
To: dhcp-***@lists.isc.org
Subject: Re: "deny duplicates;" not working?

How is your configuration? do you specifically use the MAC or is it the default (which is UID)?

On 08/01/13 20:13, Neff, Glen wrote:
>The main piece of information to identify a client is actually the UID, so with a new UID -> a new client, obviously it >can not get the same IP, that is reserved for the old client.
>You may have luck looking into classes and subclasses. Possibly with "spawn". I have never used these features >but I have a feeling they may actually do what you need.
>Use the hardware = MAC to create your subclass and that could be independant from the UID - I think.
Is dhcpd.conf(5) erroneous then?:

The duplicates keyword
allow duplicates;
deny duplicates;
Host declarations can match client messages based on the DHCP Client
Identifier option or based on the client's network hardware type and
MAC address. If the MAC address is used, the host declaration will
match any client with that MAC address - even clients with different
client identifiers. This doesn't normally happen, but is possible
when one computer has more than one operating system installed on it -
for example, Microsoft Windows and NetBSD or Linux.
The duplicates flag tells the DHCP server that if a request is received
from a client that matches the MAC address of a host declaration, any
other leases matching that MAC address should be discarded by the
server, even if the UID is not the same. This is a violation of the
DHCP protocol, but can prevent clients whose client identifiers change
regularly from holding many leases at the same time. By default,
duplicates are allowed.
-G

/*
* Glen R. J. Neff
* USD Lab Operations Infrastructure Team
* ***@emc.com<mailto:***@emc.com>
*
* EMC^2 == E^2
*/



_______________________________________________
dhcp-users mailing list
dhcp-***@lists.isc.org<mailto:dhcp-***@lists.isc.org>
https://lists.isc.org/mailman/listinfo/dhcp-users


--
Best regards

Sten Carlsen

No improvements come from shouting:
"MALE BOVINE MANURE!!!"

[Sten Carlsen]

As mentioned, I never used this.

I would look into man dhcpd.conf - spawning classes.
You should be able to spawn a new subclass for each MAC address and
allocate IP addresses accordingly.

On 08/01/13 22:23, Neff, Glen wrote:
> I guess i'm using the default, which is UID, so I guess I have to
> specify a class?
>
> How do I specify a class that includes all MAC addresses?
>
> -G
>
> /*
> * Glen R. J. Neff
> * USD Lab Operations Infrastructure Team
> * ***@emc.com
> *
> * EMC^2 == E^2
> */
>
> ------------------------------------------------------------------------
> *From:* dhcp-users-bounces+glen.neff=***@lists.isc.org
> [dhcp-users-bounces+glen.neff=***@lists.isc.org] On Behalf Of Sten
> Carlsen [***@s-carlsen.dk]
> *Sent:* Tuesday, January 08, 2013 3:49 PM
> *To:* dhcp-***@lists.isc.org
> *Subject:* Re: "deny duplicates;" not working?
>
> How is your configuration? do you specifically use the MAC or is it
> the default (which is UID)?
>
> On 08/01/13 20:13, Neff, Glen wrote:
>> >The main piece of information to identify a client is actually the
>> UID, so with a new UID -> a new client, obviously it >can not get the
>> same IP, that is reserved for the old client.
>> >You may have luck looking into classes and subclasses. Possibly with
>> "spawn". I have never used these features >but I have a feeling they
>> may actually do what you need.
>> >Use the hardware = MAC to create your subclass and that could be
>> independant from the UID - I think.
>> Is dhcpd.conf(5) erroneous then?:
>>
>> The duplicates keyword
>> allow duplicates;
>> deny duplicates;
>> Host declarations can match client messages based on the
>> DHCP Client
>> Identifier option or based on the client's network hardware
>> type and
>> MAC address. If the MAC address is used, the host
>> declaration will
>> match any client with that MAC address - even clients with
>> different
>> client identifiers. This doesn't normally happen, but is
>> possible
>> when one computer has more than one operating system
>> installed on it -
>> for example, Microsoft Windows and NetBSD or Linux.
>> The duplicates flag tells the DHCP server that if a request is
>> received
>> from a client that matches the MAC address of a host
>> declaration, any
>> other leases matching that MAC address should be
>> discarded by the
>> server, even if the UID is not the same. This is a
>> violation of the
>> DHCP protocol, but can prevent clients whose client
>> identifiers change
>> regularly from holding many leases at the same time. By
>> default,
>> duplicates are allowed.
>> -G
>>
>> /*
>> * Glen R. J. Neff
>> * USD Lab Operations Infrastructure Team
>> * ***@emc.com
>> *
>> * EMC^2 == E^2
>> */
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-***@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
> "MALE BOVINE MANURE!!!"
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Best regards

Sten Carlsen

No improvements come from shouting:
"MALE BOVINE MANURE!!!"

[Peter Rathlev]

On Tue, 2013-01-08 at 14:13 -0500, Neff, Glen wrote:
> Is dhcpd.conf(5) erroneous then?:
>
> The duplicates keyword
> allow duplicates;
> deny duplicates;
> Host declarations can match client messages based on the DHCP
> Client Identifier option or based on the client's network
> hardware type and MAC address.

AFAIK the keyword here is "host declaration". This only works if you
actually use host declarations.

--
Peter

[Neff, Glen]

>> Is dhcpd.conf(5) erroneous then?:
>>
>> The duplicates keyword
>> allow duplicates;
>> deny duplicates;
>> Host declarations can match client messages based on the DHCP
>> Client Identifier option or based on the client's network
>> hardware type and MAC address.
>>AFAIK the keyword here is "host declaration". This only works if you
>>actually use host declarations.

I actually use a lot of MAC-based host declarations (in other environments), but this is never an issue with those, 'cause they just use the MAC address. I'm not understanding the point of an option that only applies to a condition which precludes it.

I think I just need to decipher and employ the class syntax somehow.

-G

/*
* Glen R. J. Neff
* USD Lab Operations Infrastructure Team
* ***@emc.com
*
* EMC^2 == E^2
*/

[Sten Carlsen]

I do use class and subclass, something like:

class "gateway-1" {
match hardware;
}

pool{
allow members of "gateway-1";
...... other options;
}

subclass "gateway-1" 1:00:04:20:17:fd:6d; # host Sq-rcvr
subclass "gateway-1" 1:00:04:20:1b:d1:1c; # host Sq-control


This is instead of using host statements, with "spawn" there is a spawn
statement in the class instead of the subclass - if I understand correctly.


On 08/01/13 23:03, Neff, Glen wrote:
>>> Is dhcpd.conf(5) erroneous then?:
>>>
>>> The duplicates keyword
>>> allow duplicates;
>>> deny duplicates;
>>> Host declarations can match client messages based on the DHCP
>>> Client Identifier option or based on the client's network
>>> hardware type and MAC address.
>>> AFAIK the keyword here is "host declaration". This only works if you
>>> actually use host declarations.
> I actually use a lot of MAC-based host declarations (in other environments), but this is never an issue with those, 'cause they just use the MAC address. I'm not understanding the point of an option that only applies to a condition which precludes it.
>
> I think I just need to decipher and employ the class syntax somehow.
>
> -G
>
> /*
> * Glen R. J. Neff
> * USD Lab Operations Infrastructure Team
> * ***@emc.com
> *
> * EMC^2 == E^2
> */
> _______________________________________________
> dhcp-users mailing list
> dhcp-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Best regards

Sten Carlsen

No improvements come from shouting:
"MALE BOVINE MANURE!!!"

[s***@nethelp.no]

> The third entry is after the firmware update. Notice that the MAC address remains the same, however the UID has changed, so the server issued it a new IP.
>
> In consulting dhcpd.conf(5) I found "deny duplicates;" which sounded like a magic bullet workaround, so I added it to the subnet declaration in dhcpd.conf file, but the problem remains the same (in tests with other of the same type devices and firmware upgrade scenario).

By default (and according to the RFC) UID is preferred if it exists in
the DHCP request.

What you really want is the long asked for ability to prefer MAC address
(only) and ignore the UID. This is unfortunately not possible with the
current ISC DHCP.

I believe that if you look back in the archives you may find a patch
which implements this - but for a previous version of ISC DHCP. Current
status of this patch is unknown.

Steinar Haug, Nethelp consulting, ***@nethelp.no

[Paul B. Henson]

On 1/8/2013 11:02 PM, ***@nethelp.no wrote:

> What you really want is the long asked for ability to prefer MAC address
> (only) and ignore the UID. This is unfortunately not possible with the
> current ISC DHCP.
>
> I believe that if you look back in the archives you may find a patch
> which implements this - but for a previous version of ISC DHCP. Current
> status of this patch is unknown.

We have an implementation of this applicable to current release
versions, I'm pretty sure it was submitted to ISC but I don't think we
ever heard back on it. Our use case was computing labs that dual booted
windows/linux, where windows used a UID and didn't like to release the
address. Without this feature, we would have needed to allocate twice as
many IP addresses to each lab. I don't think it's currently posted
anywhere, but if anyone's interested we could put it up or send it direct.

[s***@nethelp.no]

> > What you really want is the long asked for ability to prefer MAC address
> > (only) and ignore the UID. This is unfortunately not possible with the
> > current ISC DHCP.
> >
> > I believe that if you look back in the archives you may find a patch
> > which implements this - but for a previous version of ISC DHCP. Current
> > status of this patch is unknown.
>
> We have an implementation of this applicable to current release
> versions, I'm pretty sure it was submitted to ISC but I don't think we
> ever heard back on it. Our use case was computing labs that dual booted
> windows/linux, where windows used a UID and didn't like to release the
> address. Without this feature, we would have needed to allocate twice as
> many IP addresses to each lab. I don't think it's currently posted
> anywhere, but if anyone's interested we could put it up or send it direct.

It would be very nice if you could publish this patch on the net. I am
definitely interested myself, and sure others are too.

Steinar Haug, Nethelp consulting, ***@nethelp.no

[Neff, Glen]

> > > What you really want is the long asked for ability to prefer MAC address
> > > (only) and ignore the UID. This is unfortunately not possible with the
> > > current ISC DHCP.
> > >
> > > I believe that if you look back in the archives you may find a patch
> > > which implements this - but for a previous version of ISC DHCP. Current
> > > status of this patch is unknown.
> >
> > We have an implementation of this applicable to current release
> > versions, I'm pretty sure it was submitted to ISC but I don't think we
> > ever heard back on it. Our use case was computing labs that dual booted
> > windows/linux, where windows used a UID and didn't like to release the
> > address. Without this feature, we would have needed to allocate twice as
> > many IP addresses to each lab. I don't think it's currently posted
> > anywhere, but if anyone's interested we could put it up or send it direct.
>
> It would be very nice if you could publish this patch on the net. I am
> definitely interested myself, and sure others are too.

Yes, I would like access to it as well.

-G

/*
* Glen R. J. Neff
* USD Lab Operations Infrastructure Team
* ***@emc.com
*
* EMC^2 == E^2
*/

[Paul B. Henson]

On Thu, Jan 10, 2013 at 06:40:49AM +0100, ***@nethelp.no wrote:

> It would be very nice if you could publish this patch on the net. I am
> definitely interested myself, and sure others are too.

I think the link was sent directly to the two individuals who expressed
interest, but for the rest of the list and the archives:

http://www.csupomona.edu/~bldewolf/dhcp-uid/