Log Component	Description
AFFINITY	Affimgrd and libaffin, which manage the assignment of internal processes to CPU cores.
AFN_NET	IPC Abstraction Layer, for communication between internal ARX processes.
API	API Services.
APP_RON_RTMD	RON Route Table Maintenance Daemon.
AT	AT Library. This is deprecated, so it is unlikely to yield any log messages.
AUTH_CONSOLE	Console Authentication. This component performs authentication for administrators who log into the Console (serial) port.
AUTH_HTTP	HTTP Authentication. This component performs authentication for administrators who access the GUI through HTTP.
AUTH_HTTPS	HTTPS Authentication. This component performs authentication for administrators who access the GUI through HTTP over SSL, or HTTPS.
AUTH_SSH	SSH Authentication. This component performs authentication for administrators who access the CLI through Secure SHell (SSH).
AUTH_TELNET	Telnet Authentication. This component performs authentication for administrators who access the CLI through Telnet.
AUTO_DIAG_CLI	Auto Diagnostics, which gathers input/output statistics and monitors for service degradation.
BESPD	Back-end Share Probing daemon, which periodically probes the shares behind ARX volumes and checks their health.
BOOTPD	BOOTP Daemon, or the boot-protocol server, which manages ARX boots and reboots.
CATALOG_INTERNAL	Message Catalog Internal Errors.
CHASS	Chassis Manager, which implements chassis operations such as 'reload,' 'firmware upgrade,' and hardware monitoring.
CHASS_LIB	Chassis Manager Library. The chassis manager implements chassis operations such as 'reload,' 'firmware upgrade,' and hardware monitoring.
CIFS_CLI	CIFS CLI.
CIFS_SHIM_LIB	Interface to metadata storage on CIFS filers. Metadata is data about managed-volume files, such as their locations on back-end filers.
CIFSCONFD	CIFS Configuration Daemon, which manages one front-end CIFS service.
CLI	Command Line Interface.
CLI_NFS_COPY	Copy to/from NFS namespace.
CLI_RUN_EXIM	Run exim4 from the CLI..
CLI_WIZARD	Initial Interview, which prompts with questions and performs initial configuration the first time the ARX boots.
CLUSTER	Not supported.
COMMON_DNAS	Common DNAS Messages.
COMMON_NIS	Common Network Information System (NIS) messages. NIS servers provide a lookup service for NFS servers, to manage large NFS access lists.
COMMONLIB	Not supported.
CORE	Core collector.
CRMD	Critical Resource Monitor Daemon, which makes HA failover decisions based on external filers, routers, etc.
DDBD	Distributed Database Library. This is for the internal database, which stores the ARX configuration. You can see the full configuration with 'show running-config' and 'show global-config'.
DEBUG	Internal debugging - used for development only.
DFPD	DNAS Fast Path Manager Daemon, which configures managed volumes in the NSM data plane.
DME	Policy Data Mover Engine (DME). This implements file migrations from one back-end filer to another.
DMOUNTD	Distributed Mount Daemon for NFS mounts.
DMSG_LIB	DNAS Message Library.
DNAS_IMPORT	DNAS Import Messages. An import occurs when a filer share is enabled in an enabled managed volume. This is the process of walking the directory tree of the share and recording all of its files and directories in managed-volume metadata.
DNAS_MD_MIGRATE	DNAS Metadata Migration, which moves managed-volume metadata from one external filer to another.
DNAS_PGRP	DNAS Process Group and NFS. DNAS, or Distributed NAS, is the internal name for namespace software.
DNAS_POLICY	Inline policy events that occur during normal volume processing, such as file creates, directory renames, and other client actions. This is off by default because it generates a great deal of log messages, enough to potentially affect client traffic.
DNAS_SINIT	DNAS Storage Initialization.
DNAS_SREMOVE	DNAS Storage Removal.
DNC_LIB	DNAS Configuration Library for NFS. DNAS is the internal name for namespace software.
DOMAIN_JOIN	Active Directory domain joining components, which join an ARX-CIFS service to a Windows domain.
DR	Disaster Recovery, which involves loading a configuration on a backup-ARX site and activating the configuration on command.
DT	Direct Transport processes. This is a high-speed inter-process communication (IPC) library.
EMAILHOME	Email home daemon and CLI commands.
ENVLIB	Environmental Library, for monitoring the hardware platform. This only applies to the ARX-500.
EVAL_NET_RESULT	The results of joining an Active Directory (AD) domain.
EXIMD	Exim Daemon, which sends RPC requests to the exim message-transfer agent. That agent sends SMTP (email) messages from the ARX to external devices.
FCN	File Change Notification, for API access to snapshotted configuration and metadata.
FCND	File Change Notification daemon which provides API access to snapshotted configuration and metadata.
FFP	Fast Filter Processor.
FFP_UTIL	Fast Filter Processor Library.
FFPD	Fast Filter Processor Daemon.
FILER_MGMT_LIB	Snapshot daemon filer operations library.
FREESPACEMONITOR	Free Space Monitor.
FT_CIFS_SHIM_LIB	Interface to metadata storage on CIFS filers. Metadata is information about files and directories in managed volumes, such as their locations on back-end filers.
FT_CLI	File Tracking CLI. These are the CLI operations for setting up a file-history archive and using it to track the location of managed-volume files over time.
FTD	File Tracking daemon. This is the process of sending volume metadata and configuration to an external file-history archive, and using that archive to track the location of managed-volume files over time.
GBL_LIB	Global Services Library, for NFS and CIFS service management operations.
GBL_SVCMGR	Global Service Manager, which starts and stops NFS and CIFS front-end services.
GBLSVC_CLI	Global Service CLI.
GUI	Graphical User Interface (GUI), also known as the ARX Manager.
HA_CLI	High Availability CLI, such as the 'redundancy' command.
HWAGENT	Hardware Agent, for startup, shutdown, and monitoring of hardware components.
IPC_EVENT_LIB	IPC Event Library, for communication between internal ARX processes. This is deprecated, so it is unlikely to yield any log messages.
IPC_EVENT_MGR	IPC Event Manager, for communication between internal ARX processes.
IPC_LIB	Internal software inter-process messaging library.
IPCMOND	IPC service monitoring daemon, for monitoring the communication between internal ARX processes.
IPMIUTIL	ipmiutil event collector. All log levels for this logging component go to the kernel.log file, not syslog.
KRBCONFD	Active Directory (AD) Configuration Daemon, for periodically monitoring DCs and selecting the active DCs for each Windows domain.
KRBDDNS	Dynamic DNS registration helper. This registers dynamic-DNS aliases for an ARX-CIFS service with a remote DNS server.
L2SW_DRV	Layer2 - Internal Switch Hardware. This only applies to ARX-500, ARX-2000, and ARX-4000 systems.
L2SW_LVL7	Layer2 - Internal Switch Software. This controls packet traffic over network interfaces, channel traffic and LACP, spanning-tree, and other low-level networking. This only applies to ARX-500, ARX-2000, and ARX-4000 systems.
LIBCIFS	CIFS client library, used for non-client access to CIFS file servers. For example, this library is used for policy-invoked migrations.
LIBCIFSAUTH	CIFS authentication library, for authenticating front-end CIFS clients and internal ARX processes that access back-end filers.
LIBCIFSEXT	CIFS utility library, used in conjunction with LIBCIFS.
LIBEXIM	Exim Utilities messages.
LIBKDCLBSTATS	Kerberos load-balancing statistics.
LIBSDDL	CIFS Security Descriptor Definition Language translation library, which transforms binary Security IDs (SIDs) and descriptors into text strings. Callers to this library include the SID_CACHE, POLICY_SHADOW, and SUBSHRMGT processes.
LIBXSD	CIFS security-descriptor translation library, which processes can use to access the SID_CACHE daemon. The SID_CACHE daemon translates between Security IDs (SIDs) on various file servers and the group/user names in a Windows domain.
LICENSE	License monitoring daemon and CLI.
LIP_LIB	Logical IP Address Library. A logical IP address is an internal address that processes use to communicate to one another.
LOCBROKERD	IPC Location Broker for internal (process-to-process) RPC requests.
LOGMGRD	Logging Manager Daemon.
MANUF	Manufacturing Purposes only - Internal Switch Software.
MERGED	Layer2 - Merge FPGA Daemon.
MGMT_CLI	Management SLM - not supported.
MGT_DNAS_CONFIG	DNAS Configuration. DNAS, or Distributed NAS, is the internal name for namespace software.
MGT_RON_RTMD	Route Table Control Daemon. This checks gateway health and loads the best available routes into the OS route tables.
MGT_SVC_AGENT	Service Agent, which acts as a local agent for the central Service Manager (MGT_SVCMGR) process.
MGT_SVCMGR	Service Manager, used to start (and possibly restart) ARX processes.
MLBD	Metalog Block Device (MLBD) Controller, which manages the internal metalog subsystem. The metalog subsystem stores database-transaction logs for managed volumes.
MS_CLIENT	Microsoft RPC Services - High-level library used to interact with CIFS filers.
MS_RPC	Microsoft RPC Library - Low-level library used to interact with CIFS filers.
MTLDAEMON	Metalog Daemon. This is the process that records metalog (namespace-recovery log) data, on the local NVRAM hardware. This only runs on the ARX-500, ARX-2000, and ARX-4000.
NET	Network, or data-plane, processes.
NET_APP	Miscellaneous Application Events in the network software.
NET_CIFS	NSM CIFS Proxy.
NET_ERR_TRAP	Fastpath resource errors.
NET_HA	NSM HA.
NET_IPC_PROXY	NSM IPC Proxy, for communication between internal ARX processes on the control plane and on the data plane.
NET_LOG_PROXY	NSM Log Proxy.
NET_MSG	NSM Messaging between network processes.
NET_NFS	NSM NFS Proxy.
NET_OS	NSM Embedded Operating System.
NET_SLB	Server Load Balancing in the network software - not supported.
NET_STATS	NSM Statistics Collection.
NET_TCPSP	TCP Splicing.
NETBIOS	Netbios name service, which supports WINS.
NETSNMP	SNMP management on ARX-1500 and ARX-2500.
NFSCONFD	NFS Configuration Daemon, which manages one front-end NFS service.
NISD	NIS daemon messages. NIS servers provide a lookup service for NFS servers, to manage large NFS access lists. The NIS daemon queries all the configured NIS servers and caches the results of those lookups.
NLA	NETLOGON Agent, supports NTLM authentication of CIFS clients, but only for ARX CIFS services configured for constrained delegation.
NLM	NFS Network Lock Manager (NLM) Daemon. This implements the NFS NLM protocol, which manages file locks for NFS clients.
NMPIPE	Named Pipe, for communication between internal ARX processes (MS-RPC operations on CIFS IPC$ named pipes).
NSCK	DNAS Namespace Check (NSCK), for examining and repairing managed-volume metadata. Metadata is managed-volume information about its files and directories, such as locations on back-end filers.
NSCKRPT	NSCK Report Messages.
NSM	NSM Shared Memory.
NSM_RON	NSM RON.
NTLMAGENTAPI	NTLM/NTLMv2 authentication library using ARX Secure Agent.
NTP	Network Time Protocol (NTP) subsystem to keep the ARX clock(s) synchronized with an external clock on the IP network.
NVRDAEMON	Non Volatile RAM (NVRAM) Daemon, which manages one or more mtlDaemons (see MTLDAEMON). An mtlDaemon records metalog (namespace-recovery log) data, on the local NVRAM hardware. This only runs on the ARX-500, ARX-2000, and ARX-4000.
OBJ_MGR	Object Manager Database.
OBJ_MGR_LIB	Object Manager Library.
OM	Object Manager (Distributed Database) process. This is for the internal database, which stores the ARX configuration. You can see the full configuration with 'show running-config' and 'show global-config'.
OMIO	Object Manager Record I/O Tracing. This tracing is for the internal database, which stores the ARX configuration. (You can see the full ARX configuration with 'show running-config' and 'show global-config.').
OMTT	Object Manager Transaction Tracing. This tracing is for the internal database, which stores the ARX configuration. (You can see the full ARX configuration with 'show running-config' and 'show global-config.').
PERSONALITY	Personality, which parses XML data transferred between internal processes.
POLICY	not supported.
POLICY_ACTION	Migration requests and responses. You can use this to diagnose migration issues, such as file matching and mismatching.
POLICY_CLI	not supported.
POLICY_PDP	Policy Decision Point - policy scheduler, which uses schedule configuration to trigger scans and other policy events.
POLICY_PEP	Policy Enforcement Point - policy scanning, events, rule-state processing, and rule info.
POLICY_SHADOW	Policy Shadow Volume, a read-only volume that contains replicas of all the files and directories on another volume.
PROBE	Probes for Monitoring and Controlling Subsystems.
PTW	Parallel Treewalk Library.
RELMGR	Release Manager, which stores software-release (.rel) files, unpacks them, prepares them for use on the ARX, and otherwise manages them.
RELMGR_CLI	Release Manager CLI commands. This is deprecated, so it is unlikely to yield any log messages.
REMOTE_CLI	Remote SSH CLI command execution, invoked through the CLI (with the 'rconsole' command) or the GUI.
REPLMGR	Replication Manager - Directs Data-Mover Engine (DME) file-migrations.
REPORT	Common subsystem for generating and viewing reports.
RESTARTDETECT	This determines if internal processes can be restarted after a failure.
RON	Resilient Overlay Network (RON) CLI operations.
RON_SPFD	Resilient Overlay Network (RON) Routing Daemon. This manages RON tunnels and determines the best route to remote ARX devices.
RON_VPND	Not supported.
ROOTD	Root Daemon, which performs internal Unix management that requires root-level privileges.
SCM_DSMD	DNAS Switch Monitor.
SEC_CONFIG	Security Configuration.
SEC_LOCAL	Security Local Enforcement.
SECURITY_CLI	Security CLI.
SECURITYD	Security Daemon.
SHMEM	Common, shared, memory-management subsystem. This is primarily used for gathering statistics.
SHRTOP	Share topology library - Used for various filer-subshare computations.
SID_CACHE	Security descriptor translation daemon (XSDD) and its caches. XSDD translates between Security IDs (SIDs) on various file servers and the principal (group or user) names in a Windows domain.
SLMCONFD	SLM Configuration Daemon - not supported.
SMGMT	Storage Management Library.
SMTP	Used for file transfer (through email), email events, and other email-related features.
SNAPD	Snapshot daemon, which coordinates snapshots on multiple filers behind an ARX volume.
SQMD	Redundant Pair Site Quorum Manager, which makes failover decisions based on cluster integrity.
SSB_LIB	SSB Library. The SSB is an internal mechanism for processes to communicate with one another.
SSBEVENTD	SSB Event Daemon. The SSB is an internal mechanism for processes to communicate with one another.
SSH	SSH configuration.
SSRM	Simple Share Resource Monitor, which monitors filers on behalf of the HA subsystem.
STATSD	Statistics Daemon, which exposes all ARX statistics to SNMP, the CLI, and the ARX manager (GUI).
STATSMON	Statistics monitoring.
SUBSHRMGT	Subshare management daemon and its client library. This manages filer subshares. A filer subshare is any CIFS share that is inside another CIFS share.
SVCMGR_LIB	SvcMgr Client Library. This is deprecated, so it is unlikely to yield any log messages.
SYNC_CLOCK	Log messages related to sync_clock and sntpc on ASMs - not supported.
SYNC_LIB	Shadow Synchronization Library, which supports a shadow volume (see POLICY_SHADOW).
SYSLOG_NG_GUARD	syslog-ng_guard, which monitors and (if necessary) reanimates the syslog-ng process. The syslog-ng process maintains the syslog file, possibly duplicating it to a remote peer.
TASK_LIB	Task Dispatcher Library - Internal framework used by internal processes for managing event-driven tasks and scheduled tasks.
TCMD	NSM Configuration Manager.
TCORED	NSM Core Dump Manager.
TIME	Not supported.
TRANFS	Transitional File System in DNAS.
TRANFSD	Not supported.
TXNMOND	Object Manager Transaction Monitor. This monitors the internal database, which stores the ARX configuration. (You can see the full ARX configuration with 'show running-config' and 'show global-config.').
UTIL	Fast Filter IPC Utilities, for communication between internal ARX processes and the Chassis Manager (see CHASS).
VCIFS	dNAS CIFS Proxy, which handles requests to volume software on behalf of CIFS clients.
WDOG	Watchdog, which performs internal health checks on ARX hardware such as the SSB. The SSB is an internal mechanism for processes to communicate with one another.
WMA	Windows Management Authorization (WMA) CLI Commands and Library.
WMI	Software Library for managing snapshots on back-end Windows servers using Windows Remote Management protocol (WinRM) and Windows Management Instrumentation (WMI).

Purpose	You can set up auto-diagnostics to regularly gather system information and send it to F5 Support. F5 can use this information to monitor your ARX from off site, watching for gradual loss of service or resource degradation. The information sent to F5 is the output from a series of CLI show commands. You can use the additional-command operation to add another show command to this collection of diagnostics. Use no additional-command to remove an extra show command from auto-diagnostics.
Mode	gbl-auto-diag
Security Role(s)	storage-engineer or crypto-officer
Syntax	additional-command "show-command-string" no additional-command "show-command-string"   show-command-string (1-128 characters) is a valid show command in the ARX CLI, such as show schedule. Surround the string with quotation marks (as shown) if it contains any spaces.
Default(s)	No additional commands configured.
Guidelines	This command adds an additional show command to the following list, which is always included in the auto-diags collection: show clock show chassis show processors show processors usage show health show version show running-config show global-config show ron show namespace all show arp all show redundancy all show cores show statistics namespace ... fastpath all fastpath show policy details show cifs-service user-sessions all summary show statistics cifs authentication all show active-directory status detailed show statistics filer detailed show external-filer all
Guidelines (Cont.)	You can add up to 20 additional commands to the above list. The no form of this command cannot remove any of these default show commands. In a redundant pair of ARX machines (see redundancy), both peers collect and send auto-diagnostics information through E-mail. All of the commands in gbl mode are shared between the peers, so only the active peer collects gbl-mode information (such as show global-config and show namespace all). Both peers collect and send commands related to cfg mode (such as show running-config and show ron). This also applies to any commands you add to the collection with additional-command; if the command relates to gbl mode, it is only included in collections from the currently-active peer. If the command relates to cfg mode, it is included in auto-diagnostic collections from both peers.
Sample	prtlndA(gbl-auto-diag)# additional-command "show channel summary" adds a new show command to the auto-diags collection for the prtlndA chassis.
Related Commands	auto-diagnostics

Purpose	F5 Support can monitor your ARX from off site, watching for gradual loss of service or resource degradation. This is accomplished by the ARX gathering diagnostic information and sending it (encrypted) as an E-mail attachment to F5. You can set the schedule, along with additional E-mail recipients and other options. Use the auto-diagnostics command to begin setting up auto monitoring by F5 Support. Use the no auto-diagnostics command to disable auto-diagnostics and remote monitoring.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	auto-diagnostics no auto-diagnostics
Default(s)	no auto-diagnostics
Guidelines	You must configure SMTP on the ARX before you enable auto-diagnostics, which uses E-mail as a delivery mechanism. Start with the smtp command in cfg mode. We recommend activating this feature so that F5 Support can monitor your ARX and watch for impending issues. This also provides F5 Support with you updated configuration data, so that you will not be required to provide this data at the beginning of a support call. This eases the burden of backing up your running-config and global-config; this provides a second backup for both configuration files. This command places you in gbl-auto-diag mode, where you must use the schedule (gbl-auto-diag) command to assign a schedule for collecting and sending diagnostic information. You can optionally use the mail-to (gbl-auto-diag) command to add additional E-mail recipients; the attachment is only encrypted for the E-mail to F5 Support. You can also use additional-command to add more show commands to the E-mail. To test the configuration, you can use the auto-diagnostics test command in priv-exec mode. The show auto-diagnostics command shows the current configuration for this utility, along with the status of the most-recent auto-diagnostics collection. In a redundant pair of ARX machines (see redundancy), both peers collect and send auto-diagnostics information through E-mail. All of the commands in gbl mode are shared between the peers, so only the active peer collects gbl-mode information (such as show global-config and show namespace all). Both peers collect and send commands related to cfg mode (such as show running-config and show ron). This also applies to any commands you add to the collection with additional-command; if the command relates to gbl mode, it is only included in collections from the currently-active peer. If the command relates to cfg mode, it is included in auto-diagnostic collections from both peers. To address an immediate issue, use the collect command to gather a larger amount of diagnostic information and possibly send it to F5 Support.
Guidelines: Show Commands Included in the Auto Diagnostics Collection	The process always includes the following show commands in its E-mail attachment: show clock show chassis show processors show processors usage show health show version show running-config show global-config show ron show namespace all show arp all show redundancy all show cores show statistics namespace ... fastpath all fastpath show policy details show cifs-service user-sessions all summary show statistics cifs authentication all show active-directory status detailed show statistics filer detailed show external-filer all
Sample	bstnA(gbl)# auto-diagnostics bstnA(gbl-auto-diag)# ... starts configuring auto diagnostics (and remote monitoring) for the bstnA switch.
Related Commands	schedule (gbl-auto-diag) mail-to (gbl-auto-diag) additional-command collect smtp auto-diagnostics test show auto-diagnostics

Purpose	F5 Support can monitor your ARX from off site, watching for gradual loss of service or resource degradation. This is accomplished by the ARX gathering diagnostic information and sending it (encrypted) as an E-mail attachment to F5. After you set up the schedule for this auto-diagnostics data collection, you can use the auto-diagnostics test command to perform a test run.
Mode	priv-exec
Security Role(s)	storage-engineer or crypto-officer
Syntax	auto-diagnostics test [local]   local (optional) sends the E-mail to local recipients only, defined by the mail-to (gbl-auto-diag) command. This does not send any E-mail to F5.
Default(s)	None.
Guidelines	This command gathers auto diagnostics (as determined by the auto-diagnostics command and its sub-mode commands), compresses them into a Unix Tape Archive (tar) file, and sends the file through smtp as an E-mail attachment. This tests both the auto-diagnostics configuration and the smtp configuration. By default, the E-mail goes to F5 Support and all configured mail-to (gbl-auto-diag) addresses. The E-mail attachment for F5 Support is encrypted, as it must travel outside your local network. The E-mail attachment is un encrypted for each of the local mail-to (gbl-auto-diag) addresses, for convenience. You can use the local option to send the test message only to the local addresses. The E-mail messages from this test have a different subject line than standard messages from scheduled runs: the subject line begins with Test:.
Sample	bstnA# auto-diagnostics test local collects and sends auto diagnostics, un encrypted, to the local E-mail addresses set by the mail-to (gbl-auto-diag) command.
Related Commands	auto-diagnostics mail-to (gbl-auto-diag) smtp

Purpose	Certain SNMP traps raise persistent alarms on the system. For each raise trap, there is a corresponding clear trap that clears the alarm condition. You can use the clear health command to manually clear a raised alarm condition.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	clear health trap   trap (1-64 characters) identifies the trap(s) to be cleared. Use show health to see a list of traps with open alarm conditions. Use the Event name from the output of show health.
Default(s)	None
Guidelines	The show health command shows all currently-raised traps on the system. For cases where a raised trap is unlikely to every be cleared by its corresponding clear trap, you can use this command to manually clear the trap. This clears all instances of the given trap. Then the alarm condition no longer appears in the show health output.
Sample	bstnA# clear health diskFail clears all diskFail traps.
Related Commands	show health

Purpose	Some machine problems require more diagnosis than is possible on-site. Use the collect command to collect diagnostic data on the switch and either upload it or store it locally.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax: Uploading to an FTP Site	collect {all | diag-info | config | cores | logs | stats-logs | reports | state | capture} ftp://[user:password@]server/file.tgz [async]   all | diag-info | config | cores | logs | stats-logs | report | state | capture chooses the type of diagnostics to be collected: all collects all diagnostic files on the switch. diag-info collects all diagnostic files on the switch except reports, which can be excessively large. config collects the configuration database, database logs, and the output from show running-config and show global-config. cores gathers any core-dump files on the system, along with all shared-object libraries used by the system. logs assembles the syslog, the procdat log (process data; a more-detailed log file for diagnosis by engineers), upgrade and installation logs, disk-usage logs, Kerberos state files, and logs from the systems service manager. For options to collect logs from specific times, see the documentation for collect logs. stats-logs selects all stats-log files, .csv files with performance data relevant to the ARX, its filers and servers, and other external devices. You can use the show stats-logs command to list all of the stats-log files currently available. reports chooses all reports. state collects individual log files from every processor in the switch, three system log files (syslog, procdat, and traplog), a chronological list of all CLI commands used since the switch booted, the latest of each of the stats-log files, and the output from a series of useful show commands. capture selects only the packet-capture files, if there are any. These files show the flow of IP traffic through the ARX during a capture session. You can use show capture to list all of the capture files currently available. ftp://[user[:password]@] server/file.tgz (1-1024 characters) is the destination URL: user[:password]@ (optional) is the username and password (for example, random:pw@). If you omit the password, the CLI prompts you for one. server is the machine name (for example, mymachine.myco.com). file.tgz is the desired path name for the file. Lead with an extra slash (/) if the path is absolute: for example, ...myserver//var/log/acopiaDiags.tgz specifies /var/log/acopiaDiags.tgz on myserver. Use only a single slash if the path is local to the users home directory.
Syntax: Uploading to an FTP Site (Cont.)	async (optional) makes this command return immediately, rather than waiting for the collection process to finish. The CLI generates a report that you can use to chart the collection process; the report name appears after the process starts.
Syntax: Secure Upload through SCP	collect {all | diag-info | ... | capture} scp://[user@]server:file.tgz [accept-host-key] [async]   {all | ... | capture} define the collection process, as explained above. scp://[user@]server:file.tgz (1-1024 characters) is the URL for the destination file: user@ (optional if someone created an ip scp-user) is the username to present to the other end of the SCP connection. This user must be valid at the remote host. If you omit this and an ip scp-user is defined, it defaults to the username set by that command. server: is the IP address or hostname for the SCP host. End with a colon (:). file.tgz is the destination-file path. Lead with a slash (/) if the path is absolute (for example, scp://root@10.1.1.5:/var/diags/arx.tgz). Use no slash if the path is local to the home directory for user (for example, scp://root@10.1.1.5:diags.tgz). accept-host-key (optional) indicates that if the other end of the connection has an unknown SSH host key (that is, if it is new, or if its key has changed since the last time the host was contacted), the ARX should accept the new host key and continue with the upload. Otherwise, the ARX stops the upload if the host presents an unknown key. async (optional) was explained above.
Syntax: Sending to an ARX Volume	collect {all | diag-info | ... | capture} {nfs|cifs} namespace vol file.tgz [async]   {all | ... | capture} are explained above. nfs | cifs is a required choice. This chooses the protocol for the file transfer. namespace (1-30 characters) identifies the namespace to hold the collect file. path (1-1024 characters) is the volume name. file.tgz is the path to the collect file, starting at the root of the volume. async (optional) was explained above.
Syntax: Uploading to a TFTP Server	collect {all | diag-info | ... |capture} tftp://server/file.tgz [async]   {all | ... | capture} are explained above. tftp://server/file.tgz (1-1024 characters) is the URL for the collect file: server is the machine name (for example, mymachine.myco.com). file.tgz is the desired path name for the file. Lead with an extra slash (/) if the path is absolute: for example, ...myserver//var/log/acopiaDiags.tgz specifies /var/log/acopiaDiags.tgz on myserver. Use only one slash if the path is local to the servers tftpboot directory. This conforms with the specification for FTP URLs in RFC 1738. async (optional) was explained above.
Syntax: Sending to an E-mail Address	collect {all | diag-info | ... | capture} smtp://[e-mail-address/]file.tgz [async]   {all | ... | capture} are explained above. smtp://[e-mail-address/]file.tgz (1-1024 characters) is an E-mail destination for the collect file: smtp:// declares that the destination is an E-mail address. e-mail-address (optional) is the recipient of the E-mail in username@host format (for example, jsmith@myco.com). If you omit this, the CLI uses the default address set by the cfg-smtp to command. file.tgz is the name of the copy. This is sent as an attachment to the outbound E-mail message. This is not a path, so do not use slashes (/). You must use a .tgz extension. For example, ...acopiaDiags.tgz is a valid file name. async (optional) was explained above.
Syntax: Collecting Locally	collect {all | diag-info | ... |capture} local-file.tgz [async]   {all | ... | capture} are described above. local-file.tgz (1-1024 characters) saves the file locally, to the diag-info directory. To preserve disk space, you can only save one diag-info file at a time. You must use a .tgz extension. async (optional) was explained above.
Default(s)	(FTP only) If you omit the user:password from the FTP URL, the CLI uses the username and password set by the ip ftp-user command.
Guidelines	This file contains multiple log files and possibly core files, so it can be very large. If you upload it, choose a host with ample disk space. If you send the message through SMTP, configure the local E-mail server (chosen with the mail-server command) and the recipient E-mail server to allow very large E-mail messages. (The E-mail server at F5 Support allows for large messages.) For SCP uploads, the CLI prompts for a password; enter the password for the user that you identified in the URL. The CLI also prompts for a password for FTP uploads where you do not supply one in the command. The CLI prompts for confirmation before collecting the diagnostics. Answer yes to continue. The collection process can be time-consuming; prompts appear to show the progress of the operation as it occurs. You must configure SMTP on the ARX before you use the smtp:// syntax for E-mail. Start with the smtp command in cfg mode. For saves to the local disk, you can only save one collect file at a time. If one already exists, the CLI prompts for permission to overwrite the previously-collected file. Use show diag-info to show that the file was created on disk.
Samples	bstnA# collect diag-info ftp://jpublic@arxftp.f5.com/10-24-03.tgz Password: jpassword   Collect diagnostic information? [yes/no] yes sends all diagnostic information to the FTP server at arxftp.f5.com.   bstnA# collect diag-info cifs medarcv /rcrds admin/collect.tgz   Collect diagnostic information? [yes/no] yes sends all diagnostic information to a CIFS volume on the ARX, medarcv~/rcrds.   bstnA# collect config ftp://arxftp.f5.com/10-24-03.tgz   Collect diagnostic information? [yes/no] yes sends only config information. This uses the FTP credentials established by the ip ftp-user command.   bstnA# collect diag-info investigate.tgz   Only one copy of diagnostic information may be stored on the switch at one time. This automatically removes any saved diagnostic information.   Are you sure? [yes/no] yes collects all diagnostic information in a local file.   prtlndA# collect logs smtp://logsAndReports.tgz   Collect diagnostic information? [yes/no] yes collects all logs and sends them in an E-mail attachment.
Related Commands	collect logs copy ftp copy scp copy smtp copy {nfs|cifs} copy tftp ip ftp-user ip scp-user smtp show diag-info

Purpose	You can collect all log files on the system at once, or you can focus on the logs from a specific time. This is an extension of the collect command that applies to log files only.
Mode	priv-exec
Security Role(s)	network-technician, network-engineer, storage-engineer, or crypto-officer
Syntax	collect logs [start-time start [utc]] [end-time end [utc]] destination [async]   start-time start [utc] (optional) sets a starting time for collected logs. If you omit this, the CLI collects all of its logs up to the end-time. start is a time stamp in one of two formats: mm/dd/yyyy:HH:MM:SS is designed for manual entry of a date and time. yyyy-mm-ddTHH:MM:SS is designed for a copy-and-paste of a time stamp from a log file. Time stamps from log files are in UTC instead of local time. utc (optional) declares that the start is in UTC instead of local time. This is typically used for time stamps copied from a log file (the second format from above). end-time end [utc] (optional) sets an end time for collected logs. If you omit this, the CLI collects all of its logs after the start-time. The details of this time stamp are otherwise the same as above. destination is a local-file name, an ARX volume, or a URL. The URL can use FTP, SCP, TFTP, or SMTP. The documentation for the collect command describes the exact syntax. async (optional) makes this command return immediately, rather than waiting for the collection process to finish. The CLI generates a report that you can use to chart the collection process; the report name appears after the process starts.
Default(s)	If you omit the optional flags, the CLI collects all logs.
Guidelines	This is an alternative syntax for the collect command. It is useful for collecting logs from a specific time frame; this can reduce the size of the collection as well as focus a diagnosis.
Samples	bstnA# collect logs start-time 06/05/2007:12:00:00 end-time 06/05/2007:13:00:00 ftp://jpublic@arxftp.f5.com/1hr Password: jpassword   Collect diagnostic information? [yes/no] yes collects logs from noon until 1PM on June 5, 2007. It then sends the collected logs to an FTP site.   prtlndA# collect logs start-time 2007-01-07T05:00:34 utc sinceBoot.tgz   Only one copy of diagnostic information may be stored on the switch at one time. This automatically removes any saved diagnostic information.   Are you sure? [yes/no] yes collects all logs since the given time (in UTC format). All of the logs are placed in a local file named sinceBoot.tgz.
Related Commands	collect

Purpose	You can use the expect monitor command to repeat a show command at regular intervals.
Mode	priv-exec
Security Role(s)	crypto-officer, storage-engineer, network-engineer, or network-technician
Syntax	expect monitor seconds show-command [search-string] [timeout timeout-seconds]   seconds is the number of seconds to wait between each invocation of the command. show-command is a valid CLI show command, surrounded by quotation marks (). Use any of the show commands documented in this manual. search-string (optional) also requires quotes. If you use this, the command stops repeating as soon as the search-string appears in the output. Otherwise, the command repeats until you use <Ctrl-C> to stop it. timeout-seconds (optional, 1-2096) sets a time limit on this monitor process. The show commands stop repeating when this time expires. You can also use <Ctrl-C> to stop the process at any time.
Default(s)	timeout-seconds - 21,600 (6 hours)
Guidelines	You can use this command to watch the progress of a configuration change from the CLI. For example, this command can repeat the show redundancy command after you enable (cfg-redundancy) redundancy for a pair of ARXes, to monitor their initial rendezvous. You cannot issue other CLI commands in this session while the expect monitor command is running. Use <Ctrl-C> to stop the repetition at any time. To run a full CLI script, copy the script onto the ARX (using copy ftp, copy scp, copy {nfs|cifs}, or copy tftp), and then use run to invoke it. To perform any command in the future (possibly on a schedule), use the at command.
Samples	bstnA# expect monitor 5 show namespace wwmed repeats the show namespace wwmed command every 5 seconds, until you use <Ctrl-C> to stop it.   bstnA# expect monitor 10 show namespace medarcv /rcrds repeats the show namespace medarcv command every 10 seconds until /rcrds appears in the output.
Related Commands	at run

Purpose	Use the logging destination command to define an external syslog server as an external logging destination. Use the no form of the command to remove a syslog server.
Mode	cfg
Security Role(s)	network-engineer or crypto-officer
Syntax	logging destination server-name [udp | tcp] [port port] no logging destination server-name   server-name (1-80) is the IP address or hostname of the external syslog server. udp | tcp (optional) is the transport protocol over which to send the syslog messages. port port (optional, 1-65,535) is the UDP or TCP port number where the external server is listening.
Default(s)	udp port 514
Guidelines	The external server receives log messages as they are generated and appends them to its local syslog file. Use the show logging destination command to list all configured external syslog servers.
Samples	bstnA(cfg)# logging destination 10.1.1.76 tcp sends syslog messages over TCP to an external syslog daemon at 10.1.1.76.   bstnA(cfg)# no logging destination 172.16.44.7 stops sending syslog messages to 172.16.44.7.
Related Commands	show logging destination

Purpose	Each group of log messages, known as a log component, has a separately-tunable logging level. Critical level is the most terse, displaying critical log messages only; debug level is the most verbose, displaying all log messages from critical down to debug. The messages appear in the syslog file. Use the logging level command to set a logging level. Use the no form of this command to revert a logging level back to the default.
Mode	cfg
Security Role(s)	network-engineer or crypto-officer
Syntax	logging level component {critical | error | warning | notice | info | debug | disable} logging level all {critical | error | warning | notice | info | debug | disable} no logging level {component | all}   component (up to 255 characters) is the component to tune. See Log Components for a complete list of components. all selects all components. critical | error | warning | notice | info | debug | disable is a required choice. This is the logging level you choose for the component. The disable option stops all logging from the chosen component.
Default(s)	info
Guidelines	Use show logging levels to verify the log-level settings for each component. From any mode, use show logs syslog or grep pattern logs syslog to view the log messages in the syslog file. See the manual, ARX Log Catalog, for a full list of log messages. This command applies to components on the ACM. To enable log messages for the NSM, use logging fastpath processor and logging fastpath component.
Samples	bstnA(cfg)# logging level NSCKRPT debug sets the logging level to debug (as verbose as possible) for NSCKRPT messages.   bstnA(cfg)# logging level all error sets the logging level to error (fairly terse) for all messages.   bstnA(cfg)# no logging level all sets the logging level to the default for all messages.   bstnA(cfg)# logging level RON disable disables logging for the RON component.   bstnA(cfg)# no logging level POLICY_ACTION sets the logging level to the default for POLICY_ACTION messages.
Related Commands	show logging levels show logs grep logging fastpath processor logging fastpath component

Purpose	The auto-diagnostics utility gathers performance data and sends it to F5 Support. It sends the data as an E-mail attachment. You can use the mail-to command to add an additional destination address for these E-mails. Use the no mail-to command to remove an E-mail recipient.
Mode	gbl-auto-diag
Security Role(s)	storage-engineer or crypto-officer
Syntax	mail-to recipient no mail-to recipient   recipient (1-128 characters) is one E-mail recipient (for example, juser@nemed.com).
Default	None
Guidelines	This sets a destination for auto-diagnostics E-mail messages. This E-mail recipient receives a copy of every auto-diagnostics collection that the ARX assembles. This is in addition to the copy sent to F5 Support. The attachment delivered to F5 Support is encrypted, but the attachment sent to this E-mail recipient is not. The maximum number of E-mail recipients is limited by the total bytes required to store them. If they are concatenated into a single string, separated with commas, the total string length cannot exceed 1024 bytes. You cannot remove F5 Support as an E-mail recipient.
Samples	bstnA(gbl-auto-diag)# mail-to juser@wwmed.com sets up one E-mail recipient for the bstnA switch. Whenever the bstnA switch sends out auto-diagnostics to F5 Support, it also sends an un encrypted copy of the diagnostics to juser@wwmed.com.   prtlndA(gbl-auto-diag)# no mail-to ex@nemed.com removes an E-mail recipient.
Related Commands	auto-diagnostics

Purpose	Use the management source command to set a source address for sending syslog messages. Use the no form to remove the management-source configuration.
Mode	cfg
Security Role(s)	network-engineer or crypto-officer
Syntax	management source {mgmt | vlan vlan-id} no management source   mgmt is the switchs out-of-band management interface, the default. You specify the out-of-band management IP address at switch boot-up. vlan specifies to use a configured VLAN. vlan-id (1-4096) identifies the VLAN to use as the source. Use the show vlan summary command for a list of all configured VLANs.
Default(s)	mgmt on platforms that support this command vlan 1 on platforms that do not support this command.
Platforms	any except ARX-VE
Guidelines	Use logging destination to send syslog messages to an external syslog server. This command sets the source address for those log messages. If you remove a VLAN interface that is configured as the management source, the syslog does not function properly. You must configure another source (mgmt or VLAN). The in-band management address for VLAN 1 (the default VLAN) is always the management source for an ARX-VE. The ARX-VE has no out-of-band management interface. Use the show logging destination command to view the current management source.
Sample	bstnA(cfg)# management source vlan 9 configures VLAN 9 as the management source for sending syslog traffic and SNMP traps.
Related Commands	logging destination show logging destination show vlan summary

Purpose	*** This is a beta-level command. It does not appear in the CLI unless you use the terminal beta command to unlock all beta-level commands. *** The ARX records the round-trip times between itself and external devices, such as CIFS clients and back-end filers. The stats-monitor process keeps moving averages of these round-trip times and other statistics, and records them in .csv files in the stats-log directory. The stats monitor also can log notification messages if the number of errors and/or response time from an external device increases dramatically. The stats monitor only logs a notification if the device has these increases multiple times in a row. Use the moving-average command to define the percentage of increase required, and the number of times that the errors or response times must increase that much to merit a notification. Use no moving-average to return to the default thresholds.
Mode	gbl-stmon-nfy
Security Role(s)	storage-engineer or crypto-officer
Syntax	moving-average {response-time | errors} threshold pct-threshold moving-average {response-time | errors} interval num-samples   no moving-average {response-time | errors} threshold no moving-average {response-time | errors} interval     response-time | errors is a required choice. This determines the type of threshold or interval you are setting, response times or errors. threshold pct-threshold (optional, 1-65,535) is the percentage above the moving average that could trigger an alarm. For example, if you set moving-average response-time threshold 200, the stats monitor may trigger a notification if a devices response time is 200% above (or, 3 times) its current moving average. As another example, if you set moving-average errors threshold 150, stats monitor may trigger a notification if the devices number of errors is 150% above its current average. The stats monitor process only triggers the notification if this occurs for some number of samples, as set by the interval option. interval num-samples (optional, 1-65,535) is the number of high samples in a row that are required to trigger a notification. If this many samples in a row are at least pct-threshold above the current average, the stats-monitor process logs a notification.
Default(s)	either threshold - 100% either interval - 6
Guidelines	This is a beta-level command. Use the terminal beta command to unlock all beta-level commands, including this one. The defaults are sufficient for most sites. Use this command only on the advice of F5 Support. This command changes the moving-average thresholds for one set of filers or ARX front-end services, chosen when you use the notify command to enter the mode. The moving average is the average for a number (for example, 8) of the most-recent samples. The 8th time the software calculates a moving average, it takes the average of samples 1 to 8; the 9th time it runs, it averages samples 2 to 9; the 10th time, it takes the average of samples 3 to 10; and so on. If a group of samples deviates from the current moving average, the stats monitor generates a notification. Use this command, moving-average, to decide how many samples in a row it takes to log the notification, and to decide how far over the current average a sample must be to qualify. These notifications are recorded in the syslog; you can use show logs syslog to view them along with all other syslog messages. Look for the log component named SMON_ANALYSIS, or use grep to search for it. To create an additional SNMP trap for each notification, use the trap command. The stats monitor collects data for a long period of time, called a moving-average window, before it starts using the moving average for notifications. This window is calculated from the moving average and sampling interval commands: it is 8 * moving-average interval * sampling interval. By default, that is 8 * 6 * 5 minutes, or four hours. The moving-average window restarts if you use the sampling interval command to change the sampling interval.
Samples	bstnA(gbl-stmon-nfy)# moving-average response-time threshold 10 bstnA(gbl-stmon-nfy)# moving-average response-time interval 3 sets the following tolerances for response times: if a devices response time is 10% (or more) slower than its current average for 3 samples in a row, stats monitor logs a notification message. It also sends an SNMP trap if trap is enabled.   bstnA(gbl-stmon-nfy)# moving-average errors threshold 5 bstnA(gbl-stmon-nfy)# moving-average errors interval 3 sets the following tolerances for errors: if a device returns 5% (or more) errors than its current average for 3 samples in a row, stats monitor logs a notification message. As above, stats monitor also sends an SNMP trap if trap is enabled.
Related Commands	notify trap

Purpose	*** This is a beta-level command. It does not appear in the CLI unless you use the terminal beta command to unlock all beta-level commands. *** The ARX records the round-trip times between itself and external devices, such as CIFS clients and back-end filers. You can use the notify command to trigger analysis for one group of external devices: CIFS-service clients, NFS-service clients, CIFS filers, and or NFS filers. Whenever an issue is discovered for one of the analyzed device groups, the stats-monitor process logs a notification in the syslog. Optionally, the stats monitor can also send an SNMP trap. This command also brings you into a submode, where you can alter the notification settings for the chosen group of devices. You can use the negative form of the command, no notify, to deactivate this stats-monitor process for front-end or back-end services.
Mode	gbl-stmon
Security Role(s)	storage-engineer or crypto-officer
Syntax	notify {cifs-service | nfs-service} notify filer-share {cifs | nfs}   no notify {cifs-service | nfs-service} no notify filer-share {cifs | nfs}   cifs-service | nfs-service is a required choice. The nfs-service option starts analyzing all nfs front-end services, and the cifs-service option starts analyzing all cifs front-end services. cifs | nfs is a required choice if you choose to monitor filer shares. This chooses between analyzing CIFS or NFS on back-end filers.
Default(s)	no notify cifs-service no notify nfs-service no notify filer-share cifs no notify filer-share nfs
Guidelines	This is a beta-level command. Use the terminal beta command to unlock all beta-level commands, including this one. The notify command places you in gbl-stmon-nfy mode, where you can use other CLI commands to edit the notifications for the set of devices you have chosen. The notifications only occur when some number of samples deviates from the moving average by some percentage; for example, a notification occurs when 6 samples from a particular CIFS service have twice as many NetworkErrors as the moving average, or when 6 samples from a particular back-end NFS export have progressively-higher round-trip times for GETATTR requests. You can use the moving-average command to reset the number of samples to trigger a notification, and/or to change the threshold for each sample to qualify as too high. By default, a notification goes to the syslog only; the trap command enables SNMP traps in addition to those syslog messages. The stats monitor records its notifications in the syslog; you can use show logs syslog to view them along with all other syslog messages. Look for the log component named SMON_ANALYSIS, or use grep to search for it. To create an additional SNMP trap for each notification, use the trap command.
Sample	bstnA(gbl-stmon)# notify cifs-service bstnA(gbl-stmon-nfy)# enables analysis of all front-end cifs services.
Related Commands	stats-monitor moving-average trap show health

Purpose	*** This is a beta-level command. It does not appear in the CLI unless you use the terminal beta command to unlock all beta-level commands. *** The ARX records the round-trip times between itself and external devices, such as CIFS clients and back-end filers. The stats-monitor process keeps running averages of these round-trip times and other statistics, and records them in .csv files in the stats-log directory. You can use the sampling interval command to determine the interval at which these samples are recorded. Use no sampling interval to return to the default interval.
Mode	gbl-stmon
Security Role(s)	storage-engineer or crypto-officer
Syntax	sampling interval seconds no sampling interval   seconds (30-86,400) is the number of seconds between each sample. 86,400 seconds is one day.
Default(s)	300 (seconds, or 5 minutes)
Guidelines	This is a beta-level command. Use the terminal beta command to unlock all beta-level commands, including this one. The default is sufficient for most sites. Use this command only on the advice of F5 Support. If you select a sampling interval that is shorter than the default, the stats-monitor process writes .csv files more frequently. These raw .csv files are kept (together with all other log files) on a separate disk partition from configuration files and other important data. Each hour, the stats-monitor also creates an hourly file with the hours first set of samples; this is a summary of the data in the raw file. Use show stats-logs to see a list of these .csv files, or show stats-logs file-name to view the contents of one of them. The stats-monitor files are not permitted to consume more than 50% of the log partition. If the .csv files approach their size limit, the oldest raw-data files are removed and the hourly-summary files remain. This command restarts the calculation of all moving averages. After you invoke this command, stats monitor must run for the full moving-average window before it can log any more notifications (or, possibly, send any more traps). This window is calculated from the sampling interval command as well as the moving-average command: it is 8 * moving-average interval * sampling interval. By default, that is 8 * 6 * 5 minutes, or four hours.
Sample	bstnA(gbl-stmon)# sampling interval 60 reduces the sampling interval (and raises the sampling frequency) to once every minute.
Related Commands	stats-monitor show stats-logs moving-average

