public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Stefan Hanreich <s.hanreich@proxmox.com>
To: Maurice Klein <klein@aetherus.de>, pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH container 1/1] Signed-off-by: Maurice Klein <klein@aetherus.de>
Date: Thu, 29 Jan 2026 13:20:45 +0100	[thread overview]
Message-ID: <5d2bcf8a-ea6f-48aa-8cc6-c92cfb93311f@proxmox.com> (raw)
In-Reply-To: <321bd4ff-f147-4329-9788-50061d569fa6@aetherus.de>

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




  parent reply	other threads:[~2026-01-29 12:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260109121049.70740-1-klein@aetherus.de>
2026-01-09 12:10 ` Maurice Klein via pve-devel
     [not found] ` <20260109121049.70740-2-klein@aetherus.de>
2026-01-19  8:37   ` Maurice Klein via pve-devel
2026-01-19 14:35     ` Stefan Hanreich
2026-01-21 19:04       ` Maurice Klein via pve-devel
     [not found]       ` <d18928a0-6ab0-4e90-ad3a-0674bbdedb72@aetherus.de>
2026-01-27 10:02         ` Stefan Hanreich
2026-01-27 10:37           ` Maurice Klein via pve-devel
     [not found]           ` <321bd4ff-f147-4329-9788-50061d569fa6@aetherus.de>
2026-01-29 12:20             ` Stefan Hanreich [this message]
2026-02-01 14:32               ` Maurice Klein
     [not found] <20260109124514.72991-1-klein@aetherus.de>
2026-01-09 12:45 ` Maurice Klein via pve-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d2bcf8a-ea6f-48aa-8cc6-c92cfb93311f@proxmox.com \
    --to=s.hanreich@proxmox.com \
    --cc=klein@aetherus.de \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal