VSX Migration 6400 → 9700 with Bond Redesign (4→2 Interfaces) – vsx_util Reconfigure Limitations?

[jennyado]

Hi everyone.

I’m planning a VSX hardware migration and would really appreciate your guidance on the best approach, especially regarding interface/bond reconfiguration.

Current Environment

• VSX Cluster with 2x 6400 appliances (Load Sharing mode)
• VSX Gateways:
  • VS0
  • VS1
  • VS2

Current Bonds Configuration

• bond1: eth2, eth3, eth4, eth5 (copper)
• bond2: eth6, eth7
• bond3: eth1-1, eth1-2
• bond4: eth1-3, eth1-4

Target Environment (9700 appliances)

• bond1 → eth5 + eth6 (fiber) ⬅️ (change from 4 interfaces to 2 + media type change)
• bond2 → eth3 + eth4 ⬅️ (interface change)
• bond3 → same naming (eth1-1, eth1-2)
• bond4 → same naming (eth1-3, eth1-4)

Main Question

We are considering using vsx_util reconfigure to adapt the configuration to the new hardware.

However, we have concerns about:

• Changing bond1 from 4 interfaces to 2 interfaces
• Changing interface types (copper → fiber)
• Changing interfaces in bond2
• Different interface numbering on the 9700

What we would like to understand

1. Is vsx_util reconfigure capable of handling this kind of bond redesign (including interface reduction and reassignment)?
2. If not, what would be the recommended approach?
3. Are there any known risks when modifying bonds after reconfigure in a VSX cluster?
4. Any best practices for minimizing downtime and avoiding sync issues?

Additional Context

• Both cluster members will be replaced
• Maintenance window is limited, so we are trying to balance safety vs speed
• We want to avoid issues with cluster state, sync, or VS connectivity

Any recommendations, field experience, or best practices would be highly appreciated.

Thanks in advance!

[emmap · Accepted solution]

Sounds like your bond IDs are not changing, which means that your interface names in SmartConsole are not changing, which means that vsx_util reconfigure will be fine because it doesn't know or care about what the underlying interfaces inside the bond are. The interface names on the VSs reflect the bond ID, not the member interfaces within the bonds.

Make sure, before you start, you open the VSX Cluster object in SmartConsole, go to Physical Interfaces section, and remove any unused interfaces. Leave only the interfaces being used there. Thus when you reconfigure to the new appliances, all the required interfaces (including the VS0 mgmt and sync interfaces) will exist on the new hardware. 

[jennyado]

Are interfaces eth1–eth8 preserved and equivalent when migrating from 6700 to 9700 appliances, even if the underlying hardware ports differ?

[emmap]

I don't understand what you're asking here sorry. The base OS and interface/bonding configuration should be manually redone when you are setting up the new appliances ready for the vsx_util reconfigure procedure, if you are only using bonds for data links then the member interface names are not relevant to the reconfigure procedure. 

[jennyado]

What I’m trying to understand is whether there is any guaranteed consistency in interface naming between platforms.

Specifically, when moving from a 6700 to a 9700 appliance, should I expect interfaces eth1–eth8 to keep the same naming and physical port association, or is the mapping platform-dependent and therefore needs to be validated manually on the new hardware?

[Bob_Zimmerman · Accepted solution]

Both have an eth1 through eth8, but on the 6700 eth1 through eth4 are 1g copper while on the 9700 eth1 through eth4 are SFP+ slots.

The bonds abstract all that away, though. Just make sure the physical ports aren't in the VSX cluster object's Physical Interfaces section, and create the bonds with whatever new physical ports you want. As long as your config only references bonds, you should be able to move from hardware to hardware with little effort.

If your Physical Interfaces section contains real ports like eth2 or eth1-04 and you're using them in VSs, you should look into 'vsx_util change_interfaces'. It lets you replace all references to an interface with references to another interface. Both must exist, and there will be an outage as the configuration is changed.

[Bob_Zimmerman]

Also of note: remove the bond members from the Physical Interfaces section of the VSX cluster object, too. They can't be used by VSs (only the bond can be), and having them there may break the reconfigure.

Keep these management debugs handy. They allow you to make changes to the VSX cluster object without requiring the management to provision the changes to the firewall. You will always need to do a 'vsx_util reconfigure' after making changes like that, but if you're already trying to reconfigure and it's failing, these may let you fix the problem:

fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PING=INFO
fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_INSTALL=INFO
fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PULL_SIC=INFO

[Magnus-Holmberg]

I would install it in paralell using vsx provisioning
Have the new appliances bond interfaces carrying production traffic in shutdown in the switches.

New VSX Cluster name
New VS names 

Add it to the current CMA / Domains.
Policys can be installed on new VS in parallell.

Before cutover, Flipp the VPN config to the new VS, install policy again.
During cutover, Shutdown interfaces in the switches to old appliance and open it to the new appliance boxes.

Benifit of this approch is that you can do changes to the enviroment you would like to do, for clean-up.
You do have a very easy rollback if needed, where u have not touched the old enviroment,.
You can do VS per VS migration.
As its VSX, its controlled via VS0, allowing you to prepp all in advance.

Drawback, it will require some new IP:s, may require the use of some demo licenses in the CMA / Domains during the buildup.

Regards,
Magnus