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 C91B81FF17B for ; Sun, 01 Feb 2026 15:33:07 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D3CC918126; Sun, 1 Feb 2026 15:33:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetherus.de; s=default; t=1769956371; bh=qnjdR1VPC2mpU9s2OckX3Q47/gFvGj21i2pfKL/k6oE=; h=Subject:To:From; b=X8ZucnKXvX6f7rBef1R2UMM0Ox/P4LXf4JId8V3M2Md37alsRTung3yAYJikMCuQx yQLL7xmHl9Ho0UM3SnfrIsOXLGUYhZDBgNEztvAeo9YoOuAMzJeab8ogrND6OXeFkY DBgdvrhvLzGKHx0NTC84svOQqsIBietBEWItT0VjdC/clgWNp/mCfqEJJGYH9J1KqT s+ASa/W/iTFXyinKgest1dt4rECvtjqNojzcP5K4Qjlh60AaKk0NCIzMIRpxoAlfaN Mei93JO3xIz0KD5xY4NE8TLh3OSJF9SkHMf7RQIxKAPO4UjqlEZvLlkppv7WUa465H 9aGsCeru4F4mw== 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: <2a06be0f-4f4d-4c90-ab9b-4f7b062d6664@aetherus.de> Date: Sun, 1 Feb 2026 15:32:50 +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> <321bd4ff-f147-4329-9788-50061d569fa6@aetherus.de> <5d2bcf8a-ea6f-48aa-8cc6-c92cfb93311f@proxmox.com> Content-Language: en-US From: Maurice Klein In-Reply-To: <5d2bcf8a-ea6f-48aa-8cc6-c92cfb93311f@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <176995637104.2855223.2610398405210979035@plesk01.aetherus.io> X-PPP-Vhost: aetherus.de X-SPAM-LEVEL: Spam detection results: 0 AWL -0.001 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 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: 2IAVXWGJX62JCXMAZB7D4BPU5JTHUHGA X-Message-ID-Hash: 2IAVXWGJX62JCXMAZB7D4BPU5JTHUHGA X-MailFrom: klein@aetherus.de 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: So i was looking into implementation today. Unfortunately I found some points where I'm kinda stuck with the current way SDN is designed. I'm hoping you have some ideas or advise how to continue. 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. 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. 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. 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. I don't know yet what's the best way to configure guest ip addresses. My initial idea was to have that done on a per interface vm level, that is incompatible with sdn though. I don't know how it could be integrated in IPAM though, especially considering that pve IPAM isn't the only one available to be used. Mit freundlichen Grüßen, Maurice Klein Aetherus TEL: 0212 7846460 Mail: Klein@aetherus.de Am 29.01.26 um 13:20 schrieb Stefan Hanreich: > On 1/27/26 11:36 AM, Maurice Klein wrote: >> 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. > For a PoC we could just utilize the default routing table I think? VRF > support for SDN entities is something that is on the mid-term roadmap, > so if we want VRF support we'd need to be careful not to put any > barriers in that make implementing that feature harder. We'd also have > to make sure that VRFs stay unique across all entities that are using > them (currently only EVPN zone). If we generate the names analogous to > the EVPN zones we should be fine since all zones regardless of type > share the same ID space. > > With multiple VRFs, you'd ideally want to have the option to announce > the routes per-VRF. Utilizing transit VLANs for zones would make sense > then and also being able to map each VNet in a zone to a VLAN. That'd > require creating VLAN subinterfaces inside a VRF as well via our stack > and adding them to a VNet (might be done automatically) / VRF. At that > point we're building essentially what is VRF-lite though, so that's a > bit more involved. > >> 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 > I'd not necessarily put in the default route unconditionally, either as > a config option, or - if we skip VRF support for now - we'd get this for > free via implementing the VRF feature afterwards. > >> - implement possibility to export host routes of routed zones via BGP > see below > >> - implement possibility to add static routes per Routed zone, like >> different default routes or others > we would get that via VRF support as well > >> - 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. > One option would be to utilize e.g. the fabrics where we plan to add > initial support for route redistribution soon. This should get > integrated with a future VRF feature as well. That would decouple the > zone from the redistribution / announcing itself and give users > flexibility in choosing their routing protocol. Users can create > fabrics, then select which VRFs to announce via them (and apply filters > via route-maps). >