Is it possible to recover the root password of a chassis cluster 1 node at a time so your network is not taken down?
If you have a chassis cluster you most likely have the same root password on all nodes. So recovery should only be needed to be performed on one node.
As per the password recovery instructions, you need to reboot the device when doing this. In a fully redundant environment, there should be no downtime when rebooting a single node.
I would personally remove the specific node from the cluster (ie removing cabling), follow the password recovery instructions to extract the current password. Then bring the node fully up again and recabling, connecting it back to the cluster and then use it to log in and change password if needed.
The password recovery procedure changes the password, which I'm ok with. I had planned on disconnecting one of the members to do this with. The question is, what happens when the nodes have different passwords? I'm trying to get something together to test this outside of a production network.
The changes will be overwritten during next commit. That's why I would rather recover the old password than change it.
Howdy - I had the opportunity to actually do this on a production network.
I did not take downt the link between the primary (node0) and secondary (node1) . Just did a soft power down on the primary. Lost a couple of pings until the secondary took over. Booted the primary into single user mode - did a password recovery on the primary unit. When it came back up it came up into secondary mode. I checked password validation on both boxes. The newly booted box had the new password, the old secondary (node1) still had the old password.
I did a chassis failover to return the primary status to the newly booted box. I then checked pasword validation again. No change. I then did a commit on the new primary. The commit did NOT migrate to the secondary (node1) unit. I then changed the password again on the new primary (node0) box - did a commit. It was applied on both boxes and the new password was in effect.
I did not think about just making an innocuous configuration change to see if that would have pushed the password out to node1, instead of actually changing the password again.
It all worked really well. Hope this helps!
@muttbarker wrote: I did not think about just making an innocuous configuration change to see if that would have pushed the password out to node1, instead of actually changing the password again.
Kevin, a "commit full" might have done the trick, too.
Hey Keith - you are correct - it might have and if I get chance to test it in my lab I will try it. These were SRX210's and I try and avoid a commit full cause it is such a resource hog. But it would make sense as that as a "forced" commit.
Thanks for the detailed reply Kevin. I plan on giving this a try friday evening during a maintenance window. I'll let you know how it goes.
I finally got around to resetting the password, and it went much better than expected.
I reset the password on the secondary node first. Once it came up, I checked the primary, and the password change had not propagated to it. I was however able to log in to the primary from the secondary using request routing-engine login node 0. I then changed the password on the primary node.
I'm using 10.0R3.10.