[Kea-users] Suggestions solicited to help transition away from ISC DHCPd

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Kea-users] Suggestions solicited to help transition away from ISC DHCPd

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
Reply | Threaded
Open this post in threaded view
|

[Kea-users] FW: Suggestions solicited to help transition away from ISC DHCPd

Sutherland, Robert

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
Sent: Friday, March 02, 2018 3:28 PM
To: [hidden email]
Subject: [External Source] [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
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Suggestions solicited to help transition away from ISC DHCPd

Marcin Siodelski
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
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Multi-tenancy in Kea

Tomek Mrugalski
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
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Multi-tenancy in Kea

Jason Guy
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,

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


_______________________________________________
Kea-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/kea-users
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Multi-tenancy in Kea

Sutherland, Robert
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
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Multi-tenancy in Kea

Tomek Mrugalski
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
Reply | Threaded
Open this post in threaded view
|

Re: [Kea-users] Multi-tenancy in Kea

Jason Guy
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:
> 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