BROADCOM SANnav Global View Management Portal User Guide
- June 6, 2024
- BROADCOM
Table of Contents
- SANnav Global View Management Portal
- Chapter 1: Preface
- Chapter 2: Locate Product Manuals and Release Notes
- Chapter 3: Release Contents
- Chapter 4: Brocade SANnav Global View Deployment
- Chapter 5: Licensing
- Chapter 6: Scalability
- Chapter 7: Important Notes
- Chapter 8: Defects
- Revision History
- References
- Read User Manual Online (PDF format)
- Download This Manual (PDF format)
SANnav™ 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:
- Go to www.broadcom.com, click Login, and enter your username and password.
- 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.
- The list of documents will be listed under Documentation tab in the search result screen as shown below:
2.2 Locate Product Manuals and Release Notes on the Support Portal
Complete the following steps to locate product manuals on the support portal:
- Go to support.broadcom.com, click Login, and enter your username and password.
- If you do not have an account, click Register to set up your account.
- 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:
- 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
Whereis 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
- Broadcom Inc. | Connecting Everything
- Home - Support Portal - Broadcom support portal
- Broadcom Inc. | Connecting Everything
- How to Contact Brocade Support