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 EA6F31FF13B for ; Tue, 27 Jan 2026 11:02:13 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 211AE1E649; Tue, 27 Jan 2026 11:02:35 +0100 (CET) Message-ID: <77ad7294-e8b6-4862-8ce5-b81181d1188f@proxmox.com> Date: Tue, 27 Jan 2026 11:02:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Stefan Hanreich To: Maurice Klein , 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> Content-Language: en-US In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.724 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_SHORT 0.001 Use of a URL Shortener for very short URL SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH container 1/1] Signed-off-by: Maurice Klein X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel