Guest

Cisco Prime Data Center Network Manager

Cisco DCNM Release Notes, Release 4.0

  • Viewing Options

  • PDF (211.9 KB)
  • Feedback
Cisco DCNM Release Notes, Release 4.0

Table Of Contents

Cisco DCNM Release Notes, Release 4.0

Contents

Introduction

System Requirements

Java Requirements

Server System Requirements

Client System Requirements

Supported Device Operating Systems

Supported Device Hardware

New Software Features

New Features in Cisco DCNM Release 4.0(3)

New Features in Cisco DCNM Release 4.0(2)

Installation Features

DCNM Licensed Devices

Event Browser Enhancements

New Features in Cisco DCNM Release 4.0(1a)

New Features in Cisco DCNM Release 4.0(1)

Installation Notes

Caveats

Open Caveats—Release 4.0(4)

Open Caveats—Release 4.0(3)

Resolved Caveats—Cisco DCNM Release 4.0(4)

Resolved Caveats—Cisco DCNM Release 4.0(3)

Resolved Caveats—Cisco DCNM Release 4.0(2)

Resolved Caveats—Cisco DCNM Release 4.0(1a)

Resolved Caveats—Cisco DCNM Release 4.0(1)

Related Documentation

Obtaining Documentation and Submitting a Service Request


Cisco DCNM Release Notes, Release 4.0


Release Date: November 3, 2008
Part Number: OL-16035-05 A0

This document provides the release notes for Cisco Data Center Network Manager (DCNM). Use this document in combination with documents listed in the "Obtaining Documentation and Submitting a Service Request" section.


Note Release notes are sometimes updated with new information about restrictions and caveats. See the following website for the most recent version of the Cisco DCNM Release Notes:

http://www.cisco.com/en/US/products/ps9369/prod_release_notes_list.html


Table 1 shows the online change history for this document.

Table 1 Online History Change

Part Number
Revision
Date
Description

OL-16035-01

A0

April 1, 2008

Created release notes for Release 4.0(1).

B0

April 18, 2008

Added CSCso78061 to the open caveats.

OL-16035-02

A0

April 22, 2008

Updated for Release 4.0(1a).

B0

April 29, 2008

Corrected the supported Windows 2003 Server version.

OL-16035-03

A0

June 11, 2008

Updated for Release 4.0(2).

OL-16035-04

A0

August 21, 2008

Updated for Release 4.0(3).

 

B0

August 22, 2008

Added CSCsu02090 to open caveats, corrected CSCsr72829, and moved CSCsq50211 to the Resolved Caveats section.

 

C0

August 27, 2008

Added CSCsr99977 to the open caveats.

 

D0

September 2, 2008

Added the Related Documents section.

OL-16035-05

A0

November 3, 2008

Updated for Release 4.0(4).


Contents

This document includes the following sections:

Introduction

System Requirements

New Software Features

Installation Notes

Caveats

Related Documentation

Obtaining Documentation and Submitting a Service Request

Introduction

DCNM is a management solution for Cisco NX-OS-enabled hardware platforms. Focused on the management requirements of data center networks, DCNM automates the provisioning process, monitors the network for performance degradation, secures the network, and streamlines the diagnosis of dysfunctional network elements.

Cisco NX-OS supports the Cisco Nexus product family, including the Cisco Nexus 7000 Series. For the most recent information on Cisco NX-OS, refer to the following website:

http://www.cisco.com/en/US/products/ps9372/prod_release_notes_list.html

System Requirements

This section includes the following topics:

Java Requirements

Server System Requirements

Client System Requirements

Supported Device Operating Systems

Supported Device Hardware

Java Requirements

DCNM is a Java-based client-server application. The DCNM 4.0 server and client support Java JRE 1.5.0_11.

Server System Requirements

DCNM 4.0 supports running the DCNM server on either of the following two operating systems:

Microsoft Windows Server 2003 Enterprise Edition, Service Pack 1, 32-bit edition only

The minimum hardware requirements for the DCNM server running on Windows Server 2003 are the following:

3.45-GHz dual-processor or dual-core CPU

6 GB of system RAM

60 GB of free disk space

Red Hat Enterprise Linux AS Release 4, 32-bit edition only

The minimum hardware requirements for the DCNM server running on Linux are the following:

3.40-GHz dual-processor or dual-core CPU

6 GB of system RAM with a maximum shared memory size of at least 128 MB

60 GB of free disk space

Additionally, the following prerequisites must be in place for the server:

The server system must be registered with the DNS servers.

A Perl environment must already be installed on the server system. We recommend using Active Perl version 5.8.8.822.

The path to the Perl executable must be defined in the server system PATH environment variable.

No other programs are running on the server.

Client System Requirements

DCNM 4.0 supports running the DCNM client on Microsoft Windows XP Professional Version 2002 Service Pack 2. The minimum hardware requirements for running the DCNM client are the following:

2.16-GHz single-core CPU

1 GB of system RAM

Supported Device Operating Systems

