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 <[email protected]> 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
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-user

Reply via email to