Cisco Transport Manager User's Guide, 5.0
Appendix G: Troubleshooting

Table Of Contents

Troubleshooting

G.1  Overview

G.2  Server Problems

G.2.1  CTM Server Does Not Respond

G.2.2  Cannot Connect to the CTM Server

G.2.3  NE Connection State Is Listed as Unavailable

G.2.4  Launching Tables Results in Database Errors

G.2.5  SNMP Traps Are Not Forwarded from NEs

G.2.6  Trap Port Is Unavailable

G.2.7  Problems with ONS 15530 and ONS 15540 Configuration

G.2.8  Performance Monitoring Data Is Not Displayed

G.2.9  CTC-Based NE Is Not Discovered

G.2.10  CTC-Based NE Is Not Reachable

G.2.11  ONS 15501, ONS 15540, or ONS 15530 Is Not Reachable

G.2.12  Circuits Are Not Displayed

G.2.13  Circuit State for Monitor Circuits Reads "Duplicate ID"

G.2.14  NE Model Type Appears as Unknown

G.2.15  Cannot Copy CTC Binary to the CTM Server

G.2.16  Memory Backup, Memory Restore, or Software Download Fails

G.2.17  Memory Autobackup, Software Commit, or Software Revert Fails

G.2.18  The getinfo.sh Script Fails

G.2.19  Using the get nestate Command

G.3  Client Connectivity Problems

G.3.1  Database Is Not Available

G.3.2  Database Timeout Occurred

G.3.3  Are the CTM Client and the CTM Server Connected?

G.3.4  Cannot Log In as Provisioner or Operator

G.3.5  Cannot Authenticate User Message Appears

G.4  Client Operational Problems

G.4.1  Model Index Is Unknown

G.4.2  Cannot Delete an NE

G.4.3  CTC Fails to Start

G.4.4  Added a New Software Version to the Wrong NE

G.4.5  Cannot Delete a Subnetwork

G.4.6  Cannot Move an NE Between Subnetworks

G.4.7  Cannot Schedule Jobs

G.4.8  ONS 15800, ONS 15801, or ONS 15808 NE Generates Too Many Alarms

G.4.9  Bandwidth-Intensive Operations Are Blocked

G.4.10  NE Displays Incorrect Configuration Management Data

G.4.11  Cannot Customize the Network Map

G.4.12  How Do I Change Color Settings when the CTM Client Runs on a Sun Ultra 5 Workstation?

G.4.13  How Do I Collect Thread Dumps?

G.4.14  How Do I Replace the Alarm Interface Panel?

G.5  CTM GateWay/TL1 Problems

G.6  CTM GateWay/CORBA Problems

G.7  Cisco CRS-1 and Catalyst 6509 Problems

G.7.1  CRS-1 Communication State Remains Unavailable After Marking the Device as In Service

G.7.2  Catalyst 6509 Communication State Remains Unavailable After Marking the Device as In Service

G.7.3  CTM Does Not Receive Configuration Changed Notifications from the CRS-1

G.7.4  CTM Does Not Receive Traps from the Catalyst 6509

G.7.5  CTM Does Not Receive syslog Events from the Catalyst 6509

G.7.6  CTM Does Not Collect Historical PM Data for the CRS-1

G.7.7  CRS-1 PM Tables Collect Data at the Wrong Collection Interval

G.7.8  Memory Backup or Restore Fails for the CRS-1

G.7.9  How Do I Back Up the CRS-1 Configuration File Automatically Whenever the Configuration Is Changed on the Router?

G.7.10  For the CRS-1, CTM Does Not Automatically Discover Neighboring NEs

G.7.11  Cannot Delete an Out-of-Service NE from CTM

G.7.12  Software Version Is Not Reported in the Domain Explorer and the NE Software Table Is Empty

G.7.13  Cannot Use Configuration > Telnet/SSH from the CRS-1 NE Explorer

G.7.14  How Do I Configure Telnet on the CRS-1?

G.7.15  How Do I Configure SSH on the CRS-1?

G.7.16  How Do I Create and Grant Certificates for SSL-Configured CRS-1 NEs?

G.7.17  How Do I Trigger a linkDown or linkUp Trap from the Catalyst 6509?

G.7.18  How Do I View the SNMP Configuration on the Catalyst 6509?

G.7.19   How Do I Load a Software Image on the Catalyst 6509?


Troubleshooting


This chapter offers troubleshooting steps to help solve high-level problems while operating CTM or CTM GateWay. Follow the troubleshooting procedures described in this chapter before contacting Cisco technical support.

This chapter includes the following troubleshooting information:

Overview

Server Problems

Client Connectivity Problems

Client Operational Problems

CTM GateWay/TL1 Problems

CTM GateWay/CORBA Problems

Cisco CRS-1 and Catalyst 6509 Problems


Note For information about troubleshooting CiscoView problems, see F.10  Troubleshooting, page F-6 in Appendix F, "Using CiscoView to Configure and Monitor ONS 15501, ONS 15530, and ONS 15540 NEs."


G.1  Overview

Troubleshooting involves:

1. Identifying the source of the problem—Which devices, links, interfaces, hosts, or applications have the problem?

2. Locating the problem on the network—On what VLAN, subnet, or segment is the problem occurring?

3. Comparing current network performance against an established baseline—Is the performance better or worse?

4. Finding out when the problem started—When did you first see the problem? Is it recurring?

5. Determining the extent of the problem—How widespread is the problem? Is it getting worse?


Note This chapter assumes that the server is installed under the default /opt/CiscoTransportManagerServer directory and the client is installed under the default /opt/CiscoTransportManagerClient (Solaris) or C:\Cisco\TransportManagerClient directory (Windows). If a directory other than the default installation directory is specified, replace the default path with the installed path.


G.2  Server Problems

This section describes troubleshooting procedures for CTM server-related problems.


Note Log in as the root user on the Solaris workstation where the CTM server is installed to perform any operations on the Solaris workstation.


G.2.1  CTM Server Does Not Respond


Step 1 Log in as the root user on the Solaris workstation where the CTM server is installed.

Step 2 Enter the following command to view the status of the CTM server processes:

showctm

If you do not have root user privileges but you belong to the UNIX group that can use sudo functionality to run commands as nonroot, enter the following command:

sudo showctm

If there is a line containing /CTMServer, the CTM server is running.

If there is no line containing /CTMServer, the CTM server is not running. Proceed to Step 3.


Note You can also check the ctmop.log file in /opt/CiscoTransportManagerServer/log to determine if the server was stopped by another user or if it stopped abnormally. If it stopped abnormally, proceed to Step 3.


