| Age | Commit message (Collapse) | Author |
|---|
|
The possible properties returned by the controller endpoints were only
partly documented. Add all missing properties and update descriptions
for existing properties.
Update the descriptions of the schemas in the plugin to provide more
detailed information about the different configuration options.
Move all duplicate properties between the GET endpoints into its own
variable, so we can reuse them.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
|
|
ASNs are 32-bit unsigned integers where the maximum value is
4294967295.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
|
|
Provide a new option to the EVPN controller, fabric, that can be used
to define a fabric as the underlay network for the EVPN controller.
When applying the configuration, the EVPN controller then
automatically generates the peer list and from the fabric
configuration, rather than users having to specify all IP addresses
manually. This also means that the peer list automatically updates
when changing the fabric.
An EVPN controller can only either define a peer list or a fabric, but
not both. This requires the 'peers' property to now be optional, but
the existence of either fabric / peers is now validated in the
on_update_hook now instead.
MTU is set automatically to 1450 (because of VXLAN overhead) when
fabrics are used, unless otherwise specified in the EVPN zone
configuration, since there is currently now way of reliably accessing
the MTU of the interfaces of the fabric. This means users have to
manually specify the MTU for the EVPN controller when using fabrics.
This could be particularly relevant in the future, when Wireguard is
introduced as a fabric, which incurs an overhead of 80 bytes,
requiring users to manually set the MTU to 1370.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-53-g.goller@proxmox.com
|
|
With the changes to how we handle the frr config generation,
controllers are now no longer responsible for serializing and writing
the FRR configuration. Instead, we pass the existing frr_config perl
hash to every controller, where controllers append their respective
configuration.
This requires a few changes in the controller API, so that they now
append to a perl hash, instead of directly writing their own
configuration to the file, which is now handled externally by the SDN
module.
We also remove the respective methods in the EvpnPlugin that were
previously responsible for serializing and writing the FRR
configuration, since they have been moved to the Frr helper module
instead.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-41-g.goller@proxmox.com
|
|
Up until now the EVPN controller contained all the helper methods as
well as the configuration generation logic for FRR. Since we need to
write FRR configuration with the fabrics as well, move the FRR helper
files into its own FRR module, so they can be used by the EVPN plugin
as well as the future fabrics plugins.
The fact that the EVPN controller was solely responsible for
generating the FRR config also meant, that FRR configuration was only
generated if you had an EVPN controller defined.
In the process of generating an FRR configuration, we used mainly two
formats, which I'll refer to by the following names:
frr_config: This is a perl hash, that loosely resembles the structure
of the FRR configuration file and was later converted into the
raw_config format before writing it.
raw_config: This is an array, that contains strings, where each string
is a line in the FRR configuration. So the finished FRR configuration
consists of all the strings in the array joined by newlines.
Controllers used the frr_config format for generating FRR
configuration. The local configuration in /etc/frr/frr.conf.local also
gets parsed into this format. The fabrics perlmod module, returns the
raw_config format. This was behind the intention to make this split
more clear and handle the FRR config generation in two steps from now
on:
* generate a frr_config in all plugins that utilize that format
* convert it to the raw_config format
* append the configuration obtained via perlmod
* write the finished configuration to frr.conf
This process was already in place, but the distinction wasn't that
clear. During this process I renamed all methods to make clear which
format they accept / return.
Some functions have been split to make them more granular, so we can
use intermediate results. Most namely the
generate_controller_rawconfig function has been split into multiple
functions.
Added documentation to all public FRR functions, so it is clearer
which format they expect, as well as which operations they perform on
the respective passed configurations.
For the future it might make sense to further split the FRR config
generation for zones and vnets into the respective Zone / VNet
Plugins, instead of in the EVPN controller, but this was beyond the
scope of this already quite large patch series.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-39-g.goller@proxmox.com
|
|
Since this only has an effect on applying the configuration, users
will still need to reapply the configuration when an interface changes
names / altnames. In order to add full altname support for IS-IS,
altname support would need to be implemented in FRR.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716151815.348161-7-s.hanreich@proxmox.com
|
|
CIDR is always a defined hash anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
using the new top-level `make tidy` target, which calls perltidy via
our wrapper to enforce the desired style as closely as possible.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Since we now ship frr with Proxmox VE, the frr service is available on
the nodes but disabled on install. Prior to that, users had to
manually install frr, which automatically enabled the service. When
first applying a SDN configuration with an EVPN controller, we always
fell back to restarting the frr service, because reloading fails when
the daemon isn't running. This fallback to restarting leads to the
service running but still being in the disabled state. This means that
the EVPN setup is working until the next reboot. To avoid the
situation where users configure an EVPN controller and everything
seems to be working, until a restart breaks the EVPN setup,
additionally enable and start the frr service before trying to reload
the configuration.
We enable the service after checking for the existence of
frr-pythontools in order to avoid the situation where users apply an
SDN configuration with an EVPN controller, but reloading fails due to
a missing frr-pythontools package. Since we do an early return there,
we never fell back to restarting the service in case frr-pythontools
was not available. If we enabled the service before the check, the
configuration would apply after a reboot since it already got written
to the frr configuration file.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
Prior to the upgrade to frr-pythontools 10.2.1, frr-reload.py did not
print any output to STDOUT, which masked the erroneous outfunc
provided in run_command. With 10.2.1 frr-reload.py now prints to
STDOUT, which triggers the codepath for invoking the outfunc, leading
to an error when invoking frr-reload.py. By removing the outfunc the
invocation works again.
In addition to fixing the regression introduced, we also now print the
frr-reload.py informational output to the tasklog, which can be
helpful in debugging any issues when reloading the frr configuration.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
Signed-off-by: Hannes Duerr <h.duerr@proxmox.com>
[TL: drop all other unused Dumper use statements]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
for ipv4, we use the iface ipv4 router-id as router-id need to 32bit.
That's doesn't work for pure ipv6 underlay network.
since https://www.rfc-editor.org/rfc/rfc6286, we can use any 32bit id,
it's just need to be unique in the ASN.
Simply use the last 4 bytes of iface mac address as unique id
changelog V2: add missing test
Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Need to be inserted after ip prefix-list and before route map
Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
to allow mocking local fs access
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Max Carrara <m.carrara@proxmox.com>
Tested-By: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
- don't duplicate ip
- ipv6 use "ipv6 route"
- order correctly
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
|
|
Some values have been reordered in last version
- bump version to 8.5.2
- move no bgp graceful-restart notification
- move neighbor VTEP activate
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
|
|
"match evpn" in route-map is broken since 8.5.0
https://github.com/FRRouting/frr/issues/14419
the patch
https://github.com/FRRouting/frr/commit/272c6d5db128ff7450fe9fcd16c046160594deb3
is converting type-2 && type-5 evpn routes to prefix-prefix.
(fixing prefix-list not working previously, but breaking "match evpn")
So, simply use prefix-list now, as "match epvn" was a workaround anyway.
reported on the forum, where user have routing loop between the 2 exit-nodes:
https://forum.proxmox.com/threads/sdn-with-evpn-controller-routing-loop-when-using-multiple-exit-nodes.137362/
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
|
|
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
|
|
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
|
|
|
|
|
|
add default values:
"no bgp hard-administrative-reset"
"no bgp graceful-restart notification"
to avoid frr-reload warning
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
We don't want to routes subnets between different zones when same
exit node is used.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
vrf and router bgp vrf need to be ordered by vrf name
ip protocol need to be at the end
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Currently, if a node is primary exit-node for 1 vrf, and secondary
exit-node for another vrf,
The deny route-map is filtering routes imports for both vrf.
This patch adds filtering only for the vrf's where the node is
secondary.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
like almost all of our repos do nowadays, modern git can detect such
things on rebase so in development stuff should be hopefully not too
much affected by this.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