Purpose	The auto-diagnostics utility gathers data about the ARX, encrypts it, and sends it in an E-mail message to F5 Support. Use this schedule command to assign a schedule for this operation. Use no schedule to remove the auto-diag schedule, thereby disabling auto diagnostics.
Mode	gbl-auto-diag
Security Role(s)	storage-engineer or crypto-officer
Syntax	schedule name no schedule   name (1-64 characters) identifies the schedule for auto diagnostics. Use show schedule for a list of configured schedules. Choose a schedule that has a frequency measured in days, weeks, or a longer time measure; for example, every day, every 3 days, every 1 week, or every 2 months. This command does not accept a schedule with a higher frequency, such as every 12 hours.
Default(s)	None.
Guidelines	The auto diagnostics utility gathers performance information about your system and regularly sends it to F5 Support. This command sets the schedule for sending this information. The auto diagnostics utility requires a schedule in order to run automatically. To create a schedule, use the gbl-mode schedule command. The schedule cannot run more frequently than once per day; you can define this with the every command.
Sample	minturnA(gbl-auto-diag)# schedule every2am uses a schedule named every2am for auto-diagnostic collection on minturnA.
Related Commands	auto-diagnostics schedule show schedule

Purpose	F5 Support can monitor your ARX from off site, watching for gradual loss of service or resource degradation. This is accomplished by the ARX gathering diagnostic information and sending it (encrypted) as an E-mail attachment to F5. After you set up the schedule for this auto-diagnostics data collection, you can use the show auto-diagnostics command to show the auto-diagnostics configuration along with the status of the latest auto-diagnostics run.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show auto-diagnostics
Guidelines	The output contains several tables of configuration information, followed by a table showing the status of the last auto-diagnostics run. Schedule is the schedules configured name, chosen with the schedule (gbl-auto-diag) command. The fields in this table show the configuration of the schedule. Description only appears if set by the gbl-schedule description (gbl-schedule) command. 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. Stop Time only appears if set by the gbl-schedule stop command. This is the expiration time for the schedule, after which the schedule never fires. Interval is set by the gbl-schedule every command. This is the time between scheduled runs. Duration appears only if set by the gbl-schedule duration command. This is not applicable to auto-diagnostics. 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. Mail-to is a list of local E-mail addresses, added with the mail-to (gbl-auto-diag) command. Every time the above schedule fires, the system sends a tar file with auto-diagnostic output to each of these addresses. It also sends an encrypted version of the same tar file to F5 Support.
Guidelines (Cont.)	Additional commands are extra CLI-show commands that are collected along with the default auto-diagnostics. You can add or remove these with the [no] additional-command command. Status describes the most-recent auto-diagnostics collection and delivery operation since the last reboot. The following fields appear only if an auto-diagnostics collection has occurred: Last time executed is the most-recent time that the schedule fired and the collection process started. Status of last execution is either Success or Failure with a report name in square brackets. You can use show reports report-name to read the report and find the specific failure. Date last sent is a time stamp for the most-recent E-mail delivery. Number of times sent since last reboot shows how many times the system has collected and delivered auto-diagnostics data since the last ARX reboot.
Sample	bstnA(cfg)# show auto-diagnostics shows the auto-diagnostics configuration and status for the bstnA switch. See Figure 38.1 for sample output.
Related Commands	auto-diagnostics

Purpose	Many syslog and CLI-response messages have further documentation to help with problem assessment and diagnosis. Use the show documentation command to display the documentation for a given message.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show documentation msg-catalog-id   msg-catalog-id (1-255 characters) identifies the message. Every message-catalog message has an uppercase ID that appears with it in the syslog and in the CLI.
Guidelines	The output shows the documentation for a particular message-catalog message. The CLI, the syslog, and most processes share a common message catalog. The full message catalog is documented in an alphabetical reference, the ARX Log Catalog.
Sample	bstnA(cfg)# show documentation SQM_CANNOT_BE_PROMOTED_GRACE_PERIOD shows the documentation for one message ID. See Figure 38.2 for sample output.
Related Commands	show logs syslog

Purpose	Certain SNMP traps raise persistent alarms on the system. For each raise trap, there is a corresponding clear trap that clears the alarm condition. Use the show health command to see all SNMP-related alarms that have been raised but not cleared.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show health
Guidelines	This shows a table with one row per active alarm. Each row has the following columns: Date is the date and time when the event occurred. ID is the last three digits in the traps OID. Event is the name of the trap. Description explains the alarm condition. Refer to the ARX SNMP Reference for a full list of all traps, along with explanations for each trap and procedures to address the issue. To manually clear a raised trap, you can use the clear health command. Follow the Guidelines for the command, snmp-server traps, to set up a remote host to receive SNMP traps. For an overall view of the system hardware, use show chassis.
Samples	prtlndA(cfg)# show health shows any raised alarms on the prtlndA chassis. See Figure 38.3 on page 38-40 for sample output.   bstnA> show health shows any raised alarms on the bstnA chassis. See Figure 38.4 on page 38-41 for sample output.
Related Commands	clear health snmp-server traps show chassis

Purpose	Several ARX applications require clock synchronization between the ARX and its network peers. These applications include Kerberos, which frequently uses time stamps, and the policy engine, which often places files based on their last-modified times. Use the show health time-skew command to see the clock differences between the ARX and other stations with which it communicates.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show health time-skew [timeout seconds]   timeout seconds (optional, 1-3600) is the maximum number of seconds to wait for each server response. The default timeout is 3 seconds. The ARX makes two or more attempts in some cases, and this timeout applies to each attempt. Also, the timeout applies to each individual server; the overall time for all servers to respond may be significantly longer. You can use <Ctrl-C> to stop the command at any time.
Guidelines	We strongly recommend using NTP to keep the ARX clock synchronized with other system clocks on the network. Use the ntp server command to connect the current switch to one or more NTP servers. The output shows a table with one row per network peer. Each row has the following columns: IP Address identifies the network device. Role shows the relationship of this device to the ARX. Possible values here are External Filer or Domain Controller. Use the show external-filer command for a full list of external filers used by this ARX. Use the show active-directory command for a full list of DCs and a general understanding of how the ARX is using them. Observed Time Skew ... shows a time value in HH:MM:SS format, followed by ahead, behind, or (for a time value of 00:00:00) nothing.
Sample	bstnA> show health time-skew timeout 30 shows the time skews between the bstnA chassis and its network peers. See Figure 38.5 on page 38-42 for sample output.
Related Commands	ntp server show external-filer show active-directory

Purpose	Syslog messages use numeric IDs to identify namespaces, volumes, shares, and file-history archives. Use the show id-mappings command to map these IDs to the names used in the CLI.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show id-mappings
Guidelines	The output shows four tables: Namespace lists all namespaces on the switch, one per row. The ID column contains the numeric ID. Volume lists all volumes on the switch, one per row. The Namespace column shows the volumes namespace, and the ID column contains the volumes numeric ID. Share lists all shares on the switch, one per row. The Volume and Namespace columns show the shares context, and the ID column contains the shares numeric ID. Contact F5 Support if Not Found appears at the end of any of these rows; this indicates an issue in the configuration database. Archive Name is a table of file-history archives on the ARX. A file-history archive is a repository for a managed volumes file-location records. You can use the file-history archive command to create one. The ID column in this table contains the archives numeric ID.
Sample	bstnA(cfg)# show id-mappings shows the ID mappings on the current switch. See Figure 38.6 for sample output.
Related Commands	show logs syslog

Purpose	Use the show logging destination command to view a list of configured external syslog servers.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show logging destination
Guidelines	The output contains the Source Interface used for communicating with the syslog servers, followed by a list of syslog servers. Use the logging destination command to define a syslog server. Use the management source command to define a source address for sending syslog messages and traps.
Sample	bstnA# show logging destination     Source Interface: mgmt (10.1.1.7)     External Syslog Destination(s) ------------------------------ 172.16.202.8
Related Commands	logging destination management source

