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 D00871FF13C for ; Thu, 16 Apr 2026 17:34:12 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0A7EBB46B; Thu, 16 Apr 2026 17:34:12 +0200 (CEST) Date: Thu, 16 Apr 2026 17:34:08 +0200 From: Gabriel Goller To: Hannes Laimer Subject: Re: [PATCH pve-network 06/16] evpn controller: allow multiple evpn controllers in a cluster Message-ID: <5lb37bax6ickaa5gxo2xy7457fjghbtxwwngikkk27buyog5a7@3k3jx3x6oao7> Mail-Followup-To: Hannes Laimer , Stefan Hanreich , pve-devel@lists.proxmox.com References: <20260414163315.419384-1-s.hanreich@proxmox.com> <20260414163315.419384-7-s.hanreich@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20241002-35-39f9a6 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1776353569660 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.029 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: MGNNR4ZBUXW76BZYJW6V6JVNVKFVKPRY X-Message-ID-Hash: MGNNR4ZBUXW76BZYJW6V6JVNVKFVKPRY X-MailFrom: g.goller@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 CC: pve-devel@lists.proxmox.com 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 16.04.2026 17:30, Hannes Laimer wrote: > On 2026-04-14 18:33, Stefan Hanreich wrote: > > Previously it was only possible to define one global EVPN controller > > in a cluster, which represented a single peer-group - VTEP. This patch > > allows defining multiple EVPN controllers in a cluster. One can think > > of one EVPN controller as mapping to a single peer-group. This patch > > series adds the possibility of defining multiple peer-groups. > > > > In order to enable this change, introduce a new setting in the EVPN > > controller 'peer-group-name'. Since it was only possible to create a > > single EVPN controller in the entire cluster, the FRR config > > generation generated a single peer group with a hard-coded name. To > > allow defining multiple peer-groups and preserve > > backwards-compatibility, a custom peer group name needs to be defined > > explicitly for each additional controller. The setting is optional and > > the peer group name defaults to 'VTEP' if unset, in order to avoid > > breaking backwards-compatibility with custom FRR configurations. > > > > Signed-off-by: Stefan Hanreich > > --- > > [..] > > > @@ -493,18 +517,20 @@ sub on_delete_hook { > > sub on_update_hook { > > my ($class, $controllerid, $controller_cfg) = @_; > > > > - # we can only have 1 evpn controller / 1 asn by server > > + my $controller = $controller_cfg->{ids}->{$controllerid}; > > > > - my $controllernb = 0; > > foreach my $id (keys %{ $controller_cfg->{ids} }) { > > next if $id eq $controllerid; > > - my $controller = $controller_cfg->{ids}->{$id}; > > - next if $controller->{type} ne "evpn"; > > - $controllernb++; > > - die "only 1 global evpn controller can be defined" if $controllernb >= 1; > > + my $other_controller = $controller_cfg->{ids}->{$id}; > > + next if $other_controller->{type} ne "evpn"; > > + > > + die "cannot have two controllers with no peer-group-name configured" > > + if !$controller->{'peer-group-name'} && !$other_controller->{'peer-group-name'}; > > + > > + die "cannot have two controllers with same peer-group-name configured" > > + if $controller->{'peer-group-name'} eq $other_controller->{'peer-group-name'}; > > if one has none, so the default('VTEP'), and the other sets 'VTEP', we > miss that case here I think. something like > ``` > my $pg_self = $controller->{'peer-group-name'} // 'VTEP'; > my $pg_other = $other_controller->{'peer-group-name'} // 'VTEP'; > die "cannot have two controllers with ..." if $pg_self eq $pg_other; > ``` > might be better Maybe tangentially related: we should probably disallow VTEP as a bgp fabric name. > > } > > > > - my $controller = $controller_cfg->{ids}->{$controllerid}; > > if ($controller->{type} eq 'evpn') { > > die "must have exactly one of peers / fabric defined" > > if ($controller->{peers} && $controller->{fabric}) > > > > >