BROADCOM SANnav Global View Management Portal User Guide

June 6, 2024
BROADCOM

BROADCOM SANnav Global View Management PortalSANnav™ Global View v2.3.1a
SANnav Global View v2.3.1a Release Notes (Digest Edition)
Version 1 (Digest Edition)

SANnav Global View Management Portal

Copyright © 2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.
For more information, go to www.broadcom.com. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Broadcom reserves the right to make changes without further notice to any products or data herein to improve reliability, function, or design. Information furnished by Broadcom is believed to be accurate and reliable. However, Broadcom does not assume any liability arising out of the application or use of this information, nor the application or use of any product or circuit described herein, neither does it convey any license under its patent rights nor the rights of others.
The product described by this document may contain open source software covered by the GNU General Public License or other open source license agreements. To find out which open source software is included in Brocade products or to view the licensing terms applicable to the open source software, please download the open source attribution disclosure document in the Broadcom Support Portal. If you do not have a support account or are unable to log in, please contact your support provider for this information.

Chapter 1: Preface

1.1 Contact Technical Support for your Brocade® Product
If you purchased Brocade product support directly from Broadcom, use one of the following methods to contact the Technical Assistance Center 24×7. For product support information and the latest information on contacting the Technical Assistance Center, go to www.broadcom.com/support/fibre-channel- networking/contact-brocade-support.

Online Telephone

For nonurgent issues, the preferred method is to log on to the Support portal at support.broadcom.com. You must initially register to gain access to the Support portal. Once registered, log on and then select Brocade Products. You can now navigate to the following sites:
Case Management
Software Downloads
Licensing
SAN Reports
Brocade Support Link
Training & Education| For Severity 1 (critical) issues, call Brocade Fibre Channel Networking Global Support at one of the phone numbers listed at www.broadcom.com/support/fibre-channelnetworking/contact-brocade- support

If you purchased Brocade product support from a Broadcom OEM/solution provider, contact your OEM/solution provider for all your product support needs.

  • OEM/solution providers are trained and certified by Broadcom to support Brocade products.
  • Broadcom provides backline support for issues that cannot be resolved by the OEM/solution provider.
  • Brocade Supplemental Support augments your existing OEM support contract, providing direct access to Brocade expertise. For more information on this option, contact Broadcom or your OEM.

For questions regarding service levels and response times, contact your OEM/solution provider.
To expedite your call, have the following information immediately available:
General Information
– Technical support contract number, if applicable
– Switch model
– Switch operating system version and SANnav™ version
– Error numbers and messages received
– SANnav Support Data Capture (SSDC) and Switch supportSave command output and associated files
For dual-CP platforms, the supportSave command gathers information from both CPs and any AP blades installed in the chassis:
– Detailed description of the problem, including the SANnav and switch or fabric behavior immediately following the problem and any specific questions
– Description of any troubleshooting steps already performed and the results
– Serial console and telnet session logs
– Syslog message logs

Switch Serial Number
The switch serial number is provided on the serial number label, examples of which follow:
The serial number label is located as follows:
– Brocade G630, G620, G610, G720, and G730 – On the switch ID pull-out tab located on the bottom of the port side of the switch
– Brocade 7810 – On the pull-out tab on the front left side of the chassis underneath the serial console and Ethernet connection and on the bottom of the switch in a well on the left side underneath (looking from the front)
– Brocade X6-8, X6-4, X7-8, and X7-4 – Lower portion of the chassis on the non-port side beneath the fan assemblies
World Wide Name (WWN)
– When the Virtual Fabric feature is enabled on a switch, each logical switch has a unique switch WWN. Use the wwn command to display the switch WWN.
– If you cannot use the wwn command because the switch is inoperable, you can get the primary WWN from the same place as the serial number.
License Identifier (License ID)
– There is only one license ID associated with a physical switch or director/backbone chassis. This license ID is required as part of the ordering process for new FOS licenses.
– Use the license –show -lid command to display the license ID.
1.2 Related Documentation
White papers, data sheets are available at www.broadcom.com. Product documentation for all supported releases is available on the support portal to registered users. Registered users can also find release notes on the support portal.

Chapter 2: Locate Product Manuals and Release Notes

2.1 Locate Product Manuals onBroadcom.com
Complete the following steps to locate product manuals on the Broadcom website:

  1. Go to www.broadcom.com, click Login, and enter your username and password.
  2. Enter the product name or the software version number in the Search box. For example, the following search is for software and documentation files for SANnav.BROADCOM SANnav Global View Management Portal - setting 1
  3. The list of documents will be listed under Documentation tab in the search result screen as shown below:BROADCOM SANnav Global View Management Portal - setting 2

2.2 Locate Product Manuals and Release Notes on the Support Portal
Complete the following steps to locate product manuals on the support portal:

  1. Go to support.broadcom.com, click Login, and enter your username and password.
  2. If you do not have an account, click Register to set up your account.
  3. Select Brocade Storage Networking in the support portal.

ATTENTION Be sure to periodically check for newer versions updates of SANnav Release Notes and User Guide documents.
2.3 Document Feedback
Quality is our first concern and we have made every effort to ensure the accuracy and completeness of this document. If you find an error, omission or think that a topic needs further development, we want to hear from you. You can provide feedback by sending an email to documentation.PDL@broadcom.com. Provide the publication title, publication number, and as much detail as possible, including the topic heading and page number, as well as your suggestions for improvement.

Chapter 3: Release Contents

3.1 Brocade SANnav Global View v2.3.1a Release Overview
NOTE This Release Notes document covers SANnav Global View v2.3.1a. W ithin this document, SANnav
Global View might also be referred to as SANnav or SANnav GV.

  • All features supported in SANnav Global View v2.3.1 are also supported in SANnav Global View v2.3.1a.
  • There are no new features or RFEs addressed in this SANnav v2.3.1a patch.
  • There are no new hardware platforms or blades supported in this SANnav v2.3.1a patch.
  • SANnav Global View v2.3.1a is a stand-alone release (full installer patch). This means that SANnav GV can be installed without requiring any other previous version of SANnav GV to be installed. It is also possible to upgrade and migrate to SANnav GV v2.3.1a directly from previous releases of SANnav GV.
  • The supported upgrade and migration paths are documented in subsequent sections of this document.

3.2 What’s New in SANnav Global View v2.3.1a

  • Resolution of important defect fixes are listed in Chapter 9 of this document.

3.3 What’s New in SANnav Global View v2.3.1
SANnav v2.3.1 is introduced to provide all required functions and features to manage USF and IPS capabilities in a SAN Fabric as well as to introduce incremental enhancements in specific SANnav functional areas.
The USF and IPS related highlights are as follows:

  • Hardware support and USF IPS Fabric Inventory
  • IPS Inventory (Fabrics, Switches and Switch Ports only)

The non-USF-related highlights are as follows:

  • Deployment
  • OS Support
  • Security enhancements
  • User Management enhancements
  • Miscellaneous enhancements

3.4 What’s New in SANnav Global View v2.3.0
SANnav v2.3.0 provides new features and feature enhancements that aim at simplifying and automating common and frequent operations.
The following new features or feature enhancements are provided in various functional areas of SANnav:

  • Server Platform deployment, Installation, Upgrade, and Migration
  • Security and Infrastructure
  • SANnav Licensing
  • UI/UX and Usability changes: enhanced overall UI/UX usability features in Inventory, Dashboards, and Reporting

Defect fixes included in this release are listed in the defect tables section of this document.
3.5 SANnav Global View Server Platform Support and OS Support
3.5.1 SANnav Global View v2.3.1x OS Support (VM and Bare Metal)
SANnav Global View v2.3.1a was fully qualified and tested with the following versions of RHEL:

  • RHEL releases 8.8 and 9.2.

Note that SANnav v2.3.1 is the first release to officially support RHEL 9.x based OS releases, NOTE When installing SANnav on an untested or unqualified OS version, (i.e., 8.2, 8.3, 8.5, 8.6, 8.7, 8.9, 9.3), the installation script displays a warning message indicating that the SANnav Global View installation will proceed on an untested and unqualified OS version. Explicit end user acceptance is required for SANnav Global View installation to proceed. While it may be possible to successfully install SANnav on these OS versions, if an issue(s) occur while using SANnav it may be necessary to upgrade/downgrade to a fully qualified and tested OS version and reproduce the issue(s) to receive support.
The following table shows the various OS types and versions and the associated support in SANnav v2.3. Cells marked with (Blocked) indicate that the SANnav v2.3.1 installation/upgrade will not proceed and exit, while cells marked (Not Blocked) indicate the SANnav v2.3.1 installation/upgrade will proceed with explicit user acceptance that SANnav will run on an untested and unqualified OS Release.

OS Type and Version VM or BM (bare metal)
CentOS 7.9, RHEL 7.9, 8.0, 8.1, 9.0, 9.1 No (Blocked)
CentOS 7.9 No (Blocked)
RHEL 8.8, 9.2 Yes
RHEL 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.9, 8.10, 9.3, 9.4* No (Not Blocked)

*RHEL 8.10 and 9.4 will be GA sometime in May 2024, after the SANnav v2.3.1a patch is released.
For RHEL OS, the following must be set in the OS on which SANnav Global View server is installed:

  • Language = English and Locale = US

Other Languages and Locales are not supported.
3.5.2 Other Installation and Deployment Features
3.5.2.1 SSL Certificate Expiry Notice
Starting with SANnav v2.3.1x, a SANnav Application Event is raised 30 days before the SANnav SSL certificate expires.
After that, and within the 30 days window, an event is sent daily asking the user to replace the current SSL certificates with new ones.
The following SANnav Application Events are raised for SANnav certificates expiration:

  • SSMP-SMON-1005 – Warning – 30 to 6 days before expiration.
  • SSMP-SMON-1006 – Major – 5 days to 3 days before expiration.
  • SSMP-SMON-1007 – Critical – 2 days before expiration.

With SANnav v2.3.1x, the SAN administrator user can generate and replace the current (valid or expired) SSL certificates with a set of new self-signed certificates by running the script $INST_HOME/bin/generate-and-replace- selfsigned-certificates.sh
NOTE It is recommended to use Certificate Authority (CA) signed certificates (instead of self-signed certificates) and install them on the SANnav server for the highest security protection.
3.5.2.2 SANnav File System Permissions Change
With SANnav v2.3.0, all files under SANnav installation directory had Linux permissions 775 (rwx-rwx-r-x).
With SANnav v2.3.1, all files and folders under the SANnav installation directory now belong to UID/GID sannavmgr (UID/GID 56900) with file permissions set to 770 (rwx-rwx—-) as shown in one folder example below: drwxrwx— 2 sannavmgr sannavmgr 4096 Oct 16 19:18 templates
3.5.2.3 Stop and Start SANnav with Operating System
With SANnav v2.3.1x, when an administrator performs a graceful reboot of the OS on the machine where SANnav server is running, the SANnav application will be gracefully stopped and restarted properly after the OS reboots successfully.
3.5.2.4 Host Time Zone Check
SANnav needs a valid Time Zone set in operating system to operate properly. Starting SANnav v2.3.1x if the time zone settings are deleted accidentally, the SANnav server will not start.
An error message will be shown asking the administrator to set the time zone using the command timedatectl settimzone
3.5.3 FIPS-140 Enabled OS
SANnav GV v2.3.1x is supported on FIPS-140 enabled RHEL (VM or bare metal). Please refer to RHEL specific OS version for the exact command(s) to enable FIPS mode.
Note that SANnav itself is not FIPS-140 certified. SANnav v2.3.1x may be installed and run on an officially supported RHEL version with FIPS-140 enabled.

  • On bare metal and VM deployments, FIPS-140 mode may be enabled prior to installing SANnav
  • It is possible to enable FIPS after running SANnav in non FIPS-140 enabled OS by stopping the SANnav server, enabling FIPS-140 mode at the OS level, then starting the SANnav server again.

3.5.4 SE Linux Support
SANnav Global View v2.3.1x is not supported on Security Enhanced versions of Linux (SE Linux) in Enforcing or Permissive mode on either Rocky or RHEL. The only SE Linux mode supported is Disabled.
If SE Linux is found to be enabled (either Enforcing or Permissive) during SANnav installation, the installation script will stop and exit. Enabling SE Linux post SANnav installation is not supported as mentioned above.
Contact Brocade Technical Support for more information and details on SE Linux support.
3.6 Summary of New and/or Enhanced Software Features
3.6.1 Security and Infrastructure
3.6.1.1 Installation and Upgrade/Migration as sudo

  • Prior to SANnav v2.3.x, only the root user could install and manage the SANnav server. sudo privileged users could not install/upgrade/run/manage SANnav server.
  • With SANnav v2.3.x, users with sudo privileges can now install and manage SANnav server (in addition to the root user).
  • sudo privileged users can install and manage SANnav server by prefixing the script execution with sudo (sudo ./install-sannav.sh).
  • After installing SANnav v2.3.x, additional sudo users may be added to manage SANnav by executing the script adduser-to-sannavmgr-group.sh (script can be executed by sudo user).

NOTE The user to be added must have sudo privilege already. This script simply adds that user to the list of users that can manage/run SANnav.
3.6.1.2 Running SANnav Containers with no root or sudo Privileges

  • With SANnav v2.3.x docker containers will run as a new user sannavmgr with UID/GID 56900. This new user does not require sudo privileges.
    – User sannavmgr cannot be used for remote SSH login to the SANnav server (for security reasons)

  • During SANnav v2.3.x installation or upgrade/migration, this user sannavmgr with UID/GID 56900 will be created.
    Make sure it is available prior to starting SANnav v2.3.1 first time installation.

ATTENTION UIDs 56900 is not configurable in SANnav v2.3.x. If UID and GID 56900 is occupied by another
user on the SANnav host, the installation or upgrade will fail.
3.6.1.3 Important OS Level Customization for User sannavmgr (UID 56900)

  • SANnav server needs ports lower than 1024 for running some of its services.
  • Due to this, Linux ip_unprivileged_port_start parameter is set to 0 to allow sannavmgr to run services on ports lower than 1024.

3.6.1.4 Change SANnav Server Security Password
With SANnav v2.3.x, it is now possible to change the SANnav password post installation.
SANnav Server Security password is used to encrypt SSL private key and to secure Kafka Keystore and Kafka truststore.
Prior to SANnav 2.3.x, this SANnav Server Security password cannot be changed post SANnav installation or upgrade.
With SANnav v2.3.x, this password can be changed by an authorized user after installation or upgrade completes. Invoke the SANnav console script manage- sannav-configurations.sh.

  • This script has been renamed to manage-sannav-configurations.sh in SANnav v2.3.x from sannavmanagement-console.sh in previous releases.

3.6.1.5 Nested LDAP Groups

  • With SANnav v2.3.x, it is now possible to fetch SANnav Group names (Authentication Groups) even if they defined them in a nested fashion. This was not possible with SANnav releases prior to SANnav v2.3.x.
  • To fetch the complete hierarchy, the user can import the nested hierarchy from the topmost outer group.

3.6.1.6 MFA and SSO Support with SAML Compliant Protocol
SANnav v2.3.x now supports SAML 2.0 integration with various Identity Providers (IdP). SANnav v2.3.0 should work seamlessly with any IdP complying with SAML 2.0 REST specifications.
SANnav v2.3.0 has been specifically tested and validated with the following SAML 2.0 Identity Providers:

  • Okta
  • Microsoft Azure
  • Microsoft ADFS
  • Keycloak

3.6.2 User Management Enhancements
3.6.2.1 Email Addresses to External Authentication Users
When an external Authentication (LDAP, RADIUS, SAML2.0) is used, the user accounts are automatically created upon successful login for the first time in SANnav.
Prior to SANnav v2.3.1x, these accounts were not editable to add email addresses. This prevented these external users from receiving event notifications via email.
SANnav 2.3.1 now enables the fields Tags, Description, Email and Phone number Fields to be configured and used to forward event notifications and reports by email to those external users.
In addition, any external user may configure their own personal information (including email) under User Preferences > Personal Info UI form.
3.6.2.2 User Deletion Behavior Change
When a user is deleted from the SANnav database, the Filters that were associated with that user will be associated with the default System user.
Any other user can then save these System filters (Save As …) to retain them or delete them if no longer needed.
3.6.3 Miscellaneous Enhancements
3.6.3.1 SANnav Backup Policy and Auto Purge/Delete of SANnav Backups
A New Policy to delete/purge SANnav scheduled backups (currently on demand) is provided in SANnav v2.3.1x.Options to retain scheduled backups for 5, 10 or 15 days before purging them is provided.
This new purge schedule applies only to scheduled backups and not manually or on-demand taken backups. Those are excluded from the new purge schedule and is the reason why after migration the previous unwanted backups must be removed manually.
The time at which the backup is purged depends on the time at which it was scheduled to be taken with a possible buffer of 30 minutes. For example, if a backup was generated previously by the schedule at 3:00 PM and the purging is scheduled in five days, then the backup will get purged in five days at either 3:00 PM or 3:30 PM. This buffer is randomly added to avoid SANnav having to run all tasks at the same time.
SANnav v2.3.1x backup files will now be assigned to user (UID) sannavmgr and group (GID) sannavmgr (as opposed to root in previous releases) with Linux permissions 770 (rwxrwx—).
NOTE The backup files taken prior to SANnav v2.3.1x are upgraded and migrated however, their file permissions are left as is (that is, owned by root). It is the user’s responsibility to manually delete these backup files if they are no longer needed.
3.6.3.2 SANnav Support Save Simplification
SANnav Support Data collection provided several options when taking a Partial SANnav Support Data Capture (SSDC) (SANnav supportsave) prior to SANnav v2.3.1x.
With SANnav v2.3.1x, users will be able to select either Full or Partial SSDC for one day from the UI. All other options have been removed. Users will not have the option to select anything if taking the SSDC from the SANnav CLI console.
3.6.3.2.1 Inclusion of Summary Info in SANnav Support Data Collection (SSDC)
SANnav Support Data will include a summary file for quick and easy debugging by the support team. The name of this summary file will have information embedded in it as shown below:

----.tar.gz A file called sannav-summary.txt will be generated and will have general, host, memory, network, IP tables and other SANnav details included. **3.7 USF-Related SANnav Global View Features** Unified Storage Fabric (USF) is a new capability in FOS v9.2.1 and SANnav v2.3.1x, enabling the deployment of IP Storage (IPS) along with FC Storage. IPS services include support for iSCSI, NVMe/TCP, and NAS. It has the advantage of the performance, reliability, and security of the standard FC SAN while consolidating and simplifying management. Additionally, it leverages the existing investments in FC and IP Networks and enhances the performance and reliability of the IPS. In SANnav Global View v2.3.1x, there are no operations or workflows to configure or discover IPS Fabrics and to set up, provision or configure end- to-end device connectivity. As a result, objects such as LAG, VLANs, VRF, and static routes are not displayed in SANnav Global View. The only SANnav GV v2.3.1x features related to managing USF and IPS Fabrics are limited to the SANnav GV Inventory. Once an IPS Fabric is either created or discovered in SANnav Management Portal, then it will appear as a Fabric in the SANnav GV Fabric Inventory. There are three visible changes for IPS Fabrics in Global View Fabric and Switch Inventory views.
  • For Fabrics, a new attribute Type with values (FC or IP) has been added to the Fabrics Inventory view.
  • For Switches, a new attribute Logical Role with values (Logical FC or Logical IP) has been added to the Switch Inventory view.
  • For Chassis, a new attribute IP Capable has been added to the Chassis Inventory view.

3.8 Features Deprecated with SANnav Global View v2.3.1x
The following features are deprecated in SANnav v2.3.1x. Deprecated in this context means that the feature is still available on SANnav v2.3.1x, however the feature will be removed in a future release.

  • TACACS+ server as an authentication mechanism is deprecated with SANnav v2.3.1x. It will be removed in a future release of SANnav. Customers currently using TACACS+ as an authentication mechanism are highly encouraged to migrate to a different authentication scheme.

NOTE
TACACS+ authentication to the switches has also been deprecated with FOS v9.2.1.

Chapter 4: Brocade SANnav Global View Deployment

4.1 Server Requirements
SANnav Global View v2.3.1 can be deployed either on a single bare-metal host or virtual machine (VM). The following table provide details of server requirements.

Maximum SANnav
Management Portal
Instances Supported| Operating System| Host Type| Minimum
vCPU| Memory| Hard Disk
---|---|---|---|---|---
20| RHEL 8.8, 9.2| Bare metal or VMware ESX 8.0 VM
Bare Metal/HyperV Windows
Server 2022 VM| 16 vCPUs| 32 GB|

  • RHEL 8.2, 8.3, 8.5, 8.6, 8.7, 8.9, 8.10 9.3, 9.4 are not officially supported but installation and running SANnav on these versions is allowed upon user acceptance with conditional support. Note that RHEL 8.10 and 9.4 will be available sometime in May 2024, after SANnav v2.3.1a is GA.
  • RHEL 7.9, 8.0, 8.1, 9.0 and 9.1 are not supported; the installation script exits if RHEL 7.9/8.0/8.1 or 9.0/9.1 are running on the SANnav host.
  • ESXi 8.0 is recommended. SANnav v2.3.x has not been validated with ESXi 7.x but installation should work.
  • The recommended CPU speed is 2000 MHz. Running SANnav with lower CPU speed may result in lower performance.
  • The recommended number of physical CPU sockets is two.

4.2 Client Requirements
The latest versions of the following web browsers are supported for a SANnav Global View v2.3.1 client:

  • Chrome (Windows, Linux, MacOS)
  • Firefox (Windows, Linux)
  • Edge (W indows)

4.3 Software Upgrade
Refer to the Upgrade and Migration Overview section of the Brocade SANnav Global View Installation and Migration Guide for complete details.
Supported Upgrade and Migration Paths to SANnav Global View v2.3.0a:

Current Version New Version Supported? Comments
SANnav 2.1.x and earlier SANnav v2.3.1a No Unsupported releases as per

Brocade support policy.
SANnav v2.2.0x| SANnav v2.3.1a| No| SANnav v2.2.0 was BR GA 12/15/2021. Not a valid upgrade path to SANnav v2.3.0a (over 1 year) as per Brocade support policy. Upgrade to SANnav v2.2.2a first.
SANnav v2.2.1x| SANnav v2.3.1a| No| SANnav v2.2.1 was BR GA 06/22/2022. Not a valid upgrade path to SANnav v2.3.0a (over 1 year) as per Brocade support policy. Upgrade to SANnav v2.2.2a or v2.3.0 first.
SANnav v2.2.2/2.2.2.1| SANnav 2.3.1a| No| SANnav v2.2.2 was BR GA 10/05/2022 and SANnav v2.2.2.1 was BR GA 12/16/2022. Not a valid upgrade path to SANnav v2.3.0a (over 1 year) as per Brocade support policy. Upgrade to SANnav v2.2.2a or v2.3.0 first.
SANnav v2.2.2a| SANnav v2.3.1a| No| Upgrade to SANnav v2.3.0x first.
SANnav v2.3.0x| SANnav v2.3.1a| Yes|
SANnav v2.3.1| SANnav v2.3.1a| Yes|

  • Refer to the SANnav Global View Installation and Upgrade Guide for details before attempting SANnav GV upgrade in all deployments.

NOTE

  • Migration from SANnav v2.3.0a to v2.3.1 is not supported.
  • SANnav v2.3.1x will auto-detect the source version running and will prompt the user to proceed with the upgrade/migration on the detected path or to change the path instead.

4.3.1 Environments Running CentOS /RHEL7.9
SANnav v2.3.x does not support installation on Centos 7.9 or RHEL 7.9.
Since there is no direct way to upgrade the operating system to a SANnav v2.3.x supported OS (RHEL 8.8 or 9.2), the following steps for upgrading/migrating to SANnav v2.3.x should be followed:

  • Take a backup of source SANnav version (e.g. v2.2.2x).
  • Perform a clean and fresh installation of SANnav v2.2.2x on a VM running a supported RHEL version supported by both source and target (e.g. SANnav v2.3.1 on RHEL 8.8).
  • Restore the backup taken previously.
  • Rehost the SANnav license if required (if the server has a new MAC address).
  • Perform the upgrade/migration to SANnav v2.3.1x as documented in section 4.3.

Chapter 5: Licensing

The Brocade SANnav Global View offering enables visibility across one or more Brocade SANnav Management Portal instances.

Product Offerings Description
Brocade SANnav Global View Enables comprehensive visibility across one or

more Brocade SANnav Management Portal instances.

SANnav Global View uses a subscription-based licensing model, which allows the product to function for the duration purchased. The SANnav Global View license must be renewed and installed in a timely manner to keep the product functioning without disruption.
5.1 Removal of Trial Period
SANnav Global View v2.3.x no longer provides a trial period built into the product, which allows the product to be used for a specific duration from the day of installation, without requiring a license.
Customers wanting to trial the SANnav product may do so with previous versions of SANnav as follows:

  • SANnav v2.2.1.x and v2.2.2.x have a 30-Day Trial period embedded.

5.2 Removal of 30-Day Grace Period (Available after License Expiration)
The SANnav Global View license 30-day grace period (available after license expiration) is now removed in SANnav v2.3.x.
With SANnav v2.3.x, when the license expires, the functionality will be restricted following the expiration date. A user will no longer be allowed to login to the server from the UI.
The SANnav server will continue to run and monitor the environment, but the UI will not be available (except for the ability to install a new license).
5.3 New License File Expiration Date
Beginning with SANnav v2.3.x, the SANnav license file (license.xml) must be applied to the SANnav server within 30 days of creation of the SANnav license file.

  • This 30-day expiration is completely independent of the SANnav subscription expiration date.

Refer to the SANnav Global View v2.3.x Installation and Upgrade Guide or the Licensing section of the SANnav Global View v2.3.0 User Guide for details on how to regenerate the SANnav license XML file and how to apply it to the SANnav server should this happen.
5.4 Export Renewal Request
With SANnav v2.3.x, a user may Export (download) any valid SANnav License information into a local client file. This helps customers and OEMs with ordering a SANnav license renewal for the current license.
User may export the current Active, Active (Released) or Expired SANnav license details to renew the current license.
The Export Renewal Request menu will show the following:

  • Current License Expiration Date

  • Renewal License Start Date (one day after the current expiration)

  • Renewal License End Date: by default, this is set to one year after the Renewal Start Date, but the user can change it to any arbitrary date in the future (duration must be between 60 days and seven years).
    – SANnav calculates the number of days between the start and end renewal dates in days (renewal end – renewal start, expressed in days)

  • The Export Renewal Request will download and generate a file (on the client specified browser default Download Folder) containing all the relevant information for the customer to request the renewal quote.

  • SANnav will generate a new SRV (SANnav Renewal Verification) Code as part of the Export Renewal Request to be used when placing an order for a license renewal.
    – Example SRV Code – SRVS999D0777FMX12345

Refer to the Licensing section of the SANnav Global View v2.3.x User Guide for details on how to export the License Renewal Request file from the SANnav UI.

Chapter 6: Scalability

6.1 SANnav Global View v2.3.0 Scalability

Feature Scalability Limit

Maximum number of SANnav Management Portal instances supported per SANnav
Global View| 20*
Maximum number of SANnav Global View server data collections stored in a SANnavGlobal View server| 5
Number of concurrent users per SANnav Global View server| 25

*SANnav Global View v2.3.x supports 20 SANnav Management Portals or up to 120,000 ports.
NOTE
There is no imposed limit on the number of SANnav Management Portal instances that can be monitored by an instance of SANnav Global View. However, the number of SANnav Management Portal instances that can be monitored by an instance of SANnav Global View is subject to tested/supported limits in each release.

Chapter 7: Important Notes

7.1 General

  • The network latency between a SANnav Global View server and the SANnav Management Portal servers it is managing must not exceed 100ms. If the latency is higher than 100 ms, then communication time-outs may occur and cause undesirable behavior.
  • Cockpit web console for Linux cannot co-exist with SANnav GV.
  • SE Linux is not supported (Enforcing and Permissive).
  • SANnav is expected to be installed and run on a dedicated host. If any other application is installed on the host, it is mandatory to uninstall it before starting the SANnav installation.
  • Disaster Recovery (DR) is not supported for SANnav Global View (all deployments).
  • SANnav uses a set of ports for internal communication and documented in the SANnav Global View Installation and Migration Guide. Doing so will result in the SANnav server not starting properly.
  • When migrating to SANnav GV v2.3.0 it is recommended that you take a backup of the current SANnav installation and generate a full support data collection before proceeding with the migration process.
  • Backups taken from a CLI script cannot be used for restoring the data. Users are required to always collect SANnav backups through the SANnav client.
  • If any of the backup files are moved, renamed, or deleted manually from the file system then SANnav will not show these files in the Outputs page.
  • When triggering on demand SANnav backup when the disk is running more than 70% of the filesystem the backup fails with the following message: Something went wrong. Try again later. If this happens, please check the corresponding application event in the fault management which will show the exact reason of the failure.
  • Migration from SANnav v2.2.2x or v2.3.0 to v2.3.1 will fail when at least one of the following conditions are encountered:
    1. In SANnav versions prior to v2.2.1, SANnav docker home path was customized to something other than the default path of /var/lib, then later upgraded to 2.2.1 or 2.2.2x or 2.3.0 with this customized path, and then migration to v2.3.1 was attempted.
    2. Backup from a SANnav server having a different docker home path than the current SANnav server is restored and then migration to v2.3.1 is attempted e.g. backup from an OVA (which has default docker home path) is restored on a server with custom docker home path.
    Please refer to the TSB TSB-2024-291-A for more information including the workaround and recovery.

7.2 Firewall Configuration

  • When RHEL OS boots, the firewalld backend defaults to using nftables instead of iptables. The current version of Docker used by the SANnav Global View server does not have native support for nftables. Therefore, it is mandatory to change the firewall backend to use iptables instead of nftables. Follow the steps below to configure firewalld for this purpose:
    1. Disable masquerade.
    Ensure masquerade is turned off in the firewalld configuration using the following command:
    firewall-cmd –zone= –remove-masquerade –permanent
    Where is listed in the output of the command firewall- cmd –list-all
    2. Change the firewall backend:

    • Stop the firewalld using the command systemctl stop firewalld.
    • Edit the firewalld configuration using the command vi /etc/firewalld/firewalld.conf and change the FirewallBackend=nftables to FirewallBackend=iptables.
    • Start the firewalld using the command systemctl start firewalld.
    • Reload the firewalld using the command firewall-cmd –reload.
  • When installing SANnav GV v2.3.0 and the firewall needs to be enabled, ensure the firewalld is configured before SANnav GV installation. If the step to configure the firewall is missed or omitted before starting the SANnav GV
    server. If this happens, use the following procedure to resolve the network reachability issue:
    – Stop the SANnav GV server using the script stop-sannav.sh present in the

    /bin folder. – Stop the Docker using the command systemctl stop docker. – Start the Docker using the command systemctl start docker. – Start the SANnav GV server using the script start-sannav.sh present in /bin folder.
  • If the host on which the SANnav server is installed is rebooted and the firewall was enabled in that host, then the reboot will clear the firewall rules added by SANnav during installation. It is mandatory to run the command below before restarting the SANnav server to re-insert all the missing firewall rules:
    – systemctl restart sannaviptablesetup.service

  • When migrating from previous releases to SANnav v2.3.0, if a custom port is used for internal SFTP/SCP, make sure that this port is not part of the required ports list in the installation guide. If the custom port is in the required ports list, change this port to any other free port using the change-internal-ssh-port.sh script before starting the migration.

  • SANnav product is designed to use firewalld/iptables to block external access to ports used for internal communications. If firewalld/iptables is not used, internally used ports will be exposed and may be reported as vulnerable by security scanning software. This note covers all SANnav versions and CSI patches.

Chapter 8: Defects

8.1 Known Issues in SANnav Global View v2.3.1

Defect ID Description
SANN-147120 An incorrect warning message is displayed when replace-

sannavcertificates.sh script is used to replace
the server certificate.

8.2 Defects Closed with Code Change in SANnav Global View v2.3.1

Defect ID Description
SANN-139712 Unable to log into SANnav client as proxy service does not start.
SANN-146623 Events and notifications related to server disk space usage are

not shown in SANnav
SANN-147105| Unable to send email notifications.

8.3 Defects Closed without Code Change in SANnav Global View v2.3.1

Defect ID Description
SANN-142806 Host Health score computation is inaccurate for the resiliency

check rule.
 SANN-142808| Host Health score computation is inaccurate for the redundancy check rule.

8.4 Defects Closed with Code Change in SANnav Global View v2.3.1a

Defect ID Description
SANN-148924 Migration fails when upgrading SANnav 2.2.2.1 to SANnav 2.3.1.
SANN-149485 Scheduled backup fails after upgrading to SANnav v2.3.1
SANN-148740 Fetching AD LDAP group times out during the search.

Revision History

Version Summary of Changes Publication date
1 Initial version of Brocade SANnav Global View v2.3.1a Release Notes.

4/26/2024

References

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>

Related Manuals