I have a pre-production VMM cluster with 2 new hardware controllers that I'm trying to bring online. (7240XM replacing 7240.)
I used the migration tool in preview mode and then copy/pasted the resulting default-global file into the /md node. It wasn't until later I noticed the recommendation in the user guide not to make edits at this level.
Is there any way to reset the /md node to defaults and start over, without also rebuilding the VMM and starting from scratch?
Unfortunately, I don't have physical access to the controllers right now as the campus is locked down and this is not a production system yet.
I'd appreciate any insights.
Unfortunately no. You would have to write erase the mobility master/masters, and start from scratch. The MD level will also not show a blue dot for override settings, these only change for inherited configs. Since this is at the top level, it wont throw that flag.
That's what I was afraid of. Since I no longer have physical access and the controllers weren't set up for ZTP, it may be a challenge to rebuild.
Thanks for the response.
I’m pretty sure if you wiped the vMMs and added the MDs to it after it was set back up, they should still be trying to get to the vMMs. Once they reconnect, they should sync their config.
If you can get someone to wire up the furthest port to the right on the controllers with a network that has internet access, you could leverage Aruba activate to point them to the vMM after wiping them as well. But who knows these days if that’s possible....
Dustin mentioned wiring the last copper Ethernet port to use for ZTP. This is needed for an AOS8 prior to 8.4. With 8.4 and above, any copper Ethernet can be used for ZTP except for the 2nd port, which is reserved in case you need to make manual settings for the device doing ZTP to communicate, such as if you were using a PPPoE connection.
As for the direct question, I agree with the others. I don't know of any way to do this except to do a write erase all.
I hope this helps,
For the interest of anyone reading this later.
I figured out a way around the write erase on the VMM. By taking out the master redundancy and the erasing the old secondary, I was able to successfully restore the flash on the master. Then I just brought the old secondary back online.
Unfortunately, somewhere in the process, both of the controllers locked up.and I'm left with this.
Type Model Status Configuration State Config ID---- ----- ------ ------------------- ---------master ArubaMM-VA up UPDATE SUCCESSFUL 79MD Aruba7240XM down CONFIG PROPAGATION 136MD Aruba7240XM down UPDATE REQUIRED 136standby ArubaMM-VA up UPDATE SUCCESSFUL 79
Since my connections are both to the first port, I thought I might be in luck for ZTP if the boxes were cycling, but as it turns out, neither one is in activate for some reason, and with the box locked up I can't get the activation ID to do a manual entry. Sigh.
Reply to my own post again for posterity.
The reason the controllers seemed to lock up was because the version of flash I restored actually had an older master-ip in it. So the controllers did exactly what they were supposed to do.
Thanks again all.
Actually, I'm about to try wiping the standby VMM and restoring the backup flash from a couple weeks ago. I tried earlier but the standby kept putting the broken config right back onto the master.
Yeah, no ZTP for me.The building is off limits unless it's a production issue. The connection is going into the standard build manual for all new installs though.
OTOH, I worked out how to get access I think. If I just add a extra network port on a VM somewhere, and add it and the current network port for the controller to a dedicated VLAN, I should be able to use the VM to log into the GUI on the default IP address.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.