public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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




  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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal