Admins please advise if this should be posted in the API board.
I'm migrating a cluster with about 60 logical interfaces across 12 physicals to new hardware. Where most of those trunks connect to the same switch fabric I'll be consolidating them to a 10G port channel, and will need to replicate the topology with anti-spoofing on the target cluster with different interface names.
The gateways are managed in-band on one of those logical interfaces and we'll be replicating the logical topo. Access to the DC where the appliances are installed is managed by a 3rd party and all cabling goes through a request process so a physical cable swap-out for migration is untenable. I'm pre-configuring management for the new members on the same VLAN and will be shipping the boxes to the DC along with those cabling requests, once everything is cabled up there will be no physical access so all migration tasks must be logical. Each member will use the same IPs as the old cluster members except for the in-band management network which allows us to stand the new cluster up in parallel.
My strategy is to pre-configure all sub-interfaces on the new members in the "off" state except for in-band management where I can use dedicated IPs, and build the new cluster from the existing mgmt server. Normally I would control interface migration at the switch by allowing the VLANs to the new cluster and removing them from the old, but the switch fabric (Cisco ACI) is also managed by a 3rd party so we would rather remove this dependency hence deploying the logical interfaces in the "off" state.
Herein lies the challenge - in my lab if I fetch topology from the new cluster members, we only get the interfaces that are in the "on" state so 59 out of 60 are not fetched. I'd like to grab the topology from the old cluster incl. anti-spoofing configs and copy it to the target cluster with new interface names (e.g. eth1-02.2049 --> bond0.2049).
I've seen a few articles on replacing hardware and/or migrating to new interfaces, all requiring manual configuration of the target topology, so I'm looking for a way to automate this - so far I've been able to grab the current cluster config from the mgmt_cli in json format and looking to import/merge this to the new cluster once the edits are done - assuming the mgmt API will support this?
I've done a fair bit of this type of work in VSX, where the vsx_provisioning_tool has been a good friend allowing me to export a VS config and re-import with new topology - the only caveat is you can't use a group with exclusion in the interface topology. But a simple cluster not so much.
Thanks in advance 🙂
Matt
