SANnavMP-231a-RN-v4

SANnav™ Management Portal v2.3.
1a
SANnav Management Portal v2.3.1a Release Notes
Version 4
Broadcom SANnavMP-231a-RN-v4
October 17, 2024
SANnav™ Management Portal v2.3.1a SANnav Management Portal v2.3.1a Release Notes
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.
2
Table of Contents
Chapter 1: Preface .............................................................................................................................. 5

1.1 Contact Technical Support for your Brocade® Product .................................................................................. 5
1.2 Related Documentation ...................................................................................................................................... 6
Chapter 2: Locate Product Manuals and Release Notes ................................................................. 7

2.1 Locate Product Manuals on Broadcom.com .................................................................................................... 7
2.2 Locate Product Manuals and Release Notes on the Support Portal ............................................................. 7
2.3 Document Feedback ........................................................................................................................................... 8
Chapter 3: Release Contents ............................................................................................................. 9

3.1 Brocade SANnav Management Portal v2.3.1a Release Overview .................................................................. 9
3.2 What’s New in SANnav Management Portal v2.3.1a........................................................................................ 9
3.3 What’s New in SANnav Management Portal v2.3.1.......................................................................................... 9
3.3.1 What’s New in SANnav Management Portal v2.3.0 ................................................................................... 10
3.4 New Hardware Platforms Supported in SANnav Management Portal v2.3.1x ............................................ 11
3.5 New Blades Supported in SANnav Management Portal v2.3.1x .................................................................. 11
3.6 SANnav Management Portal Server Platform Support and OS Support ..................................................... 11
3.6.1 SANnav Management Portal v2.3.1x OVA Support ................................................................................... 11
3.6.2 SANnav Management Portal v2.3.1a OS Support...................................................................................... 12
3.6.3 New Disaster Recovery (DR) Features....................................................................................................... 13
3.6.4 Other Installation and Deployment Features .............................................................................................. 13
3.6.5 FIPS-140-Enabled OS ................................................................................................................................ 14
3.6.6 SE Linux Support ........................................................................................................................................ 14
3.7 Summary of New and/or Enhanced Software Features ................................................................................ 15
3.7.1 Security and Infrastructure .......................................................................................................................... 15
3.7.2 User Management Enhancements ............................................................................................................. 17
3.7.3 Fault Management Enhancements ............................................................................................................. 17
3.7.4 Call Home Enhancements .......................................................................................................................... 19
3.7.5 Discovery .................................................................................................................................................... 21
3.7.6 Inventory ..................................................................................................................................................... 22
3.7.7 Zoning ......................................................................................................................................................... 23
3.7.8 Configuration Policy Management .............................................................................................................. 25
3.8 Flow Management ............................................................................................................................................. 25
3.8.1 SANnav v2.3.0 Flow Management Summary ............................................................................................. 25
3.8.2 SANnav v2.3.1x Flow Management Changes ............................................................................................ 26
3.9 REST Interfaces ................................................................................................................................................. 27
3.9.1 REST Interfaces .......................................................................................................................................... 27
3.9.2 Miscellaneous Enhancements .................................................................................................................... 28
3.10 USF-Related SANnav Features ........................................................................................................................ 29
3.10.1 Hardware Support for IPS ........................................................................................................................... 30
3.10.2 IPS Fabric Management in SANnav ........................................................................................................... 30
3.10.3 End-to-End IP Device Connectivity Provisioning in SANnav (Day 1) ......................................................... 30
3.10.4 Day 2 Provisioning Use Cases for IP Device Connectivity ......................................................................... 34
3.10.5 Topology Contexts for IPS Fabrics ............................................................................................................. 35
3.10.6 CLI Based Discovery of IP Devices (Not Recommended).......................................................................... 35
3.10.7 Investigating Any IO (ETH) Ports ................................................................................................................ 35
3.10.8 IPS Dashboards and Reports ..................................................................................................................... 36
3.11 Features Deprecated with SANnav Management Portal v2.3.1x .................................................................. 36
3
3.12 Features Removed from SANnav Management Portal v2.3.1x ..................................................................... 36

3.13 Important Considerations When Upgrading to SANnav v2.3.1x .................................................................. 37
3.13.1 Flow Management....................................................................................................................................... 37
3.14 SANnav Management Portal v2.3.1/2.3.1x Supported SAN Switches.......................................................... 38
3.14.1 Platform Support and FOS Support – New Policy ...................................................................................... 38
3.14.2 Hardware Platforms and FOS Support Matrix ............................................................................................ 38
Chapter 4: Brocade SANnav Management Portal Deployment ..................................................... 40

4.1 Server Requirements ........................................................................................................................................ 40
4.2 Client Requirements ......................................................................................................................................... 41
4.3 Software Upgrade.............................................................................................................................................. 41
4.3.1 Environments Running CentOS/RHEL7.9 .................................................................................................. 42
Chapter 5: Licensing ........................................................................................................................ 43

5.1 Removal of Trial Period .................................................................................................................................... 43
5.2 Removal of 30-Day Grace Period (Available after License Expiration) ....................................................... 43
5.3 New License File Expiration Date .................................................................................................................... 43
5.4 Export Renewal Request .................................................................................................................................. 44
Chapter 6: Scalability ....................................................................................................................... 45

6.1 SANnav Management Portal v2.3.1x Scalability ............................................................................................ 45
Chapter 7: Important Notes .............................................................................................................. 46

7.1 General ............................................................................................................................................................... 46
7.2 Infrastructure, Installation, and Migration ...................................................................................................... 46
7.3 Firmware Management and Support Save ..................................................................................................... 48
7.3.1 Firmware Management and TruFOS .......................................................................................................... 49
7.4 Discovery and Performance Management ..................................................................................................... 49
7.5 SANnav Backup, DR, and Support Data Collection....................................................................................... 50
7.6 SANnav Telemetry Registration with FOS ...................................................................................................... 50
7.7 SNMP and Syslog Registration with FOS ....................................................................................................... 51
Chapter 8: Security Vulnerability Fixes........................................................................................... 52
Chapter 9: Defects ............................................................................................................................ 53

9.1 Known Issues in SANnav Management Portal v2.3.1.................................................................................... 53
9.2 Defects Closed with Code Change in SANnav Management Portal v2.3.1 ................................................. 57
9.3 Defects Closed without Code Change in SANnav Management Portal v2.3.1 ........................................... 61
9.4 Defects Closed with Code Change in SANnav Management Portal v2.3.1a ............................................... 64
Revision History................................................................................................................................ 66
4
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 24x7. 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 For Severity 1 (critical) issues, call Brocade Fibre Channel
Support portal at support.broadcom.com. You must initially Networking Global Support at one of the phone numbers listed
register to gain access to the Support portal. Once registered, log at www.broadcom.com/support/fibre-channel-
on and then select Brocade Products. You can now navigate to networking/contact-brocade-support
the following sites:
 Case Management
 Software Downloads
 Licensing
 SAN Reports
 Brocade Support Link
 Training & Education
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
5
 Switch Serial Number

The switch serial number is provided on the serial number label, examples of which follow:
FT00X0054E9
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 and 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.
6
Chapter 2: Locate Product Manuals and Release Notes
2.1 Locate Product Manuals on Broadcom.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.
3. 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:
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.
7
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 [email protected]. 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.
8
Chapter 3: Release Contents
3.1 Brocade SANnav Management Portal v2.3.1a Release Overview

NOTE This Release Notes document covers SANnav Management Portal v2.3.1a. Within this document,
SANnav Management Portal might also be referred to as SANnav or SANnav MP.
 All features supported in SANnav Management Portal v2.3.1 are also supported in SANnav Management Portal
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 Management Portal v2.3.1a is a stand-alone release (full installer patch). This means that SANnav MP can
be installed without requiring any other previous version of SANnav MP installed. It is also possible to upgrade and
migrate to SANnav MP v2.3.1a directly from previous releases of SANnav MP.
 The supported upgrade and migration paths are documented in subsequent sections of this document.
3.2 What’s New in SANnav Management Portal v2.3.1a
 Support and qualification for RHEL 8.8 and 9.2 for bare metal and Virtual Machine (VM) deployments, including
Disaster Recovery (DR)
 Support and qualification of Rocky 8.9 for OVA deployments, including DR
NOTE For OVA deployments, it is mandatory to upgrade the SANnav server to Rocky Linux to 8.9 before
attempting the upgrade to SANnav v2.3.1a.
 Resolution of other important defect fixes are listed in Chapter 9 of this document.
3.3 What’s New in SANnav Management Portal 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 Discovery
 IPS Inventory
 IPS Provisioning and Configuration
 IPS Fabric creation and management
 IPS end-to-end IP device connectivity
 IPS Monitoring
 IPS Troubleshooting
 IPS Topology
 IPS Reports
9
The non-USF-related highlights are as follows:

 Deployment, OS Support, and DR enhancements such as RHEL 9.2 support and DR on bare metal platforms
 Security enhancements
 Zoning enhancements
 Inventory enhancements
 Configuration Policy Management enhancements
 Call Home enhancements
 User Management enhancements
 Fault Management enhancements
 Miscellaneous enhancements
 Flow Management changes
3.3.1 What’s New in SANnav Management Portal 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, including DR
 Security and Infrastructure: provide security features and enhancements in all areas, including SANnav server and
managing Switch and FOS security
 SANnav Licensing
 FOS Certificates Management
 FOS Firmware Platform Specific Download (PSD) Management
 Call Home
 Discovery
 Inventory: simplify device ports to enclosure mapping using host and storage mapping policies.
 Zoning: simplify day-to-day zoning tasks with new or enhanced workflows such as Zone Database snapshots and
zone policies.
 Configuration Policy Management: accelerate the deployment of new switches, hosts, and targets with enhanced
features.
 Flow Management: quickly identify issues with device ports with new IO Health and Latency widget
 Dashboards and Reports
 Events and Violations
 Topology
 UI/UX and Usability changes: enhanced overall UI/UX usability features in Inventory, Topology, Flow Management,
Dashboards, and Reporting
Defect fixes included in this release are listed in the defect tables section of this document.
10
3.4 New Hardware Platforms Supported in SANnav Management

Portal v2.3.1x
Support for the following hardware platforms has been added in SANnav Management Portal v2.3.1x.
 None
3.5 New Blades Supported in SANnav Management Portal v2.3.1x

The following new blade platforms have been added in SANnav Management Portal v2.3.1x.
 None
3.6 SANnav Management Portal Server Platform Support and OS

Support
3.6.1 SANnav Management Portal v2.3.1x OVA Support

SANnav v2.3.1x continues to support deploying SANnav Management Portal as an Open Virtual Appliance (OVA).
SANnav v2.3.1a OVA now packages Rocky Linux v8.9.
 Deployment of the OVA file is officially supported on vCenter 8.x and ESXi 8.x.
NOTE Extraction of the SANnav OVA image using vCenter 7.x should work but has not been tested or
qualified with SANnav v2.3.x.
 OVA is currently available only for SANnav Management Portal and not for SANnav Global View.
 Upgrade and migration from SANnav v2.3.0x to SANnav v2.3.1x is to be performed inline, since the OS kernel is the
same (8.x based).
NOTE For upgrade from SANnav v2.3.0 to SANnav v2.3.1a, it is recommended to upgrade the server OS to
Rocky Linux 8.9 prior to performing the inline OVA upgrade. Refer to Section 4.3 Software Upgrade.
 Upgrade and migration from SANnav v2.2.2x to SANnav v2.3.1x cannot be performed inline (disruptive OS change,
CentOS to Rocky).
 Instead of automatically starting the installation on the first login, the script install-sannav.sh must be manually
run after successfully setting up the VM. This is the same as SANnav v2.3.0.
 By default, firewalld is disabled in the OVA-deployed VM. This is the same as SANnav v2.3.0.
 A SANnav v2.3.1x OVA deployment will force a change of the OS root password at the first login. A new root
password must be entered by the user deploying SANnav v2.3.1x OVA.
 While deploying SANnav 2.3.1x OVA, if a valid DNS IP address is not available, use the following IP address:
127.0.0.1 (IPv4) or ::1 (IPv6).
ATTENTION Make sure to strictly follow the SANnav MP Installation and Upgrade Guide before attempting the
upgrade and migration from SANnav Management Portal v2.2.2x OVA to SANnav MP v2.3.1x
OVA.
11
3.6.1.1 OVA and Rocky Linux CVEs Process
While Brocade ensures that Rocky Linux CVEs on the OS are addressed at the release of SANnav v2.3.1x, it is possible
that some specific Rocky Linux 8.8/8.9 CVEs are only found and disclosed after SANnav v2.3.1x has been released and
before a patch on SANnav v2.3.1x is issued.
NOTE In the event this occurs, it is the end user’s responsibility to update Rocky Linux with OS security
patches on the SANnav server and the OS to address new CVEs. If that is not possible due to
internal constraints such as internet access and security, contact Brocade Support.
3.6.2 SANnav Management Portal v2.3.1a OS Support

SANnav Management Portal v2.3.1a is fully qualified and tested with the following versions of RHEL:
 RHEL releases 8.8 and 9.2.
NOTE When installing SANnav 2.3.1a on an untested or unqualified OS version, (RHEL 8.2, 8.3, 8.4, 8.5,
8.6, 8.7, 8.9, 8.10, 9.3, 9.4 for VM/BM) or (Rocky 8.6, 8.8, 8.10 for OVA), the installation script
displays a warning message indicating that the SANnav Management Portal installation will proceed
on an untested and unqualified OS version. Explicit end user acceptance is required for SANnav
Management Portal installation to proceed. While it may be possible to successfully install SANnav
on these OS versions, if issues occur while using SANnav it may be necessary to migrate to a fully
qualified and tested OS version and reproduce the issues to receive support.
The following table shows the various OS types and versions and the associated support in SANnav v2.3.1a cells marked
with (Blocked) indicate that the SANnav v2.3.1a installation/upgrade will not proceed and exit, while cells marked (Not
Blocked) indicate the SANnav v2.3.1a installation/upgrade will proceed with explicit user acceptance that SANnav will run
on an untested and unqualified OS Release. DR support is also shown in the table for completeness.
VM or BM (Bare
OS Type and Version OVA DR Support
Metal)
CentOS 7.9, RHEL 7.9, 8.0, 8.1, 9.0, 9.1 No (Blocked) No No (Blocked)
RHEL 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.9, 8.10, 9.3, 9.4 No (Not Blocked) No No (Not Blocked)
RHEL 8.8, 9.2 Yes No Yes - VM and BM (new)
Rocky Linux 8.9 No (Blocked) Yes Yes (OVA only)
Rocky Linux 8.6, 8.8, 8.10 No (Blocked) No (Not Blocked) No (Not Blocked)
For both Rocky and RHEL OS, the following must be set in the OS on which SANnav Management Portal server is
installed:
 Language = English
 Locale = US
Other Languages and Locales are not supported.
12
3.6.3 New Disaster Recovery (DR) Features

 DR support on bare metal (BM) servers is new in SANnav v2.3.1x. DR was only supported on VM and OVA
deployments up to SANnav v2.3.0.
 Up to SANnav v2.3.0, users needed to uninstall the entire SANnav application to remove or reset the DR
configuration in the Active server. With SANnav v2.3.1x, users can now execute the reset-dr-primary.sh script
on the Active server, which will clear all DR configurations and restart the SANnav server. In addition, the reset-dr-
primary.sh script may be executed at any time if there is a failure while setting up the Active SANnav server.
 While setting up the DR standby server, user can choose not to auto-rehost the SANnav license during a planned or
unplanned failover. This will save time while testing the planned failover to make sure DR operations work properly
should a disaster or outage happen.
 When the DR script setup-dr-standby.sh is executed, it will prompt the user for three items:
– Option to automatically rehost the SANnav license after failover (yes or no, default is no)
– The email server address
– To and from email addresses
 Email notifications on the DR standby server can now be configured, updated, and disabled after completion of the
DR setup.
– Execute the setup-dr-email-notifications.sh script after DR on the standby server setup to update
email notification settings.
ATTENTION The SANnav Management Portal Installation and Upgrade Guide, 2.3.x document provides step-
by-step procedures in eight different use cases (VM/BM or OVA, revertive failover or not,
planned, or unplanned combinations) to perform DR functions. Make sure to refer to this section
of the document before proceeding with setting up DR in SANnav MP.
3.6.4 Other Installation and Deployment Features
3.6.4.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-day 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.1, 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-self-
signed-certificates.sh
NOTE It is recommended to use Certificate Authority (CA) signed certificates instead of self-signed
certificates, and to install them on the SANnav server for the highest security protection.
ATTENTION SANnav SSL certificate expiration will impact and interrupt features such as Streaming and
Secure Syslog.
13
3.6.4.2 SANnav File System Permissions Change
With SANnav v2.3.0, all files under the SANnav installation directory had Linux permissions 775 (rwx-rwx-r-x).
With SANnav v2.3.1x, 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.6.4.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.6.4.4 Host Time Zone Check
SANnav needs a valid Time Zone set in the operating system in order to operate properly. When 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 set-
timzone <TIME_ZONE>
3.6.5 FIPS-140-Enabled OS
SANnav MP v2.3.1x is supported on FIPS-140-enabled RHEL (VM or bare metal) or Rocky (OVA). Refer to the RHEL or
Rocky-specific OS version for the exact commands to enable FIPS mode.
NOTE 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.
 On OVA deployment, FIPS-140 mode must be enabled post installation.
 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.6.6 SE Linux Support

SANnav Management Portal 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 in either Enforcing or Permissive mode 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.
ATTENTION Customers requiring SE Linux in Enforcing mode should deploy SANnav MP in OVA
environment.
14
3.7 Summary of New and/or Enhanced Software Features
3.7.1 Security and Infrastructure
3.7.1.1 Chassis Password Management for FOS maintenance Account
Up to SANnav v2.3.0, it is possible to bulk select multiple chassis and request that SANnav changes the password for the
FOS admin user on all user-selected chassis to the user-provided password.
With SANnav v2.3.1x, this functionality has been extended to support the same functionality for the FOS maintenance
user.
NOTE This feature is supported for FOS v9.1.1 or higher only.
NOTE For security reasons, changing the FOS default maintenance password the first time on a factory-
shipped chassis is not allowed from SANnav. A message will be shown asking the user to first
change the switch default maintenance account in FOS CLI before changing it with SANnav.
3.7.1.2 vCenter Account and Password Change
With SANnav v2.3.1x, it is now possible to select a single vCenter-discovered instance in SANnav and change the user
name and/or the password for SANnav to subsequently login to that vCenter instance using the new credentials. Note that
this will trigger rediscovery of the vCenter instance in SANnav. A bulk change is not allowed.
3.7.1.3 Installation and Upgrade/Migration as sudo
 Prior to SANnav v2.3.x, only the root user could install and manage the SANnav server. Users with sudo privileges
could not install, upgrade, run, or manage the SANnav server.
 With SANnav v2.3.x, users with sudo privileges can now install and manage the SANnav server. This is in addition to
the root user.
 Users with sudo privileges can install and manage the 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 add-
user-to-sannavmgr-group.sh. This script can be executed by the sudo user.
NOTE The user to be added must have sudo privileges already. This script simply adds that user to the list
of users that can manage and run SANnav.
3.7.1.4 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.
 For security reasons, the sannavmgr user cannot be used for remote SSH login to the SANnav server.
 During SANnav v2.3.x installation, upgrade, or migration, the sannavmgr user with UID/GID 56900 will be created.
Make sure it is available prior to starting the first-time installation of SANnav v2.3.1.
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.
15
 UID 1000 was required in prior SANnav releases, and is still required for SANnav v2.3.x to receive streams from FOS.
SANnav will create UID/GID 1000 with the sannavstreaming user name/group name. If UID/GID are occupied by
another user name and group name, then whatever user name/group name is associated with UID/GID 1000 will be
used.
3.7.1.5 Important OS-Level Customization for User sannavmgr (UID 56900)
 The SANnav server needs ports lower than 1024 to run some of its services.
– Due to this, the Linux ip_unprivileged_port_start parameter is set to 0 to allow sannavmgr to run services on
ports lower than 1024.
3.7.1.6 Change SANnav Server Security Password
With SANnav v2.3.x, it is now possible to change the SANnav password after installation.
The SANnav Server Security password is used to encrypt the SSL private key and to secure Kafka Keystore and Kafka
truststore.
Prior to SANnav v2.3.x, this SANnav Server Security password cannot be changed after SANnav installation or upgrade.
With SANnav v2.3.x, this password can be changed by an authorized and privileged user after installation or upgrade
completes. Invoke the SANnav console script manage-sannav-configurations.sh.
 This script has been renamed to manage-sannav-configuration.sh in SANnav v2.3.x, from sannav-
management-consol.sh in previous releases.
3.7.1.7 Nested LDAP Groups
 With SANnav v2.3.x, it is now possible to fetch SANnav Groups names (Authentication Groups) even if they are
defined 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.7.1.8 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.x should work
seamlessly with any IdP complying with SAML 2.0 REST specifications.
SANnav v2.3.x has been specifically tested and validated with the following SAML Identity Providers:
 Okta
 Microsoft Azure (SANnav MP and GV are now available in the Azure Gallery)
 Microsoft ADFS
 Keycloak
3.7.1.9 Secure Syslog Registration with FOS
Since FOS v8.2.x, there is validation/authentication of the host name (FQDN or IP address – IPv4 or IPv6) with HTTPS
certificates on FOS. SANnav v2.3.x secure syslog reception will ensure the following occur:
 Third-party or self-signed HTTPS certificates are used when registering the following:
– FQDN
– IPv4 or IPv6 addresses
16
 For secure syslog to work properly with custom (third-party signed) certificates, a FQDN must be configured on the
SANnav host server before SANnav installation.
– If the FQDN has not been configured on the SANnav server, then SANnav falls back to using the IP address.
 After upgrade and migration, a previously registered secure syslog with an IPv4 or IPv6 address will be replaced with
the SANnav FQDN if an FQDN was defined for the SANnav host.
 If a switch (SwitchA) is discovered in a SANnav server (ServerA) and if an attempt is made to discover SwitchA in
another SANnav server (Server B), then the syslog HTTPS certificate will be automatically imported in ServerB, and
secure syslog will no longer be functional in ServerA.
3.7.2 User Management Enhancements
3.7.2.1 Email Addresses to External Authentication Users
When an external Authentication (LDAP, RADIUS, SAML) is used, the user accounts are automatically created upon
successful login for the first time in SANnav. This applies to user names only; passwords are not stored in SANnav for
external users.
Prior to SANnav v2.3.1x, email addresses could not be added to these accounts. This prevented external users from
receiving event notifications via email.
SANnav 2.3.1x now enables the 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, in the form found at User
Preferences > Personal Info UI.
3.7.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 using Save As… to retain them or delete them if they are no longer
needed.
3.7.3 Fault Management Enhancements
3.7.3.1 Default Filter to Exclude Unacknowledged SANnav Application Events
Prior to SANnav v2.3.1x, SANnav events cannot be suppressed using an Event Action Policy. This may cause unwanted
events to be displayed when too many such SANnav events are triggered. Most of the time, these messages should be
suppressed.
In the absence of the suppress action, SANnav 2.3.1x provides an out-of-the-box default filter that excludes all
acknowledged events. The default filter is called Exclude Unacknowledged Events and can be seen under the Filters
view.
Users can now create a new Event Action Policy (EAP) to acknowledge unwanted SANnav events by using this new
default Exclude Unacknowledged Events filter when creating the EAP.
3.7.3.2 SANnav Events Message ID Reference View
Under the SANnav > Fault Management menu tab, a new entry called SANnav Events has been added. This view
provides a reference table with Message ID, Severity, Feature, and Event Summary fields.
The intent of this new reference table is to help users to easily search and identify the correct Message IDs to be used
when creating and updating Event filters and Event Action Policies.
17
3.7.3.3 Custom Description Forwarding Filter and SANnav Custom Description
With FOS, certain traps do not contain the key fields Severity and Description. They are left empty in the FOS MIB
definition. These traps are as follows:
 connUnitPortStatusChange
 swStateChangeTrap
 swPortMoveTrap
 fruStatusChanged
 fruHistoryTrap
 swFabricSegmentTrap
 swDeviceStatusTrap
 swZoneConfigChangeTrap
 cpStatusChanged
 swFault
When SANnav receives these kinds of traps, it will customize the Severity and the Description attributes before displaying
them in the SANnav Events list view. However, when using the SNMP Forwarding feature of SANnav to forward such
traps to an external SNMP collector system, they will be sent as is (raw).
In SANnav v2.3.1x, the Description customization prepends the text SANnav custom description: at the beginning
of the description field to indicate that these have been customized by SANnav.
In addition, an information message (i) has been added when creating a new Forwarding Filter next to the Description
field to clarify that the user should use the OID field instead of description for these types of traps.
This information message appears when user creates a Forwarding Filter, and add a Forwarding Rules where the
Category is set to Switch Event and the Event Column is set to Description. In this case the (i) message will appear as
follows:
3.7.3.4 Event Filter Logic Simplification
Prior to SANnav v2.3.1x, the logic for filters when multiple Category values are selected always resulted in zero results.
For example, if a user created a filter with two different Categories and two different Event Columns for the filter, the filter
would yield no results prior to SANnav v2.3.1x. This is because prior to SANnav v2.3.1x, rules created with multiple
Categories resulted in zero records fetched as per SANnav logic.
SANnav v2.3.1x uses a new logic to group by Categories first and then group by the Event Columns and uses an OR
operation in between to yield the desired/expected results.
18
3.7.3.5 Event Action Policy Filter Behavior Modification
In the Event Action Policy filters, a new message has been added to explain the new behavior of the EAP filter with
regards to Exclude behavior as follows:
Include and exclude rules are applied per category. All events that fulfill the
criteria defined by Include rules will be selected first, then events fulfilling
the criteria defined by the Exclude rules will be removed from that Include rule.
The All option for Category is deprecated as its use may lead to unexpected results
in some situations. Refer to the SANnav Management Portal User Guide for details.
3.7.3.6 Trap Forwarding Enhancements
Since raw traps are used for forwarding, SANnav versions prior to SANnav v2.3.1x default to Info severity if the SNMP
trap sent by FOS does not have a severity associated with it. This behavior results in traps not being forwarded if a filter is
used based on custom severity.
SANnav v2.3.1x enhances the SNMP trap forwarding to take the custom severity into account while applying forwarding
filters.
3.7.4 Call Home Enhancements
3.7.4.1 IBM Call Home
3.7.4.1.1 New Customer Details (First and Last Name)
The IBM Call Home Center in SANnav 2.3.0x has been enhanced to add the following customer details:
 First Name
 Last Name
 Phone Number
 Alternate Phone Number
 Email
 SANnav server Location
In SANnav v2.3.1x the fields First Name and Last name above have been enhanced to support the following special
characters .\_-!@#$%^() and the white space “ “ character.
3.7.4.1.2 Test Call Home to Include all Three Chassis Serial Numbers
In SANnav v2.3.1x, the IBM Test Call Home email has been modified to include all three Chassis Serial Numbers in the
body of the email, so it is now the same as the production Call Home email:
 Factory Serial Number
 Supplier Serial Number
 Chassis Serial Number (this field has also been added the reproduction email)
19
3.7.4.2 Dell Secure Connect Gateway (SCG) (Dell SRS Replacement)
Starting with SANnav v2.3.1x onwards, Dell SRS will no longer be supported. It is replaced by a new Dell SCG software.
SRS will be renamed to SCG in the Dell Technologies Call Home details page in the SANnav UI and in associated
SANnav application events.
When upgrading and migrating from prior versions to SANnav v2.3.1x, the SRS gateway details previously configured
(including the chassis that were associated with the SRS center) will be preserved and associated with a new SCG entry
instead. If modifications need to be made after upgrade and migration, they may be done form the Dell SCG details page.
ATTENTION SANnav v2.3.1x has been tested and validated with SCG version 5.20.00.10. Other releases
have not been tested with SANnav v2.3.1x and therefore are not supported by SANnav v2.3.1x.
3.7.4.2.1 Dell SCG Keep Alive
In addition to migrating from Dell SRS to Dell SCG, SANnav v2.3.1 adds a keep alive support for Dell Technologies SCG
Call Home Center.
The Keep Alive RESTful services from SCG allow the SANnav management application to ping SCG every 15 minutes
using secure RESTful services. SCG creates an alarm if the Keep Alive update is not updated within the threshold period
This feature is useful for monitoring functioning of the SCG Call Home Center.
3.7.4.3 NetApp Call Home
NetApp’s automation case creation tool relies on the Chassis Factory Serial Number in the subject line to check for valid
entitlement. Up to SANnav v2.3.0, the title of the email for NetApp Call Home Center included the WWN Factory Serial
Number instead.
SANnav v2.3.1x now includes the Chassis Factory Serial Number in the email subject line for the NetApp Call Home
Center. Other fields in the subject are untouched.
In addition to updating the subject line, the following Serial Number is also added to the body of the NetApp Call Home
email:
 Chassis Serial Number
NOTE The Factory Serial Number and Supplier Serial Number were already in the email.
3.7.4.4 License Serial Number in Call Home Email (Brocade and NetApp only)
The SANnav License Serial Number will be included in the Call Home email for Brocade and NetApp Call Home Centers.
A new entry in the body of the email will be added under the Management Server Information section of the email follows:
 Management Server Information
– Server Name = sannav-portal-v231
– Server IP = <IP Address>
– Server Version = 2.3.1 build <xyz>
– SANnav Active License Serial Number : <Serial Number>
3.7.4.5 Call Home Status Indication by Last Notification Sent
A new column has been added in each Call Home Center list page called Last Notification, which will indicate when the
last notification was sent from SANnav to the Call Home Center.
The intent of this new column is to help customers determine if the Call Home Center is working properly.
20
3.7.5 Discovery
ATTENTION
 FOS v9.2.1 has introduced a new authentication mechanism for machine-to-machine interfaces
using an OAuth protocol Federated Identify Provider (Azure). SANnav v2.3.1x does not use this
method of authentication and continues to use a traditional user name and password to discover
fabrics.
 Fabric Discovery with RSA-based FOS user names and passwords are not supported in SANnav.
Specifying an RSA-based user name and password for the seed switch in the Fabric Discovery
dialog will result in SANnav discovery failing with the following message:
seed switch authentication failed.
3.7.5.1 Display SNMP Auth and Priv Protocols Details
In the SANnav > SAN Monitoring > Fabric Discovery list page, which shows the list of Discovered Fabrics, clicking on
the Fabric name will show the details of the Fabric with a table showing the list of Logical Switches in this Fabric. In this
list, two new columns are added in SANnav v2.3.1x:
 Auth Protocol value (e.g. HMAC_SHA512)
 Priv Protocol value (e.g. CFB_AES256)
3.7.5.2 Display SNMP Authentication Failures
Prior to SANnav 2.3.1x, during Fabric discovery, SANnav checks if the SNMP account to be used by SANnav exists on
the switch.
If the SNMP user does not exist on the switch, SANnav adds it to the switch using SANnav default predefined credentials,
which are not visible to the user.
If the SNMP user already exists on the switch, SANnav does not overwrite the existing configuration using its default
predefined credentials on the switch if the SNMP credentials do not match. Because of this mismatch all of the SNMP
communication fails.
To resolve this issue, SANnav v2.3.1x will first detect if there is an SNMP credentials mismatch. If a mismatch is found
between the SANnav predefined configuration and the switch, SANnav will overwrite the SNMP configuration on the
switch if the SNMP Manual configuration is not selected and a firmware download is not in progress on that switch.
In some cases, the SNMP communication may fail due to the SNMP access control and security level security settings on
the switch. To detect these problems, SANnav will check the SNMP access control and security level when the FOS
version on the switch is equal to or higher than 8.2.1b, since FOS does not support this for older versions.
3.7.5.3 Restrict SANnav Versions Allowed to Discover Specific FOS Versions
Prior to FOS v9.2.1, FOS allowed SANnav to discover a switch no matter what the SANnav version is. There was no
version restriction from FOS to allow SANnav to discover a given switch.
Starting with FOS v9.2.1 and higher, FOS will only allow discovery by specific SANnav versions. Attempts to discover the
switch with a non-supported SANnav version will be denied by FOS v9.2.1 and later.
For example, FOS v9.2.1 can only be discovered by SANnav v2.3.1x or higher. Attempting to discover a FOS v9.2.1
switch with SANnav v2.3.0 or v2.2.2xa will be rejected by FOS v9.2.1. Refer to the FOS Administration Guide for more
information.
3.7.5.4 More Prominent Message When Deleting a Logical Fabric from SANnav
When deleting a Logical Fabric of any type from SANnav 2.3.1x, the user will be shown a more prominent message with a
red triangle and an explanation of the side effects of deleting the Logical Fabric from SANnav.
21
3.7.5.5 Customized SNMP account for SANnav Discovery issue
With SANnav v2.3.0x and SANnav v2.3.1x there is a known issue if a user checks the “SNMP Manual Configuration”
checkbox during the first time discovery of the fabric or after discovery of the fabric.
The issue is that once the fabric is successfully discovered, if the user goes back to the Fabric Discovery dialog, the
“SNMP Manual Configuration” checkbox shows as “unchecked” leading the user to believe the Fabric was discovered
using SANnav “automatic” SNMP credentials, which is not the case.
3.7.6 Inventory
3.7.6.1 Device Port to Device Enclosure Mapping Policy Enhancement
This feature was introduced in SANnav v2.3.0 to define policies to map device ports (host ports and storage ports) to
enclosures (hosts and storage) in a stateless and idempotent manner (can be run multiple times and at any time). The
policy contains rules to determine this mapping at runtime.
In the menu SANnav > SAN Monitoring > Inventory Settings, a tab called Host and Storage Naming Policy was
introduced in SANnav v2.3.0 to control and manage the device ports to enclosure mapping formation.
In this tab there are four main items:
1. SANnav Automatic Host Enclosure
2. Automatic Storage Enclosure
– These two items determine whether the SANnav automatic device port to enclosure mapping formation should be
enabled or not. By default, Host Auto Enclosure is enabled and Auto Storage Enclosure is disabled.
3. Manual Host Naming Policy
4. Manual Storage Naming Policy
– These two items allow to control how SANnav should determine the mapping between the device ports and their
associated container enclosures using specific naming components, such as zone alias, Node Symbolic Name,
and Port Symbolic Name, and regular expressions (regex grammar) to pick only certain characters from the value
of the component.
– In SANnav v2.3.1x, under each item Manual Host Naming Policy and Manual Storage Naming Policy, a new
option menu called Case Conversion with values None, Uppercase, Lowercase is added to control the case of the
formed enclosure name.
3.7.6.2 Enclosure Map/Un-map REST API Change
Prior to SANnav v2.3.1x, when all device ports are removed after performing an un-map from the manual enclosures
using a REST call, the empty enclosures were not deleted. When this same operation is performed from the SANnav UI,
the enclosures are deleted.
With SANnav v2.3.1x, after either map or un-map operation through REST URL, empty enclosures will be deleted so that
REST and UI operations are consistent in behavior.
3.7.6.3 Offline Device Ports and Manual Enclosures
When a device port associated with a manual enclosure goes offline and either tracking is disabled or changes are
accepted, releases prior to SANnav v2.3.1x will remove the association between the device port and the manually formed
enclosure. The user must manually re-map the device port to the manual enclosure again when the device port comes
back online.
SANnav v2.3.1x stores the mapping between the device port and the manual enclosure in the offline device ports view
when the device port goes offline, regardless of whether tracking changes is on or off. When the device port returns
22
online, SANnav v2.3.1x will remove the corresponding offline device port mapping entry, and the device port is
automatically mapped to the manual enclosure present in the offline device port mapping.
This generic enhancement addresses all use cases regardless of device port connectivity to either a Native Switch or an
AG switch.
NOTE If a given device port(s) went offline before upgrade and migration to SANnav v2.3.1x and later came
back online after the upgrade and migration to 2.3.1x was done, then those ports must be manually
re-mapped after upgrade and migration to SANnav v2.3.1x.
3.7.7 Zoning
SANnav v2.3.0 offered several enhancements and new features related to effectively managing Zoning. These features
may be used whether automation is used to manage Zoning in customer environment or not.
SANnav v2.3.0 Zoning provides the following key features to manage SAN Zoning effectively:
 Manage up to five Zone DB snapshots of the entire Zone Database of a Fabric in SANnav.
 Provide new option to create I-* or *-T Zoning Policy with multiple Principals, as opposed to one peer zone per
principal as is the case up to SANnav v2.2.2.
 Enhance Policy-Based Zoning to provide the option to only save to Defined Zone Config (no Activation).
 Provide new Zoning System Policy.
 Display affected Zone tree entities when deleting Zones or Zone Aliases.
SANnav v2.3.1x adds more features and enhancements to the existing Zoning introduced in SANnav v2.3.0 with the
enhancements listed in the next subsections.
3.7.7.1 Fabric Zone DB Snapshots Enhancements
There are two enhancements implemented for Zone Database snapshots in SANnav v2.3.1x.
The first enhancement increases the limit of the number of snapshots for a given Fabric from 5 to 20 in SANnav v2.3.1x
with the same behavior. The oldest snapshot is overwritten when the limit is reached.
The second enhancement is a behavior change from SANnav v2.3.0 when restoring a zone Database snapshot in
SANnav v2.3.1x as explained below:
 In SANnav 2.3.0, restoring a snapshot with an effective configuration involves the following two steps:
1. Disable the effective zone configuration in the fabric.
2. Submit the snapshot content to replace the zone database and activate the zone configuration from the
snapshot.
This approach could result in momentary traffic disruption due to step 1, as the default zone policies can come into effect
between steps 1 and 2.
With SANnav v2.3.1x, the Fabric Zone DB snapshot restore operation with the activate option checked will not disable the
fabric’s effective zone configuration.
CAUTION
 Take a snapshot of the Fabric Zoning Database when the Effective and Defined zone
configurations are identical, that is when the Defined Zone Configuration is in the Defined (Copy)
state. If the Defined configuration is not the same as the Effective configuration, that is in Defined
(Modified) state, then care must be taken when restoring this snapshot in the future. The Defined
configuration is always used to restore the Effective configuration in the Fabric no matter its state,
Defined (Copy) or, Defined (Modified).
23
 Users are not allowed to edit a Fabric Zoning Database snapshot when restoring the Fabric
Zoning Database from an existing snapshot. Restoring the Fabric Zoning Database from a user
modified snapshot content (JSON backup file) is not supported and may void support from
Broadcom.
3.7.7.2 Bulk Deletion of Zone Configurations
When decommissioning large arrays and cleaning up the zone databases for multiple Fabrics, there is a need to be able
to delete multiple Zone Configurations at one time. This has been added in SANnav v2.3.1x.
This operation is only supported from the Zone Configuration view, not the Zone Inventory view, and is only supported
when the seed switch is running FOS version 9.0 or higher.
3.7.7.3 Zoning Policy Enhancements
New Zoning preferences were introduced in SANnav v2.3.0 which allowed users to define system-wide behavior and
choices for managing Fabric Zoning with SANnav. The following five new items are available in SANnav v2.3.0:
 Allow Mixed Zones creation/edit/deletion
 Allow for preferred default zone type on creation (Standard or Peer)
 Allow for preferred Zone Policy default creation Type (I-T, I-*, *-T)
 Zone naming scheme
 Zone Alias naming scheme
With SANnav v2.3.1x for both the zone naming policy and the zone alias naming schemes, a new Case Conversion
option menu called Case Conversion with the values None, Uppercase, Lowercase is added to control the case of the
formed zone alias and/or zone names.
3.7.7.4 Import Zone Alias Enhancements (Conflict Resolution)
Importing zone aliases from a CSV file involves creating new zone aliases and modifying existing zone aliases. The
workflow up to SANnav v2.3.0 may lead to unintended behavior at times, as conflicts may occur when importing zone
aliases that already exist in the fabric zone database.
To resolve this side effect, the import zone aliases workflow has been changed in SANnav 2.3.1x as follows:
 Allow importing zone aliases that do not exist in the live fabric
 Show conflicting zone aliases and skip importing them, and proceed with importing other aliases from the CSV file
When conflicts are detected, a new UI will show the conflicts to the user when importing the CSV file. SANnav will not
attempt to merge or resolve conflicts automatically. Instead, the user will have to decide to either skip the conflicts and
resolve them through either changing the zone aliases in the Fabric zone database using zone alias operations in
SANnav if the zone aliases menu if CSV file is correct, or to modify the zone aliases in the CSV file and re-import it again
if the zone aliases in fabric zone database are correct.
3.7.7.4.1 Import Aliases into SANnav That Were Exported from Brocade Network Advisor (BNA)
When importing the aliases that are exported from BNA, the import will fail with the following message in SANnav v2.3.1x:
Importing zone aliases failed. Invalid file header. The header should match
"Member WWN / D,P", "Zone Alias", "Tags", "Description"
To import aliases exported from BNA, the file exported from BNA must be modified to include the following header (first
row in the CSV file exported from BNA). Then proceed with importing the file into SANnav v2.3.1x:
"Member WWN / D,P", "Zone Alias", "Tags", "Description"
24
3.7.7.5 Zoning UI to Bring User Selection in Context
This is a minor usability enhancement where, in environments with large zone sets, it is difficult to read the details of a
Zone when using the Show Details for a Zone.
In SANnav v2.3.1x, the UI to Show Details of a Zone has now been changed to only show the zones selected by the user.
In SANnav v2.3.0, all zones were shown, even those not selected by the user, which caused a usability issue when the
list of entities was large.
3.7.8 Configuration Policy Management

FOS v9.2.0 introduced an Adaptive Quiet Time feature to reduce the number of MAPS violations raised by FOS over a
period. Refer to the FOS 9.2.1 Administration Guide for more details on this feature.
This feature was not supported in SANnav v2.3.0.
SANnav v2.3.1x supports this feature by introducing a new option to select Adaptive Quiet Time under the Configuration
Blocks for Chassis. A new option to select Adaptive Quiet Time is now available.
NOTE The Quiet Time at the Logical Switch level for FOS versions prior to FOS 9.2.0 is still supported. The
Configuration Policy Manager feature contains a data model to derive which FOS version supports
the new Adaptive Quiet Time and which do not.
3.8 Flow Management

The SANnav v2.3.1x Flow Management feature introduces more changes on top of existing SANnav v2.3.0 Flow
Management feature changes. A summary of the SANnav v2.3.0 Flow Management changes is introduced in this
document.
3.8.1 SANnav v2.3.0 Flow Management Summary

The SANnav v2.3.0 Flow Management feature has undergone several important changes:
 Gen 6 collections and associated reports removal
 Flow Management support on large deployment platforms only; there is no support on small platforms
 Deprecated Reports is removed in SANnav v2.3.1
Gen7 platforms running FOS v9.2.0 and higher can send MAPS rules violated statistics for IO Health and IO Latency
categories to SANnav. SANnav receives the violated counts for all different types of flows (IT/ITL/ITN/VITL/VITN).
3.8.1.1 New IO Health and IO Latency Widget
Based on the flow violations streamed to SANnav, a new widget is derived and calculated to determine the Initiator Host
and Target Storage device ports that are impacted by violated flows.
The new widget is available as a dashboard widget, which gets updated every five minutes and is kept for the last two
hours. This widget is a troubleshooting widget to determine which device ports are impacted by violated flows indicating
possible traffic issues such as errors, congestion, and/or oversubscription on these ports.
While a Fabric scope may be selected for this widget, Fabric scope and filter are not honored in the dashboard widget
view.
25
SANnav v2.3.0 runs an algorithm to determine the severity of the impacted host ports or storage ports as one of the
following:
 Severely Degraded
 Degraded
 Marginally Degraded
3.8.1.1.1 Investigate Violated Flows and F-Ports from the IO Health and Latency Widget
When the widget shows the device ports that are impacted by having flows going through them that are violated (severity
is either Severely Degrade, Degraded, or Marginally Degraded) it is possible to drill down on the severity bar to view the
violated flows.
Upon drill down, a table will show the violated flows, the flow attributes, and sample metrics aggregated over the last two
hours. From this table, it is possible to investigate any flow or to investigate the entry and exit F-ports associated with the
Flow. With this feature, a user may view the flow metrics and the physical port (F-port) metrics to detect any correlation or
relation.
3.8.1.2 Flow Telemetry Chassis Registration
In a customer environment, there could be millions of flows going through the Fabric at any time. SANnav does not collect
flow telemetry statistics through streams of data for all of these possible flows.
To manage flow scale, which can be quite large, the SANnav user must determine which chassis to receive flows from. By
default, no flow streams are received until the user registers for flow telemetry streaming reception.
To control and manage from which chassis SANnav will receive flow telemetry streams (both flow metrics and flow
violated metrics), use the new menu under SANnav > SAN Monitoring > Flow Telemetry Registration Management.
This menu is only available on large platforms, as stated earlier. This menu lists all currently managed chassis and
whether the chassis is registered for sending flow telemetry data to SANnav.
The user may select up to 150,000 flows total, which is the current flow scale supported and tested/validated in SANnav
v2.3.0. When there are more than 150,000 flows registered, SANnav will not allow any more chassis registration.
Each type of switch or Director chassis has a specific limit that is platform dependent. Refer to the FOS v9.2.0
Administration Guide and the SANnav v2.3.0 User Guide for details on supported flows per hardware platform.
CAUTION Flow Management is only supported on large platforms (96GB RAM, 24 vCPUs, 1.2TB storage).
If a SANnav server with a Base license is upgraded to a large platform, then the Flow telemetry
chassis registration menu will be available, but this configuration has not been tested or validated.
3.8.2 SANnav v2.3.1x Flow Management Changes

The following section highlights the changes introduced in SANnav v2.3.1x and FOS v9.2.1x for Flow Management:
ATTENTION The SANnav v2.3.1x Flow Management feature changes are as follows:
 SANnav v2.3.1x does not support flows from any Fabric OS® release other than Fabric OS v9.2.1x.
– SANnav v2.3.1x consumes IT flows (only) streams with FOS v9.2.1, and only at a five-minute interval.
– SANnav v2.3.1x no longer consumes ITL/ITN or VITL/VITN flows from any hardware platform.
– Upgrades and migrations to SANnav v2.3.1x will not migrate previous flow data (including ITL/ITN and VITL/VITN
flows). See Important Considerations When Upgrading to SANnav v2.3.1x.
26
 FOS 9.2.1 will support IT flows only, no ITL/ITN or VITL/VITN flows, streaming to SANnav combining IT flow statistics
and violations in one new consolidated and optimized Kafka data schema.
– SANnav v2.3.1x Flow Inventory continues to display VM and LUN columns however, they will never be populated.
– Filters: Using filters with LUN or VM values will lead zero flows as a result. Only IT filters will yield results.
 SANnav v2.3.1x Investigation View for Flows changes

– The Investigation view for flows is available for IT flows only, and for FOS v9.2.1x only
– Real-time flow investigation view at a 10-second interval has been removed, as FOS v9.2.1 no longer supports
collections, which is required to provide the real-time flow investigation.
– Six-hour visibility (Inventory and Investigation views for any flow IT/ITL/ITN/VITL/VITN) has been removed.
– Investigation intervals can either be five minutes (native FOS stream) or one hour (aggregated by SANnav).
 The SANnav IO Health and Latency Flow Widget continues to be available in SANnav v2.3.1x, however, it will
process and compute affected device ports for IT flows only (no ITL/ITN/VITL/VITN flows) and for FOS v9.2.1
platforms only.
– The SANnav IO Health and Latency widget only processes IT flow violations on Gen 7 platforms running FOS
v9.2.1x only.
– The SANnav IO Health and Violation widget is not supported on any Gen 6 platforms for any FOS version.
 Flow scale for SANnav v2.3.1x is 160,000 IT flows on large platforms.

 With an Enterprise license, Flow Management is only supported on large server configurations (96 GB RAM,
24vCPUs, 1.2 TB storage).
 The SANnav northbound streaming for flow topics has been removed from SANnav v2.3.1x.
3.9 REST Interfaces
3.9.1 REST Interfaces

Two new REST interfaces have been introduced in SANnav v2.3.1x.
The first REST interface is a GET URL to obtain the SANnav version information. The structure returned contains the
following data as an example (version 2.3.0 example):
 "version": "2.3.1"
 "build": "build 1"
 "generatedOn": "12-20-2023"
 "productBrandName" : "SANnav Management Portal"
 "oemName": "BROADCOM"
The second REST interface is also a GET URL to obtain the SANnav security password and lockout settings. The data
structure returned by this call is shown below as an example:
 "minimumLength": "8"
 "uppercaseLetters": "0"
 "lowercaseLetters": "0"
 "digits" = "0"
27
 "specialCharacter": "0"
 "maximumRepeat": "2"
 "maximumSequence": "1"
 "passwordExpires": "true"
 "lockoutAttempts": "3"
 "lockoutDuration": "15"
 "passwordAge": "0"
 "historyCount": "0"
 "warningPeriod": "0"
 "inactiveLockoutTime": "30"
 "dashboardKeepAlive": false
3.9.2 Miscellaneous Enhancements
3.9.2.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 to backups taken manually or on-demand. Those are
excluded from the new purge schedule and are 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.9.2.2 Switch Support Save – Show Clear Reason for Failure
With SANnav v2.3.1x, a clear and explicit reason for failure will be shown when taking a switch support from SANnav
save fails. There are various reasons why a Switch Support Save might fail from SANnav. This field provides additional
details.
3.9.2.3 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. When selecting
Partial, the only option available is whether to take an HTTP capture. All other options have been removed. Users will not
have the option to select anything if taking the SSDC from the SANnav CLI console.
The name of the Support data collection format is shown below:
<SANnav_host_name>-<SMP>-<GUI/CLI>-<Full/Partial>-<Timestamp>.tar.gz
28
3.9.2.3.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. A file called
sannav-summary.txt will be generated and will have general, host, memory, network, IP tables, and other SANnav
details included and present inside the SSDC file.
3.9.2.4 Change High Granular Data Frequency from 2 Seconds to 10 Seconds
With FOS v9.2.1 and higher, the streaming interval of performance stats will change as follows:
 FC port metrics streaming frequency is changed to 10 seconds from the current 2 seconds.
 FCIP Tunnel, FCIP Circuit, Eth port, and GigE port streaming is changed to 10 seconds from the current 5 seconds.
The investigation view for scheduled ports will show data points spaced at 10 second intervals instead of 2 seconds as in
previous releases.
The investigation view for scheduled Tunnels/Circuits will show data points spaced at 10 second intervals instead of 5
seconds as in previous releases.
There are no impact or changes on historical port or tunnels/circuits Investigation.
3.10 USF-Related SANnav 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 traditional 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 the next sections, SANnav enhancements to support IPS Fabric discovery, IPS Fabric creation and end to end IP
device configuration will be explained. In addition, monitoring of IPS fabric and various other functions within SANnav
have been enhanced to support management of IPS Fabric and will be highlighted briefly.
The fundamental principle used in SANnav to fully manage USF and IPS Fabrics has been to ensure that the IPS
functionality is seamlessly integrated within existing SANnav paradigms. New paradigms are only introduced in SANnav
when required, for example to provision and manage new L2/L3 entities such as VLANs, VRFs, and static routes.
To properly deploy, configure, monitor, and debug end-to-end IP Device connections through an IPS Fabric, a basic
understanding of the following IP networking is expected.
 VLAN
 VRF
 IP Routing
 ARP
 LAG
 DHCP
 DNS
Refer to the USF section of the SANnav Management Portal v2.3.1x User Guide for more details on this entire feature as
well as the Brocade Fabric OS Administration Guide. The following sections will only cover a brief introduction and
overview of the new features for USF and IPS Fabric management.
29
3.10.1 Hardware Support for IPS

IP Storage Logical Switch is supported in the Gen7 chassis (X7-4 or X7-8) running Fabric OS (FOS) version 9.2.1 with
FC64-48 blades.
Ethernet ports are only allowed on FC64-48 blades. However, the E-Ports to establish IPS LS connectivity may be
selected on either FC64-48 or FC64-64 blades or on ports on the core blades. The ICL ports can also be used as an E-
Port for IP Storage fabric.
The following range of AnyIO ports on the FC64-48 blade with appropriate optics are supported for transitioning to
Ethernet ports:
 Ports from 16 to 23
3.10.2 IPS Fabric Management in SANnav

IPS Fabric management in SANnav follows the same principles used for FC and FICON Fabric management. There are
two ways in which Fabrics can be added to SANnav. The first is through Fabric Discovery (brownfield) and the second is
through Logical Fabric creation workflow in SANnav (greenfield).
3.10.2.1 IPS Fabric Discovery (Brownfield Workflow)
The same workflow used to discover a FC or FICON Fabric in SANnav applies to discovering an IPS Fabric. There is no
change in the input required in the UI to discover an IPS Fabric.
There are two visible changes when the Fabric is discovered successfully. First, a new Logical Role attribute is added to
indicate whether the Logical Switch is Logical FC or Logical IP (for UPS and IPS Fabrics) type. Second, a new attribute
Type with the values FC or IP has also been added for the Discovered Fabrics view in SANnav.
3.10.2.2 IPS Fabric Creation (Greenfield Workflow)
A new Tab called IP Storage Fabrics in the SANnav > SAN Configuration > Logical Fabric Management has been
added to initiate the creation/editing/deletion of IPS Fabrics. The workflow to create an IPS Fabric is very similar to that
used for creating Logical Fabrics (for FC Fabrics) or FICON Fabrics (for FICON Fabrics).
The most notable difference is the fact that the user needs to specify which AnyIO ports to assign to the IP Logical
Switches (IP LS). There are restrictions for IPS creation, such that only one IP LS per chassis is allowed in the SANnav
v2.3.1x and FOS v9.2.1x releases along with other restrictions which are described in detail in the USF section of the
SANnav Management Portal User Guide, as well as the Brocade Fabric OS Administration Guide.
3.10.3 End-to-End IP Device Connectivity Provisioning in SANnav (Day 1)

This section discusses the workflows used in SANnav to configure and provision IP device connectivity through one IPS
Fabric.
If an IPS Fabric is deployed in a redundant manner through a second IPS Fabric, then the same steps performed on the
first IPS Fabric to provision end-to-end device connectivity must be performed a second time on the second IPS Fabric to
achieve redundant end-to-end paths through both IPS Fabrics.
The key and important points to note in this section are detailed and described in the USF section of the SANnav
Management Portal User Guide. They are summarized below:
 It is highly recommended to use the reference architecture (dual fabric multipath topology).
30
 While any combination of IP device connectivity is allowed in both FOS v9.2.1x and SANnav v2.3.1x, the only
recommended and test/validated IPS configuration is the topology where IP servers are connected through L3TOR
switches to the IPS Fabric and where the IP Storage ports are directly attached/connected to the IPS Fabric.
 It is important to have a topology diagram representing the end-to-end device connectivity drawn before proceeding to
the provisioning steps in SANnav. An example is provided in the Getting Started with IP Storage section of the
SANnav Management Portal User Guide.
 Another important and fundamental aspect in SANnav 2.3.1x and FOS v9.2.1x is that since there is no device name
server in FOS v9.2.1x for IP devices (such as iSNS, for example), the device port discovery by SANnav cannot be
performed as is done for traditional FC-connected devices and will require user intervention and data input.
 To provision end-to-end IP device connectivity requires two tasks performed by potentially two different Administrator
roles (who may be the same person).
– The first part is performed by the SAN Administrator, who will provision all aspects in the SAN and IPS Fabric
through SANnav (or CLI).
– The second part is performed by a Network Administrator, who is responsible for connecting and configuring
(through the L3TOR CLI console) the L3TOR switches and LAGs to the IPS Fabric, as well as the Host subnets
attached behind the L3TOR that need to access IP Storage ports on the other end of the IPS Fabric.
ATTENTION When provisioning end-to-end IP Device Connectivity through one fabric (FabricA), if redundancy
is required through a second Fabric (FabricB) because the IP devices are redundantly connected
through two IPS Fabrics, then the complete provisioning steps described below need to be
performed on both FabricA and FabricB in SANnav, one fabric at a time.
3.10.3.1 Launch Point to Configure IPS Fabric Device Connectivity
The launch point for all tasks related to IPS end-to-end device connectivity is under a new menu tab in SANnav > SAN
Configuration > IP Storage Fabric Configuration.
When this menu is launched, the IPS Port Connectivity Tab displays. By default, the first time that this menu is launched,
the user must select an IPS Fabric on the right side of the IPS Connectivity table. If no IPS Fabric has been provisioned,
this table (and the other tabs) will be empty.
There are five tabs shown when the IP Storage Fabric Configuration menu is launched. The order of provisioning for
these tabs follows the standard SANnav paradigm, from right to left. The user is expected to navigate from the right-most
tab to the left-most tab to properly configure the device connectivity through an IPS Fabric as follows:
1. IPS Port Connectivity tab
2. Connected Subnet tab
3. VRF tab
4. VLAN tab
5. Routing tab
The next subsections will briefly explain the tasks that the user is expected to perform in each tab above.
3.10.3.2 IPS Port Connectivity View – Provisioning End Devices in SANnav
Once the SANnav > SAN Configuration > IP Storage Fabric Configuration is clicked, the IPS Port Connectivity tab is
shown. If the Fabric context has been set before, the last Fabric used is shown. If the Fabric context has not been set
before, a specific IPS Fabric scope must be selected.
This IPS Port Connectivity table represents the inventory of all the AnyIO ports attached to the Fabric that are available for
IP device connectivity or that are used to interconnect, link, and trunk IP LS switches (E-Ports).
These ETH ports have been previously provisioned, either during IPS Fabric creation or discovery, as ETH ports. An ETH
port is an AnyIO port whose protocol has been configured or provisioned to ETH, indicating that it is used for IP Device
31
connectivity (server or storage). An E-Port belonging to the IPS Fabric is an FC port used to connect to another E-Port in
another IP LS in the IPS Fabric.
This table allows operations to properly configure and provision the end devices connected to the IPS Fabric. As
mentioned previously, since there is no name server in FOS v9.2.1 and SANnav v2.3.1x, the user is expected to provision
through this IPS Port Connectivity UI the L3TOR connected to the IPS Fabric as well as the IP Storage Ports directly
attached to the IPS Fabric.
The L3TOR is likely connected to the IPS Fabric using a LAG that contains multiple individual links. This LAG object also
needs to be provisioned as part of provisioning the L3TOR in SANnav.
In the IPS Connectivity view, an important column is the Configuration Status column, which has a few key values:
 Available: The AnyIO port is not provisioned to have an attached device to it (L3TOR or IP Storage port) and is
available to use.
 Configured: The required objects have been provisioned from SANnav and the IPS Fabric side. This does not mean
that the end-to-end IP device connectivity is working properly.
 Auto Config: This applies for E-Ports and means that the AnyIO it has been automatically configured to E-Port (for an
ISL connection).
 Partially Configured: This typically applies to LAG objects and is a transient state.
 Provisioned: The Connected Type device has been entered, but the rest of the data (Subnet/VRF/VLAN/static
routing) has not been entered. This is also a transient state.
NOTE The Network Administrator will also need to provision the L3TOR and LAG in the L3TOR switch.
3.10.3.3 Provisioning Connected Subnets
After the IPS device port connectivity, including devices, device ports, and LAGS, has been provisioned, the user is
expected to provision the subnets.
There are two types of subnets: Intermediate Subnets and Destination Subnets.
In most typical deployments, one Intermediate Subnet is created for the L3TOR switch connected via LAGs to the IPS
Fabric. Destination Subnets are created for each host subnet attached to the L3TOR that need to access the storage
ports.
For example, if there is one L3TOR switch with two host subnets connected to it, then the following subnets will need to
be provisioned so that the hosts in each subnet can be routed to the proper storage ports on the other side of the IPS
Fabric:
 One Intermediate Subnet for the storage ports attached directly to the IPS Fabric
 Two Destination Subnets, one for each host subnet attached to the L3TOR
3.10.3.4 Provisioning VRF
Once the Subnets have been provisioned, Virtual Routing and Forwarding (VRF) can be provisioned. By default, VRF 0 is
the default VRF created by FOS.
VRF provisioning is optional. VRF provisioning may be required to partition various independent traffic flows on the same
IPS Fabric to segregate traffic from multiple devices on the same single IPS Fabric; otherwise, there is no need to
provision VRFs. An example of VRF provisioning would be to use VRF 0 for a certain set of applications and VRF 1 for
another set of applications; all traffic is carried over the same IPS Fabric with no interference between traffic on VRF 0
and VRF 1.
If VRF is required, then up to four VRFs may be provisioned in FOS v9.2.1x in one single IPS Fabric.
32
3.10.3.5 Provisioning VLANs
Once the subnets and the optional VRF objects have been created, the next step is to provision the VLANs. There are two
types of VLAN objects used: VLAN and Interface (Intermediate) VLAN.
In most cases, when a set of storage ports directly attached to the IPS Fabric need to communicate to host subnets
behind an L3TOR, then one Interface VLAN and one VLAN would need to be created.
 The VLAN object is to be created for the direct attached devices, most typically, storage ports.
 The Interface VLAN would need to be created for the L3TOR device attached to the Fabric.
NOTE
 The fundamental difference between VLAN and Interface VLAN is that when creating a VLAN, an
object storage port directly attached to the IPS must be specified, while when creating an
Interface VLAN, a subnet or a link must be added instead of ports.
 The Network Administrator will also need to provision the VLAN objects on the L3TOR switch.
3.10.3.6 Provisioning Static Routing
Once the VLAN objects have been created, the last and final step is to specify the static route for the storage ports to
reach the host subnets behind the L3TOR switch.
From SANnav, one static route per host subnet behind the L3TOR needs to be created. So, with the example of two
storage ports directly connected to the IPS Fabric and two host subnets behind the L3TOR switch, two static routes need
to be provisioned:
– One static route for the storage ports to reach the first host subnet
– One static route for the storage ports to reach the second host subnet
NOTE The static route provisioned in SANnav is a one-way static route, from the storage ports to the host
subnets behind the TOR. The route from each of the host subnets behind the L3TOR to the storage
ports needs to be configured by the Network Administrator on the L3TOR.
3.10.3.7 Exporting a Complete IPS Device Connectivity End-to-End
Once all the provisioning on the SANnav has been performed (all five tabs have been fully completed) it is important to go
back to the IPS Port Connectivity tab to Export the complete IPS end-to-end device connectivity. This export function is
not like an Inventory Export where only the data in the inventory being viewed is exported. Here, all data is exported
including IPS Port Connectivity, Subnets, VRFs, VLANs, and static routes.
This feature is useful to get a complete end-to-end view of each IPS fabric port and what is connected to it. The SAN
Administrator may then exchange this file with the Network Administrator to make sure all data is consistent and matches
on the L3TOR side. Note that the reverse can occur as well. That is, the Network Administrator provides to the SAN
Administrator the Host Subnets, LAGs, VLANs and static routes configured from IP side so that the SAN Administrator
configures the SAN portion accordingly.
NOTE When all the provisioning steps above have been completed, the Configuration Status column in the
IPS Connectivity view should be set to Configured state.
3.10.3.8 Troubleshooting End-to-End IP Device Connectivity
In SANnav v2.3.1x, there are no features to troubleshoot IP Device end-to-end connectivity, such as ping or other
means. However, FOS v9.2.2 CLI does provide a set of commands to do so. Since these commands are interactive, it is
not recommended to use SANnav switch CLI to send them. Instead SSH to the FOS switch to run these commands
directly.
33
3.10.4 Day 2 Provisioning Use Cases for IP Device Connectivity

The Day 1 operations described above are to be performed for the initial setup for IP device connectivity and involves the
creation of multiple objects in SANnav and FOS.
The Day 2 activities and typical use cases involve application life cycle management operations on the objects created in
Day 1. Typical operations involve editing these objects from SANnav and to FOS.
There are four use cases for Day 2 as explained below.
3.10.4.1 Add Storage Ports to an Existing End-To-End Connection
As is the case for SAN zoning, it may be required to add storage ports due to an existing zone in FC for better
performance and to scale the application. The same is true for IPS device ports, it may be required to add more storage
ports to an existing end-to-end application.
The SAN Administrator needs to configure any IO port as direct-attached storage in the IPS Port Connectivity view and
add the port to the storage VLAN in the SANnav VLAN tab. There is no need to add a new static route. There is nothing
for the Network Administrator to do.
3.10.4.2 Add a New Server Under an Existing Host Subnet
A new server may need to be added under a host subnet to access the storage provisioned Day 1. To add a new host
inside an existing host subnet, there is nothing to do if the subnet has available IP addresses. If the host subnet has a
CIDR of 24, up to 255 hosts IP addresses can be added in the subnet.
The Network Administrator need to configure the IP address of the host to be added to an available one. There is nothing
for the SAN Administrator to do.
3.10.4.3 Add a New Storage Subnet Connected to the IPS Fabric
A new subnet for storage may need to be created if either the maximum number of storage ports in a subnet limit is
reached or if it is required to manage different storage subnets.
In this case, the Storage Administrator needs to follow the same steps described to provision the storage ports in Day 1
activities. However, there is no need to add new static routes by the SAN Administrator. The Network Administrator will
need to add a new static route on the L3TOR to reach the newly added storage subnet.
3.10.4.4 Add a New Host Subnet Connected to the L3TOR Switch
In some cases, if the number of hosts exceeded the number of allowed hosts, and new hosts need to access the storage
ports already configured in Day 1, a new host subnet may need to be added behind the L3TOR switch in SANnav and a
new static route defined (added) for the storage VLAN ports to reach new host subnet.
In this case, both the SAN Administrator and the Network Administrator need to perform tasks. The SAN Administrator
needs to define a static route to reach the storage VLAN for the new host subnet. The Network Administrator must
configure a new host subnet behind the L3TOR switch and define a new static route for the new host subnet to reach the
existing storage subnet.
3.10.4.5 Add Links to an Existing LAG Between the L3TOR Switch and the IPS Fabric
With scale and many devices connected, congestion between the L3TOR switch and the IPS Fabric may occur.
In this case, more links may need to be added to LAG between the L3TOR and the IP LS created on Day 1. In this case,
both the SAN Administrator and the Network Administrator need to perform tasks to add ports to the LAG on each of their
respective end. In SANnav, the SAN Administrator can invoke Add Port(s) to LAG from the IPS Port Connectivity view on
any port that is already part of the LAG created in Day 1.
34
3.10.4.6 Other Use Cases for Day 2
There are other use cases for Day 2 operations which are like the previous use cases explained above. Refer to the
SANnav Management Portal v2.3.1x User Guide for details on how to achieve these use cases in the SANnav UI. These
use cases include the following:
 Removing storage ports from a VLAN (operations by SAN Administrator only)
 Removing a server from a host subnet (operations by Network Administrator only)
 Removing an entire host subnet behind the L3TOR (operations by both SAN Administrator and the Network
Administrator)
 Removing ports from a LAG (operations by both SAN Administrator and the Network Administrator)
3.10.5 Topology Contexts for IPS Fabrics

The following topology contexts are supported for IPS Fabric and USF:
 IPS Fabric context
 IP LS Switch context
Viewing any of these contexts will display appropriate IPS topology. Assuming the user has properly created or
discovered the Fabric and provisioned end-to-end IP device connectivity correctly, then the topology will reflect device
connectivity through the IPS Fabric.
There are new icons and badges in the topology for IPS Fabric and IP LS switch contexts. Key ones to mention here are
the Subnet icons that represent the host subnets behind a L3TOR, L3TOR switch, L2TOR switch and a few others. Refer
to the SANnav Management Portal v2.3.1x User Guide for details.
ATTENTION SANnav v2.3.1x does not support IP Hosts or IP Storage as a context, therefore it is not possible
to display redundant and resilient host subnets connected to two Fabrics with storage ports on
the other side in topology as can be done for traditional FC devices.
3.10.6 CLI Based Discovery of IP Devices (Not Recommended)

This approach is like the IPS Fabric Discovery brownfield approach but is applied for device connectivity discovery. In this
approach, the user has used FOS CLI to provision all required entities such as subnets, VRFs, VLANs, and static routes.
SANnav will then discover automatically (no action required) all the IPS objects created and will add them to the
associated tabs.
The Configuration State status of the ISP Port Connectivity view is a key column to pay attention to in these cases. To
complete the end-to-end provisioning and view a consumable SANnav topology, the user will likely have to complete the
provisioning steps in SANnav. This is the reason why this approach is not recommended although supported.
3.10.7 Investigating Any IO (ETH) Ports

AnyIO ports, whether configured as ETH ports or as E-Ports, can be investigated from the SANnav Switch Port Inventory
view like any other standard Fabric port. The metrics shown for AnyIO ports configured as ETH are:
 Tx Utilization (MB/sec)
 Rx Utilization (MB/sec)
 Tx Utilization %
 Rx Utilization %
35
3.10.8 IPS Dashboards and Reports

There are no new dashboard widgets or reports for IPS in SANnav v2.3.1.
The existing Fabrics Status widget for reports and dashboards has been modified to add the Type of Fabric (FC vs IP).
Similarly, for the Switches Status widget, a new Logical Role column has been added, with values of Logical FC (for FC
LS) or Logical IP (for IP LS switch).
3.11 Features Deprecated with SANnav Management Portal 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.0, however the feature will be removed in a future release.
 The feature under the menu SANnav > SAN Monitoring > MAPS Policy Management has been deprecated in
SANnav v2.3.0x and continues to be deprecated for SANnav v2.3.1x.
 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.1x.
3.12 Features Removed from SANnav Management Portal v2.3.1x

The following features are no longer available with SANnav v2.3.1x:
 Launching Web Tools using SANnav user’s credentials was deprecated in SANnav v2.3.0x and is now removed with
SANnav v2.3.1x.
 Inventory Search REST Interface (end point /external-api/v1/inventory/search) has been removed.
Instead use other available REST interfaces to search using filter and scope. Refer to the SANnav REST API
Reference Guide.
 The SANnav northbound streaming for flow topics have been removed.
– Other topics, including Ports, Tunnel/Circuit, and Switch, continue to be supported and will likely be deprecated or
removed in a future release.
 Real time investigation of flows at a 10-second interval has been removed from both FOS v9.2.1x and from SANnav
v2.3.1x.
 Investigation at a six-hour interval has been removed from SANnav v2.3.1x, since there are no longer ITL/VITL flows
in SANnav v2.3.1x.
– Only IT flows may be investigated at either 5-minute (native stream) or 1-hour (aggregated) intervals.
 Flow Management is no longer supported on small platforms for SANnav v2.3.x.

 The following nine flow-related reports were deprecated with SANnav MP v2.3.0x and are now removed with SANnav
v2.3.1x:
– Time Series – Flows
– Top Flows – IO Exceptions
– Top Flows – Other (non-Read/Write) commands
36
– Top Host Port Pending IOs

– Top Storage Port Pending IOs
– Top Storage Port Data Rate
– Top Storage Port ECT
– Top Storage Port FRT
– Top Storage Port IOPS
 The SNMP MIB Foundry attribute with Vendor Id 1991 was used for authorization by releases of SANnav before
v2.3.1x. In SANnav 2.3.1x, support for the Foundry attribute on the RADIUS server has been removed. Customers
using this specific attribute should change their RADIUS server dictionary file typically called
dictionary.NM_AAA_dictionary to use the Brocade attribute with Vendor Id 1588 and the attribute
sequence number to 1 or any other unique number for RADIUS authorization. An example is shown below. The
changes to be made are shown in blue:
# -*- text -*-
#
# dictionary.Brocade
#
VENDOR Brocade 1588
BEGIN-VENDOR Brocade
ATTRIBUTE NM-Roles-AORs-List 1 string.
END-VENDOR Brocade
Save and close the RADIUS server dictionary file. Restart the RADIUS server.
NOTE If Attribute sequence number 1 is already used for the other attribute for Vendor Id 1588, change
the attribute sequence number to any unique number.
3.13 Important Considerations When Upgrading to SANnav v2.3.1x

This section highlights key points to consider during upgrade and migration from previous releases of SANnav MP to
SANnav MP v2.3.1x.
If these considerations are a concern, then customers are advised to stay on the previous release (SANnav v2.2.2x or
SANnav v2.3.0x) and to not upgrade or migrate to SANnav v2.3.1x.
Refer to the Features Affected by Upgrade and Migration section of the SANnav Management Portal v2.3.1x User Guide
for more details on behavior changes and considerations during upgrade and migration to SANnav v2.3.1.
3.13.1 Flow Management

 Upgrade and Migration to SANnav v2.3.1x will not migrate previous flow data (including ITL and VITL flow data)