DCNM 4.0 supports management and monitoring of devices that run a release of Cisco NX-OS that matches the DCNM release. For example, DCNM Release 4.0(2) supports management of devices that run NX-OS Release 4.0(2), and DCNM Release 4.0(1a) supports management of devices that run NX-OS Release 4.0(1a).

Supported Device Hardware

DCNM 4.0 supports management and monitoring of the Nexus 7000 Series 10-slot chassis.

DCNM 4.0 supports management and monitoring of the following Nexus 7000 Series I/O modules:

32-port 10-GB Ethernet module, part number N7K-M132XP-12

48-port 10/100/1000-MB Ethernet module, part number N7K-M148GT-11

New Software Features

This section describes the new features introduced in the releases of Cisco DCNM. For detailed information about the features listed, see the documents listed in the "Obtaining Documentation and Submitting a Service Request" section. The "New and Changed Information" section in each of these books provides a detailed list of all new features and includes links to the feature description or new command.

This section includes the following topics:

New Features in Cisco DCNM Release 4.0(3)

New Features in Cisco DCNM Release 4.0(2)

New Features in Cisco DCNM Release 4.0(1a)

New Features in Cisco DCNM Release 4.0(1)

New Features in Cisco DCNM Release 4.0(3)

Cisco DCNM Release 4.0(3) refers to SVIs as "Interface VLANs."

New Features in Cisco DCNM Release 4.0(2)

This release includes features in the following categories:

Installation Features

DCNM Licensed Devices

Event Browser Enhancements


Note For information about the new features in this release, see the Cisco DCNM Fundamentals Configuration Guide at the following website:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_0/dcnm/fundamentals/configuration/guide
/dcnm_fund_config.html


Installation Features

The installation of this release includes the following new features:

The Cisco DCNM server software installs on Microsoft Windows as a service.

Upgrading Cisco DCNM server software automatically migrates database content as required by the new release.

DCNM Licensed Devices

The DCNM Licensed Devices feature allows you to control which physical devices that you can manage with licensed DCNM features. The feature maintains a list of licensed devices. If a device is on this list, you can manage licensed DCNM features on the device.

Event Browser Enhancements

The Event Browser in the DCNM client includes the following enhancements:

You can filter events in the Events Browser by the following criteria:

Event date and time

Event severity

You can view events that are up to 24 hours old when you start the DCNM client.

You can add a note to more than one event at a time.

New Features in Cisco DCNM Release 4.0(1a)

There are no new features available in Cisco DCNM Release 4.0(1a).

New Features in Cisco DCNM Release 4.0(1)

This release is the initial release of Cisco DCNM.

Cisco DCNM Release 4.0(1) includes the configuration and monitoring of the following NX-OS features:

Ethernet switching

Physical ports and port channels

Loopback and management interfaces

VLANs and private VLANs (PVLANs)

Spanning Tree Protocol, including Rapid Spanning Tree (RST) and Multi-Instance Spanning Tree Protocol (MST)

Network security

Access control lists

IEEE 802.1X

Authentication, authorization, and accounting (AAA)

Role-based access control

Dynamic Host Configuration Protocol (DHCP) snooping

Dynamic Address Resolution Protocol (ARP) inspection

IP source guard

Traffic storm control

Port security

General

Virtual Device Context

Gateway Load Balancing Protocol (GLBP), Object Tracking, and keychain management

Hardware resource utilization with Ternary Content Addressable Memory (TCAM) statistics

Switched Port Analyzer (SPAN)

DCNM includes the following features for assistance with management of your network:

Topology viewer

Event browser

Hardware inventory

DCNM includes the following administrative features:

DCNM server user accounts

Device discovery, including support for the Cisco Discovery Protocol

Automatic synchronization with discovered devices

Statistical data collection management

DCNM server and client logging

Installation Notes

For information about installing and uninstalling Cisco DCNM 4.0, see the Cisco DCNM Fundamentals Configuration Guide at the following website:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_0/dcnm/fundamentals/configuration/guide
/dcnm_fund_config.html

Caveats

This section includes the following topics:

Open Caveats—Release 4.0(4)

Open Caveats—Release 4.0(3)

Resolved Caveats—Cisco DCNM Release 4.0(4)

Resolved Caveats—Cisco DCNM Release 4.0(3)

Resolved Caveats—Cisco DCNM Release 4.0(2)

Resolved Caveats—Cisco DCNM Release 4.0(1a)

Resolved Caveats—Cisco DCNM Release 4.0(1)

Open Caveats—Release 4.0(4)

This section lists the open caveats for Release 4.0(4).

CSCsv14655

Symptom: The DCNM client failed to launch with Java versions later than 1.5.0_11.

Condition: If the required version of Java (1.5.0_11) is not installed on the DCNM client workstation, DCNM will redirect you to the download page of the latest update of Java version 1.5.0. If you install the latest update of Java version 1.5.0, the DCNM client will not launch.

Workaround: Manually install Java version 1.5.0_11 from http://java.sun.com/products/archive/j2se/5.0_11/index.html.

Open Caveats—Release 4.0(3)

This section lists the open caveats for Release 4.0(3).

CSCsl31907

Symptom: Discovery of a device repeats continuously, or new system messages do not appear in the Event Browser and corresponding status changes for all features are not updated. Any configurations changes are not reflected in DCNM.

Conditions: This issue occurs when one of the following conditions is true:

The system clock time or time zone of the device is changed either before or after device discovery to a time in the past.

The system clock time is set to a time in the past as a result of the end of summer time.

For example, a device has logs that contain messages with a time stamp of Tue Mar 25 16:00:00 UTC 2008. DCNM discovers the device when the device system time is Thu Mar 27 15:00:00 UTC 2008. Later, the device system time is changed to Tue Mar 25 15:00:00 UTC 2008. As a result, DCNM continuously discovers the device.

Workaround: On the CLI of the NX-OS device, clear the accounting log by using the clear accounting log command and clear the system log by using the clear logging logfile command. Using these commands causes DCNM to rediscover the device automatically.

CSCsl51966

Symptom: When you select a cell in a table in the summary pane and you use a keyboard shortcut, such as Ctrl+S (Save), DCNM performs the action of the shortcut but the selected table cell becomes editable. As a result, you must click elsewhere to stop editing in the cell.

Conditions: This issue occurs only when the selected summary table cell is editable.

Workaround: When an editable summary table cell is selected, use the menu bar or toolbar buttons instead of keyboard shortcuts.

CSCsl93917

Symptom: Filtering (Ctrl+F) does not work for any table that has grouped column headers.

Conditions: This issue occurs only with tables that have grouped columns.

Workaround: No workaround.

CSCsm09616

Symptom: While you are configuring loopback interfaces, you try to filter (Ctrl + F) with any column value, and the client displays an error message. Filtering occurs correctly anyway.

Conditions: Inconsistent

Workaround: No workaround.

CSCsm94859

Symptom: DCNM does not recognize the installation or uninstallation of a license on NX-OS devices.

Conditions: The user installs a license on an NX-OS device to enable licensed features, such as tunnels, but the user cannot use DCNM to manage the licensed NX-OS features.

Workaround: Use the Devices and Credentials feature to rediscover devices that have had an NX-OS license installed or uninstalled.

CSCsm17010

Symptom: The percentages shown next to the pie chart in the Event Browser overlap, which results in incorrect values being shown.

Conditions: This issue occurs when the Event Browser contains a large number of events for a particular severity and a very small number of events for the next severity.

Workaround: Make the pie chart bigger by clicking and dragging the bar below the charts. The DCNM client recalculates the pie chart when you resize the pane that contains the charts.

CSCso02217

Symptom: Starting a DCNM client that is already installed on a computer results in a dialog box that asks if you want to save shortcuts for the client.

Conditions: This issue occurs after you install the DCNM client on the computer by using a web browser to access the client on the DCNM server and you previously answered the same dialog box.

Workaround: Uninstall and reinstall the DCNM client. For information about installing and uninstalling the client, see the Cisco DCNM Fundamentals Configuration Guide at the following website:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_0/dcnm/fundamentals/configuration
/guide/dcnm_fund_config.html

CSCso19425

Symptom: Copying and pasting an entity (for example, VLANs, ACLs, etc.) from one device to another device fails to apply changes to the device.

Conditions: This occurs when you use the DCNM client to view the entities configured on a managed device, such as VLANs or ACLs, and someone uses a method other than DCNM to create a new entity. The DCNM client will automatically update shortly after the entity is added to the running configuration of the device, but if you try to copy the new entity and paste it into a different managed device, the operation fails in the DCNM server and changes are not applied to the device.

Workaround: Press F5 to refresh the DCNM client before copying and pasting the new entity.

CSCso28169

Symptom: Changes made for ACL Logging for VLAN in ARP ACL screen do not work.

Conditions: Choose Switching > Layer2 Security > ARP Inspection, and then change the configuration for ACL logging for a VLAN in the summary table or in the selected VLAN details panel.

Workaround: No work around. Currently, enabling ACL logging in the device is not supported.

CSCso29714

Symptom: While using DCNM to create a nondefault VDC in a physical device, if you accidently assign to the management interface of the new VDC the IP address that is already assigned to an existing nondefault VDC in that same physical device, then DCNM does not give a warning. After you deploy the configuration, DCNM shows the new VDC information for the previously created VDC.

Conditions: This issue occurs when you use a method other than DCNM to create a nondefault VDC on a physical device and configure the management interfaces of the default VDC and nondefault VDC, and then you use DCNM to discover both VDCs. While using DCNM to create another nondefault VDC, you assign to the management interface of the new VDC the same IP address that you previously assigned to the management interface of the existing, nondefault VDC. DCNM does not warn you and deploys the configuration to the device. After deployment, DCNM shows the new VDC information for the previously existing, nondefault VDC.

Workaround: Use the Devices and Credentials feature to rediscover the nondefault VDCs on the physical device.

CSCso35181

Symptom: DCNM has incorrect configuration data for a managed device after DCNM processes changes received from the device at the same time that you change the device configuration in the DCNM client.

Conditions: When you use a method other than DCNM to configure a managed device, the Auto Synchronization with Devices feature in DCNM retrieves the configuration changes from the device and updates the configuration data for the managed device in DCNM. If you use DCNM to make changes to the configuration of the managed device at the same time that DCNM is synchronizing with the device, the changes that you made with DCNM are not applied to the running configuration of the device. Also, the changes that you made to the device by a method other than DCNM are not reflected in DCNM client.

Workaround: Use the Devices and Credentials feature in DCNM to rediscover the device.

CSCso94565

Symptom: GLBP group state changes are not updated in summary and details panes.

Conditions: A GLBP group state on a managed device changes after the DCNM client has been started.

Workaround: Press F5 to refresh the GLBP pane.

CSCsq13902

Symptom: Inventory and Topology displays chassis state as managed when rediscovery fails.

Conditions: This issue occurs when DCNM fails to rediscover a device.

Workaround: No workaround.

CSCsq42300

Symptom: Even after the link between two Nexus 7000 Series devices comes up, the DCNM topology map does not show the links until the user refreshes the screen.

Conditions: Two devices are discovered by DCNM when the link between the two devices is down. After discovery, the link between the devices is restored by a means other than DCNM, such as by the CLI. The DCNM topology screen does not reflect the link status change until the user refreshes the topology screen.

Workaround: Press F5 to refresh the topology.

CSCsq51358

Symptom: For the Interfaces > Physical > Ethernet feature in the DCNM client, for a subinterface the Status Description field in summary pane is blank.

Conditions: When DCNM discovers a device that has a Ethernet subinterface or when someone creates a new subinterfaces by a means other than DCNM, the DCNM client does not display the available information in the Status Description field for the subinterface.

Workaround: No workaround.

CSCsq61332

Symptom: The DCNM client shows an incorrect power supply redundancy mode.

Conditions: Discover a Nexus 7000 Series device using the DCNM client. Using the inventory feature, choose the device in the summary table. In the details pane, choose the Environment Status tab. Under power supply redundancy, the administrative and operational modes appear.

Now access the command-line interface of the same Nexus 7000 Series device and use the power redundancy-mode redundant command to change the power supply redundancy mode.

The DCNM client continues to show the old power supply redundancy mode.

Workaround: In the DCNM client, go to the Inventory feature, choose any I/O module in the affected device, choose the Environment Status tab in the details pane, expand the Temperature Status Table section, change the Refresh Frequency to 30 seconds, and deploy the change.

Wait 30 seconds and press F5 to refresh the client. DCNM will show the new power supply redundancy mode.

CSCsq62414

Symptom: DCNM client does not launch with Java 1.4.2.

Conditions: When the client workstation has Java 1.4.2 installed, DCNM client does not automatically download and install Java 5, which is required to launch the application.

Workaround: Uninstall Java 1.4.2 or manually install Java 5.

CSCsq76212

Symptom: When you use the CLI to change a hostname, it is not displayed in the DCNM window for IPv4 ACL.

Conditions: Use DCNM to discover a Nexus 7000 device and then open the IPv4 ACL window to verify the device. Next, use the CLI to login to the same device and change the hostname of the device. DCNM shows the updated hostname except on the IPv4 ACL window.

Workaround: Refresh the IPv4 ACL screen.

CSCsq76959

Symptom: On DCNM client uninstall from control panel->Add remove Programs, it doesn't delete all the cached files stored in the client machine.

Conditions: This will happen when the client is uninstalled through control panel -> Add Remove Programs only.

Workaround: Uninstall the client as mentioned in DCNM Help, i.e from control panel -> Java Application Manager.

CSCsq77763

Symptom: An exception occurs when interfaces that are part of a removed module are associated with other features in any of the DCNM screens.

Conditions: Remove the module from a device, which was discovered by DCNM. DCNM still lists the interfaces for the removed module. When you try to modify the interface or try to associate the interfaces with any other feature, an exception occurs.

Workaround: No work around. The exception is harmless.

CSCsr37245

Symptom: Devices and Credentials screen shows duplicate rows for a device with the status "Discovering" and "Managed."

Conditions: Create new VDC by using the VDC wizard, select "Discover" check box in the final wizard screen, and then use the Devices and Credentials screen to show the newly created VDC.

Workaround: Refresh the Devices and Credentials screen.

CSCsr46487

Symptom: The DCNM uninstall is not clearing the database. Not able to login to DCNM server after installing 4.0(3).

Conditions: Uninstall DCNM version 4.0(1)/4.0(2) on server, and then install version 4.0(3).

Workaround: Clear the DCNM data base manually.

CSCsr53247

Symptom: Discovery of devices fails with an error "Error saving data to DB for <IP address>" or "Discovery of <IP address> failed due to server error."

Condition: Discovery could fail under any of the following conditions:

If the devices with directly connected links between them are discovered concurrently

If the devices are deleted when DCNM is discovering their directly connected neighbor devices

Workaround:

Discover the interconnected devices using a single discovery task by specifying appropriate hop count.

Run one discovery task at a time and wait for it to complete before creating a new discovery task.

CSCsr72829

Symptoms: Even though you have given the admin credential when the VDC is created through the DCNM (VDC wizard), when you try to get into the VDC (using the switchto command), the device is asks you to configure the admin user credential.

Conditions: The problem occurs when a weak password is configured for the admin user when the VDC is created using DCNM. NX-OS requires the following for a strong password:

The length of the password must be at least eight characters

The username and password cannot be the same, and the password cannot be the reverse of the username.

The password must include any three of the following types of characters:

- Lowercase letters

- Uppercase letters

- Digits

- Special characters (except the $ character)

The password should not be a word from a dictionary.

Since DCNM is not performing the validations mentioned above, and it only validates whether the password length is at least eight characters, if a user configures a nonstrong password, then DCNM will fail to validate the password, and the device will reject that password.

Workaround: Configure a strong password based on the above instructions when you create a VDC using DCNM.

CSCsr91447

Symptom: Configure a tunnel interface from DCNM or directly in the switch. DCNM will show an incorrect operational status for that tunnel interface.

Condition: Configure a tunnel interface from either DCNM or from switch CLI. DCNM will reflect that interface in the Tunnel Interface screen, but the operational status of that tunnel interface shown by DCNM will be incorrect. Reason for this problem is that DCNM relies on the syslogs from the switch to update the tunnel interface operation status. So whenever the tunnel interface operation status changes, the switch has to send a status change syslog for that tunnel interface similar to the status change syslogs it is sending for other physical ports and SVIs. However, with a tunnel interface, there are no status change syslogs generated from the switch, so DCNM will show incorrect operational status for that tunnel interface.

Workaround: Rediscover the device.

CSCsr95739

Symptoms: Sometimes DCNM shows the same device twice with a different host name.

Conditions: Discover an Nexus 7000 switch in DCNM. Now, go to the CLI of that switch and perform the following configuration:

"cdp format device-id serial-number" 

After few minutes, re-discover the same device in DCNM. You will see two device entries in DCNM, even though you discovered and rediscovered the same device. This is because DCNM uses the serial number to uniquely identify a chassis. And it picks that information from the Device-ID field in show cdp neighbor detail command output. By default, that field either shows the host name (Release 4.0(2) or earlier), or both hostname and serial number (Release 4.0(3) and afterwards). If you configure using the above command and force the CDP to show the serial number alone in the "Device-ID" field, then DCNM cannot handle it.

Workaround: Do not use the cdp format device-id serial-number command. Use the default format.

CSCsr96608

Symptom: Some of the tunnel interface attributes, like MTU, Path MTU and Keepalive, are not available in tunnel interface screen.

Condition: Go to the Tunnel screen in DCNM (Interfaces > Logical > Tunnel). Select a tunnel interface from the summary panel and the details panel will display its corresponding details. There are no DCNM provisions to configure the MTU, Path MTU and Keepalive parameters for the tunnel interface.

Also, if the attributes are configured in the device for a tunnel interface, then DCNM is not allowing users to modify the other parameters of those tunnel interfaces.

MTU, Path MTU and Keepalive parameters will be supported in next release.

Also, if you have configured those attributes in the device for a tunnel interface, then those interfaces attributes/parameters cannot be modified by using DCNM. Modifying them will result in an error message.

Workaround:

MTU, Path MTU and Keepalive parameters will be supported in next release.

If you want to use DCNM to modify the tunnel parameters, then make sure that the tunnel interface is not configured with mtu, path-mtu and keep alive settings in the device. If they are configured, then remove those configurations from the device.

CSCsr99977

Symptom: When the client session has expired after the client is idle for 24 hours and the user selects a feature that was not visited earlier, the user is notified and logs in again. The screen for the selected feature fails to load.

Conditions: This issue occurs only when the session has expired and the user selects a feature not visited earlier.

Workaround: Close the client and relaunch it.

CSCsu02090

Symptom: The discovery of devices with a hop count of 1 or more above shown as successful even though some of the discovered devices are shown as unmanaged.

Condition: The device cannot discover neighbor devices if probing fails for the device, but the status of the device discovery may be shown as successful.

Workaround: Discover the neighbor device with pointed discovery.

Resolved Caveats—Cisco DCNM Release 4.0(4)

This section describes possibly unexpected behavior by Cisco DCNM Release 4.0(3). All the caveats listed in this section are resolved in Cisco DCNM Release 4.0(4).

CSCsu09693

Symptom: Discovery of the device happens every minute.

Condition: The DCNM server should be running in a Japanese windows operating system.

Workaround:

1. Stop the DCNM server.

2. Edit <DCNM_INSTALL_DIR>/config/dcnm-wrapper.conf and add the following lines:

wrapper.java.additional.10=-Duser.region=US 
wrapper.java.additional.11=-Duser.language=en  

3. Start the DCNM server. If DCNM is installed in the default directory, then you can find the dcnm-wrapper.comf file by using the C:\Program Files\Cisco Systems\DCNM\config\ path.

CSCsu40214

Symptom: A new Data Center Network Manager (DCNM) installation will not work because the PostgreSQL database service is offline.