Step 3 Run the getinfo.sh CTM server tool and send the data to Cisco technical support for analysis.

If you do not have root user privileges but you belong to the UNIX group that can use sudo functionality to run commands as nonroot, enter the following command:

sudo getinfo.sh

Step 4 Start the CTM server by using the ctms-start script in the /opt/CiscoTransportManagerServer/bin directory.

a. Log in as the root user.

b. Change the directory to /opt/CiscoTransportManagerServer/bin and enter the following command:

ctms-start

If you do not have root user privileges but you belong to the UNIX group that can use sudo functionality to run commands as nonroot, enter the following command:

sudo ctms-start


If the preceding procedure does not solve the problem, complete the following steps:


Step 1 Verify that the /opt/CiscoTransportManagerServer/cfg/CTMServer.cfg file is not corrupted. The file should contain the db-config-mode = auto parameter in the [database] section. If the entry is missing, the CTM server configuration file is corrupt. Reinstall the CTM server.

Step 2 Verify that the first entry in the /var/opt/oracle/oratab file looks similar to CTM5_0:/oraclesw9i/product/9.2:Y. If this entry is missing, the Oracle database might not be installed. The Oracle database is a prerequisite for installing the CTM server.


G.2.2  Cannot Connect to the CTM Server


Step 1 Ping the server's IP address from the client PC or workstation.

Step 2 If the ping fails, resolve the IP connectivity problem and try again.

Step 3 Telnet to the server and log in as the root user.

Step 4 Enter the following command to verify that CTM is running:

showctm

If you do not have root user privileges but you belong to the UNIX group that can use sudo functionality to run commands as nonroot, enter the following command:

sudo showctm

Step 5 The server should have at least the following four processes running:

root 3778 0.1 0.1567 9592 ? S 16:57:36 0:00 /opt/CiscoTransportManagerServer/bin/CTMServer
root 3771 0.1 0.4 6208 pts/1 S 16:57:34 0:00 
/opt/CiscoTransportManagerServer/bin/CTMServer
root 3876 0.5 0.6129464 8648 ? R 16:58:12 SnmpTrapService
root 3798 26.8 4.115732060968 ? S 16:57:37 0:29 SMService

Step 6 Manually stop the server if you see fewer than four processes running. Enter the following command:

ctms-stop

Step 7 If you changed the server IP address, verify that the configuration files shown in Table 4-12 have been updated. See 4.4.2  Updating the Configuration Files After Changing the CTM Server IP Address, page 4-35.

Step 8 Verify that the Oracle database is accepting connections:

a. Enter the following command to log in as the Oracle user:

su-oracle

b. Enter the following command to open an SQL*Plus session:

omu-u60-3% sqlplus ctmanager/ctm123!

Step 9 Reboot the server if you receive another error message and the SQL prompt does not appear. Wait enough time for the server to boot up and try to run the client. The SQL prompt indicates that the Oracle database is running and accepting connections.

Step 10 Enter the following commands to manually restart CTM:

SQL> exit
omu-u60-3% exit
omu-u60-3% logout
ctms-start

If you do not have root user privileges but you belong to the UNIX group that can use sudo functionality to run commands as nonroot, enter the following command:

sudo ctms-start

Step 11 Wait for 5 minutes and run the client.


G.2.3  NE Connection State Is Listed as Unavailable

If the connection state of an NE is listed as Unavailable in the Domain Explorer window, a connectivity or configuration problem exists. Wait 5 to 10 minutes after adding the NE to the CTM domain; then, complete the following steps:


Step 1 To see the NE IP address, select the NE in the Domain Explorer window. The Address tab of the Network Element Properties pane lists the IP address of the selected NE.

Step 2 From the CTM server, enter the following command to verify connectivity between the CTM server and the NE:

ping <IP_address>

Step 3 If the ping fails, a physical or configuration problem exists in the data communications network (DCN).

a. If connectivity existed earlier:

If there were no configuration changes made to any routers in the DCN or to the CTM server, the problem is a physical problem.

If the configuration was changed, the change might have introduced problems. Verify the changed configuration.

b. If connectivity was never established:

Verify that there are no problems on the physical level.

Verify the DCN configuration.

Step 4 If the ping succeeds, verify that the NE software version is listed in the Supported NE Table. See 4.3.6  Adding a New NE Software Version to the CTM Domain, page 4-30.

Step 5 For ONS 15501, ONS 15530, and ONS 15540 NEs, SNMP read and write community strings must be set up properly on each NE. The running configuration on each NE should contain entries similar to the following example:

snmp-server community public RO
snmp-server community private RW

The community strings configured on the server should match the strings configured on the NE. For information on configuring community strings in CTM for ONS 15501, ONS 15530, and ONS 15540 NEs, see 3.5.1.5  Prerequisites for Adding ONS 15501, ONS 15530, and ONS 15540 NEs, page 3-9.


G.2.4  Launching Tables Results in Database Errors

If the Oracle database or Oracle listener that CTM is using is down, launching tables will generate database errors. To troubleshoot table launching errors:


Step 1 Log in as the Oracle user and enter the following command:

sqlplus ctmanager/ctm123!

If the login is successful, an SQL> prompt appears, which indicates that the Oracle database has been installed and the database server is up and running. If login fails, either the Oracle database has not been installed or the database server is not running.

Step 2 To start the Oracle database, log into the Solaris workstation as the Oracle software owner user.

Step 3 Enter the following command at the shell prompt to start the Oracle database:

dbstart

Step 4 Enter the following command at the shell prompt to start the Oracle listener:

lsnrctl start

If there are still problems with starting the Oracle database or the Oracle listener, refer to the Oracle documentation or contact Oracle support.


G.2.5  SNMP Traps Are Not Forwarded from NEs

SNMP traps might not be forwarded, either because the trap port is already in use, or because the NE is not properly configured.

G.2.6  Trap Port Is Unavailable

The CTM server requires exclusive access to the SNMP trap port to receive SNMP traps from the NE.


Step 1 To verify that the standard SNMP trap port (number 162) is not being used by another application running on the same Solaris workstation, enter the following command:

netstat -a | grep 162

If the following line is seen, the SNMP trap port is being used by another application:

*.162	 Idle

Step 2 If the trap port is being used by another application, stop the other application.


G.2.7  Problems with ONS 15530 and ONS 15540 Configuration

ONS 15530 and ONS 15540 NEs must be properly configured to send traps to the server.


Step 1 The running configuration on the NE should contain entries similar to the following example:

