Re: [Kea-users] Best practice recommendation for reserving/blocking out VIPs?
Hi Francis, Thanks for the feedback. Your first point seems like the best practice implementation, although in practice just using a dummy MAC for a blocked-out address will work well enough. We manage reservations through an external application talking to MySQL directly, and so don't store reservations in the config file itself. cheers, Klaus On Fri, Jun 15, 2018 at 12:38 AM, Francis Dupont wrote: > I don't fully understand your problem but: > - the simplest is to not have addresses you want reserve in a pool > > - using host reservations work too but with a performance penalty > (cf out-of-pool text in the doc) and with a hairy but handle case > if you change dynamically the config (cf conflict text in the doc). > > Note you do not need to use an existing MAC in a host reservation, > the only constraint is to use a different MAC (or identifier in general) > between host reservations. > > Regards > > Francis Dupont > ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] lease6-del command
On Mon, 18 Jun 2018 16:10:16 -0400 Thomas Markwalder wrote: > Hello: > > What is occurring is that kea-ctrl-agent is attempting to execute the > command, and since it does not have a lease mgr, the command fails. The > lease-cmds hooks library should be loaded by kea-dhcp4 and kea-dhcp6, > not the control agent. Currently, none of our hook libraries should be > loaded by the kea-ctrl-agent. I originally loaded it becasue I would get this error if I didn't: 'lease6-del' command not supported. > Also be sure to include the "service" parameter with your commands so > the control agent knows which service should process the command, see > Chapter 16, Yeah, if I add in the service dhcp6 as part of the request it seems to succeed. :) Thanks! -- Tim Howe ti...@bendtel.com Data Processing541-389-8252 BendTelGPG pubkey id: CBDE9FFE ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] lease6-del command
Hello:
What is occurring is that kea-ctrl-agent is attempting to execute the
command, and since it does not have a lease mgr, the command fails. The
lease-cmds hooks library should be loaded by kea-dhcp4 and kea-dhcp6,
not the control agent. Currently, none of our hook libraries should be
loaded by the kea-ctrl-agent.
Also be sure to include the "service" parameter with your commands so
the control agent knows which service should process the command, see
Chapter 16,
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#ctrl-channel
Cheers,
Thomas Markwalder
ISC Software Engineering
On 06/18/2018 02:56 PM, Tim Howe wrote:
I am currently using postgresql lease storage for hdcpv6 and dhcpv4.
When attempting to delete a lease using lease command hook library, I
get the following reply:
[ { "result": 1, "text": "no current lease manager is available" } ]
Does this only work with memfile, or am I doing something else
wrong?
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
[Kea-users] lease6-del command
I am currently using postgresql lease storage for hdcpv6 and dhcpv4.
When attempting to delete a lease using lease command hook library, I
get the following reply:
[ { "result": 1, "text": "no current lease manager is available" } ]
Does this only work with memfile, or am I doing something else
wrong?
--
Tim Howe ti...@bendtel.com
Data Processing541-389-8252
BendTelGPG pubkey id: CBDE9FFE
___
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] kea 1.3.0 dying with mysql error
On 06/18/2018 05:03 AM, Satish Patel wrote: > Thanks you for comments, I told you half story, full story is we have two kea > instance for HA and they are pointed to galera DB cluster for centralize > Shared DB. > > Both node active and inserting records in cluster DB and everything works but > every few hour node-2 kea is dying with mentioned error, everything same node > dying. Node-1 never had any issue. > > Do you think this is clustering issue they both trying to do same thing and > one of node dying? I have check network and every possible thing but nothing > wrong there, also I have increase max_packet_size in db but no luck :( > I have galera cluster too and also observe routine cases of 'server has gone away' across sql apps, which is being dealt with by application layer checks to 'reconnect' to the db. Have not investigated the underlying cause other than tcpdump but I think this is squarely a galera / mysql issue. MIke- ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] kea 1.3.0 dying with mysql error
Thanks you for comments, I told you half story, full story is we have two kea instance for HA and they are pointed to galera DB cluster for centralize Shared DB. Both node active and inserting records in cluster DB and everything works but every few hour node-2 kea is dying with mentioned error, everything same node dying. Node-1 never had any issue. Do you think this is clustering issue they both trying to do same thing and one of node dying? I have check network and every possible thing but nothing wrong there, also I have increase max_packet_size in db but no luck :( Sent from my iPhone > On Jun 18, 2018, at 7:29 AM, Tomek Mrugalski wrote: > >> On 18/06/2018 01:07, Satish Patel wrote: >> I have configured kea 1.3.0 with mysql and everything works but after >> few hours found kea is dead and spotted following error in log, I have >> check everything mysql running fine everything looks good in DB. >> >> 2018-06-15 11:48:55.798 INFO [kea-dhcp4.dhcp4/16020] DHCP4_STARTED >> Kea DHCPv4 server version 1.3.0 started >> 2018-06-15 12:01:29.048 ERROR [kea-dhcp4.dhcpsrv/16020] >> DHCPSRV_MYSQL_FATAL_ERROR Unrecoverable MySQL error occurred: unable >> to execute for > h.dhcp_identifier_type, h.dhcp4_subnet_id, h.dhcp6_subnet_id, >> h.ipv4_address, h.hostname, h.dhcp4_client_classes, >> h.dhcp6_client_classes, h.dhcp4_next_server, h.dhcp4_server_hostname, >> h.dhcp4_boot_file_name, o.option_id, o.code, o.value, >> o.formatted_value, o.space, o.persistent FROM hosts AS h LEFT JOIN >> dhcp4_options AS o ON h.host_id = o.host_id WHERE h.dhcp4_subnet_id = >> ? AND h.dhcp_identifier_type = ?AND h.dhcp_identifier = ? ORDER BY >> h.host_id, o.option_id>, reason: MySQL server has gone away (error >> code: 2006). Server exiting now! > Translation to plain English: MySQL server has gone away (i.e. Kea > connection to MySQL server was terminated for whatever reason, DB > restart, temporary network failure, etc). > > In this state Kea would be useless. It would not be able to answer any > packets as it couldn't check lease state, create new leases, extend > existing ones etc. Continuing in this state would give users a false > impression that the server is somehow functional. Therefore kea 1.3 > terminates itself as soon as database failure is detected. > > This has been improved in 1.4. Kea attempts to reconnect. If this > behavior makes you unhappy, please upgrade. > >> 2018-06-15 12:01:29.055 INFO [kea-dhcp4.legal-log/16020] >> LEGAL_LOG_FILE_CLOSED @@Missing placeholder %1 for >> '/var/log//kea-forensic4.20180615.txt'@@ > This is begign bug in our logging routines. I've submitted bug #5653 for > this. You can view (and possibly comment on it if you like) here: > https://kea.isc.org/ticket/5653 > > Tomek > ___ > 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] kea 1.3.0 dying with mysql error
On 18/06/2018 01:07, Satish Patel wrote: > I have configured kea 1.3.0 with mysql and everything works but after > few hours found kea is dead and spotted following error in log, I have > check everything mysql running fine everything looks good in DB. > > 2018-06-15 11:48:55.798 INFO [kea-dhcp4.dhcp4/16020] DHCP4_STARTED > Kea DHCPv4 server version 1.3.0 started > 2018-06-15 12:01:29.048 ERROR [kea-dhcp4.dhcpsrv/16020] > DHCPSRV_MYSQL_FATAL_ERROR Unrecoverable MySQL error occurred: unable > to execute for h.dhcp_identifier_type, h.dhcp4_subnet_id, h.dhcp6_subnet_id, > h.ipv4_address, h.hostname, h.dhcp4_client_classes, > h.dhcp6_client_classes, h.dhcp4_next_server, h.dhcp4_server_hostname, > h.dhcp4_boot_file_name, o.option_id, o.code, o.value, > o.formatted_value, o.space, o.persistent FROM hosts AS h LEFT JOIN > dhcp4_options AS o ON h.host_id = o.host_id WHERE h.dhcp4_subnet_id = > ? AND h.dhcp_identifier_type = ?AND h.dhcp_identifier = ? ORDER BY > h.host_id, o.option_id>, reason: MySQL server has gone away (error > code: 2006). Server exiting now! Translation to plain English: MySQL server has gone away (i.e. Kea connection to MySQL server was terminated for whatever reason, DB restart, temporary network failure, etc). In this state Kea would be useless. It would not be able to answer any packets as it couldn't check lease state, create new leases, extend existing ones etc. Continuing in this state would give users a false impression that the server is somehow functional. Therefore kea 1.3 terminates itself as soon as database failure is detected. This has been improved in 1.4. Kea attempts to reconnect. If this behavior makes you unhappy, please upgrade. > 2018-06-15 12:01:29.055 INFO [kea-dhcp4.legal-log/16020] > LEGAL_LOG_FILE_CLOSED @@Missing placeholder %1 for > '/var/log//kea-forensic4.20180615.txt'@@ This is begign bug in our logging routines. I've submitted bug #5653 for this. You can view (and possibly comment on it if you like) here: https://kea.isc.org/ticket/5653 Tomek ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] kea 1.3.0 dying with mysql error
Satish Patel writes: > h.host_id, o.option_id>, reason: MySQL server has gone away (error > code: 2006). Server exiting now! => it is a MySQL error so not a Kea one, but I have 2 extra comments: - google gave an idea: increase the maximum packet setting in MySQL (I am afraid it won't solve the problem but just try in the case I am wrong) - Kea 1.4 reconnects databases so the error should be transient (vs fatal) in the new 1.4 release. Regards Francis Dupont ___ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
