Re: [pve-devel] [RFC cluster/manager/network 0/6] Add support for DHCP servers to SDN

["DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>]

Hi,

I'm going to do a POC with kea dhcp and host reservations

It seem possible to dynamically inject reservations with need to reload
the daemon (and only 1 daemon is needed for all interfaces/bridges)
https://ftp.iij.ad.jp/pub/network/isc/kea/1.5.0-P1/doc/kea-guide.html#host-cmds


I'll try to do something like:

- at vm create (or nic create), create a reservation in ipam (the code
is already here) if user want a persistant ip.  (maybe add something 
like :  net:....., dhcp=(unmanaged|persistant|ephemeral)


- at vm start,  
   if dhcp=persistant,look in ipam for reserved ip address, 
   if dhcp=ephemeral, allocation a new ip in pam

   and inject host reservation in local kea.


- at vm stop, remove reservation from local kea
   if dhcp=ephemeral, remove ip from ipam


- at vm destroy or nic detroy, if dhcp=persistant, remove the ip from
ipam




About kea, it seem also possible to allocate /32 leases with soom
hooks, could be usefull too for users with routed setup
https://github.com/zorun/kea-hook-runscript/blob/master/examples/slash32_leases/README.md

Le lundi 11 septembre 2023 à 03:53 +0000, DERUMIER, Alexandre a écrit :
> 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,...)
> 
> 
> 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.
> 
> 
> 
> 
> What do you think about it ?
> 
> 
> Le vendredi 08 septembre 2023 à 15:42 +0200, Stefan Hanreich a
> écrit :
> > This patch series adds support for automatically deploying dnsmasq
> > as
> > a DHCP
> > server to a simple SDN Zone.
> > 
> > While certainly not 100% polished on some ends (looking at
> > restarting
> > systemd
> > services in particular), the general idea behind the mechanism
> > shows.
> > I wanted
> > to gather some feedback on how I approached designing the plugins
> > and
> > the
> > config regeneration process before comitting to this design by
> > creating an API
> > and UI around it.
> > 
> > For your testing convenience I've provided deb packages on our
> > share:
> >   /path/to/nasi/iso/packages/shan-sdn-dhcp
> > 
> > You need to install dnsmasq (and disable it afterwards):
> > 
> >   apt install dnsmasq && systemctl disable --now dnsmasq
> > 
> > 
> > You can use the following example configuration for deploying a
> > DHCP
> > server in
> > a SDN subnet:
> > 
> > /etc/pve/sdn/dhcp.cfg:
> > 
> >   dnsmasq: nat
> > 
> > 
> > /etc/pve/sdn/zones.cfg:
> > 
> >   simple: DHCPNAT
> >           ipam pve
> > 
> > 
> > /etc/pve/sdn/vnets.cfg:
> > 
> >   vnet: dhcpnat
> >           zone DHCPNAT
> > 
> > 
> > /etc/pve/sdn/subnets.cfg:
> > 
> >   subnet: DHCPNAT-10.1.0.0-16
> >           vnet dhcpnat
> >           dhcp-dns-server 10.1.0.1
> >           dhcp-range server=nat,start-address=10.1.0.100,end-
> > address=10.1.0.200,lease-time=86400
> >           dhcp-range server=nat,start-address=10.1.1.100,end-
> > address=10.1.1.200,lease-time=86400,dns-server=10.1.0.2
> >           gateway 10.1.0.1
> >           snat 1
> > 
> > 
> > Then apply the SDN configuration:
> > 
> >   pvesh set /cluster/sdn
> > 
> > 
> > Be careful that after configuring dhcp-range you do not save the
> > subnet config
> > from the Web UI, since the dhcp-range line will vanish from the
> > config.
> > 
> > 
> > 
> > pve-cluster:
> > 
> > Stefan Hanreich (1):
> >   cluster files: add dhcp.cfg
> > 
> >  src/PVE/Cluster.pm  | 1 +
> >  src/pmxcfs/status.c | 1 +
> >  2 files changed, 2 insertions(+)
> > 
> > 
> > pve-manager:
> > 
> > Stefan Hanreich (1):
> >   sdn: regenerate DHCP config on reload
> > 
> >  PVE/API2/Network.pm | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > 
> > pve-network:
> > 
> > Stefan Hanreich (4):
> >   sdn: dhcp: add abstract class for DHCP plugins
> >   sdn: dhcp: subnet: add DHCP options to subnet configuration
> >   sdn: dhcp: add DHCP plugin for dnsmasq
> >   sdn: dhcp: regenerate config for DHCP servers on reload
> > 
> >  debian/control                      |   1 +
> >  src/PVE/Network/SDN.pm              |  11 ++-
> >  src/PVE/Network/SDN/Dhcp.pm         | 122
> > ++++++++++++++++++++++++++++
> >  src/PVE/Network/SDN/Dhcp/Dnsmasq.pm | 115
> > ++++++++++++++++++++++++++
> >  src/PVE/Network/SDN/Dhcp/Makefile   |   8 ++
> >  src/PVE/Network/SDN/Dhcp/Plugin.pm  |  76 +++++++++++++++++
> >  src/PVE/Network/SDN/Makefile        |   4 +-
> >  src/PVE/Network/SDN/SubnetPlugin.pm |  43 ++++++++++
> >  8 files changed, 377 insertions(+), 3 deletions(-)
> >  create mode 100644 src/PVE/Network/SDN/Dhcp.pm
> >  create mode 100644 src/PVE/Network/SDN/Dhcp/Dnsmasq.pm
> >  create mode 100644 src/PVE/Network/SDN/Dhcp/Makefile
> >  create mode 100644 src/PVE/Network/SDN/Dhcp/Plugin.pm
> > 
> > 
> > Summary over all repositories:
> >   11 files changed, 380 insertions(+), 3 deletions(-)
> > 
> > --
> > murpp v0.4.0
> > 
> > 
> > _______________________________________________
> > pve-devel mailing list
> > pve-devel@lists.proxmox.com
> > https://antiphishing.cetsi.fr/proxy/v3?i=SHV0Y1JZQjNyckJFa3dUQiblhF5YcUqtiWCaK_ri0kk&r=T0hnMlUyVEgwNmlmdHc1NSqeTQ1pLQVNn4UvDLnWe4fCxNuytxXrtkvXRfHgEH29SgNUOJTfU-F2je9BBTq-sg&f=V3p0eFlQOUZ4czh2enpJS6vlBYwhEUcOwTmUN-Hu71ZWogcUGH-slS7gYzVrVVB6_wb2zNaC4g2GRLF4nWvKLw&u=https%3A//lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel&k=ZVd0
> > 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel