[Kea-users] Suggestions solicited to help transition away from ISC DHCPd
Locked
[Kea-users] Suggestions solicited to help transition away from ISC DHCPd
 
|
Hello all. I have an unusual situation and I was hoping for some inspiration. I'm sure that this will be entertaining as well, in a "WTF?" kind of way. I am trying to wean my company off ISC DHCPd to Kea for many reasons. The main hurdle is that the
version of DHCPd that we use has been rather extensively ... modified (other adjectives come to mind. Ones such as "butchered". But I digress.) The best way to describe these changes is to describe the intended behaviour. Our product is multi-tenanted. Each tenant has a bunch of devices (IP phones) that DHCP as expected and form part of our network plane. Many of these tenants have other devices that are also served DHCP addresses by our product. These devices
are PCs, printers and whatnot. Their network traffic never crosses the router towards our systems. Straightforward so far. Here's the wonky part: because these network segments are isolated, they can have overlapping IP ranges without conflict. In fact, the
same IP address can be assigned to devices in different tenants. I have argued that this behavior can be most charitably described as “bizarre” and that it anchors us to a particular version of DHCPd to no avail. I have no objection to writing hooks but I don’t even know where to begin. Any suggestions? Thanks, Rob
Rob Sutherland
Senior Product Developer –
silhouette R&D | Windstream
[hidden email]
| broadviewnet.com
p: 613-280-2008 (Canada)
p: 973-848-8811 (US)
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
_______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
[Kea-users] FW: Suggestions solicited to help transition away from ISC DHCPd
|
|
I think I’ll some more detail about the modified version of DHCPd. It doesn’t have to dole out leases on its own network segment.
All DHCP requests arrive via dhcrelay. The server uses the relay IP address as an index to pools of IP addresses. That’s how it can give the same IP address to multiple devices in different tenants. Rob
From: Kea-users [mailto:[hidden email]]
On Behalf Of Sutherland, Robert Hello all. I have an unusual situation and I was hoping for some inspiration. I'm sure that this will be entertaining as well, in a "WTF?" kind of way. I am trying to wean my company off ISC DHCPd to Kea for many reasons. The main hurdle is that the
version of DHCPd that we use has been rather extensively ... modified (other adjectives come to mind. Ones such as "butchered". But I digress.) The best way to describe these changes is to describe the intended behaviour. Our product is multi-tenanted. Each tenant has a bunch of devices (IP phones) that DHCP as expected and form part of our network plane. Many of these tenants have other devices that are also served DHCP addresses by our product. These devices
are PCs, printers and whatnot. Their network traffic never crosses the router towards our systems. Straightforward so far. Here's the wonky part: because these network segments are isolated, they can have overlapping IP ranges without conflict. In fact, the
same IP address can be assigned to devices in different tenants. I have argued that this behavior can be most charitably described as “bizarre” and that it anchors us to a particular version of DHCPd to no avail. I have no objection to writing hooks but I don’t even know where to begin. Any suggestions? Thanks, Rob
Rob Sutherland
Senior Product Developer –
silhouette R&D | Windstream
[hidden email]
| broadviewnet.com
p: 613-280-2008 (Canada)
p: 973-848-8811 (US)
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Suggestions solicited to help transition away from ISC DHCPd
|
|
In reply to this post by Sutherland, Robert
Hi Rob,
Thanks for posting your inquiry. The major hurdle you're going to have with Kea is that it expects that IPv4 addresses are unique within the lease database. We're considering to allow non-unique IPv4 addresses if they belong to different subnets but this is a future. The 1.4.0 release of Kea will still have this limitation. Kinds Regards, Marcin Siodelski ISC On 02.03.2018 21:28, Sutherland, Robert wrote: > Hello all. > > I have an unusual situation and I was hoping for some inspiration. I'm > sure that this will be entertaining as well, in a "WTF?" kind of way. I > am trying to wean my company off ISC DHCPd to Kea for many reasons. The > main hurdle is that the version of DHCPd that we use has been rather > extensively ... modified (other adjectives come to mind. Ones such as > "butchered". But I digress.) The best way to describe these changes is > to describe the intended behaviour. > > Our product is multi-tenanted. Each tenant has a bunch of devices (IP > phones) that DHCP as expected and form part of our network plane. Many > of these tenants have other devices that are also served DHCP addresses > by our product. These devices are PCs, printers and whatnot. Their > network traffic never crosses the router towards our systems. > > Straightforward so far. Here's the wonky part: because these network > segments are isolated, they can have overlapping IP ranges without > conflict. In fact, the *_same_* IP address can be assigned to devices in > different tenants. > > I have argued that this behavior can be most charitably described as > “bizarre” and that it anchors us to a particular version of DHCPd to no > avail. I have no objection to writing hooks but I don’t even know where > to begin. > > Any suggestions? > > Thanks, > > Rob > > *Rob Sutherland* > > Senior Product Developer – /silhouette/ R&D | Windstream > > [hidden email] > <mailto:[hidden email]> | broadviewnet.com > > *p:*613-280-2008 (Canada) > > *p:*973-848-8811 (US) > > > > > > This email message and any attachments are for the sole use of the > intended recipient(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, > please contact the sender by reply email and destroy all copies of the > original message and any attachments. > > > _______________________________________________ > Kea-users mailing list > [hidden email] > https://lists.isc.org/mailman/listinfo/kea-users > _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Multi-tenancy in Kea
|
|
Hi Rob,
I did a little experiment. With a bit of code tweaking, I managed to force Kea to load two identical subnets that only differed in relay IP address. It started all fine and I was able to get leases in each subnet. There's one major caveat, though. Allocation engine, the core part of the code that picks leases for new clients, can't tell a difference between them and thinks the address is used, despite it being used in the other subnet. My subnets defined were 192.0.2.1 - 192.0.2.200. First client in the first subnet got 192.0.2.1 (as expected), but the second client in the second subnet got 192.0.2.2, not 192.0.2.1. If your subnets are large (e.g. 10.0.0.0/8) you may not care. If they're smaller, you'll use up all addresses real quick. To implement it properly, we would have to remove getLeases4(addr) call and implement getLeases4(addr, subnet-id) instead. There's tons of uses of getLease4(addr) throughout the whole code (around 200 instances). This would require a MAJOR rework of Kea code and the reworked code would probably we worse than it is now. So am afraid it's unlikely to happen. At least in official master. I can imagine you hacking Kea code similar way you did dhcpd would be somewhat realistic, if you accept that certain things will be broken. Keep in mind that tweaking the code to allocate the leases is only the first step on this dark and twisted path. The next step that will probably not work is lease renewal. Then release release. After that you'll face probably broken lease expiration. Commands related to leases won't work etc. You can end up with all sorts of messed up situations, like client from one network renewing a lease from another subnet, then his lease expiring because not being renewed. If you really want to go that path, here's a page that described my experiment: http://kea.isc.org/wiki/KeaMultiTenant Tomek _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
|
|
Hi Tomek, Are you referring to VRF support when you say Multi-Tenancy? In the latest Linux kernel (4.9+), the full VRF infrastructure is working well, but I don't think a lot of classic services have added support. It would be awesome to assign a subnet to a linux VRF. Cheers, Jason On Wed, Mar 7, 2018 at 8:24 AM, Tomek Mrugalski <[hidden email]> wrote: Hi Rob, _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Multi-tenancy in Kea
|
|
In reply to this post by Tomek Mrugalski
Tomek,
Thanks for taking a swing at this. You took the first steps of the road we took with the old DHCP daemon. While I might extend your efforts, this would leave me with a code-base that couldn't easily merge with any future versions of Kea. Rob -----Original Message----- From: Kea-users [mailto:[hidden email]] On Behalf Of Tomek Mrugalski Sent: Wednesday, March 07, 2018 8:25 AM To: [hidden email] Subject: Re: [Kea-users] Multi-tenancy in Kea Hi Rob, I did a little experiment. With a bit of code tweaking, I managed to force Kea to load two identical subnets that only differed in relay IP address. It started all fine and I was able to get leases in each subnet. There's one major caveat, though. Allocation engine, the core part of the code that picks leases for new clients, can't tell a difference between them and thinks the address is used, despite it being used in the other subnet. My subnets defined were 192.0.2.1 - 192.0.2.200. First client in the first subnet got 192.0.2.1 (as expected), but the second client in the second subnet got 192.0.2.2, not 192.0.2.1. If your subnets are large (e.g. 10.0.0.0/8) you may not care. If they're smaller, you'll use up all addresses real quick. To implement it properly, we would have to remove getLeases4(addr) call and implement getLeases4(addr, subnet-id) instead. There's tons of uses of getLease4(addr) throughout the whole code (around 200 instances). This would require a MAJOR rework of Kea code and the reworked code would probably we worse than it is now. So am afraid it's unlikely to happen. At least in official master. I can imagine you hacking Kea code similar way you did dhcpd would be somewhat realistic, if you accept that certain things will be broken. Keep in mind that tweaking the code to allocate the leases is only the first step on this dark and twisted path. The next step that will probably not work is lease renewal. Then release release. After that you'll face probably broken lease expiration. Commands related to leases won't work etc. You can end up with all sorts of messed up situations, like client from one network renewing a lease from another subnet, then his lease expiring because not being renewed. If you really want to go that path, here's a page that described my experiment: http://kea.isc.org/wiki/KeaMultiTenant Tomek _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
Re: [Kea-users] Multi-tenancy in Kea
|
|
In reply to this post by Jason Guy
On 07/03/2018 15:47, Jason Guy wrote:
> Hi Tomek, > > Are you referring to VRF support when you say Multi-Tenancy? No. Long time ago one company approached us asking about support for many hotspots, each using the same overlapping address space. Kea would see the packets coming from different relays. The company disappeared soon afterwards and nothing came out of it. Since Rob asked it, I though it may be a good time to do a quick experiment. That's it. Just wanted to make it clear there's no secret plan to develop anything in that area. > In the latest Linux kernel (4.9+), the full VRF infrastructure is > working well, but I don't think a lot of classic services have added > support. It would be awesome to assign a subnet to a linux VRF. I don't know anything about vrf, except quick look at this: https://andir.github.io/posts/linux-ip-vrf/ If you want to have overlapping address spaces, comments from my earlier mail apply. If you want Kea to just be able to provide addresses over VRF interface that are globally unique, we can explore this a bit further. How should Kea open sockets here - one for each vrf interface (10 customers = 10 sockets)? We already have a knob for setting outbound interface (search for outbound-interface here https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html). There are some improvements coming in that area soon (http://kea.isc.org/ticket/5515). Tomek _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
|
|
Hi Tomek, I have no requirements for VRF support currently. I was just curious if that is the "multi-tenancy" being referenced... I realize this is a rather generic term, and can be used to refer to anything that creates separation in the forwarding plane. Thanks for the explanation, Jason On Thu, Mar 8, 2018 at 3:22 AM, Tomek Mrugalski <[hidden email]> wrote: On 07/03/2018 15:47, Jason Guy wrote: _______________________________________________ Kea-users mailing list [hidden email] https://lists.isc.org/mailman/listinfo/kea-users |
| Free forum by Nabble | Edit this page |