From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id B0ED71FF09B for ; Mon, 17 Aug 2026 16:50:59 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 822DA2143E; Mon, 17 Aug 2026 16:50:57 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 17 Aug 2026 16:50:53 +0200 Message-Id: To: "Lukas Sichert" , "Hannes Laimer" , Subject: Re: SPAM: [RFC cluster/docs/ifupdown2/manager/network/proxmox{-ve-rs,-ebpf,-perl-rs} v2 00/27] sdn: add microsegmentation support From: "Lukas Sichert" References: <20260709091852.538885-1-h.laimer@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1786978232520 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.700 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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: EQ4VL65YAILF5HVUV2OD4IFRS7SL5ER7 X-Message-ID-Hash: EQ4VL65YAILF5HVUV2OD4IFRS7SL5ER7 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-08-17 13:17, Lukas Sichert wrote: > On 2026-07-09 11:18, Hannes Laimer wrote: > >> This adds support for microsegmentation using eBPF programs attached to >> interfaces. Mostly the tap/veth interfaces on the guests directly. >> > > Overall, the microsegmentation setup worked for both VMs and containers > across the three-node EVPN cluster. > On 2026-08-17 13:17, Lukas Sichert wrote: > On 2026-07-09 11:18, Hannes Laimer wrote: > >> This adds support for microsegmentation using eBPF programs attached to >> interfaces. Mostly the tap/veth interfaces on the guests directly. >> > > Overall, the microsegmentation setup worked for both VMs and containers > across the three-node EVPN cluster. > One thing I forgot to add in my last mail: Hannes mentioned concerns that the 16-bit identity field used to carry the eBPF-assigned identity might be too small. A minimal theoretical exhaustion scenario requires 16 independently distinguishable groups, 8 rules, and 65,536 NICs. Each rule can distinguish group membership in both its source and destination predicate. For example: allow g1 -> g2 allow g3 -> g4 ... allow g15 -> g16 A NIC can belong to any subset of these groups, such as {g1}, {g1, g3}, or {g2, g5, g8}. With the predicates above, every subset produces a different rule-matching signature and therefore forms a separate policy-equivalence class. With 16 groups, there are: 2^16 =3D 65,536 possible subsets. Only equivalence classes actually realized by NICs receive identities. Identity 0 is reserved for genuinely untagged traffic, leaving 65,535 identities for managed equivalence classes. Therefore, up to 65,535 NICs can always be assigned, even if every NIC has different policy behavior. Configurations with more NICs remain possible as long as some NICs share an equivalence class. In practice, reaching the limit would require an automatically generated configuration containing at least 65,536 distinct policy behaviors. Real environments generally contain many NICs with identical behavior and therefore sharing an identity. It seems highly unlikely that the 16-bit limit will become a practical problem.