[Kea-users] Combining class definitions with or/and operands
Just a foreword, I am experimenting with the class definitions and different
test structures, since the examples provided in the official documentation
are very limited. Specifically, I created these match conditions, and they
seem to work just fine
"client-classes": [
{
"name": "CTS19-RPDs",
"test": "pkt4.mac == 0x0020a361415b or pkt4.mac ==
0x001848fe8f35"
},
{
"name": "CTS17-RPDs",
"test": "(pkt4.mac == 0x0020a3283bfb) or (pkt4.mac ==
0x0020a3263a4b) or (pkt4.mac == 0x0020a3263a6b) or (pkt4.mac ==
0x0020a35a1b0b)"
},
{
"name": "CTS18-RPDs",
"test": "(pkt4.mac == 0x0020a325c53b) or (pkt4.mac ==
0x0018480ae57d) or (pkt4.mac == 0x0020a32b08bb) or (pkt4.mac ==
0x0020a328e02b) or (pkt4.mac == 0x0020a357fc6b) or (pkt4.mac ==
0x0020a358a5bb) or (pkt4.mac == 0x0020a35eb56b) or (pkt4.mac ==
0x0020a35ecadb) or (pkt4.mac == 0x0018480ae35f) or (pkt4.mac ==
0x0018480ae903) or (pkt4.mac == 0x0020a35dfb3b) or (pkt4.mac ==
0x0020a380378b) or (pkt4.mac == 0x0020a34f93cb)"
}
],
As you can see, the test structure seems to not care for brackets () or not,
and does the matching well even with very long conditions.
Where the question comes is with the "client-class" statement in individual
pool / subnet definitions. In the following example, the client class
statement contains an 'or' combination for three different classes defined
before. It parses fine, but . it does not seem to work. All examples I can
find show a single entry in the client-class, but I am wondering whether the
example below is a mistake and the parser should throw an error or not. I do
know I can create another class that combines three previous classes into
one, but I find this cleaner to read, where the match in client-class is
performed on and/or combined structure of different atomic classes.
{
"id": 1,
"subnet": "172.27.60.16/28",
"relay": {
"ip-addresses": [ "172.27.60.17" ]
},
"pools": [
{
"pool": "172.27.60.18 - 172.27.60.30",
"client-class": "CTS19-RPDs or CTS18-RPDs or
CTS17-RPDs"
}
],
"option-data": [
{
"space": "dhcp4",
"name": "subnet-mask",
"code": 1,
"data": "255.255.255.240"
},
{
"space": "dhcp4",
"name": "routers",
"code": 3,
"data": "172.27.60.17"
},
{
"space": "dhcp4",
"name": "vendor-encapsulated-options",
"code": 43,
"csv-format": false,
"data": "3d04ac1b3d04"
}
]
},
Is the above shown "client-class" match condition a valid example and should
it work?
Regards
Marek
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit 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] Converting an ISC IPv6 class definition to Kea syntax
Hi Marek,
It looks to me like, in your last screenshot, that option 17 is part
of the solicit message proper rather than the relay portion. It's a
little hard to tell from screenshots.
You can split the classes up for testing (or permanently) so that you
can see exactly what is happening. For example:
{
"name": "ecm-test-1",
"test": "substring(option[17].option[2].hex,0,3) == 'ECM'"
},
{
"name": "md-test-1",
"test": "member('ecm-test-1') and
substring(relay6[2].option[18].hex,0,9) == 'Md1:0/0.0'"
},
This will cause the logs to tell you which classes the client became a
member of so that you can note which part of the test is failing.
I think I've corrected your test strings above to reflect the actual
position in the packet. If you wouldn't mind attaching the actual
packet capture, however, that would make things easier.
Thank you,
Darren Ankney
On Mon, Apr 29, 2024 at 2:19 PM Marek Hajduczenia
wrote:
>
> Thank you, Darren,
>
>
>
> That seems to work as well.
>
>
>
> I did run into another corner case, I think, though. The same table shows
> relay6[nest].option[code].hex as the only available options for classifying
> on options within the Relay6 messages. I assume this applies to option
> 17/18/37, which are part of the relay message and can be accessed at the
> level of Relay6[1] in this example below. However, there are additional
> suboptions within these options, for example, sub-option 14 within option 17,
> so relay6[1].option[17].option[14].hex would be the only way to extract and
> match on this sub-option but this does not seem to be supported today. Is
> there any specific reason as to why?
>
>
>
>
>
> The issue that I am running into is related, i.e., the Solicit message I
> receive traverses two relays as shown below
>
>
>
>
>
> and I want to classify based on option 17, sub-option 2 and also option 18 in
> relay6[1], as shown below
>
>
>
> {
>
> "name": "ecm-1",
>
> "test": "substring(option[17].option[2].hex,0,3) == 'ECM' and
> substring(relay6[1].option[18].hex,0,9) == 'Md1:0/0.0'"
>
> },
>
>
>
> but the valuation logs show the “EVAL_DEBUG_SUB_OPTION_NO_OPTION Requested
> option 17 sub-option 2, but the parent option is not present, pushing result
> 0x” error, which implies option 17, sub-option 2 is requested but not found.
> I suspect it is matching on option 17 in outer relay messages for some reason.
>
>
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUB_OPTION_NO_OPTION
> Requested option 17 sub-option 2, but the parent option is not present,
> pushing result 0x
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '3'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUBSTRING_EMPTY
> Popping length 3, start 0, string 0x pushing result 0x
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string 'ECM'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_EQUAL Popping 0x45434D
> and 0x pushing result 'false'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_OPTION Pushing option
> 18 with value 0x4D64313A302F302E3000A8705DD0DD0D
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string '9'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUBSTRING Popping
> length 9, start 0, string 0x4D64313A302F302E3000A8705DD0DD0D pushing result
> 0x4D64313A302F302E30
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text
> string 'Md1:0/0.0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_EQUAL Popping
> 0x4D64313A302F302E30 and 0x4D64313A302F302E30 pushing result 'true'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960
> DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_AND Popping 'true' and
> 'false'
Re: [Kea-users] Planning some experimentation with HA using ECMP
> On Apr 30, 2024, at 9:18 AM, Dan Geist wrote: > > Thanks Vicky. > > Facebook's dhcplb is an option, but it also solves problems that we don't > have (imbalance of DHCP messaging and need for staged deployments). It also > requires more infra (either physical or virtual) and a slightly greater > network complexity which differs from what we already support in other > services. I'm trying to stick with the "just because you have a hammer, you > should still try to use a screwdriver on screws" philosophy :) Well, for sure, not many users have Facebook’s scale, so their solution might not fit either. Recently we have had a couple of requests to write a new DHCP relay, since ISC DHCP is now EOL and Kea doesn’t include a relay. This is a thing that very few people ask for, which makes it a difficult thing to invest in. However, if there is enough interest in a load-balancer, maybe we could make a relay that is also a load balancer?? I would encourage anyone who has requirements like this to add them to https://gitlab.isc.org/isc-projects/kea/-/issues/1869, which is a ticket about requirements for a relay. One big question is whether a relay should be a version of Kea, or a completely separate (presumably simpler) implementation - any requirements that help decide that are useful. > > I suppose the WAY in which the traffic is balanced is ultimately a wash, > though. Either way, we'd need Kea instances in a horizontal N-number farm > with mostly-identical behaviors (regardless of if they listen for the virtual > IP or if it's housed one hop upstream). Ideally, having as little state as > possible (or as little state that DIFFERS between hosts) is an important > aspect. Certainly, this sounds ideal, and I thought everyone would be doing this with the lease backend. The problem is that the DHCP protocol specifically requires writing the lease to a file on disk before confirming it. This is inevitably time-consuming, and more so if you are writing it to remote shared storage with possible contention. This would mean that a local database with replication is the best way to go. We are not really database experts at ISC, so the expertise in this is going to have to come from other users. I know we have users doing this, but I am under the impression that the database replication is complicated to set up and administer and therefore not for everyone. > > Performance tuning, strategy for maintaining the database backend (monolithic > vs multiple replicating instances) and so forth will be important, but is > there anything inherent about Kea itself that will break this conceptually > (unique metadata payload in messaging that will break on DHCP refresh to a > different node or something along those lines)? Conceptually it should work and I am pretty sure there are users doing this now. (here’s an old thread on this topic https://lists.isc.org/mailman/htdig/kea-users/2017-November/001471.html ) One thing that comes to mind, are options added by the relay(s). We just added a frequently-requested feature from ISC DHCP in Kea 2.5.8 to ’stash’ options provided by the relay on the original assignment to use on refresh. I am thinking this is cached in the Kea server that originally created the lease, and *might* not work if the client renews with a different server…. I am not sure where lease 'extended info’ is stored, and whether it would be included in a separate lease backend. In any case, relay options would be path-specific, so if you depend on them, that could cause an issue with renewals. Let us know what you end up doing and how it works! > > Thanks > Dan > > - On Apr 30, 2024, at 8:39 AM, Victoria Risk wrote: > > > On Apr 29, 2024, at 6:16 PM, Dan Geist wrote: > > Hi. I have an environment where many of the network services (DNS, NTP, ToD, > etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front > of the service) and BGP. Each (of the 2 or more) service node(s) monitors the > status of that service and announces/pulls BGP announcements from the > upstream router pair. This works really well for protocols with simple > request/response transactions. > > I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the > same "virtual service IP" would be configured on each of several Kea nodes > (in addition to the real link IPs) and they would announce these to the next > hop (as above). My thinking is that if there is a common configuration and > lease backend to these multiple nodes, then this can be a way to provide HA > services (and scaling) to a very large number of devices. My only concern is > how the multi-step transaction will be handled. > > Before I spend the time to mock this up, has anyone else tried ECMP load > distribution with DHCP, specifically on Kea, and are there any "gotchas" to > be aware of? > > You might want to check out the DHCP Load Balancer from Facebook: >
[Kea-users] Kea 2.5.8 packages will be up by tomorrow
Hi Kea-users, Kea 2.5.8 is posted at https://downloads.isc.org/isc/kea/2.5.8/, but I jumped the gun a bit, and announced availability before we had built all the packages and uploaded them to Cloudsmith. So, if you are looking to download Kea 2.5.8, just wait a few hours, or until tomorrow. The usual packages will be there, after all the machines have churned and the scripts have run and the bits have transferred…. Vicky-- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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] Planning some experimentation with HA using ECMP
Brendan, we've nothing special with the use of ECMP as it's just the forwarding decision logic on the spine routers of our datacenter stack. The equal routes are all still inserted there by BGP announcements from the service nodes...I think we have a VERY similar setup. Based on what you need to do to HAVE formal HA mechanisms in place, our thinking is just to avoid it altogether (and let potential conflicts on lease reservations work themselves out with blocking calls to a config database). Hopefully the potential pitfall of having more than one node "bound" to a virtual service IP will be mitigated by nodes not being aware of each others' configurations. We'll keep the list updated with progress. Dan - On Apr 30, 2024, at 9:41 AM, Brendan Kearney wrote: > On 4/30/24 9:18 AM, Dan Geist wrote: >> Thanks Vicky. >> Facebook's dhcplb is an option, but it also solves problems that we don't >> have >> (imbalance of DHCP messaging and need for staged deployments). It also >> requires >> more infra (either physical or virtual) and a slightly greater network >> complexity which differs from what we already support in other services. I'm >> trying to stick with the "just because you have a hammer, you should still >> try >> to use a screwdriver on screws" philosophy :) >> I suppose the WAY in which the traffic is balanced is ultimately a wash, >> though. >> Either way, we'd need Kea instances in a horizontal N-number farm with >> mostly-identical behaviors (regardless of if they listen for the virtual IP >> or >> if it's housed one hop upstream). Ideally, having as little state as possible >> (or as little state that DIFFERS between hosts) is an important aspect. >> Performance tuning, strategy for maintaining the database backend >> (monolithic vs >> multiple replicating instances) and so forth will be important, but is there >> anything inherent about Kea itself that will break this conceptually (unique >> metadata payload in messaging that will break on DHCP refresh to a different >> node or something along those lines)? >> Thanks >> Dan >> - On Apr 30, 2024, at 8:39 AM, Victoria Risk [ mailto:vi...@isc.org | >> ] wrote: On Apr 29, 2024, at 6:16 PM, Dan Geist [ mailto:d...@polter.net | ] wrote: Hi. I have an environment where many of the network services (DNS, NTP, ToD, etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front of the service) and BGP. Each (of the 2 or more) service node(s) monitors the status of that service and announces/pulls BGP announcements from the upstream router pair. This works really well for protocols with simple request/response transactions. I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the same "virtual service IP" would be configured on each of several Kea nodes (in addition to the real link IPs) and they would announce these to the next hop (as above). My thinking is that if there is a common configuration and lease backend to these multiple nodes, then this can be a way to provide HA services (and scaling) to a very large number of devices. My only concern is how the multi-step transaction will be handled. Before I spend the time to mock this up, has anyone else tried ECMP load distribution with DHCP, specifically on Kea, and are there any "gotchas" to be aware of? >>> You might want to check out the DHCP Load Balancer from Facebook: [ >>> https://github.com/facebookincubator/dhcplb | >>> https://github.com/facebookincubator/dhcplb ] Thanks. Dan -- Dan Geist dan(@)polter.net -- ISC funds the development of this software with paid support subscriptions. Contact us at [ https://www.isc.org/contact/ | https://www.isc.org/contact/ ] for more information. To unsubscribe visit [ https://lists.isc.org/mailman/listinfo/kea-users | https://lists.isc.org/mailman/listinfo/kea-users ] . Kea-users mailing list [ mailto:Kea-users@lists.isc.org | Kea-users@lists.isc.org ] [ https://lists.isc.org/mailman/listinfo/kea-users | https://lists.isc.org/mailman/listinfo/kea-users ] >>> -- >>> ISC funds the development of this software with paid support subscriptions. >>> Contact us at [ https://www.isc.org/contact/ | https://www.isc.org/contact/ >>> ] >>> for more information. >>> To unsubscribe visit [ https://lists.isc.org/mailman/listinfo/kea-users | >>> https://lists.isc.org/mailman/listinfo/kea-users ] . >>> Kea-users mailing list >>> [ mailto:Kea-users@lists.isc.org | Kea-users@lists.isc.org ] >>> [ https://lists.isc.org/mailman/listinfo/kea-users | >>> https://lists.isc.org/mailman/listinfo/kea-users ] >> -- >> Dan Geist dan(@)polter.net > i do quite a bit of anycast, using BGP, which may differ from your ECMP > desires. > that said, there is probably some overlap in the
Re: [Kea-users] Planning some experimentation with HA using ECMP
On 4/30/24 9:18 AM, Dan Geist wrote: Thanks Vicky. Facebook's dhcplb is an option, but it also solves problems that we don't have (imbalance of DHCP messaging and need for staged deployments). It also requires more infra (either physical or virtual) and a slightly greater network complexity which differs from what we already support in other services. I'm trying to stick with the "just because you have a hammer, you should still try to use a screwdriver on screws" philosophy :) I suppose the WAY in which the traffic is balanced is ultimately a wash, though. Either way, we'd need Kea instances in a horizontal N-number farm with mostly-identical behaviors (regardless of if they listen for the virtual IP or if it's housed one hop upstream). Ideally, having as little state as possible (or as little state that DIFFERS between hosts) is an important aspect. Performance tuning, strategy for maintaining the database backend (monolithic vs multiple replicating instances) and so forth will be important, but is there anything inherent about Kea itself that will break this conceptually (unique metadata payload in messaging that will break on DHCP refresh to a different node or something along those lines)? Thanks Dan - On Apr 30, 2024, at 8:39 AM, Victoria Risk wrote: On Apr 29, 2024, at 6:16 PM, Dan Geist wrote: Hi. I have an environment where many of the network services (DNS, NTP, ToD, etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front of the service) and BGP. Each (of the 2 or more) service node(s) monitors the status of that service and announces/pulls BGP announcements from the upstream router pair. This works really well for protocols with simple request/response transactions. I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the same "virtual service IP" would be configured on each of several Kea nodes (in addition to the real link IPs) and they would announce these to the next hop (as above). My thinking is that if there is a common configuration and lease backend to these multiple nodes, then this can be a way to provide HA services (and scaling) to a very large number of devices. My only concern is how the multi-step transaction will be handled. Before I spend the time to mock this up, has anyone else tried ECMP load distribution with DHCP, specifically on Kea, and are there any "gotchas" to be aware of? You might want to check out the DHCP Load Balancer from Facebook: https://github.com/facebookincubator/dhcplb Thanks. Dan -- Dan Geist dan(@)polter.net -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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 -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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 -- Dan Geist dan(@)polter.net i do quite a bit of anycast, using BGP, which may differ from your ECMP desires. that said, there is probably some overlap in the what, how and why between the setups. i have 3 nodes all participating in BGP, and they inject routes to the IPs for several stateless services, like DNS, NTP, Kerberos, etc. in my BGP configs, i have set maximum-paths to 4, allowing for multiple routes to the same address. then i put the anycast IP on the loopback or some other virtual interface, so that the anycast IP is not on the wire. if i understand things correctly, this anycast setup is the way the root DNS servers are setup for their anycast configurations. i have started thinking about setting up Kea to have the "listening" interface be a VIP on the loopback, like the rest of my anycast services, but haven't gotten to a final design or game plan. i am still muttering through how Kea will work when i want to have the "listening" interface receive requests and respond to them, while using a different interface to talk to the other HA instances or to the database i'm using for configs, etc. the question i have not answered yet is, what, if any, stateful requirements are there in Kea, that would obviate the use of anycast? stateless protocols are fully self contained in request and response, and i dont know if dhcp, when served by Kea, is entirely stateless. client to server requests, and their
Re: [Kea-users] Planning some experimentation with HA using ECMP
Thanks Vicky. Facebook's dhcplb is an option, but it also solves problems that we don't have (imbalance of DHCP messaging and need for staged deployments). It also requires more infra (either physical or virtual) and a slightly greater network complexity which differs from what we already support in other services. I'm trying to stick with the "just because you have a hammer, you should still try to use a screwdriver on screws" philosophy :) I suppose the WAY in which the traffic is balanced is ultimately a wash, though. Either way, we'd need Kea instances in a horizontal N-number farm with mostly-identical behaviors (regardless of if they listen for the virtual IP or if it's housed one hop upstream). Ideally, having as little state as possible (or as little state that DIFFERS between hosts) is an important aspect. Performance tuning, strategy for maintaining the database backend (monolithic vs multiple replicating instances) and so forth will be important, but is there anything inherent about Kea itself that will break this conceptually (unique metadata payload in messaging that will break on DHCP refresh to a different node or something along those lines)? Thanks Dan - On Apr 30, 2024, at 8:39 AM, Victoria Risk wrote: >> On Apr 29, 2024, at 6:16 PM, Dan Geist wrote: >> Hi. I have an environment where many of the network services (DNS, NTP, ToD, >> etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front >> of >> the service) and BGP. Each (of the 2 or more) service node(s) monitors the >> status of that service and announces/pulls BGP announcements from the >> upstream >> router pair. This works really well for protocols with simple >> request/response >> transactions. >> I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the >> same "virtual service IP" would be configured on each of several Kea nodes >> (in >> addition to the real link IPs) and they would announce these to the next hop >> (as above). My thinking is that if there is a common configuration and lease >> backend to these multiple nodes, then this can be a way to provide HA >> services >> (and scaling) to a very large number of devices. My only concern is how the >> multi-step transaction will be handled. >> Before I spend the time to mock this up, has anyone else tried ECMP load >> distribution with DHCP, specifically on Kea, and are there any "gotchas" to >> be >> aware of? > You might want to check out the DHCP Load Balancer from Facebook: [ > https://github.com/facebookincubator/dhcplb | > https://github.com/facebookincubator/dhcplb ] >> Thanks. >> Dan >> -- >> Dan Geist dan(@)polter.net >> -- >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> To unsubscribe visit 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 > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > To unsubscribe visit 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 -- Dan Geist dan(@)polter.net -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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] Planning some experimentation with HA using ECMP
> On Apr 29, 2024, at 6:16 PM, Dan Geist wrote: > > Hi. I have an environment where many of the network services (DNS, NTP, ToD, > etc.) provide scaling, fault tolerance, and load sharing via ECMP (in front > of the service) and BGP. Each (of the 2 or more) service node(s) monitors the > status of that service and announces/pulls BGP announcements from the > upstream router pair. This works really well for protocols with simple > request/response transactions. > > I'd like to try doing this same thing with Kea dhcpv(4|6). In that setup, the > same "virtual service IP" would be configured on each of several Kea nodes > (in addition to the real link IPs) and they would announce these to the next > hop (as above). My thinking is that if there is a common configuration and > lease backend to these multiple nodes, then this can be a way to provide HA > services (and scaling) to a very large number of devices. My only concern is > how the multi-step transaction will be handled. > > Before I spend the time to mock this up, has anyone else tried ECMP load > distribution with DHCP, specifically on Kea, and are there any "gotchas" to > be aware of? You might want to check out the DHCP Load Balancer from Facebook: https://github.com/facebookincubator/dhcplb > > Thanks. > Dan > > -- > Dan Geist dan(@)polter.net > > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit 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 -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit 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
