Question: What Brocade data source should be used?
Answer: The Brocade SSH (CLI) data source is what you should be using for all Brocade devices running FOS 5.2 and higher.
Question: What is required in order to collect inventory data with the Brocade SSH (CLI) data source?
Answer: An admin-level account is more than sufficient. To create a non-admin user for OCI to use, the non-admin user must be granted permissions on all virtual fabrics, and be granted the 'Chassis Role' right. You will want to create this user on every Brocade switch in your environment.
Question: How does the OCI fabric discovery feature work in Brocade environments?
Answer: The OCI data source will SSH to the switch you specify in the data source configuration. OCI will inventory that switch, and perform a
fabricShow command. With the fabric discovery feature enabled, OCI will parse the
fabricShow output looking for real IP addresses (not 0.0.0.0) of switches, and try to determine the WWN of the switch if it is a Brocade device (McDATA devices may appear in fabricShow output in certain interop configs). After inventorying the first Brocade switch, the data source will then move to SSH-ing to the next Brocade switch it has learned about. If configured incorrectly this can result in the same switch being polled repeatedly by several data sources, which can cause performance and utilization issues on the switches.
Question: What is required for collecting FC switch port performance with Brocade CLI/SSH data source?
Answer: It depends - are you using the Virtual Fabric feature? If not, you can use SNMP v2 or v3. If the Virtual Fabric feature is being used, you must use SNMP v3.
Question: What is required to use SNMP v2 for collecting FC switch port performance with Brocade CLI/SSH data source?
Answer: A working SNMP v2 community string. Out of the box, "public" is enabled and works. If any access-control lists have been configured, or "public" has been disabled, you will need to ensure that there is a usable SNMP community string that is permitted through access-control lists. OCI only requires read-only access. For access-control lists, take care to understand what the IP address is of your 'point of acquisition' - if your Brocade CLI data source lives on an OCI Remote Acquisition Unit (RAU), the RAU's IP address needs to be granted access through the access-control list, not the OCI server's IP address.
Question: What is required to use SNMP v3 with the Brocade CLI/SSH data source?
Answer: If Virtual Fabrics are in use, the default Brocade SNMP v3 users snmpuser[1-3] and snmpadmin[1-3] are NOT sufficient. These default users do not have permission on the non-default Virtual Fabrics (VF1 through VF127), which means that the OCI data source will fail to collect statistics on ports in those VFs. You want to put your OCI inventory user into one of the SNMP v3 user slots - this needs to be done on all of your switches.
Question: Why are SAN routed paths within OCI not seen, or the dedicated Brocade SAN routers not discovered even though Brocade datasources are successful?
Answer: The Brocade datasource is unlike the Cisco datasource in that SAN routing information is not automatically obtained. In your Brocade datasources, the Retrieve MPR Data checkbox must be checked to tell OCI to collect this data as part of the inventory
Question: The Brocade SSH datasource has a Fabric Name field. How to use this? Or, why is the name of the fabric a WWN?
Answer: This field is from a simpler time, when a Brocade switch could support only one fabric. The purpose of this field is to allow you to give a fabric a more descriptive name than the WWN of the fabric, which is the default name for a fabric within OCI. If your environment is FOS 7.0.0 or higher, we recommend you actually name your fabrics at the Brocade device, using the FOS cli command fabricname. OCI 7.0.1 and higher will execute the fabricname command on each virtual fabric or fabric on a switch - this is the only way to name virtual fabrics in OCI. Future versions of OCI may actually remove the fabric name field entirely, and only rely on the fabricname data on the switch to avoid clutter in the OCI UI.
Question: Why is the FC Identify view for the Switch Alias column not appearing as expected?
Answer: Each Brocade SSH/CLI datasource has a field "Choose Favoring HBA vs Zone Aliases". It defaults to "HostBusAdapter". This means for a given WWNN, and its associated WWPNs, OCI will prefer to report as Switch Alias, OCI's best attempt at parsing the hostname from the data for that WWNN from the FC Name Server table. There is not much for standards for what metadata gets sent to the FC Name Server table - some hosts (most Windows and Linux) will send their HBA model, firmware, driver data, and often the simple hostname. Other hosts (HPUX, etc) only send hostname and OS version. OCI makes a best effort to parse this data to report HBA details. What OCI pulls for hostname from the FC Name Server may be more accurate than manually created switch aliases within Brocade FOS.
If you only want OCI to use the actual switch alias data on the switch for reporting switch alias, for use for auto resolution, toggle your Brocade datasources from HostBusAdapter to ZoneAlias