Conditions: If a system administrator installs DCNM on a Red Hat Enterprise Linux (RHEL) system using the default values, the wizard that communicates those values might not work with the shared memory but the installation can complete successfully. The amount of shared memory defined during the install is not enough for PostgreSQL to start preventing this service from being active. PostgreSQL must be active for DCNM to work as expected.

Workaround: Before installing the system, you should increase the values of the maximum and allowed shared memory as follows:

$ sysctl -w kernel.shmmax=134217728

$ sysctl -w kernel.shmall=2097152

In addition, you can save these settings between reboots in the /etc/sysctl.conf file. Once configured, these values can be confirmed by using the ipcs -m command.

CSCsu45271

Symptom: During the DCNM installation process in a Red Hat Enterprise Linux (RHEL) system, the installation wizard can report an error. The error reads: "Unable to generate DCNM Instance ID. Could not find MAC address for this linux OS!"

Conditions: During the installation of Release 4.0(3) on a RHEL 4.1(6), the installation wizard can report a DCNM Instance ID error.

Workaround: No workaround.

CSCsv09138

Symptom: PostgreSQL will not start after rebooting the DCNM server Linux machine.

Condition: Linux shared memory settings are too low to run PostgreSQL.

Workaround: Configure a maximum total shared memory size that is greater than 128 MB by using the sysctl -w kernel.shmmax=134217728 command. Save this setting in the /etc/sysctl.conf (kernel.shmmax=134217728) to enable PostgreSQL to start.

For more information, see http://www.postgresql.org/docs/8.2/interactive/kernel-resources.html.

Resolved Caveats—Cisco DCNM Release 4.0(3)

This section describes possibly unexpected behavior by Cisco DCNM Release 4.0(2). All the caveats listed in this section are resolved in Cisco DCNM Release 4.0(3).

CSCsm94621

Symptom: When you use the DCNM client to enable an NX-OS feature that requires a license and the NX-OS device does not have the required license installed, the client does not display the error message reported by the NX-OS device.

Conditions: This issue occurs whenever you attempt to enable a licensed feature in NX-OS without first installing the required license on the NX-OS device.

Workaround: No workaround.

CSCsq03181

Symptom: Some of the columns in the GLBP summary pane, such as the Active Gateway and Forwarder Count columns, are not populated with data.

Conditions: This issue occurs when you configure a GLBP group for an interface that is administratively and operationally up.

Workaround: Rediscover the device.

CSCsq36359

Symptom: When you use a DCNM client to move an interface from the default VDC to a custom VDC, other DCNM clients that use the same DCNM server do not reflect the change to interface allocation until you refresh the client screens.

Conditions: A DCNM server manages a device that has one default VDC and one custom VDC, two or more users each run a DCNM client that uses the same DCNM server, and one user uses a DCNM client to move an interface from the default VDC to the custom VDC.

Workaround: In DCNM clients that do not show the change, press F5 to refresh the VDC screen.

CSCsq40843

Symptom: The statistics charts for interfaces fail to update if the monitored device is reloaded.

Conditions: The device is reloaded when DCNM is monitoring statistics from the device.

Workaround: Stop and restart the statistics charts.

CSCsq42244

Symptom: The topology map sometimes displays duplicate links in the tool tip and properties panel after DCNM rediscovers devices and links.

Conditions: DCNM rediscovers devices.

Workaround: Press F5 to refresh the topology.

CSCsq42267

Symptom: When a link is down, the topology map does not reflect changes to the administrative status of the ports that correspond to the link.

Conditions: The administrative status of the ports is modified when the corresponding link is down.

Workaround: When the link is down, view the configuration and status of the ports using the Interfaces feature.

CSCsq44035

Symptom: DCNM cannot manage the rate mode for ports in a 32-port 10-GB Ethernet module, part number N7K-M132XP-12.

Conditions: DCNM does not include provisions for configuring the port rate mode in the 32-port 10-GB Ethernet module, part number N7K-M132XP-12.

Workaround: No workaround.

CSCsq50211

Symptom: After you click a column heading to sort items on a list of available items, when you move an available item to a list of selected items, the wrong item appears in the selected items list.

Conditions: This issue occurs when you sort the list of available items while you configure the following lists:

In the Security > RBAC > Roles feature, when you have selected a role on a device, on the Details tab, General area, the Permitted VLANs, Permitted Interfaces, and Permitted VRFs lists.

In the Switching > Spanning Tree > MST feature, when you have selected a MST instance on a device, on the Details tab, MST Setting area, and the VLANs list.

Workaround: Do not use column headings to sort the list of available items.

CSCsq56112

Symptom: The DCNM Licensed Devices summary pane fails to show a nondefault VDC after successful discovery.

Conditions: This issue occurs when you follow the steps below:

1. Install a license on the DCNM server.

2. Use the DCNM client to discover the default VDC on a device.

3. Use the DCNM Server Administration > DCNM Licensed Devices pane to add the device that you discovered to the list of licensed devices.

4. Use the DCNM client to discover a nondefault VDC on the device.

5. View the DCNM Licensed Devices pane again, where the list of licensed devices will not include the newly discovered VDC in the row for the device.

Workaround: Press F5 to refresh the DCNM client.

CSCsq58138

Symptom: The DCNM installation application does not install license files even though you specified the correct directory for the license files during installation.

Conditions: This issue occurs when any executable files are in the directory that contains the license files.

Workaround: Keep the license files in a directory that contains no other files. During the license installation, specify the directory that contains only license files.

CSCsq60246

Symptom: For the Switching > VLAN feature in the DCNM client, if you select a VLAN in the summary pane, use the details pane to change the VLAN name without pressing Enter, and select any other VLAN in the summary pane, then the name of the other VLAN changes instead of the VLAN that you originally selected.

Conditions: This issue occurs when you change the VLAN name by using the details pane, do not press Enter, and select a different VLAN in the summary pane.

Workaround: Do one of the following:

After changing the VLAN name in the details pane, press Enter.

After changing the VLAN name in the details pane, select the same VLAN in the summary pane before selecting a different VLAN.

Change the VLAN name in the corresponding row in the summary pane.

CSCsq68569

Symptom: After you perform an In Service Software Upgrade (ISSU) on a Nexus 7000 Series device that has two supervisor modules and that is managed by DCNM, the Inventory feature in the DCNM client shows only one supervisor module.

Conditions: This issue occurs in two conditions:

1. On a Nexus 7000 Series device with two supervisor modules, you perform an ISSU from image X to image Y. After you complete the ISSU, the DCNM client shows only one supervisor module.

2. On a Nexus 7000 Series device with two supervisor modules, when you remove the standby supervisor module, the DCNM client removes the standby supervisor module from the Inventory feature. If you reinstall the supervisor module in the Nexus 7000 Series device, the DCNM client does not show the newly installed supervisor module.

Workaround: After performing an ISSU or installing a supervisor module in a managed Nexus 7000 Series device, use the DCNM client to rediscover the device.

CSCsq70267

Symptom: For the Switching > Layer 2 Security > Port Security feature, when you try to view the overview chart on the Statistics tab, the statistics do not appear in the overview chart and the message "Loading Data. Please wait." appears.

Conditions: The issue occurs intermittently.

Workaround: No workaround.

CSCsq74997

Symptom: For the Interfaces > Logical > SVI feature, the IP address and netmask that you configure for an SVI is not deployed to devices and the DCNM client shows blank values for the IP address and netmask.

Conditions: In the Interfaces > Logical > SVI feature, when you double-click the IP Address or NetMask fields in the summary table but you do not specify any values, and then you specify an IP address and a netmask in the details pane, the configuration for the IP address and netmask is lost when you deploy the configuration.

Workaround: Specify the IP address and the netmask in the summary table, or do not double-click the IP Address and Netmask field in the summary table before configuring these values in the details pane.

Resolved Caveats—Cisco DCNM Release 4.0(2)

This section describes possibly unexpected behavior by Cisco DCNM Release 4.0(1a). All the caveats listed in this section are resolved in Cisco DCNM Release 4.0(2).

CSCsk17175

Symptom: Creation of SVI fails inconsistently from GUI.

Conditions: On the Interfaces > Logical > SVI screen, you try to create an SVI, or on the Switching > VLAN screen, you try to create an SVI for a selected VLAN.

Workaround: No workaround.

CSCsl44105

Symptom: After you disable and reenable the DHCP snooping feature, the Dynamic ARP Inspection configuration for VLAN 1 still appears in the client even though it should have been cleared.

Conditions: On the Switching > ARP Inspection screen and the Switching > VLAN screen, the client still shows the Dynamic ARP Inspection configuration for VLAN 1 after you enable and disable the DHCP snooping feature.

Workaround: No workaround.

CSCsm76086

Symptom: The Topology Tree view, which shows VDCs within a physical device, is not consistent with the topology after the device becomes unmanaged or deleted.

Conditions: This issue occurs when DCNM discovers a device and you use the Topology feature to view the device, use the Devices and Credentials feature to change the device status to Unmanaged, return to the Topology feature, and then compare the Topology Tree to the topology map.

Workaround: Press F5 to refresh the screen. Any deleted devices disappear and the Topology Tree becomes consistent with the current topology.

CSCsm82493

Symptom: The DCNM client does not display any status information for GLBP. The status information includes GLBP gateway and forwarder information.

Conditions: This issue occurs with any GLBP group configuration.

Workaround: No workaround.

CSCso08098

Symptom: If you use the CLI of a managed device to create a role with rules that permit or deny specific configuration commands, DCNM never updates its role configuration data for the device with these changes.

Conditions: After the initial discovery of a device by DCNM, if you perform some configuration tasks on the device without using DCNM, such as using the CLI, the Auto Synchronization with Devices feature keeps the DCNM configuration data for the device up to date by periodically checking the running configuration of the device and status-change system messages from the device. However, if you configure a role with rules to permit or deny specific configuration commands, DCNM may fail to parse role configuration changes, which results in inaccurate role configuration data for that device in DCNM.

