[Kea-users] Kea 1.4 HA questions

[Jeffery Harrell]

Not for nothing, but what we’re currently doing is using *unequal*-cost
multipath with Kea. We have two Kea servers (VMs) running OSPF, and the
“primary” one advertises its route with a lower cost than the “secondary”
one. Quotes because there’s absolutely no difference between the two
servers except the route metrics. If server #1 goes down (or more
realistically, is taken down for maintenance) routers just use the
next-lowest-cost route to get to the other server.


On December 13, 2017 at 1:07:22 PM, Zayer, Sebastian (
sebastian.zayer at takko.de) wrote:

Hi Jason,



if …

| 2) Server1 sends DHCPOFFER to the Client via the relay.

| 3) Client sends DHCPREQUEST via the relay, but arrives on server2.

… that happens, you should have a look at the session-management on the
HAproxy.



Just my thoughts.





With kind regards,



Sebastian




<https://m.exactag.com/cl.aspx?tc=622d63de2c2dfa4e3133f6eff7f4a2cb&url=https://www.takko.com/de-de/?utm_source=mail&utm_medium=intern&utm_campaign=Takko_DE_Mailing_Signatur>

<https://www.facebook.com/TakkoFashionDE>
<https://www.youtube.com/user/TakkoFashion1>
<https://instagram.com/takko_fashion> *Sebastian Zayer*
Specialist IT Systems

T: +49 2504 923 865
F: +49 2504 923 797
M: +49 152 21811579

Takko Holding GmbH
Alfred-Krupp-Straße 21
48291 Telgte, Deutschland

Geschäftsführer: Ulrich Eickmann, Thomas Helmreich, Alexander Mattschull,
Arnold Mattschull
Amtsgericht Münster HRB 8939 | Ust.-Id Nr. DE209094382 | *takko.com
<https://m.exactag.com/cl.aspx?tc=622d63de2c2dfa4e3133f6eff7f4a2cb&url=https://www.takko.com/de-de/?utm_source=mail&utm_medium=intern&utm_campaign=Takko_DE_Mailing_Signatur>*
Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail
erforderlich ist.

*From:* Kea-users [mailto:kea-users-bounces at lists.isc.org] *On Behalf Of *Jason
Guy
*Sent:* Wednesday, December 13, 2017 7:17 PM
*To:* KEA-Users (kea-users at lists.isc.org) <kea-users at lists.isc.org>
*Subject:* [Kea-users] Kea 1.4 HA questions



After reading the HA page http://kea.isc.org/wiki/HADesign, I realized that
the mode for Load-balancing does not state if a separate device (load
balancer) is used to direct the traffic to the servers. It would be good to
indicate how the traffic is distributed across the servers.



There is a growing trend in networking, to utilize IP equal-cost multipath
(ECMP) forwarding to reach services, rather than maintain a separate device
(like an F5 or Linux HAproxy). This does not work for all services
obviously, but I think it could work fine for DHCP, provided it is fully
HA-aware.



How will the current HA design work in the scenario where the clients are
reaching the load-balanced DHCP servers via dhcp-relay?

1) Client sends the DHCPDISCOVER, which is relayed and arrives on Server1

2) Server1 sends DHCPOFFER to the Client via the relay.

3) Client sends DHCPREQUEST via the relay, but arrives on server2.

4) Server2 should send a DHCPACK, but will it?

Is the state between the servers synchronized at each point in the overall
transaction, such that server2 can complete the lease?



I think the answer is no, because it appears that the subnet definitions in
the Kea configurations have to be manually partitioned, as explained in the
section Subnets and Pools Configuration for HA. This implies that each
server is still basically autonomous in the subnets they can allocate,
while both servers are alive.



This seems like a cumbersome way to implement HA from the user point of
view. It is much more intuitive to have a matching configuration (enforced
when the HA communication is established), and either server can perform
operations on the same resources. In openstack this is all handled via a
message queue, so redundant nodes know the active state of transactions.



Anyhow, I think this is a really cool addition to Kea. I am curious how it
will work for various data center environments I see every day, where the
microservices concept is way things are moving. It may be I misunderstood
the HAdesign page, but I would like to understand this better as I plan to
test this as soon as possible.



Cheers,

Jason
_______________________________________________
Kea-users mailing list
Kea-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171213/fd1ebcdf/attachment.htm>