Since we're going to start peering with clusters outside of the established local networks, I thought it might be a good idea to move the intercluster lifs out of the "Default" IPspace to something more isolated routing wise. This turns out to be more work than just moving a broadcast-domain to a new IPspace, unfortunately. Even if it's not documented as such, one can't move a broadcast if it has any active lifs.
I've sort of reached the conclusion that I have to use a new broadcast-domain and IPspace and remove the old peering and re-establish it. I assume this will also mean re-establishing all of the existing vserver peer relationships.
How far off am I?
This seems like it could be pretty disruptive especially for existing flexcache relationships.
The other alternative is, of course, just to establish a new net/vlan (and ipspace and broadcast domain) for the "external" clusters, but it's a bit more interdepartmental work.
Any insights?
#Migrating cluster peer network to new ipspace
shell raptor
copper sigil
Here is the process for SnapMirror https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/How_to_move_intercluster_LIFs_used_for_snapmirror_to_a_different_IPSpace
For FabricPool there is another guide: https://kb.netapp.com/on-prem/ontap/DM/FabricPool/FabricPool-KBs/How_to_move_Intercluster_LIFs_to_another_IPSpace_for_FabricPool
shell raptor
luckily, I split fabricpool into its own ipspace long ago
but the snapmirror doc... it gets around the active lif part by just deleting them all... but the strange part, and i don't know what this looks like on the other side, the current peer configuration lists the IPspace that it is using, but i don't know if that is just registered info, or a hard configuration
if one does this quick, it might not be terribly disruptive, but if it breaks half-way through, it's going to cause a bit of disruption
shell merlin
Not sure if you can merge across ipspaces but you can merge two broadcast-domains even if there are active LIFs on its ports.