Scanner Issues
...
Critical configurations are listed on top of the page. There There are two buttons for each scan category (ToplogyTopology, Performance, Event, HFTCS): The left one shows the scan status, the right one the persist status.
Click on a red icon to see the log file for the selected item.
Set severity to "Error" to limit the amount of information.
In most cases, the error can now be narrowed down to either a configuration issue or a product defect:
...
| Expand | ||
|---|---|---|
| ||
| Expand | ||
|---|---|---|
|
Error Message: "Max limit for REST sessions reached"
| No Format |
|---|
Got error from Brocade Switch with IP 10.10.101.147! (body: {
"errors": {
"error": [
{
"error-type": "application",
"error-tag": "operation-failed",
"error-app-tag": "Error",
"error-path": "/rest/login",
"error-message": "Max limit for REST sessions reached",
"error-info": {
"error-code": 14,
"error-module": "auth"
} |
BVQ Version: 6.2 and above
Suggested Action:
By default, the SSH session limits on Brocade switches is set to 3. The number of SSH sessions can be increased up to 10 by using CLI command mgmtapp --config -maxrestsession <1...10>
| Expand | ||
|---|---|---|
| ||
SAN (REST) scanner fails with "authentication failed" Due to a bug in FOS version 8.2.3a and 8.2.3a1, communication via SNMP and REST APIs is broken after an update causing Brocade REST scanners to fail. Root cause is a file descriptor leak that occurs in weblinker during LDAP authentication. Once all file descriptors are consumed a verify error is logged. This also results in webtools authentication failing, causing SANnav, BNA or BVQ to be unable to authenticate with the switch. BVQ Version: any Suggested Action: Brocade official workaround SVA/BVQ specific workaround Final Fix |
| Expand | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| title | Brocade (BNAError Message: HTTP-Error 500 "Unable to connect to Database"
BVQ Version: 2021.H1.3 and above Suggested Action: The Postgres DB on VIO servers which the HMC queries to get various system information (like virtual networks, virtual storage, etc.) is broken or Postgres service (vio daemon) is not running. This causes HTTP-500 error messages on both, the HMC and BVQ scanner. The issue can be fixed using the following commands on the VIOS:
Error Message: HTTP-Error 500 "Exception while getting SEA" No Format | HMC responding slowly to REST API calls Typically, REST API calls to the HMC should be answered within ms up to a few seconds (depending on the amount of data that is requested by the command). If the execution of those calls takes much longer resulting in unacceptably increasing performance scan durations, the problem might be caused by a bug in the IBM HMC.
BVQ Version: any Suggested Action: Upgrade the HMC to V10R2M1040 + iFix MF71107 or V10R2M1041 or higher. Important: Upgrading to this level will only resolve the issue if performance collection on the HMC was disabled prior to the upgrade. Otherwise one of the following two methods is required:
Error Message: HTTP-Error 500 "Unable to connect to Database" during topo scan
BVQ Version: 2021.H1.3 and above Suggested Action: Different problems can result in this error. One reason might be a full filesystem (as the error message itself suggests). Another reason might be a dodgy SEA adapter. Please run command
to see if there are Limbo Packets which indicate that the SEA has detected its physical network is not operational. Error Message: "ObjectNotValidException"
BVQ Version: 2021.H1.3 and above Suggested Action: Information provided by AIX and sent via REST do not match (In this case it was an hdisk which looked fine from AIX point of view but reported no location code when queried via REST API). Root cause is not understood but rebooting the VIOS servers - one after the other - probably fixes the issue. |
Network
...
| title | Brocade (REST) |
|---|
The Postgres DB on VIO servers which the HMC queries to get various system information (like virtual networks, virtual storage, etc.) is broken or Postgres service (vio daemon) is not running. This causes HTTP-500 error messages on both, the HMC and BVQ scanner. The issue can be fixed using the following commands on the VIOS:
Error Message: HTTP-Error 500 "Exception while getting SEA" during topo scan
BVQ Version: 2021.H1.3 and above Suggested Action: Different problems can result in this error. One reason might be a full filesystem (as the error message itself suggests). Another reason might be a dodgy SEA adapter. Please run command
to see if there are Limbo Packets which indicate that the SEA has detected its physical network is not operational. Error Message: "ObjectNotValidException" during topo persist
BVQ Version: 2021.H1.3 and above Suggested Action: Information provided by AIX and sent via REST do not match (In this case it was an hdisk which looked fine from AIX point of view but reported no location code when queried via REST API). Root cause is not understood but rebooting the VIOS servers - one after the other - probably fixes the issue. Error Message: "NullPointerException" during topo persist
BVQ Version: 2021.H1.3 and above Suggested Action: This problem can be caused by a corrupt CMDB on a VIO server. There is a script available from IBM to clean up the CMDB which probably fixes the issue. Error Message: "DuplicateKeyException" during topo persist
BVQ Version: 2022.H1 and above Suggested Action: This problem can be caused by a corrupt CMDB on a VIO server. There is a script available from IBM to clean up the CMDB which probably fixes the issue. |
Network
| Expand | ||
|---|---|---|
| ||
Error message: "Max limit for REST sessions reached"
BVQ Version: 6.2 and above Suggested Action: By default, the SSH session limits on Brocade switches is set to 3. The number of SSH sessions can be increased up to 10 by using CLI command Brocade scanner fails with "authentication failed" Due to a bug in FOS version 8.2.3a and 8.2.3a1, communication via SNMP and REST APIs is broken after an update causing Brocade REST scanners to fail. Root cause is a file descriptor leak that occurs in weblinker during LDAP authentication. Once all file descriptors are consumed a verify error is logged. This also results in webtools authentication failing, causing SANnav, BNA or BVQ to be unable to authenticate with the switch. BVQ Version: any Suggested Action: Workaround Final Fix Error message: "E11000 duplicate key error collection: bvq.dgx_brocade_rule" There is a known Brocade bug which leads to duplicate brocade rule entries. See Brocade documentation FOS-845272. This bug is fixed in Brocade FOS 9.1.1.c, 9.2.0 or higher. BVQ Version: 2023.H1.2 Suggested Action: There are two ways to resolve this issue:
|
| Expand | ||
|---|---|---|
| ||
Storage
| Expand | ||||
|---|---|---|---|---|
| ||||
Error Message: "rbash: line xxx: yyy Killed"
BVQ Version: all Suggested Action: None. This is an SVC limitation. The error typically disappears the next time the system is scanned. Error Message: "the svc raised an error -> CMMVC6098"
BVQ Version: all Suggested Action: None. The error occurs when SVC is busy , e.g. copying files between nodes. The error typically disappears the next time the system is scanned. |
| Expand | ||
|---|---|---|
| ||
| Expand | ||
|---|---|---|
| ||