ATTENTION Customers wishing to keep previous SANnav release flow data (especially ITL/ITN and
VITL/VITN) must remain on previous SANnav versions (v2.3.0x or v2.2.2x) and should not
upgrade to SANnav v2.3.1x.
 Backing up a SANnav instance on a large platform and restoring it on a small platform running SANnav v2.3.x is not
recommended. The flow data will not be migrated on the small SANnav v2.3.x platform as flow management is not
supported on small platforms.
37
3.14 SANnav Management Portal v2.3.1/2.3.1x Supported SAN

Switches
3.14.1 Platform Support and FOS Support – New Policy

Starting with SANnav v2.3.0 and later, support for various SAN hardware platforms and FOS versions will be reduced.
This affects support for SANnav customers as follows:
 An end user reports an issue on an unsupported hardware platform and/or unsupported FOS release.
– To receive support, the end user must reproduce the issue with a supported hardware platform and/or FOS
version.
End users should upgrade to supported hardware platforms and/or FOS version configurations before deploying SANnav
MP v2.3.1.
3.14.2 Hardware Platforms and FOS Support Matrix

The officially supported matrix of supported hardware platforms and FOS versions is listed in the table below. Note that no
Gen4 platform is officially supported with SANnav v2.3.0 and later. SANnav will continue to recognize, discover, and
manage these End-of-Support (EOS) platforms, however, support may be limited in some cases.
NOTE Switches running EOS FOS versions such as FOS v7.4.x or any FOS v8.x non-target path releases
may be managed by SANnav, however, issues specific to those FOS firmware versions will not be
addressed by Broadcom.
Switch Type Hardware Model FOS Version(s) Supported*
Gen 7 Switches  Brocade G720  FOS v9.0.1e1 and later

 Brocade G730  FOS v9.1.1c and later
 Brocade X7-4  FOS v9.2.0a and later
 Brocade X7-8  FOS v9.2.1x
 Brocade 7850
Gen 6 Switches  Brocade G610  FOS v9.0.1e1 and later
 Brocade G620  FOS v9.1.1c and later
 Brocade G620 (switchType 183)  FOS v9.2.0a and later
 Brocade G630  FOS v9.2.1x
 Brocade G630 (switchType 184)
 Brocade 7810 Extension Switch
 Brocade X6-4
 Brocade X6-8
 Brocade MXG610s Blade Server SAN I/O Module
 Brocade G648
38
Gen 5 Switches  Brocade 7840 Extension Switch  FOS v8.2.3d and later
 Brocade DCX 8510-4
 Brocade DCX 8510-8
 Brocade 6505
 Brocade 6510
 Brocade 6520
 Brocade M6505 Blade Server SAN I/O module
 Brocade 6542 Blade Server SAN I/O module
*Not all FOS versions listed in this column are supported on all hardware model platforms. Refer to the FOS and SANnav
User Guides for details of which FOS version is supported by which platform.
 For new Gen7 hardware models (7850), only FOS v9.2.0 and above is supported.
39
Chapter 4: Brocade SANnav Management Portal Deployment
4.1 Server Requirements

SANnav Management Portal v2.3.1x can be deployed either on a single bare-metal host, VM or as an OVA. The following
two tables provide details of server requirements in each case.
ATTENTION It is strongly recommended to run the script check-sannav-system-requirements.sh prior

to starting the SANnav installation. The script checks for correct server specifications and reports
any issues found to the user. Make sure to adhere to the server specifications before proceeding
with the installation.
VM and Bare Metal Deployments

Max Switch Ports Operating System Host Type Minimum Memory Hard Disk
Under Management vCPU
(Base or Enterprise)
Small RHEL 8.8, 9.2 Bare metal or VMware ESX 16 vCPUs 48 GB 600 GB
600 Ports (Base) or, 8.0 VM
3000 (Enterprise) Bare metal/HyperV Windows
Server 2022 VM
Large RHEL 8.8, 9.2 Bare metal or VMware ESXi 24 vCPUs 96 GB 1.2 TB
15,000 (Enterprise) 8.0 VM
Bare metal/HyperV Windows
Server 2022 VM
 RHEL 8.2, 8.3, 8.5, 8.6, 8.7, 8.9, 8.10, 9.3, 9.4 are not officially supported, but installing and running SANnav on these
versions is allowed upon user acceptance with conditional support.
 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.
OVA Deployments
Max Switch Ports Supported Host Type Minimum Memory Hard Disk
Under Management Hypervisor vCPU
(Base or Enterprise)
Small VMware ESXi 8.0 VMware ESXi VM 16 vCPUs 48 GB 600 GB
600 Ports (Base) or,
3000 (Enterprise)
Large VMware ESXi 8.0 VMware ESXi VM 24 vCPUs 96 GB 1.2 TB
15,000 (Enterprise)
 SANnav MP v2.3.1a OVA packages Rocky Linux 8.9 in the OVA file
 ESXi 8.0 is recommended. SANnav v2.3.x has not been validated with ESXi 7.x but installation should work.
40
 The OVA deployment allows user to select a small or large deployment configuration.
 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 Management Portal v2.3.1x client:
 Chrome (Windows, Linux, MacOS)
 Firefox (Windows, Linux)
 Edge (Windows)
NOTE Refer to Web Tools User Guide and Release Notes for supported list of browsers for Web Tools
launch for all FOS versions (FOS v8.x and below – Java required, and FOS v9.x and above – no
Java required)
4.3 Software Upgrade

Refer to the Upgrade and Migration Overview section of the Brocade SANnav Management Portal v2.3.1x Installation and
Migration Guide for complete details.
Supported Upgrade and Migration Paths to SANnav v2.3.1a:
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.
41
SANnav v2.3.0x SANnav v2.3.1a Yes OVA upgrade inline. OS upgrade first to Rocky 8.9
(recommended)
SANnav v2.3.1 SANnav v2.3.1a Yes OVA upgrade inline. OS upgrade first to Rocky 8.9
(recommended)
 For upgrade from SANnav v2.3.0 to v2.3.1a or v2.3.1 to v2.3.1a OVA case, it is recommended to upgrade the OS to
Rocky Linux 8.9 first. If that is not possible, then in these cases SANnav will require user acceptance to run SANnav
v2.3.1a on an untested OS. Refer to the Note in section SANnav Management Portal v2.3.1a OS Support.
 Refer to the SANnav Installation and Upgrade Guide for details before attempting a SANnav MP 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 versions do 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), follow
these steps to upgrade/migrate to SANnav v2.3.x:
 Take a backup of the 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.1x 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.
42
Chapter 5: Licensing
The Brocade SANnav Management Portal can be licensed in either a Base or Enterprise version.
 SANnav Management Portal Base enables management of up to 600 ports residing on fixed port switches or
embedded blade switches, but it cannot be used to manage ports from any Directors (4-slot or 8-slot).
 SANnav Management Portal Enterprise enables management of up to 15,000 ports from any embedded switch, fixed
port switch, or Director-class products.
Product Offerings Description
SANnav Management Portal Base Manages up to 600 ports from fixed-port or embedded switches but does not manage
directors.
SANnav Management Portal Enterprise Manages up to 15,000 switch ports from any type of switch including directors (either
4-slot or 8-slot).
ATTENTION SANnav Management Portal uses a subscription-based licensing model, which allows the product
to function for the duration purchased. The SANnav Management Portal license must be renewed
and installed in a timely manner to keep the product functioning without disruption.
5.1 Removal of Trial Period

SANnav Management Portal 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 Management Portal 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 the creation of the SANnav license file.
 This 30-day expiration is completely independent of the SANnav subscription expiration date.
