Applies To:

Show Versions Show Versions

Release Note: ARX version 5.0.1
Release Note

Updated Date: 08/29/2013


This release note documents the version 5.0.1 release of the ARX software. This is a maintenance release. We recommend this release for those customers who want the fixes and enhancements listed in Fixes and Enhancements in This Release.

This release is cumulative, and includes all fixes and enhancements released since version 3.0.0. You can apply the software upgrade to 3.0. and later. For information about installing the software, please refer to Installing the Software.

Note: F5 offers both feature releases and maintenance releases. For more information on our release policies, please see Description of the F5 Networks software version number formats.


- User Documentation for This Release
- Minimum System Requirements and Supported Browsers
- Supported Platforms
     - New/Updated Certifications
- Installing the Software
     - Configuration Changes
- Fixes and Enhancements in This Release
     - Features
     - Fixes
- Fixes and Enhancements in Prior Releases
     - Version 5.0.0
     - Version 4.1.1
     - Version 4.1.0
     - Version 4.0.1
     - Version 4.0.0
     - Version 3.2.2
     - Version 3.2.1
     - Version 3.2.0
     - Version 3.1.0
- Required Configuration Changes
     - For Upgrades from Before 5.0.1
     - For Upgrades from Before 3.2.0
- Optional Configuration Changes
- Known Issues
- Workarounds for Known Issues
- Contacting F5 Networks

User Documentation for This Release

In addition to these release notes, the following user documentation is relevant to this release.

These manuals are available from the ARX® GUI or CLI. From the GUI, click on the Documentation link in the navigation panel. From the CLI, use the show software command for a complete listing of the ARX manuals, then use the following command to upload the manual from the ARX:

copy software manual-name destination-url

You can also find the product documentation on the F5 Online-Knowledge Base web site, along with an extensive solutions database.

[ Top ]

Minimum System Requirements and Supported Browsers

The minimum supported browsers for the ARX GUI are:

  • Microsoft® Internet Explorer® (IE), version 6.0
  • Mozilla® Firefox® 1.5, and other browsers that use the Mozilla engine

Later versions are also supported, such as IE 7 and Firefox 3.x.

[ Top ]

Supported Platforms

This release supports the following hardware platforms:

  • ARX®500
  • ARX®1000
  • ARX®4000
  • ARX®6000

New/Updated Certifications

In Release 5.0.1, there are no new and updated certifications.

New/Updated Certifications in Release 5.0.0

In Release 5.0.0, F5 Data Solutions has certified Windows 2008 for use as both a file server (behind the ARX) and as a client machine (in front of the ARX).

NOTE: Windows 2008 has not been certified as a Domain Controller (DC) in the ARX's Domain.

Windows Filer Servers that Support ARX Snapshots

The following Windows file servers have been certified for use with ARX snapshots:

  • Windows Server 2003
  • Windows Server 2008

The ARX manages snapshots on these file servers through Windows Remote Management (WinRM). This is included with Windows Server 2008, but you must install it on a 2003 server. After installation, create at least one WinRM listener, listening on HTTP port 80 (encrypted or unencrypted). Whether or not the HTTP connection is encrypted, the ARX authenticates through Kerberos.

New/Updated Certifications in Release 4.1.0

In Release 4.1.0, F5 Data Solutions certified the following file servers and client machines for use with the ARX.

Filers and File Servers

F5 has tested and qualified Data ONTAP Release 7.3 and 7.3.1 for use on the following back-end filers:

  • NetApp, and
  • IBM N Series.

F5 has also tested and qualified EMC DART 5.6 for use as a back-end file server.

Client Machines

F5 has tested and confirmed the interoperability of the following client software with the ARX:

  • Mac OS X 10.5.5 with
  • Thursby DAVE 7.1.2.

Release 4.1.0 also supports photocopier/scanners as CIFS clients. These scanners can use their "Save As" feature to save a scanned image to a file on an ARX share. The ARX namespace must have a security setting disabled through the CLI (with the new cifs anonymous-access command) or the GUI to support this option.

F5 Data Solutions has tested and qualified the following Kyocera photocopiers/scanners:

  • KM-C2525
  • KM-C3232
  • KM-C3232E
  • KM-C4035E

New/Updated Certifications in Release 4.0.0

For Release 4.0.0, F5 Data Solutions tested and qualified the following 10-gigabit-networking devices with the ARX®4000:

  • F5 BigIP
    10GBASE-SR JDS Uniphase XFP F529937700F4
  • Cisco 4948
    Cisco X2 SR 10-gig Module
  • Force 10 S50N
    10-gig SR Module
  • SMC 8708L2
  • Chelsio NIC
    10GBASE-SR Intel XFP MYBG69N90U
  • Extreme 10G4Xa
    10GBASE-SR Intel SR XFP MYBG71G81W
  • Intel NIC
    10GBASE-SR Infineon XPAK 01564948
  • Netgear GSM7328S
    10GBASE-SR Netgear XFP SR AXM751
  • Netirion NIC
    10GBASE-SR Infineon XPAK 01564948
  • Nortel 5530-24TFD
    10GBASE-SR Intel SR XFP MYBG71G81W
  • Nortel 4526GTX-PWR
    10GBASE-SR Intel SR XFP MYBG71G81W
  • HP Procurve 2900
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 3400
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 3500
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 4205
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 5400
    10GBASE-SR Procurve X2 DE523RQ001
  • HP Procurve 8100
    10GBASE-SR Procurve X2 DE523RQ001

New/Updated Certifications in Release 3.2.1

In Release 3.2.1, F5 Data Solutions certified the following file-server operating systems for use with the ARX:

  • NetApp Data ONTAP Release 7.2.4 for CIFS-only, NFS-only and Multi-protocol
  • NetApp Data ONTAP Release 7.2.5 for CIFS-only, NFS-only and Multi-protocol
  • EMC Celerra 5.5 for CIFS-only, NFS-only and Multi-protocol
[ Top ]

Installing the Software

For an existing installation, you can upgrade to 5.0.1 from any of the following releases:

  • 5.0.0
  • 4.1.1
  • 4.1.0
  • 4.0.1
  • 4.0.0
  • 3.2.2
  • 3.2.1
  • 3.2.0
  • 3.1.0
  • 3.0.0

For installation instructions, refer to the Upgrading Software chapter in the CLI Maintenance Guide.

This release also includes a new version of firmware. You can upgrade the firmware during the software upgrade; the instructions in the above manual explain how and when to upgrade the firmware.

Configuration Changes

Once you install the software, refer to the Required configuration changes section, which contains important information about changes you must make before using the new software.

[ Top ]

Fixes and Enhancements in This Release

This Release includes the following fixes and enhancements:


Release 5.0.1 is functionally equivalent to Release 5.0.0.


Release 5.0.1 adds the following fixes to the ARX:

When internal logging software was blocked with a rare failure, administrative access was frozen. Administrators could not log onto the ARX to resolve the issue. Now, administrators can log onto the ARX and correct the problem if this rare failure recurs.

A direct (or presentation) volume could not attach to an NFSv3/UDP export unless the export also supported NFSv2. Direct volumes can now attach to NFSv3/UDP exports whether or not the exports also support NFSv2.

Mac OS X clients using SMB file sharing components that are part of the OS were unable to mount shares hosted on the ARX. This was caused by crash of the NetAuthAgent component on Mac OS X. ARX software in this release works around this problem.

Administrators were unable to change the quorum disk location when the quorum disk was offline. Administrators now can change the location of the quorum disk when it is offline.

[ Top ]

Fixes and Enhancements in Prior Releases

The current release includes the fixes and enhancements that were distributed in prior releases, as listed below. (Prior releases are listed with the most recent first.)

Version 5.0.0

Release 5.0.0 included the following fixes and enhancements, also included in this release.


Release 5.0.0 adds the following features to the ARX:

File Tracking
An ARX managed volume moves files through tiers of back-end storage as time passes. Some installations use data-protection systems that perform backups and restores directly on their back-end filers. If a backup occurs on Filer A before an ARX volume migrates some files to Filer B, it is unclear which files should be restored to which filer. The new file tracking application resolves this issue.

You can configure an external file server as a file-history archive and configure a volume's snapshot rules so that they regularly store their file locations in that archive. Later, you can make queries about current file locations as well as their locations as they moved from tier to tier in the past. From the GUI, access the File History Query option from the navigation pane. From the CLI, use the commands described in the chapter, Tracking Files on your Back-End Storage in the CLI Maintenance Guide.

Seamless Managed-Volume Import
Previous ARX-software Releases blocked certain client operations, such as renaming directories, while a managed volume imported storage from its file servers. Release 5.000.000 lifts all client restrictions during a managed-volume import, so that clients can access the managed volume's storage as soon as it is enabled.

Kerberos Authentication for the ARX Proxy User
An ARX proxy user is a set of Windows credentials (a username, Windows domain, and password) that a managed volume can use as its identity for autonomous operations. A proxy user in previous releases always authenticated with back-end file servers using NTLM; as of Release 5.0.0, it can use Kerberos as well.

Copying Files Between ARX Maintenance Directories and ARX Volumes
Release 5.0.0 offers a new option for transporting maintenance files: you can transfer them to and from ARX volumes. This is designed for sites that do not permit FTP access (or other Internet access) to their data centers. You can use the copy {nfs | cifs} CLI command, or its GUI equivalent, to copy software-release files, diagnostic files, logs, or other maintenance-related files. Refer to the CLI Reference Guide for detailed instructions on using the CLI command.

New Online Help in the GUI
The 5.0.0 GUI now offers extensive online help, with indexing, book marking, and a search interface. These new navigation tools give administrators the opportunity to pursue any given topic and learn more as needed.


Release 5.0.0 fixes the following software issues:

When clients repeatedly performed a metadata modifying operation (create, delete, or rename) on the same file or a permission/attribute modification on the same directory during import, the import software unnecessarily rescanned the modified object's directory. The import software no longer performs these redundant scans.

The ARX CLI failed if you entered multi-byte characters (such as Japanese characters) through a terminal emulator that did not support UTF-8.

The output from collect was inaccessible unless you explicitly specified a .tgz extension. The CLI and GUI formerly accepted this directive without the proper extension; the current release prompts for the .tgz extension if it is missing.

The management address for an external filer, set with the ip address a.b.c.d management CLI command, could not be on the out-of-band (OOB) management subnet for the ARX. That restriction is now lifted.

The show ntlm-auth-server status CLI command got an OPEN_SSL_ERROR string if the NTLM-server password was longer than 22 characters. It now allows up to 64 characters, as indicated by the documentation and online help.

If you incorporated a non-existent filer snapshot into an ARX-snapshot rule (with the snapshot manage CLI command), the ARX erroneously created an empty ARX snapshot.

Under rare circumstances, an nsck ... rebuild on a shadow volume made the volume stall in "importing" state.

The ntp server command allowed v1 and v2 of the NTP protocol, two versions that were not supported. The command no longer offers those options.

An ill-timed filer error sometimes resulted in a spurious "Completed" state for a file-placement rule. In the current release, all reports correctly show a failed migration whenever a filer issue causes a failure.

The report for a failed file-placement rule may terminate with the RULE_INTERRUPTED error. This error is designed for rules that were interrupted by configuration changes and reboots. In former releases, it was also inappropriately used for filer errors and connection issues.

The 'Files in Fileset' counter was incorrect in a File-Placement report and the 'show policy' (detailed) output. The counter for 'Files in Fileset' was higher than the actual number of files when it was incorrect. The counter is accurate in the current release.

Incorrect "Snapshot State" appeared in snapshot reports and the output of the "show snapshot" CLI command. The "Snapshot State" of a sparse snapshot should appear as "Sparse" if any of the volume's shares are excluded for any reason. The snapshot state appeared as "Complete" when shares are excluded because of filer configuration. In this release, the snapshot state correctly appears as "Sparse."

Shadow Volume sync performance for ARX4000 was poor compared to that of the ARX6000. Sync performance in the current Release is equivalent between the two hardware platforms.

The option to ignore a back-end file/directory name was applied to directories during import, and it was applied to both files and directories after import. The CLI command was named ignore-directory, and its GUI equivalent had a similar name. As a result of this inconsistent treatment of ignored names, a file could successfully import into a managed volume and then be ignored by volume software, making it inaccessible to clients. The CLI command (and function) has been renamed to ignore-name: this command and its GUI equivalent now ignores all directory and file names that it matches.

The output of the show global-config command displayed reserve file settings for direct volumes.

Conflicting place rules caused a deadlock when simultaneously migrating files between two separate share-farms. Each rule was asking the other rule for a particular share's index while holding a lock preventing simultaneous access.

Dual switch reboot fixed by ignoring a latent disk heartbeat, which caused the junior switch to reboot.

Too many alerts sent due to a transaction leak.

Users could not log on due to authentication errors which were fixed with health check and load balancing improvements.

A standard NFS error resulted in extra "DFM_FILE_ASSERT" messages in the syslog. The ARX no longer logs these unnecessary messages.

The nsmResouceThresholdClear trap was clearing alarm conditions that had not-yet been raised by the nsmResouceThreshold trap. Now any nsmResouceThresholdClear trap follows a matching nsmResouceThreshold trap.

When the dncd tried to send message with too many entries it cored. The NSM can only support up to 64K attach points. When processing a directory with a large number of sub directories, break up the request into multiple messages, which will keep dncd from coring.

Previously, there was a problem display the Japanese character set in a share using a MAC 10.4 GUI on an ARX. This issues is resolved now in the handling of the RPC.

Removing an empty direct/presentation volume will cause disruption to all clients that are attached to that volume. A message now warns the user when the volume is still in use by an active global service (Virtual Service in ARX Manager) and asks if they want to destage anyway.

Previously, log messages contained the use of forward and back slashes for path names. They used to use forward slashes in some cases and now they are consistent.

A shadow-copy rule produced ambiguous errors when its target volume had no more file credits. The errors appeared in the shadow-copy report in the Target Information section, similar to this error:

% ERROR:  (38):
  Read source file attribute data failed; Unable to read file attributes;
File: partial-file-path

Now the report includes a clearer message:

Shadow volume target has no free files

The redundancy software did not send an SNMP trap when the heartbeat directory was restricted to read-only access. The heartbeat directory is on the external filer used as a quorum-disk. Now the redundancy software raises the haPairQDiskOffline trap whenever this write failure occurs.

The ARX had insufficient algorithms for checking the health of its remote Domain Controllers (DCs) and for quickly switching to a healthy redundant DC. As of Release 5.0.0, the ARX began using an LDAP query for its health checks, and offers an option to declare a set of "preferred" DCs in a given Windows Domain. The CLI Storage Guide contains instructions for setting DC preferences and changing the timeout for DC health-check queries.

The ARX kept two copies of each core-memory file. Core files contain important diagnostic information for processes that failed; they typically consume large amounts of space on the internal disks. The ARX now keeps only a single copy of each core file.

User access issues resolved by adding a separate auth queue to vcifs. This is used for incoming NEGOTIATE and SESSION SETUP requests.

The Mibs.tgz file, available in the "software" directory, contained the Secure Agent code as well as the MIBs. The Secure Agent packages have been removed from the Mibs.tgz file. They are still available on the ARX, in the "software" directory alongside the Mibs.tgz file.

A file-placement rule kept trying and failing to migrate files after its target share ran out of space.

A syslog message from the policy engine, RULE_UPDATE_INLINE_FAILED, contained cryptic references to internal processes.

If a file server behind an ARX volume ran out of space, directory renames locked out all other client access for 10 to 15 seconds. The directory renames now fail immediately, without locking out clients.

Workaround: Disable the rule that is scanning.

The clear statistics cifs-auth CLI command did not clear all of the CIFS-authentication statistics. The Failure Reason Table at the end of the show statistics cifs-auth output retained its error strings. Now the clear command clears the full contents of the corresponding show command.

The cancel import CLI command (or its GUI equivalent) failed for a share that had not yet started its import scan. This failure made it impossible to cancel the share import. It also prevented future import cancellations and volume controls in the share's volume.

The POLICY_PEP logging component wrote misleading messages to the syslog during normal tiering operation:

        - no target specified.

These messages appeared when the POLICY_PEP component was at a logging level of "debug." They were not errors. We have rewritten these log messages to be less confusing in the current release.


This redundancy configuration caused a dual reboot:

  • The quorum disk and a managed volume's metadata share are on the same back-end file server,
  • the metadata share is configured as a "critical resource" on the ARX, and
  • file server goes offline.

In the current release, no reboot or failover occurs.


A reboot issue had no immediately client-visible effects, but had the potential to take services offline at a later time. An NSCK destage of one of the affected volumes could trigger the service loss. (From the CLI, you use the nsck ... destage command to destage a volume.) At the time of the destage, all of the volume's front-end services went offline. The root cause of this outage has been corrected.

The show namespace CLI command and the GUI's Managed Volume Details screen both display the number of files used and files available on a volume's shares. The number in the CLI output was different from that of the GUI; one was rounded and the other was exact. In the current release, the numbers match in both interfaces.

The copy ... ftp CLI command (and its GUI equivalent) occasionally failed with the following error:

FTP Put error: 'remote file appears to be the same as the local file, upload is not necessary'.

This rare failure no longer occurs.

Version 4.1.1

Release 4.1.1 was a maintenance release that fixed the following software issues:

Two administrative operations often resulted in omTransactionsRaise traps from the ARX: those invoked by the collect and remove-share ... migrate CLI commands, or their GUI equivalents.

If a managed volume with browsing enabled was importing when a process requested the volume's free space, the import slowed noticeably.

UPN support. Added UPN support for NTLM.

The cancel sync files CLI command had an issue with command completion. The syntax below showed all volumes on the ARX instead of the set of volumes in namespace:

cancel sync files namespace volume ?

Now the command shows only the list of volumes from the specified namespace.


An ARX-snapshot removal is designed to remove each component snapshot from the ARX volume's file servers. If any file server failed to delete its snapshot, the ARX noted the failure and then removed all records of the ARX snapshot from its database. This made it impossible to delete the file-server snapshot from the ARX. Now the delete-snapshot operation keeps the ARX snapshot as a "sparse" snapshot; the sparse snapshot only includes the file-server snapshot(s) where the delete failed.

EMC Checkpoints fail with error "Unable to find file system ID <FSID #>." It is possible that the query can fail to find the file system ID. The usual cause of this problem is that the management IP address set for the external-filer object does not identify the correct EMC Control Station for the file system. To view a list of file system IDs and names, run the command 'nas_fs -list' on the EMC Control Station's management console. If the file system ID reported in the error message is not in the list, then it is likely that the wrong Control Station IP address is configured for the external-filer.

33676, 33676
Previously, the LED link light did not come on for 100Mbps setting for the 500+. This issue has been resolved.

In a particular VPU configuration, a share-removal operation could cause volume software to restart and produce a core file. The restart occurred for a volume that shared its VPU domain with 63 other volumes. (You can remove a share with the remove-share CLI command or its GUI equivalent.)

An ARX administrator could not use remote SSH commands if RADIUS was used for administrator authentication.

A shadow volume sometimes failed if it was backed by an NTFS qtree. The problem was that the shadow-copy rule was using NFS to write its database to the qtree. This release uses CIFS to write the shadow-copy database to an NTFS qtree.

If a multi-protocol volume had a non-latin1 character (such as a Japanese character) in its name, the volume software sometimes failed and produced a core file. The failure only occurred if the namespace's NFS-side character encoding was set to "iso-8859-1;" from the CLI, you can set this with the character-encoding command.

The policy engine failed to detect a rare metadata failure that made it impossible to operate successfully. File-placement rules continued to take CPU cycles without successfully migrating any files. The place rules added many messages to the syslog with this statement: "(No policy queue exists for this volume.)." In the current release, all rule processing stops for a managed volume with this failure.

Share discovery used to not preserve back-end share descriptions. When creating ARX exports by scanning back-end storage, the ARX now initializes the ARX export description from the back end. ** Subsequent changes to the ARX export description will NOT be propagated to existing back-end shares or subshares.** .

The snapshot manage CLI command had an unclear error message. The error message is clearer in this release.

An NSM-core processor could fail with a rare combination of NLM transactions (from NFS clients) and file-server outages. These combinations no longer cause an NSM failure.

The snapshot manage CLI command (or its GUI equivalent) failed unless it was preceded by a snapshot create operation in the same managed volume.

CIFS clients occasionally hung when trying to get a directory listing in a direct (or presentation) volume. The problem only occurred in large directories hosted by a Windows server behind the ARX.

When a CIFS-only volume on the ARX attempted to import a CIFS share from a NetApp filer, the import could fail due to an NFS security setting on the filer. The failure occurred only for an ARX volume configured for CIFS subshares, and for a NetApp share backed by a Unix qtree. The NetApp's Unix-security setting is now properly ignored by the CIFS-import process.

Previously, the LED link light did not come on for 100Mbps setting. This issue has been resolved.

Version 4.1.0

Release 4.1.0 included the following fixes and enhancements, also included in this release.


Release 4.1.0 added the following features to the ARX:

CIFS Access-Based Enumeration (ABE) Support
Release 4.1.0 adds CIFS support for Access-Based Enumeration (ABE). If an ARX volume has ABE enabled, its CIFS clients can only see the files that they have permission to read. That is, inaccessible files and directories do not appear in directory listings. This feature is designed to eliminate client curiosity about files and directories that they do not have permission to view.

The following ABE-supporting filers have been qualified for use behind ABE-supporting volumes:

  • EMC Celerra, software version 5.5.
  • NetApp, software versions 7.2.3 and 7.2.5.
  • Windows 2003 R2 SP2.
  • Windows 2003 SP1.

NOTE: For any ABE-supporting volume backed with NetApp filers, the volume's namespace requires a proxy-user with new access privileges. The proxy-user account must belong to the "Administrators" group on each ABE-supporting NetApp share. This is a higher level of access than the "Backup Operator" privileges required for file migrations.

Support for Maximum Age for Kerberos-Machine-Account Passwords
Some Domain Controllers (DCs) support a "Maximum Age" option that you can set for Machine-Account passwords. This is a secret password exchanged between a machine account (such as an ARX-CIFS service) and the DC when the machine/service first joins the Active-Directory domain. By default, the password lasts indefinitely. Administrators have an option on some DCs to set an expiration period, called a "maximum age." If the machine-account password expires for an ARX-CIFS service, the service can no longer use Kerberos to authenticate its CIFS clients.

Release 4.1.0 adds an operation to resolve this issue. For a site where the maximum age is set and about to expire, you can use the cifs rekey CLI command (or its GUI equivalent) to regenerate the key(s) for your ARX-CIFS service(s).


Release 4.1.0 fixed the following software issues, also fixed in this release:

A reboot failed to recover an ARX4000 in SSB-degraded mode. SSB-degraded mode means that the PCI connection has failed between the DP and the CP. In this release, the connection recovers after a CLI reload or its GUI equivalent.

The snapshot timeout client-tolerance command is unsupportable in some file-server topologies. The solution to this issue is to automatically generate a suitable timeout value for ARX snapshots, and to deprecate the command.

When an NSM fails in an ARX6000, certain CLI commands and GUI operations hang without ever completing.

When removing a back-end share from a managed volume, a transient connectivity problem with the share's filer can stop the share-removal operation. The share-removal operation now retries for a longer period of time before canceling. (You can invoke a share-removal operation with the no share, no filer, or remove-share CLI commands, or their GUI equivalents.)

Share-removal reports may contain spurious FF ("Found File") entries.

The solution to this problem is to issue a new CLI command, expect change-mfg-date.scr serial-number, where the serial-number is the one on the chassis label. This changes the output of show chassis chassinfo.

Some processes on the SCM or ACM use progressively-more memory, causing the ARX to eventually refuse administrative logins and offer progressively-slower service to its clients.

The ARX supports a single default route; this may be a problem in a multi-VLAN network with a certain firewall configuration.
The new ip route ... per-vlan CLI command allows an administrator to work around this issue. Refer to the CLI Reference Guide for details on this command.

An alarming syslog message, "xsdd_aipc_task: IPC service error 3...," may appear repeatedly on an ARX, often when the ARX is processing a large number of SID translations. This message does not typically indicate a service-affecting problem, so its severity has been downgraded.

The CLI online help does not line up its options with the correct descriptions. For example, the description below should line up with the generic "Text" option instead of the specific "" choice:

my-arx(gbl)# cifs ?      - Specify the global server hosting this CIFS service.      -
nfs1.test.lab       -
Text<1-128>         -


If an ARX with two internal disks (an ARX1000, ARX4000, or ARX6000) loses both of them, it fails to reboot so that its redundant peer can take over its storage services. The resolution to this issue is a proper reboot and a faster failover.

An NSM processor fails and produces a core-memory file if it receives a particular error from a back-end-CIFS filer. This only occurs in a presentation (or "direct") volume.

The following circumstances lead to progressively-more memory consumption on the SCM or ACM processor, 1.1:

  • a presentation (or "direct") volume uses a managed volume as one of its "filers", and
  • that managed volume is deleted.

The bespd daemon uses up progressively-more memory until it fails and restarts. This daemon's memory consumption is visible in the output of the show system task CLI command.


If an ARX4000 NSM experiences certain driver issues, the driver writes an excessive number of repetitive log messages to the serial Console. This slows the performance of the network drivers, and masks useful driver logs.

A DAVE 7.x client application can create an issue when opening directories in an ARX volume: if the ARX has a particular failure while opening the directory, the directory remains open after the DAVE client has left it. A directory in this state cannot be deleted or renamed by other clients.

A pair of NSM processors can unexpectedly fail, causing a failover in a redundant pair of ARXes. This is due to the NSM software's incorrect assertion that an internal-memory buffer (for log messages) has overflowed.

The ARX4000 does not reliably process jumbo frames. (You can enable or disable jumbo frames with the [no] jumbo mtu CLI command.)

Version 4.0.1

Release 4.0.1 included the following fixes and enhancements, also included in this release.


Release 4.0.1 is functionally equivalent to Release 4.0.0. Unlike Release 4.0.0, this release has been fully qualified for use on the ARX®6000 as well as all the other ARX platforms.


Release 4.0.1 fixed the following software issues. These fixes are also included in the current release:

The ARX does not re-create its error.log or fastpath files if an administrator deletes one of them. (You can delete these files with the delete logs error.log or delete logs fastpath CLI commands, or their GUI equivalents.)

If an ARX runs active VPUs on both redundant peers (configurable only on earlier versions of ARX software), the CLI or GUI may show incorrect used-file credits for those VPU(s).

An NFS-access list with more than 128 IP addresses can cause the ARX to repetitively reboot if it is used in a presentation (or "direct") volume's attach point.

The ARX4000 allows the Control Plane to power up when the Data Plane is powered off and/or disconnected. This is an unsupported configuration that causes a software loop and prevents the ARX from fully booting.

If a client reads or writes a file with a particular byte sequence through an ARX4000 VIP, the ARX stops processing client traffic.

Version 4.0.0

This section describes the features and fixes from Release 4.0.0. Sites that upgrade from Release 3.2.0 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 4.0.0 adds the following features:

Release 4.0.0 supports the new ARX®4000 hardware platform, which is a 4U device with 10-gigabit interfaces. The ARX®4000 has storage capabilities equal to an ARX®6000 with 2 ASMs and 2 NSMs. This platform supports a total of 10Gbps throughput.

Passive LACP
The Link Aggregation Control Protocol (LACP, defined in IEEE 802.3ad) dynamically manages the member ports in a channel. For example, if a configuration change disqualifies a port for channel membership, LACP processes automatically detect the change and stop using the port in the channel. Release 4.0.0 supports passive LACP, which you can configure with the lacp passive CLI command. Refer to the Layer-2 chapter in the CLI Network Guide for details on LACP and LACP configuration.


Release 4.0.0 fixes the following software issues:

The policy status showed scan complete/migration complete but the metadata report showed files left on source share.

Deploying switches via template doesn't work with configuration order.

Major inconsistencies revolving around the volume hosting home directories.

When l2 failed on the senior switch, it detected a remote metalog error and causes the junior switch to fail. Since the senior is already rebooting due to the l2 failure, this causes a dual reboot.

Cannot identify volumes using namespace-level metadata.

CIFS AD forest names and Windows domain names are case-sensitive and should not be.

GUI virtual services page does not display "joined" when no exports exist.

A planned ARX reload during a large NTP-time skew can result in an unplanned reboot later.

Remove-share nomigrate incorrectly requires "force" on failed import share. The "remove-share nomigrate" command used by the GUI and from priv-exec at the CLI required the "force" option to remove a share that failed import.

A global server that references only disabled volumes can consume 99% of the CPU.

Scripted creation of a VLAN in the ARX4000 CLI may fail.

Policy is unable to move files from one share to another. When looking at the shares in the managed volume, freespace is being reported correctly, yet when a place rule is enabled, policy is unable to move files.

Can't find active partition in config file.

On the ARX4000, if the data plane is powered up after the control plane, the reload CLI command reboots the control plane but not the data plane.

Cryptic error message needs to be more helpful. Superfluous text removed.

Under cifs-service, the vol-path in the exports command is case-sensitive.

If an NSM core has failed, nsm recovery is disabled, and you create a new CIFS service, the service cannot get past the "Starting" state.

Version 3.2.2

This section describes the features and fixes from Release 3.2.2. Sites that upgrade from Release 3.2.1 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.

Previously, If a file server was very busy, it was slow to respond to CIFS file close messages. Some clients would resend the close if they don't receive a response after some period of time. Multiple closes on the same file identifier would cause the internal state in the ARX to become corrupted resulting in a failure in an NSM processor. This is now resolved.

The customer tried to move subshares to a Windows cluster share farm using the GUI in the ARX. This resulted in the files showing up with 0 bytes and not being accessible (permissions issues). This issue was fixed to provide the necessary subshare handling.

In some unusual circumstances, a filer may take more than 75 seconds to complete a create-file request. This may cause files to appear on the back end that are not recorded in the ARX volume's metadata. If a CIFS client creates the same file during this lag time, the syslog shows a STATUS_OBJECT_NAME_COLLISION error and the ARX sends a vcifsNameCollision SNMP trap. A CIFS volume with auto sync files enabled now also automatically updates its metadata with the new file.

The following circumstances can cause dual-NSM-core failures in two ARXes:

  • redundancy is enabled between the ARXes,
  • their quorum disk is an NFS/UDP share,
  • the NFS filer for the quorum disk is unreachable, and
  • the same NFS filer contains shares used for NFS/UDP storage.


A file-placement rule promoted stripe directories to "master" status during a concurrent rule's volume scan. This occurred when the directory-promoting rule had volume-scan disabled. The concurrent place rule was on the same schedule and did perform volume scans. With this fix, the directory-promoting rule only promotes directories in response to an inline change, not in response to another rule's scan.

When a CIFS client requested a list of snapshots from an ARX volume, an NSM processor lost a small amount of memory. Eventually, the NSM processor failed.

Under extremely rare conditions the NFS Network Lock Manager (NLM) daemon crashed, triggering an ARX to ARX failover. This occurred when multiple NFS clients canceled lock requests simultaneously.

The memory utilization is reported incorrectly for the ASM board of the ARX6000. As a result, when memory utilization is high it is possible for the active switch to failover to the standby switch before sending any memory utilization SNMP traps.

In some cases, NSM processes incorrectly terminated filenames in their syslog messages. Now the NSM terminates all filenames correctly.

The find command succeeds only for volumes in the first-configured VPU domain; it fails for volumes in all other VPU domains.

Some ARX6000s shipped with incorrect serial numbers on their labels. The show chassis chassinfo command displays the correct serial number. The incorrect values are in digits 3-6, which represent the month and year of manufacture.

In some cases, a scheduled snapshot failed without notification.

The output of the show statistics migration CLI command measured its "Average Data Rate" in bits-per-second instead of bytes-per-second. The units shown (such as "MB/s") indicated that the measure was in bytes-per-second. The field now correctly displays its data rate in bytes-per-second.

A share farm with auto-migrate enabled reserved progressively-more memory, until volume software eventually failed and produced a multi-Gigabyte core file. This memory leak is fixed in the current release.

The volume freespace count on the volume detail page of the ARX GUI is reported incorrectly for values larger than terabytes.

Some rare failure scenarios caused a memory leak in NSM processors, leading to eventual NSM-core failures. The causes included:

  • a failed redundancy link, and
  • an overload of TCP packets to be forwarded to a file server.


The ARX sent frequent nsmResourceThreshold traps when the "probuf" resource exceeded 80% utilization. That level of utilization is not unusual, so the threshold for the probuf resource is now 100%.

When a tier 2 NFS filer is slow in responding to client requests from the ARX the performance of ARX operations on tier 1 files may be impacted. Under certain conditions metadata inconsistencies may be introduced.

If two or more CIFS clients repetitively deleted and re-created the same file in a managed volume, the volume spuriously reported a metadata skew for the file. The volume lost track of the file's state. If it happened often enough, the volume's performance suffered.

An additional log message "SSB_LIB_PCI_WORD_WRITE_ERROR" is needed to provide possible early warning for potential hardware issues.

When using MS-RPC to close a file on the ARX, an NSM may experience memory corruption if there are other in-flight operations on that file. This results in the peer NSM processor taking over service.

When a configured name server is unreachable, a domain-join operation sometimes failed due to a timeout.

An internal NFS fault occasionally caused an NSM core to fail on a busy system. The underlying fault is now corrected.

A file-placement rule could remain in an "Initializing" state indefinitely if someone changed its priority during a volume scan. This also affected any other rules running on the same schedule. Now the volume scan may restart or continue, as appropriate; it does not pause indefinitely.

On an ARX with a large number of CIFS Query-Path Info (QPI) requests, an NSM processor occasionally failed. QPI processing is enabled by default in every CIFS-supporting volume, with the cifs path-cache CLI command.

Version 3.2.1

This section describes the features and fixes from Release 3.2.1. Sites that upgrade from Release 3.2.0 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 3.2.1 decreases failover times from an ARX to its redundant peer. The decrease is most-noticeable in ARXes with large configurations (that is, many namespaces, volumes, and/or front-end services).


Release 3.2.1 fixed the following software issues. Fixes for these problems are also included in the current release:

If a filer's multi-protocol (NFS and CIFS) directory contains more than 1,024 files and subdirectories whose NFS names (such as "file?.txt") differ from their CIFS names (like "file~1.txt"), an ARX-managed volume is excessively slow to import the volume. Clients cannot access the volume until the directory finishes importing.

A domain controller that is slow to respond to the ARX's Kerberos-authentication requests can lead to an eventual outage for the ARX's CIFS clients.

An ARX proxy user is a set of Windows credentials (a username, Windows domain, and password) that a managed volume can use as its identity for autonomous operations. When the proxy user had insufficient permissions to read back-end files, policy scans became excessively slow.

When the CIFS-path cache is very busy, it creates excessive log messages and may send an unnecessarily-alarming nsmResourceThreshold trap. (You can activate this cache for an ARX volume with the cifs path-cache CLI command.)

An internal timeout in the policy engine was too short for some large-scale deployments. This occasionally caused the policy engine to stop migrating under heavy load. F5 personnel now have a method for customizing the timeout value as needed.

When a failed migration appears in the output of show policy history, the file name (including the full path) appears twice.

A failover from an ARX6000 to its redundant peer is unnecessarily lengthy.

The collect CLI command, when used to create a local copy of a diagnostics file, uses twice as much internal disk space as necessary. If the diagnostics file is very large, this could potentially fill the ARX disk and cause an unplanned reboot.

The at ... report report-name command produces reports that are not displayable by the show reports command.

If a shadow-copy rule was disabled in the middle of a run, it sometimes deleted directories behind the target (shadow) volume.

The ARX sends the SNMP trap, kerberosCacheRaise, when an internal cache is 85% full. 85% is not sufficiently full to raise an alarm. The solution to this problem was to send progressive kerberosCacheRaise traps when 90% full, then 95%, 98%, and 100%.

If a CIFS application opens numerous Find-Files queries without properly closing them, the open queries can lead to a slow memory-allocation buildup and eventual ARX failure.

A presentation (or "direct") NFS volume reports incorrect free space.

A managed volume prematurely disconnects from an unresponsive back-end filer. If the filer connection improves, this unnecessarily extends the time that ARX clients cannot access the filer's storage.

If a client modifies a directory's attributes and then deletes it, any file-placement rule fills its "inline notify cache" with unnecessary entries about that directory. The rule cannot process legitimate inline notifications (that is, notifications of file changes by the volume's clients) during this time. This also results in excessive, unnecessary messages in the syslog.

When a file-placement rule attempts a directory-rename operation that would exceed a NetApp filer's disk quota, it repeats the failed-rename attempt indefinitely.
A directory rename may use additional disk space if the rename moves the directory to a new parent directory (for example, \dirA\myDir is renamed to \dirA\dirB\dirC\myDir), and one of these conditions also exists:

  • The new parent directory (\dirA\dirB\dirC) exists on one back-end share, but not on the NetApp share, so the ARX must create the parent directory (a stripe of \dirA\dirB\dirC) on the NetApp share.
  • The new parent directory already has a large number of entries (files and subdirectories), so the NetApp file system must request more disk space to store this subdirectory entry.


The policy engine may halt in a managed volume with a large database. When this occurs, the following message appears in the ARX syslog: "Lock table is out of available locks." The policy engine does not process any rules while this condition persists.

When a place rule attempts to migrate a file that is too large for the target share's q-tree quota, but is small enough for the overall back-end volume, the rule retries the migration continuously. This prevents smaller files from migrating.

Downgrading from a 3.aa.bbb release to a pre-3.0.0 release triggers a re-import of all managed-volume shares on the ARX. This only occurs in a redundant pair of ARXes, where the peer is still running the pre-3.0.0 release. This can occur during an unsuccessful upgrade.

A multi-terabyte file migration may stop before finishing.

A failure in the snapshot software can cause the ARX to reboot.

The snapshot manage command, which sends filer-specific-CLI commands from the ARX to its back-end filers, causes the ARX to reboot if it receives an unexpected response to those commands.

A managed volume may lose its NFSv3/TCP connection while importing from an EMC Celerra.

An NSM processor may fail and produce a core file on a busy ARX. The following CIFS-client session may trigger this error condition:

  1. The CIFS client connects to an ARX volume,
  2. fails to authenticate with Kerberos, and then
  3. leaves the CIFS connection idle until it times out.


A managed volume with an NFSv3/TCP share on an EMC Celerra may spuriously mark the share "offline" if the share is accessed over a WAN or VPN.

A CIFS volume may create a hidden-subshare name (for example, "_acopia_dir5_3$") on a back-end filer, and then record it incorrectly in its database. The volume is then unable to find the back-end subshare(s). This only occurs for subshares that are exported with the hidden or expose-hidden option.

A Windows-Vista client cannot create shortcuts to a subdirectory in an ARX export.

Frequent ARX-share additions to a front-end-CIFS service can put the CIFS-volume software into an unstable state. In this state, the CIFS-volume software periodically restarts and writes a core-memory file.

The following CLI command (or its GUI equivalent) causes continuous reboots if the path-to-exclude contains contains both wildcards and UTF-8 characters:

path match not path-to-exclude ignore-case

This is related to bug 30064, which was fixed in an earlier release.


A multi-protocol (CIFS and NFS) volume does not support NTFS qtrees as back-end shares if they run on NetApp Release 7.2.4.

If NFS clients try to mount an ARX volume with NFSv2/TCP, the volume's performance is slow for all NFS clients.

A CIFS volume may stop and restart if its clients have thousands of files open while an MMC (or similar) client is listing its open files.

If a CIFS client attempts to access "\\vip\C$\~snapshot" in a namespace that supports both Windows management (MMC) and snapshots, the namespace software fails. The "C$" share is a virtual share offered for Windows-management access (for example, through MMC). The "~snapshot" directory is a virtual directory for accessing snapshots within an actual share, but does not offer any snapshots in the virtual "C$" share.
For example, suppose the volume(s) in a CIFS namespace is/are shared through a CIFS service at (a virtual-IP address, or VIP). If a client maps the "G" drive to \\\C$ and then starts working in the "G:\~snapshot" directory, the namespace behind the VIP fails.

Version 3.2.0

This section describes the features and fixes from Release 3.2.0. Sites that upgrade from Release 3.1.0 and earlier get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 3.2.0 added the following features:

Microsoft Windows VSS for Shared Folders (or Previous-Versions) Support for ARX Snapshots
Windows offers an interface called Volume Shadow-copy Service (VSS) for Shared Folders (called "Previous Versions" in Windows Vista) for accessing snapshots. Clients can select a file or directory from their Windows Explorer, pull up the Properties sheet, and click on the Previous Versions tab. This tab displays all snapshots for the chosen file or directory. As of Release 3.2.0, a managed volume that supports snapshots can offer them through VSS.

Automated Controls for CIFS-Accessible File/Directory Names Ending In "." (28630)
Trailing spaces and periods (for example, "myFile.txt." or "myDirectory ") are illegal for most implementations of CIFS, though they are supported by the file system under Windows. Some CIFS vendors convert any file or directory names with trailing periods into Filer-Generated Names (FGNs). In Release 3.2.0, a managed volume probes its back-end shares for this behavior and prevents any trailing-period names from migrating to those shares. Refer to the CLI Maintenance Guide for more information on illegal trailing characters in CIFS volumes.

ARX Secure Agent Support for 64-Bit Windows 2003 DCs
The ARX Secure Agent (ASA, described in Secure Agent Installation) now runs on 64-bit Windows 2003 DCs. There are no functional changes to the ASA.


Release 3.2.0 fixed the following software issues:

NSM runs out of memory and crashes.

If a CIFS client joins a new Windows group while connected to an ARX-CIFS service, the client must disconnect from the ARX service and remain disconnected for at least 10 minutes to get the group's access permissions.

The standby ARX sends redundant Kerberos-DC traps (kerberosDCOffline and/or kerberosDCOnline) after the active ARX already sent them.

The snapshot manage command causes the ARX to reboot if it runs on a CIFS volume with a particular configuration issue. The issue is that the actual share name (for example, "MYSHARE") has different case from the one defined in the ARX volume (for example, "MyShare"). In the CLI, you define the share name with the gbl-ns-vol-shr filer command.

Microsoft-Explorer users cannot write to an empty Properties -> Summary tab for a file or directory in an ARX volume.

The GUI allows only 64 bytes in the name of a front-end-export, while the CLI correctly allows up to 1,024 bytes.

If a file-placement rule has spaces in its name, its report name does not have quotation marks ("") around it in the global-config. Without the quotation marks, the report command fails when you run the global-config in the CLI.

If a shadow-copy rule's configuration changes while it is running, the rule pauses indefinitely.

A shadow-copy rule, under rare circumstances, causes a shadow-database corruption at the shadow volume.

If a tentative file-placement rule has a share farm as its target, the rule causes all newly-created files in the share farm to gravitate to a single back-end share.

If you perform a no share or no filer command using the force argument and omitting the remove-file-entries option, all files on the removed share remain in the volume's metadata. This leaves the files visible to clients even though they are inaccessible.

On the originally-junior switch in a redundant pair, you cannot disable or enable a virtual service from the GUI's Virtual Service summary screen.

The ARX is not sending shareOnline traps for NFS shares with import errors.

A volume with the cifs path-cache feature may fail and produce a core file.

Given the following circumstances, an ARX-CIFS volume fails and produces a core file:

  • two back-end shares ("SHARE_A" and "SHARE_B") have subshares whose paths differ only in case (for example, "\\SHARE_A\topDir\nextDir" and "\\SHARE_B\TOPDIR\NEXTDIR"),
  • both subshares are exported with the same share name ("NEXTDIR"),
  • both shares ("SHARE_A" and "SHARE_B") are imported into the same ARX volume, and
  • the ARX volume has filer-subshares enabled.

The volume failure occurs on import if filer-subshares is already enabled before the import, or when filer-subshares is activated later on the already-running volume (for example, with the cifs export-subshares CLI command).


If you disable a share in a CIFS volume with filer-subshares, you cannot re-enable the same share later.

Windows Explorer's VSS for Shared Folders (or "Previous Versions") feature does not function in a CIFS subshare exported from the ARX; no snapshots appear under the "Previous Versions" tab in Windows Explorer.

The GUI's Collect Diag-Info operation (invoked with an action button on the Maintenance screen) does not create a "cli_show.log" file.

Changes to the quorum-disk configuration, such as a change in the IP address of the quorum-disk filer, do not take effect.

Multi-protocol managed volumes do not support EMC file systems with an "accesspolicy=MIXED" setting.

A file-placement rule does not recover from the "Failed" state if the volume stops in the middle of a placement run.

If an ARX volume has a CIFS metadata share, client access is slowed by removing a storage share from the volume (for example, with the remove-share CLI command).

30515, 30462
A remote processor times out waiting for a "watchdog" response from an ASM processor, resulting in an unplanned reboot (and, in a redundant pair, a failover).

You cannot stop and restart the GUI on the backup switch in a redundant pair.

A path or match CLI command can cause continuous reboots if you use both of the following in the command string (or the its GUI equivalent):

  • the optional ignore-case flag, and
  • a wild-card string that contains UTF-8 characters.


A CIFS managed volume with cifs path-cache enabled may create malformed Query-Path-Info packets for named streams. A CIFS client can only trigger these malformed queries in a front-end share of a subdirectory (not the root) of the ARX volume.

A volume with cifs path-cache enabled has slow performance during busy times.

Version 3.1.0

This section describes the features and fixes from Release 3.1.0. Sites that upgrade from Release 2.07.001 get the benefit of all the features and fixes described here, in addition to the features and fixes described above.


Release 3.1.0 added the following features:

Maximum CIFS Exports Increased from 9,000 to 16,000 (28867)
As of Release 3.1.0, the ARX can support a total of 16,000 CIFS front-end shares.

Add Drive Letter to MSRPCs that Require It (28337)
Some Microsoft Remote Procedure Calls (MSRPCs) require a file or directory path in their returns. Prior to Release 3.2.0, the ARX omitted the drive letter from these returned paths; now a CIFS service includes the drive letter if it has browsing enabled.

Full NSM Core Dumps
You now have the option to enhance the core-dump files produced by a failed NSM processor. By default, a failing NSM processor produces an ASCII-text file with its current state. The new nsm binary-core-files CLI command enhances the files to a much-larger binary format, with more information that F5-Data-Solutions engineers can use for diagnosing the cause of the failure.

Faster Failover Times (28901)
The 3.1.0 release includes enhancements in failover times between redundant ARXes. Lab testing has shown failover times that have improved from 34 - 60%.

Enhancements to CLI "show health," GUI "Status," and E-mail Notifications (27313, 26514)
The SNMP-based indicators of ARX health now offer better support for redundancy features. New indicators notify you of NSM-core failovers, ARX failovers, and quorum-disk failures. These indicators appear in the CLI's show health command, the GUI's "Status" screen (under "System Health Information"), and in E-mail notifications.

The CLI "wait-for migration" Command is Fully Supported
The CLI command, wait-for migration, was formerly accessible only if the terminal beta flag was raised. As of Release 3.1.0, this command is fully qualified, accessible, and documented.

Timeout Option for all CLI "expect" Commands (26737)
Every CLI expect command now has a timeout option, which sets a time limit on the operation. The CLI documentation contains the full syntax.

Reload Option for the CLI "clear nvr" Command (28697)
In previous releases, the clear nvr command halted the chassis at the end of the operation, so that you had to turn the power back on manually. This was designed for preparing the chassis for shipment. In 3.1.0, you have the option to reload the chassis instead of halting it.

Beta Option: Defer Setting "Trust for Delegation" During a Domain Join Operation
If an ARX-CIFS service supports Kerberos authentication, you must perform a domain-join operation to join the service to an Active-Directory domain. The CIFS Service must also have "Trust Computer for Delegation" set at the domain controller. By default, the CLI domain-join command (and its GUI equivalent) requires a username and password with sufficient credentials to set the "Trust Computer for Delegation" flag at the DC. The 3.1.0 release offers a beta option to avoid setting the flag from the ARX:

domain-join domain-name no-trust-for-delegation

You can use lesser credentials to run the command with the no-trust-for-delegation flag raised, then log onto the DC with stronger credentials and raise the flag from there.

This is a beta option that has not been fully qualified. You must use the terminal beta command from the CLI to enable this and other beta features.


Release 3.1.0 fixed the software issues below. Fixes for these issues are also included in the current release:

A cryptic error appears in the shadow-copy report when the source volume is undergoing an nsck ... rebuild.

When an import fails for a CIFS share with a corrupt file system, the show namespace command shows an uninformative import error: "...DTFS Operation has error status [-51]."

If you remove a CIFS export at the same instant that the backup ARX reboots, the ARX may incorrectly remove all CIFS exports.

The ASM occasionally hangs during a firmware upgrade operation.

The show exports command may spuriously indicate a successful mount on an NFS share that the ARX cannot import.

The show exports external-filer filer-name command defaults to a spurious IP address,, if the ARX definition for filer-name has an undefined IP address. The command should return an error instead of defaulting.

A busy ARX may emit spurious shareOffline traps for shares named "acopia#:...". These shares are internal to the ARX, and should not be reported in SNMP traps.

If a back-end filer uses NFS filehandles that do not align with four bytes (that is, the number of bytes is not evenly-divisible by four), the ARX may reboot repetitively. Only unsupported NFS filers, such as those from Permabit, use NFS filehandles that cause this problem.

A redundant pair of ARX6000s cannot join if the redundancy link has excessive latency; the backup switch repeatedly reboots without ever fully joining its peer.
Solution: For sites with great distances between ARX6000 peers, F5 Support can extend the redundant pair's tolerance for a long latency.

An inconsistencies report (invoked with the nsck ... report inconsistencies CLI command) occasionally misses some replica-leaf directories that it should have recorded as "SD" entries.

A file-placement rule stops scanning directories if a filer returns a serious scan error (such as "path too long") for a single directory.
Solution:: The rule now logs the failed directory in its show policy statistics and continues the scan. The rule retries all such failed directories after the scan is otherwise complete, and marks the rule as "failed" if the scan errors persist.

If a direct volume "attaches" to a managed volume at the same time a client disconnects from the same managed volume, an NSM processor may fail.

In some cases, a CIFS service does not support both NTLM and Kerberos authentication in the same CIFS-client session.

Under rare circumstances, NFS/TCP clients are briefly blocked out of a managed volume if any direct volume in the same VPU Domain is "attached" to it.

The copy reports command (or its GUI equivalent) truncates reports larger than 2GB.

[ Top ]

Required Configuration Changes

There are no required configuration changes for release 5.00.01.

For Upgrades from Before 5.0.1

This section only applies to installations that upgraded to Release 5.0.0 or earlier.

Once you have installed the software, you must make the following required configuration change(s).

Unicode Upgrade

This section is for administrators who need to upgrade from releases prior to 5.0.0. The 5.0.0 Release includes a new Unicode library that may have an effect on client files and/or directories. The new version of Unicode adds 168 lower-case versions of characters that were uppercase-only in the previous version. The characters derive from the following languages:

  • Native-American languages from modern-day Canada, including SENC'O?EN.
  • Greek symbols for editorial markings.
  • Cyrillic letters that may not be current.
  • Georgian letters from an ancient ecclesiastical alphabet.
  • Glagolitic letters; Glagolitic is a historical Slavic alphabet.
  • Coptic letters, used by the original Christians in Egypt.

After the upgrade to Release 5.0.0, clients cannot open any files or directories with any of these rare characters in their names. This problem should be very rare. The symptoms are different for files than they are for directories, as explained below. If you see these symptoms on any of your files or directories, escalate the problem to F5 Support.


If a Windows client attempts to open a file with one of these characters in its name, an error similar to this appears in Windows Explorer:

Cannot find the \\VIP\unicode/dir1/file%c8%ba.txt


Windows Explorer returns the following error if it attempts to open a directory with one of these characters in its name:

Refers to location that is unavailable

Release 5.0.0 introduces two new maintenance features for shadow-copy rules. If your site uses shadow-copy rules, F5 recommends that you use these features after the upgrade to 5.0.0.

  • Moving the Shadow-Copy Database to the Metadata Share
    You can now place a rule's shadow-copy database on the target volume's metadata share. In previous releases, the shadow-copy database resided on the same back-end filers that held the target volume's copied files. As the set of copied files expanded, it became possible to run out of space on the target filer(s), thereby possibly corrupting the database. The shadow volume's metadata does not grow as fast as its user data, and there are SNMP traps to alert you of free-space issues on that share, so the metadata share is typically a better candidate for this database. From the CLI, you can go to gbl-ns-vol-shdwcp mode and use the database-location metadata-share command to move the shadow-volume database the next time the rule runs.
    This is only necessary for a shadow-copy rule from before the 5.0.0 upgrade. The next time the rule runs, it migrates the database to the metadata share.
  • Shadow Copying Names that Match the CIFS "8.3" Pattern
    This option only applies to an ARX volume that supports CIFS. CIFS-supporting filers typically create an alternate name for any file or directory whose name is longer than eight characters, or whose extension is longer than three characters. The alternate name matches the old-style "8.3" pattern, with up to eight characters that are optionally followed by a "." and up to three more characters. Typically, filers include a tilde (~) in this alternate name. If a real name on the source volume matches one of these alternate names in the shadow volume, the shadow-copy rule refuses to copy the file by default. This is a rare circumstance, but it is possible in any CIFS volume.
    You can change this with a new feature in 5.0.0. From the CLI, you can go to gbl-ns-vol-shdwcp mode and use the cifs-8dot3-resolution command to make the copy possible without overwriting the file with the alternate name.

Refer to the CLI Reference Guide for details on both of these commands.

NOTE: These are not strictly-required configuration changes, but F5 strongly recommends them for customers that use shadow-copy rules on the ARX.

For Upgrades from Before 3.2.0

This section only applies to installations that upgraded from Release 3.1.0 or earlier.

Once you have installed the software, you must make the following required configuration change(s).

For Sites with Windows Filers, New Filer Setting Required for NTLM Connections
Before Release 3.2.0, the ARX used "non-extended security" for its NTLM-authenticated connections to back-end filers. To correct Issue 27316, the ARX started to use "extended security" for its CIFS connections. However, newer Windows servers require NTLMv2 (not NTLM) for its "extended security" connections. To prepare for an upgrade to Release 3.2.0+ in an installation with Windows filers, verify that the following parameter (from the Windows security-policy UI) allows NTLM connections:

Network security: minimum session security for NTLM SSP based clients.

This policy parameter should be set to "No minimum;" none of the four flags for this parameter should be raised.

The following parameter must also be set so that it does not refuse NTLM from clients (such as the ARX). This was required for ARX Releases before 3.2.0, so you only need to investigate this for new Windows filers or new ARX installations:

Network security: LAN Manager authentication level

You must reboot the Windows server for this (or these) changes to take effect.

NOTE: Windows 2008 clients and Windows Vista clients require similar changes to authenticate to ARX services with NTLM. In a typical installation, these clients use Kerberos authentication; no change is required for Kerberos.

[ Top ]

Known Issues

The following items are known issues in the current release.

The ARX4000 Data Plane (NSM side) cannot recover from a power failure until the Control Plane (ASM and SCM side) reboots. (29444)
If the Data Plane (the lower half of the chassis with the network ports) loses power independently of the Control Plane, the Data Plane cannot recover by itself. If both halves of the chassis lose power at the same time (a more-likely event), both halves reboot normally.

Best Practice: The Data Plane and Control Plane each have two power supplies. Connect one power supply from each Plane to one power source, and the other power supply from each Plane to an alternate power source.

Recovery: Stop and restart power on the Data Plane (the upper half of the ARX). This causes both modules to power up in the proper sequence.

File History Query Requires either File or Path name. (34523)
If you are on the File History Query page, and you leave the Path and File fields empty, and then press Query, it won't work and no error returns.

Workaround: Simply enter a Path or a File name, or both.

In the CLI and in the ARX Manager GUI, the "collect all" target file for nfs on VIP multi-protocol volume fails. (34695)
In a multi-protocol environment, if you specify an nfs target for the "collect all" command or the "copy" command, the target file will not be created.

Workaround: In a multi-protocol environment, specify a cifs target for the "collect all" command or the "copy" command. The target file will then be created.

The copy namespace command does not work on direct (presentation) mapped volumes. (34692 )
The interface that copy namespace uses to copy to cifs file servers does not support direct (presentation) mapped volumes.

Workaround: None.

On the ARX 4000, CoreCollector code has been change and may display old cores that were never collected and reported. (34722)
The new CoreCollector code now correctly reports all cores from the current release and previous releases. It may find cores that were never collected and reported.

Workaround: Take the time to notate the creation date of any new core files reported after upgrade, prior to contacting F5 Customer Support.

If a metadata file server type is not set, and you want to remove snapshots for a Delete operation, it fails. (34347)
In this situation, the system can't get information for the metadata file server and so it fails.

Workaround: If you're going to change the contents to include volume-config and metadata for a snapshot rule that already has managed snapshots, then remove the existing managed snapshots before adding the new contents.

When using "copy to a namespace" from a backup (peer) switch an incorrect error message displays. (34817)
The message you see is:% ERROR: CIFS_CONNECT_BADPATH_COPY_NAMESPACE (40960205): Unable to create file 'procdat' in volume '/max1-VOL1' in namespace 'max1'. Reason:Unable to establish a network connection.

Workaround: None. Copying to a namespace from a backup switch is not supported.

The GUI process uses 100% of CPU 1.1 on an ARX with thousands of reports. (31068)

The no monitor module CLI command does not completely disengage its network ports from their port-mirroring roles. (30435)
After you stop port mirroring from one network port to another, the ports retain some of their internal "mirroring" state. This prevents you from performing valid actions on the ports, such as adding them to a channel.

Workaround: Reboot the ARX after you use the no monitor module CLI command. You can use the priv-exec reload command to reboot the ARX from the CLI.

UTF-8 Chinese characters are truncated in namespace name. (30941)
If a user enters Chinese characters that exceed the GUI's limit for any input field, the GUI will not issue an error message but instead simply truncates the input.

The GUI input fields limit input based on characters and not bytes. When entering multi-byte characters, the input may be truncated if the total number of bytes representing the characters exceed the internal byte limit.

The CLI "show clock" output does not always show the correct time after a time-zone change. (24526)
You can use the clock timezone CLI command to set the time zone of the ARX. On rare occasions, the output from the show clock command does not show the correct time after this change. For example:

ARXa500# clock set 14:43:00 01/11/2007
ARXa500# show clock
        Local time:  Thu Jan 11 14:43:02 2007 EST -0500 America New_York
    Universal time:  Thu Jan 11 19:43:02 2007 UTC
ARXa500# config
ARXa500(cfg)# clock timezone America Denver
ARXa500(cfg)# show clock

        Local time:  Thu Jan 11 14:43:13 2007 EST -0500 America Denver
    Universal time:  Thu Jan 11 19:43:13 2007 UTC

The time does not conform to the new time zone, though the correct new time zone (America Denver) does appear in the output.

Workaround: Log out of the CLI and log back in.

During the hour of transition from daylight-savings time to standard time, the clock set CLI command incorrectly interprets times in some time zones. (24709)
Times are ambiguous in the hour when daylight-savings time reverts to standard time, once per year. Suppose the transition occurs at 3 AM on the day of the daylight-savings change: time passes from 3 to 4 AM in daylight-savings time, then the clock goes back to 3 AM for standard time, and then time passes from 3 to 4 AM again. In some time zones, if you reset the clock to a time between 3 and 4 AM, the clock set command may not interpret your time correctly. If this occurs, the ARX assumes that the transition to standard time has already occurred.

This only occurs in time zones that are East of the Prime Meridian, with positive offsets from UTC.

Workaround: Avoid the clock set command during the day and hour of transition.

The CLI displays unintended errors if you interrupt the copy CLI command (with <Ctrl-C>) during the file transfer. (32531)
The CLI copy command prints the following messages while it transfers a large file to or from the ARX:

% INFO: Transferred nnn of total megabytes; still copying . . .

If you press <Ctrl-C> while the CLI is printing these messages, some internal processes continue after the overall copy process halts. After 20-30 seconds, the CLI displays the following errors from those sub-processes:

gunzip: stdin: unexpected end of file
acrypt: Error, uncompress failed(256).

No output appears for the show statistics namespace fastpath CLI command. (34834)
This CLI command is designed to print statistics for every namespace on the ARX. It only prints statistics for specific namespaces. The CLI Maintenance Guide and the CLI Reference Guide incorrectly document the full, intended output for the command.

An ARX4000 does not support jumbo frames with 4.1.0 software and older firmware. (32103)
On an ARX4000 that is running 4.1.0 or later software with an earlier version of firmware, NSM cores fail if they are configured for jumbo frames. (You can enable or disable jumbo frames with the [no] jumbo mtu CLI command.)

Workaround: A workaround is only necesssary if you upgrade an ARX4000 from Release 4.0.0 or earlier. In this case, upgrade the ARX4000 with the latest firmware as part of the installation process. For installation instructions, including the method for upgrading firmware, refer to the Upgrading Software chapter in the CLI Maintenance Guide.

The ARX cannot send E-mail messages through the out-of-band (OOB) management interface. NTP, DNS, RADIUS, and snapshot-management services (SSH and RSH) are also unsupported through the OOB interface. (24595)
All e-mail notifications from the ARX go out through an in-band (VLAN) management interface, configured with the interface vlan CLI command. At least one in-band-management interface must have a route to the E-mail server for E-mail notifications to function. The same applies to NTP, DNS, and RADIUS services, as well as SSH and RSH for managing filer snapshots.

Workaround: Use the cfg-mode ip route command (without the mgmt flag) to add a static IP route to the E-mail server(s), NTP server(s), DNS server(s), and/or RADIUS servers. All filers and file servers must have a route to be useable by the ARX at all, so this is less likely to be an issue for SSH and RSH.

Spurious errors appear in the syslog after an NSM failover. (25782)
NSM processors have redundant peers, even in an ARX that is not configured for overall redundancy. If an NSM processor fails, its peer processes packets for both. If nsm recovery is enabled, the failed processor comes back online and waits to take over for the running processor. The failed processor may repeatedly put the following message in the syslog:

NAT rule TCP/ip-address:port for remote action ip-address-2:port-2 type 3 not found.

This syslog message is spurious.

Under very rare circumstances, the ARX may block administrative logins after a reboot. (32537)
An ARX in the F5-Development laboratory did not allow administrative logins after a reboot. Logins to the serial-Console port always timed out after entering the administrative password, and logins to the Out-of-Band Management port (typically labelled "MGMT") were rejected with this error message:

ssh_exchange_identification: Connection closed by remote host

F5 Development has been unable to reproduce this problem, despite hundreds of reboots. We note it here until the problem is proven to be unreproducible at any customer site.

Recovery: Power cycle the ARX.

The ARX erroneously allows you to assign the same secondary-IP address to multiple file-server configurations. (33211)
Two different file-servers (called "filers" in the CLI) cannot use the same IP address, but the ARX permits this mis-configuration.

You must separately export a CIFS managed volume if you use it as a "managed volume" in a CIFS presentation volume. (21231, 24359)
If a CIFS-managed volume is used as a managed volume in a CIFS-presentation volume, its CIFS front-end service must export the managed volume separately. This is in addition to the export for the presentation (or direct) volume. (The same CIFS service must export both volumes.)

A client IP address remains in the output of show nfs-service mounts after the client unmounts. (24478)
The output of the show nfs-service mounts command is a table of NFS mounts from client machines. For each currently-active client mount, the table displays the Global Server, the mount point, the VIP, and the client IP address.

When the client is unmounted, there may be a slight lag in the update of table information, and a repeat of the show nfs-service mounts command may show the client still mounted.

Workaround: Retry the show nfs-service mounts command.

Snapshot rule spuriously reports that it failed when it gets a minor communication error. (32814)
A snapshot rule pauses a volume's policy migrations while it runs. When the rule completes its filer snapshots, it tells the policy engine to resume its standard migrations. The snapshot rule erroneously reports that it failed if the policy engine fails to respond to this "resume" request. The failure appears in the snapshot report, along with the following message at the bottom of the report:

Unable to notify policy engine to resume any active migrations.

The policyRuleRunSuspend trap does not indicate the cause of the policy suspension. (32756)
An ARX rule may be suspended manually, through a CLI or GUI instruction, or because its schedule has a limited duration that has expired. The trap does not currently indicate whether the suspension is manual or scheduled.

A shadow-copy rule runs indefinitely (instead of terminating immediately) when the RON connection to the target share fails. (32110)
A shadow-copy rule should fail as soon as the RON connection to the target filer fails. Instead, it continues indefinitely, waiting for the RON connection to return.

NSCK reports do not identify "marked" multi-protocol directories where you should run a sync files operation. (23891)
Some multi-protocol (NFS and CIFS) directories are "marked" for special processing. These directories contain files and/or subdirectories one of these naming issues:

  • the name resembles a Filer-Generated Name (FGN, such as "myfile~1.txt"), or
  • the name produces an FGN on its back-end filers (such as "my:file.txt," or "MYFILE" in the same directory as "myfile").

If a directory is marked with one of these naming issues, the volume performs extra processing whenever a client tries to introduce an entry with the other naming issue. Depending on the outcome of the processing, the new client entry could become NFS-only (inaccessible to CIFS clients). Refer to the CLI Maintenance Guide for details.

Clients can resolve these issues by accessing the volume through its VIP and renaming the directory's entries. However, the directory mark persists after all of its child entries have been correctly renamed; you use the sync files CLI command to remove the mark.

The issue is that there are no reports that identify a directory as "marked" after its entries have been correctly renamed.

Workaround: Use sync files to clear the directory mark immediately after renaming its entries.

[ Top ]

Contacting F5 Networks

  F5 Knowledge Base:
F5 Services Support Online:
F5 Online-Request Form:

For additional information, please visit

[ Top ]

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)