duplicate ip address assigned

[Simon Hobson]

Alan Batie <alan at peak.org> wrote:

> On 4/23/21 12:57 PM, Simon Hobson wrote:
>> Alan Batie <alan at peak.org> wrote:
> 
>> Is 1.1.1.200 part of the dynamic pool in the config ? I think it is because that's exactly what the warning in the log is telling you.
>> What I think has happened is that you've configured the server to allocate 1.1.1.200 to one device via a host statement with fixed-address, AND also allowed it to be dynamically allocated to another device via the dynamic allocation mechanism. The ISC server does **NOT** automatically fix this configuration error for you - but the above warning was added some years ago to alert people to the issue given that many were being caught out by it.
> 
> I tried making the pool smaller in case that was an issue and it complained about the static reservation not being in a subnet...
> 
> relevant excerpt from config:
> 
> subnet 1.1.1.0 netmask 255.255.255.0 {
>  option routers 1.1.1.1;
> 
>  pool {
>    range 1.1.1.2 1.1.1.250;
>  }
> }
> 
> host StaticCustomer {
>    hardware ethernet 00:11:22:33:44:55;
>    fixed-address 1.1.1.200;
> }
> 
> host DyanmicCustomer {
>    # keeps stealing address
>    hardware ethernet 66:66:66:66:66:66;
>    fixed-address 1.1.1.201;
> }

Post the log entry and config that caused it.


The snippet above illustrates your problem. Both 1.1.1.200 and 1.1.1.201 are within the dynamic pool and so **CAN** be given to any other client at any time. So sooner or later you'll see the same problem surface again next time client churn brings those addresses into use. The way to fix it is like this :

subnet 1.1.1.0 netmask 255.255.255.0 {
 option routers 1.1.1.1;

 pool {
   range 1.1.1.2 1.1.1.199;
   range 1.1.1.122 1.1.1.250;
 }
}

That will make it so that 200 and 201 cannot be given to a dynamic client, so the problem will disappear.

As I mentioned, it's an issue that appeared so often on this list that the code was updated to detect and warn about it. In part I think that was due to it being different to the "MS way of doing things" that many people had previously been used to.


An alternative way to manage this is with reserved allocations. If you add "reserved;" to a lease for 1.1.1.200 (and remove the host statement) then it will be reserved for that device - but is otherwise like any other dynamic lease (you do NOT exclude it from the dynamic range). But because hosts with fixed-addresses don't get lease entries, you may have to create a skeleton lease first.
I believe you can do this via OMSHELL, but I;ve not used that myself. I;ve only done it by stopping the server and editing the leases file manually.


Two ways of doing things, both have pros and cons.
Host statements with fixed-address are clear to see in the config file but don't follow the normal lease lifecycle - especially a problem with dynamic DNS.
Reserved leases follow the normal lease lifecycle, including dynamic DNS updates, but the config is hidden in the leases file. Having something that will parse the leases file would quickly show you them.


Simon