Jump to content
Welcome to our new Citrix community!

Run VPX side by side with MPX to test configuration


Recommended Posts

Hello.  We have stood up 7 new Virtual VPX's in VMware.  They are accessible and only the NSIP has been assigned.  I will apply licenses soon.  Of the 7 VPX's, there are 2 HA's and the rest are single nodes.  Both the physical MPX9700's (which we're moving from) and the Virtual VPX's (moving to) are running firmware 12.1.55.210nc.

So now I'm following https://www.carlstalhood.com/migrate-citrix-adc-config-to-new-adc-appliances/ to do so, however; I'd really like to get the basic configuration on the VPX that currently resides on the MPX9700 (physical) to ensure that all is working before an actual cutover.  

The article suggests removing quite a few things, so I'm wondering, would it make sense to just update the NSIP entry in the exported running config with the new NSIP and remove or change the Netscaler Gateway VIP - so I don't introduce an interruption in traffic?  Additionally my current MPX's are running FIPS -so would like to maintain those keys as we're using Wildcard or do we need to redo this process?

Since I have a few instances to do, trying to vet out the process in my singular nodes which are Test and DR before doing production which are the HA's.  In other words, I'd like to import the current MPX running config and just change enough for it to run some basic tests and then schedule the actual cutover which I know would cause users a disruption.

Thanks in advance for your expertise. 

Link to comment
Share on other sites

Changing the NSIP, VIP, SNIPs to avoid conflicts is bare minimum.

But since your MPX are in fips mode and your vpx's are not...its not going to be a straight forward process.  

 

Unless you are completely isolating the VPX's network from production to avoid IP conflicts, a straight config import and reboot is likely not going to work without some post import changes anyway.

 

Things that you need to look out for,

1) Do you have the same interface names/channel names on the VPX's that you have on MPX. If not, this may affect interface/channel/vlan import commands.  In addition, the test environment may have additional network differences regarding routes and vlans.

2) CAn you fully isolate the networks to avoid the VPX's creating ip conflicts with the production MPX's?  If not, then you will have to change the NSIP/VIP/SNIP in most cases either pre-config import or  post config while appliance is "offline" to avoid introducing conflicts.

3) If the private keys/certs you are using in production are fips based and the VPX you are configuring will not be (even if you decide to do external FIPs...this would be challenging), you'll have to deal with cert management post config import.   Likely, the fips commands would be ignored if hardware doesn't support this, but it also means you will need alternate certs (like a domain or test domain wildcard cert and private key that you could bind in place of the "protected" production certs...since you would be unlikely to import them on a non-fips appliance anyway -- as it would defeat the reasons that you use fips.)  In this case, the certkey create commands and any ssl cert bind commands *should* be ignored during a config import; but that also means any ssl entity will be down until replacement certs are bound.

4) Editing the saved config file directly is tricky if you use the wrong text editor or line return format it might not be valid.  

 

 

So a import config and reboot process is still going to have a fair amount of pre-import or post-import edits to go into effect.

 

If you were to completely stage your Test environment:  routes/vlans/nsip/snips and necessary temporary certs.

Your "test" procedure might work better if you think of your production config as the commands needed to create the entities; create a batch file of the commands to execute and then change the commands for the necessary VIPs and ignore commands that don't apply, and then run the NEW commands on the new destination.

This is still a bit of upfront work, but after the initial config is done, you just need to think about future command differences and may give you more control of the commands to keep and modify.   Basically, thing and document the config to run to apply changes on top of the base test environment to config and you can more easily fix the overlaps and apply new settings.

If isolated, you can import the config and then fix ip conflicts (if needed after the fact); but you'll still need to review the config for things ignored during import, etc...

 

Neither process is without work; just shifting the complexity to different phases.

Regardless of method:

1) isolate the test environment to avoid potential conflicts

2) Your going to have to review and/or modify the config either pre-import or post-import in either case.

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Thanks, I do understand the work, just making sure it's an effective test ;)  So I will play around with this, use some temp ip's, modify the exported config, import and see what happens... I am just trying to figure this out as our Physical Netscaler's are the only exposure I've had and they are working well. They were built manually so this is a first on VPX's and trying to export/import a config.  I can certainly setup manually but that doesn't seem like the right approach if I can get most things in the config and just update IP's to some extent ;)

 

Thanks in advance.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...