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 7425C1FF13F for ; Thu, 18 Jun 2026 15:10:51 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DE17A18EE8; Thu, 18 Jun 2026 15:10:49 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 18 Jun 2026 15:10:45 +0200 Message-Id: Subject: Re: [RFC cluster/docs/ifupdown2/manager/network/proxmox{-ebpf,-ve-rs,-perl-rs} 00/16] sdn: add microsegmentation support From: "Lukas Sichert" To: "Hannes Laimer" , References: <20260609132522.235917-1-h.laimer@proxmox.com> In-Reply-To: <20260609132522.235917-1-h.laimer@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1781788186066 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.249 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 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: HYI47MTVLXPZY5XTKAKNYTP2DQQNSFMZ X-Message-ID-Hash: HYI47MTVLXPZY5XTKAKNYTP2DQQNSFMZ X-MailFrom: l.sichert@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-06-09 15:25, Hannes Laimer wrote: > This adds support for microsegmentation using eBPF programs attached to > interfaces. Mostly the tap/veth interfaces on the guests directly. I installed and tested this using the .debs from the staff repo. First, on a standalone node I created some groups and subgroups and and assigned VMs. After I set some policies and moved the VMs around the groups. Everything works as expected. Also overriding rules set for parent groups with subgroup rules works. After that I set up a 3 node EVPN-VXLAN setup with an IPv6 Openfabric underlay. Then on different nodes I setup VMs and played around with goups and policies. Again everything works as expected. > # feedback wanted > - the general desgin, specifically with the agent being one-shot and tri= ggered > rather than a running service > - I put the VXLAN-GBP flag into the zones that run on vxlan for now, so = it has > to be enabled on the zone, and will affect all vxlan interfaces that a= re > part of it. The only real alternative is enabling it always, or trying= to > infer if a nic is assigned a vnet that is in a zone that does vxlan an= d > corss-referencing that with potentially configured microseg > groups/assignments. This seemed brittle, and since the needed flag is > additionally create-only, a simple flag on the zone appeard to be the = better > approach > - and the ui, very likely needs some polishing, and im very open to > alternative approaches - I only glanced over the EBPF code and the agent call in pve-network and did not dive in deeper into every function, but in general making the config change triggered rather than a service actively syncing is a good idea. This eliminates delays that users might encounter, it decreases cpu load and also it makes it easier to see current state of the ebpf setup as we don't have to consider, what the service currently might doing. - We have already had a small discussion about whether it would be possible to infer which vms belong to groups and only mark these. But as the marking happens at the vxland encapsulation and not really at egress from the VM, it gets handled by the vxlan interface of the host. Therefore IMO it makes most sense to make this a zone configuration. Additionally, there is no scenario I can think of where this enabled on the zone could cause any packet dropping. some small UI nits: - the Add button is greyed out when trying to allow untagged traffic for a Group, one can set it only by first making a change, then undoing the change - the error messages for removal are a bit cryptic, specifically I encountered: - 'delete sdn microseg group failed: group 'gr1-1' is still referenced by 'p0-3' (500)', when removing a group that still contained a VM - 'delete sdn microseg group failed: group 'gr2' is still referenced by 'p0-2' (500)', when removing a group, that still contained a policy - I would love to have something like a move button for VMs instead of having to remove and then add again - IMO the symbols are really nice, especially that the egress and ingress from and to other groups can and must be set separatly, but for the unstamped traffic I would maybe do something like <-> instead of just ->, because this leads to beleave egress also has to bet set Apart from that I found the UI very intuitive. As these are all smaller nits, if nothing bigger changes consider for this and future versions: Tested-by: Lukas Sichert