Refer to the Licensing section of the SANnav Management Portal v2.3x 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.
43
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. The 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 date minus
renewal start date, expressed in days.
 The Export Renewal Request will download and generate a file (into 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 SANnav Renewal Verification (SRV) 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 Management Portal v2.3.x User Guide for details on how to export the
License Renewal Request file from the SANnav UI.
44
Chapter 6: Scalability
6.1 SANnav Management Portal v2.3.1x Scalability
Feature Scalability Limit – SANnav Scalability Limit – SANnav

Management Portal Base Management Portal Enterprise
Maximum Number of SAN Ports Managed 600 15,000
Maximum Number of End Device Ports Managed 2000 40,000
Maximum Number of End Device Ports per Fabric 10,000
Maximum Number of Hosts Managed through 200

vCenter Discovery (Across All vCenter Instances)
Maximum Number of Events Stored 2 million
Maximum Number of MAPS Violations Stored 2 million
Port Statistics Stored 5-minute samples are stored for up to 30 days.

1-hour data is stored for 30 days.
1-day aggregated data is stored for 30 days.
10-second samples are collected for up to 3 days for a
maximum of 100 user-selected Gen 6 or Gen 7 ports. These
ports can be on the same switch or across multiple Gen 6 or
Gen 7 switches. Data is retained for 14 days.
Extension Tunnel Statistics Stored 5-minute samples are stored for up to 30 days.
1-day aggregated data is stored for 30 days.
10-second samples are collected for up to 3 days for a
maximum of 100 circuits (only supported for the SX6 Blade and
7810 switch). These circuits can be on the same switch or
across multiple switches. Once data collection is complete, the
data is retained for 14 days.
Maximum Number of Flows Supported Enterprise Edition (15,000 ports) large platform only. No support
on small platforms.
Up to 160,000 IT Flows (only IT Flows) maximum allowed (not
blocked). Blocked > 160,000 flows.
Note: 6-hour investigation removed and no ITL/ITN/VITL/VITN
flows in SANnav v2.3.1. No migration of flows to SANnav v2.3.1
from any other previous release
Flow Statistics Stored 5-minute samples are stored for up to 7 days.
Number of Concurrent User Sessions per SANnav 25
Management Portal Server
(Includes UI Sessions and REST Sessions)
45
Chapter 7: Important Notes
7.1 General
 The network latency between SANnav clients to the SANnav Management Portal server and between the SANnav
Management Portal server to the switches must not exceed 100 ms. If the latency is higher than 100 ms, then
communication time outs may occur and cause undesirable behavior.
 When configuring the VM for SANnav installation, make sure the MTU size of the network interface is set to 1500,
otherwise SANnav will not receive Port Performance data for switches running Fabric OS less than v8.2.1b.
 Cockpit web console for Linux cannot co-exist with SANnav Management Portal.
 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.
 SANnav application performance may be affected during operations like SANnav backup and support data collection.
It is recommended to schedule SANnav backup during application idle time.
 DR is supported for SANnav Management Portal only. DR is not supported for Global View
 In the SANnav > SANnav Password and Lockout Policies menu tab, even if the checkbox Keep dashboard
active after session expires is checked, the dashboard will disappear after 24 hours if there is no user activity due to
nginx forcing the session timeout.
7.2 Infrastructure, Installation, and Migration
 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, the 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 a custom docker home path.
Please refer to the TSB TSB-2024-291-A for more information including the workaround and recovery.
 SANnav uses a set of ports for internal communication which is available in the SANnav Management Portal
Installation and Migration Guide. Do not use those ports while customizing the SCP/SFTP server, SNMP trap,
Syslog/Secure Syslog, or HTTPS communication. Doing so will result in the SANnav server not starting properly.
46
 Firewalld Backend Configuration:

– When RHEL OS boots, the firewalld backend defaults to using nftables instead of iptables. The current
version of Docker used by the SANnav Management Portal 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=<Active Zone Details> --remove-masquerade –permanent
Where <Active Zone Details> 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 Management Portal v2.3.x and the firewall needs to be enabled, ensure the firewalld is
configured before SANnav Management Portal installation. If the step to configure the firewall is missed or omitted
before starting the SANnav Management Portal server, fabric, and switch discovery in SANnav Management Portal
will fail (network reachability issue). If this happens, use the following procedure to resolve the network reachability
issue:
– Stop the SANnav Management Portal server using the script stop-sannav.sh present in
<install_home>/bin folder.
– Stop the Docker using the command systemctl stop docker.

– Follow the firewalld configuration procedure as per the Firewalld Backend Configuration important note.
– Start the Docker using the command systemctl start docker.
– Start the SANnav GV server using the script start-sannav.sh present in <install_home>/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.1, 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.
 When upgrading to SANnav Management Portal v2.3.1, take a backup of the current SANnav installation and
generate a full support data collection before proceeding with the migration process.
47
 If upgrading to SANnav v2.3.1a OVA when FIPS is enabled in the VM and the openSSL is running a non-FIPS
complaint version, the upgrade to SANnav 2.3.1a will fail. In order to fix the problem upgrade the openSSL version in
the VM to a FIPS-complaint version or disable FIPS before the SANnav upgrade.
 When upgrading to SANnav v2.3.1, SANnav may be using TLS v1.2. Switches that are using TLS v1.3 and are
configured to use the default-strong seccryptocfg template cannot be discovered in SANnav. In this situation, you
must configure SANnav to use TLSv1.3 as follows:
– Stop SANnav by running the following script: <install_home>/bin/stop-sannav.sh.
– Go to the <install_home>/conf folder and edit the server.properties file. Change the tls.protocol.version
property from TLSv1.2 to TLSv1.3.
– Start SANnav by running the following script: <install_home>/bin/start-sannav.sh.
– Wait a minimum of 45 minutes for the SANnav server start-up to complete one round of discovery asset
collection.
– After 45 minutes, the status of the switch configured with default-strong seccryptocfg template should be changed
to Discovered.
7.3 Firmware Management and Support Save
 A switch Supportsave or firmware download operation initiated via SCP or SFTP protocol from SANnav Management
Portal will fail in the following scenario for switches running Fabric OS less than v9.0:
1. User has performed a switch Supportsave or a firmware download operation at least once on that switch using
SANnav Management Portal.
2. User has uninstalled SANnav Management Portal.
3. User has re-installed SANnav Management Portal and attempted to either perform a switch Supportsave or a
firmware download for the same switch that was used in step 1.
 To avoid this situation, before uninstalling SANnav Management Portal, take a backup of the ssh-
keypair.ser file from the following location: <SANnav_home>/conf/security. After reinstalling
SANnav, restore the previously backed-up file to the same location.
 To recover from this situation, log in to the switch on which the firmware download or supportsave was
performed, and delete the SANnav Management Portal server IP address from the list of known hosts by
using the following command: sshutil delknownhost <SANnav-server-IP>
 Importing a Fabric OS software package into the SANnav Management Portal repository will fail if the firmware
package is stored on a network shared folder. The workaround for this situation is to download the firmware package
to a local disk on the SANnav Management Portal server, and then import it into the repository.
 SANnav supports only strong ciphers and if switch configuration supports only weak ciphers, firmware download will
not work from SANnav. Please contact Broadcom support for a workaround in case user is willing to use weak
ciphers.
 Updated firmware might not show in the SANnav when one or more ports in the fabric are bouncing. Fix the issue to
see the new firmware details in SANnav
48
 SANnav has a limit of two switches for on-demand Supportsave collection if using an internal SCP/SFTP server. If
more than two switches are selected in bulk, it may take a long time to complete the Supportsave collection with an
internal SCP/SFTP server.
– To work around this issue, either select only two switches at a time with an internal SCP/SFTP server or use an
external SCP/SFTP server which has no switch limit.
– Additionally, if a switch Supportsave is scheduled using the Bulk Select option, the operation may fail for some of
the switches. The workaround is to use an external SCP/SFTP server, which has no switch limit.
7.3.1 Firmware Management and TruFOS

For the following platforms the TruFOS Certificate presence is not enforced until FOS v9.2.x+:
 G610
 G720
 G620
 7810
If a customer has switch models that are part of the list above running FOS versions below FOS v9.2x (FOS 9.1.1a, FOS
9.0.1e1 or later) and is planning to upgrade the FOS version to 9.2.0+, the Firmware Download from SANnav will fail
because a TruFOS certificate is required on FOS 9.2.0+ (enforced).
To work around this issue, for each switch that needs to be upgraded, copy the License ID from the SANnav TruFOS
Certificates UI page and access the Licensing Portal and download the TruFOS certificates for the License ID and
manually apply it to SANnav (select Apply TruFOS). After that is successfully completed, proceed with the firmware
upgrade.
7.4 Discovery and Performance Management
 A Web Tools session depends on the session timeout set on the switch irrespective of direct or proxy launch. Web
Tools running in proxy mode validates the SANnav session before sending a request to the switch to avoid any
illegitimate connection. If Web Tools is open in proxy mode, the SANnav client session will be considered as active;
inactive time will be computed from the time Web Tools is closed.
 A switch will become unreachable after upgrading its firmware to FOS v9.2.0 or above when it was previously
discovered with HTTP protocol in SANnav. To work around this, before upgrading the switch FOS firmware, configure
the switch either with self-signed generated HTTPS certificate or load the custom certificate in the switch.
 In cases where a switch was discovered using HTTP initially and then changed to HTTPS later, the port 80 and/or 443
must not be blocked until the protocol change is reflected in the SANnav UI.
 If a DSA algorithm is used for the HTTPS certificate, then SANnav cannot discover the switch because all the
supported ciphers for this algorithm are no longer supported.
49
7.5 SANnav Backup, DR, and Support Data Collection
 When the SANnav Management Portal server is restored from a SANnav Management Portal backup or when
performing a DR fail over, high granularity performance data, FCIP performance data, and flow statistics and
violations are no longer collected due to a new HTTPS digital certificate that is generated in the server, which does
not match with the digital HTTPS certificates on the switches.
– To resolve this issue, un-monitor and monitor all data-streaming switches. This will update the certificates on the
switches with the new certificate on the SANnav server.
 When the SANnav Management Portal support data file size is greater than 5 GB, copy the file directly from the
SANnav server rather than trying to download it using the client.
 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.
 SANnav Backup generated on large (96-GB) platform cannot be restored on small (48-GB) platforms.
 When collecting support data collection when SANnav services are down, use the CLI option. Run the SANnav
support data collection from the Linux server machine console at the system-level console; all the system commands
can be executed there to collect the required logs and data, which is not possible with the UI option.
 If any of the backup files are moved, renamed, or deleted manually from the file system then SANnav will not show
these files on the Outputs page.
 When triggering on-demand SANnav backup when the disk is running more than 70% of the file system, the backup
fails with the following message: Something went wrong. Try again later. If it happens, please check the
corresponding application event in fault management, which will show the exact reason of the failure.
 DR on OVA:
– When the SANnav version is upgraded, DR needs to be reconfigured. Before reconfiguration, the standby VM
needs to be removed and redeployed as a new VM even though the primary server is migrated inline Refer the
installation guide for the migration procedure and then perform the DR reconfiguration.
– When the DR configuration is reset on the primary server, the standby server VM needs to be removed and
redeployed as a new VM, as there is no reset option on the standby server. Then perform the DR reconfiguration.
7.6 SANnav Telemetry Registration with FOS

Switch telemetry configuration and profile registration is required for the switch to stream switch, port, tunnels, circuits,
and flow performance data.
Use option 4 in the script troubleshooting-sannav.sh present in the <SANnav-Home>/
/Portal_2.3.1_bld124/bin folder to troubleshoot the telemetry registration issue. The user can provide a comma-
separated list of IP addresses of switches that are currently monitored by SANnav. This test will report Switch Telemetry
Diagnostics, which will test for the following:
1. Validate the ports (Firewall check on the SANnav server for the telemetry required ports)
2. Validate whether the switch supports data streaming
3. Validate the switch is bound to this SANnav Server
4. Validate the switch CA Root certificate
5. Validate Telemetry configurations and profiles.
After running the tests, if any of the test result is Not Ok, then there is an issue with Telemetry registration for the switch
and the switch will fail to stream data. In this case, SANnav will not show switch, port, and flow stats. If the issue cannot
be fixed then contact Brocade support to fix the issue.
50
7.7 SNMP and Syslog Registration with FOS

SNMP and Syslog configuration is required for the switch to send Traps, Informs, and Syslog events and to collect switch,
port, and tunnel performance data for switches running FOS versions that do not support streaming.
Use option 4 in the script troubleshooting-sannav.sh present in the <SANNAV-Home>/
/Portal_2.3.1_bld124/bin folder to troubleshoot the SNMP and Syslog. The user can provide a comma-separated
list of up to 10 IP addresses of switches that are currently monitored by SANnav. This test will report SNMP and Syslog
Diagnostics, which will test for following:
1. Validate SNMP Trap Port (Firewall check on the SANnav server for the port 162 or Custom port)
2. Validate SNMP Trap Target Properties (SNMP user/settings)
3. Validate SNMP Security Level
4. Validate Retrieval of Agent's SNMP Engine ID
5. Validate SNMP GET request
6. Validate SNMP Access Control
7. Send and validate test trap
8. Validate syslog port (Firewall check on the SANnav server for the port 514 or Custom port)
9. Validate secure syslog port (Firewall check on the SANnav server for the port 6514 or Custom port)
10. Validate secure syslog CA root certificate
After running the tests, if any of the test result is FAIL, then there is an issue with SNMP/Syslog communication with the
switch. The switch will fail to send Traps, Informs, and Syslog events, and SANnav will not show switch and port statistics
for switches running FOS versions that do not support streaming. If the issue cannot be fixed, contact Brocade support.
51
Chapter 8: Security Vulnerability Fixes
In addition to defect fixes, software releases may also contain updates to address Common Vulnerabilities and Exposures
(CVEs). The latest security vulnerability disclosures and descriptions of each CVE can be found by visiting the Brocade
Security Advisories web page:
www.broadcom.com/support/fibre-channel-networking/security-advisories
Specific CVEs addressed within any given software release will be publicly released a short period after the initial posting
of the software. This is done to provide enough time for OEMs to qualify security updates prior to public disclosure.
The exact CVEs addressed within the SANnav software releases are provided in the following security announcement
support.broadcom.com/external/content/SecurityAdvisories/0/24999
52
Chapter 9: Defects
9.1 Known Issues in SANnav Management Portal v2.3.1
Defect ID: SANN-145090

Technical Severity: High Probability: Low
Product: SANnav Technology Group: Device Management
Reported In SANN2.3.0 Technology: Discovery
Release:
Symptom: Fabric state changes are not reflected in SANnav views
Condition: Rarely, when SANnav database service restarts
Recovery: Restart SANnav server

Technical Severity: High Probability: Medium
Release:
Symptom: A wrong OEM model name is displayed in SANnav
Condition: When IBM branded below switches are discovered in SANnav: Brocade 8510-4 (DCX-4x+)
Brocade 8510-8 (DCX+)

Technical Severity: Medium Probability: Medium
Product: SANnav Technology Group: Fault Management
Reported In SANN2.3.1 Technology: Event Notification
Release:
Symptom: SANnav displays different occurrence times for the notification message and the corresponding
event
Condition: When there is a notification in the notification panel for a given SANnav event
Recovery: The timestamp in the notification panel can be ignored and consider the time shown in the
events view.

Reported In SANN2.3.1 Technology: FCIP
Release:
Symptom: Duplicate IPSec policy is created on the switch
Condition: Editing the IPSec policy which is shared between more than one switch
Workaround: This condition can be ignored since there is no impact on the switch operations.

Product: SANnav Technology Group: Device Monitoring
Reported In SANN2.3.1 Technology: Policy Configuration
Release:
Symptom: FTP block push fails on Non-VF Brocade 7840 switch
Condition: When the user pushes FTP configuration to Brocade 7840 switch running firmware version
v8.2.3d
Workaround: Use CLI to perform this operation
53

Reported In SANN2.3.1 Technology: Firmware Management
Release:
Symptom: A blank dialog is seen after the EULA acceptance step during the firmware update operation.
Condition: When an error occurs during the firmware update operation, if the user stays on the firmware
update page, corrects the error through CLI, and retries the operation.
Workaround: Refresh the client or go to other tabs and then retry the operation

Technical Severity: Medium Probability: Low
Release:
Symptom: SNMPv3 password is set incorrectly on the switch
Condition: When a user sets the SNMPv3 configuration to a non-VF switch running v9.0.1e using
SANnav configuration policy management
Workaround: Use Webtools or CLI to set SNMPv3 configuration for FOS v9.0.1e

Product: SANnav Technology Group: System
Reported In SANN2.3.1 Technology: Component
Release:
Symptom: SANnav database size in the file system increases
Condition: SANnav standby server has been down for a long period after the disaster recovery setup was
completed
Workaround: Bring the standby server up
Recovery: Execute reset-dr-primary.sh script on the primary server if the standby server cannot be
recovered

Reported In SANN2.3.1 Technology: MAPS - Monitoring and Alerting Policy Suite
Release:
Symptom: Created MAPS policies are not shown on the policies page
Condition: Rarely, when some of the SANnav services restart

Release:
Symptom: SNMP FFDC file is created in the switch.
Condition: When firmware is downgraded from a FOS version supporting SNMP security Auth protocol
SHA-512 to a version that does not support SHA-512 while the switch is discovered in SANnav
with Auto SNMP configuration.
Recovery: This FFDC can be ignored and it does not indicate any impact on the switch health.
54

Release:
Symptom: SANnav Disaster Recovery data replication stopped
Condition: Rarely when the standby server fails to respond the replication status to the primary server due
to conditions such as network timeouts. This condition can be detected by executing show-dr-
status.sh and checking the "Last Successful Checkpoint". If the last checkpoint is older than one
hour and DR status is not paused.
Workaround: Login to primary and standby servers and restart DR by running
<INSTALLATION_HOME>/bin/dr/restart-dr.sh

Release:
Symptom: Able to set incorrect LDAP role configuration on the switch from SANnav
Condition: When pushing LDAP Role MAPS block with invalid roles from SANnav
Recovery: Edit the block and provide the valid roles and set on the switch again

Release:
Symptom: SANnav incorrectly reports firmware download on the switch as 'failed' even though the
operation succeeded.
Condition: In rare cases when the switch is not ready for management after firmware download.
Recovery: Once the switch is ready for management, SANnav will display the updated firmware version.

Reported In SANN2.3.1 Technology: Topology Views
Release:
Symptom: The client becomes unresponsive.
Condition: In the Topology view, when the 'show virtual ports' option is selected for a device port which has
no connected switch port or connected switch information.
Workaround: Refresh the page.

Product: SANnav Technology Group: Application Management
Reported In SANN2.3.1 Technology: Installation and Migration
Release:
Symptom: An incorrect warning message is displayed when replace-sannav-certificates.sh script is used to
replace the server certificate.
Condition: Occasionally, the script fails to parse the CN (common name) of the SSL certificate and shows
the country name instead when openssl command returns CN in a different order.
Recovery: Ignore the WARNING shown and proceed to the next step while replacing SANnav SSL
certificates if the CN is correctly mapped to FQDN.
55

Release:
Symptom: The 'OK' button does not work in the MAPS page.
Condition: When a newly created MAPS block is not saved, and a bulk-edit operation is performed.
Recovery: Save the newly created MAPS block and then try the bulk-edit operation.

Reported In SANN2.3.1 Technology: Zoning
Release:
Symptom: User unable to rename zone from zone inventory view
Condition: When the selected Zone name matches partially with other Zone name in the fabric
Workaround: Edit the zone name from the zone management views

Reported In SANN2.3.1 Technology: Dashboards
Release:
Symptom: An error message is displayed when trying to investigate.
Condition: When trying to investigate from the Distribution widgets in the Dashboard.
Workaround: Launch the investigate view from the Dashboard Template for a port or chassis in the drill-down
dialog.

Release:
Symptom: Switch configuration backup page does not render successfully
Condition: Under rare conditions, when some of the SANnav services restart

Release:
Symptom: A duplicate PS_STATE measure is seen in MAPS rule configuration view
Condition: When switches running different FOS versions including FOS v9.2.1 are managed in SANnav
Workaround: This duplicate entry can be ignored and rules can be created by selecting any of the duplicate
measures

Reported In SANN2.3.1 Technology: Device configuration
Release:
Symptom: Device ports are not mapped to auto-enclosures.
Condition: Occasionally, the auto-enclosure option is enabled while fabric discovery is in progress.
Recovery: After fabric discovery is completed, disable, and re-enable the auto-enclosure option.
56

Technical Severity: Medium Probability: High
Release:
Symptom: Renaming Chassis from SANnav fails
Condition: When the operation is performed on a switch running FOS v9.2.1
Workaround: Use Webtools of CLI for chassis renaming
9.2 Defects Closed with Code Change in SANnav Management

Portal v2.3.1

Release:
Symptom: Unable to log into SANnav client as proxy service does not start.
Condition: When the ESXi server hosting the SANnav VM is abruptly restarted.
Workaround: Shutdown SANnav services using the stop-sannav.sh script before restarting the ESXi server.
Recovery: Restart SANnav server using the restart script.

Release:
Symptom: An additional blank widget is added to the report template.
Condition: When the user adds any Timeseries widget to a report template.
Recovery: Remove the extra widget and save the template.

Reported In SANN2.2.2 Technology: Reports
Release:
Symptom: SANnav report generation fails.
Condition: When the report is generated for a large count (>9K) of ports (switch/host/storage).
Workaround: Generate the report by selecting a smaller number of ports using filters.

Reported In SANN2.3.0 Technology: Configuration File Management
Release:
Symptom: Switch FID configuration backups are not listed for a replaced switch.
Condition: When the switch is part of two fabrics - one monitored and the other unmonitored.
Workaround: Delete the unmonitored fabric which contains the given switch.
57

Release:
Symptom: Health Summary Dashboard reduces health score for host/storage redundant paths.
Condition: When the host/storage zone member is part of multiple zones.

Release:
Symptom: Email alerts are not triggered for configured Event Action Policy.
Condition: For events other than critical, major, warning, and info severities.
Reported In SANN2.3.0 Technology: Performance
Release:
Symptom: Port investigation view does not load
Condition: When ports are bulk selected and some of the ports are not part of the assigned AOR

Release:
Symptom: Users cannot view or edit IPSec policies.
Condition: After migrating from SANnav v2.1.1.x/v2.2.x to v2.2.2.
Recovery: Create new IPSec policies.

Release:
Symptom: Login to SANnav application fails.
Condition: When the time zone on the server is incorrectly configured.
Workaround: Configure the time zone and restart SANnav services.

Release:
Symptom: Configuring DR setup fails for standby server
Condition: If the database backup fails while configuring the standby server for reasons such as the
database in the primary server is not reachable due to firewall issues.
Recovery: Contact support for resetting DR setup
58

Reported In SANN2.1.0 Technology: Third-party tools
Release:
Symptom: In Frames and Out Frames are set to 0 while streaming performance data from SANnav.
Condition: When outward performance data streaming is enabled
Workaround: In Octets and Out Octets can be used instead of In Frames and Out Frames

Reported In SANN2.2.2 Technology: Reports
Release:
Symptom: The generated port performance report does not show any data
Condition: When a user selects less than three measures in the report template
Workaround: Select three or more measures in the template

Product: SANnav Technology Group: Performance
Reported In SANN2.2.1 Technology: Utilization
Release:
Symptom: SANnav investigation view for FCIP Tunnels shows incorrect Rx/Tx utilization
Condition: When a single side of the tunnel is managed in SANnav

Reported In SANN2.2.0 Technology: SNMP Setup
Release:
Symptom: SANnav does not forward SNMP traps to the configured forwarder
Condition: When severity-based filters are used for forwarding SNMP traps and the received trap from the
switch does not have a severity
Workaround: Use the OID-based filter instead for the traps that do not contain the severity

Release:
Symptom: Migration from SANnav 2.1.1 to SANnav 2.2.2 fails
Condition: Events or violations generated and persisted exactly at the below time in the source release will
lead to migration failure. 5:59:59.999 AM 11:59:59.999 AM 5:59:59.999 PM 11:59:59.999
PM

Reported In SANN2.2.2.1 Technology: Third-party tools
Release:
Symptom: External REST API for fetching events does not work.
Condition: When user roles other than System Administrator role is used
Workaround: Use System Administrator for fetching events
59

Release:
Symptom: Existing IPSec policy cannot be used
Condition: When migrated from prior versions of SANnav with existing IPSec policies
Workaround: Create new IPSec policy post migration

Reported In SANN2.2.0 Technology: Licensing
Release:
Symptom: The switch related changes are not reflected in the SANnav
Condition: When the password field is empty for the supportftp configuration
Workaround: Set the password for supportftp configuration

Product: SANnav Technology Group: Partner Integration
Reported In SANN2.2.0 Technology: vCenter Integration
Release:
Symptom: In rare conditions, vCenter discovered in SANnav goes down
Condition: When SANnav opens a large number of sessions to the vCenter due to vCenter events.

Technical Severity: Low Probability: Low
Release:
Symptom: Switch configuration restore fails
Condition: After fabrics are discovered and deleted several times in SANnav

Release:
Symptom: Changes in the switch are not reflected in SANnav
Condition: When a blade is removed from the chassis after discovering the switch in SANnav
Recovery: Delete the fabric and discover it again in SANnav

Reported In SANN1.1.0 (EOS) Technology: Firmware Management
Release:
Symptom: SANnav reports success for firmware upgrade operation though the operation fails on the switch
Condition: When the switch is not ready for management at the time of initiating the firmware upgrade
operation
Workaround: Retry the firmware upgrade operation after the switch is ready for management.
60

Release:
Symptom: Events and notifications related to server disk space usage are not shown in SANnav
Condition: When SANnav installation location and docker home are in different mounts

Release:
Symptom: All Fabrics selection does not work in the switch configuration backup page
Condition: When a fabric is deleted and discovered again
Workaround: Unselect and reselect All Fabrics

Release:
Symptom: Unable to send email notifications.
Condition: When the SMTP server supports only TLS v1.2 and the security protocol is SSL/TLS in SANnav.
9.3 Defects Closed without Code Change in SANnav Management

Portal v2.3.1
Defect ID: SANN-141437 Technical Severity: Medium

Reason Code: In Progress Probability: Low
Release:
Symptom: Drift check fails occasionally for some of the switches with an error.
Condition: When the user configures a non-default value for SSH timeout on the switch.
Recovery: Wait till the next drift check.

Reason Code: In Progress Probability: Medium
Release:
Symptom: Sometimes firmware download status shows completed in SANnav even though it has not
completed on the switch.
Condition: Due to rare timing issues, when trying to update firmware on switches running FOS v8.2.3d.
Workaround: Retry firmware update from SANnav.
61

Reason Code: In Progress Probability: Medium
Release:
Symptom: The firmware download fails with the error "server is inaccessible or firmware path is invalid".
Condition: When firmware update is tried for switches running FOS v9.0.1x.
Workaround: Delete the SSH key for the SANnav server IP on the switch using the sshutil CLI command and
then retry the firmware update from SANnav.

Reason Code: Not a Software Issue Probability: Low
Release:
Symptom: Health score is deducted for both host and storage and the health details are not displayed for the
enclosure in Dashboard and Inventory.
Condition: If the host is converted to the hybrid device after initial score computation.
Recovery: Delete the host enclosure and re-create it.

Release:
Symptom: Drift check and configuration push fails error for RADIUS and TACACS+ blocks.
Condition: This issue occurs when more than the supported number of entries for RADIUS and TACACS
block are pushed to the switch in a migrated SANnav environment (from SANnav v2.1.1).
Workaround: Update the blocks containing the RADIUS and TACACS blocks after migration to remove the
additional entries.

Reason Code: Already Reported Probability: Medium
Release:
Symptom: Host Health score computation is inaccurate for the resiliency check rule.
Condition: When the same port of the given host is part of multiple zones.
Recovery: Disable the resiliency health check rule.

Reason Code: Already Reported Probability: Medium
Release:
Symptom: Host Health score computation is inaccurate for the redundancy check rule.
Condition: When ports of the given host are part of multiple zones.
Recovery: Disable redundancy health check rule.
62

Reason Code: Cannot Fix Probability: Medium
Release:
Symptom: Importing a zone alias from the CSV file causes the loss of a zone alias from the fabric.
Condition: The zone alias that is imported from the CSV file already exists in the fabric and Resolve changes
-> Accept/Remove option is used during import zone alias action.
Workaround: Before attempting Import Zone Alias action , remove the zone alias entries from the CSV file if
those zone aliases already exist in the fabric.

Reason Code: Cannot Fix Probability: Medium
Release:
Symptom: Member role changes from Principal to Peer in a peer zone.
Condition: When the zone alias that is imported from the CSV file already exists in the fabric and is part of
one or more peer zones as the principal member and the 'Accept all Changes' option is used
during import zone alias action.
Workaround: Before importing such a zone alias, remove the duplicate zone alias entries from the CSV file.
Recovery: After import, change the membership role to Principal.

Reason Code: Cannot Fix Probability: Low
Release:
Symptom: Existing alias members get removed from peer zones with mixed membership types (WWN, Alias
or DP, Alias).
Condition: When the zone alias that is imported from the CSV file already exists in the fabric and is part of
one or more peer zones that contain mixed membership types such as (WWN, Alias) or (DP,
Alias) and the 'Accept all Changes' option is used during import zone alias action.
Workaround: Before importing such a zone alias, remove the duplicate zone alias entries from the CSV file.

Release:
Symptom: SANnav continuously reports bad health status via email and notification panel for disaster
recovery setup
Condition: When SANnav database service is restarted in the primary server without restarting all other
services
Recovery: Login to the primary server and restart DR service by executing <installation-home>/bin/dr/restart-
dr.sh

Reason Code: Implemented Probability: Low
Release:
Symptom: Unable to discover replacement switch after RMA
Condition: When the seed switch is RMA'ed in a two-switch fabric while the other switch is in an unmonitored
state
63
9.4 Defects Closed with Code Change in SANnav Management

Portal v2.3.1a

Reported In SANN2.3.0a Technology: Firmware Management
Release:
Symptom: A blank dialog is seen after the EULA acceptance step during the firmware update operation.
Condition: When an error occurs during the firmware update operation, if the user stays on the firmware
update page, corrects the error through CLI, and retries the operation.
Workaround: Refresh the client or go to other tabs and then retry the operation.

Reported In SANN2.3.0a Technology: Component
Release:
Symptom: SANnav Disaster Recovery data replication stopped
Condition: Rarely when the standby server fails to respond the replication status to the primary server due to
conditions such as network timeouts. This condition can be detected by executing show-dr-
status.sh and checking the "Last Successful Checkpoint". If the last checkpoint is older than one
hour and DR status is not paused.
Workaround: Login to primary and standby servers and restart DR by running
<INSTALLATION_HOME>/bin/dr/restart-dr.sh

Release:
Symptom: Migration fails when upgrading SANnav 2.2.2.1 to SANnav 2.3.1.
Condition: The Docker home location is set to the default location when it is customized and the server is
upgraded from a pre-SANnav 2.2.1 version.
Workaround: Fix the Docker home location in server.properties in the source version before Migration.

Reported In SANN2.3.1 Technology: Server Properties
Release:
Symptom: Scheduled backup fails after upgrading to SANnav v2.3.1
Condition: When the schedule is created prior to SANnav v2.2.1
Workaround: Update any of the fields in the backup schedule after migrating to SANnav v2.3.1.

Reported In SANN1.1.1 (EOS) Technology: User Profile
Release:
Symptom: Fetching AD LDAP group times out during the search.
Condition: When trying to fetch the AD LDAP group with no filters and the AD has more than 100000
members.
Workaround: Use a filter when searching for the AD LDAP group.
64

Reported In SANN2.3.0 Technology: User Profile
Release:
Symptom: Unable to configure CA LDAP.
Condition: When the CA LDAP server port number is larger than 999.

Release:
Symptom: A duplicate PS_STATE measure is seen in MAPS rule configuration view
Condition: When switches running different FOS versions including FOS v9.2.1 are managed in SANnav
Workaround: This duplicate entry can be ignored and rules can be created by selecting any of the duplicate
measures
65
Revision History
Version Summary of Changes Publication Date

1.0 Initial version of Brocade SANnav Management Portal 04/26/2024
v2.3.1a Release Notes.
2.0 Fixed Note about OVA upgrade to recommending 06/07/2024
upgrading Rocky OS to 8.9 instead of mandating it.
Added Rocky 8.6 in table of OS support in section
3.6.2. Minor other edits in various sections.
3.0 Updated sections 3.14, 4.1. Added section 7.3.1 07/01/2024
4.0 Added section 3.7.5.5. 10/17/2024
66

SANnavMP-231a-RN-v4

Uploaded by

Copyright:

Available Formats

SANnavMP-231a-RN-v4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SANnavMP-231a-RN-v4

Uploaded by

Copyright:

Available Formats

SANnav™ Management Portal v2.3.

Chapter 1: Preface .............................................................................................................................. 5

Chapter 2: Locate Product Manuals and Release Notes ................................................................. 7

Chapter 3: Release Contents ............................................................................................................. 9

3.12 Features Removed from SANnav Management Portal v2.3.1x ..................................................................... 36

Chapter 4: Brocade SANnav Management Portal Deployment ..................................................... 40

Chapter 5: Licensing ........................................................................................................................ 43

Chapter 6: Scalability ....................................................................................................................... 45

Chapter 7: Important Notes .............................................................................................................. 46

Chapter 8: Security Vulnerability Fixes........................................................................................... 52

Chapter 9: Defects ............................................................................................................................ 53

1.1 Contact Technical Support for your Brocade® Product

 Switch Serial Number

The serial number label is located as follows:

 World Wide Name (WWN)

 License Identifier (License ID)

1.2 Related Documentation

Chapter 2: Locate Product Manuals and Release Notes

2.1 Locate Product Manuals on Broadcom.com

2.2 Locate Product Manuals and Release Notes on the Support

2.3 Document Feedback

Chapter 3: Release Contents

3.1 Brocade SANnav Management Portal v2.3.1a Release Overview

3.2 What’s New in SANnav Management Portal v2.3.1a

3.3 What’s New in SANnav Management Portal v2.3.1

The non-USF-related highlights are as follows:

3.3.1 What’s New in SANnav Management Portal v2.3.0

3.4 New Hardware Platforms Supported in SANnav Management

3.5 New Blades Supported in SANnav Management Portal v2.3.1x

3.6 SANnav Management Portal Server Platform Support and OS

3.6.1 SANnav Management Portal v2.3.1x OVA Support

3.6.1.1 OVA and Rocky Linux CVEs Process

3.6.2 SANnav Management Portal v2.3.1a OS Support

RHEL 8.8, 9.2 Yes No Yes - VM and BM (new)

Rocky Linux 8.9 No (Blocked) Yes Yes (OVA only)

3.6.3 New Disaster Recovery (DR) Features

3.6.4 Other Installation and Deployment Features

3.6.4.1 SSL Certificate Expiry Notice

3.6.4.2 SANnav File System Permissions Change

3.6.4.3 Stop and Start SANnav with Operating System

3.6.4.4 Host Time Zone Check

3.6.6 SE Linux Support

3.7 Summary of New and/or Enhanced Software Features

3.7.1 Security and Infrastructure

3.7.1.1 Chassis Password Management for FOS maintenance Account

NOTE This feature is supported for FOS v9.1.1 or higher only.

3.7.1.2 vCenter Account and Password Change

3.7.1.3 Installation and Upgrade/Migration as sudo

3.7.1.4 Running SANnav Containers with No root or sudo Privileges

3.7.1.5 Important OS-Level Customization for User sannavmgr (UID 56900)

3.7.1.6 Change SANnav Server Security Password

3.7.1.7 Nested LDAP Groups

3.7.1.8 MFA and SSO Support with SAML Compliant Protocol

3.7.1.9 Secure Syslog Registration with FOS

3.7.2 User Management Enhancements

3.7.2.1 Email Addresses to External Authentication Users

3.7.2.2 User Deletion Behavior Change

3.7.3 Fault Management Enhancements

3.7.3.1 Default Filter to Exclude Unacknowledged SANnav Application Events

3.7.3.2 SANnav Events Message ID Reference View