Re: [RFC cluster/docs/ifupdown2/manager/network/proxmox{-ebpf,-ve-rs,-perl-rs} 00/16] sdn: add microsegmentation support

["Lukas Sichert" <l.sichert@proxmox.com>]

On 2026-06-09 15:25, Hannes Laimer <h.laimer@proxmox.com> 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 triggered
>    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 are
>    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 and
>    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 <l.sichert@proxmox.com>