Purpose	Use the activate configs command to enable all of the volumes and services in a pre-loaded global-config file. If this site is a backup for another site, this is the final step in performing a disaster-recovery operation.
Mode	priv-exec
Security Role(s)	crypto-officer
Syntax	activate configs file-name [partial][take-ownership][tentative] activate replicated-configs file-name ...   file-name (1-1024 characters) is the name of the global-config file. You can activate a replicated global-config from a remote cluster or a locally-defined global-config file. Use show replicated-configs for a list of replicated-config files from other clusters, or use show configs for a list of locally-defined configuration files. partial (optional) activates a subset of the full configuration. This can be any of these keywords, or any combination of them: global-server fqdn (1-128 characters) activates a particular global-server configuration, along with all of its component objects (such as its namespace and all the shares behind it). This is the fully-qualified domain name (for example, myserver.myorg.org) for one global server in the global-config. Use show replicated-configs file-name to view the global config and see all of its global servers. shares activates all shares. volumes activates all volumes. global-servers activates all global servers. policies activates all rules and share farms. If you specify any of the above, the command activates only the specified option(s). If you omit all of them, the command enables all global servers, volumes, and shares but does not activate any policy rules. take-ownership (optional, but recommended) causes the command to use the take-ownership option for every managed-volume share that it enables (see the documentation for enable (gbl-ns-vol-shr)). The filer-replication process typically copies hidden files from the back-end shares at the source site, including files that mark the back-end share as already imported by the source sites ARX. The managed volumes will not import these shares unless the take-ownership flag is raised. tentative (optional) creates a report to describe the how the command runs, but does not actually enable any configuration objects. The CLI shows the name of the report after you issue the command. You can use show reports report-name to review the report and confirm that the command implements the configuration as desired.   activate replicated-configs file-name ... is an alternative syntax, with the same options as described above for activate configs.
Default(s)	partial - shares volumes global-servers
Guidelines: Preparation for Disaster	This command is used in a disaster-recovery operation, which requires preparation before the disaster occurs. Preparing Back-End Filers You begin by using file-replication facilities (such as NetApps SnapMirror, EMCs SRDF, or RoboCopy) to duplicate the storage from an active site to a backup site. Continuously replicate all of the back-end shares behind the ARX. Also create back-end shares for managed-volume metadata at the backup site, but you do not need to replicate the source sites metadata. The ARX software at the backup site will recreate the metadata there. Then you begin the process of building a global configuration to be regularly copied from the active site to the backup site. The global configuration includes all storage-service parameters; see show global-config. The peers at the active site run the global configuration during normal service, and the peers at the backup site run it after a disaster. Sharing Master Keys and Removing Global-Config from Backup Site The ARX peers at both sites must share the same master key in order to share the same global configuration. The master key encrypts and decrypts all of the passwords and other Critical Security Parameters (CSPs) in the global-config file. Use the show master-key command to show an encrypted copy of the master key on the current ARX. The master keys should be synchronized during installation time, as described in the Hardware Installation manuals. If the backup peers have the wrong master key, reset the peers to factory defaults and reset the master key. They should only have their network parameters configured (show running-config), along with the correct master key. The documentation for show master-key provides details for this process. Connecting Sites with a Full Mesh of RON Tunnels At the ARX CLI, use the ron tunnel command to connect both ARX peers at the active site to both peers at the backup site. That is, each ARX must have two tunnels, one to each peer at the other site. Removing All Storage Services from the Backup Cluster We recommend removing all namespaces, global servers, and front-end services from the backup cluster before you begin. This prevents any significant configuration conflicts between the active site and the backup site, which could possibly prevent a successful disaster recovery. Ideally, the backup cluster should only have network parameters configured (which you can see with show running-config), along with administrative accounts (show group users) and any AD forests that have been discovered in the network (show active-directory). If there are any storage services on the backup cluster, we recommend removing them. From the backup clusters CLI, use remove service namespace for each namespace in the backup clusters configuration. The remove service command removes the namespace configuration along with all associated external-filer definitions, and it also removes ARX metadata from the filers behind the namespace. Then use no global server, no cifs, and/or no nfs to remove all of the global servers and front-end services at the backup cluster.
Guidelines: Preparation for Disaster (Cont.)	Building a Shared Global-Config Once all ARX peers have the same master key and are connected by RON tunnels, use the cluster-name command to establish a cluster name for each site. The cluster-name command also assigns each peer to a cluster. You then expand the active clusters global configuration so that it can also include the backup clusters file servers and Virtual-IP addresses: Add a new external-filer object for each of the backup sites filers. After you define them, the active cluster has definitions for all the active sites filers and all the backup sites filers. With both sets of filers defined, you can use the following commands to associate each filer to its role in each cluster: metadata share ext-filer ... cluster n chooses ext-filer to host a metadata share in cluster n. You run the command again to choose a different filer for this metadata share at the other cluster. filer ext-filer ... cluster n chooses a filer to host a storage share in a particular cluster. As above, you run the command twice for each share; once to choose the filer at the active cluster, and another time to choose the filer at the backup cluster. sam-reference ext-filer ... cluster n chooses ext-filer to play the role of a SAM-reference filer in cluster n. You run the command again to choose a different filer for SAM at the other cluster. Use the virtual server ... vip ... cluster n command to set the vip (Virtual-IP) addresses for use at cluster n. This brings you into a submode, with several commands for setting CIFS-service names. The submode, and those service names, are the same for both clusters; if the submodes commands were already set for the active cluster, you can exit the mode without repeating them for the backup cluster. Regularly Copying the Global-Config to the Backup Cluster This prepares the active clusters global config so that it is valid at either the active cluster or the backup cluster. Then create a config-replication rule to regularly copy that global config from the active cluster to the backup cluster. Preparing for Snapshot Reconstitution If you use any snapshot rules to back up client data, and if the filer-replication application copies the snapshots to the backup site, we advise that you also prepare for snapshot reconstitution. You prepare for snapshot reconstitution by regularly copying snapshot reports off of the active cluster, along with a Perl script in the configs directory. The guidelines for snapshot rule describe this preparation process in detail: see Guidelines: Preparing for Snapshot Reconstitution.
Guidelines: Preparation for Disaster (Cont.)	Testing the Load Configs Operation at the Backup Cluster After the global-config is successfully copied to the backup cluster, we recommend an occasional test of the load configs command at that cluster. This loads all of the active clusters storage services into the database without enabling any shares or volumes. It also loads the Active Directory configuration, which may not be correct for the backup cluster; after the load operation, run active-directory update seed-domain there to confirm that the AD configuration is correct. If you are running CIFS services with constrained delegation, you require some additional configuration at the Domain Controller (DC) to support your CIFS clients. The back-end CIFS servers at the backup cluster must be on the delegate-to list for each front-end CIFS service; for each cifs service, run the probe delegate-to command to find any back-end servers that need to be added to the list, and add them at the DC. When you finish, the CIFS services delegate-to list includes the back-end servers behind both clusters. This configuration occurs at the DC, and persists after this load-configs test. Check the remaining configuration to confirm that it is correct. Then use remove service to remove each of the namespaces that you added with the load configs command. Finally, use no global server, no cifs, and/or no nfs to remove all of the global servers and front-end services.
Guidelines: Disaster Recovery	To recover from a disaster, go to the backup cluster and run load configs on the global-config file that was copied earlier. This loads the global-config into the database without enabling any shares, volumes, global servers, or policy rules. You can use this command, activate configs, to enable any or all of those objects. Unless you use the tentative option, the CLI prompts for confirmation before activating the global-config file. Enter yes to proceed. The best practice is to activate the configuration in stages and verify the success of each stage. Use the following command order, as time allows: activate configs ... shares take-ownership, then activate configs ... volumes. Periodically use show namespace status to verify that the volumes come online, and that there are no issues blocking your imports. You can use show namespace for detailed status. activate configs ... global-servers. You can use show cifs-service and/or show nfs-service to confirm that client services are running. Also verify that you can connect to the global server(s) as a client. activate configs ... policy. (The policy keyword is required for the activate configs command to enable any rules.) Use show policy to confirm that all rules are migrating or otherwise functioning properly. Alternatively, you can bring up the shares, volumes, and global servers all at once by omitting any specific keywords. After confirming that the services are running properly, you can use activate configs ... policy to activate all rules. If you also prepared for snapshot reconstitution, play back the snapshot reconstitution script as described in Guidelines: Reconstituting ARX Snapshots. If the cluster at the failed site is still on the network after the disaster, log into the cluster and use no enable (gbl-cfg-repl) to stop copying the global configuration from the now-backup site.
Guidelines: Report	This command always creates a report to show its actions. The CLI shows the name of the report after you issue this command. You can use tail report-name follow to follow the report as the command runs, or show reports report-name to view the report after the command has finished. The configuration file is an ordered list of CLI commands that recreate the global configuration, including all volumes and storage services. The report shows these CLI commands as it runs them. If it reaches a configuration object that already exists in the local database, it shows an INFO message to explain that the object is being ignored. An X appears at the beginning of each ignored line. This includes the enable command for each activated configuration object (such as a share or volume); the load configs command does not enable any configuration objects.
Samples	newptA# activate configs provSvcs.rcfg tentative   Generating activate configuration report: 'act_provSvcs.rcfg_201007060305'.   performs a tentative activation of the global-config file, provSvcs.rcfg.   newptA# activate configs provSvcs.rcfg shares take-ownership   This enables the global configuration.   Are you sure? [yes/no] yes   Generating activate configuration report: 'aact_provSvcs.rcfg_20100709113618'.   activates all shares from the above configuration, and takes ownership of them. See Figure 35.1 for a sample report.
Related Commands	load configs show global-config

Purpose	A cluster is single ARX site, comprised of a redundant pair of ARX systems or a standalone ARX. Use this command to declare a cluster name for any ARX (or redundant-ARX pair) in the current Resilient Overlay Network (RON). This name is required for configuring disaster recovery between two ARX sites. Use no cluster-name to remove a cluster name from the ARX configuration.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	cluster-name cluster-name member peer-a [member peer-b] no cluster-name cluster-name member peer-a [member peer-b]   cluster-name (1-64 characters) is the name you choose for this cluster. peer-a (1-64 characters) is an ARX that you assign to the above cluster. Each ARX can be assigned to a single cluster only. The ARX must already be on the same RON as the current switch; you can use the show ron command for a full list of all switches on the RON. peer-b (1-64 characters) is the redundant peer to the above ARX, if there is one. You can use the show ron peer-a command to find if peer-a has a redundant peer.
Default(s)	None.
Guidelines	This command establishes an ARX site as a cluster, capable of failing its global-configuration over to another cluster. You can create two clusters on your RON and set them up in a disaster-recovery configuration, so that one can take over service for the other in the event of a catastrophic failure. The ron tunnel command creates a RON tunnel between any two ARX systems on the same WAN; use that command to create a full mesh of RON tunnels between all four peers. Additionally, ensure that all four peers have the same master key, so that they can share their global configurations (see show master-key for details). To set up disaster recovery between two clusters, you designate one cluster as active and the other as the backup site. Use filer-replication facilities (for example, NetApps SnapMirror or EMCs SRDF) to copy all files and directories from the active sites back-end filers to their counterparts at the backup site. Once the files and directories are synchronized, add all of the backup clusters external-filers to the active clusters configuration. Use the filer, metadata share, and sam-reference commands to establish how those filers should be used in the backup cluster. Then use the virtual server command to establish a new Virtual-IP address and configuration for each global server in the backup cluster. Finally, create a config-replication rule to regularly copy this configuration from the active cluster to the backup cluster. This prepares the backup site to take over service from the active site. If the active site fails, you can then resume your storage services at the backup cluster. To accomplish this, go to the backup cluster and use load configs to load the active sites configuration into the backup clusters database, then use activate configs to enable all volumes and services at the backup cluster.
Guidelines: Only One Metadata Share Per Managed Volume	A cluster allows the configuration of a single metadata share per managed volume. If any managed volume has more than one metadata share, this command fails. A single metadata share per volume is required to ensure that the disaster-recovery software can reliably re-create the volume configuration on a backup cluster.
Guidelines: Removing Cluster Configuration	To remove a remote cluster along with all its associated filers, metadata shares, and virtual servers, use the remove cluster-config command. You can use the same command on the local cluster to remove the cluster object and all references to it, without actually removing the above objects. The no cluster-name command removes only the cluster definition; the CLI rejects this operation if the cluster name is referenced by any of the above objects.
Sample	provA(gbl)# cluster-name providence member provA provB provA(gbl)# cluster-name newport member newptA newptB creates two new clusters, providence and newport. You can now set up one as a backup site for the other.
Related Commands	config-replication load configs activate configs remove cluster-config

Purpose	Use the config-replication command to create a rule for replicating the global configuration to an ARX cluster at another site. A cluster is a redundant pair of ARX systems. This prepares for a disaster-recovery scenario. If your back-end filers mirror their data between the sites, this rule mirrors the configuration data for managing those filers at each site. Use the no form of the command to delete the rule.
Modes	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	config-replication name cluster cluster-name no config-replication name cluster cluster-name   name (1-32 characters) is the name you choose for the rule. cluster-name (1-64 characters) is the name of the source cluster. This cluster must be defined in the database; you can use the show cluster command for a complete list of pre-defined clusters.
Default(s)	None
Guidelines: Preparing to Share Configs Between Clusters	Before you copy the global configuration file from one cluster to another, the cluster members require require matching master keys and a full mesh of RON tunnels. The master key for an ARX encrypts and decrypts the passwords in its global-config file, so it must be the same for all switches that share the global-config. The backup switches should have the same master key as their active counterparts; the master keys should be set accordingly when the backup switches are installed. Refer to the documentation for the show master-key command for information on showing the key and possibly changing it on the backup switches. Every switch in the active cluster must have a ron tunnel to every switch in the backup cluster. This provides multiple pathways for copying the global configuration between clusters. The backup cluster should not have any storage services configured, so that it accepts the latest storage-services configuration from the active cluster without any conflicts. If the backup cluster has any namespaces, use remove service to cleanly remove each of them. Also use no global server, no cifs, and/or no nfs to remove all of the global servers and front-end services at the backup site.
Guidelines	The config-replication command creates a rule to regularly copy the active clusters global configuration and send it to the backup cluster. The command puts you into gbl-cfg-repl mode, where you have various configuration commands for configuring the config-replication rule. Use the target-cluster command to choose the ARX cluster to receive this configuration. Then use the user (gbl-cfg-repl) command to enter your administrative credentials at the remote cluster; this gives you permission to write the configuration file there. The target-file command provides a name for the file copy. Use the schedule (gbl-cfg-repl) command to choose a regular schedule for duplicating the configuration file. We recommend using the report (gbl-cfg-repl) command to create a report about each config-replication event. You can also use the description (gbl-cfg-repl) command to describe this rule in the output of show policy. Finally, use the enable (gbl-cfg-repl) command to start the rule.
Guidelines: Schedule	To create a schedule to be applied to the config-replication rule, use the gbl schedule command at the source cluster. The rule fires as dictated by its schedule: if the schedule has a start time that is earlier than now, the first config replication begins as soon as you enable the rule.
Guidelines: Reports	As mentioned above, we recommend that you use the config-replication report feature to keep a detailed log of all config-replication events. The reports appear on the source cluster: the show reports command shows all reports on the switch, including config-replication reports. You can use the standard file-management commands with these reports: delete, rename, show reports file-name, tail, and/or grep.
Guidelines: Preparing for Disaster Recovery	The global-config file replicated by this rule must support both clusters before you can use it to recover from a disaster. Expand the active clusters global configuration so that it can also include the backup clusters file servers and Virtual-IP addresses: Add a new external-filer object for each filer at the backup site. With both sets of filers defined on the active cluster, you can use the following commands to associate each filer to its role in each cluster: metadata share ext-filer ... cluster n chooses ext-filer to host a metadata share in cluster n. You run the command again to choose a different filer for this metadata share at the other cluster. filer ext-filer ... cluster n chooses a filer to host a storage share in a particular cluster. As above, you run the command twice for each share; once to choose the filer at the active cluster, and another time to choose the filer at the backup cluster. sam-reference ext-filer ... cluster n chooses ext-filer to play the role of a SAM-reference filer in cluster n. You run the command again to choose a different filer for SAM at the other cluster. Use the virtual server ... vip ... cluster n command to set the vip (Virtual-IP) addresses for use at cluster n. This brings you into a submode, with several commands for setting CIFS-service names. The submode, and those service names, are the same for both clusters. This prepares the active clusters global config so that it is valid at either the active cluster or the backup cluster.
Sample	provA(gbl)# config-replication prov2newport cluster providence   instantiates a new config-replication rule, prov2newport.
Related Commands	target-cluster user (gbl-cfg-repl) target-file schedule (gbl-cfg-repl) report (gbl-cfg-repl) description (gbl-cfg-repl) enable (gbl-cfg-repl) schedule show reports

Purpose	Use the optional description command to set a descriptive string for the current config-replication rule. This appears in show commands. Use the no form of the command to delete the description.
Mode	gbl-cfg-repl
Security Role(s)	storage-engineer or crypto-officer
Syntax	description text no description   text (1-48 characters) is your description. Surround the text with quotation marks () if it contains any spaces.
Default(s)	no description
Guidelines	The description appears in the output for show config-replication.
Sample	provA(gbl-cfg-repl[prov2newport])# description send service config to Newport site specifies a description for the current config-replication rule.
Related Commands	config-replication show config-replication

Purpose	Use the enable command to enable the current config-replication rule. Use no enable to disable the rule.
Modes	gbl-cfg-repl
Security Role(s)	storage-engineer or crypto-officer
Syntax	enable no enable
Default(s)	no enable
Guidelines	You must enable the config-replication rule for the policy engine to use it. Once enabled, the config-replication rule follows its assigned schedule (set with the schedule (gbl-cfg-repl) command) and copies its global-config file to the target ARX cluster (target-cluster). The no form of the command is useful in a formerly-active cluster that is still on the network. Use the no enable command to stop the cluster at the failed site from copying its configuration to the newly-active site.
Samples	provA(gbl-cfg-repl[prov2newport])# enable enables the prov2newport rule.   bstnA(gbl-cfg-repl[dr-test])# no enable disables the dr-test rule.
Related Commands	config-replication

Purpose	The global-config parameters are shared among both ARXes in a redundant pair. (The traditional running-config applies only to the local switch.) You can copy the global-config from one redundant pair to another, so that the second redundant pair (called an ARX cluster) can act as a backup for the first. Use this command, load configs, to load a global-config into the local database without enabling any configuration objects. This is the first step in disaster recovery; this cluster can use the loaded configuration to take over services from the failed cluster.
Mode	priv-exec
Security Role(s)	crypto-officer
Syntax	load configs file-name [global-server fqdn] [tentative] load replicated-configs file-name ...   file-name (1-1024 characters) is the name of the global-config file. You can load a replicated global-config from a remote cluster or a locally-defined global-config file. Use show replicated-configs for a list of replicated-config files from other clusters, or use show configs for a list of locally-defined configuration files. fqdn (optional, 1-128 characters) selects a particular global-server configuration, along with all of its component objects (such as a namespace and all the external-filers behind it). This is the fully-qualified domain name (for example, myserver.myorg.org) for one global server in the global-config. Use show replicated-configs file-name to view the global config and see all of its global servers. tentative (optional) creates a report to describe the how the command runs, but does not actually commit any configuration changes to the database. The CLI shows the name of the report after you issue the command. You can use show reports report-name to review the report and confirm that the command implements the configuration as desired. load replicated-configs file-name ... is an alternative syntax, with the same options as described above for load configs.
Default(s)	None
Guidelines	After proper preparations have been made for disaster recovery (see the documentation for the config-replication command), you can use this command as a first step toward recovering from a disaster at a remote site. After you run this command to load the configuration, use activate configs to enable it and start client services at the current cluster.
Guidelines: Reports	This command always creates a report to show its actions. The CLI shows the name of the report after you issue this command. You can use tail report-name follow to follow the report as the command runs, or show reports report-name to view the report after the command has finished. The configuration file is an ordered list of CLI commands that recreate the global configuration, including all volumes and storage services. The report shows these CLI commands as it runs them. For every configuration object that the load operation ignores, an INFO message appears before the object to explain why it was skipped. An X appears at the beginning of each ignored line.
Guidelines: Rules for the Load Operation	The load operation skips configuration objects that meet any of the following criteria: A configuration object of the same name already exists on this ARX. The load operation does not overwrite existing configuration objects. The exception to the above rule is the namespace configuration. The load operation merges namespaces by creating any volumes, shares, and rules that are not already present in the local configuration.
Guidelines: Loading Configurations from Higher-Rev Systems	If you use a configuration from a newer release of ARX software, edit the script before you load it. Command syntax may have changed as well as the best practices for command order. Consult this manual (and other documentation from the current release) for the correct syntax, and change the configuration files commands as needed. The load operation prompts for confirmation if it finds that the configuration is for a newer release. After you edit the configuration, enter yes to proceed.
Guidelines: Recommendations	We recommend running this command on a cluster without any storage services in its global configuration. If any object in the global-config file has the same name as an object that already exists, the load operation typically does not change the object that already exists. Therefore, if you load a configuration onto a backup cluster and leave it there, change the configuration on the active cluster, and copy the changed configuration to the backup cluster to load it again, many (possibly all) of the configuration changes are ignored at the backup cluster. If you run a test load before any disaster, we recommend using remove service for each loaded service after you finish. Also use no global server, no cifs, and/or no nfs to remove all of the global servers and front-end services. Contact F5 Support for advice if you wish to retain different global-config parameters at the backup site.
Samples	newptA# load configs provSvcs.rcfg tentative   Generating load configuration report: 'load_provSvcs.rcfg_201007010258'.     performs a tentative load of the global-config file, provSvcs.rcfg.   newptA# load config provSvcs.rcfg   Generating load configuration report: 'load_provSvcs.rcfg_201007091136'.     loads the same configuration file into the local database. A sample report appears in Figure 35.2.
Related Commands	config-replication activate configs show replicated-configs

Purpose	Use the remove cluster-config command to delete a cluster-name from the database along with any references to that cluster name. If you use this with the remote cluster name, this removes all filers, metadata shares, and/or virtual servers associated with that cluster. If you use this with the current cluster name, this only removes the cluster name from those configuration objects, leaving them otherwise intact.
Modes	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	remove cluster-config cluster-name   cluster-name (1-64 characters) identifies the cluster. You can use the show cluster command for a complete list of configured clusters.
Default(s)	None.
Guidelines	The CLI prompts for confirmation before removing or changing any configuration objects; enter yes to proceed. For a remote cluster, this removes the following objects from the system: any filer, any metadata share, or any virtual server that resides in the cluster. For the local cluster, this only removes the cluster name from the above objects. They remain in the configuration, but without the cluster name as part of their definitions. If any of the above object types refer to a cluster name, you cannot use no cluster-name to remove the cluster name. This command exists as a convenience; it is a single command for removing the cluster name and all of its dependent configuration. To change the name of the local cluster, you can use this command to remove the current name and then use the cluster-name command to add the new cluster name to all of the above objects at once.
Sample	bstnA# remove cluster-config portland   This removes all configuration for this cluster.   Are you sure? [yes/no] yes removes all configuration objects associated with the portland cluster.
Related Commands	cluster-name

Purpose	Use this command to enable progress reports for the current config-replication rule. Use no report to prevent progress reports.
Mode	gbl-cfg-repl
Security Role(s)	storage-engineer or crypto-officer
Syntax	report file-prefix [verbose] no report   file-prefix (1-1024 characters) sets a prefix for all config-replication reports from this rule. Each report has a unique name in the following format: prefixYearMonthDayHourMinute.rpt For example, gblRepl2newport201003031200.rpt could be the name for one report with the gblRepl2newport prefix. verbose (optional) enables verbose data in the reports.
Default(s)	no report
Guidelines	Every time the config-replication rule fires and duplicates the global-config, the rule can generate a report to show the details of the copy session. The reporting feature is disabled by default; we recommend that you enable reporting for all config-replication rules, to keep a log of all these copy sessions. Use show reports for a list of reports, or show reports file-name to show the contents of one report.
Samples	provA(gbl-cfg-repl[prov2newport])# report gblRepl2newport enables reports for the config-replication rule, prov2newport. For a sample report, see Figure 35.3.   bstnA(gbl-cfg-repl[dr-test])# report drTest verbose enables verbose reports for the config-replication rule, dr-test.   newptA(gbl-cfg-repl[newpt2prov])# no report disables reports for the newpt2prov rule.
Related Commands	config-replication

Purpose	Use this schedule command to assign a schedule to the current config-replication rule. Use no schedule to remove the rules schedule.
Mode	gbl-cfg-repl
Security Role(s)	storage-engineer or crypto-officer
Syntax	schedule name no schedule   name (1-64 characters) identifies the schedule. Use show schedule for a list of configured schedules.
Default(s)	None.
Guidelines	A config-replication rule copies the global-configuration from the current ARX to another ARX at a backup site. This copy operation occurs on the schedule you choose with this command. To create a schedule, use the gbl-mode schedule command. You cannot use a schedule with a fixed duration; a config-replication rule must always run to completion in order to succeed.
Sample	provA(gbl-cfg-repl[prov2newport])# schedule oncePerDay assigns the oncePerDay schedule to the config-replication rule, prov2newport.
Related Commands	config-replication schedule show schedule

Purpose	Use the show cluster command to get a list of all ARX clusters, or redundant pairs, known to the current ARX. You can set up ARX clusters so that one cluster can act as a backup for another.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show cluster [cluster-name]   cluster-name (optional, 1-64 characters) shows only the chosen cluster.
Guidelines	The summary output shows a table of clusters, one row per cluster. Each row has the following columns: Cluster Name identifies the cluster. You set this when you use the cluster-name command to create the cluster. Member is the hostname of one ARX in the cluster (typically a redundant pair). Member in the next column is for the above switchs redundant peer, if there is one.
Samples	provA# show cluster shows all clusters. See Figure 35.4 for sample output.   provA# show cluster newport shows one cluster. See Figure 35.5 for sample output.
Related Commands	cluster-name

Purpose	Use the show config-replication command to see the current status of one or more config-replication rules. A config-replication rule copies the global config (see show global-config) from the current site to an ARX at a disaster-recovery site.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show config-replication [rule-name]   rule-name (optional, 1-32 characters) provides configuration details for a particular config-replication rule.
Guidelines: Summary Output	The summary output shows a table of config-replication rules, one row per rule. Each row has the following columns: Name identifies the rule. You set this when you use the config-replication command to create the rule. Cluster is the name of the target ARX cluster (or redundant pair) where the rule sends its global configuration file. You can set this with the target-cluster command. Filename is the name of the configuration file that the rule creates at the remote cluster. You can change this with the target-file command. Schedule is the name of the schedule for the config-replication rule. Use the schedule (gbl-cfg-repl) command to assign a schedule to the rule. Admin State is Enabled or Disabled, depending on the setting of the enable (gbl-cfg-repl) command.
Guidelines: Detailed Output	Detailed output appears when you specify a config-replication rule in the command. The detailed output contains these fields: Name identifies the rule, as described above. Description describes the rule, as specified with the description (gbl-cfg-repl) command. Cluster is the name of target cluster, as described for the summary output above. Target Filename is the name of the configuration file that the rule creates. This is the same as the Filename in the summary output. Report Prefix shows the prefix used in all of the rules reports. The reports appear on the source cluster. You can use the report (gbl-cfg-repl) command to change this prefix. Username is the administrative user name used for authentication at the remote cluster. These credentials confirm that the rule is authorized to write the configuration file. This is a valid administrative user at the ARX cluster that receives the copy. Admin State is Enabled or Disabled, as described above for the summary output.
Guidelines: Detailed Output (Cont.)	Status shows the results of the last attempt to copy the global-config: Copy Successful indicates a success. Not Copied Yet means that the rules schedule (gbl-cfg-repl) has not started yet. The config-replication target-cluster is not defined for rule. shows that the copy failed because the config-replication rule has no target. You can use the target-cluster command to define a target cluster for the copy operation. The config-replication user is not defined for rule. shows that the copy failed because the config-replication rule has no user defined. The rule needs an administrative user name that is valid at the target cluster, so that it has permission to copy a file onto the remote ARX. You can use the user (gbl-cfg-repl) command to identify an administrative account for the copy operation. File file-name does not exist. means that an internal process failed to open file-name, a temporary version of the global-config file. This indicates an internal error; contact F5 Support if you see this. Any other error indicates a low-level error with the SCP process. Contact F5 Support if you see any such error in this field. Schedule is the schedules configured name, chosen with the schedule (gbl-cfg-repl) command. The fields in this table show the configuration of the schedule. Start Time can be reset by the gbl-schedule start command. This is the date and time of day used for all time-based calculations: for example, if a schedule runs every Saturday, this determines the time of day on Saturdays when the schedule fires. Interval is set by the gbl-schedule every command. This is the time between scheduled runs. Status is Paused (the schedule is between run times), Running, or Waiting for start time (the schedule has never been invoked). Previous is a sub-table showing the Run time (when the run started) and End time of the most-recent run. Current appears if the rule is currently running. This has the same fields as the Previous table, Run time and End time. Next shows when the schedules next run will begin. It also has the Run time and End time fields.
Samples	provA# show config-replication shows the status of all config-replication rules. See Figure 35.6 for sample output.   provA# show config-replication prov2newport shows the detailed status for a particular rule. See Figure 35.7 for sample output.
Related Commands	config-replication

Purpose	Use the target-cluster command to choose a remote ARX cluster as a target for copies of the local clusters configuration. The current config-replication rule copies the global-configuration from the local cluster on a schedule. This prepares the remote cluster as a backup for the local cluster in the event of a disaster at the local site.
Mode	gbl-cfg-repl
Security Role(s)	storage-engineer or crypto-officer
Syntax	target-cluster cluster-name   cluster-name (1-64 characters) is the target cluster for the copy of the global-config file. This cluster must be defined on the current ARX; use the show cluster command for a list of defined clusters, or the cluster-name command to define one.
Default(s)	None.
Guidelines	This command sets a cluster target for the current config-replication rule. A cluster is a redundant pair of ARX peers (see redundancy), or possibly a standalone ARX.
Sample	provA(gbl-cfg-repl[prov2newport])# target-cluster newport uses the newport cluster as the target for the prov2newport rule.
Related Commands	config-replication cluster-name show cluster

Purpose	The current config-replication rule copies the global-configuration from the local cluster to a remote cluster on a schedule. Use the target-file command to choose the name of the remote copy. The copy operation prepares the remote cluster as a backup for the local cluster in the event of a disaster.
Mode	gbl-cfg-repl
Security Role(s)	storage-engineer or crypto-officer
Syntax	target-file file-name   file-name (1-255 characters) is the file name for the destination file.
Default(s)	None.
Guidelines	This command sets a file-name target for the current config-replication rule. A cluster is a redundant pair of ARX peers (see redundancy), or possibly a standalone ARX. A config-replication rule copies the local clusters global configuration (see show global-config) to a remote cluster. This prepares the remote cluster as a backup for the local cluster, in case of a disaster at the local site.
Sample	provA(gbl-cfg-repl[prov2newport])# target-file provSvcs.rcfg uses the name, provSvcs.rcfg, as the target file name for the prov2newport rule.
Related Commands	config-replication

Purpose	When you use a config-replication rule to copy the global configuration to a remote ARX cluster, you require an administrative username and password for the remote peer. Use the user command to set this username and password. Use the no form of this command to remove the administrative credentials, effectively disabling the config-replication rule.
Mode	gbl-cfg-repl
Security Role(s)	storage-engineer or crypto-officer
Syntax	user name no user   name (1-32 characters) is a valid administrative user at a remote ARX.
Default(s)	None.
Guidelines	The CLI prompts twice for a password. See the sample below.
Sample	provA(gbl-cfg-repl[prov2newport])# user admin Password: s3cr3tpasswd Validate Password: s3cr3tpasswd provA(gbl-cfg-repl[prov2newport])# ... provides a username and password, admin and s3cr3tpasswd, for sending global-config copies to a remote ARX.
Related Commands	config-replication