From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 27DEB1FF0AB for ; Wed, 21 Oct 2026 08:16:49 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id EA4652160B; Wed, 21 Oct 2026 08:16:45 +0200 (CEST) Message-ID: <2001674a-32d1-4ae4-a7c8-4d989eea0fce@proxmox.com> Date: Wed, 21 Oct 2026 08:16:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Hannes Laimer Subject: Re: [PATCH pve-network v3 09/17] sdn: dhcp: add an eBPF backend answering on each guest interface To: Stefan Hanreich , pve-devel@lists.proxmox.com References: <20261020080005.470757-1-h.laimer@proxmox.com> <20261020080005.470757-10-h.laimer@proxmox.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792563401575 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.395 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: EAGM7EXT7XBXETNIMKFZVY7ORTIOUIBT X-Message-ID-Hash: EAGM7EXT7XBXETNIMKFZVY7ORTIOUIBT X-MailFrom: h.laimer@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2026-10-20 15:11, Stefan Hanreich wrote: > On 10/20/26 10:04 AM, Hannes Laimer wrote: >> The ebpf DHCP backend answers DHCPv4 from a program in the kernel on >> every guest interface of its zones, with the address the SDN MAC cache >> holds for the interface's MAC. No server runs per zone, and IPv6 >> subnets are not served. A subnet without a gateway is served under a >> link-local server identifier no host owns, so its guests renew by >> broadcast at their rebinding time. >> >> An apply runs a full pass on each node, and on a node that no zone >> with the ebpf backend includes, the pass removes the responder >> altogether. A record change rewrites the answers for its MAC on the >> node the change is made on, and the other nodes catch up at their >> next apply. >> >> The responder is pinned in bpffs and does not survive a reboot, so a >> boot hook runs a full pass. Removing the package deletes those pins, >> since nothing would detach the responder afterward. >> >> Signed-off-by: Hannes Laimer >> --- [..] >> +# the NIC lines come from pmxcfs in one go, so no guest config gets parsed for >> +# this. With a vmid only that guest's lines are fetched >> +sub guest_nics { >> + my ($vmid) = @_; >> + >> + # a hook script starts with the cluster cache empty >> + PVE::Cluster::cfs_update(); >> + my $vmlist = PVE::Cluster::get_vmlist(); >> + my $nets = PVE::Cluster::get_guest_config_properties([map { "net$_" } 0 .. 31], $vmid); >> + my $nics = []; >> + for my $vmid (sort keys %$nets) { >> + my $guest = $vmlist->{ids}->{$vmid} // next; >> + my $prefix = ($guest->{type} // '') eq 'lxc' ? 'veth' : 'tap'; >> + for my $key (sort keys %{ $nets->{$vmid} }) { >> + my ($index) = $key =~ m/^net(\d+)$/ or next; >> + my $net = $nets->{$vmid}->{$key}; >> + my ($bridge) = $net =~ m/(?:^|,)bridge=([^,]+)/ or next; >> + # a VM names the MAC as the value of its model, a container as hwaddr >> + my ($mac) = $net =~ m/(?:^|,)[a-z0-9_-]+=([0-9a-f]{2}(?::[0-9a-f]{2}){5})(?:,|$)/i; > > Is there a reason for not using the pre-existing parse_net / > parse_lxc_network functions in qemu-server / pve-container here? > They'd provide a standalone way of parsing the property string only, > without re-implementing the logic here. > > Circular dependencies potentially? yes, both depend on pve-network :/ the lxc helper also fills the mac if missing, and for `parse_property_string` we'd need the format > >> + push @$nics, >> + { >> + vmid => $vmid, >> + node => $guest->{node}, >> + iface => "$prefix${vmid}i$index", >> + bridge => $bridge, >> + mac => $mac, >> + }; >> + } >> + } >> + >> + return $nics; >> +} >> + [..]