snmp-server enable traps snmp authentication warmstart 
snmp-server enable traps bgp 
snmp-server enable traps oscp 
snmp-server enable traps config 
snmp-server enable traps entity 
snmp-server enable traps fru-ctrl 
snmp-server enable traps topology throttle-interval 60 
snmp-server enable traps optical monitor min-severity not-alarmed 
snmp-server enable traps rf 
snmp-server enable traps aps 
snmp-server enable traps patch 
snmp-server enable traps cdl all 
snmp-server enable traps alarms 
snmp-server enable traps threshold min-severity degrade

snmp-server host 172.20.126.214 version 2c public snmp bgp oscp  
config entity fru-ctrl topology optical rf aps patch cdl alarms threshold

In this example, the host 172.20.126.214 will receive the specified traps from the NE.

Step 2 You can also run the following commands on the server and device:

a. As the root user, enter the following command on the server:

# snoop udp port 162

b. On the device, enter the following command to generate a configuration change:

wr mem

If the device is configured correctly, the snoop command reports a configuration change trap.


G.2.8  Performance Monitoring Data Is Not Displayed


Step 1 Use the Domain Explorer NE Properties pane to see if PM collection is disabled for the selected NE.

Step 2 Choose Administration > Control Panel and expand PM Service. Select the NE type to see if the service status is Active or Not Active.

Step 3 Choose Administration > Audit Log to see if PM was ignored for the selected NE.

Step 4 Choose Administration > Control Panel and click PM Service. Look at the PM Data Storage field. Choose Optimized to save only nonzero values in the database. Choosing Optimized requires less space than saving all values, including zero values. If you choose Normal in the PM Data Storage field, the database saves all PM values, including zero values.


Note The Optimized PM data storage feature is available only for CTC-based and ONS 155xx NEs.


Step 5 Choose Administration > Error Log to see if there are any critical, major, or minor errors against the PM service.

Step 6 Verify that the NE is reachable during the duration that PM data is collected. If the NE is not reachable, there is an entry in the Audit Log table (Administration > Audit Log).


G.2.9  CTC-Based NE Is Not Discovered


Step 1 Verify that the NE is up and running.

Step 2 Verify that the NE IP address and default route are configured correctly.

Step 3 To verify that the NE is running the correct version of system software, open a CTC session to the NE and check the NE software version.

Step 4 Verify that the NE that acts as the GNE (through which this node is discovered) is added to CTM and is available.

Step 5 Open CTC from the GNE and see if CTC can discover the NE.


G.2.10  CTC-Based NE Is Not Reachable


Step 1 Verify that the NE is up and running.

Step 2 Verify that the NE IP address and default route are correctly configured.

Step 3 Wait for five poll cycles while CTM reestablishes connectivity with the NE.

Step 4 To test IP connectivity to the NE from the CTM server, enter the following command from the Solaris workstation running CTM:

ping <NE_IP_address>

Step 5 To verify that the NE is running the version of system software supported by CTM, open a CTC session to the NE and check the NE software version.

Step 6 Verify that the username and password that CTM uses to reach the NE exist on the NE.


G.2.11  ONS 15501, ONS 15540, or ONS 15530 Is Not Reachable


Step 1 Enter the following command on the server to verify IP connectivity between the server and the NE:

ping <NE_IP_address>

Step 2 If the NE is reachable through IP, verify that the correct read community string is configured on the server.

On the server, choose Administration > ONS 155XX > ONS 155XX SNMP Settings Table to view the community strings set in CTM.

On the NE, enter the following command to view the read community string set on the NE:

show run | begin SNMP

In the running configuration, the community strings are shown in entries similar to the following:

snmp-server community public RO
snmp-server community private RW

In this example, the read string is public, and the read/write string is private.

Step 3 If IP connectivity and community strings are verified and the device is still unavailable, check the error log for any errors reported by ONS 155xx NE Service.


G.2.12  Circuits Are Not Displayed

If CTM fails to display some circuits or if the information displayed by CTC and CTM differs, complete the following steps:


Step 1 Wait for two minutes while the CTM server synchronizes with the NE. If the Circuit table is not in autorefresh mode, click the Refresh Data tool when the tool flashes.

Step 2 Verify that the Circuit table is opened from either the source or destination NE of the circuit to be viewed.

Step 3 Verify that the NEs that are part of the circuit (source, destination, or drop) are available in CTM.

Step 4 Open another CTC session and compare the circuit information in the newly opened CTC session with the circuit information displayed by CTM.


G.2.13  Circuit State for Monitor Circuits Reads "Duplicate ID"

CTM generates a unique number that is appended to the circuit name to make the monitor circuit name unique. On rare occasions, CTM might create two or more monitor circuits with the same name. The circuit state for these circuits reads "Duplicate ID." This is a known issue that has been tracked as DDTS number CSCdz87566.

When the circuit state reads "Duplicate ID," you cannot see the actual circuit state. In this case, you must change the duplicate name to a unique name, so that you can see the correct circuit state. Use the Modify Circuit wizard to enter a unique name for each monitor circuit.

G.2.14  NE Model Type Appears as Unknown

If an in-service NE is added to the Domain Explorer, but the model type appears as unknown, the software version of the NE might not be prepopulated in the database. In other words, CTM cannot match the NE with a recognizable version.

Use the NE Software Table to add the NE software version string to the CTM database. See 4.3.4  Viewing Software Versions and Restarting the NE with a New Software Image, page 4-27.

G.2.15  Cannot Copy CTC Binary to the CTM Server

If a CTC binary fails to be copied to the CTM server, the <CTM_install_directory>/cms/ directory might be missing or write-protected. If the directory is missing, create a cms directory with write-access permissions. Otherwise, change the permissions of the existing cms directory to allow write access.

G.2.16  Memory Backup, Memory Restore, or Software Download Fails


Step 1 In the Domain Explorer window, choose Administration > Job Monitor. The Job Monitor table shows the status of the operation. The reason for the failure is shown in the Additional Information column.

Step 2 Return to the Domain Explorer window and choose Administration > Error Log. The Error Log table shows information about the backup, memory restore, or download failure.

Step 3 See Error Messages, page E-1 for the correct action to take in response to the error.


G.2.17  Memory Autobackup, Software Commit, or Software Revert Fails


Step 1 In the Domain Explorer window, choose Administration > Audit Log. The Audit Log table shows the status of the operation.

Step 2 Return to the Domain Explorer window and choose Administration > Error Log. The Error Log table shows the reason for the failure.

Step 3 See E.2  CTM Server Error Messages, page E-92 for the correct action to take in response to the error.


G.2.18  The getinfo.sh Script Fails

You might experience a problem where the getinfo.sh script fails with the following error:

"Error: permission denied while running `rsh.' Check the environment and make sure the root is permitted to run .rsh on host <IP_address>."

This problem occurs because the getinfo.sh script does not run unless an entry is made in the /.rhosts file. This problem occurs even on a local server and database configuration. This is a known issue that has been tracked as DDTS number CSCin66495.

The solution is to add an entry for the server IP address to the /.rhosts file.

G.2.19  Using the get nestate Command

The get nestate CLI command available in the ctm utility in the EMS server bin directory returns the provisioned operational state (NE_Info_Table: NEState) and the read-only modifiers to the operational state (NE_Info_Table: NEDiscoveryState). The get nestate command returns the following possible values:

Preprovisioned

In Service

Out of Service

Under Maintenance

In Service-Initializing

In Service-Sync Configuration

In addition, the show nelist command lists all of the NEs with the following information:

NE database ID

NE IP address

Model type

SID

Network partition ID

Operational state

G.3  Client Connectivity Problems

The CTM client might not be able to connect to the CTM server for various reasons. Complete the following procedures in the order listed until the problem is resolved.

G.3.1  Database Is Not Available

If the CTM client cannot connect to the CTM server, verify that the database is available.


Step 1 Log into the CTM server as the Oracle user.

Step 2 Enter the following command to connect to the database:

sqlplus ctmanager/ctm123!

Step 3 If the error message "maximum processes exceeded" is received, the maximum number of database connections has been reached. Close several clients or ask the database administrator to increase the maximum number of processes for the database.


G.3.2  Database Timeout Occurred


Step 1 Reduce the scope of the query by selecting a group or an NE and not the entire domain before opening tables such as the Alarm Browser, Alarm Log, Audit Log, and PM tables.

Step 2 Increase the client database query timeout period by editing the ems-client.cfg file in the C:\Cisco\TransportManagerClient\config or /opt/CiscoTransportManagerClient/config directory.

Step 3 Add hardware resources to the Oracle database server.

Step 4 Ping the Oracle database server from the client to verify the response time. Increase the bandwidth if the round-trip response time is inadequate.


G.3.3  Are the CTM Client and the CTM Server Connected?

If the database is available, check connectivity between the client and the server.


Step 1 To see the CTM server IP address, enter the following command on the Solaris workstation that is running the CTM server:

ifconfig -a

The command output looks similar to the following example:

hme0:flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>mtu 1500
inet 192.168.120.93 netmask ffffff00 broadcast 192.168.120.255

The IP address is the address following the inet field.

Step 2 To verify that the physical connection between the CTM client and the CTM server does not have problems, enter the following command from the CTM client:

ping <IP_address>

where the IP address belongs to the Solaris workstation that runs the CTM server.

Step 3 If the ping command is not successful, fix the physical connectivity; then, log into the CTM client.


G.3.4  Cannot Log In as Provisioner or Operator


Step 1 Use the default username and password to log into the CTM client:

Username: SysAdmin

Password: Ctm123!

Step 2 If the SysAdmin login is successful, but the provisioner or operator login fails, verify that the provisioner or operator exists and is not disabled. In the Domain Explorer window, choose Administration > CTM Users to view a table of all configured CTM users.

Step 3 If the provisioner or operator is not in the CTM Users table, the user is not configured. Configure the provisioner or operator; then, log in as that user.

Step 4 If the provisioner or operator is in the CTM Users table, select the row corresponding to that user and click the Modify User Properties tool to bring up the Modify CTM User Properties wizard. Verify that the Login State field is set to Enabled. If the login state is disabled, enable it and log in as the provisioner or operator. The user might have been disabled after attempting to log in with an incorrect password.

Step 5 If the password is not correct, set a new password for the user and log in again.


G.3.5  Cannot Authenticate User Message Appears

If the "Cannot authenticate user" error message is received when logging into the CTM client, the CTM server might be initializing. Wait for five minutes while the CTM server finishes initializing; then, try to log in again. Alternately, check your username and password and enter them again. The username and password are case sensitive.

G.4  Client Operational Problems

This section describes troubleshooting procedures for CTM client operational problems.

G.4.1  Model Index Is Unknown

If a new NE is added to the CTM domain and marked as In Service, but the model index is unknown, complete the following steps:


Step 1 Verify that the IP address and other parameters are entered correctly.

Step 2 The CTM server might not be able to establish connectivity to the GNE for the NE. Verify that the GNE for the NE is marked as In Service, and that the GNE is correctly populated in the CTM domain.

Step 3 Verify that the GNE is DCC-connected to the NE.

Step 4 The CTM server might not recognize the NE's software version. In the Domain Explorer tree, select the NE and choose Fault > Test NE Connectivity. If the NE is available, contact Cisco Systems and verify that the version of the software on the NE is compatible with the CTM server being used. Use the Supported NE Table to provide the new NE software version that the CTM server will recognize.

Step 5 The CTM server might be configured to attempt communication with new NEs after a certain delay. To change the health poll frequency:

a. In the Domain Explorer window, choose Administration > Control Panel and click NE Service.

b. In the NE Poller tab, look at the NE Health Poll Interval field. The default is 240 seconds. If the value is too large, there might be a communication delay between CTM and the NEs. Under normal conditions, the CTM server attempts communication with new NEs for no more than twice the number of seconds specified in the NE Health Poll Interval field.


G.4.2  Cannot Delete an NE

If an NE cannot be deleted, verify that the user logged in as SuperUser or NetworkAdmin—not as a Provisioner or Operator. Provisioners and Operators cannot delete NEs. If the user logged in as Provisioner or Operator, restart the CTM client session and log in as SuperUser.

G.4.3  CTC Fails to Start

If CTC cannot be started for a CTC-based NE, complete the following steps:


Step 1 If an error occurs while opening the NE Explorer yet the CTC progress screen and login dialog boxes appear, the CTC username or password might be incorrect.

a. Choose Administration > CTM Users.

b. In the CTM Users table, choose Edit > Modify. The Modify CTM User Properties wizard opens.

c. Click Next to move to the CTC/Craft User Properties panel and change the CTC username and password to match those configured on the device. Click Finish.

Step 2 If the CTC progress screen idles for a long time before the login dialog box appears, there might be problems with network connectivity to the device.

a. From a DOS command window or a Sun Solaris terminal, ping the device.

b. If no response is received, set up routes so that the device is available; then, restart CTC. If CTC does not start, the workstation might have resource constraints.

c. Close some open applications and try again.

d. Close some instances of CTC that are managing another group of CTC-based NEs and try again.

Step 3 If the GNE for the selected NE was not found, there might be a mismatch between the GNE specified for the device and the available GNEs. This means that the data in the database is corrupt. Contact Cisco technical support for assistance.


G.4.4  Added a New Software Version to the Wrong NE


Step 1 In the Domain Explorer window, choose Administration > Supported NE Table.

Step 2 In the Supported NE Table, select the incorrect entry and choose Edit > Delete.

Step 3 Click OK in the confirmation dialog box.

Step 4 Select the correct NE row from the Supported NE Table.

Step 5 Add the correct software version.

Step 6 In the Domain Explorer > Network Element Properties pane, set the operational state of all NEs that are behaving erroneously to Out of Service.

Step 7 Click Save.

Step 8 In the Network Element Properties pane, set the operational state of all the NEs back to In Service.

Step 9 Click Save.


G.4.5  Cannot Delete a Subnetwork

If a subnetwork cannot be deleted from the Subnetwork Explorer, complete the following steps:


Step 1 Verify that the user logged in as a SuperUser—not as a Provisioner or an Operator. Provisioners and Operators cannot delete subnetworks. If the user logged in as a Provisioner or Operator, restart the CTM client session and log in as a SuperUser.

Step 2 Verify that the target subnetwork does not contain NEs. Move all NEs to another subnetwork before deleting the empty target subnetwork.


G.4.6  Cannot Move an NE Between Subnetworks

When automatic grouping of NEs in subnetworks is enabled, you cannot move NEs between subnetworks. To move NEs from one subnetwork to another:


Step 1 In the Domain Explorer window, choose Administration > Control Panel.

Step 2 In the Control Panel, click UI Properties.

Step 3 Under Subnetwork Grouping, uncheck the Automatically Group NEs in Subnetworks check box.

Step 4 Click Save.


G.4.7  Cannot Schedule Jobs

The CTM client can schedule three types of administrative tasks:

Software download

Memory backup

Memory restore

CTM maintains an error log and audit log to track potential problems. To view the error log or audit log:


Step 1 In the Domain Explorer window, choose Administration > Audit Log or Error Log.

Step 2 Look for errors related to software download, memory backup, or memory restore.


G.4.8  ONS 15800, ONS 15801, or ONS 15808 NE Generates Too Many Alarms

Occasionally, ONS 15800, ONS 15801, and ONS 15808 NEs generate so many alarms that the CTM client cannot process all of them. Set the operational state of the NE to Under Maintenance while debugging the cause of the alarms:


Step 1 In the CTM Domain Explorer window, right-click the ONS 15800, ONS 15801, or ONS 15808 that is generating the large number of alarms and choose Mark Under Maintenance.

Step 2 Debug the ONS 15800, ONS 15801, or ONS 15808 NE to see which card is in error. Find the card that is generating the alarms and mark it as Under Maintenance.

Step 3 While the card is under maintenance for debugging, set the ONS 15800, ONS 15801, or ONS 15808 NE back to In Service.


G.4.9  Bandwidth-Intensive Operations Are Blocked

Bottlenecks in the DCN affect bandwidth-intensive operations, such as software download. Tune the timeout and retry values to match DCN performance. Log into the NE and enter the following commands:

ip tftp min-timeout—Sets the minimum wait time, in seconds, before retrying the read/write request.

ip tftp max-timeout—Sets the maximum wait time, in seconds, before retrying the read/write request.

ip tftp backoff-delay—Sets the number of seconds to extend wait time if the read/write request times out.

ip tftp write-retries—Sets the maximum number of times to retry the TFTP read/write request before declaring a failure.

G.4.10  NE Displays Incorrect Configuration Management Data


Step 1 In the Domain Explorer window, choose Administration > Service Monitor and verify that the NE Service is running. If it is not running, start the NE Service.

Step 2 Test NE connectivity.

a. In the Domain Explorer tree, select the NE and choose Fault > Test NE Connectivity. The message "<NE_name> (<IP_address>) is available" should be generated.

b. If the NE is unavailable, establish connectivity to the NE before retrieving configuration data.


G.4.11  Cannot Customize the Network Map

If an image file is not displayed while changing the Network Map background or while changing a node icon, complete the following steps:


Step 1 Choose another image file. The file might be corrupt.

Step 2 Check the size of the image file. The image file might be larger than 100 KB, which is too big to load. If the file is too big, use a smaller image file.

Step 3 Verify that the image file exists in the \images\mapbkgnds\shapefiles directory or the \images\mapicons directory. If the file is missing, it has been deleted. Reinstall the CTM client.


Note The client is bundled primarily with shape files (*.shp) and only a few map background GIF files.



G.4.12  How Do I Change Color Settings when the CTM Client Runs on a Sun Ultra 5 Workstation?

To run the client on a Sun Ultra 5 workstation, the color map must be changed from 8 bit to 24 bit. If the colors do not look right, change the color map from 8 bit (the default) to 24 bit as follows:


Step 1 To see the current color settings, enter the following command:

/usr/sbin/m64config -prconf

Command output looks similar to the following example:

--- Hardware Configuration for /dev/fbs/m640 ---
ASIC: version 0x7c004750
DAC: version 0x0
PROM: version 104
Card possible resolutions: 720x400x88, 640x480x60, 640x480x72, 640x480x75, 800x600x56, 
800x600x60, 800x600x72, 800x600x75, 1024x768x87, 1024x768x60, 1024x768x70, 1024x768x75, 
1280x1024x75, 1280x1024x60, 1152x900x66, 1152x900x76, 1280x1024x67, 1280x800x76, 
1280x1024x85
1280x1024x76, 1152x864x75, 1024x768x77, 1024x800x84, vga, svga, 1152, 1280, 800x600, 
1024x768, 1280x1024, 1152x900
Monitor possible resolutions: 720x400x70, 720x400x88, 640x480x60, 640x480x67, 640x480x72, 
640x480x75, 800x600x56, 800x600x60, 800x600x72, 800x600x75, 832x624x75, 1024x768x60, 
1024x768x70, 1024x768x75, 1280x1024x75, 1152x870x75, 1152x900x66, 1152x900x76, 
1280x1024x67, 1280x1024x76, vga, svga, 1152, 1280, 800x600, 1024x768, 1280x1024, 1152x900
Possible depths: 8, 24
Current resolution setting: 1280x1024x76
Current depth: 8

Step 2 To change the color setting to 24 bit, log in as the root user and enter the following commands:

su
Password: <password>
/usr/sbin/m64config -depth 24 -res 1152x900x76

Step 3 Reboot the workstation for the new color settings to take effect.


Note The resolution in 24-bit depth is a little lower than is possible with 8-bit depth (1152 x 900 x 76 versus 1280 x 1024 x 76), but the difference is hardly noticeable.



G.4.13  How Do I Collect Thread Dumps?

Thread dumps are helpful references when debugging the CTM process. To collect thread dumps:


Step 1 Log into the server workstation as the root user.

Step 2 On the command line, enter the following command:

thread_dumper [\<Group/Service>\]

where:

Group is the group name for which to collect thread dumps. It can be:

SM

SNMPTRAP

NE

PM

GW

Service is the service name for which the thread dump is required. It can be:

SMService

SNMPTrapService

CORBAGWService

ONS15200NEService

ONS15216NEService

ONS15302NEService

ONS15305NEService

ONS15310NEService

ONS15327NEService

ONS15454NEService

ONS15454SDHNEService

ONS15501NEService

ONS15530NEService

ONS15540NEService

ONS15600NEService

ONS15600SDHNEService

ONS15800NEService

ONS15801NEService

ONS15808NEService

UnmanagedNEService

ONS15216PMService

ONS15302PMService

ONS15305PMService

ONS15310PMService

ONS15327PMService

ONS15454PMService

ONS15454SDHPMService

ONS15501PMService

ONS15530PMService

ONS15540PMService

ONS15600PMService

ONS15600SDHPMService

ONS15800PMService

ONS15801PMService

ONS15808PMService


G.4.14  How Do I Replace the Alarm Interface Panel?

The Alarm Interface Panel (AIP) provides surge protection for CTC-based NEs. This panel has a nonvolatile memory chip that stores the unique node address known as the MAC address. The MAC address identifies the nodes that support circuits. It allows CTM to determine circuit sources, destinations, and spans.

If an AIP fails, an alarm will be generated and the LCD display on the fan-try assemblies of the NEs will go blank. To perform an in-service replacement of the AIP, you must contact Cisco technical support. For contact information, go to the technical support website at http://www.cisco.com/tac.

You can replace the AIP on an in-service system without affecting traffic by using the circuit repair feature. See 7.2.10  Repairing a Circuit, page 7-62.

G.5  CTM GateWay/TL1 Problems

If the OSS cannot connect to CTM GateWay/TL1, or if the OSS does not receive a response, check the cables, address bindings, and configuration.


Step 1 If the connection times out, check the cables and connections.

Step 2 Verify that the address bindings between the OSS and the Solaris workstation running the CTM GateWay/TL1 service are correct.

Step 3 Using the ping command, verify connectivity between the OSS and the Solaris workstation running the CTM GateWay/TL1 service.

Step 4 Verify that the TCP/IP socket connection is still open for the OSS-to-CTM GateWay/TL1 port.

Step 5 Choose Administration > Control Panel. Click GateWay/TL1 Service and confirm that the service status is Active.

Step 6 Verify that the username and password under Control Panel > Security Properties match the user configuration of the NEs that CTM GateWay/TL1 will manage.

Step 7 Verify that the username and password in the Domain Explorer > Network Element Properties > NE Authentication tab match the user configuration of the NEs that CTM GateWay/TL1 will manage.


G.6  CTM GateWay/CORBA Problems

If the CTM server is installed without the CTM GateWay/CORBA option, and the CTM GateWay/CORBA option is installed later, the Control Panel does not refresh automatically after the CORBA installation to show that CTM GateWay/CORBA is installed.

This problem occurs because the CTM GateWay/CORBA installation is handled by a script that notifies the database that the component is installed, but does not notify the CTM server.

To work around this problem, click the Refresh Data button in the Control Panel. It might take some time for the Control Panel to show that CTM GateWay/CORBA is installed. You might need to close and reopen the Control Panel to see the change.

G.7  Cisco CRS-1 and Catalyst 6509 Problems

This section describes troubleshooting procedures for problems related to the Cisco CRS-1 and the Catalyst 6509.

G.7.1  CRS-1 Communication State Remains Unavailable After Marking the Device as In Service


Step 1 Verify that the CRS-1 is configured with "hfrems" as the username and "hfrems" as the password with "root-system" privileges. By default, CTM expects "hfrems" as both the username and password. You can change the username and password in the Control Panel > Security Properties > CRS-1 tab.

Step 2 Enter the following commands to verify that the XML CORBA agent service is running:

Router(config)# xml agent corba [ssl] 
Router(config)# commit


Note SSL is optional and enables SSL CORBA services.


Step 3 If SSL CORBA services are running, enter the following commands to verify that HTTP over SSL is running:

Router(config)# http server ssl
Router(config)# commit

Step 4 The CORBA agent on the router accepts connectivity only when the connection is done through hostname. Verify that the device IP address has an entry in DNS. If not, add an entry to the /etc/hosts file.

Step 5 Verify that CTM supports the software image that is running on the router. In the Domain Explorer, choose Administration > Supported NE Table and verify that the software version is supported.

Step 6 When the CRS-1 is added to CTM, the NE type is retrieved from the NE to verify that the NE is a CRS-1. If the device does not report CRS-1 as the NE type, CTM reports a loss of communication (LOC) to the NE and raises an NE type mismatch alarm.

Step 7 Verify that the NE hostname specified in DNS or in the CTM server's /etc/hosts file matches the hostname configured on the NE. If the hostnames do not match, CTM reports an LOC to the NE.


G.7.2  Catalyst 6509 Communication State Remains Unavailable After Marking the Device as In Service


Step 1 Verify that the IP address entered in CTM is configured on the Catalyst 6509. Enter the following command to configure the IP address:

cat6509 (enable)# set interface <logical_interface_name_like_sc0/sc1> 
<IP_address_of_the_Catalyst_6509> <mask>

Step 2 Enter the following command to verify that the device is configured correctly with the default route:

cat6509 (enable)# set ip route default <gateway_IP_address>

Step 3 Verify that CTM supports the software image that is running on the Catalyst 6509. In the Domain Explorer, choose Administration > Supported NE Table and verify that the software version is supported.


Note For the Catalyst 6509, the supported software version is Release 6.3(7) or later.


Step 4 Verify that the community string shown in the Domain Explorer > Address tab is same as the community string on the device. If there is a mismatch, enter the following command to change the SNMP community string on the device:

cat6509 (enable)# set snmp community read-only <community_string>

For example:

cat6509 (enable)# set snmp community read-only public


G.7.3  CTM Does Not Receive Configuration Changed Notifications from the CRS-1


Step 1 Enter the following commands to verify that the CTM server hostname and "logging-events-level" are configured in the running configuration:

Router# sh run | include domain ipv4 host
Router# sh run | include logging events level informational

Step 2 If the CTM server hostname and "logging-events-level" are not configured in the running configuration, enter the following commands:

Router# conf t
Router(config)# domain ipv4 host <CTM_server_hostname> <IP_address>
Router(config)# logging events level informational
Router(config)# commit


G.7.4  CTM Does Not Receive Traps from the Catalyst 6509


Step 1 Enter the following command to configure the CTM server as the trap receiver on the Catalyst 6509:

cat6509 (enable)# set snmp trap <CTM_server_IP_address> <community_string> 

Step 2 Enter the following command to configure the Catalyst 6509 to enable only specific traps:

cat6509 (enable)# set snmp trap enable <specific_trap>

where <specific_trap> is auth, bridge, chassis, config, entity, ippermit, module, stpx, syslog, systemp, vmps, or vtp.

Step 3 Enter the following command to configure the Catalyst 6509 to enable all traps:

cat6509 (enable)# set snmp trap enable all


Note The set snmp trap enable all command enables traps only on physical ports. For logical ports such as sc0 or sc1, you must enable traps separately. Go to Step 4.


Step 4 Enter the following command to enable traps on logical ports:

cat6509 (enable)# set interface trap <logical_port_name> enable

For example, to enable traps on the logical interface sc0, enter:

cat6509 (enable)# set interface trap sc0 enable


G.7.5  CTM Does Not Receive syslog Events from the Catalyst 6509

The Catalyst 6509 sends syslog traps only if the trap severity is both:

Less than or equal to facility severity (which is set with the set logging level command)

Less than or equal to history severity (which is set with the set logging history severity command)

It is recommended that you set the history severity to debugging (7).

The show logging command shows both the history severity and the severity for all facilities. For example, in the following output, the history severity is 7 and facility severity is 5. Syslog events of severity X will be triggered from the device if X is less than or equal to 5 and less than or equal to 7.

Cat6509 (enable)# show logging

Trace logging:                disabled
Logging buffer size:          500
        timestamp option:     enabled
Logging history:
        size:                 1
        severity:             debugging(7)
Logging console:              enabled
Logging telnet:               enabled
Logging server:               enabled
{10.77.56.151, 172.19.75.86}
        server facility:      SYSLOG
        server severity:      debugging(7)
Current Logging Session:      enabled
Callhome Functionality:       disabled 
Callhome Severity:            LOG_CRIT(2)

SMTP servers are not configured for callhome messages.

Destination addresses are not configured for callhome messages.

From Address is not configured for callhome messages.
Reply-To Address is not configured for callhome messages.

Facility            Default Severity         Current Session Severity
-------------       -----------------------  ------------------------
acl                 5                        5                    
callhome            2                        2                    
cdp                 4                        4                    
cops                3                        3                    
...
... 
sys                 5                        5 
... 
vmps                2                        2                    
vtp                 2                        2                    

0(emergencies)        1(alerts)             2(critical)           
3(errors)             4(warnings)           5(notifications)      
6(information)        7(debugging)

G.7.6  CTM Does Not Collect Historical PM Data for the CRS-1


Step 1 Verify that PM collection is enabled for the CRS-1. To do this, go to the Network Element Properties > Status tab and in the PM Collection area, check the 15 Min check box. Click Save. Also, verify that the CRS-1 PM Service Status is Active in the Control Panel window.

Step 2 Enter the following commands to verify that the correct PM configuration is in the running configuration on the CRS-1:

Router(config)#  show run perf

performance-mgmt resources tftp-server <IP_address_of_server> directory 
<directory_on_TFTP_server>
performance-mgmt statistics bgp template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics mpls ldp template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics node cpu template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics interface generic-counters template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics interface data-rates template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics mpls TE-link template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics node memory template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics node process template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics mpls TE-tunnel template default
 sample-size 1
 sample-interval 15
!
performance-mgmt statistics mpls interface template default
 sample-size 1
 sample-interval 15
!

Step 3 If the files are not being dumped to the target directory on the TFTP server, verify that the TFTP server is using the correct tftpd (tftp daemon binary). The tftpd should be a version that allows the CRS-1 to create new files in the specified directory. The default tftpd only allows pre-existing TFTP files to be written. The default tftpd does not create new TFTP files.

Step 4 If the files appear on the TFTP server but do not appear in the PM table, verify that the CTM server is being notified of PM TFTP file dumping events. To do this, choose Fault > Alarm Log and check for events that arrive every 15 minutes and resemble the following output:

pm_collector[301]: %PM_COLLECTOR-6-TFTP_SEND : Successfully dumped 
file:tftp://<IP_address><TFTP_directory><NE_name>_node_process_1100886887.212000

Step 5 If events do not appear after 15 minutes, verify that configuration change notifications are enabled. See CTM Does Not Receive Configuration Changed Notifications from the CRS-1.

Step 6 If events are present, verify that the TFTP server is reachable from the CTM server. To do this, ping the IP address that is present in the event notification. If the IP address is not reachable, configure the routes so that it becomes reachable. Alternately, include a mapping file in the /opt/CiscoTransportManagerServer/cfg/hfr/IPAddressMapping.cfg directory that includes the following mapping:

<IP_address_in_event_notification> <reachable_IP_address_of_the_same_TFTP_server>

For example:

172.19.64.51 223.255.254.254


G.7.7  CRS-1 PM Tables Collect Data at the Wrong Collection Interval

You might experience a problem where the PM data collection interval is set to 15 minutes, but the CRS-1 PM tables are collecting data more frequently (or less frequently).

The CRS-1 collects and dumps data to a binary file on a TFTP server at user-configured intervals based on the IOS-XR CLI. After dumping the PM data, the CRS-1 notifies CTM with the location of the file. CTM then collects PM data from the CRS-1. Therefore, you should configure the CRS-1 to collect data every 15 minutes.

G.7.8  Memory Backup or Restore Fails for the CRS-1


Step 1 Verify that the NE is in service and the communication state is Available.

Step 2 Verify that you can ping the CTM server from the NE. The NE is used as a TFTP client for downloading the configuration file.

Step 3 In the /etc/inetd.conf file, verify that the TFTP server is enabled on the CTM server. Also, verify that the specified tftpboot directory has the correct permissions.


G.7.9  How Do I Back Up the CRS-1 Configuration File Automatically Whenever the Configuration Is Changed on the Router?


Step 1 In the Domain Explorer, choose Administration > Control Panel.

Step 2 Click NE Service.

Step 3 In the NE AutoBackup tab, choose Cisco CRS-1 as the NE model. Alternately, choose All NE Models.

Step 4 Check the Enable Auto Backup check box.

Step 5 Specify the number of backup copies and the backup time.

