Re: [pve-devel] [PATCH container 1/1] Signed-off-by: Maurice Klein <klein@aetherus.de>

[Maurice Klein via pve-devel <pve-devel@lists.proxmox.com>]

[-- Attachment #1: Type: message/rfc822, Size: 7343 bytes --]

From: Maurice Klein <klein@aetherus.de>
To: Stefan Hanreich <s.hanreich@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH container 1/1] Signed-off-by: Maurice Klein <klein@aetherus.de>
Date: Tue, 27 Jan 2026 11:37:00 +0100
Message-ID: <321bd4ff-f147-4329-9788-50061d569fa6@aetherus.de>

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.

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

- implement possibility to export host routes of routed zones via BGP

- implement possibility to add static routes per Routed zone, like 
different default routes or others

- 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.


Let me know if that is a way you agree with and if it is i would like to 
get started implementing the first step.


Mit freundlichen Grüßen,

Maurice Klein

Aetherus

TEL: 0212 7846460
Mail: Klein@aetherus.de


Am 27.01.26 um 11:02 schrieb Stefan Hanreich:
> On 1/21/26 8:04 PM, Maurice Klein wrote:
>
> Some thoughts below from my side, but I'm still unsure on what would be
> the best approach for this.
>
>> I agree it would work nicely as a SDN plugin and I was also considering
>> that approach.
>> The problem I saw with that is that SDN relies on there being a bridge
>> for every zone and making it work without one seems to be a huge refactor.
>> Do you think the bridge should not be removed at all, even for a pure l3
>> routed setup?
> That would be one reason, but there are others. The gateway IP only
> needs to be configured once on the bridge / vnet itself then, whereas it
> needs to be specified explicitly for every guest with your approach.
> You'd most likely also need to generate a MAC address that is the same
> for the GW on all PVE hosts, so VM mobility works properly. With tap
> interfaces that is even more complicated as you'd need to handle setting
> the MAC for each tap interface. It's cleaner and simpler that way imo,
> since you can just set up the gateway once and be done.
>
> A simple zone with port isolation is already quite similar to what
> you're trying to achieve imo. It denies L2 connectivity between guests
> via the isolated flag [1] on bridge members and the PVE node acts as a
> router for the zone. I think that could be used as a starting point and
> then build upon it. Simple zones have IPAM support, so we could utilize
> that for managing the guest IPs. It would probably also make sense to
> manage neighbor / fdb table entries statically for this kind of setup.
>
> [1] https://man7.org/linux/man-pages/man8/bridge.8.html
>



[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel