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 37C6B1FF13E for ; Fri, 06 Feb 2026 09:23:45 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A108520BFC; Fri, 6 Feb 2026 09:24:17 +0100 (CET) Message-ID: Date: Fri, 6 Feb 2026 09:23:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Stefan Hanreich Subject: Re: [pve-devel] [PATCH container 1/1] Signed-off-by: Maurice Klein 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> <77ad7294-e8b6-4862-8ce5-b81181d1188f@proxmox.com> <321bd4ff-f147-4329-9788-50061d569fa6@aetherus.de> <5d2bcf8a-ea6f-48aa-8cc6-c92cfb93311f@proxmox.com> <2a06be0f-4f4d-4c90-ab9b-4f7b062d6664@aetherus.de> Content-Language: en-US In-Reply-To: <2a06be0f-4f4d-4c90-ab9b-4f7b062d6664@aetherus.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.721 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 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 Message-ID-Hash: D2DSUXI3EGE5P7BVREOVXXIL44VFUBUK X-Message-ID-Hash: D2DSUXI3EGE5P7BVREOVXXIL44VFUBUK X-MailFrom: s.hanreich@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 2/1/26 3:31 PM, Maurice Klein wrote: > Basicly the vnet and subnet part I see as in issue. > Since in this kind of setup there is no defined subsets required the > current configuration doesn't fully make sense. > I guess you could still have a subnet configuration and configure all > the host addresses inside that subnet, but it's not really necessary . > Every VM route would be a /32 route and also the configured address on > that bridge (gateway field) would be a /32. We would still need a local IP on the PVE host that acts as a gateway and preferably an IP for the VM inside the subnet so you can route the traffic for the /32 IPs there. So we'd need to configure e.g. 192.0.2.0/24 as subnet, then have the host as gateway (e.g. 192.0.2.1) and each VM gets an IP inside that subnet (which could automatically be handled via IPAM / DHCP). Looking at other implementations (e.g. kube-router) there's even a whole subnet pool and each node gets one subnet from that pool - but that's easier done with containers than VMs, so I think the approach with one shared subnet seems easier (particularly for VM mobility). > When the tap interface of a vm gets plugged a route needs to be created. > Routes per VM get created with the comand ip route add 192.168.1.5/32 > dev routedbridge. > The /32 gateway address needs to be configured on the bridge as well. This could be done in in the respective tap_plug / veth_create functions inside pve-network [1]. You can override them on a per-zone basis so that would fit right in. We'd have to implement analogous functions for teardown though so we can remove the routes when updating / deleting the tap / veth. Someone has actually implemented a quite similar thing via utilizing hooks and a dedicated config files for each VM - see [2]. They're using IPv6-LL addresses though (which I would personally also prefer), but I'm unsure how it would work with windows guests for instance and it might be weird / unintuitive for some users (see my previous mail). > There needs to be some way to configure the guests IPs as well, but in > ipam there is currently no way to set a ip for a vm, it's only ip mac > bindings. That's imo the real question left, where to store the additional IPs. Zone config is awkward, PVE IPAM might be workable with introducing additional fields (and, for a PoC we could just deny using any other IPAM plugin than that and implement it later). Network device is probably the best bet, since we can then utilize the hotplug code in case an IP gets reassigned, which would be more complicated with the other approaches. The only reason why I'm reluctant is because we're introducing a property there that is specific to one particular SDN zone and unused by everything else. > A potential security flaw is also devices on that bridge can steal a > configured ip by just replying to arp. > That could be mitigated by disabling bridge learning and creating static > atp entires as well for those configured IPs. That setting should be exposed in the zone configuration and probably be on by default. There's also always the option of using IP / MAC filters in the firewall although the static fdb / neighbor table approach is preferable imo. [0] https://docs.cilium.io/en/stable/network/lb-ipam/#requesting-ips [1] https://git.proxmox.com/?p=pve-network.git;a=blob;f=src/PVE/Network/SDN/Zones.pm;h=4da94580e07d6b3dcb794f19ce9335412fa7bc41;hb=HEAD#l298 [2] https://siewert.io/posts/2022/announce-proxmox-vm-ips-via-bgp-1/