Updated Date: 08/29/2013
This release note documents the version 4.1.0 release of the ARX software. We recommend this maintenance 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 2.07.001. You can apply the software upgrade to 2.7.1 and later. For information about installing the software, please refer to Installing the Software.
Note: F5 offers both feature releases and maintenance release. For more information on our release policies, please see Description of the F5 Networks software version number formats.
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 AskF5 Technical Support web site, along with an extensive solutions database.
The supported browsers for the ARX GUI are:
This release supports the following hardware platforms:
F5 has tested and qualified Data ONTAP Release 7.3 for use on the following back-end filers:
F5 has also tested and qualified Data Domain DDX series V184.108.40.206 for use as a back-end filer.
F5 has tested and confirmed the interoperability of the following client software with the ARX:
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:
For Release 4.0.0, F5 Data Solutions tested and qualified the following 10-gigabit-networking devices with the ARX®4000:
In Release 3.2.1, F5 Data Solutions certified the following file-server operating systems for use with the ARX:
In Release 3.0.0, F5 Data Solutions has certified IBM NAS 500G file servers.
An ARX volume can coordinate snapshots amongst the filers behind it. This ARX-snapshot feature supports the following filer-software releases:
All other filers not explicitly listed above are not supported. When the snapshot subsystem attempts a snapshot on an unsupported filer, the error is written to the snapshot-create report and the ARX syslog.
For an existing installation, you can upgrade to 4.1.0 from any of the following releases:
For installation instructions, refer to the Upgrading Software chapter in the ARX CLI Maintenance Guide.
This release also includes a new version of firmware for the ARX4000. If you are upgrading an ARX4000 chassis, you can upgrade the firmware during the software upgrade; the instructions in the above manual explain how and when to upgrade the firmware.
The 3.1.0 release included a new database format and new firmware, described in the subsections below. These changes necessitate additional steps if an ARX crosses from a pre-3.1.0 release to a post-3.1.0 release. This only applies to systems that are upgrading from Release 2.7.1; skip this section if you are upgrading from a later release.
Release 3.1.0 upgraded the policy database, so that it has a different format than the policy database in 2.7.1. In a redundant pair of ARXes, the policy database runs only if both peers are running 3.1.0 or later when the boot process begins. This is a safeguard to allow for a software rollback. For upgrades from 2.7.1, you must therefore reboot the active peer after both peers are fully upgraded to this release. The CLI Maintenance Guide describes the full software-upgrade procedure; this is an additional failover at the end of the process. This causes a brief service outage while the ARX processes fail over.
As mentioned above, this release includes a firmware upgrade for the ARX4000. If you are upgrading from Release 2.7.1, any chassis type requires a firmware upgrade. The 3.1.0+ firmware supports NSM recovery and NSM binary-core files. Instructions for upgrading firmware are integrated into the Upgrading Software chapter of the ARX CLI Maintenance Guide.
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.
This release includes the following fixes and enhancements.
Release 4.1.0 adds 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:
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 fixes the following software issues:
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 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.)
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.
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.
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.
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 "arx.testlab.sg" choice:
my-arx(gbl)# cifs ? arx.testlab.sg - Specify the global server hosting this CIFS service. cifs.arxsg.com - nfs1.test.lab - Text<1-128> - my-arx(gbl)#
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.
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 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.)
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.)
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.
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.
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:
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.
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.
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.
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:
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.
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.
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.)
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 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%.
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 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 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.
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.
path match not path-to-exclude ignore-case
This is related to bug 30064, which was fixed in an earlier release.
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 192.168.25.15 (a virtual-IP address, or VIP). If a client maps the "G" drive to \\192.168.25.15\C$ and then starts working in the "G:\~snapshot" directory, the namespace behind the 192.168.25.15 VIP fails.
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 (Previous-Versions) Support for ARX Snapshots
Windows offers an interface called Volume Shadow-copy Service (VSS) (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 the Secure Agent Installation Guide) 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:
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 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.
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 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.
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).
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.
This section describes the features and fixes from Release 3.1.0. Sites that upgrade from Release 2.7.1 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:
The show exports external-filer filer-name command defaults to a spurious IP address, 220.127.116.11, if the ARX definition for filer-name has an undefined IP address. The command should return an error instead of defaulting.
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.
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.
This section describes the features and fixes from Release 3.0.0. Sites that upgrade from Release 2.7.1 get the benefit of all the features and fixes described here, in addition to the features and fixes described above.
NOTE: Upgrades from Release 3.0.0 are not supported. If your system is currently running Release 3.0.0, upgrade to 3.1.0 or 3.0.1 before installing this Release.
Release 3.0.0 provided the following features and enhancements:
Snapshot integration (CIFS only)
Release 3.0.0 provides the ability to manage the generation, removal, and scheduling of periodic snapshots on a per ARX virtual volume basis across heterogeneous filers. Additionally, the ARX can control access and presentation of snapshots.
Automatic Volume Sizing (AVS)
With AVS, the number of reserve files is automatically set to 4 million files when an ARX managed volume is created. The reserve file limit is automatically increased by 4 million files every time the number of available file credits falls below 2 million. AVS is automatically disabled if the new required limit exceeds the maximum number of reserve files supported within the managed volume or VPU. For information on the maximum file limits supported per ARX platform, see the Site Planning Guide.
Auto Close File Migration
Prior to 3.0.0, the ARX policy engine would not migrate CIFS files that remained persistently open. The policy engine attempted to migrate an open file for a fixed number of retries. If unsuccessful, the policy rule proceeded to the next file. When complete, the policy engine marked the rule as "FAILED" and generated a report indicating which files where not migrated.
With Release 3.0.0, you can optionally configure a file-placement rule to automatically close any file opened by a CIFS client. The policy engine holds the file closed until it has finished migrating or until the migration request is cancelled.
SNMP Traps and E-Mail Notifications
The smtp welcome command was added to send an introductory (welcome) E-mail to all members in an email-event group. The introductory message informs the recipients of the types of system events they will be receiving through E-mail.
A description field was added to the email-event command.
The warmStart trap has been modified to append the cause of reboot in the message text (traplog and email). All reboots are now recorded in the reboot history log file. The SNMP trap text has not been changed.
Robust SID Translation
Prior to 3.0.0, mis-translation of Security Identifiers (SIDs) could occur if local and domain groups had the same names. With V3.0.0, the SID translation algorithm has changed so that only locally-defined user and group SIDs are subject to translation. This enhancement permits identical user and group names to be defined both locally on a file server and within an Active Directory domain.
CIFS Sub-Share ACL improvements
Prior to V3.0.0, with CIFS sub-shares enabled, an ARX managed volume did not support multiple CIFS shares on the same filer. V3.0.0 removes this limitation, and enables migration, tiering, load balance share farms on a single file server where CIFS sub-shares are configured.
CIFS AD Forest-to-Forest Trusts
In a Windows 2003 Active Directory forest, you can link two disjoint Windows 2003 forests together to form a one-way or two-way trust relationship. A two-way forest trust is used to form a transitive trust relationship between every domain in both forests.
Forest trusts can provide the following benefits:
V3.0.0 allows for support for CIFS Kerberos authentication across Windows 2003 two-way (or bi-directional) forest-to-forest trusts.
CIFS AD Auto-discovery from the ARX switch
Prior to 3.0.0, Active Directory forest information had to be manually collected from customers and manually configured in the ARX switch.
V3.0.0 enables the ARX switch to perform automatic discovery of all Active Directory information. The auto-discovery feature works within a single AD forest and does not auto-discover forest-to-forest trusts. This feature greatly simplifies and makes less error prone the installation of the switch in CIFS Kerberos environments.
Deterministic directory mastership when using NSCK Rebuild
Prior to V3.0, in some configurations directory mastership was not deterministic after an nsck ... rebuild operation. After the operation dis-assembled all volumes in the namespace and re-imported them, directory mastership was distributed across all shares. In 3.0.0, the ARX software determines directory mastership based on configured place-rules. For example, if age-based tiering is configured, then all master directories will be assigned to tier-1 share(s).
Release 3.0.0 also included fixes for the following issues. Fixes for all of these issues are also included in the current release:
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.
Upgrade Firmware and (Optionally) Set NSM Recovery
As mentioned above, Release 3.1.0 includes a firmware upgrade. This upgrade is required to support NSM recovery and NSM binary-core files. The required firmware upgrade is discussed above, in Firmware Upgrade for All Chassis Types.
The NSM recovery feature allows an NSM processor to recover after a failure without necessarily rebooting the entire ARX. This configuration change is strongly recommended. After you upgrade the firmware, you can use the nsm recovery CLI command to enable failovers between NSM processors. Refer to the "Preparing for NSM Recovery and Diagnosis" chapter in the CLI Network Guide for full details about the NSM-recovery feature and the nsm recovery command.
Warning: To fully activate the NSM-recovery feature, you must reboot the ARX after you enable it. For a redundant pair of ARXes, enable NSM recovery on the backup ARX first, then enable it on the active ARX (causing a failover to the backup) during off hours.
A stand-alone ARX endures a longer service outage as the ARX reboots; for this reason and others, we recommend redundant ARXes for sites that support extensive client traffic.
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.
In SSB degraded mode, slot reload does not recover the system. (30623)
Slot reload does not reset PCI link when link is already down.
The output from collect is inaccessible unless you specify a .tgz extension. (32636)
The collect CLI command (and its GUI equivalent on the Maintenance screen) always creates a zipped tarball. This is traditionally represented by a ".tgz" extension. The ARX expects this extension, and cannot find the output file if you omit the extension or select a different one.
Workaround: Select a ".tgz" extension for all collect output.
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.
ARX CLI fails if you enter multi-byte characters (such as Japanese characters) through a terminal emulator that does not support UTF-8. (31073)
The ARX character set and the terminal character set must match or the CLI may crash. You can set the ARX to accept UTF-8 characters with the terminal character-set unicode-utf-8 CLI command. The crash occurs when the terminal software is not set for UTF-8 and sends multi-byte characters to a CLI that is configured for UTF-8.
Workaround: To enter multi-byte characters, use a terminal emulator/TELNET program that supports UTF-8.
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.
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: 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 ARX 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.
The management address for an external filer cannot be on the out-of-band (OOB) management subnet for the ARX. (25487)
To support coordinated snapshots in an ARX volume, the volume requires the management-IP address for the filer. You set this with the ip address a.b.c.d management CLI command, or its GUI equivalent. This address cannot be on the same subnet as the ARX's OOB interface. This is related to issue 24595, above.
The ntp server command allows v1 and v2 of the NTP protocol. (30634)
v1 and v2 are not supported. Refer to the CLI Reference Guide for details.
Changes to the global-config may be lost while the standby switch is still booting. (28844)
After a failover, the standby switch may take several minutes to reboot. During this time, while the active and standby switches are synchronizing their databases, it is possible for changes in the global configuration to fail with a database error.
Workaround: Wait for the standby switch to finish booting before making any changes to namespaces, policies, or other storage-related objects. In the CLI, all storage-related objects are under gbl mode.
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 show ntlm-auth-server status CLI command gets an OPEN_SSL_ERROR string if the NTLM-server password is too long. (31029)
The ARX Secure Agent (ASA) applet and the ARX CLI allow an ASA password of up to 64 characters, but underlying encryption software supports a maximum of 22 characters.
Workaround: If you see this error, change the password so that it is 22 characters or less. This change must occur in two places: at the NTLM-Authentication Server (where the ASA is installed) and at the ARX CLI. For instructions on modifying the ASA password, both on the ASA and in the ARX CLI, refer to the Secure Agent Installation Guide.
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.)
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. (30343)
If one or more NSM cores has failed but the others are running, a new CIFS service should be able to start by using the available NSM cores. The problem only occurs if you create the CIFS service while the NSM core(s) is/are down.
Workaround: If any NSM cores are down, use the nsm recovery CLI command before creating any CIFS services. (As mentioned above, you must reboot the ARX to fully enable nsm recovery.) This bug cannot occur if nsm recovery is enabled.
Recovery: Use the reload CLI command to reboot the ARX. In a redundant pair, this results in a failover to the peer ARX.
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.
A ill-timed filer error can result in a spurious "Completed" state for a file-placement rule. (32570)
A filer error or connection error can cause failed migrations for a file-placement rule. If this error occurs at the wrong instant, the migration status for the rule run erroneously appears as "Complete." This incorrect status appears in the output of the show policy namespace vol-path rule-name CLI command, or its GUI equivalent. The Total Failed Migrations field in the same output correctly shows the number of failed migrations.
Recovery: Correct the filer error and manually rerun the file-placement rule. This timing issue is rare, and unlikely to occur on a second run.
A non-specific error appears in some failed file-placement-rule reports. (32609)
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. It is also inappropriately used for filer errors and connection issues.
The Volume Scan Status field may display a "Volume Paused" state after the policy engine has resumed. (32619)
After a volume's policy engine pauses and resumes, it may display an incorrect scan status. This incorrect status indicates that the scan is still paused. It appears in the output of the show policy namespace vol-path rule-name CLI command, or its GUI equivalent. This is a display issue only; the file-placement rule correctly resumes its scan when policy resumes.
The 'Files in Fileset' counter is incorrect in a File-Placement report and the 'show policy' (detailed) output. (32468)
The counter for "Files in Fileset" is higher than the actual number of files when it is incorrect.
Rule never fails when target is out of space. (32080)
Sometimes files need to be move to a share; however, there is not enough space on a target share. The rule still tries and migrations continue to fail. Instead of the rule stopping, it just keeps on trying. This delays other volume scans for other volumes on the same VPU domain.
Workaround: Disable the rule that is scanning.
Spurious syslog errors after snapshot commands. (32230)
After a snapshot command like show snapshot or its GUI equivalent, the following spurious error may appear in the syslog file (available through the GUI or the show logs syslog CLI command):
OM_RECORD_READ_FAILED:: A record read from the configuration database failed. Record result code [noMoreRecords ] Record name [StorageContainer] Debug string [containerName="", filerId=0].
The "noMoreRecords" error (shown above) and the "keyNotFound" error (not shown) are sometimes spurious.
Incorrect "Snapshot State" in snapshot reports and the output of the "show snapshot" CLI command. (32473)
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 appears as "Complete" when shares are excluded because of filer configuration. The snapshot state is correct when shares are explicitly excluded with the CLI exclude command or its GUI equivalent.
Workaround: Observe the "Excluded Shares" section of the report (or command output). This is correct. If any shares appear in this section, the snapshot is sparse.
Shadow Volume sync performance for ARX4000 is poor compared to ARX6000. (30406)
This issue is being actively worked. The issue is alleviated when pursuing the following Best Practice:
This will give a speedup of up-to 4x during initial treewalk vs. default settings, but ONLY with a pre-seeded target on a CIFS volume.
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:
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.
Under rare circumstances, an nsck ... rebuild on a shadow volume can make the volume stall in "importing" state. (18135)
If a shadow volume meets all of the following criteria when someone issues an nsck ... rebuild command, the shadow volume stays in "importing" state for a long time (perhaps hours), and is inaccessible to clients:
The root of the problem is that the .acopia_shadow directories contain millions of files, and the nsck ... rebuild must remove those directories at the beginning of its process. Clients cannot access the volume until all the filers are able to delete this directory.
If this occurs, messages appear in the syslog that describe the problem.
|F5 Online Knowledge Base:||An online repository of answers to frequently-asked questions.
|F5 Services Support Online:||F5's online customer knowledge base and support request system.
|F5 Online-Request Form:||https://login.f5.com/resource/login.jsp|
|Telephone:||Follow this link for a list of international Support numbers:
For additional information, please visit http://www.f5.com.