Configuration, startup configuration files, and stacking flash
Stacking system behavior is defined by the runtime configuration, which can be displayed using the show run command. The write memory command stores the runtime configuration in a flash file called startup-config.txt. During bootup, the system reads and applies the startup-config.txt file to the runtime configuration. The startup-config.txt file can be shown using the show config command.
The stacking system installs a stacking.boot file on each unit that tells the unit what its role is during the boot process. The stacking.boot file is generated whenever there is an election that defines the roles for all units.
When an active controller is booted or a write memory command is issued, the active controller synchronizes its startup-config.txt file to every stack unit. The original startup-config.txt files in the standby controller and other stack members are renamed to startup-config.old. If you issue the stack unconfigure me command on the standby controller or stack member directly, these units recover their original startup-config.txt files and reboot as standalone devices. If you enter the stack unconfigure all command from the active controller, all devices recover their old startup-config.txt files and become standalone devices. When this happens, the startup-config.old file is renamed to startup-config.txt, and the stacking.boot file is removed.
Whenever a stack unit configuration parameter, such as the priority setting, is changed, an election is held to determine the active controller, and the result is written into the stacking.boot file. A prompt message appears on the console that recommends you use the write memory command. For an active controller role change to take effect, you must reset the entire stack.
If you do not use the write memory command but reset the stack, the stack units continue to operate in their roles as defined by the stacking.boot file. After the reset, each unit readjusts based on the current runtime configuration. However, you may observe different results depending on what has not been saved. If you have renumbered the stack unit IDs, you may see a configuration mismatch because your changes no longer match the active controller configuration.
If you change priorities to elect an active controller, the new active controller assumes its role after a reboot, whether or not you have used the write memory command. If you do not save your priority change before the next reboot, the reboot triggers an election that may result in a different winner based on the priority in the unsaved configuration. The new winner assumes the active controller role after the next reboot.
If you change the stacking port configuration and do not save your changes, you may encounter connectivity errors. To recover from a configuration error, define the correct stacking port by running secure-setup.