These changes are stored temporarily in the running configuration in the RAM of the switch. In order to save these changes, the running configuration must be saved to the working directory as shown:
In this diagram:
1 The switch boots from the certified directory, and the software is loaded to the RAM to create a running configuration.
2 Changes are made in the running configuration and are saved to the working directory.
Now the boot.cfg file in the running configuration and the boot.cfg file in the working directory are identi- cal. Should the switch go down or reboot, the configuration changes made can be restored.
Note. If the switch is rebooted at this point in the process, since the certified and working directory boot.cfg files are not the same, the switch will boot and run from the certified directory. (See “Where is the Switch Running From?” on page 4-4 for a description of this process.)
The modifications made to the functionality of the switch are recorded in the running configuration, in the RAM. These changes in the RAM are only valid until the switch is rebooted. At that time, the switch reboots from the certified directory. If the running configuration is not saved to the working directory before a reboot, then the changes made in the running configuration are lost. To save these changes, it is necessary to save the contents of the running configuration to the working directory.
Working Certified
Running Primary CMM
1 2
Managing CMM Directory Content Managing the Directory Structure (Non-Redundant)
To save the running configuration to the working directory, enter the copy running-config working or write memory command at the prompt, as shown:
-> copy running-config working or
-> write memory
The above commands perform the same function. When these commands are issued the running configu- ration with all modifications made is saved to a file called boot.cfg in the working directory.
Note. This command will not function if the switch is running from the certified directory. See “Where is the Switch Running From?” on page 4-4 for an explanation.
The copy running-config working and write memory commands are described in detail in the
OmniSwitch CLI Reference Guide.
Note. The saved boot.cfg file will be overwritten if the takeover command is executed after the copy running-config working or write memory commands in an OmniSwitch set up with redundant CMMs.
Note. It is important to certify the working directory and synchronize the stack as soon as the validity of the working directory software is established in OmniSwitch 6800 switches only. Stacks booted from the working directory or unsynchronized stacks are at risk of mismanaging data traffic due to incompatibili- ties in different versions of switch software. Certifying the working directory is described in “Copying the Working Directory to the Certified Directory” on page 4-21, while synchronizing the switch is described in “Synchronizing the Primary and Secondary CMMs” on page 4-27.
Managing the Directory Structure (Non-Redundant) Managing CMM Directory Content
Rebooting from the Working Directory
Besides a regular boot of the switch (from the certified directory), you can also force the switch to boot from the working directory. This is useful for checking whether a new configuration or image file will boot the switch correctly, before committing it to the certified directory. (For information on saving the working directory to the certified directory, see “Copying the Working Directory to the Certified Direc- tory” on page 4-21.)
The following picture illustrates the case of a switch being rebooted from the working directory:
In the above diagram:
1 The certified directory is used to initially boot the switch.
2 Changes are made to the configuration file and are saved to the configuration file in the working direc- tory by using the copy running-config working command, described in the section “Copying the Running Configuration to the Working Directory” on page 4-16.
3 The switch is rebooted from the working directory by using the reload workingcommand.
When a reload working command is entered, the switch prohibits a takeover from the secondary CMM. Switch functions are suspended until the boot process is complete.
If you decide against using the new software booted from the working directory, the switch can revert to the software stored in the certified directory by using the copy certified working command as described in “Copying the Certified Directory to the Working Directory” on page 4-22, or by using the reload command as described in “Rebooting the Switch” on page 4-13.
Working Certified
Running Primary CMM
1
Managing CMM Directory Content Managing the Directory Structure (Non-Redundant)
Note. If the switch is rebooted before using the copy certified working command, the switch will be running from the certified directory as the working and certified directories are not the same. This behav- ior is described in “Where is the Switch Running From?” on page 4-4.
To reboot the switch from the working directory, enter the following command at the prompt, along with a timeout period (in minutes), as shown:
-> reload working rollback-timeout 5
At the end of the timeout period, the switch will reboot again normally, as if a reload command had been issued.
Note. It is important to certify the working directory and synchronize the stack as soon as the validity of the software is established in OmniSwitch 6800 switches only. Stacks booted from the working directory or unsynchronized stacks are at risk of mismanaging data traffic due to incompatibilities in different versions of switch software. Certifying the working directory is described in “Copying the Working Direc- tory to the Certified Directory” on page 4-21, while synchronizing the switch is described in “Synchroniz- ing the Primary and Secondary CMMs” on page 4-27.
Rebooting the Switch from the Working Directory with No Rollback Timeout It is possible to reboot from the working directory without setting a rollback timeout, in the following manner:
-> reload working no rollback-timeout Scheduling a Working Directory Reboot
It is possible to cause a working directory reboot of the CMM at a future time by setting time parameters in conjunction with the reload workingcommand, using the in or at keywords. You will still need to specify a rollback time-out time, or that there is no rollback.
To schedule a working directory reboot of the CMM in 3 hours and 3 minutes with no rollback time-out, you would enter:
-> reload working no rollback-timeout in 3:03
To schedule a working directory reboot of the CMM at 8:00pm with a rollback time-out of 10 minutes, you would enter:
-> reload working rollback-timeout 10 at 20:00
Managing the Directory Structure (Non-Redundant) Managing CMM Directory Content
Cancelling a Rollback Timeout
To cancel a rollback time-out, enter the reload cancel command as shown: -> reload primary cancel
or
-> reload cancel
Managing CMM Directory Content Managing the Directory Structure (Non-Redundant)