From: Julien OHAYON <j.ohayon@xoxo.fr>
To: Stefan Hanreich <s.hanreich@proxmox.com>
Cc: Proxmox VE user list <pve-user@lists.proxmox.com>
Subject: Re: [PVE-User] OSPF when migrating from v8 to v9
Date: Fri, 10 Oct 2025 17:58:52 +0200 [thread overview]
Message-ID: <CD7470C4-6495-4AB9-B3DD-F66417F00664@xoxo.fr> (raw)
In-Reply-To: <04471187-a8a9-4b6c-b425-ad1581b3505b@proxmox.com>
Hi Stefan
Thank you for this workaround.
I’m testing this in the beginning of the week.
Thanks
> Le 10 oct. 2025 à 16:34, Stefan Hanreich <s.hanreich@proxmox.com> a écrit :
>
> On 10/10/25 7:55 AM, Julien OHAYON wrote:
>> Yes, indeed, during the upgrade nothing changes. Unfortunately, we will have to migrate over several days, and above all, there is still a huge unknown that we would have liked to be able to control: how the switch to the new configuration will happen.
>>
>>
>>
>> What we would have liked (and I don’t think I’m the only one in this case) is to be able to apply the configuration on the new nodes running v9, without it affecting those still in v8. Because if I have to migrate all my nodes and then press the button afterwards thinking everything will work fine… No, that’s not ideal.
>>
>>
>>
>> Unfortunately, with network interactions — and even more so interactions with routing protocols deeply embedded in the infrastructure — you want to have control over how the switchover will occur.
>>
>>
>>
>> For now, I don’t see how to migrate to v9 without risking major downtime (a lab will not show the exact behavior we can expect in this type of SDN infrastructure).
>
>
> Understandable, I took a closer look with a colleague today and we found
> a way that should hopefully work for you.
>
>
> What should work as a workaround is setting 'ospfd=yes' in
> /etc/default/frr - which provides a way to override the /etc/frr/daemons
> file. While that file (/etc/default/frr) is deprecated, it is still read
> and respected by FRR and therefore provides a way of overriding the
> value independent of our tooling. This prevents the OSPF daemon from
> getting disabled on applying the SDN configuration, since our tooling
> doesn't touch it.
>
> After you are finished upgrading everything to 9, you can then test
> migrating to the SDN fabrics by freeing up one node in your cluster
> (migrate everything away, rename the frr.conf.local, ...) and define a
> new fabric that only contains the node you want to use for testing.
> Applying the SDN configuration then leaves the OSPF configuration for
> all other nodes intact, while configuring OSPF using the Fabrics on the
> one node that is part of the fabric. Alternatively, a virtualized
> Proxmox VE instance could be used for testing the fabrics specifically.
>
>
> If that test is successful, you can start migrating the other nodes over
> one by one.
>
> I tested this procedure on a cluster here locally and it worked
> perfectly here. It would still be advisable to test this procedure on a
> test cluster (can be virtualized) before you proceed on your production
> cluster.
>
>
> Kind Regards
> Stefan
_______________________________________________
pve-user mailing list
pve-user@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user
next prev parent reply other threads:[~2025-10-10 15:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 6:16 Julien OHAYON
2025-10-07 13:52 ` Stefan Hanreich
2025-10-07 15:58 ` Julien OHAYON
2025-10-08 9:34 ` Stefan Hanreich
2025-10-08 10:48 ` Julien OHAYON
2025-10-09 12:17 ` Stefan Hanreich
2025-10-10 5:55 ` Julien OHAYON
2025-10-10 14:34 ` Stefan Hanreich
2025-10-10 15:58 ` Julien OHAYON [this message]
2025-10-08 18:24 ` Flavio Visentin via pve-user
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=CD7470C4-6495-4AB9-B3DD-F66417F00664@xoxo.fr \
--to=j.ohayon@xoxo.fr \
--cc=pve-user@lists.proxmox.com \
--cc=s.hanreich@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.