ViPR SRM 3.6 – SolutionPack for Cisco MDS Nexus Summary Sheet

Table of Contents

Overview

Learn how to install and configure SolutionPack for Cisco MDS/Nexus. The SolutionPack for Cisco MDS/Nexus accesses performance data that was automatically collected and interpreted (using resource grouping and mathematical calculations) across multiple MDS/Nexus fabrics.

Alerts are consolidated from Cisco MDS/Nexus Switches and shown on the All Alerts Console.

SolutionPack for Cisco MDS/Nexus

SolutionPack for Cisco MDS/Nexus

Back to Top

Technical specifications

Data collection methods

Accesses performance data information that was automatically collected and interpreted (using resource grouping and mathematical calculations) from across multiple fabrics. Uses SNMP to collect fabric information.

Main reports

Port Utilization
Report over Fibre channel ports and Port-Channel.
VSAN
VSAN utilization and relationship.
Overall Throughput
The sum of throughput of all the interfaces of each switch
Switch Performance
Report on the utilization, reachability, and uptime of the switch
Name Server
Name Server Database information.
Environmental elements
Power Supply, temperature sensors.

Supported collection interfaces

For information about supported collection interfaces, refer to the ViPR SRM Support Matrix.

Back to Top

Where to find the latest SolutionPack software

Install the latest core software update for your product suite. SolutionPacks distributed with core software have a 30-day free evaluation period. If you plan to use the software longer than 30 days, you must install a SolutionPack license before the trial period ends.

This 30-day free evaluation only applies to new installations and is not available for upgraded installations. If you upgrade the core software and want to try a new SolutionPack, you must request a license for that SolutionPack.

Back to Top

Performing pre-configuration tasks

Before you discover a Cisco switch in ViPR SRM you need to perform the following checks.

All switches in the Cisco fabric must have SNMP credentials for use with ViPR SRM. For example, if SNMPv1/v2c is used, all Cisco switches in the fabric should have the SNMPv1/v2c community name set with a role of network-admin or network-operator. For example, if SNMPv3 is used, all Cisco switches in the fabric should have the SNMPv3 user set with the role of network-admin or network-operator.

Procedure

  1. Ensure all hardware and software is listed as supported in the EMC ViPR SRM Support Matrix.
  2. Verify the TCP/IP connectivity to the switches to be discovered. Test by issuing a ping command to these switches.
  3. Determine if SNMP traps are enabled. Log in to the switch and run the command show snmp trap.
  4. Run the command snmp-server enable traps to enable SNMP traps.
    SWDevCisco8-9216i# config terminal

    Enter configuration commands, one per line. End with CNTL/Z.

    SWDevCisco8-9216i (config)# snmp-server enable traps

  5. Display the traps that are enabled. Execute the show snmp trap command. The values in the Enabled column should be Yes.
Back to Top

Known issue with user-defined roles

If an SNMPv3 user or SNMPv1/v2c community string used for switch discovery is assigned to a role that has VSAN policy set to deny, there is a possibility of switch reboot and supervisor fail-over.

This is due to an issue in Cisco NX-OS 5.2(6) through 6.2(x).

The workaround is to execute the following commands in sequence:

linbge197#config t
linbge197#role name <name of the role>
linbge197#no vsan policy deny
linbge197#copy run start
linbge197#exit

Back to Top

Configuring switches for SNMPv1 and SNMPv2c

You have to configure Cisco switches for SNMPv1 or SNMPv2c to enable switch discovery, and alert consolidation for the switches. The SNMPv1 or SNMPv2c information you provide when performing discovery is necessary for ViPR SRM to contact the switch to obtain information.

Before you begin

If SNMPv1/v2c is used, all Cisco switches in the fabric should have the SNMPv1/v2c community name set with a role of network-admin/network-operator.

ViPR SRM collects data from the switch using the SNMP community name. It uses the SNMP port for communication. The default port set is port 161.

Note Image
The Cisco documentation provides information on configuring Cisco switches for SNMPv1 and SNMPv2c management.

