I have 3 Cisco APICs that all require a reboot in relation to a known bug that TAC identified during a recent case I had open with them. The APICs are in an area of my companies infrastructure that is considered super high risk, which alongside some change failures elsewhere in the business recently has resulted in changes being examined with a fine tooth comb. In addition since these APICs were stood up this is the first time they've been rebooted, so everyone's just feeling a little squeeky bum about the whole deal.
Ive fully documented the process for running ad hoc remote & local backups prior to the reboot, the process for reboot, the process to restore from both remote & local backups in the event of loss of config, and also the process by which I'd swap out an APIC in the event of full hardware failure.
My only outstanding question which got raised is as follows; Is there a way whereby after the reboot I can prevent the APIC from syncing to its other two cluster members, until after I've performed manual validation that the config is still as it should be? The query being, what if the rebooted APIC came up with incorrect/invalid config, the timestamp of most recent config change showed that APIC as having the most up to date config, it then syncs to the other two APICs and overwrites their correct config with the invalid config?
I don't know whether this is a valid concern or even in the rhelms of possibility but I'm just trying to anticipate not only questions senior management may ask during change approval, but also worst case scenarios.
No comments:
Post a Comment