[Kea-users] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT - conflicting reservation for address

[Mikael Bjerkeland]

We narrowed down the problem and it turned out to be caused by an ARP probe
from the device tracking feature on the Cisco switches. Adding the
following switch config resolved the issue:

ip device tracking
ip device tracking probe use-svi
ip device tracking probe auto-source fallback 0.0.0.0 0.0.0.0 override
ip device tracking probe delay 10

Thanks for the pointer, Marcin. The Windows workstation declined the lease
as it believed it was a duplicate IP.

2017-11-03 18:07 GMT+01:00 Mikael Bjerkeland <mikael at bjerkeland.com>:

> Thanks. I'll look into that after the weekend. Out of curiousity, why did
> deleting the lease from database resolve this? And why is the hwaddr and
> client_id set to \x for this particular lease? May that be why the Windows
> 10 client declines it? Not even ipconfig /release and ipconfig /renew
> worked in this case before the lease was deleted from db. I've seen it
> happen on two clients in a short period of time.
>
> The client should get its reserved address even if a lease for it already
> exists, right?
>
> Mikael
>
>
> 3. nov. 2017 17:53 skrev "Marcin Siodelski" <marcin at isc.org>:
>
> It looks like the client has declined the lease and thus it can't be
> allocated to him. Depending on the logging level, you may find the
> DECLINE packet in your log and see who and when sent it. Declined
> addresses remain in that state for a configurable amount of time. Nobody
> can be assigned those addresses as long as they remain in that state.
>
> Marcin Siodelski
> ISC
>
> On 03.11.2017 14:44, Mikael Bjerkeland wrote:
> > Hi,
> >
> > I'm a new Kea user. Just recently upgraded to 1.3.0 and went into
> > production with DHCPv4 and DHCPv6 reservations and leases stored in
> > PostgreSQL.
> >
> > Upon a reboot or change on a workstation we noticed the user was not
> > able to get its IP address anymore:
> >
> > 2017-11-03 13:15:26.269 WARN  [kea-dhcp4.alloc-engine/31631]
> > ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 f4:6d:04:0f:3f:b6],
> > cid=[01:f4:6d:04:0f:3f:b6], tid=0xe1f27234: conflicting reservation for
> > address 200.1.246.60 with existing lease Address:       200.1.246.60
> > Valid life:    86400
> > T1:            0
> > T2:            0
> > Cltt:          1509711225
> > Hardware addr:
> > Client id:     (none)
> > Subnet ID:     11
> > State:         declined
> >
> > 2017-11-03 13:15:26.272 WARN  [kea-dhcp4.alloc-engine/31631]
> > ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 f4:6d:04:0f:3f:b6],
> > cid=[01:f4:6d:04:0f:3f:b6], tid=0xe1f27234: failed to allocate an IPv4
> > address after 6 attempt(s)
> >
> > To resolve this I had to clear the lease from the lease4 table in the
> > database. Can anyone shed some light on this? The user should have
> > received its previously assigned address. Is there a config flag to
> > allow this? I am using out-of-pool reservations.
> >
> > Before deletion lease4 had the following column for this specific lease:
> >
> >   address   |     hwaddr     |    client_id     | valid_lifetime |
> >    expire         | subnet_id | fqdn_fwd | fqdn_rev |     hostname     |
> > state |    ?column?
> >  3355571772 | \x             | \x               |          86400 |
> > 2017-11-04 13:13:45+01 |        11 | f        | f        |
> >     |     1 | 2001.1.246.60
> >
> >
> > Regards,
> > Mikael
> >
> > --
> > Hug a tree before you print this e-mail
> >
> >
> > _______________________________________________
> > Kea-users mailing list
> > Kea-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/kea-users
> >
>
>
>


-- 
Hug a tree before you print this e-mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171113/6236824d/attachment.htm>