Procedure

  1. Log into the switch as an administrator.
  2. To configure the snmp-server community string with read-only privileges, run the following commands:

    Cisco8-9216i# config terminal

    Cisco8-9216i(config)# snmp-server community srmuser ro

    Enter configuration commands, one per line.

  3. To verify if the SNMPv1 community string exists, run the command show snmp community.
    A sample output of the command:
    Community Group/Access
    srmuser network-operator
Back to Top

Configuring switches for SNMPv3

You have to configure Cisco switches for SNMPv3 to enable discovery and alert consolidation for the switches. The SNMPv3 information you provide when performing discovery is necessary for ViPR SRM to contact the switch to obtain information.

ViPR SRM collects data from the switch using SNMPv3 secure credentials. ViPR SRM supports SNMPv3 with all the combinations of Auth (MD5, SHA) and Priv (AES, DES, NONE).

Note Image
Create the SNMPv3 users with authentication and privacy passwords on all physical switches in the fabric. The Cisco documentation provides information on creating SNMPv3 users on Cisco switches.

This procedure provides an example of creating an SNMPv3 user called srmuser with a network-operator role, SHA authorization, and AES128 authentication.

Procedure

  1. Log into the switch as an administrator.
    Cisco8-9216i# config terminal

    Enter configuration commands, one per line.

  2. Run the snmp-server user commands as follows:

    snmp-server user srmuser network-operator auth sha <SHA-password> priv aes-128 <AES-password>

  3. To verify the new user creation run the command show snmp user.
Back to Top

Configuring Cisco switches for alert consolidation

Use the snmp-server command to forward SNMP v1 alert traps from Cisco FC switches to ViPR SRM.

Procedure

  1. Log into the Cisco FC switch as the administrator.
  2. Type # config, and press Enter.
  3. Type snmp-server host <trap recipient IP> traps <SNMP trap version> <Community String> udp-port <trap listening port >, and press Enter.
    In the command syntax:
    Syntax element Input
    <trap recipient IP> In a single vApp installation, this is the ViPR SRM IP, and in a distributed environment, is the Backend server's IP.
    <SNMP trap version> version 1
    <Community String> public
    <trap listening port > 2041, which is the ViPR SRM trap listening port.
    Example: snmp-server host 10.247.24.190 traps version 1 public udp-port 2041
  4. If you have multiple Cisco FC switches in your storage environment, repeat this procedure on each switch.
Back to Top

Installing the SolutionPack

Before you begin

Procedure

  1. Click Administration.
  2. Click Centralized Management.
  3. Click SolutionPacks.
  4. Click SolutionPack Center.
  5. Select the SolutionPack in the Browse and Install SolutionPacks window.
  6. Click Install.
  7. Type the instance name.
  8. Assign a server for each component.
    In a typical four server deployment, the recommended servers are selected automatically.
  9. Click Next.
    The window displays a note about Alert Consolidation.
  10. Click Next.
    The window displays pre-configured alert details.
  11. From the Alerting on data collection drop-down menu, select existing settings that have been specified for other components, or select Add a new alerting data collection.
    If you select Add a new alerting on data collection, type information about the alerting configuration. In Alerting Backend hostname or IP address, specify the Primary Backend host.
  12. Click Next.
    The window displays reports settings.
  13. In Administration Web-Service Instance, select an existing instance or create a custom instance.
  14. Click Next.
    The window displays a note about SNMP masks.
  15. Click Install.
  16. Click Ok when the installation is complete.
Back to Top

Enabling passive host discovery for Cisco MDS/Nexus through Generic-SNMP

If you cannot access the active host, you cannot use active host discovery. In this case, you must enable passive host discovery if you want to see end-to-end topology from hosts to array and identify chargeback on SAN enabled hosts.

To enable passive host discovery through the SolutionPack for Cisco MDS/Nexus, edit the Generic-SNMP independent SolutionPack block instance, select the Enable Passive Host Discovery checkbox, and click Reconfigure.

The default zone naming patterns supported in SolutionPack for Cisco MDS/Nexus are:

After you have enabled passive host discovery, there are two options for passive host configuration:
Enable DNS Resolution
This option, which is enabled by default, resolves the "IP" property by using the DNS lookup handler. You can un-check this option to avoid using the DNS lookup feature.
Customize zone naming patterns
This option allows you to customize the zone naming pattern. By default, this option is disabled, and ViPR SRM uses the four default zone naming patterns. You can enable this option to add, delete, or modify the default zone naming patterns and host positions in zones.

Back to Top

Enable and edit customized zone naming patterns

Procedure

  1. Select the Enable Passive Host Discovery checkbox.
  2. Select the Customized zone naming patterns checkbox.
    The system displays the four default zone naming templates.
  3. Click the Add button (plus icon) to view the zone naming pattern and host position for a template. Edit the pattern or position if desired.

    Only Java-based zone naming patterns are supported.

    Only plain numbers can be used for the position. Special characters (like $) should not be prefixed.

    For more information on writing Java's regular expression refer to http://docs.oracle.com/javase/tutorial/essential/regex/

Back to Top

Limitations

Maintenance operations that cause a large number of changes in the SAN environment, such as zoning changes and migrations, might degrade APG database performance. These operations generate new active metrics to represent the new SAN environment, and previous metrics become inactive. If active plus inactive metrics exceed 1.5 million entries, slower performance of the database is expected. If needed, you can clean the database to remove inactive metrics, or split the database if active metrics are greater than 1.5 million entries.

Back to Top

Confirming report creation

After you install a SolutionPack, you can view its reports.

To view the reports:

Procedure

  1. Go to User Interface > Report Library.
  2. Click the SolutionPack to view its reports.

Results

It may take up to an hour to display all relevant information in these reports.

Back to Top

Troubleshooting

Report display problems

Back to Top

What to do if data does not appear in any reports

Procedure

  1. After the completion of at least three collection cycles, verify if data is populating into the reports. If there is still no data in the reports, continue to the next step.
  2. Run the scheduled task to import data into reports. If there is still no data in the reports, continue to the next step.
  3. To view the log files for errors, go to Centralized Management and click Collecting > Collector-Manager::<instance name> > Log Files.
Back to Top

Running a scheduled task to import data into reports

After you push a new configuration into a collector, a scheduled task runs and populates the reports with new data. You can manually run the scheduled task to import the data more quickly.

Before you begin

Allow at least three polling cycles to pass before manually running the scheduled task.

Procedure

  1. Click Administration.
  2. Click Centralized Management.
  3. Expand Scheduled Tasks.
  4. Click Database.
  5. Select the import-properties-Default task.
  6. Click Run Now.
  7. Confirm success in running the task in the Last Result and Last Result Time columns.
Back to Top

What to do if data does not appear in some reports

Procedure

  1. Run the scheduled task to import data into reports. If there is still no data in the reports, continue to step 2.
  2. Search for the metric in the database.
  3. To view the log files for errors, go to Centralized Management and click Collecting > Collector-Manager::<instance name> > Log Files.
Back to Top

Searching for metrics in the database

You can verify that a metric is being collected and used for reporting when you search and find the metric in the database.

Procedure

  1. Go to the Administration page.
  2. Under Modules, click Management of Database Modules.
  3. On the Metric Selection page, create the filter, type the number of results, and select the properties to display for the metric.
    For example, to list up to 100 results of the SignalWait Time metric with the properties of device and IP, type name=='SignalWaitTime' in the Filter field, 100 in the Maximum results field, and select device and IP for the Properties to show.
  4. Click Query.
    A list of the metric results appears. If nothing displays, the metric is not being collected.
Back to Top

Viewing collector errors in the Collector-Manager log files

Review the Collector-Manager log files to troubleshoot problems with data collection.

Procedure

  1. Click Administration.
  2. Click Centralized Management.
  3. Expand Collecting.
  4. Click the Collector-Manager for your collector instance.
    Collector-Manager::<Collector-Manager instance> - <physical_host_ID>
  5. Expand Log Files and click the View File icon to review the configuration error messages.
Back to Top