Purpose	Log messages are divided into groups based on the system components that generate them. You can set a logging level for each component, from critical (terse; shows only the most-urgent messages) to debug (verbose). Use the show logging levels command to list all of the log components and the current logging level for each.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show logging levels [component]   component (optional) specifies that you only want the logging level for the given component.
Guidelines	The log components are listed in an earlier section; see Log Components. This command shows the logging levels in a graph: for each log component, an X appears in the column of its logging level. Use the logging level command to change any or all component-logging levels.
Samples	bstnA(cfg)# show logging levels shows the logging levels for all components. See Figure 38.7, below.   bstnA(cfg)# show logging levels POLICY shows the logging levels for one component, POLICY. See Figure 38.7, below.
Related Commands	logging level

Purpose	The stats-monitor process keeps round-trip-time (RTT) and error statistics for communication between the ARX and external devices, as well as internal performance statistics. It also analyzes this data, watches for sudden changes in RTT or error rates, and notifies you of these changes. Use the show stats-monitor command to see the current administrative state of the stats monitor.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show stats-monitor
Guidelines	The output contains a configuration table, followed by a table of configured notifications. The notification table only appears if at least one notification is set up with the notify command. Statistics Monitor Configuration is a table with the high-level configuration for the stats monitor. You can edit this configuration with the stats-monitor command and its sub commands. Status is always Enabled. Sampling Interval is the time between the data samples (such as average RTTs and error rates) recorded in the stats-log. The stats monitor records these samples in a series of .csv files. Each .csv file represents one group of external devices (such as back-end CIFS filers or NFS clients for a particular NFS service), or an internal process (such as file migrations or an internal CIFS work queue). You can use show stats-logs to view these .csv files. The default sampling interval is adequate for most sites, but you can use the sampling interval command to change it if necessary. Max Data Size is the storage limit for all statistics (.csv) files stored in the stats-logs partition. Max Raw Data Size is the percentage of Max Data Size permitted for .csv files with raw (not hourly) in their names. Used Data Size and Used Raw Data Size are the amounts of the above storage that are already used. These are for all statistics (hourly and raw) and raw statistics, respectively. Notification Parameters only appears if at least one notification is active; use the notify command to enable analysis and notification for front-end services or back-end filers. This shows each notification in one row of the table, with the following fields: Applies To identifies the type of service, process, or device that is configured for notifications. You set this with the notify command. This is : CIFS Services (related to a cifs front-end service and its clients; these statistics are similar to the CIFS output from show statistics global server), NFS Services (for an nfs service and its clients, similar to the NFS output from show statistics global server), CIFS Shares or NFS Shares (back-end shares behind an ARX volume, viewable with show statistics namespace ... summary on an individual share),
Guidelines (Cont.)	Statistics shows the type of notification. This is Errors for a notification of an unusual number of errors, or RespTime for a notification of an increase in response time. You can use the moving-average command to enable or disable notifications for this type of event. Traps indicates whether or not the stats monitor sends an SNMP trap with this notification. This is Enabled or Disabled, and you can use the trap command to change the setting. Metric is always Mov.Avg. Parameters shows the threshold settings that trigger a notification. You can use the moving-average command to change these thresholds.
Sample	bstnA# show stats-monitor   shows the configuration of the stats monitor. See Figure 38.9, below.
Related Commands	stats-monitor sampling interval show stats-logs

Purpose	Use the show system tasks command to see a list of subsystem tasks running on the ARX.
Mode	(any)
Security Role(s)	crypto-officer, storage-engineer, network-engineer, network-technician, or operator
Syntax	show system tasks
Guidelines	Proc - is the module slot (number) and processor on which this task is running. This column only appears for platforms with more than one physical processor, such as the ARX-4000. Subsystem - is the name of the subsystem task. If the task is a script, that fact is noted in parentheses: (script). Instance - is how many instances of the same task are running on this processor. This column does not appear for the ARX-1500 or ARX-2500. Memory (Kb) - is the amount of memory used by this task. CPU% - measures the CPU cycles that the task is consuming. This percentage is measured since the last invocation of show system tasks. For a measurement of overall CPU usage, use show processors and/or show processors usage. CPU-Time - only appears on an ARX-1500 or an ARX-2500. This shows the CPU time used by the current subsystem task since the process last started. The time is expressed in HH:MM:SS format.
Samples	bstnA> show system tasks shows all subsystem tasks. See Figure 38.10 for sample output.   stoweA> show system tasks shows all subsystem tasks running on an ARX-2500 named stoweA. Figure 38.11 on page 38-52 shows sample output.
Related Commands	show processors show processors usage show logging levels

Purpose	*** This is a beta-level command. It does not appear in the CLI unless you use the terminal beta command to unlock all beta-level commands. *** The ARX records the round-trip times and errors between its own software and other external devices (such as back-end filers and front-end clients), as well as time required for migrations and internal operations. You can use the stats-monitor command to begin configuring an analysis process that keeps a running average of this data and monitors it for sudden changes. Whenever an issue is discovered, the stats-monitor process logs a notification of the issue. Optionally, it also sends an SNMP trap and raises and alarm that is visible with the show health command. You can use the stats-monitor command to enter gbl-stmon mode and edit the analysis parameters.
Mode	gbl
Security Role(s)	storage-engineer or crypto-officer
Syntax	stats-monitor
Default(s)	None
Guidelines	This is a beta-level command. Use the terminal beta command to unlock all beta-level commands, including this one. This command puts you into gbl-stmon mode, where you can use commands to change the stats-monitor configuration. The stats monitor takes periodic samples of errors, computation times, and round-trip times for analysis; you can use the sampling interval command to change the time between these samples. To change the set of external devices that are analyzed (such as front-end client machines and/or back-end filers), you can use the notify command. The notify command also leads to a submode, where you can enable traps for the group of devices and change the thresholds for the device sets notifications. The stats monitor records its notifications in the syslog; you can use show logs syslog to view them along with all other syslog messages. Look for the log component named SMON_ANALYSIS, or use grep to search for it. The raw monitoring data from the stats monitor is kept in .csv files, which you can list and examine with the show stats-logs command.
Sample	bstnA(gbl)# stats-monitor bstnA(gbl-stmon)# enters the configuration mode for monitoring statistics. From here, you can change parameters for the stats-monitor process.
Related Commands	sampling interval notify show stats-logs show stats-monitor show health

Purpose	*** This is a beta-level command. It does not appear in the CLI unless you use the terminal beta command to unlock all beta-level commands. *** The ARX records the round-trip times between itself and external devices, such as CIFS clients and back-end filers. The stats-monitor process keeps running averages of these round-trip times and other statistics, and raises alarms in the syslog if the number of errors from an external device increases dramatically, or if the response time from an external host slows dramatically. Use the gbl-stmon-nfy trap command to trigger an SNMP trap for these alarms. Use no trap to stop sending an SNMP trap for these alarm conditions.
Mode	gbl-stmon-nfy
Security Role(s)	storage-engineer or crypto-officer
Syntax	trap {response-time | errors} no trap {response-time | errors}   response-time | errors is a required choice. This determines the type of error that triggers an SNMP trap: slow response times or excessive errors.
Default(s)	no trap response-time no trap errors
Guidelines	This is a beta-level command. Use the terminal beta command to unlock all beta-level commands, including this one. This command enables traps for one set of filers or ARX front-end services, chosen when you use the notify command to enter the mode. Refer to the ARX SNMP Reference for a full list of all traps, along with explanations for each trap and procedures to address the issue. Follow the Guidelines for the command, snmp-server traps, to set up a remote host to receive SNMP traps. To manually clear a raised trap, you can use the clear health command. To send these traps in E-mail to a set of interested recipients, you can use the email-event command and its sub-commands to create an e-mail event group.
Sample	bstnA(gbl-stmon-nfy)# trap response-time bstnA(gbl-stmon-nfy)# trap errors causes the stats monitor to send SNMP traps for any slow response times or excessive errors.
Related Commands	notify snmp-server traps clear health email-event -> group ... event or group (cfg-email-event) stats-monitor