Step 6 Click Save.


G.7.10  For the CRS-1, CTM Does Not Automatically Discover Neighboring NEs


Step 1 Verify that there is a physical link between the two NEs.

Step 2 Complete one of the following options, depending on your configuration:

If the link is an Ethernet link, bring up the interfaces on both NEs. For example, enter the following commands on the first router:

Router-1(config)# int GigabitEthernet0/2/0/0
Router-1(config-if) ipv4 address <IP_address> <mask>
Router-1(config-if) no shutdown
Router-1(config-if) commit

Enter the following commands on the second router:

Router-2(config)# int GigabitEthernet0/1/0/0
Router-2(config-if) ipv4 address <IP_address> <mask>
Router-2(config-if) no shutdown
Router-2(config-if) commit	

If the link is a POS link, enter the following commands on the first router:

Router-1(config)# int POS 0/2/0/0
Router-1(config-if) ipv4 address <IP_address> <mask>
Router-1(config-if) no shutdown
Router-1(config-if) commit	

Enter the following commands on the second router:

Router-2(config)# int POS 0/1/0/0
Router-2(config-if) ipv4 address <IP_address> <mask>
Router-2(config-if) no shutdown
Router-2(config-if) commit

Verify that the SONET controllers are up. For example, enter the following commands:

Router-1(config)# controller SONET 0/2/0/0
Router-1(config-sonet)# no shutdown
Router-1(config-sonet)# commit

Router-2(config)# controller SONET 0/1/0/0
Router-2(config-sonet)# no shutdown
Router-2(config-sonet)# commit

Step 3 Enter the following commands to enable CDP on both NEs:

Router-1(config)# cdp
Router-1(config)# commit

Router-2(config)# cdp
Router-2(config)# commit


G.7.11  Cannot Delete an Out-of-Service NE from CTM

If you cannot delete an out-of-service NE from CTM, enter the following command in the CTM server <CTM_ROOT>/bin directory to forcefully delete the NE:

./prune_ne.sh <NE_name_as_shown_in_CTM>

G.7.12  Software Version Is Not Reported in the Domain Explorer and the NE Software Table Is Empty

If you cannot see the software version in the Domain Explorer > Identification tab and NE Software table is empty, complete the following steps:


Step 1 Verify that the NE is in service and the communication state is Available.

Step 2 Verify that the device is configured with either Telnet or SSH.


G.7.13  Cannot Use Configuration > Telnet/SSH from the CRS-1 NE Explorer

If you cannot use Configuration > Telnet/SSH from the CRS-1 NE Explorer, try pinging the NE from the CTM client. You might be able to reach the NE from the CTM server but not from the client if they are in different subnets.

G.7.14  How Do I Configure Telnet on the CRS-1?

To configure Telnet on the CRS-1, log into the router through the console and enter the following commands:

Router# conf t
Router(config)# telnet ipv4 server 
Router(config)# commit

G.7.15  How Do I Configure SSH on the CRS-1?


Step 1 Enter the following command to verify that the security PIE(k9) is installed and activate on the router. The PIE(k9) is required for encryption, decryption, IPSec, SSH, SSL, and PKI:

Router# sh install active

Step 2 Enter the following command to verify that DSA keys have been generated on the router:

Router# crypto key generate dsa

Step 3 Enter the following command to verify that RSA keys have been generated on the router:

Router# crypto key generate rsa

Step 4 Enter the following command to verify that SSH is enabled on the router:

Router# crypto key generate rsa

Step 5 Enter the following command to enable the SSH server on the router:

Router(config)# ssh server enable


G.7.16  How Do I Create and Grant Certificates for SSL-Configured CRS-1 NEs?

See 5.4.24  Configuring Secure Socket Layer for the CRS-1, page 5-180.

G.7.17  How Do I Trigger a linkDown or linkUp Trap from the Catalyst 6509?

Complete one of the following options:

To trigger a linkDown trap from the Catalyst 6509, enter the following command:

cat6509 (enable)# set port disable <module_number/port_number> 

For example:

cat6509 (enable)# set port disable 5/1

To trigger a linkUp trap from the Catalyst 6509, enter the following command:

cat6509 (enable)# set port enable <module_number/port_number>

For example:

cat6509 (enable)# set port enable 5/1

G.7.18  How Do I View the SNMP Configuration on the Catalyst 6509?

To view the SNMP configuration on the Catalyst 6509, enter the following command:

cat6509 (enable)# show snmp

G.7.19   How Do I Load a Software Image on the Catalyst 6509?

Complete the following steps:


Step 1 Enter the following command to view all the software images on the Catalyst 6509:

cat6509 (enable)# dir bootflash:

The output is similar to the following example:

-#- -length- -----date/time------ name
2  5849256 Aug 09 2004 14:41:25 cat6000-sup2.6-3-7.bin
3  8801412 Aug 09 2004 15:30:57 cat6000-sup2k8.8-3-2.bin
4  5713736 Aug 11 2004 13:08:02 cat6000-sup2.6-3-2a.bin
5  8182352 Aug 12 2004 09:15:00 cat6000-sup2k8.8-2-1.bin
17     1786 Aug 23 2004 14:16:30 6509svt-171-180
19     1688 Sep 24 2004 15:26:40 6509svt-171-180.cfg

3346628 bytes available (28634940 bytes used)

Step 2 Enter the following command to retrieve the image name that is currently on the device:

cat6509 (enable)# whichboot

The output is similar to the following example:

Boot image name is 'bootflash:cat6000-sup2.6-3-7.bin'.

Step 3 Enter the following command to delete the existing image:

cat6509 (enable)# del <image_name> 

Step 4 Enter the following command to remove the deleted image:

cat6509 (enable)# squeeze bootflash: 

Step 5 Enter the following commands to copy the image to flash memory:

cat6509 (enable)# copy tftp flash 
IP address or name of remotehost[]? <TFTP_server_IP_address>
Name of file to copy from []? <Full_path_name_and_filename_of_the_image_location>

For example:

tftpboot/cat6k/7-2/<image_name>

Step 6 Enter the following command to verify that the downloaded image exists on the device:

cat6509 (enable)# dir bootflash:

Step 7 Enter the following command to verify that the download was successful:

cat6509 (enable)# verify <image_name>

Step 8 Enter the following command to clear the flash system:

cat6509 (enable)# clear boot system flash bootflash:<previous_image_name>

Step 9 Enter the following command to set the boot system flash with the new image name:

cat6509 (enable)# set boot system flash bootflash:<new_image_name> prepend

Step 10 Enter the following command to reset the device:

cat6509 (enable)# reset