Table Of Contents
Release Notes for the Cisco WAN Manager, Release 16.0.00 P1
These release notes are for use with the Cisco WAN Manager (CWM) 16.0.00 P1 software release that supports MGX, BPX, and IGX switches. To locate the documentation for 16.0.00 P1, visit the following location:
To locate the documentation for specific switches, see the link provided in General Link for Switch Documentation.
Document Revision History
The Document Revision History table records changes made to this document since its initial release. The table shows the document revision number for the change, the date of the change, and a brief summary of the change.
Revision Date Change Summary
Added information on Apache server requirements to System Requirements section. For more information, see Apache Web Server Requirements.
Added bug details of CSCta95976 to the section, Caveats
A note added to the CWM Server System Requirements section.
New Features and Enhancements
This section describes the features and enhancements introduced in CWM 16.0.00 P1. For details, refer to the appropriate guides, such as the Cisco WAN Manager User Guide, 16.0.00, Cisco WAN Manager SNMP Service Agent Guide, 16.0.00, Cisco WAN Manager Installation Guide, 16.0.00. See Related Documentation, for a list of the CWM documents.
Trap Resiliency and Support for Offline CWM Machine
When excessive traps are received from a switch, the online CWM marks this node as unmanageable by deregistering from the switch. Because the online CWM stops receiving traps from the deregistered and unmanaged switch, the OSS does not receive traps from online CWM.
That switch is added as a standalone node to the offline1 CWM, which syncs up with the switch and starts managing the node so that the OSS will continue to receive traps from the switch via the offline CWM. The offline CWM machine (backup) started managing the excessive traps. This feature is supported on all MGX devices.
With this option, the OSS can continue to receive traps from these switches through the offline CWM. These nodes are managed as standalone nodes by the offline CWM server.
The following are the prerequisites for using the feature:
•This feature should be enabled only in the online CWM servers during installation. This feature should not be enabled for offline CWM.
•RtmProxy should be installed on the online and offline CWM machines, and the OSS must be registered with RtmProxy on both machines.
•The offline CWM should be running with a dummy network.
•To establish communication between online CWM machine and offline CWM machines, configure SSH Authentication without Password for an svplus user by manually exchanging and copying public authorization keys to /usr/users/svplus/.ssh/authorized_keys file. For the procedure for manually creating and exchanging public authorization keys between two machines, refer the section Secure Connection between CWM Servers.
•Configure the following parameters for both the online and the offline CWM servers:
–In /usr/users/svplus/config/agent++.conf file, change the parameter ENABLEV3 to 0 (insecure mode); the community strings should be same as that of snmpd.cnf file.
–In /usr/users/svplus/config/svplus.conf set NETWORKSNMPVERSION to V1_ONLY.
•Configure the following parameters for the online CWM server:
–In /usr/users/svplus/config/nts.conf file, set HIGH_TRAP_NODE_AUTO_SHUTOFF to 1 (enable).
Ensure that the flag CWM_OFFLINE_MGMT is set to 1.
Set the parameter of OfflineCwmIP to the IP address of the offline CWM server.
By default, TrapResilencyMgrPort is set to 3500. If port 3500 is engaged, set the port number to any other unused port.
•Configure the following parameters for the offline CWM server:
–In /usr/users/svplus/config/nts.conf file, set HIGH_TRAP_NODE_AUTO_SHUTOFF to 0 (disable).
–In /usr/users/svplus/config/nts.conf file, set CWM_OFFLINE_MGMT to 0 (offline machine).
When the online CWM machine starts receving excessive traps, it deregisters from the switch by generating a newly-defined CWM trap 28502. The new trap 28502 will be added to the newly-created Group 27 in the trap_filters.conf file. This trap should not be added to any other groups. The CWM forwards this trap to both RtmProxy and port 162.
As soon as the fault on the switch is fixed, unblock the node in online CWM using ntsControl by choosing the option "ubtn". The node will then be deleted from offline CWM, and online CWM starts managing the nodes again. The offline CWM automatically deregisters from switch.
Support for SFTP on NBSM Cards
Secure File Transfer Protocol (SFTP) support has been added for secure uploading and downloading of configuration and statistics files to and from the CWM server. Release 16.0.00 P1 provides SFTP support for configuration upload and statistics files, for the NBSM cards.
The SFTP credentials are stored in the same fields used for FTP credentials.
By default, CWM uses FTP. To use SFTP, you must specify SFTP as the file transfer protocol in the CWM configuration file [cwmftpd.conf], and ensure that SFTP is enabled on the MGX. The configuration parameter is FILE_TRANSFER_PREFERENCE. The value 0 indicates FTP and 1 indicates SFTP.Ensure that in MGX, in the F:SSHD directory, the sshd_config file contains the following option: PasswordAuthentication yes
This feature is supported on the PXM1E and PXM45 series platforms, and with SNMPv1 or SNMPv3, as configured.
Secure Connection between CWM Servers
In 16.0.00 P1, all remote shell operations have been migrated to Secure Shell (SSH) for enhanced security.
CWM Gateway—It is not mandatory to enable the secure remote authentication between the CWM gateway machines. You can also configure your gateways for SSH Authentication without Login. In that case, for a secured remote authentication, you have to manually register the authentication keys for the Solaris machines that will be present in the gateway or offline setup. The authentication key has to be created for svplus user by choosing either RSA or DSA encryption with either SSH1 or SSH2 protocol version respectively.
Offline CWM—To establish communication between CWM and offline CWM machines, configure SSH Authentication without Password for an svplus user by manually exchanging and copying public authorization keys to /usr/users/svplus/.ssh/authorized_keys file. You have to manually create the authorization keys and authorized_keys file.
The following steps will help you create and exchange public keys between two machines:
Step 1 Login as svplus user.
Step 2 Create an .ssh directory under /usr/users/svplus.
Step 3 Create a file name authorized_keys.
Step 4 Create a public key in the id_rsa.pub file by executing
ssh key gen.
ssh-keygen -t rsa
Step 5 Copy the public key to the other remote CWM machine using the following command:
cat id_rsa.pub | ssh <remote cwm hostname> 'cat >> .ssh/authorized_keys'
cat id_rsa.pub | ssh tballraker7 'cat >> .ssh/authorized_keys'
Step 6 The first time you log in, you will be prompted to enter the remote machine 'svplus' user password. Enter the password.
SNMPv3 Northbound Support
The CWM can now send traps to external OSS managers in SNMPv1 or SNMPv3 mode, depending on the manager's registration. Previously, only SNMPv1 traps could be used.
The SNMP version is identified using a new MIB called "managerTrapVersion" during registration, and the default is SNMPv1. If the version is SNMPv3, the security name should be specified.
Agent Mode in SNMPv3 Mode
If the agent mode is SNMPv3:
1. The manager will be registered with RtmProxy through an SNMPv3 request only.
2. While registering, the managerTrapVersion should be 3 and the security name should be provided [cisco].
Note The manager cannot register to receive SNMPv1 traps when the agent is in fully secured mode.
Agent Mode in SNMPv1 Mode
If the agent mode is SNMPv1:
1. The manager will be registered with RtmProxy through an SNMPv1 or SNMPv3 request.
2. The OSS can be registered with RtmProxy using the managerTrapVersion 1 or 3 to receive SNMPv1 traps or SNMPv3 traps respectively.
The following tips will help you configure SNMPv3 Northbound Support:
You can specify the following keywords in the agent++.conf file:
–AGENTLOGFILE—Specifies the log file name.
–ENABLEV3—Specifies the mode of the SNMP Agent. If it is set to 1 (secure mode), the CWM responds only to SNMPv3 requests. If it is set to 0 (unsecure mode), the CWM responds to SNMPv1 requests, as well as to SNMPv3 requests.
–LOG_ENABLE—Specifies if events should be written on the log file, or not logged (To achieve better performance, disable logging by changing the
LOG_ENABLEvalue to 0)
–READ_COMMUNITY—Specifies the Read-Only Community String of the agent.
–WRITE_COMMUNITY—Specifies the Read and Write Community String of the agent.
The snmpd.cnf file in the /usr/users/svplus/config directory should have the same READ_COMMUNITY and WRITE_COMMUNITY values as that of agent++.conf file.
For all USM updates, you must send an HUP signal to the agent process and RtmProxy process.
When you change ENABLEV3 from 0 (insecure mode) to 1 (secure mode) in agent++.conf file, you should send the HUP signal to agent processes and rtmProxy process. Also, you must send the USR2 signal to the RtmProxy to deregister all of the v1 managers.
The usm.conf file contains the list of users and passwords that are generated using the USM tool in /usr/users/svplus/tools/snmp (By default, Cisco is the username and password. MD5 and DES are used for authProtocol and PrivacyProtocol respectively.).
The CWM Agent supports only the USM security model. It supports MD5 and SHA as authProtocol, and DES and AES128 as privProtocol.
The external OSS must be SNMPv3 compliant.
The port number 8170 should be opened for agent to agent communication within CWM server.
For additional information about registering the OSS in RtmProxy, see the CWM 16.0.00 Service Agent User Guide.
Enabling V1 Provisioning Using the MasterAgent
The default provisioning option, using the agent process, is v1 and v3. But the additional security feature that is provided for SNMPv3 may slow down the processing of SNMPv3 provisioning requests; it may be slower than that of SNMPv1. If the OSS applications are not configured for SNMPV3 features, we recommend that you enable the MasterAgent with only V1 to improve the speed of processing of provisioning requests.
To enable v1 provisioning using the MasterAgent, do the following:
Step 1 Login as svplus user.
Step 2 Stop the core.
Step 3 Update the SR_SNMP_TEST_PORT to 8161 in /usr/users/svplus/.cshrc file.
Step 4 Take a backup of the files /usr/users/svplus/config/process.conf, /usr/users/svplus/config/startup.conf, and /usr/users/svplus/scripts/plist.txt.
Step 5 Comment out the process agent in the following files:
–/usr/users/svplus/config/process.conf (#agent on off. agent)
–/usr/users/svplus/config/startup.conf (#agent: MasterAgent)
Step 6 Update the ENABLEV3 to insecure mode in /usr/users/svplus/config/agent++.conf (ENABLEV3 0).
Step 7 Set the .cshrc by executing source /usr/users/svplus/.cshrc.
Step 8 Start the CWM core.
To revert to the default settings, do the following:
Step 1 Login as svplus user.
Step 2 Stop the core.
Step 3 Update the SR_SNMP_TEST_PORT to 8170 in /usr/users/svplus/.cshrc.
Step 4 Uncomment the process agent in the following files:
–/usr/users/svplus/config/process.conf (agent on off. agent)
–/usr/users/svplus/config/startup.conf (agent: MasterAgent)
Step 5 Update ENABLEV3 flag in /usr/users/svplus/config/agent++.conf:
–0—To handle both V1 and V3 requests
–1—To handle only V3 requests
Step 6 Set the .cshrc by executing source /usr/users/svplus/.cshrc.
Step 7 Start the CWM core.
Supported Switch Platforms and Software Releases
Table 1 shows the BPX, IGX, and MGX switch platforms and releases that the CWM 16.0.00 P1 software supports.
For additional information on supported products, see Releases Certified for CWM 16.0.00 P1.
Note The CWM does not support the VXSM card configured for VoIP. The Cisco Transport Manger (CTM) supports this functionality.
Note As of CWM 12.0, the CWM does not support these cards: the BME card and the FRSM12, URM, ARM, FRM, BTM, ALM and CVM service modules.
Note The software releases provided in this section are not tested with CWM 16.0.00 Patch1. However, CWM should be able to perform as expected with the older releases. Issues arising from platforms that have been notified as End of Support (EoS) will not be addressed by Cisco.
Releases Certified for CWM 16.0.00 P1
Table 2 lists the shelf or switch software releases that were used to test the CWM 16.0.00 P1 software. Although CWM 16.0.00 P1 supports other releases, the releases listed in the table are the specific releases that were tested for CWM 16.0.00 P1.
For links to the documentation for cards, see the list of Release Notes at this location:
CWM 16.0.00 P1 Packaging and Basic Data
This section describes CWM 16.0.00 P1 and its associated software. The latest CWM version, 16.0.00 P1, and its associated software can be downloaded from the Cisco website. Note that this patch release is not available on CD_ROM. Table 3 describes CWM and associated software of 16.0.00. The details listed in this table apply to this patch release of CWM as well.
Note For this patch, ensure that you download the associated software from the Cisco website. However, you can continue to use the 16.0.00 versions of Cisco WANDEST, Cisco Automated Bulk Provisioning (ABP) Tool, and Cisco WAN Modeling Tools.
The required software for the CWM system are the following:
•CWM Server software
•Solaris platform and required patches
•CWM Java Client
•Web browser to launch the online help. Cisco recommends that you use Netscape 4.76 or later, or Internet Explorer 6.0 or later.
Table 3 describes the required and optional CWM software. The CWM Software Evaluation package includes all CWM CDs and functionality. All CWM features are available until the 45-day evaluation period expires.
When you launch the CWM, you can also access additional information about getting started. In the CWM Client Launcher, you can click the Help tab for this information:
•Accessing online help and documentation
•Installing Java Web Start
•Installing on Solaris and Windows platforms
•Configuring Netscape for Using Web Start on Solaris platforms
The following table describes the CWM baseline package, 16.0.00, and its associated software.
Table 3 CWM 16.0.00 and Associated Software
Informix 9.40 UC8
Java Development Kit (JDK)
The CWM Server software is part of the CWM package and required for installation.
As part of the JDK, CWM Java Client is deployed using Java Web Start, which is a deployment tool that uses the Java Network Launching Protocol (JNLP) to manage Java applications from a centralized server. These applications are cached and run locally on Windows 98, NT, 2000, or XP or on a Solaris client.
Java Web Start is bundled with the Java 2 Platform, Standard Edition (J2SE), v1.5 and above. To start using Web Start applications, download the latest J2SE v 1.5.x Java Runtime Environment (JRE) for your operating system (OS) from the SUN website.
CWM documentation in PDF format
Part of the CWM package.
(The gzip command is gzip -d.)
Note The Release Notes for Cisco WAN Manager, 16.0.00 P1 is available on Cisco.com at http://www.cisco.com/en/US/products/sw/netmgtsw/ps2340/prod_release_notes_list.html.
CWM SNMP Service Agent
This CD must be ordered separately from the CWM Client/Server package CD set.
Note This patch release is not available on CD_ROM.
Although SNMP Service Agent is not required to run the CWM, it can provide provisioning and fault management to the upper layer OSS. It is not required for an SCMSA workstation.
The SNMP Service Agent CD also contains the tar file for updating the CIC so that it can function with the CWM system.
Standalone Statistics Collection Manager
This CD must be ordered separately from the CWM package CD set.
Note This patch release is not available on CD_ROM.
The SCMSA software includes the Cisco WAN Database Extraction and Synchronization Tool (WANDEST) client software (for communicating with the CWM server) and the Informix server software.
RtmProxy for the SCM application
RtmProxy for SCM Application
This application is included on a separate CD with the SCM software only when you order that software. It is meant to be installed only with the SSM and not on systems using the Service Agent. If you have already installed the Service Agent software and you attempt to install this application, you will see errors because the ~/config/process.conf file has duplicate entries for the RtmProxy.
To install the RtmProxy for the SCM application from the CD, refer to the CWM installation guide.
Note This patch release is not available on CD_ROM.
This two-CD set must be ordered separately from the CWM set.
Note This patch release is not available on CD_ROM.
WANDEST is software that enables the CWM system to communicate with the operational support system (OSS) or other telco applications. The OSS applications use WANDEST to keep their databases synchronized with the CWM (stratacom) database.
Cisco Automated Bulk Provisioning (ABP) Tool
Cisco Automated Bulk Provisioning Tool
This CD must be ordered separately from the CWM set.
The ABP tool is a time-based provisioning system that enables you to schedule connection and port-provisioning jobs. It is standalone software that resides on top of the CWM.
Cisco WAN Modeling Tools
Cisco WAN Modeling Tools
This CD must be ordered separately from the CWM set.
Consider also the following:
•Ultra 60 and Enterprise 450 and 4500—They were certified with earlier CWM releases and can still be used with this release. For the system requirements, see the CWM 11.0.10 release notes. Note that Cisco does not provide technical support for Sun configurations or products that Sun Microsystems no longer supports.
•Graphics card—A graphics card is required when using the Java Client to access the CWM.
•Video—Video on the CWM server is required only for user access or maintenance. It can be added to Sun servers or workstations. For Ultra and Enterprise, a video adapter is required.
•Firewalls—If you are using a firewall between the server and the clients, you must open a range of ports for the CWM servers. For additional information about using firewalls, see the "Using Firewalls" section in the CWM installation guide.
You can access all CWM documentation at this website:
This section describes the system requirements for using CWM 16.0.00 P1. See these System Requirements sections:
CWM 16.0.00 P1 Server Requirements
Table 4 lists the system requirements for the CWM server. Note also the following about the CWM servers:
•Other UltraSPARC III server models with equal or higher CPU speed and memory capacity can also be used.
•If UltraSPARC II servers are used, see the CWM 11.0.10 release notes for system requirements.
•If you are using an Ultra 60 (low-end platform), it should have at least 2 GB of RAM.
Note The above mentioned hardware is the minimum requirement recommended. Check with SUN Microsystems, Inc. for their latest hardware versions.
CWM Java Client Requirements
Table 5 lists the CWM Java Client system requirements.
SSC and SSM Requirements
Table 6 lists the Standalone Statistics Collector (SSC) or Standalone Statistics Manager (SSM) system requirements, which are the same. Note also the following:
•The file size is 2 MB (typically holds statistics with peak enabled for 20-KB endpoints).
•The number of files does not increase with a smaller file size.
•The average network transfer rate is the required TFTP or FTP throughput to collect the maximum number of files (combination of server performance, network bandwidth, and traffic).
•One SSM can control a maximum of 12 SSCs.
•The SSM must be run on a machine with the same Solaris release as that of the CWM server.
•Besides enabling statistics collection on the SCM, statistics must be enabled on the individual connections for statistics to be collected on that connection. Because you do not receive a warning message to enable collection on the connection, the CWM does not display an error message.
Table 7 lists the added system requirements for using a parser in the CWM, SSC, or SSM. If the parser is enabled, add the applicable system requirements in Table 7 to the CWM requirements listed in Table 4 or to the SSM or SSC requirements listed in Table 6.
Five statistics are collected from each connection segment endpoint in 15-minute file collection intervals. Collecting statistics for 4 million endpoints with five statistics per endpoint requires 80 GB of disk space per 24-hour period. You will need at least 3 x 36 GB of disk space.
Solaris Patch and Source Library Requirements
This section shows the Solaris patches and source libraries that you need to install on the CWM after you install the Solaris operating system.
See these sections:
Before Installing Patches and Source Libraries
For best results, follow these Sun recommendations before you begin installing patches and libraries:
•Shut down CWM processes before installing the patches and use the single-user mode to install most patches.
•After installing the Solaris OS, you must install the appropriate kernel patch. After that, install the patches and libraries (see Table 8) if they were not installed as part of the cluster. See Patch Installation Procedure.
•Avoid installing these Solaris 9 patches on the SPARC platform: 112963-21 through 112963-24. They can cause problems with Informix during startup.
•DST patches—If you are using U.S. time zones, you must install the Solaris DST patches. See Table 8. As recommended in Sun Microsystems Alert ID 102775, countries not affected by the DST rule changes are still advised to install the latest DST patches. Note that countries may switch to other time zones programmatically to meet an application-specific configuration or a needed computation. These other time zones can include ones that are affected by the DST changes.
•Not all Solaris patches or patch clusters require a reboot. If a reboot is not required, you can start the CWM after the patch is installed.
•To install the packages, use pkgadd -d <package location> command.
Caution Sun fixed a bug in the "pam_dial_auth.so.1" module, which is in the 112960-46 patch. However, this fix causes a login failure with the CWM. You can see the login error message in the CWM GUI and also in in this /var/adm/message: "Jun 22 01:44:09 sv210cwm1 CwmGs: [ID 427199 user.error] pam_dial_auth: terminal-device not specified by login, returning Error in underlying service module."
The workaround is that if you have already installed the patch, uninstall it, or you can simply comment out or remove "pam_dial_auth.so.1" from the PAM "auth" stack for "login" in /etc/pam.conf because the CWM does not use the pam_dial_auth.so.1 module for authentication. You do not need to reboot. (This bug, CSCsj45688, has been resolved.)
Table 8 Solaris Patches and Source Libraries
Patches and Libraries Solaris 9 Solaris 10
Kernel Patch 112233-12
Kernel Patch 118833-36
Time-zone patch 113225-08 or later, and libc patch 112874-33 or late
Time-zone patch 122032-04 or later, and libc patch 119689-07 or later
See the following website:
See the following website: http://www.sunfreeware.com/programlistsparc10.html
Patch Installation Procedure
Use this procedure and sequence to install the Solaris patches, which assumes that the Solaris OS is already installed.
Step 1 Verify the already installed patches. To do this, use the Solaris showrev -p command.
Step 2 Go to the SunSolve Patch Access website to access the patches:
(If you have a SunSpectrum contract, you can also access patches from SunService.)
Step 3 Install the appropriate kernel patch for Solaris 9 or 10. See Table 8 for the correct version number.
Step 4 Install the rest of the required patches if they were not already installed as part of the cluster. Depending on your situation, you may want to enter only the first 6 digits of the patch number in the Find Patch field on the Sun Patch Access site and not the version extension to obtain the latest patch version.
Step 5 Install the recommended patches, as needed and desired. (Several of these recommended patches may require a service contract with Sun.)
The CWM uses Informix for database operations. The Informix program is bundled with the CWM and included on the CWM Server CD in the CWM package. The program is installed automatically when the CWM is installed.
Note the following Informix information that is compatible with CWM 16.0.00 P1:
•Informix Version: 9.40 UC8
•Informix Server Port: 8000
•Informix Service: informix_istar
Apache Web Server Requirements
CWM uses Apache web server 1.3.12 for client login operations. The Apache web server is bundled with the CWM Server CD in the CWM release 16.0.00 package. The program is installed automatically when CWM is installed.
Installing and Uninstalling CWM Software
For the starting and ending installation and upgrade configurations, review Table 9.
To upgrade from an earlier CWM release, you must first upgrade to one of the releases listed in Table 9. See the release notes and installation guide for the applicable CWM version.
To install, upgrade, or uninstall the CWM software, review the CWM installation guide:
•Chapter 2, "Preparing to Install." In that chapter, be sure to review "Before You Start." It includes information about configuring and estimating the Informix database size.
•Chapter 3, "Installing Software." In this chapter, be sure to review "CWM Server Post-Installation Tasks," which describes how to check the system and configure system configuration files, such as the network.conf and NMServer.conf files.
•Chapter 4, "Upgrading Software"
•Chapter 5, "Uninstalling"
In general, you will install the appropriate CWM software and perform CWM installation tasks in this order. The installation guide describes these tasks:
1. Install the CWM server.
2. If you are using the SSM and traps and not using SNMP Service Agent, you must install RtmProxy on the CWM server.
3. Install the SNMP Service Agent (optional).
4. Install the SCMSA (SSM or SSC).
5. Perform the CWM post-installation tasks.
6. Set up the CWM client.
7. Set up the network routers and nodes, which can be done before or after installing the CWM.
8. Install optional software, such as the WANDEST server and client, the ABP tool, and the NMT tools.
In this section, see these subsections:
The installation and upgrade procedures enable you to install the CWM components in various combinations according to the starting configuration and the desired ending configuration.
Table 9 summarizes these configurations and procedures. Additional information about the CWM software is provided in the CWM installation guide. See Chapter 1, "Introduction."
Notes and Cautions
In addition to these notes, you can also review the following guides:
•CWM Installation Guide—Contains installation information, such as procedures for CWM and SCMSA installation and upgrade, and provides a section on CWM server post-installation tasks, including how to check the system and set up configuration files, such as the network.conf file.
•CWM User Guide—Provides notes about particular applications.
You can access all CWM documentation at this website:
Review the following notes about software:
•ILOG—Because of the asynchronous behavior of the ILOG client and server, CWM client requests can be sent before the CWM server is ready. In this case, this error message appears:Ilb Error: Synchronous request to <unidentified actor failed by timeout>.
If the ILOG times out for more than 5 minutes and the CWM is not functioning normally, you should call service.
•The RPM card on the PXM1-based MGX 8850, 8230, or 8250 platform is provisioned using Telnet because it does not support SNMP SETs. This behavior should normally be transparent.
•The CWM also supports these Cisco products: Cisco Info Center (CIC) and Cisco C-Note. For information about these products, refer to the CWM installation guide.
Caution If you do not shut down Informix before rebooting, data will be lost. To shut down Informix properly before you reboot the machine, execute
/usr/users/svplus/scripts/kill_db as superuser (root).
Features Not Supported
These features are not supported by the CWM:
•Several windows display fields that relate to the MPSM-T3E3-155 MultiLink Frame Relay (MLFR) feature, which is not currently supported.
•When managing VISM service modules that are running VISM 3.2.10, the CWM supports only the Rel. 3.2 features.
•The VISM 3.1 features cannot be accessed from the CWM: TGCP, Dynamic Payload, and T.38 Fax Relay.
•These are the Current Route feature limitations:
–P2MP calls and SVC/SVP connections are not supported.
–Only master-ended (not slave-ended) connections have current route information.
–The configuration upload file contains only a snapshot of the current route information at the time the switch receives a CWM configuration upload request.
–If a node becomes congested, both of the connTrace messages that the CLI and the Current Route feature send are dropped. The CWM does not distinguish between the messages. This situation is also true for a connTrace ACK message received on a congested node.
–When a node ID is changed, follow this procedure on each network node to flush out all existing current route information and start collecting new information.
a. Disable and re-enable the current route feature by using the cnfndcurrte command
b. After disabling the feature, wait for at least 9 seconds (the timeout period for a conntrace message) before re-enabling the feature to avoid processing stale conn-trace messages.
–Because the path information for a connection traversing more than 20 nodes is not stored in the current route path table, the connection does not have current route information.
•While the CWM is running, if the remote display is stopped without properly shutting down the CWM desktop, reopening it remotely may not succeed.
CWM Feature Limitations
The following are known CWM feature limitations:
•Trap Resiliency and support for Offline CWM machine:
–Trap loss may occur in the OSS, for the faulty node, during the process of node management switchover between online and offline machines.
–If the node sends excessive traps when the switch is busy, there is a possibility of trap manager deregistering/registering request failures.
–Offline CWM can be used to receive traps and manage nodes only when the node is deregistered from the online CWM. Offline CWM cannot be used for provisioning connections.
–If trap deregistration from the switch happens via the CLI or the Diagnostics Center GUI, the information regarding the deregistration will not be present in the NTS. In such a case, offline CWM cannot manage the node.
–When the node is being managed by an offline CWM machine, the Stats feature will not work if SSM and SSC are configured on different machines.
–This feature is supported only for V1 networks. Ensure that the agent mode is on insecure mode.
•CWM installation requires C shell.
•If an svplus user enables the non-UNIX user account feature, he or she will not be able to change the user password through the GUI.
•For SNMPv3, the CWM Agent supports only the USM security model. It supports MD5 and SHA as authProtocol, and DES and AES128 as privProtocol. The external OSS must be SNMPv3 compliant.
•In contrast to the normal sequence for CWM changes of upgrading the CWM first and then the switch, you must upgrade the switch completely, including the service and route processor modules, before upgrading the CWM SNMP mode from SNMPv1 to SNMPv3. The CWM running in SNMPv3 mode cannot sync with the switch if the service modules are not running 5.4 releases.
If you change the SNMP version on the node from SNMPv1 to SNMPv3 when CWM is managing the node in SNMPv1, the node moves to an unmanaged state in the CWM. For the CWM to start managing the node again, use the Network Configurator GUI to change the mode of the node to SNMPv3.
If the SNMP mode in the device is changed from 1 to 2 and is being managed in the CWM using SNMPv1, the CWM still manages the node; however, any set operation on the node fails. Also, during the next resync, the node moves to unmanaged state.
We recommend that you use the Network Configurator to change the SNMP version of the node to 3 when you change the node's SNMP mode in the device from 1 to 2 or 1 to 3
•When a node is in SNMPv3 mode, the CWM database is not updated after executing the switchcc command for the PXM45 card. The node is left in an unmanaged state. Then it will be managed only during the next resync, which happens every 8 hours. So, it is suggested to perform the switchcc command only when the node is in SNMPv1 mode.
•SNMPv3 Southbound Support—By default, CWM assumes the network has both SNMPv1 and SNMPv3 nodes and tries to discover the nodes. The discovery will take a long time for SNMPv3-supported nodes. If you are using only SNMPv1 networks, you should make the following changes to achieve faster discovery
NETWORKSNMPVERSIONflag to V1_ONLY
SnmpGetTimeOutflag in the ILMITopoc.conf file to 20
Note ABP does not have the SNMPv3 support. So, if you are using ABP, AGENT mode should always be set to 0 (Unsecure in agent++.conf).
•SNMPv3 Northbound Support—The CWM SNMP tools do not support the AES128 privacy protocol.
•For the VISM-PR 3.3.30 cards, upspeed cannot be enabled or disabled in the Configuration Center.
•As of CWM 15.0, the RPM-PR card is not supported on MGX PXM1-based nodes that Chassis View manages. The applicable trap is missing so the CWM cannot monitor the back card. For both RPM and RPM-PR cards managed by Chassis View that are in standby state, the card status displays as blue. For other types of cards, stand-by card status displays as yellow. For both the RPM and RPM-PR card types, hardware and firmware revisions are not populated in the database.
The RPM back card support feature is disabled by default. To enable the feature and obtain RPM back card information, edit the emd.conf file before starting the CWM core. Note that when back card support is enabled, back card information is polled from the switch only during a cold start or a manual resync. After that, any back card configuration or status changes are not updated until you perform another cold start or a manual resync.
The CWM does not distinguish between the Ethernet back card versions installed with the MGX-RPM-128M/B or RPM-PR. No difference in functionality exists.
•For a few of the latest Solaris patches and the Sun Fire E6900 server, the Informix engine may generate a shared memory error as shown in this example:"oninit: Fatal error in shared memory creation <machine name>"
When this error occurs, the Informix engine fails to come up and is not able to perform database related operations. The error can be resolved by changing values in the /etc/system and /usr/users/informix94/etc/onconfig files. The following shows the change to the /etc/system file:forceload: sys/shmsys forceload: sys/semsys set shmsys:shminfo_shmmax=268435456 set semsys:seminfo_semaem=16384 set semsys:seminfo_semmap=64 set semsys:seminfo_semmni=4096 set semsys:seminfo_semmns=4096 set semsys:seminfo_semmnu=4096 set semsys:seminfo_semume=64 set semsys:seminfo_semvmx=32767 set shmsys:shminfo_shmmin=100 set shmsys:shminfo_shmmni=100 set shmsys:shminfo_shmseg=100 set semsys:seminfo_semmsl=100 set rlim_fd_max=1024
After you have made the above changes, edit and configure the "SHMBASE" value in /usr/users/informix94/etc/onconfig as follows and reboot the machine:SHMBASE 0x0A000000L
•We do not recommend pointing multiple CWMs at the same gateway node.
•When /usr/users becomes completely full, the ORBIX processes cannot write to the disk and continue operations. To correct the problem, free up disk space in /usr/users and then restart the ORBIX processes and the CWM as follows: Stop the core and exit out of the CWM prompt, run the stoporbix2000 script, type CWM (you should see "Starting Orbix..." in the ~svplus/log/.startStopOrbix.log file), and start the core.
•When a shortage of shared memory exists on the workstation, the Informix engine may generate an OS error, and the statsparser cannot perform database-related operations. The long-term solution is to increase the amount of memory to support 2 million connections consistently. You can resolve the error temporarily by changing the /etc/system configuration as follows:forceload: sys/shmsysforceload: sys/semsysset shmsys:shminfo_shmmax=1073741824set semsys:seminfo_semaem=16384set semsys:seminfo_semmap=5000set semsys:seminfo_semmni=8192set semsys:seminfo_semmns=8192set semsys:seminfo_semmnu=8192set semsys:seminfo_semume=256set semsys:seminfo_semvmx=50000set shmsys:shminfo_shmmin=256set shmsys:shminfo_shmmni=32000set shmsys:shminfo_shmseg=256set semsys:seminfo_semmsl=100
•If an ATM IP interface (also called in-band interface) is being used to manage the switch from the CWM, the CWM cannot receive all node bring-up traps. The ATM connections required for in-band management can take time to get routed on node bring-up and therefore are not available for trap delivery at the time of initialization. If this initialization time is an issue, the workaround is to configure the CWM for out-of-band management.
•If starting collection on the SCM GUI is taking too long, verify whether or not it was started with an unreachable IP address. You must use a reachable in-band or out-of-band IP address.
•The SSM statistics database can go out of sync with node_ids on the CWM after a cold start -F is executed on the server. To ensure that the node IDs remain consistent, stop and disable collection in the SSM server before doing a cold start -F in CWM. A CWM-to-CWM gateway must be enabled to ensure uninterrupted statistics collection.
•When the persistent topology feature is enabled and you want to decommission a node and take it out of the topology, use the switch CLI to delete the node from the persistent topology data. To decommission a node or to delete a trunk from the PNNI network, you must delete the entry from the persistent gateway nodes.
•To ensure that all CWM 16.0.00 P1 servers have the same XPVC preferred data, the CWM-to-CWM gateway must be enabled; otherwise, you must manually propagate the data to all CWM servers.
•On MGX PXM1-based feeders in the BPX network, XPVCs terminated on the VISM or VISM-PR cards can connect only to the AUSM service module. No such restriction exists for PXM1E-based or PXM45-based nodes.
•To correctly manage feeder nodes after they have been moved, you must first delete all trunks from the old node by using the CLI before adding the feeder back onto the system.
•RPM-PR and RPM ports and subinterfaces must be configured with a number less than 32767. If you have configured any ports or subinterfaces with a number greater than 32767, you must delete them and then re-add them using a number less than 32767.
•Note the following in regard to receiving SNMP traps:
–If you register an SNMP Manager with the SNMP Agent without changing the bit-mask (if you accept the default of FFFFFFFFFFFFFFFF), you receive all SNMP traps, including 25302 and 25303.
–If you register the SNMP Manager with a non-default bit mask because you do not want certain groups, such as FFFFFFFFF10701555, you do not receive trap 25302 and 25303, even though you have registered for that group.
–If you deselect a currently undefined group such as Group 28 (a bit mask of FFFFFFFFEFFFFFFF), you can then add traps 25302 and 25303 by editing the trap_filter.conf file and adding these lines to Group 20 # network connectivity status change traps: TRAP 25302 and TRAP 25303.
•Changing the line, payload, and medium types of VXSM-4OC3 causes the CWM to perform a whole card resync when you change any of the following: the medium type between SONET and SDH for SONET physical line, the payload type between T1 (VT 1.5 VC 11) and E1(VT 2 VC 12) for the STS or STM (Au) path or between T1 (VT 1.5 VC 11) and DS3 for the STS path, or the tributary path between Au4 and Au3 for the STM path in the SDH medium. (A whole card resync takes several minutes to complete.)
•If you remove and then immediately add back the same IGX feeder when the CWM is running, the CWM establishes two LINK 0's with the node. This is treated as a delete, and the node is deleted. In this situation, Cisco recommends you either remove and add the feeder when the CWM is down, or, after adding the feeder, restart the CWM.
•The "l_network_id" field in the connection segment or port tables may not be populated correctly. To ensure collection of an accurate network ID, use the "netw_id" field from the "node" table.
•If the log level for the CWM EM module is set too high or set above the production default value and many configurations are changed on the switch during a warm start, the sync-up performance is impacted during the warm start.
•SmartLogging is a feature for CWM debugging that is available when the log level is set to Level 2. It dumps detailed log messages to log files for each Level 2 log message. For example, when SmartLogging is enabled, an SNMP failure that triggers a Level 2 log message dumps messages at all levels immediately before and after this event. Because the feature can impact performance due to excessive log messages, it should be disabled in normal operation and enabled only when needed for monitoring performance.
•When setting up VISM connections, the virtual path identifier (VPI) value in the VPI/VCI Selector window is grayed out with the VISM card slot number. If VISM is sitting in a feeder node, the VPI value in the VPI/VCI selector is grayed out as zero.
•Ports on PXM45-based nodes associated with a trunk display as "Trunk Ports"; however, ports that are carrying signalling protocol information display as "User Ports." Because they are carrying information, you cannot provision connections on these ports. Attempting to do so results in an error. Choose another port.
•Virtual ports on the BPX card are displayed in the tree view at the Line level as physicalPort.virtualPort.
•The administrative state of the PNNI ports is not aggregated into the total administrative state of the port. The Inspector View application shows both the total administrative state of the port and the administrative state of the PNNI ports as two separate items.
•With MPSM-OC3 cards, after you replace an OC-3 back card with a DS3 back card or vice versa, you need to do a cold start.
•In the Connection Manager, the Service Type field displays some nonapplicable service types for SPVCs; however, the CWM displays an error if you select one of these nonapplicable service types.
•If a valid network.conf file is not present, the CWM may not start properly and may cause a total core dump.
•For the MPSM, PXM1E, and FRSM cards, an SCT greater than 255 cannot be associated with the SCT Manager due to a device limitation.
Creating a CWM Auto-Restart Shell Script
This section describes how to create and configure a shell script that automatically starts the CWM core after a reboot.
To create this shell script, use a text editor to create a new file containing the commands that you want the script to execute. To save your changes when using the Vi editor, press Esc, colon (:), then wq!.
Use this procedure to create a script that uses the Vi editor and shell commands to automatically restart the CWM core after the workstation has been rebooted.
Step 1 Log in to the CWM as user root:$ su
Step 2 Change to the /etc/rc3.d directory:# cd /etc/rc3.d
Step 3 Create a shell script of the form: Snn <filename>, where nn is the relative sequence number for starting the job under
/etc/rc3.dby entering this command:# vi /etc/rc3.d/S99init_sv
Because this script does not exist currently, the vi editor opens a blank line for you to enter the script commands.
Step 4 Create the shell script by entering these lines:#!/bin/sh# Check if Informix configuration is going on while [ ! -z "`ps -ef | grep S98init_db | grep -v grep`" ]doecho "Informix initialization in progress...." >> /usr/users/svplus/log/.start_stopCWM.logsleep 5done# Start Orbix E2A ... as svplus echo "Starting Orbix E2A ..." >> /usr/users/svplus/log/.start_stopCWM.logsu - svplus -c /usr/users/svplus/scripts/startorbix2000 >> /usr/users/svplus/log/.start_stopCWM.logsleep 5# Running Guard process ... as svplusecho "Running Guard process" >> /usr/users/svplus/log/.start_stopCWM.log su - svplus -c /usr/users/svplus/scripts/Install/RunGuard &# Start CWM core process ... as svplus su - svplus -c /usr/users/svplus/scripts/start_SV+ &
Step 5 Enter this command to provide execute permissions for /etc/rc3.d/S99init_sv:# chmod 755 S99init_sv
Step 6 Follow several specifications when creating the shell script:
a. A shell script, called /etc/rc3.d/S98init_db, was created automatically during the CWM installation to auto restart Informix after a reboot. To ensure the restart, use a script number (the second and third numbers in the filename) greater than 98 in the new auto-restart shell script.
b. Ensure that the new auto-restart shell script does not have the same script number as any other script files in /etc/rc3.d.
For additional information on configuring the auto-restart shell script, refer to the /etc/init.d/README file.
MGX SNMP Agent Trap Limitation
This section describes the SNMP Service Agent trap limitation with the PXM1-based MGX nodes. You can use the cnfchantrapenbl and dspchantrapenbl commands to configure the traps that the CWM collects when connections are added or modified on Cisco MGX PXM1-based nodes running release 1.3.00 and later:
•For sending the legacy traps and trap 50601, select "default."
•For sending only trap 50601, select "enable."
Note the following about changing the option while the CWM is running:
•If the dspchantrapenbl command is set to "default," (legacy traps and trap 50601), you can use the cnfchantrapenbl command to change to collecting only trap 50601 when the CWM is running.
•If the dspchantrapenbl command is set to "enable" (only trap 50601) and you want to use the cnfchantrapenbl command to send legacy traps also for connection additions and modifications, you must stop the core to execute the command.
To determine which CWMs are managing the node, run the dsptrapmgr command.
This section lists known and resolved issues in the CWM 16.0.00 P1 and WANDEST 2.9.00 software. For:
•Known Issues in the CWM 16.0.00 P1—See Table 10.
•Issues Resolved in CWM 16.0.00 P1—See Table 11.
Table 11 lists the issues resolved in the CWM 16.0.00 P1 software.
Table 11 Issues Resolved in CWM 16.0.00 P1
Bug ID Description
When errors occur during the transfer of a file using SFTP, the file handlers that open, do not close. The possible reason could be that the disk is full.
Using the usm script, when a new user is being added, the username and security name should be the same.
Support for trap resiliency and offline CWM machine.
Password change for the existing user fails in GW setup for non-UNIX user feature.
Advanced load option in Finder GUI does not reproduce the saved operation for trunk.
Unable to get the logical port using svMapLogicalPort for AXSM-XG card.
PXM1 node is not discovered when added as standalone node using network configurator.
Default password should be accepted for easy migration of UNIX users.
Signal handler, which is used for managing offline CWM, does not work as expected for trapResMgr process.
For RtmProxy process, the USM parameters do not get updated on sending HUP signals
The flag NODE_DEREGISTRATION_ON_DELETE is obsolete as it prevents automatic deregistration of a node from an offline CWM machine on deletion.
The maximum port speed for an FR-FR connection on E1 line on FRSM is restricted to 1536K.
Patch package and Install script need to be updated with the new tool, shmStats. The new tool is a replacement for the existing tools cntdbkr and count.
Preference set for a particular user in primary server is not reflected in the secondary server due to lack of proper gateway communication.
NMServer core dump occurs as and when a huge number of CWM health alarms are exchanged between primary and secondary servers.
The newly added MGX1 nodes with node IDs greater than 3000 do not sync up causing an emc core dump.
Connection Manager for MPSM cards does not handle the connections as expected.
When attempting to configure an FR-FR connection between an FRSM and an MPSM card, with a line speed greater than 1536K at both ends, an error message
CIR Out of Rangegets displayed.
An svplus user can establish a connection with the CWM server without providing a password. The connections now are via SSH, and are more secure.
The default process for provisioning requests is v1 and v3. The additional security feature that is provided for SNMPv3 may slow down the processing of SNMPv3 provisioning requests; it may be slower than that of SNMPv1. If the OSS applications are not configured for SNMPV3 features, we recommend that you enable the MasterAgent with only V1 to improve the speed of processing of provisioning requests. For configuration tips, refer the section Enabling V1 Provisioning Using the MasterAgent.
At the time of enabling line in AXSM-16-155-XG, the ooemc core dumps.
These documents comprise the CWM documentation set:
•Release Notes for the Cisco WAN Manager, 16.0.00 P1
•Cisco WAN Manager Installation Guide, 16.0.00
•Cisco WAN Manager User Guide, 16.0.00
•Cisco WAN Manager SNMP Service Agent Guide, 16.0.00
•Cisco WAN Manager Database Interface Guide, 16.0.00
•Cisco WAN Data Extraction and Synchronization Tool User Guide, 2.9.00
You can access all CWM documentation at this website:
These documents are also available on Cisco.com:
•Release Notes for the Cisco WAN Modeling Tools, 16.0.00
•Cisco WAN Modeling Tools User Guide, 16.0.00
•Release Notes for the Cisco Automated Bulk Provisioning Tool, 16.0.00
•Cisco Automated Bulk Provisioning Tool Guide, 16.0.00
The Cisco WAN Modeling Tools and Automated Bulk Provisioning Tool user guides are also available on their software CDs and ordered separately. In addition, a Guide to Cisco Multiservice Switch Documentation ships with your product.
General Link for Switch Documentation
For links to documentation for specific switches, go to the following location and click on the URLs for specific switches or switch software:
On www.Cisco.com, you can search for any product and topic documentation. On the main page, enter the word or phrase in the Search window and click the Documentation link. For example, you can search for "configuring MGX 8850" or "PXMIE." On the results page, you can click Advanced Options to refine your search.
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 this URL:
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.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned 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. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2010 Cisco Systems, Inc. All rights reserved.1 Offline CWM is a separate CWM server which can take over managing the high trap nodes from the production CWM. The purpose of the offline machine is that the main production CWM can offload the fault and configuration management for the nodes which generate high trap rate. Once the trap rate issue gets resolved, the MGX can be handed over back to the production CWM to resume normal operations. This is done to protect the overall network manageability and the health of main CWM server.