One of the regularly used features in BNA is the ability to retain performance numbers and a history of port errors. It is then most annoying when these graphs show a flatline when you know there is a significant amount of traffic traversing these links.
The problem can be on the BNA side but also the switch configuration plays a role. You can be fairly sure that if you point BNA to a switch for discovery, the switch will automatically be configured to have this BNA server as an SNMP trap-recipient. (This is enabled by default but you can turn this off in the Server -> Options -> Trap registration window.) This means that the major components of the switch will be monitored and in case of an issue the switch will send out a trap to inform BNA right away of this event. Depending on the sort and severity of the event BNA may then decide to poll the switch for a status update to check the status of that switch.
The process of discovery and registration is obviously depending of the authorisation BNA has on that particular switch. The ability to poll the switch depends on the credentials supplied by BNA . Since BNA uses SNMP you either have to set the SNMPv1 community names correctly or, and more preferred, set the SNMPv3 credentials. This will result in BNA be able to poll the switch and not be knocked back due to an authentication problem but it doesn’t mean the switch is obligated to return any values for each specific OID that it is queried for.
On the switch there is a license that shows “Enhanced Group Management license” . To be honest I’ve never been able to figure out what it turns on or off. The description in the FOS manual is less useful then a particle physics engineer explaining me the origins of the universe. It says:
Enables full management of the device in a data center fabric with deeper element management functionality and greater management task aggregation throughout the environment. This license is used in conjunction with Brocade Network Advisor application software. This license is applicable to all of the Brocade 8G and 16G FC platforms.
So it seems it is good for something but don’t ask me. Anyway if you have a 16G platform or a DCX(-4s) on FOS 7+ it is always included by default. The 8G platforms in piza-box format or any of the 8G bladeserver IO modules would require this license separately. I almost assume that gathering performance information out of a switch is also tied to this license.
One other setting you need to watch out for is the snmp mibcapability configuration. This is the part on the switch which tells the snmp daemon on which queries to respond.
You can view this with:
snmpconfig –show mibcapbility
Make sure they are all enabled via the same command but with the –set parameter.
snmpconfig –set mibcapability
The following should all be set to “Enabled” or “Yes”
The entries below this section show the snmp trap configuration. Basically telling the switch on which class of events to send out a trap or not.
If you have the MIBS all set to “Yes” then BNA will start logging performance counters (if enabled) and it will keep them in the database. After a short while you should be able to see the performance graphs showing something else than a flatline.
If you want to check “real-time” you can fireup the real-time performance graphs in BNA before enabling these settings. If the real-time performance monitor graphs show up the history tables also should work. The amount of data that is kept is based on the granularity of the counters.
- 5 minutes for last 8 days.
- 30 minutes granularity for last 30 days
- 2 hour granularity for last 30 days
- 1 day granularity for last 730 days.
That means that if you select a range of one month you will not see anything if you also select a 5 minute granularity. Obviously other combinations also may yield no results.
Hope this helps.