Re: [Kea-users] ignore the broadcast flag in a discover and response with unicast

[Francis Dupont]

It requires to write code but it does not strictly require C++ code even
it this case it will be simpler than to master interfaces between C++
and "external" languages as Python, OCaml, Lua or V8 cf. the fdxhook
branch available on github where I describe such experiment.

Regards

Francis Dupont 
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] ignore the broadcast flag in a discover and response with unicast

[Marcin Siodelski]

That obviously requires writing a C++ code. But, the good news is that we have 
hooks examples provided with Kea code and documentation.

Marcin

On 13.11.2017 15:50, Rene Stoutjesdijk wrote:
> Hello Marcin,
>
> thx for pointing me into that direction.
> i'll have a closer look into it.
>
> wkr
> rene
>
> On Mon, Nov 13, 2017 at 1:21 PM, Marcin Siodelski  > wrote:
>
>     Hello,
>     Any non-standard behavior like this can be implemented using hooks.
>     You'd need to create a simple hook library which implements
>     pkt4_send callout.
>
>     See:
>     -https://jenkins.isc.org/job/Kea_doc/doxygen/index.html#hooksFramework
>     -https://jenkins.isc.org/job/Kea_doc/doxygen/de/df3/dhcpv4Hooks.html
>          -https://jenkins.isc.org/job/Kea_doc/doxygen/de/df3/dhcpv4Hooks.html>
>
>     Marcin Siodelski
>     ISC
>
>
>     On 11.11.2017 16:23, Rene Stoutjesdijk wrote:
>     > Good day,
>     > i'm new too the list and couldn't find yet an answer to my challenge,
>     > hopefully you can help.
>     >
>     > Is it possible to setup KEA for DHCPv4 in such a way that:
>     > - if a discover comes in then following items are checked:
>     >    - if a gi-addr is being used and if the broadcast_flag (0x8000)
>     is set
>     >         then the response will be set with a unicast flag
>     >
>     >
>     >
>     > thx in advance for your response
>     >
>     >
>     >
>     >
>     >
>     > ___
>     > Kea-users mailing list
>     > Kea-users@lists.isc.org 
>     > 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] ignore the broadcast flag in a discover and response with unicast

[Rene Stoutjesdijk]

Hello Marcin,

thx for pointing me into that direction.
i'll have a closer look into it.

wkr
rene

On Mon, Nov 13, 2017 at 1:21 PM, Marcin Siodelski  wrote:

> Hello,
> Any non-standard behavior like this can be implemented using hooks. You'd
> need to create a simple hook library which implements pkt4_send callout.
>
> See:
> -https://jenkins.isc.org/job/Kea_doc/doxygen/index.html#hooksFramework
> -https://jenkins.isc.org/job/Kea_doc/doxygen/de/df3/dhcpv4Hooks.html
>
> Marcin Siodelski
> ISC
>
>
> On 11.11.2017 16:23, Rene Stoutjesdijk wrote:
> > Good day,
> > i'm new too the list and couldn't find yet an answer to my challenge,
> > hopefully you can help.
> >
> > Is it possible to setup KEA for DHCPv4 in such a way that:
> > - if a discover comes in then following items are checked:
> >- if a gi-addr is being used and if the broadcast_flag (0x8000) is set
> > then the response will be set with a unicast flag
> >
> >
> >
> > thx in advance for your response
> >
> >
> >
> >
> >
> > ___
> > Kea-users mailing list
> > Kea-users@lists.isc.org
> > 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] 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 :

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


-- 
Hug a tree before you print this e-mail
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] subnet scope DHCPv4 options in database?

[Owen Dunn]

On Sat, 11 Nov 2017, Tomek Mrugalski wrote:


W dniu 10.11.2017 o 16:27, Owen Dunn pisze:

However, it seems that subnet-scope options in the dhcp4_options table
are not processed.

Not supported yet. This is currently planned for 1.5.

Currently (1.3) you can store options associated with host reservations.


Ah, OK.  Well, since these are all views on a database I can fix it up 
behind the scenes :-)



I have my subnet (with id 29) defined in the config file, and kea is
able to give my client the correct reserved address.  However, the
options for that subnet in my dhcp4_options table are not passed on. 
What am I doing wrong?

Nothing. Is there any part of the User's guide that suggested this is
supported? If there is, please point it out and we'll make the docs more
clear.


It was this wiki page http://kea.isc.org/wiki/HostReservationsHowTo and in 
particular the Postgres code which inserted something into the 
dhcp4_options table with subnet scope.


Owen___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [Kea-users] ignore the broadcast flag in a discover and response with unicast

[Marcin Siodelski]

Hello,
Any non-standard behavior like this can be implemented using hooks. You'd need 
to create a simple hook library which implements pkt4_send callout.

See:
-https://jenkins.isc.org/job/Kea_doc/doxygen/index.html#hooksFramework
-https://jenkins.isc.org/job/Kea_doc/doxygen/de/df3/dhcpv4Hooks.html

Marcin Siodelski
ISC


On 11.11.2017 16:23, Rene Stoutjesdijk wrote:
> Good day,
> i'm new too the list and couldn't find yet an answer to my challenge,
> hopefully you can help.
>
> Is it possible to setup KEA for DHCPv4 in such a way that:
> - if a discover comes in then following items are checked:
>    - if a gi-addr is being used and if the broadcast_flag (0x8000) is set
>         then the response will be set with a unicast flag
>
>
>
> thx in advance for your response
>
>
>
>
>
> ___
> Kea-users mailing list
> Kea-users@lists.isc.org
> 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