Network Management

I have made several server migrations where the IP address stayed the same, all easy and painless, so I wasn't worrying too much about the upcoming migration.

It dawned on me yesterday that I'm changing IP addresses this time.

The plan so far:

I'm going to need to backup the old server and restore it to the new.

After that, I realize there are a few things I don't know how, or in what order will be best.

Airwave:

Do I run them in parallel during the migration, or shut oof old before restoring database on new?

Can I make this easier by setting up a backup-airwave relationship and then just fail forward?

Controllers: (Monitor mode)

Do I just change the IP address for the airwave server and I'm done, or is there some other change required?

iAP: (Manage Mode)

Will the new server just push the new IP out, or will I need to use the old server to push the change?

What am I overthinking, and what am I missing?

Sounds to me like you're planning to migrate between 2 physical servers, correct?

1) If so, then it's a good idea to run both in parallel for a short period of time.  The old server can be disabled once the device communication migrates completely to the new server.

2) Controllers need to have their mgmt-server settings adjusted to point to the new server (for traps/AMON)

3) For IAPs, regardless of if you're on templates or IGC, both servers will need the AirWave IP variable updated.  A push would be required from the old server to update the IAPs with the new AirWave IP.  Then on the new server, things should just start coming up.  The reason updating both servers is needed is so that you don't have to worry about monitor/managed states causing an AP to go back and forth between the 2 servers.

This worked smoothly once I remembered to amp_enable after the restore on the new server ;)

The exception is that 5 stores and my lab couldn't find the new Airwave server (amp_disable will do that) and somehow remembered and reverted to the old Airwave, where they are still trying to check-in but have an ams-key mismatch displaying:

     Status: Down (Mismatched Virtual Controller shared secret)

Oddly while these 6 clusters are mis-keyed on one Airwave and not-checked-in on the other, they also will not let me log in with my RADIUS credentials. I suppose failing-shut is good security, but I'd like to be able to straighten them out.

Any thoughts?

Are you able to access any of the VCs using the non-RADIUS admin creds?  If not, bouncing the APs during off hours should work to restore the access to the new AMP server (I've done this by bouncing the port on the switch).

Sorry I hadn't mentioned that. The local admin account also doesn't work.

I'll reboot my lab in a few minutes and let you know how it went.

--Matthew

I found an end-around.

The slave iAP let me ssh in, and show running configuration.

I copied the encrypted key and pasted it into the template for the troubled stores, and they were able to connect.

Once connected, the iAP clusters checked in and got the configuration push to move to the new Airwave and switched to not-connected. The AMP single-sign-on continued to work so I was able to sign in to each one and re-enter the correct key.

All good now, the old server is off and the new has all devices communicating.

whew!

New problem: Not a problem, my co-worker mis represented his findings.

Visual RF has lost quite a few all of my floorplans.

Is it possible to re-restore just the VisualRF, or tell from some troubleshooting steps why they aren't displaying?