For example, DCNM may not successfully synchronize its configuration data with the following commands, using the CLI:

switch(config)# role name test 
switch(config-role)# rule 1 permit command config terminal ; aaa * 
switch(config-role)# exit 

If the command that you are trying to permit or deny contains a semicolon (;), then those configurations are not updated in DCNM.

Workaround: Either use DCNM to configure such roles and rules, or after using the CLI to configure roles, rediscover the device with DCNM so that DCNM has correct configuration data for the device.

CSCso12073

Symptom: When you remove an I/O module, DCNM shows the change only on the Inventory pane. Other DCNM features still show the interfaces on the removed I/O module and allow you to make configuration changes to those interfaces.

Conditions: For example, if DCNM discovers a Nexus 7000 Series device that has three 48-port I/O modules, initially the device is shown properly in the DCNM client. If you power down an I/O module on the device by using the CLI or if the device powers down the I/O module due to another reason, DCNM reflects the change to the I/O-module status in the Inventory screen but the Interfaces screen continues to show the interfaces on the powered-down module as available for configuration.

Workaround: After an I/O module is powered down, use the Devices and Credentials feature in DCNM to rediscover the device.

CSCso29990

Symptom: The rows in the summary table appear blank.

Conditions: After you drag and drop column headings so that the heading that appears in the first column is changed, the values in the summary table rows disappear.

Workaround: Restart the client.

CSCso39685

Symptom: Even though a Nexus 7000 Series device can have a maximum of three power supplies, the Inventory feature in the DCNM client may show more than three power supplies in the chassis.

Conditions: Using DCNM, you discover a Nexus 7000 Series device that has three power supply units. The Inventory feature shows correct information about the power supplies. If you remove one of the power supply units from the device, DCNM updates the Inventory correctly. But when you replace the power supply unit in the device, DCNM shows four power supply units, which is incorrect.

Workaround: After removing and reinserting a power supply unit in a physical device, in DCNM, use the Devices and Credentials feature to rediscover the devices on that physical device.

CSCso44620

Symptom: The DCNM client does not permit you to configure dead-time interval of 0 (zero) for AAA (RADIUS/TACACS+) servers.

Conditions: This issue occurs when you attempt to configure the dead-time interval for a AAA server.

Workaround: Use the CLI of the NX-OS device to configure a dead-time interval of 0.

CSCso44669

Symptom: You cannot start statistical monitoring for an access control list (ACL).

Conditions: The ACL contains a remark that is not the last entry in the ACL.

Workaround: Either remove all remarks from the ACL or move any remarks to the end of the ACL.

CSCso47585

Symptom: After you enter a VLAN ID for a new VLAN and click the Deploy button in the File toolbar or press CTRL + S (without pressing Enter or Tab), DCNM does not deliver the configuration changes to the managed devices.

This issue also occurs during the creation of VLAN interfaces and port-channel interfaces.

Conditions: This issue occurs when you try to create a new VLAN, port channel, or VLAN interface, and then you click the Deploy button in the File toolbar without first pressing Enter or Tab.

Workaround: After entering the ID for the new VLAN, SVI, or port channel, press Enter or Tab, and then click the Deploy button in the File toolbar.

CSCso50106

Symptom: You cannot select more than four interfaces and change the administrative status of the interfaces.

Conditions: On the Interfaces > Physical > Ethernet screen, the Ethernet menu options Admin Up and Admin Down are not available if you select more than four interfaces.

Workaround: Select less than five interfaces.

CSCso78061

Symptom: The module status does not display correctly on the inventory screen and the following message appears on the DCNM server console:

ERROR [STDERR] java.lang.IllegalArgumentException: CardOperationalStatus keyword name 
[mod_status_online/ok.] does not exist

Conditions: This issue occurs when you install Cisco NX-OS Release 4.0(1a) software on the device.

Workaround: No workaround.

Resolved Caveats—Cisco DCNM Release 4.0(1a)

There are no resolved caveats for Cisco DCNM Release 4.0(1a).

Resolved Caveats—Cisco DCNM Release 4.0(1)

This was the first release for the Cisco DCNM software.

Related Documentation

Cisco DCNM documentation is available at the following URL:

http://www.cisco.com/en/US/products/ps9369/tsd_products_support_series_home.html

The documentation for Cisco DCNM includes the following:

Cisco DCNM Getting Started with Virtual Device Contexts, Release 4.0

Cisco DCNM Fundamentals Configuration Guide, Release 4.0

Cisco DCNM Interfaces Configuration Guide, Release 4.0

Cisco DCNM Layer 2 Switching Configuration Guide, Release 4.0

Cisco DCNM Security Configuration Guide, Release 4.0

Cisco DCNM Unicast Routing Configuration Guide, Release 4.0

Cisco DCNM Virtual Device Context Configuration Guide, Release 4.0

Cisco DCNM Web Services API Guide, Release 4.0

The Release Notes for upgrading the FPGA/EPLD is available at the following URL:

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_0/epld/release/notes/epld_rn.html

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS Version 2.0.