From: Stefan Hanreich <s.hanreich@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
"DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
Subject: Re: [pve-devel] [RFC cluster/manager/network 0/6] Add support for DHCP servers to SDN
Date: Wed, 13 Sep 2023 10:54:18 +0200 [thread overview]
Message-ID: <d047f4fd-bdba-c7d9-64b6-5dfd5e5faccb@proxmox.com> (raw)
In-Reply-To: <2fd1071602ad075d4580d62565fc757e4bd92a91.camel@groupe-cyllene.com>
Sorry for my late reply, I was a bit busy the last two days and I also
wanted some time to think about your suggestions.
On 9/11/23 05:53, DERUMIER, Alexandre wrote:
> Hi,
>
> I think we should think how we want to attribute ips to the vms before
> continue the implementation. >
> I think they are 2 models:
>
> 1)
>
> - we want that dhcp server attribute itself ips && leases from the
> subnets/ranges configured.
>
> That mean that leases need to be shared across nodes. (from the same
> cluster maybe with /etc/pve tricks, but in real world, it should also
> works across multiple clusters, as it's not uncommon to shared subnets
> in differents cluster, public network,...)
>
> So we don't have that 2 differents vms starting on the same time on 2
> differents cluster, receive the same ips. (so dhcp servers need to use
> some kind of central lock,...)
>
This is also something I have thought about, but I assume dnsmasq is not
really built in mind with multiple instances accessing the same leases file.
This problem would be solved by using distributed DHCP servers like kea.
kea on the other hand has the issue that it we need to set up a SQL
database or other external storage. Alternatively we need to write a new
backend for kea that integrates with our pmxcfs.
This is partly why I think Thomas mentioned implementing our own DHCP
server, where we have the flexibility of handling things as we see fit.
Then we can just recommend the dnsmasq plugin for simple setups (e.g.
single node setups), while more advanced setups should opt for other
DHCP backends.
>
> 2)
>
> The other way (my preferred way), could be to use ipam. (where we
> already have local ipam, or external ipams like netbox/phpipam for
> sharing between multiple cluster).
>
>
> The ip is reserved in ipam (automatic find next free ip at vm creation
> for example, or manually in the gui, or maybe at vm start if we want
> ephemeral ip), then registered dns,
> and generated dhcp server config with mac-ip reserversation. (for dhcp
> server config generation, it could be a daemon pooling the ipam
> database change for example)
>
> Like this, no need to handle lease sharing, so it can work with any
> dhcp server.
>
Implementing this via IPAM plugins seems like a good idea, but if we
want to use distributed DHCP servers like kea (or our own
implementation) then this might not be needed in those cases. It also
adds quite a bit of complexity.
With dnsmasq there is even the possibility of running scripts (via
--dhcp-script, see the docs [1]) when a lease is added / changed /
deleted. But as far as I can tell this can not be used to override the
IP that dnsmasq provides via DHCP, so it is probably not really useful
for our use-case.
------
Another method that I had in mind was providing a DHCP forwarding plugin
that proxies the DHCP requests to another DHCP server (that can then
even be outside the cluster). This way there is only one DHCP server
that handles keeping track of the leases and you do not have the issue
of having to handle sharing a lease database / using IPAM. So, for
instance, you have a DHCP server running on one node and the other nodes
just proxy their requests to the one DHCP server.
I was also thinking we could implement setting the IP for a specific VM
on interfaces where we have a DHCP server, since we can then just
provide fixed IPs for specific MAC-addresses. This could be quite
convenient.
[1] https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
next prev parent reply other threads:[~2023-09-13 8:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 13:42 Stefan Hanreich
2023-09-08 13:42 ` [pve-devel] [RFC pve-cluster 1/6] cluster files: add dhcp.cfg Stefan Hanreich
2023-09-08 13:43 ` [pve-devel] [RFC pve-manager 2/6] sdn: regenerate DHCP config on reload Stefan Hanreich
2023-09-08 13:43 ` [pve-devel] [RFC pve-network 3/6] sdn: dhcp: add abstract class for DHCP plugins Stefan Hanreich
2023-09-08 13:43 ` [pve-devel] [RFC pve-network 4/6] sdn: dhcp: subnet: add DHCP options to subnet configuration Stefan Hanreich
2023-09-11 4:03 ` DERUMIER, Alexandre
2023-09-13 8:37 ` Stefan Hanreich
2023-09-08 13:43 ` [pve-devel] [RFC pve-network 5/6] sdn: dhcp: add DHCP plugin for dnsmasq Stefan Hanreich
2023-09-08 13:43 ` [pve-devel] [RFC pve-network 6/6] sdn: dhcp: regenerate config for DHCP servers on reload Stefan Hanreich
2023-09-11 3:53 ` [pve-devel] [RFC cluster/manager/network 0/6] Add support for DHCP servers to SDN DERUMIER, Alexandre
2023-09-13 8:18 ` DERUMIER, Alexandre
2023-09-13 8:54 ` Stefan Hanreich [this message]
2023-09-13 9:26 ` DERUMIER, Alexandre
2023-09-13 11:37 ` Thomas Lamprecht
2023-09-13 11:43 ` DERUMIER, Alexandre
2023-09-13 11:50 ` Stefan Hanreich
2023-09-13 12:40 ` Thomas Lamprecht
2023-09-13 12:50 ` DERUMIER, Alexandre
2023-09-13 13:05 ` Stefan Hanreich
2023-09-13 13:21 ` DERUMIER, Alexandre
2023-09-13 13:48 ` Stefan Hanreich
2023-09-13 13:52 ` Stefan Hanreich
2023-09-14 13:15 ` DERUMIER, Alexandre
2023-09-20 21:48 ` DERUMIER, Alexandre
2023-09-26 11:20 ` Stefan Hanreich
2023-09-26 13:07 ` DERUMIER, Alexandre
2023-09-26 14:12 ` Stefan Hanreich
2023-09-26 16:55 ` DERUMIER, Alexandre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d047f4fd-bdba-c7d9-64b6-5dfd5e5faccb@proxmox.com \
--to=s.hanreich@proxmox.com \
--cc=alexandre.derumier@groupe-cyllene.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox