Purpose	Use this command to clear the counters in the various show redundancy ... commands.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear counters redundancy [heartbeat | transition | network | critical-services]   heartbeat (optional) clears only the heartbeat-related counters. This applies to heartbeats over the redundant-pair link (from show redundancy peer) as well as quorum-disk heartbeats (from show redundancy quorum-disk). transition (optional) clears the counters associated with state/status transitions. This applies to all transition counters in all show redundancy ... commands. network (optional) clears only the network counters, from the show redundancy network output. See clear counters redundancy network for details. critical-services (optional) clears the counters associated with critical-services (from show redundancy critical-services).
Default(s)	If you omit all of the optional flags, this clears all redundancy counters from all show redundancy ... commands.
Platforms	any except ARX-VE
Guidelines	These counters appear in the output of four show commands: show redundancy peer, show redundancy quorum-disk, show redundancy network, and show redundancy critical-services. The first two of these commands have heartbeat counters that track the number of exchanged heartbeats. All of them have transition counters that track the number of times that the connection state has changed.
Samples	bstnA# clear counters redundancy bstnA# clears all counters.   bstnA# clear counters redundancy heartbeat bstnA# clears only the heartbeat-related counters. This does not clear any transition-related counters.   bstnA# clear counters redundancy transition bstnA# clears all transition-related counters from all show redundancy ... output.
Related Commands	show redundancy peer show redundancy quorum-disk show redundancy network show redundancy critical-services clear counters redundancy network

Purpose	Use this command to designate an external subnet as critical, so that a failover may occur if there is no route to the subnet. Use the no form of the command to make a subnet non-critical.
Mode	cfg-redundancy
Security Role(s)	network-engineer or crypto-officer
Syntax	critical route subnet mask no critical route subnet mask   subnet (0.0.0.0-255.255.255.255) is the IP address of the subnet. This must be reachable through at least one static route; use show ip route to view all static routes. mask (0.0.0.0-255.255.255.255) is the netmask, which identifies the network part of the subnet address.
Default(s)	No critical routes
Platforms	any except ARX-VE
Guidelines	The CLI prompts for confirmation if the route is down, the peer is down, or there is some other issue. Enter yes if you want to proceed anyway. You can re-issue this command multiple times to establish multiple critical routes. If a critical route fails on the current peer and the other peer has no failures, control fails over to the other peer. If the other peer has any failures that would ordinarily cause a failover (such as a major hardware fault), no failover occurs. This prevents unnecessary failovers. The ARX tests for failure with regular ARP requests. Every 20 seconds, the ARX sends an ARP to the routes gateway. (The gateway is configured with the ip route command.) If the gateway fails to respond, the ARX waits an additional 20 seconds before asking the peer if it is possible to fail over. The ARPs continue indefinitely at 20-second intervals. If the gateway responds before the failover is initiated, the failover does not occur. The ARX uses one of its in-band (VLAN) management addresses to send those ARP requests. The subnet you identify with this command must have a management address for its VLAN. Use the interface vlan command to create an in-band management address for a the subnets VLAN. From gbl-ns-vol-shr mode, you can declare a namespace share as a critical resource with the critical command. Critical routes (unlike critical shares) are not shared between redundant switches. This is because the switches may have different visibility into the network. To duplicate a critical route, issue this command on both peers. To show all critical routes and shares on the current peer, use the show redundancy critical-services command.
Samples	bstnA(cfg-redundancy)# critical route 172.16.54.0 255.255.255.0 designates a class-C subnet as a critical route. If the ARX loses all routes to that subnet and its redundant peer has no serious issues, a failover occurs. bstnA(cfg-redundancy)# no critical route 172.16.0.0 255.255.0.0 removes a class-B subnet from the list of critical subnets.
Related Commands	redundancy show redundancy critical-services critical interface vlan

Purpose	Use this command to enable redundant pairing on the current switch.
Mode	cfg-redundancy
Security Role(s)	network-engineer or crypto-officer
Syntax	enable no enable
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Before you enable redundant pairing through enable (cfg-redundancy), you must complete the following steps: 1. For ARX-2000 or ARX-4000: Prepare interfaces or a channel to connect the switches. At both switches, define an interface that can be used in a redundant-pair link (redundancy protocol), or define a larger channel between the two switches (redundancy protocol (cfg-channel)). This is unnecessary for the ARX-500, which has a dedicated port for this link. 2. For ARX-500 only: configure a ron tunnel between the switches to carry the redundancy heartbeats. 3. At each switch, identify the redundant peer using the peer command. 4. Define the quorum disk by using the quorum-disk command on both switches. Each peer writes its heartbeats to the same external-filer share, called a quorum disk, and reads the heartbeats from its peer. The quorum disk configuration must be identical on both switches. The enable command then starts the initial rendezvous of the switches. Once this command is invoked on the peer switch, the rendezvous can proceed. The pair is joined after the rendezvous is complete.
Guidelines: Resilvering	The enable command invokes the initial-rendezvous process, which then starts the metalog (namespace log) resilvering process. Metalog resilvering is duplicating the metalog data from the active peer to the backup peer. The metalog data must be mirrored on both peers to ensure that the namespace software can fail over. You may want to monitor the resilvering process if the peers are separated by a long distance: you can use the show redundancy metalog command for this. If resilvering times out due to excessive latency, you can use the resilver-timeout command to reset the timeout value.
Guidelines: Senior-Switch Election	The senior switch is elected based on its global configuration; if switch A has any namespaces or global servers and switch B does not, switch A becomes the senior switch. If neither has any namespaces or global servers, the one with the lower rendezvous address (established with the peer command) is elected senior. If both have namespaces and/or global servers, the rendezvous fails; see below.
Guidelines: Failure Recovery	One of the switches (if not both) should be devoid of any namespaces or global servers before you enable redundancy. If both have examples of these global-configuration objects, the rendezvous fails. Use the show redundancy history command to detect this failure. To recover, use the clear global-config command to remove all global-config from one of the peers and reboot it. Then enable redundancy again. The rendezvous also fails if the private subnets of the peers match, or if one peers private subnet matches any private subnet in the others RON. The show redundancy history command indicates this problem if it occurs. To recover, use no enable to undo the redundancy configuration, use ip private subnet reassign on one of the switches, then try enabling redundancy again. The switches continue to retry the rendezvous indefinitely. If you decide to abandon the pairing, you can use no enable to stop the switches from retrying. The no enable feature is disabled after the pair successfully forms.
Sample	prtlndA(cfg-redundancy)# enable enables redundant pairing on the current switch.
Related Commands	redundancy protocol redundancy protocol (cfg-channel) redundancy peer quorum-disk show redundancy show redundancy history

Purpose	By default, an NSM processor creates a detailed binary-core file if it has a failure. On the advice of F5 Support, you can use no nsm binary-core-files to return to the smaller ASCII form of NSM-core files. The nsm binary-core-files command re-instates detailed core files from NSM processors. The core file is useful for diagnosing processor failures.
Mode	cfg
Security Role(s)	crypto-officer
Syntax	nsm binary-core-files no nsm binary-core-files
Default(s)	nsm binary-core-files
Platforms	ARX-500, ARX-2000, and ARX-4000
Guidelines	Only use this command on the advice of F5 Support. An NSM processor requires very-little time to generate the smaller ASCII form of NSM-core files, but they offer less information for later diagnosis. An NSM processor requires up to three minutes to generate the detailed binary-core file, but it fails over to its peer processor at the beginning of the process. If two peer processors fail at the same time, the ARX fails over to its redundant peer before they write their core files. The extra time to write the binary-core file(s) has no effect on clients.
Important: A standalone ARX, without a redundant peer, loses service for up to three minutes if two peer processors fail at the same time. Without an ARX peer, clients must wait for the peer processors to write their binary-core files. For this reason and others, we recommend redundant ARXes at all live customer deployments.
	An ARX-500 requires nsm recovery before you can enable this feature. Use the show nsm command to see the current setting for binary-core files.
Sample	bstnA(cfg)# nsm binary-core-files sets the current chassis to produce detailed, binary-core files in the event of any NSM-processor failure.
Related Commands	nsm recovery show nsm

Purpose	Each NSM-processor core has a redundant peer that takes over in case of a failure. A recovered processor goes into a Standby state while its peer processor manages all network traffic for both. If the peer processor fails, all network traffic fails back to the peer that failed first. On the advice of F5 Support, you can use no nsm recovery to prevent NSM-processor recoveries on this ARX. The nsm recovery command re-enables this ARXs NSM processors to recover from failures.
Mode	cfg
Security Role(s)	crypto-officer
Syntax	nsm recovery no nsm recovery
Default(s)	nsm recovery
Platforms	ARX-500, ARX-2000, and ARX-4000
Guidelines	Only use this command on the advice of F5 Support. The show processors command shows all NSM processors that are in the standby state. This command cannot run on an ARX-2000 chassis. An ARX-2000 contains four cores on a single chip, so it cannot benefit from the nsm recovery command. If a core fails on the ARX-2000, it remains in the Failed state while its peer core processes all of its traffic. On an ARX-500, this must be enabled before you can enable nsm binary-core-files. The nsm binary-core files command enhances the diagnostic files produced by an NSM processor when it fails. It is enabled by default. You can use the show nsm command to see the current setting for NSM-processor recovery and/or binary-core files.
Guidelines: Enabling Warm Restarts	You also have the option to make individual cores restart independently, without necessarily putting the entire NSM processor into the Standby state. Use the nsm warm-restart command to enable these restarts.
Samples	prtlndA(cfg)# no nsm recovery stops NSM-processor recovery on the current chassis. If a processor fails, it fails over to its peer once; if the peer fails later, the ARX reboots.   bstnA(cfg)# nsm recovery sets up the NSM-processors to recover after a failure and assume a hot-standby state.
Related Commands	nsm binary-core-files nsm warm-restart show nsm

Purpose	An NSM-processor core can attempt to restart after a failure, without causing its entire NSM processor to reboot and go into a Standby state. Other cores on the same NSM processor are unaffected by this warm-restart of the failed core. Use the nsm warm-restart command to make NSM cores attempt these warm restarts. The no nsm warm-restart command returns to the default: if any core fails on an NSM processor, the entire processor reboots.
Mode	cfg
Security Role(s)	crypto-officer
Syntax	nsm warm-restart no nsm warm-restart
Default(s)	nsm warm-restart
Platforms	ARX-2000 and ARX-4000
Guidelines	This command localizes the effects of an NSM-core failure. Only the core that failed restarts, without affecting any sister cores on the same processor. A warm restart produces a core-memory file, visible with the show cores command. The core-memory files produced by this failure are smaller than those produced by a full NSM restart, but they contain enough information for F5 Engineering to analyze the failure. The size of the core-memory file is unaffected by the nsm binary-core-files command. There are two internal counters, restart count and restart limit, that prevent repetitive warm restarts. The restart limit is 3, and the restart count applies to an entire NSM processor (or CPU). If core 1 fails on a four-core CPU, and then core 3 fails on the same CPU, the NSM CPU has a restart count of 2. If the restart count reaches the restart limit (3), the entire NSM CPU reboots and behaves as dictated by the nsm recovery setting. Each restart event times out after 24 hours, decrementing the restart count by one. For example, At noon on Thursday, core 1 restarts - restart count = 1. At 5PM on Thursday, core 3 restarts - restart count = 2. At noon on Friday, core 1s restart times out - restart count = 1. At 5PM on Friday, core 3s restart times out - restart count = 0. You can use the show nsm command to see the current settings for NSM warm restarts, NSM-processor recovery, NSM binary-core files. To see the history of warm restarts on this system, use the show nsm warm-restart history command. Hardware faults are too severe to allow for a warm restart. For hardware faults, the NSM processor fully reboots and restarts as set by the nsm recovery command.
Sample	bstnA(cfg)# nsm warm-restart sets up the NSM-processor cores to independently restart on failure, without affecting any other cores on the same processor.
Related Commands	nsm recovery nsm binary-core-files show nsm show nsm warm-restart history

Purpose	At each redundant peer, use this command to identify the other switch. Use the no form of the command to remove the redundant-peer configuration.
Mode	cfg-redundancy
Security Role(s)	network-engineer or crypto-officer
Syntax	peer peer-address no peer   peer-address (0.0.0.0-255.255.255.255) is one of the peer switchs management-IP addresses. This can be the out-of-band (MGMT) interface or one of the switchs inband (VLAN) management interfaces. For the ARX-1500 and ARX-2500, you must use the inband management interface defined for the redundancy link: define a special VLAN for the link (with vlan and members (cfg-vlan) for a standalone link, or with vlan (cfg-channel) for a channel), and use the interface vlan and ip address (cfg-if-vlan) commands to create the inband-management IP.
Default(s)	Port default is 49800.
Platforms	any except ARX-VE
Guidelines	A rendezvous occurs after you issue enable (cfg-redundancy) at the second switch. Each switch uses its peer-address to contact the other switch and exchange information for the join operation. It also uses this address for regular heartbeat exchanges. Define the redundant peer before issuing enable (cfg-redundancy) on the switches. Use the show redundancy peer command to see the current configuration for the peer, as well as heartbeat counters.
Sample	bstnA(cfg-redundancy)# peer 10.1.1.12 identifies the switch at 10.1.1.12 as the current switchs redundant peer.
Related Commands	redundancy enable (cfg-redundancy) show redundancy peer

Purpose	Use this command to set up a quorum disk for a redundant pair.
Mode	cfg-redundancy
Security Role(s)	network-engineer or crypto-officer
Syntax: NFS	quorum-disk nfs-server:/export[path] {nfs2 | nfs3 | nfs3tcp}   nfs-server:/export[path] (1-1024 characters) selects an NFS export: nfs-server is the IP address for the filer (for example, 192.168.70.65). This address must be on a server (proxy-IP) subnet (see ip proxy-address) or reachable through a gateway on that subnet (via static route: see ip route to create a static route). export is the path to an NFS export on the server. path (optional) is the specific directory to use. nfs2 | nfs3 | nfs3tcp is a required choice; this is the NFS protocol to use for accessing the quorum-disk share.
Syntax: CIFS	quorum-disk \\cifs-server\share[\path] cifs [DOMAIN/]username spn spn   \\cifs-server\share[path] (1-1024 characters) is the syntax for a CIFS share. cifs-server is the IP address for the filer (for example, 192.168.23.23). This address must be reachable, as described above for an NFS filer. share is the specific share to use. path (optional) is a path within the share. cifs is a required keyword. [DOMAIN/]username (1-1024 characters) is the username that the redundancy software can use to write to the CIFS share. If you use a short DOMAIN name, like medarch, you authenticate with NTLM or NTLMv2. If you use an FQDN for the domain, like medarch.org, you use Kerberos authentication. spn spn (required for a Windows 2008 cluster, optional for other servers; 1-255 characters) is the Service-Principal Name (SPN) for the back-end server. You require a SPN to connect to a CIFS service on any Windows 2008 cluster.
Default(s)	path defaults to the top of the NFS export or CIFS share.
Platforms	any except ARX-VE
Guidelines	The quorum disk is an NFS or CIFS share on any reliable, external filer. Each peer records its heartbeat messages on the quorum disk, and reads the heartbeat messages from the other. This is another path for reading the peers heartbeats, in addition to the path through the redundant-pair link. The quorum disk also records ballot information for senior-switch election (see show redundancy ballots).
Guidelines: Filer/Share Requirements	Use a highly-available, high-performance filer for the quorum disk. Round trip data write times for 1 block of quorum-disk data must be below 1 second. Slow-performing filers may cause the redundancy state to fluctuate and could lead to unnecessary switch down time. The quorum disks volume must be capable of storing 1 MB of file data. Use a share that blocks until the data is written to disk; no caching should be enabled for the share. If the quorum disk is an NFS export, it must be configured (at the filer) for synchronous writes. Use the sync option. We also recommend that you specify the no_wdelay option. CIFS shares do not have this configuration issue; they perform synchronous writes on request.
Guidelines: Filer Connectivity	Each peer uses one of its in-band (VLAN) management addresses to communicate with the quorum disks filer. Use the interface vlan command to create an in-band management address for a particular VLAN. The switch can reach the quorum-disk filer through this interface if the filer is on the same VLAN as the management interface, or the filer is reachable through a static ip route that goes through a gateway on the same VLAN as the management interface.
Guidelines: Command Usage	If you connect to a CIFS share, the CLI prompts for a password to use for accessing the filer. It prompts a second time to confirm the password. For both prompts, enter the password for the username. Use the show redundancy quorum-disk command to view the current configuration for the quorum disk, as well as some counters.
Samples	bstnA(cfg-redundancy)# quorum-disk 172.16.4.98:/lhome/qdisk1 nfs3 configures an NFS quorum disk.   provB(cfg)# quorum-disk \\10.10.201.8\qd cifs BOSTONCIFS/juser spn svcA@BOSTONCIFS Password: jpasswd Confirm: jpasswd configures a CIFS quorum disk.
Related Commands	redundancy show redundancy quorum-disk

Purpose	Use this command to start configuring redundancy between two switches. If an ARX with a redundant peer experiences a catastrophic failure, all of its services fail over to its peer ARX.
Mode	cfg
Security Role(s)	network-engineer or crypto-officer
Syntax	redundancy
Default(s)	None.
Platforms	any except ARX-VE
Guidelines: Before You Begin	Before you configure redundancy, you must connect the two peers together with a redundancy link. You can use a single port for this, but we recommend two or more ports in a channel. The ARX-1500 and ARX-2500 use layer-3 (IP) networking software for exchanging heartbeats and important metalog data between the peers, so they require layer-3 configuration for their redundancy link. Use these commands to set up a layer-3 connection: Establish a new VLAN for this link. This requires different CLI commands for a channel than it does for a stand-alone port: For a channel, use the vlan (cfg-channel) command to assign the channel to the VLAN. For a single port, use the vlan command to create a new VLAN, then use members (cfg-vlan) to assign the single port to that VLAN. Use the interface vlan to create a management-IP interface on the VLAN; this puts you into cfg-if-vlan mode. From cfg-if-vlan mode, use the ip address (cfg-if-vlan) command to establish an in-band (VLAN) IP address. You later use this VLAN-management IP address to identify this ARX to its peer, as described below. From the same mode, use redundancy (cfg-if-vlan) to designate the interface for exchanging metalog data and heartbeats. From the same mode, use no shutdown (cfg-if-vlan) to enable the management interface. Other platforms use a layer-2 connection for their redundancy link. After cabling the peers together, you use the redundancy protocol command on the links interface to designate it for use as this link. If you use multiple links in a channel, as recommended, you use the redundancy protocol (cfg-channel) command instead.
Guidelines	The cfg redundancy command brings you to cfg-redundancy mode, where you configure the parameters for creating a redundant pair. From this mode, you use the peer command to identify the redundant peer; for the ARX-1500 and ARX-2500, you must use the other peers in-band (VLAN) IP address at the other end of the redundancy link. You also use quorum-disk to identify an external-filer share to be used as a quorum disk. Repeat these steps at the peer switch, which must have redundancy parameters that agree. Once the parameters match on both switches, you enable the redundant pair with enable (cfg-redundancy) at each peer. The enable command invokes the initial-rendezvous process, which then starts the metalog (namespace log) resilvering process. Metalog resilvering is duplicating the metalog data from the active peer to the backup peer. The metalog data must be mirrored on both peers to ensure that the namespace software can fail over. You may want to monitor the resilvering process if the peers are separated by a long distance: you can use the show redundancy metalog command for this. If resilvering times out due to excessive latency, you can use the resilver-timeout command to reset the timeout value. For rare situations where network maintenance may cause unwanted failovers, you can use the suspend-failover command to suspend failovers for a short time. Use the no form of the command to lift the suspension when the maintenance is finished.
Guidelines: ARX-1500 and ARX-2500 Redundancy	The ARX-1500 and ARX-2500 store their metalog data on their internal disks, along with logs, software-release files, and other management data. Managed volumes write their metalog data as clients change the volume state; the metalog is used to restore the volume configuration in the event of a failure. The metalog is also copied to the redundant peer. The speed of many volume operations depends on fast metalog writes. Some other system operations create a large number of writes to the internal disk, potentially slowing metalog writes. This can slow volume performance, even if it occurs on the backup peer. For example, the process of upgrading the software release is extremely disk intensive, and may cause a noticeable performance degradation. During an upgrade, you use the copy command (copy ftp, copy {nfs|cifs}, copy scp, or copy tftp) to copy a full release file to the disk, and the boot system command to unpack the release file on the disk. You should perform such disk-intensive operations during off-peak hours on the ARX-1500 and ARX-2500. This is true whether you run the operations on the active peer or the backup.
Guidelines: ARX-VE Redundancy	The ARX-VE is a Virtual Appliance (VA, similar to a VM) that runs on a standard hypervisor, and uses the same redundancy mechanisms that are used in a VM cluster. If the ARX-VEs hypervisor host fails, an identical ARX-VE on a peer hypervisor resumes processing. This does not require any additional configuration on the ARX, so the redundancy command, cfg-redundancy mode, and other ARX-redundancy operations are excluded from the ARX-VE CLI.
Sample	bstnA(cfg)# redundancy bstnA(cfg-redundancy)# ... starts redundancy configuration.
Related Commands	enable (cfg-redundancy) quorum-disk show redundancy show redundancy metalog resilver-timeout suspend-failover

Purpose	Use this command to resolve a rare scenario (described below) where one peer has failed unrecoverably and the other will not take over as the active peer.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, or crypto-officer
Syntax	redundancy force-active
Default(s)	None.
Platforms	any except ARX-VE
Guidelines	This command forcibly promotes the backup peer to active status.
Important: This command discards any forward progress made at the other peer. It also re-imports all namespaces, forcing all clients to re-mount all front-end services. Never use this command unless under the circumstances below, and with the advice of F5 personnel.
	Consider a redundant pair where Peer A is active and Peer B is either active or backup. Peer B fails, then (later) Peer A fails unrecoverably. When Peer B recovers, it refuses to take an active role because it knows that it was down while Peer A was active: Peer A may therefore have changed its configuration or managed some transactions with back-end filers. If Peer B were to take control, all such configuration changes and transactions would be lost. In this scenario, Peer B waits indefinitely for Peer A and the redundant pair never comes back online. You need to force Peer B to take an active role, thus abandoning any configuration changes or transactions that occurred on Peer A. The peer switch must be offline, and the current switch must have been up and waiting for its peer to come online for at least 5 minutes. Also, the quorum disk must be online and available. Use the show redundancy command to verify that the peer is down and the quorum disk is connected. The CLI warns you before discarding transactions and rebooting both peers. Enter yes to proceed.
Sample
bstnA(cfg)# redundancy force-active CAUTION: To avoid data corruption, the peer switch MUST BE OFFLINE and remain offline while this command executes. Any global configuration changes made on the Active peer switch while this switch was unavailable will be lost. All namespaces will be re-imported automatically to ensure consistency in the metadata. All in-flight transactions not synchronized will be lost. NFS-based clients will need to remount. Please contact Technical support for further advice.   Proceed? [yes/no] yes bstnA(cfg)# ...
	forces the bstnA switch to take active status in its redundant pair.
Related Commands	show redundancy

Purpose	The redundant peers exchange their metalog (namespace-transaction) data during initial rendezvous, or after a failover. This is called resilvering the metalog data. At some sites, the latency between peers is high enough that the resilvering process times out before the pair can form. On the advice of F5 Support, you can use this command to increase the time allowed for resilvering. Use the no form of the command to reset the resilvering timeout to its default.
Mode	cfg-redundancy
Security Role(s)	network-engineer or crypto-officer
Syntax	resilver-timeout minutes no resilver-timeout   minutes (6-60) is the maximum number of minutes for resilvering. If this time expires before resilvering is complete, the redundant pair cannot form.
Default(s)	6 minutes
Platforms	any except ARX-VE
Guidelines	A rendezvous occurs after you issue enable (cfg-redundancy) at the second switch. A failover occurs whenever the active switch fails and the backup switch takes control. You can use this command to increase the time allotted for resilvering metalog data during a rendezvous or a failover. The default is sufficient for most sites. Use this command only on the advice of F5 Support. It is unnecessary if you use a direct layer-2 connection for the redundancy link. The packet latency on a direct connection is typically very short. If resilvering times out, the redundancy software retries until it succeeds. This severely impacts system performance. You can use the show redundancy history command to see the results of resilvering (referenced as synchronization in that output), and determine whether or not it is repetitively timing out. You can use show redundancy metalog to monitor the resilvering process as it occurs. Use the show redundancy resilver-timeout command to see current timeout value for resilvering.
Sample	provA(cfg-redundancy)# resilver-timeout 10 sets the resilvering timeout to 10 minutes on the provA switch. The resilvering process has 10 minutes to complete after rendezvous or failover.
Related Commands	redundancy show redundancy resilver-timeout show redundancy metalog

Purpose	The show nsm command shows the current state of the NSM-maintenance features: processor recovery and binary-core files. For each of these features, this command shows the administrative setting as well as whether or not the setting is operational.
Mode	(any)
Security Role(s)	crypto-officer
Syntax	show nsm [recovery | binary-core-files | warm-restart]   recovery | binary-core-files | warm-restart (optional) focuses the output on the state of a single NSM-maintenance feature. If you omit these, the output shows the state of all NSM features.
Platforms	ARX-500, ARX-2000, and ARX-4000
Guidelines	The output contains a separate table for each NSM-maintenance feature, Recovery, Binary Core Files, and Warm-Restart. Each table has one row per NSM, where each row has the following fields: Proc identifies an NSM processor, in slot.processor format. Status - Admin is the status that was last set for this feature. Status - Operational is the features actual status. You can use [no] nsm recovery to disable or re-enable NSM-processor recovery. You can also use [no] nsm binary-core-files to change NSM-processor core files to an ASCII format or a larger binary format. NSM recovery must be enabled before you can enable NSM binary-core files. Only change these settings on the advice of F5 Support. The final table concerns the [no] nsm warm-restart command; this allows a processor core to fail and recover independently, without rebooting the entire processor.
Sample	bstnA# show nsm binary-core-files     Binary Core Files: Status Proc Admin Operational ------ ---------- ------------ 2.1 Enabled Enabled 2.2 Enabled Enabled 2.3 Enabled Enabled 2.4 Enabled Enabled 2.5 Enabled Enabled 2.6 Enabled Enabled 2.7 Enabled Enabled 2.8 Enabled Enabled 2.9 Enabled Enabled 2.10 Enabled Enabled 2.11 Enabled Enabled 2.12 Enabled Enabled   shows that the current chassis is configured to produce detailed, binary core files in the event of an NSM-processor failure.
Related Commands	nsm recovery nsm binary-core-files nsm warm-restart

Purpose	To show the history of warm restarts by the NSM-processor cores, use the show nsm warm-restart history command.
Mode	(any)
Security Role(s)	crypto-officer
Syntax	show nsm warm-restart history [processor slot.processor]   processor slot.processor (optional) specifies one NSM processor for which to view this history. If you omit this option, the output includes warm-restart history for all NSM processors. slot (2 for ARX-4000; 1 for any other) is the slot number. processor is the processor number. Use the show processors command to show all processors and their associated slot.processor IDs.
Platforms	ARX-500, ARX-2000, and ARX-4000
Guidelines	An NSM warm restart occurs when an NSM-processor core encounters a catastrophic software failure and reboots, without causing any other cores to reboot with it. A warm restart is only possible on a system where nsm warm-restart is enabled. The output contains two tables, one that shows the most-recent recent warm restart and another that shows the current values for restart count and restart limit. The restart count is the sum of all restarts for a given CPUs cores, and the restart limit is the maximum number of restarts for each CPU. If a core fails after its CPUs restart count reaches the restart limit, the entire CPU reboots. The full-CPU reboot follows the rules set by the nsm recovery command. The first table has one row per NSM processor, with the following fields: Proc identifies the NSM processor, in slot.processor format. This identifies a specific core on the CPU. CPU identifies the NSM-processor CPU, where each CPU typically contains multiple cores. This field identifies the CPUs with a letter, such as A, B, or C. Restart Number is the most-recent restart number for this core. The full restart count for the CPU is the sum of all its cores Restart Numbers. As mentioned above, you use the nsm warm-restart command to make warm restarts possible for NSM cores. Date/Time (UTC) is time stamp (if any) for the most-recent warm restart. The second table shows the number of restarts remaining for each hardware CPU from the first table: Slot is the slot number for the NSM processor. CPU identifies the NSM-processor CPU, where each CPU typically contains multiple cores. This maps to the CPU field in the table above. Restart Remaining is the number of warm restarts remaining for this NSM CPU. This count decreases by one every time one of the CPUs cores has a warm restart. It increases by one every time a warm restart ages by 24 hours. Restart Limit is the total number of restarts allowed for each CPU.
Samples	bstnA# show nsm warm-restart history shows the warm-restart history for all NSM processors in the bstnA chassis. See Figure 15.1 for sample output., without any warm restarts.   prtlndA# show nsm warm-restart history shows the warm-restart history for all NSM processors in the prtlndA chassis. See 15.2 for sample output., where two warm restarts occurred in the last 24 hours.
Related Commands	nsm recovery nsm binary-core-files nsm warm-restart

Purpose	Use this command to show high-level status for the redundant pair.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Node is 1 for the initial-senior switch, 2 for the initial-junior switch, or QD for the quorum disk. The asterisk (*) indicates the local node. Switch/Quorum Disk identifies each node with a hostname or IP address. Status is Up, Up,NoFovr, Down, Suspended, or Unknown for a redundant peer. The UpNoFovr status indicates that someone used suspend-failover to temporarily freeze the Active/Backup status of the peers and suspend failovers. The status is Up, Up,NoHb, Pending, or Down for the quorum disk. Up,NoHb means that the quorum disk is up but not showing any heartbeats from the peer yet. Role is Active, Backup, or Quorum. The senior peer is always Active, meaning it can run namespace software and virtual servers. The junior peer is Backup; it is a hot standby for the active peer. Transitions: Total is the number of times that the Status has changed. This increments for each failover. If there has never been a failover, the Total is Never. Transitions: Last (UTC) is the timestamp for the last status change, in Universal Coordinated Time (UTC).
Sample	See the sample output in Figure 15.3.
Related Commands	redundancy

Purpose	Use this command to show all redundant-pair information with a single command.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy all
Default(s)	None
Platforms	any except ARX-VE
Guidelines	This command shows all flavors of show redundancy ... output, in the following order: 1. show redundancy 2. show redundancy history 3. show redundancy peer 4. show redundancy ballots 5. show redundancy network 6. show redundancy critical-services 7. show redundancy resilver-timeout 8. show redundancy quorum-disk For details about the show redundancy all output, refer to the command descriptions for these individual commands.
Sample	See the sample output in Figure 15.4.
Related Commands	redundancy

Purpose	Each failover is followed by an election process to choose the senior switch. Use this command to show the ballots from the most-recent redundancy election.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy ballots
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Node is 1 for the initial-senior switch, 2 for the initial-junior switch, or QD for the quorum disk. The asterisk (*) indicates the local node. Switch/Quorum Disk identifies each peer with a hostname or IP address. Ballot Cast shows the most-recent seniority vote from each node: Senior Switch is the switch that the node believes should be senior, and Epoch is the epoch number that the node last recorded. All three quorum members keep a common epoch number that increments with each failover. If one node has a lower epoch number than the others, its vote for Senior Switch is discounted.
Guidelines: Redundancy Elections	Each switch, as well as the quorum disk, stores an epoch number and the identity of the senior switch. After a switch failure, this information is exchanged as election ballots to determine which peer should have seniority. Ballots with higher epoch numbers carry more weight in the election. If two nodes agree but disagree with the third, the majority rules. The results determine which peer is senior. None of the ballots are authoritative; use the show redundancy command to see which peer(s) is/are currently active. (The senior switch is always active, the junior switch is active after the initial rendezvous but backup after a failover.) For example, the following table shows that the Quorum Disk and the second peer, prtlndB, agree on the Epoch number (9) and the senior peer (node 2, which is prtlndB). The prtlndA peer cast the dissenting vote (1, or itself, as senior) with a lower Epoch number (8). From this output, we can infer that prtlndA was senior before it failed, then became junior when it rejoined the pair.
... Ballot Cast Node Switch/Quorum Disk Senior Switch Epoch ---- -------------------- -------------------- ----- *1 prtlndA 1 8 2 prtlndB 2 9 QD 192.168.74.83 2 9 ...
	Ballots are only cast when a node fails, so all ballots are 0 (zero) when the pair first forms. In this case, both nodes are always active and Node 1 is always senior.
Sample	See the sample output in Figure 15.5.
Related Commands	redundancy show redundancy

Purpose	If the current switch loses contact with a critical service (such as a critical namespace share or a critical subnet), a failover may occur. Use this command to show all of the critical services configured for the current peer.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy critical-services
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Each critical service has one row in the table: Type is quorum share, route, or meta-only. The quorum disk is a critical resource by default, and you cannot remove it from this list. To declare a namespace share as critical, use critical in gbl-ns-vol-shr mode. To create a critical route, use critical route in cfg-redundancy mode. A meta-only resource is a dedicated metadata share that is critical: use metadata share to configure a dedicated metadata share, and use metadata critical to make it a critical resource. Service specifies the exact route or share. For a quorum disk, this shows the machine and path to the share. For shares, this shows the share in namespace~volume~share-name format. For a critical route, this shows the critical subnet in ip-address/subnet-length (CIDR) format. Status is Up, Down, or Config. A Config status indicates that the critical service is configured but the Up or Down status has not been determined yet. Transitions: Count is the number of times that the Status has changed. Transitions: Last (UTC) is the timestamp for the last status change, in Universal Coordinated Time (UTC). If there has never been a failover, this shows Never.
	Counters Last Cleared is the timestamp for the last time someone ran clear counters redundancy [critical-services].
Guidelines: Failover Algorithm	Only an active switch can initiate a critical-services failover. By default, both switches are active. After a failover, only the senior switch is active. If an active switch loses a critical share or route, it requests a failover. If the peer has all critical routes, shares, and access to the quorum disk, the failover occurs. Conversely, the peer rejects the failover if it has lost any of its own critical resources: a failover in this case could cause more service outages than it resolves. Note the difference in the way that the quorum disk is treated. Peer A does not initiate a failover if it loses access to the quorum disk. If peer A loses some other critical service (such as a critical share), it does initiate a failover. In this case, peer B rejects the failover if peer B cannot access the quorum disk. Loss of the quorum disk can prevent a failover, but never causes a failover.
Sample	See the sample output in Figure 15.6.
Related Commands	critical critical route metadata critical clear counters redundancy

Purpose	Use this command to show some high-level redundancy logs kept at the local switch.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy history
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Recent History messages include: Remote peer has gone offline Pair status changed from Inactive to Rendezvous, Rendezvous to Joining, or Joining to Formed. Incumbent switch wins seniority election (sr=1, epoch=4) Site quorum manager daemon started Errors with forming the pair appear here when they occur. Many of them are self-explanatory, but some of them (such as DbSync errors) may require intervention from F5 Support.
Sample	See the sample output in Figure 15.7.
Related Commands	redundancy

Purpose	Both peers in a redundant pair require the same license, to prevent any loss of service after a failover. A failover to a peer with a lesser license would result in fewer supported features and fewer available system resources. To confirm that the licenses are the same between the current peers, use the show redundancy license command.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy license
Default(s)	None
Platforms	any except ARX-VE
Guidelines	The output contains a success message if the licenses are the same for both peers. Otherwise, it returns a failure message along with all mis-matched features. In the case of a failure, you need to determine which peer has the desired license, and then activate or re-activate the license at the other peer. Run show active-license at each peer to see details about the licenses there. If the peer can connect to the Internet, you can use the license activate command to automatically activate the license there. Otherwise, you can use a manual activation method, as described in the documentation for the license create license-dossier command.
Sample	prtlndA> show redundancy license % INFO: The HA peer license is equivalent to the license on this ARX.   shows that the licenses match between the peers.
Related Commands	show active-license license activate license create license-dossier redundancy show redundancy

Purpose	Metalog (namespace transaction) data is mirrored between redundant peers during their initial rendezvous, and it is duplicated between the peers during normal operation. The duplication process is called resilvering. You can use the show redundancy metalog command to see the current state of the metalog-resilvering process between peers. This command is especially useful for monitoring the connection between redundant peers that are separated by long distances.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy metalog
Default(s)	None
Platforms	any except ARX-VE
Guidelines	The active peers metalog data must be mirrored at the backup peer so that namespace software can recover after a failover. Use this command to monitor the resilvering process. This command only functions on the active peer. Use this output to gauge the latency and performance of the redundant-pair link. An overly-long latency between peers can cause a large number of metalog-packet retransmits (see below), and may lead to slow responses that are noticeable to namespace/volume/front-end service clients. On all platforms, the namespace software keeps metalog read/write statistics. You can use the show statistics metalog command to see these metalog-usage statistics from a namespace-software perspective. The ARX-1500 and ARX-2500 store their metalog data on their internal disks. On those platforms, you can use the show metalog usage command to see the metalog-usage statistics. The ARX-VE stores its metalog data on an external data store. On the ARX-VE, you can use the probe metalog latency command to test the latency between the ARX and this external storage.
Guidelines: Output	The output shows the current state of the resilvering process: State is Resilvering - the active peer is copying all of its metalog data to the backup peer during a rendezvous. Peer Online - the metalog data was 100% duplicated after rendezvous, and now the active peer is sending metalog updates as they occur. Peer Offline The next three fields only appear for the Resilvering state, which occurs during rendezvous: Started is the start time for the rendezvous process. Timeout indicates the total time allowed for resilvering. The resilvering process times out, sends an SNMP trap, and restarts if it exceeds this time limit. You can use the resilver-timeout command to reset this time limit. Time Remaining is the estimated time left for resilvering. This estimate is based on the current data-transfer rate and the amount of data left to transfer. Byte Count is the number of bytes of metalog data transferred to the backup peer. If the initial Resilvering process is still underway, this also shows the total size of the metalog data to be copied to the backup peer. Retransmits counts the retransmissions of individual metalog packets. A retransmit occurs if an internal timeout passes before the packet is acknowledged by the backup peer. This field counts the total retransmits that occurred since the most recent start of the resilvering operation. A long latency between peers may increase the number of retransmits. This always displays 0 (zero) for the ARX-1500 or ARX-2500 when they are resilvering. These platforms use a different transmission mechanism for their metalog packet. Latency shows the minimum, maximum, and average latency for sending packets of metalog data to the backup peer. These are measured in micro-seconds (us). Data Rate shows the average megabits per second for the transfer of metalog data. This field only appears while resilvering is occurring.
Samples	nyc15> show redundancy metalog State: Resilvering   Started: 01/31/2012 22:48:03 +0000 Timeout: 00:06:00 sec Time Remaining: 00:00:58 sec   Byte Count: 992 M of 3.7 G (26%)   Retransmits: 0   Latency: Min: 18538 usec Max: 77860 usec Avg: 22715 usec     Data Rate: 47.2 Mb/s   shows the state of metalog resilvering on the nyc15 chassis.
	prtlndA> show redundancy metalog State: Peer Online   Byte Count: 55 M Retransmits: 0   Latency: Min: 80 usec Max: 127 usec Avg: 83 usec     shows the state of metalog resilvering on the prtlndA chassis. In this case, the initial resilvering is complete and the active peer is sending metalog updates as it generates them.
Related Commands	resilver-timeout redundancy show redundancy show metalog usage show statistics metalog probe metalog latency

Purpose	Use this command to show the configuration and counters associated with the current switchs redundant peer.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy peer
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Peer is the heading for peer-identification parameters: Name is set by the hostname command at the peers CLI. IP Address is the peers management IP that is chosen for the rendezvous. You can change this with the peer command. Port is the peer port used for rendezvous. You can use an option in the peer command to change the port number. Status is Active, Backup, Down, or Unknown.. Heartbeats are counters for the number of redundancy heartbeats sent and received. You can use the clear counters redundancy command to clear this counter. Transitions are the number of changes in redundancy Status for this peer. You can use the clear counters redundancy command to clear this counter, too.
Sample	See the sample output in Figure 15.8.
Related Commands	redundancy peer clear counters redundancy

Purpose	A quorum disk is a filer share that each switch uses to write its own heartbeats and read the heartbeats from its peer. Use this command to show the configuration and counters associated with the quorum disk.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy quorum-disk
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Path is in machine:/path format (for an NFS export) or \\machine\path format (for a CIFS share). This is the external-filer share used as the quorum disk. From cfg-redundancy mode, use quorum-disk to reset this. Protocol is the file-access protocol (nfs2, nfs3, nfs3tcp, or cifs) used to access the quorum-disk share. This flag is also set with the quorum-disk command. If the protocol is cifs, the following fields appear to describe the CIFS options used to access the quorum disk. These are all options from the quorum-disk command: QD User is the Windows username that the ARX uses as its identity when accessing the quorum disk. User Domain is the Windows domain for the above username. QD SPN is the Service Principle Name (SPN) for the quorum disks host server. Status is Up, Pending, or Down. Pending indicates that the quorum disk is functional but the redundant pair is in the process of forming. Heartbeats are counters for the number of redundancy heartbeats sent to the quorum disk by the current node, and received from the quorum disk by the current node. You can use the clear counters redundancy command to clear this counter. Transitions shows the changes in Status for the quorum disk: Count is the number of changes. This should be a low number; the only valid reason for a quorum-disk transition is a planned outage of the quorum-disk filer (such as a hardware upgrade). Last is the time stamp for the most-recent transition. Reason is the log message associated with the Status change. You can use the clear counters redundancy command to clear the transitions counter, too.
Guidelines (Cont.)	Heartbeat Latency is a chart of latency measures over the past 24 hours. This is the latency (round-trip time) for heartbeat packets between the current peer and the quorum disk. Each row shows the latency measures in one hour: Time Interval shows the start and end time for the hour, in local time. [0-499] is a count of heartbeats with a latency of 0-499 milliseconds. This column should have by far the highest count of all of them. [500-999] is the number of heartbeats that took 500-999 milliseconds to make a round trip. This is a long latency and should be uncommon. [1-3999] shows how many heartbeats took 1 second to 3,999 milliseconds (almost 4 seconds). This latency should be extremely rare, if it ever occurs. [No Response] is the number of heartbeats that were lost. This number should be 0, unless there is a planned outage for the quorum disk. If either peer reboots while one of them is disconnected from the quorum disk, they both may reboot simultaneously. Heartbeat Latency Summary shows the percentage of heartbeats in each of the above time intervals. If the Heartbeat Latency and Heartbeat Latency Summary tables indicate long latencies, choose a faster quorum disk. You can run the quorum-disk command on both peers to change the quorum disk.
Sample	See the sample output in Figure 15.9.
Related Commands	redundancy quorum-disk clear counters redundancy

Purpose	Use this command to show the history for all redundancy-related reboots.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy reboot-history
Default(s)	None
Platforms	any except ARX-VE
Guidelines	Version is the software version running at the time the reboot was issued. Time of reboot is a timestamp from the beginning of the reboot. Message is the message that appeared on the Console to announce the reboot.
Sample	See the sample output in Figure 15.10.
Related Commands	redundancy

Purpose	Initial rendezvous and standard managed-volume processing involves duplicating the metalog (namespace transaction) data from the active peer to the backup. This process is called resilvering. Use this command to show the maximum time allowed for resilvering. If this time expires before resilvering is complete, the redundant pair cannot form.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show redundancy resilver-timeout
Default(s)	None
Platforms	any except ARX-VE
Guidelines	The output is a single value, the timeout allowed for resilvering. You can use the resilver-timeout command to reset this. The show redundancy metalog command shows the current state of the resilvering process.
Sample	prtlndA# show redundancy resilver-timeout   Resilver Timeout: 6 minutes
Related Commands	resilver-timeout redundancy show redundancy show redundancy metalog

Purpose	There are occasions when site maintenance may inadvertently cause redundancy-inspired failovers and reboots. These can complicate the maintenance procedure. You can use the suspend-failover command to prevent any failovers until further notice. You can later lift the suspension with no suspend-failover.
Mode	cfg-redundancy
Security Role(s)	network-engineer or crypto-officer
Syntax	suspend-failover no suspend-failover [force]   force (optional) is only necessary when the peer switch is disabled or otherwise unreachable. This causes the current switch to assume the active role in the pair, whether or not it previously had the active role. This is similar to the behavior from the redundancy force-active command.
Important: If you use the force option on the backup peer when the other peer is still active and connected, this command creates a split-brain condition.
Default(s)	no suspend-failover
Platforms	any except ARX-VE
Guidelines	Use this command only under the guidance of F5 personnel. This command locks the redundancy state until the suspension is lifted. The peers retain their active and backup roles during the suspension. The CLI prompts for confirmation before doing this; enter yes to proceed. You can only use this command when redundancy is enabled, the peer is reachable and ready to take control, the quorum disk is functioning normally, and all critical services are healthy on the active peer. Use the show redundancy command to verify that the peer and quorum disk are functioning, and use show redundancy critical-services to check on critical services.
	During a period of failover suspension, both peers continue to record conditions that would typically cause failovers and/or failover-related reboots. These appear in the syslog (use show logs syslog to view the syslog), and some result in SNMP traps (see the ARX SNMP Reference for a full list of traps). Traps and logs also appear for any suppressed failovers or reboots.
Guidelines: Force Option	As stated above, you should only use the force option if the peer is disabled or otherwise unreachable. If the peer is reachable and active, the force option may cause both peers to take the active role and work at cross purposes. This is called a split-brain situation, and it can create serious issues that are very difficult to repair. The CLI prompts for special confirmation before lifting suspension in this way. A switch that is properly forced can successfully re-join its peer later, but there is another possibility of split brain during that rendezvous. The rendezvous happens automatically when you first boot the repaired peer. A split-brain may occur if the running switch has any connectivity issues during the rendezvous. Verify that the running switch has full network connectivity and all of its critical resources, especially the quorum-disk link, before booting its repaired peer.
Samples	prtlndA(cfg-redundancy)# suspend-failover   Are you sure you want to suspend redundancy? [yes/no] yes suspends failovers and failover-related reboots on prtlndA and its redundant peer.   bstnA(cfg-redundancy)# no suspend-failover lifts the failover suspension from bstnA and its redundant peer.   bstnA(cfg-redundancy)# no suspend-failover force   The force option should only be used when the peer switch is disabled. The peer should be off or isolated from the network. Otherwise, services could be severely disrupted.   Are you sure you want to proceed? [yes/no] yes forces a resumption of standard-redundancy. This should only be used if the redundant peer is offline.
Related Commands	show redundancy show redundancy critical-services