From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 4568D1FF139 for ; Tue, 27 Jan 2026 11:36:47 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 689701F634; Tue, 27 Jan 2026 11:37:09 +0100 (CET) Date: Tue, 27 Jan 2026 11:37:00 +0100 To: Stefan Hanreich , pve-devel@lists.proxmox.com References: <20260109121049.70740-1-klein@aetherus.de> <20260109121049.70740-2-klein@aetherus.de> <021b748f-44db-4546-8399-c6f7312a11fc@proxmox.com> <77ad7294-e8b6-4862-8ce5-b81181d1188f@proxmox.com> In-Reply-To: <77ad7294-e8b6-4862-8ce5-b81181d1188f@proxmox.com> MIME-Version: 1.0 Message-ID: List-Id: Proxmox VE development discussion List-Post: From: Maurice Klein via pve-devel Precedence: list Cc: Maurice Klein X-Mailman-Version: 2.1.29 X-BeenThere: pve-devel@lists.proxmox.com List-Subscribe: , List-Unsubscribe: , List-Archive: Reply-To: Proxmox VE development discussion List-Help: Subject: Re: [pve-devel] [PATCH container 1/1] Signed-off-by: Maurice Klein Content-Type: multipart/mixed; boundary="===============8530750266835875083==" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" --===============8530750266835875083== Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: pve-devel@lists.proxmox.com Delivered-To: pve-devel@lists.proxmox.com Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 43681E0E3C for ; Tue, 27 Jan 2026 11:37:08 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2D4EA1F610 for ; Tue, 27 Jan 2026 11:37:08 +0100 (CET) Received: from plesk01.aetherus.io (plesk01.aetherus.io [195.5.114.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Tue, 27 Jan 2026 11:37:07 +0100 (CET) Received: from [10.97.254.1] (unknown [195.5.114.21]) by plesk01.aetherus.io (Postfix) with ESMTPSA id B22EF301202; Tue, 27 Jan 2026 11:37:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetherus.de; s=default; t=1769510220; bh=dk6mq35LeadIFAls9/UD7blWTDA6EuM+jhiO+wcb/dc=; h=Subject:To:From; b=GoDPnf+hJ66C5O6nizrrE9mniJQv5B78sAr1jyS7vZgJNd7s5cDOCe+Wtv6nzRpe2 lJ4/hbmu07OOqpapNGOIc4l784UxvCnWCH6k2Rbpw99RY06myv/1C2YDT7VI2N82tK WikGQxcQvhCDjSDUIvgpV63EHUfFwlSr8CIErq925+n77bJ3uhsDl20K4GLr0X2BUQ eYKxlbbuqaOY2XSvhoCuaFYb+LcYFcO/nvLmGyLdl8wDs5zQ2qw5ctYYi5e+G+vQZ7 jJ8LAKdHoYHwoXdtXnyp8uFpj5bFeSSfXgOTflzbxNTMzvzYiIpn8Ghf8EKNOSOcjF KTsSzGuGgsCqA== Authentication-Results: plesk01; spf=pass (sender IP is 195.5.114.21) smtp.mailfrom=klein@aetherus.de smtp.helo=[10.97.254.1] Received-SPF: pass (plesk01: connection is authenticated) Message-ID: <321bd4ff-f147-4329-9788-50061d569fa6@aetherus.de> Date: Tue, 27 Jan 2026 11:37:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH container 1/1] Signed-off-by: Maurice Klein To: Stefan Hanreich , pve-devel@lists.proxmox.com References: <20260109121049.70740-1-klein@aetherus.de> <20260109121049.70740-2-klein@aetherus.de> <021b748f-44db-4546-8399-c6f7312a11fc@proxmox.com> <77ad7294-e8b6-4862-8ce5-b81181d1188f@proxmox.com> Content-Language: en-US From: Maurice Klein In-Reply-To: <77ad7294-e8b6-4862-8ce5-b81181d1188f@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <176951022087.1796819.6859862793135279642@plesk01.aetherus.io> X-PPP-Vhost: aetherus.de X-SPAM-LEVEL: Spam detection results: 0 AWL -0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy KAM_SHORT 0.001 Use of a URL Shortener for very short URL RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Hi, I didn't even think about mac address, since arp does recover quickly but it would be a unwanted interruption. I like the idea with using a bridge with l2 isolation. I'd like to implement the zone then, with the use of a l2 isolated bridge. I'd propose the first step would be to get the zone working, to get the mechanism working to add host routes. I would use one VRF then per zone. A proposed name would be "Routed". Do you have better Ideas? A roadmap I'd have in my head then would look the following way: - implement zone "Routed"    ensuring that all routing between guests and host works and that default routes get put in the vrf as well - implement possibility to export host routes of routed zones via BGP - implement possibility to add static routes per Routed zone, like different default routes or others - implement dynamic routing updates into routed zones vrf tables Where I'm still not sure is how to get routing in a cluster running between the same zone. It could be implemented via IBGP Sessions between the hosts, but i don't know if that is the preffered way and it needs to be clear to the user which path will be taken and how it works. Let me know if that is a way you agree with and if it is i would like to get started implementing the first step. Mit freundlichen Grüßen, Maurice Klein Aetherus TEL: 0212 7846460 Mail: Klein@aetherus.de Am 27.01.26 um 11:02 schrieb Stefan Hanreich: > On 1/21/26 8:04 PM, Maurice Klein wrote: > > Some thoughts below from my side, but I'm still unsure on what would be > the best approach for this. > >> I agree it would work nicely as a SDN plugin and I was also considering >> that approach. >> The problem I saw with that is that SDN relies on there being a bridge >> for every zone and making it work without one seems to be a huge refactor. >> Do you think the bridge should not be removed at all, even for a pure l3 >> routed setup? > That would be one reason, but there are others. The gateway IP only > needs to be configured once on the bridge / vnet itself then, whereas it > needs to be specified explicitly for every guest with your approach. > You'd most likely also need to generate a MAC address that is the same > for the GW on all PVE hosts, so VM mobility works properly. With tap > interfaces that is even more complicated as you'd need to handle setting > the MAC for each tap interface. It's cleaner and simpler that way imo, > since you can just set up the gateway once and be done. > > A simple zone with port isolation is already quite similar to what > you're trying to achieve imo. It denies L2 connectivity between guests > via the isolated flag [1] on bridge members and the PVE node acts as a > router for the zone. I think that could be used as a starting point and > then build upon it. Simple zones have IPAM support, so we could utilize > that for managing the guest IPs. It would probably also make sense to > manage neighbor / fdb table entries statically for this kind of setup. > > [1] https://man7.org/linux/man-pages/man8/bridge.8.html > --===============8530750266835875083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel --===============8530750266835875083==--