Configuration Guide User guide

FastIron Configuration Guide 325
53-1002494-02
More about IronStack technology
More about IronStack technology
This section discusses stacking technology in greater detail than the information presented in
Section 1.
Configuration, startup configuration files,
and stacking flash
Stacking system behavior is defined by the run time configuration, which can be displayed using
the show run command. The write memory command stores the run time configuration in a flash
file called startup-config.txt. During bootup, the system reads and applies the startup-config.txt file
to the run time 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
will 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 will 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. For more information,
refer to “Unconfiguring an IronStack” on page 287.
Whenever a change is made to a stack unit's configuration, such as priority, (which could affect
stack elections) an election is held, and the result is written into the stacking.boot file. A prompt
message appears on the console that suggests you do a write memory. For an Active Controller role
change to take effect, you will need to reset the entire stack.
If you do not do a write memory, and reset the stack, the stack units will continue to operate in their
roles as defined by the stacking.boot file. After the reset, each unit readjusts based on the current
run time configuration. However, you may get 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 will assume its role
after a reboot whether you have done a write memory or not. If you do not save your priority change
before the next reboot, the reboot will trigger an election that may result in a different winner based
on the priority in the unsaved configuration. The new winner assumes its 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, run Secure Startup to define the correct
stacking port.
NOTE
You should always do a write memory after making stacking-related configuration changes such as
priority and stacking ports. If you do not want to keep the changes, change the configuration back
to the previous version, and do a write memory. Do not discard configuration changes by using the
reset without a write memory.