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>
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>
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>
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>
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>
2023-05-25 18:18:57 +02:00
Renamed from PVE/Network/SDN/Controllers/EvpnPlugin.pm (Browse further)
