Downloads |
Table Of Contents
Cisco DCNM Release Notes, Release 4.0
Supported Device Operating Systems
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)
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)
Obtaining Documentation and Submitting a Service Request
Cisco DCNM Release Notes, Release 4.0
Release Date: November 3, 2008Part Number: OL-16035-05 A0This 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.
Contents
This document includes the following sections:
•
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
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:
•
The minimum hardware requirements for the DCNM server running on Windows Server 2003 are the following:
–
–
–
•
The minimum hardware requirements for the DCNM server running on Linux are the following:
–
–
–
Additionally, the following prerequisites must be in place for 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:
•
•
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:
•
•
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)
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:
Note
Installation Features
The installation of this release includes the following new features:
•
•
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:
•
–
–
•
•
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:
•
–
–
–
–
•
–
–
–
–
–
–
–
–
–
•
–
–
–
–
DCNM includes the following features for assistance with management of your network:
•
•
•
DCNM includes the following administrative features:
•
•
•
•
•
Installation Notes
For information about installing and uninstalling Cisco DCNM 4.0, see the Cisco DCNM Fundamentals Configuration Guide at the following website:
Caveats
This section includes the following topics:
•
•
•
•
•
Open Caveats—Release 4.0(4)
This section lists the open caveats for Release 4.0(4).
•
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).
•
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:
–
–
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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:
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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:
–
–
Workaround:
–
–
•
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:
–
–
–
- Lowercase letters
- Uppercase letters
- Digits
- Special characters (except the $ character)
–
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.
•
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.
•
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.
•
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.
–
–
Workaround:
–
–
•
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.
•
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).
•
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=USwrapper.java.additional.11=-Duser.language=en3. 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.
•
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:
–
–
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.
•
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.
•
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).
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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:
–
–
Workaround: Do not use column headings to sort the list of available items.
•
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.
2.
3.
4.
5.
Workaround: Press F5 to refresh the DCNM client.
•
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.
•
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:
–
–
–
•
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.
2.
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.
•
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.
•
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).
•
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.
•
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.
•
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.
•
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.
•
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)# exitIf 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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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.
•
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 existConditions: 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:
•
•
•
•
•
•
•
•
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.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2008 Cisco Systems, Inc. All rights reserved.
