Table Of Contents
Managing Southbound and Northbound Interfaces
12.1 How Do I Manage Southbound Interfaces?
12.1.1 Southbound Port Details
12.1.2 Using a Static CORBA Listener Port on the CTM Server
12.1.3 Client-Server Communication Protocols
12.1.4 Changing the CTM Server Port
12.2 How Do I Manage Northbound Interfaces?
12.2.1 Managing CTM GateWay/SNMP
12.2.2 Managing CTM GateWay/TL1
12.2.3 Managing CTM GateWay/CORBA
12.2.4 Trap Management
Managing Southbound and Northbound Interfaces
CTM uses protocols such as CORBA, SNMP, TL1, and HTTP to provide southbound and northbound interfaces to communicate with NEs and operations support systems (OSSs).
This chapter contains the following information:
•
How Do I Manage Southbound Interfaces?
•How Do I Manage Northbound Interfaces?
12.1 How Do I Manage Southbound Interfaces?
The CTM server communicates with NEs through the data communications network (DCN) by using several protocols (CORBA, HTTP, TL1, SNMP, and so on).
You can access NEs in CTM through:
•NE Explorer—Provides detailed rack, shelf, and card-level views of an NE. Detailed NE attributes and parameters are viewable and configurable.
•Craft Interface—Depending on the NE model, CTM provides access to NE craft interfaces such as CTC, Cisco Edge Craft, CiscoView, web browsers, and the command line interface (CLI). Table 2-5 on page 2-12 lists the available craft interfaces by NE model.
Note A command line interface (CLI) session might not have a scroll bar depending on the operating system you are using. To enable the scroll bar on Solaris, hold down the Ctrl key, click the middle button of your mouse, and select enable scroll bar.
12.1.1 Southbound Port Details
This section explains the ports that CTM uses to communicate with NEs.
•Inbound ports are for operations initiated by the node and then directed to the CTM server.
•Outbound ports are for operations initiated by the CTM server and then directed to the node.
The following table lists the ports that CTM uses to communicate with ONS 15216 NEs.
Table 12-1 Port Information for the ONS 15216
Port
|
ONS 15216
|
Inbound or Outbound?
|
TL1 Telnet
|
3083
|
Outbound
|
CLI
|
23, 8023
|
Outbound
|
CTM GateWay/SNMP set/trap
Note CTM GateWay/SNMP uses port 8765 as an internal port.
|
161, 162
|
Outbound
|
TFTP
|
69
|
Inbound
|
The following table lists the ports that CTM uses to communicate with ONS 15302 and ONS 15305 NEs.
Table 12-2 Port Information for the ONS 15302 and ONS 15305
Port
|
ONS 15302, ONS 15305
|
CLI
|
23
|
CTM GateWay/SNMP
Note CTM GateWay/SNMP uses port 8765 as an internal port.
|
161
|
The following table lists the ports that CTM and CTC use to communicate with CTC-based NEs.
Table 12-3 Port Information for CTC-Based NEs
Port
|
NE
|
CORBA listener port on the Timing Communications and Control Card (TCC+/TCC2) (NE)
|
Configurable with:
•TCC+/TCC2 fixed (57790, Outbound)
•Standard Internet Inter-ORB Protocol (IIOP) port (683, Outbound)
•User-defined constant
Note Configure the port in the NE Explorer (Network > Address subtab). For more information, see 4.4.4 Viewing and Changing the Network Address—CTC-Based NEs, page 4-45.
|
CORBA listener port on CTM server (callback)
|
Dynamic (current functionality)
Note To make the port static, see 4.5.4.4 CTC IIOP Port Configuration, page 4-79.
|
HTTP
|
From any CTC or CTM port to HTTP port 80 (Outbound) on the NE
|
HTTPS
|
Port 443, active if configured on the NE. This port is only available in NE release 6.0 and later. CTM tries to communicate on this port regardless of whether the NE supports HTTPS. If this port is blocked, it could cause long NE initialization times.
|
TL1 port on TCC+/TCC2 (NE)
|
From any CTC or CTM port to TCP port 3082, 2361 (Outbound), or port 4083 (secure).
|
Software download, backup, restore port on TCC+/TCC2 (NE)
|
From any CTC or CTM port to TCP port 9999 (Outbound; data transfer) on the NE.
|
Software activate/revert diagnostics port on CTM server
|
Dynamically allocated in the range of ports 9500 to 9550 (Outbound) to allow multiple concurrent activate/revert operations
|
CTC launched from CTM Domain Explorer
|
•From any CTC port to the IIOP port on the NE
•From any NE port to the IIOP port on CTC
•From any CTC port to HTTP port 80 (Outbound) on the NE
•Either port is configurable in the CTC.INI (Windows) or .ctcrc (UNIX):
–Dynamic (Cisco default)
–Standard IIOP port (683, Outbound)
–User-defined constant
|
L2 Service Resync and IOS CLI ports
|
From any port on CTM to ports 20xx and40xx on the NE, where xx is the ML-series card slot number
|
CTM GateWay/SNMP
Note CTM GateWay/SNMP uses port 8765 as an internal port.
|
From any NE port to SNMP trap port 162 (Inbound) on the CTM server
|
The following table lists the ports that CTM uses to communicate with ONS 155xx NEs.
Table 12-4 Port Information for the ONS 155xx
Port
|
ONS 155xx
|
Inbound or Outbound?
|
HTTP
|
80/81
|
Outbound
|
TL1
|
TCP 3082, 3083
|
Outbound
|
IOS CLI
|
TCP 23 (Telnet)
|
Outbound
|
Software download, backup, restore
|
69 (TFTP server)
|
Inbound
|
CTM GateWay/SNMP requests
Note CTM GateWay/SNMP uses port 8765 as an internal port.
|
UDP 161
|
Outbound
|
SNMP traps
|
UDP 162
|
Inbound
|
CiscoView (if CiscoView is cross-launched by CTM to manage ONS 155xx NEs)
|
TCP 1741
|
Inbound (CTM client to CTM server)
|
The following table lists the ports that CTM uses to communicate with ONS 1580x NEs.
Table 12-5 Port Information for the ONS 1580x
Port
|
ONS 1580x
|
Inbound or Outbound?
|
TL1
|
1000
|
Outbound
|
Telnet to OS
|
23
|
Outbound
|
TFTP
|
69
|
Inbound
|
The following table lists the ports that CTM uses to communicate with the CRS-1 and Cisco XR 12000.
Table 12-6 Port Information for the CRS-1 and Cisco XR 12000
Port
|
CRS-1 and Cisco XR 12000
|
Inbound or Outbound?
|
SSH CLI
|
22
|
Outbound
|
Telnet CLI
|
23
|
Outbound
|
TFTP (for PM data collection, memory backup, and memory restore)
|
69
|
Inbound and outbound1
|
HTTPS
|
443
|
Outbound
|
CORBA naming service
|
10001
|
Outbound
|
CORBA notifications
|
Dynamic
|
Outbound
|
The following table lists the ports that CTM uses to communicate with the Catalyst 6509.
Table 12-7 Port Information for the Catalyst 6509
Port
|
Catalyst 6509
|
Inbound or Outbound?
|
SNMP operations
|
161
|
Outbound
|
SNMP traps
|
162
|
Inbound1
|
The following table lists the ports that CTM uses to communicate with the Cisco MGX Voice Gateway.
Table 12-8 Port Information for the Cisco MGX Voice Gateway
Port
|
Cisco MGX Voice Gateway
|
Inbound or Outbound?
|
SNMP operations (Get/Set/GetNext)
|
161
|
Outbound
|
SNMP Traps
|
2500
|
Inbound1
|
SSH CLI
|
22
|
Outbound
|
Telnet CLI
|
23
|
Outbound
|
FTP (for PM data collection, and configuration file upload)
|
24
|
Outbound
|
12.1.2 Using a Static CORBA Listener Port on the CTM Server
See 4.5.4.4 CTC IIOP Port Configuration, page 4-79.
12.1.3 Client-Server Communication Protocols
CTM uses the following protocols for client-server communication:
•Common Object Request Broker Architecture (CORBA)—Object Management Group's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks.
•Java Management Object and Configuration Object (JMOCO)—Cisco proprietary TCP/IP-based request/response protocol.
•Telnet—A standard internet protocol that provides terminal emulation using the TCP/IP protocols.
•Java Database Connectivity (JDBC)—The industry standard for database-independent connectivity between Java programming languages and databases.
Note All ports from 1024 to 65536 must be open to ensure communication between the CTM server and client.
The following table lists the ports that the CTM server uses to communicate with CTM clients.
Table 12-9 CTM Server and Client Ports
Module or Protocol
|
Port
|
Inbound or Outbound?
|
Apache HTTP port
|
8051
|
|
JMOCO port
|
27613 (configurable)
|
Inbound
|
CORBA IIOP listener port on CTM server
|
Dynamic
Note This port cannot be set to static.
|
—
|
GateWay/TL1 OSS listener port
|
26715 (configurable)
|
Inbound
|
SNMP command port
|
161
Note Port 161 is used only for communication between SNMP-managed NEs and the CTM server, not for communication between the CTM client and server.
|
Outbound
|
SNMP trap port
|
162
Note Port 162 is used only for communication between SNMP-managed NEs and the CTM server, not for communication between the CTM client and server.
|
Inbound
|
SNMP trap forwarding port
|
8765 (configurable)
|
—
|
SSH port
|
22
|
|
JMS web server
|
8033
|
|
JNDI port
|
1099
|
Inbound
|
Orbix ports
|
3075, 3079, 3094
|
|
RMI Registry port
|
19999
|
|
RTM Proxy port
|
8161
|
|
CORBA naming service
|
14005
|
Inbound
|
CORBA notification service
|
Dynamic
|
|
Database listener port
|
1521 (configurable)
|
Inbound
|
Internal process-to-process communication ports
|
9000 to 9011
|
|
CORBA OS agent port
|
14000
|
—
|
CTC debug port
|
9401 (if unavailable, uses the next available port)
|
Inbound
|
CTM server Telnet debug port
|
9403
|
Inbound
|
Telnet proxy port on CTM server
|
10023 to 10087
|
Inbound
|
Telnet port
|
23
|
|
UDP port to receive traps
|
2500
|
|
12.1.4 Changing the CTM Server Port
Normally, users do not change the CTM server port. In cases where the CTM server port is used for other applications, use the NE Service pane to change the TCP port number of the CTM server. All CTM clients use the JMOCO port to connect to the CTM server. See Table 12-9 for information about the JMOCO port.
Step 1 In the Domain Explorer window, choose Administration > Control Panel.
Step 2 In the Control Panel window, click NE Service to open the NE Service pane. Click the NE Poller tab.
Step 3 Change the server port in the CTM Server Port field. The server port in the Active column displays the current port. The server port in the After Restart column displays the port that is active after the server is restarted.
Step 4 Click Save. Changes to this parameter take effect only after the server is restarted.
12.2 How Do I Manage Northbound Interfaces?
CTM GateWay is an architectural component that provides northbound EMS-to-NMS interface mediation. CTM GateWay allows service providers to integrate CTM with their OSSs by using open, standard interfaces.
CTM supports three gateway modules that provide northbound EMS-to-NMS interface mediation. Not all NE types are supported by each module. Table 2-3 on page 2-3 shows the NE types supported by each gateway module.
12.2.1 Managing CTM GateWay/SNMP
SNMP is a network management protocol used almost exclusively in TCP/IP networks. SNMP allows you to monitor and control network devices, manage configurations, collect statistics, check performance, and monitor security.
CTM's GateWay/SNMP feature provides an SNMP trap forwarding service, where any trap received by CTM will be forwarded to the set of defined trap destinations. Traps are autonomous notifications sent by an SNMP agent to an SNMP manager, such as HP Open View. CTM GateWay/SNMP does not support southbound SNMP relaying (SNMP SET, GET, and GETNEXT).
The primary advantage of CTM GateWay/SNMP is to limit the amount of traffic on the wide-area DCN. Imagine NEs deployed over a wide geographic area and a centralized network operations center where the management systems are located. If there are five OSs required to receive NE traps, instead of having each NE send five traps over the wide area to each OS, send a single trap to CTM, which can then relay the trap locally in the NOC to the other OSs. NE configuration is also simpler because only one trap destination needs to be configured on each NE.
CTM GateWay/SNMP supports SNMPv1 and SNMPv2c traps. SNMPv2c traps contain the CTM host IP address in the source address of the IP packet. In order for the OS to determine which NE sent the trap, the trap must be defined with a variable binding that indicates the source NE.
CTM GateWay/SNMP is applicable to any NE with an SNMP interface.
Note Table 2-3 on page 2-3 shows the NEs that support CTM GateWay/SNMP.
The following figure shows the CTM GateWay/SNMP communications architecture within a service provider's OSS environment.
Figure 12-1 CTM GateWay/SNMP Communications Architecture
12.2.1.1 Starting and Stopping the CTM GateWay/SNMP Service
CTM GateWay/SNMP is a CTM process that can be separately started and stopped through the Control Panel. NEs must be configured with the CTM server IP address as a trap destination for traps to be sent from the NEs to CTM.
Step 1 In the Domain Explorer window, choose Administration > Control Panel.
Step 2 In the Control Panel window, click GateWay/SNMP Service. Table 12-10 describes the fields in the GateWay/SNMP Service pane.
Step 3 In the Status area, click the Start button to start CTM GateWay/SNMP. Notice that the service status toggles to Active.
Step 4 Click Stop to stop the service. The service status toggles to Not Active.
Note The CTM GateWay/SNMP Service can take up to 60 seconds to initialize after the GUI status has changed to indicate that the service is up. The status is an indication of the successful initiation of the service startup, not successful initialization. To avoid problems with the service hanging, wait at least 60 seconds after starting or stopping the service before restarting it.
12.2.1.2 Adding and Removing a CTM GateWay/SNMP Host
You can configure up to 16 SNMP trap destination hosts for CTM GateWay/SNMP. (No duplication check is enforced.)
Step 1 In the Domain Explorer window, choose Administration > Control Panel.
Step 2 In the Control Panel window, click GateWay/SNMP Service. Table 12-10 describes the fields in the GateWay/SNMP Service pane.
Step 3 In the SNMP Hosts field, enter the IP address of the SNMP forwarding host; then, click Add. To remove an SNMP host, select the IP address of the host and click Remove.
Step 4 Repeat for each host to be added or removed; then, click Save.
Table 12-10 Field Descriptions for GateWay/SNMP Service Pane
Field
|
Description
|
Service Status
|
Displays the current status of the service: Active or Not Active.
|
Service Action
|
Allows you to stop or start the CTM GateWay/SNMP service. Notice that the Service Action button toggles between Stop or Start and the Service Status field changes accordingly.
|
SNMP Hosts
|
Displays the IP address of the host where each SNMP trap will be forwarded. You can enter up to 16 IP addresses. Use the Add and Remove buttons to add or remove host IP addresses.
|
12.2.1.3 Configuring SNMP on NEs
SNMP must be configured for each NE that uses CTM GateWay/SNMP. This section contains the following procedures:
•Configuring SNMP for the ONS 15216 EDFA2 and EDFA3
•Configuring SNMP for the ONS 15302 and ONS 15305
•Configuring SNMP for CTC-Based NEs
•Configuring SNMP for the ONS 15501, ONS 15530, and ONS 15540
For additional information, refer to the NE user documentation.
Note When configuring SNMP on NEs, make sure that no other SNMP daemon is running on the designated CTM server host.
Note If you enter the showctm command after configuring SNMP, CTM GateWay/SNMP is not shown. This is because the showctm command shows all of the CTM processes and CTM GateWay/SNMP is not a separate process. Use the Service Monitor table to view the status of CTM GateWay/SNMP.
12.2.1.3.1 Configuring SNMP for the ONS 15216 EDFA2 and EDFA3
For the ONS 15216 EDFA2 and EDFA3, SNMP trap entries are automatically added when the NE is added to CTM. See 5.3.9 Using SNMP, page 5-19 for more information.
12.2.1.3.2 Configuring SNMP for the ONS 15302 and ONS 15305
For information on how to configure SNMP for the ONS 15302 and ONS 15305, refer to the Cisco ONS 15302 Installation and Operations Guide or Cisco ONS 15305 Installation and Operations Guide.
12.2.1.3.3 Configuring SNMP for CTC-Based NEs
Step 1 Select a CTC-based NE in the Domain Explorer tree and choose Configuration > NE Explorer (or click the Open NE Explorer tool).
Step 2 In the node properties pane, click the Network tab; then, click the SNMP subtab.
Step 3 (Not applicable to the ONS 15600) To allow SNMP proxy, check the Allow SNMP Proxy check box.
Step 4 (Not applicable to the ONS 15600) To use the SNMP management software with the NE, check the Allow SNMP Set check box.
Step 5 (Not applicable to the ONS 15600) Click Apply.
Step 6 Click Create. The Create SNMP Trap Destination dialog box opens. The following table provides descriptions.
Step 7 After making your selections, click OK.
Step 8 Click Apply.
Table 12-11 Field Descriptions for the Create SNMP Trap Destination Dialog Box
Field
|
Description
|
IP Address
|
Enter the IP address of your NMS.
|
Community Name
|
Enter the SNMP community name. For a description of SNMP community names, refer to the SNMP information in the NE reference guide.
Note The community name is a form of authentication and access control. The community name assigned to the ONS 15600 is case-sensitive and must match the community name of the NMS.
|
UDP Port
|
Set the UDP port for SNMP. The Cisco default port is 162. Allowed UDP port values are 162, 391, and values between 1024 and 65535.
|
Trap Version
|
Set the Trap Version field for either SNMPv1 or SNMPv2. See your NMS documentation to determine whether to use SNMPv1 or SNMPv2.
|
Max Traps per Second (not applicable to the ONS 15600)
|
Enter the maximum number of traps per second that will be sent to the SNMP manager. A zero value indicates that there is no maximum and all traps are sent to the SNMP manager.
|
12.2.1.3.4 Configuring SNMP for the ONS 15501, ONS 15530, and ONS 15540
Configuring SNMP on ONS 15501, ONS 15530, and ONS 15540 NEs is a prerequisite for adding an NE to CTM. If SNMP is not configured on the NE, refer to the instructions in the relevant hardware configuration guide.
12.2.2 Managing CTM GateWay/TL1
CTM GateWay/TL1 provides EMS-to-NMS interface mediation, which allows up to 25 (configurable) OSSs to receive native TL1-based alarm, event, and performance monitoring reports from CTM simultaneously. CTM GateWay/TL1 forwards autonomous TL1 messages from the NEs to the OSS and manages TL1 commands and responses between the OSS and the NEs.
TL1 is a standard Man-Machine Language (MML) developed by Telcordia Technologies (formerly Bellcore) in the mid-1980s as a basis for interoperability across multivendor technologies. In a series of published standards, Telcordia defined the TL1 language and a number of messages specific to technology, such as transport and access NEs. As deployment of TL1-based NEs increased throughout North America, Telcordia and other vendors developed OSS software applications by using TL1 as the NE management protocol.
With CTM GateWay/TL1, service providers can use their TL1-based OSSs to manage the TL1-capable NEs in the CTM management domain without significant interface development. In addition, only a single Telnet session is needed to interface to the CTM domain manager and manage a complete subnetwork of NEs through TL1.
Note Table 2-3 on page 2-3 shows the NEs that support CTM GateWay/TL1.
There are a number of advantages to using CTM GateWay/TL1 as opposed to having an OS connected directly to each NE:
•In the case of multiple OSs, a single TL1 session on the NE can be shared
•Using the Domain Manager Mode (DMM) feature of CTM GateWay/TL1, the OSS is not required to log into each NE, but only has to log into CTM itself to gain access to all the NEs
•Event forwarding discriminators (EFDs), or filters, can be configured in CTM GateWay/TL1 to customize which autonomous notifications are forward to the OS
•DMM commands provide the ability for OSs to discover which NEs are in the network
Note CTM GateWay/TL1 reports all TL1 messages in Greenwich Mean Time (GMT).
Note Secure TL1 communication to the NE is supported with CTM GateWay/TL1 in CTM R7.0.
The following figure shows the CTM GateWay/TL1 communications architecture within a service provider's OSS environment.
Figure 12-2 CTM GateWay/TL1 Communications Architecture
The CTM GateWay/TL1 message set is based on the following Telcordia standards:
•GR-833-CORE: OTGR: Network Maintenance: Network Element and Transport Surveillance Messages. Issue 2, November 1996.
•SR-1665: NMA Operations System Generic Transport Network Element Interface Support. Issue 1, December 1997.
•SR-NWT-002723: Applicable TL1 Messages for SONET Network Elements. Issue 1, June 1993.
12.2.2.1 Setting the CTM GateWay/TL1 Username and Password
CTM requires the specification of a TL1 username and password that it can use to log into each NE that will be supported though CTM GateWay/TL1. This username and password are specified in one of the following locations:
•Control Panel for each NE model
•Domain Explorer > Network Element Properties pane > NE Authentication tab for each node
The changes to the username and password take effect after CTM reconnects to the NE either by restarting CTM GateWay/TL1 or by setting the NE's operational state to Out of Service and to In Service again.
Note Make sure that you set the correct CTM Gateway/TL1 username and password in all the CTM servers so that the CTM GateWay/TL1 service will stop trying to connect to the NEs using the wrong username and password.
12.2.2.1.1 Setting the CTM GateWay/TL1 Username and Password from the Control Panel
Step 1 In the Domain Explorer window, choose Administration > Control Panel.
Step 2 Click Security Properties; then, click one of the following:
•ONS 15216 EDFA2
•ONS 15216 EDFA3
•ONS 15216 OADM
•ONS 155XX
•ONS 158XX
•CTC-Based SDH tab > ONS 15454 SDH, ONS 15600 SDH subtab
•CTC-Based SONET tab > ONS 15310 CL, ONS 15310 MA, ONS 15327, ONS 15454, ONS 15600 subtab
Step 3 In the GateWay/TL1 - NE Connection area, enter the username and password.
Note For the ONS 15800, ONS 15801, and ONS 15808, the CTM GateWay/TL1 username and password are the same as those used for general CTM connectivity to the NE.
Note The GateWay/TL1 - NE Connection area is not applicable for ONS 15454 SDH releases earlier than R5.0.
Note The ONS 15216 EDFA3 supports only a single TL1 session for each username. Make sure that the username you choose is not already used for the CTM connection with the NE.
Step 4 Retype the password as confirmation.
Step 5 Click Save.
12.2.2.1.2 Setting the CTM GateWay/TL1 Username and Password from the Domain Explorer
Step 1 In the Domain Explorer tree, click an ONS 15216 EDFA2, ONS 15216 EDFA3, ONS 15216 OADM, ONS 15310 CL, ONS 15310 MA, ONS 15327, ONS 15454 SONET, ONS 15454 SDH, ONS 155XX, ONS 15600 SONET, or ONS 1580x NE.
Step 2 In the Network Element Properties pane, click the NE Authentication tab.
Step 3 In the GateWay/TL1 - NE Connection area, enter the username and password.
Note The ONS 15454 SDH R5.0 supports a TL1 interface. The GateWay/TL1 - NE Connection area is not available for ONS 15454 SDH releases earlier than R5.0.
Note The ONS 15216 EDFA3 supports only a single TL1 session for each username. Make sure that the username you choose is not already used for the CTM connection with the NE.
Step 4 Retype the password as confirmation.
Step 5 Click Save.
Note If no username and password are configured in the NE Authentication tab of the Domain Explorer, CTM GateWay/TL1 uses the username and password specified in the Control Panel.
12.2.2.2 Using the GateWay/TL1 Service Pane
Use the GateWay/TL1 Service pane in the Control Panel window to start and stop the CTM GateWay/TL1 Service and configure TL1-specific parameters. TL1-specific parameters are listed in the following table. In the Domain Explorer, choose Administration > Control Panel; then, click GateWay/TL1 Service.
Table 12-12 Field Descriptions for CTM GateWay/TL1 Service Pane
Field
|
Description
|
Status
|
Service Status
|
Displays the current status of the CTM GateWay/TL1 service: Active or Not Active.
|
Service Action
|
Allows you to stop or start the CTM GateWay/TL1 service. The Service Action button toggles between Stop or Start, and the Service Status field changes accordingly.
|
GateWay/TL1 Polling
|
GateWay/TL1 Poll Frequency
|
Allows you to set the CTM GateWay/TL1 poll frequency, in seconds. The minimum time is 60 seconds; the maximum time is 60 minutes. Changes occur when CTM GateWay/TL1 is restarted.
The poll cycle ensures that TL1 connectivity to the managed nodes works correctly. A failure in the polling for a given node implies that all of the commands directed to that node receive a "Gateway Not Ready" error code. This condition persists until the first successful polling cycle on that NE.
Note Be aware that the connectivity status reported by the CTM client might not be aligned with the connectivity status detected by CTM GateWay/TL1. This discrepancy occurs because the CTM server checks the status of the NE's management interface, while CTM GateWay/TL1 checks the status of the NE's TL1 interface. As a result, the CTM client might show an NE as connected (meaning that the management interface used by the CTM server works correctly), while TL1 commands directed to the same NE receive a "Gateway Not Ready" error code (meaning that TL1 connectivity between the server and the node is temporarily unavailable).
Note TL1 agents on the nodes typically define an idle timeout parameter, which is the maximum time a session can remain idle without being closed automatically by the NE's embedded software. You must set the GateWay/TL1 Poll Frequency parameter to a lower value than any idle timeout parameter defined in the network. If the polling time is equal to or greater than the idle timeout defined on a given NE, that NE will experience systematic loss of TL1 connectivity.
Note The GateWay/TL1 Poll Frequency parameter should be long enough to allow CTM GateWay/TL1 to perform a complete round of polling on all of its managed NEs. Therefore, make the poll frequency as long as possible, without exceeding the idle timeout value.
|
GateWay/TL1 Connection Parameters
|
GateWay/TL1 Timeout
|
Allows you to set the CTM GateWay/TL1 connection timeout, in seconds. The minimum timeout value is 240 seconds (4 minutes); the maximum value is 1 day.
|
GateWay/TL1 Connections
|
Allows you to set the number of CTM GateWay/TL1 connections.
|
Apply Timeout to
|
You can apply the timeout feature for the following:
•Login command (ACT-USER): The session will be closed if the ACT-USER command is not performed before the requested timeout and if the Listener Mode is disabled.
•All valid TL1 command: The session will be closed if a valid command is not sent by the OSS to CTM before the requested timeout and if the Listener Mode is disabled.
Changes occur when CTM GateWay/TL1 is restarted.
|
Enable Command Echo
|
Allows you to view the command line when you enter commands during a GateWay/TL1 session. This also allows you to log all messages received during a GateWay/TL1 session. Check or uncheck the Enable Command Echo check box to enable or disable echoing the GateWay/TL1 session.
|
GateWay/TL1 Advisory Message
|
Enable Advisory Message
|
Allows you to display and configure an advisory message that appears after a successful login to CTM GateWay/TL1. Check or uncheck the Enable Advisory Message check box to enable or disable the message display.
|
Message Content
|
Allows you to enter the text of the advisory message. The message cannot exceed 255 ASCII characters. Non-ASCII characters are not supported. It is not necessary to restart CTM GateWay/TL1 after updating the message.
|
TID/SID for CTM
|
Displays the target identifier (TID) and/or source identifier (SID) used by the EMS. It can be configured for DMM operation. The Cisco default value is "CTM." If the TID/SID information is changed, restart the CTM GateWay/TL1 service to make the new TID/SID take effect.
|
Error Level
|
Allows you to select the error level to include in the error log for the CTM GateWay/TL1 service. Critical, major, minor, and informational errors are logged to the database; trace and debug information is logged to a log file.
Caution CTM performance will degrade significantly if the trace or debug option is left on. All operations will slow down and you might lose alarm and event notifications. Use trace or debug only when troubleshooting with a customer support engineer.
Note Trace and debug information does not appear in the error log.
|
12.2.2.3 Starting or Stopping CTM GateWay/TL1
Note If an NE is added to multiple CTM servers, start the CTM Gateway/TL1 service in only one server.
The CTM GateWay/TL1 service can be stopped or started by using either the Control Panel or the CLI.
12.2.2.3.1 Starting or Stopping CTM GateWay/TL1 from the Control Panel
Step 1 In the Domain Explorer window, choose Administration > Control Panel.
Step 2 Click GateWay/TL1 Service to open the GateWay/TL1 Service pane.
Step 3 In the Global tab > Status area, click the Start button to start GateWay/TL1 or the Stop button to stop the service.
Note The CTM GateWay/TL1 Service can take up to 60 seconds to initialize after the GUI status has changed to indicate that the service is up. The status is an indication of the successful initiation of the service startup, not successful initialization. To avoid problems with the service hanging, wait at least 60 seconds after starting or stopping the service before restarting it.
12.2.2.3.2 Starting or Stopping CTM GateWay/TL1 Using the CLI
Step 1 Log into the CTM server with administrative privileges.
Step 2 Enter the following command to run the script that will start CTM GateWay/TL1:
Step 3 Enter the following command to run the script that will stop CTM GateWay/TL1:
Step 4 Enter your username and password.
12.2.2.4 Configuring the TL1 Timeout
The TL1 timeout determines the number of seconds that CTM maintains an active TL1 connection before closing it. If the CTM server does not return a response in time, TL1 automatically times out.
Step 1 In the Domain Explorer, choose Administration > Control Panel.
Step 2 Click GateWay/TL1 Service to open the GateWay/TL1 Service pane.
Step 3 In the Global tab, fill in the following fields:
•GateWay/TL1 Poll Frequency
•GateWay/TL1 Timeout
•GateWay/TL1 Connections
•Apply Timeout to (see the following table for a summary of timeout behavior)
Step 4 Click Save. All changes take effect when CTM GateWay/TL1 is restarted.
Table 12-13 Timeout Behavior
Listener Mode
|
DMM
|
Timeout Applicable
|
Apply Timeout to ACT-USER
|
Apply Timeout to All Valid TL1 Command
|
Yes
|
Yes
|
No
|
Not applicable
|
Not applicable
|
Yes
|
No
|
No
|
No
|
Yes
|
Yes
|
Session is closed if the ACT-USER is not performed before the given timeout.
|
Session is closed if user does not send any valid command including ACT-USER.
|
No
|
No
|
Yes
|
12.2.2.5 Configuring the TID/SID in CTM GateWay/TL1
Step 1 In the Domain Explorer, choose Administration > Control Panel.
Step 2 Click GateWay/TL1 Service to open the GateWay/TL1 Service pane.
Step 3 In the Global tab, enter the new TID or SID for CTM GateWay/TLI in the TID/SID for CTM field.
Step 4 Click Save. All changes take effect when CTM GateWay/TL1 is restarted.
12.2.2.6 Defining CTM GateWay/TL1 Advisory Messages
CTM allows you to define an advisory message on the successful connection of CTM GateWay/TL1 to the OSS.
Step 1 In the Domain Explorer, choose Administration > Control Panel.
Step 2 Click GateWay/TL1 Service to open the GateWay/TL1 Service pane.
Step 3 In the Global tab, check the Enable Advisory Message check box, and enter the text of your advisory message in the Message Content field.
Step 4 Click Save.
12.2.2.7 Setting CTM GateWay/TL1 Error Levels
Note For more information about error levels, see Chapter 9, "Managing Faults."
Step 1 In the Domain Explorer, choose Administration > Control Panel.
Step 2 Click GateWay/TL1 Service to open the GateWay/TL1 Service pane.
Step 3 In the Global tab, select an error level in the Error Level field.
Step 4 Click Save.
12.2.2.8 Viewing the GateWay/TL1 Users Table
The GateWay/TL1 Users table displays a profile for each OSS client that uses a CTM GateWay/TL1 service. With that profile, depending on the Listener Mode parameter value, it is possible to allow an OSS to receive autonomous messages from the CTM managed NEs before the OSS establishes a session with them. Also, the DMM parameter specifies whether the OSS can access some database information with the commands listed previously.
You can add, modify, or delete CTM GateWay/TL1 OSS profiles using the GateWay/TL1 Users table. To view the GateWay/TL1 Users table, choose Administration > GateWay/TL1 Users in the Domain Explorer window. The following table provides descriptions.
Table 12-14 Field Descriptions for GateWay/TL1 Users Table
Column Name
|
Description
|
OSS Profile Name
|
OSS client profile name. Each client has a unique alphanumeric name. This name corresponds with the user ID that will be used to log into CTM GateWay/TL1 for access to DMM functionality. The profile name cannot contain spaces or a colon (:), semicolon (;), or comma (,).
|
OSS IP Address
|
IP address of the OSS client that is authenticated by CTM GateWay/TL1 during the initial connection request made by the OSS.
Note Each OSS profile defines a specific IP address for logins. CTM GateWay/TL1 allows connection only from the specific IP address that is defined for the user. If the user tries to connect from a different IP address, the connection is refused.
|
Listener Mode
|
If enabled, the OSS client receives autonomous TL1 messages from allowed NEs when the OSS client connects to CTM. If disabled, autonomous TL1 messages are not forwarded until the OSS successfully logs into NEs by using the ACT-USER command.
|
Domain Manager Mode
|
If enabled, a TL1 command subset is available to the OSS for direct communication with CTM. TL1 commands include:
•ACT-USER
•CANC-USER
•RTRV-HDR
•RTRV-NE-EMS
•RTRV-SUBNTWK-EMS
•RTRV-ALM-EMS
•RTRV-ALM-ALL
•RTRV-ALM-ENV
If disabled, the TL1 command subset is not available to the OSS.
|
Event Forwarding Discriminator State
|
If enabled, indicates that the CTM GateWay/TL1 session uses an EFD profile. EFD profiles set the parameters for forwarding TL1 messages to the OSS client. If disabled, an EFD profile is not used in the CTM GateWay/TL1 session.
|
Event Forwarding Discriminator Name
|
If an EFD profile is used in the OSS client session, EFD Name indicates the name of that profile.
|
12.2.2.9 Managing OSS Client Profiles
The following sections detail how to create, modify, and delete OSS client profiles.
12.2.2.9.1 Creating an OSS Client Profile
Each OSS profile defines CTM GateWay/TL1 parameters, such as the OSS IP address, permissions, listener mode, and DMM. OSS client profiles are stored in the GateWay/TL1 Users table.
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Choose Edit > Add (or click the Create a New User tool). The Add GateWay/TL1 User dialog box opens. The following table provides descriptions.
Step 3 After making your selections, click OK. The new profile is listed in the GateWay/TL1 Users table.
Table 12-15 Field Descriptions for Add/Modify GateWay/TL1 User Dialog Box
Field
|
Description
|
OSS Profile Name
|
Enter the name of the OSS profile. The profile name cannot contain spaces or a colon (:), semicolon (;), or comma (,).
|
Password
|
Enter the password that the OSS client uses to log into the CTM server. The password must:
•Contain from six to 64 characters
•Contain at least two alphabetic characters (A-Z, a-z)
•Contain at least one numeric character (0-9)
•Contain at least one special character (. % & ! + #)
•Not contain a colon (:), semicolon (;), or comma (,).
|
Confirm Password
|
Re-enter the password to confirm it.
|
OSS IP Address
|
Enter the OSS IP address.
|
Listener Mode
|
If enabled, the OSS client connects to CTM. If disabled, the OSS does not receive autonomous TL1 messages until it successfully logs into the CTM by using the ACT_USER command.
|
Domain Manager Mode
|
If enabled, a TL1 command subset is available to the OSS for direct communication with CTM. TL1 commands include ACT-USER, CANC-USER, RTRV-HDR, and RTRV-NE. If disabled, the TL1 command subset is not available to the OSS.
|
EFD State
|
If enabled, the OSS uses the EFD profile selected under EFD Name to filter the events forwarded to it. If disabled, an EFD profile is not used.
|
EFD Name
|
If EFD State is enabled, displays the EFD profile name. You can select one of 12 EFD profiles delivered with CTM, or click Create to create a new profile. The maximum length of an EFD name is 64 characters.
|
12.2.2.9.2 Modifying an OSS Client Profile
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Select the OSS client profile to modify; then, choose Edit > Modify (or click the Modify User Properties tool). The Modify GateWay/TL1 User dialog box opens. Table 12-15 describes the fields in the dialog box.
Step 3 Modify the fields described in Table 12-15.
Note If there are active users logged into CTM using the OSS profile being modified, CTM GateWay/TL1 does not allow you to modify the OSS Profile Name, Password, and OSS IP Address fields. The Listener Mode, Domain Manager Mode, EFD State, and EFD Name fields can be modified.
Note Regardless of the actual size of the password, the Password and Confirm Password fields display only a fixed-length string. The fixed-length string is 12 asterisks (*).
Step 4 Click OK. The updated profile is listed in the GateWay/TL1 Users table.
12.2.2.9.3 Deleting an OSS Client Profile
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Select the OSS client profile to delete; then, choose Edit > Delete (or click the Delete User tool).
Step 3 Click OK in the confirmation dialog box.
Note CTM GateWay/TL1 does not allow an OSS profile to be deleted if there are active users logged in using that OSS profile.
12.2.2.10 Managing EFD Profiles
The following sections detail how to view, create, modify, and delete EFD profiles.
12.2.2.10.1 Viewing the EFD Table
The GateWay/TL1 Event Forwarding Discriminator table displays EFD profiles for OSS clients that use the CTM GateWay/TL1 service. EFD profiles define the parameters for filtering and forwarding alarms and events, which helps limit the flow of messages to the OSS.
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Choose Administration > GW/TL1 EFD Table. The following table provides descriptions.
Table 12-16 Field Descriptions for GateWay/TL1 Event Forwarding Discriminator Table
Column Name
|
Description
|
Event Forwarding Discriminator Name
|
EFD profile name. Each profile has a unique alphanumeric name. CTM is delivered with twelve EFD profiles. You can create new profiles. See Creating an EFD Profile.
|
Alarm Reporting
|
If enabled, NE alarms (REPT ALM) are forwarded to the OSS client. If disabled, NE alarms are not forwarded to the OSS client.
|
Event Reporting
|
If enabled, NE events (REPT EVT) are forwarded to the OSS client. If disabled, NE events are not forwarded to the OSS client.
|
PM Reporting
|
If enabled, NE performance monitoring events (REPT PM) are forwarded to the OSS client. If disabled, NE PM events are not forwarded to the OSS client.
|
Critical
|
If enabled, critical severity alarms are forwarded to the OSS client. (Alarm reporting must be enabled.) If disabled, NE critical alarms are not forwarded to the OSS client.
|
Major
|
If enabled, major severity alarms are forwarded to the OSS client. (Alarm reporting must be enabled.) If disabled, NE major alarms are not forwarded to the OSS client.
|
Minor
|
If enabled, minor severity alarms are forwarded to the OSS client. (Alarm reporting must be enabled.) If disabled, minor alarms are not forwarded to the OSS client.
|
Denied NE Target IDs
|
NE target IDs whose alarms and events are not forwarded to the OSS client.
|
Denied NE Access IDs
|
NE access IDs used to filter forwarded alarms and events. Denied Access IDs can filter one or more of the following: DS1, EC1, T1, T3, VT1, OC12, OC3, OC48, OC192, STS1, STS3c, STS12c, STS48c, CHASSIS (equipment alarms), ENET (Ethernet), BITS, ENV (environmental alarms), SYNCN (synchronization messages), and ALL.
|
12.2.2.10.2 Creating an EFD Profile
Each OSS client profile can include an EFD profile, which allows filtering of alarms and events that are forwarded to the OSS. CTM is delivered with 12 EFD profiles.
Table 12-17 Event Forwarding Discriminator Profiles
EFD Name
|
Event Type
|
Alarm Severity
|
Target Identifier
|
Access Identifier
|
Alarm
|
Event
|
PM
|
Critical
|
Major
|
Minor
|
Alarms & Events
|
X
|
X
|
—
|
X
|
X
|
X
|
All
|
All
|
Alarms Only
|
X
|
—
|
—
|
X
|
X
|
X
|
All
|
All
|
All Pass
|
X
|
X
|
X
|
X
|
X
|
X
|
All
|
All
|
Critical Alarms Only
|
X
|
—
|
—
|
X
|
—
|
—
|
All
|
All
|
Equipment Alarms Only
|
X
|
—
|
—
|
X
|
X
|
X
|
All
|
—
|
Events Only
|
—
|
X
|
—
|
—
|
—
|
—
|
All
|
All
|
Facility Alarms Only
|
X
|
—
|
—
|
X
|
X
|
X
|
All
|
—
|
Major Alarms Only
|
X
|
—
|
—
|
—
|
X
|
—
|
All
|
All
|
Major & Higher Alarms
|
X
|
—
|
—
|
X
|
X
|
—
|
All
|
All
|
Minor Alarms Only
|
X
|
—
|
—
|
—
|
—
|
X
|
All
|
All
|
Minor & Higher Alarms
|
X
|
—
|
—
|
X
|
X
|
X
|
All
|
All
|
PM Only
|
—
|
—
|
X
|
—
|
—
|
—
|
All
|
All
|
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Choose Administration > GW/TL1 EFD Table.
Step 3 In the GW/TL1 Event Forwarding Discriminator table, choose Edit > Add EFD Profile. The Create Event Forwarding Discriminator Profile wizard appears. The following table provides descriptions.
Step 4 Fill in the following fields:
•Name
•Event Type
•Alarm Severity
Step 5 Click Next.
Step 6 Choose a target ID; then, click Next.
Step 7 Choose an access ID; then, click Finish.
The new EFD profile appears in the GW/TL1 Event Forwarding Discriminator table.
Table 12-18 Field Descriptions for Create Event Forwarding Discriminator Profile Wizard
Field
|
Description
|
Event Forwarding Discriminator Profile
|
Name
|
Enter the name of the EFD profile. The maximum length of an EFD name is 64 alphanumeric characters. The name cannot contain special characters.
|
Event Type
|
Select the type of event to forward to the OSS:
•Alarm Reporting: If selected, forwards NE alarm messages (REPT ALM) to the OSS.
•PM Reporting: If selected, forwards NE performance monitoring messages (REPT PM) to the OSS.
•Event Reporting: If selected, forwards NE event messages (REPT EVT) to the OSS.
|
Alarm Severity
|
If Alarm Reporting is selected under Event Type, select the severity of alarms to forward to the OSS:
•Critical: If selected, forwards critical NE alarms to the OSS.
•Major: If selected, forwards major NE alarms to the OSS.
•Minor: If selected, forwards minor NE alarms to the OSS.
|
Choose Target IDs
|
Available
|
Choose the target IDs of NEs whose TL1 messages you want forwarded to the OSS. NEs in the Available column will have their TL1 messages forwarded to the OSS. All TL1-capable NEs in the CTM management domain display in the Available column by default. Use the Add and Remove buttons to move target IDs between the Available column and the Denied column.
|
Denied
|
Autonomous messages from NE target IDs in this column will not be forwarded to the OSS.
|
Choose Access IDs
|
Available
|
Choose TL1 access IDs for which autonomous TL1 messages will be forwarded to the OSS. All access IDs are available by default. Use the Add and Remove buttons to move access IDs between the Available column and the Denied column.
|
Denied
|
Autonomous messages from NEs that include access IDs in this column will not be forwarded to the OSS.
|
12.2.2.10.3 Modifying an EFD Profile
Use the Modify Event Forwarding Discriminator Profile wizard to modify an EFD profile for OSSs that use the CTM GateWay/TL1 service to receive TL1 messages from NEs that support a TL1 interface.
EFD profiles define the parameters for filtering and forwarding TL1 messages from NEs to the OSS.
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Choose Administration > GW/TL1 EFD Table.
Step 3 In the GW/TL1 Event Forwarding Discriminator table, select the EFD profile to modify; then, choose Edit > Modify EFD Profile. The Modify Event Forwarding Discriminator Profile wizard opens. The following table provides descriptions.
Step 4 Modify the following fields, as necessary:
•Name
•Event Type
•Alarm Severity
Step 5 Click Next.
Step 6 Modify the list of target IDs, as necessary; then, click Next.
Step 7 Modify the list of access IDs, as necessary; then, click Finish.
The modified EFD profile appears in the GW/TL1 Event Forwarding Discriminator table.
Table 12-19 Field Descriptions for Modify Event Forwarding Discriminator Profile Wizard
Field
|
Description
|
Event Forwarding Discriminator Profile
|
Name
|
Modify the name of the EFD profile. The maximum length of an EFD name is 64 alphanumeric characters. The name cannot contain special characters.
|
Event Type
|
Modify the type of events to forward to the OSS:
•Alarm Reporting: If selected, forwards NE alarm messages (REPT ALM) to the OSS.
•PM Reporting: If selected, forwards NE performance monitoring messages (REPT PM) to the OSS.
•Event Reporting: If selected, forwards NE event messages (REPT EVT) to the OSS.
|
Alarm Severity
|
If Alarm Reporting is selected under Event Type, modify the severity of alarms to forward to the OSS:
•Critical: If selected, forwards critical NE alarms to the OSS.
•Major: If selected, forwards major NE alarms to the OSS.
•Minor: If selected, forwards minor NE alarms to the OSS.
|
Choose Target IDs
|
Available
|
Modify the target IDs of NEs whose TL1 messages you want forwarded to the OSS. NEs in the Available column will have their TL1 messages forwarded to the OSS. Use the Add and Remove buttons to move target IDs between the Available column and the Denied column.
|
Denied
|
Autonomous messages from NE target IDs in this column will not be forwarded to the OSS.
|
Choose Access IDs
|
Available
|
Modify TL1 access IDs for which autonomous TL1 messages will be forwarded to the OSS. Use the Add and Remove buttons to move access IDs between the Available column and the Denied column.
|
Denied
|
Autonomous messages from NEs that include access IDs in this column will not be forwarded to the OSS.
|
12.2.2.10.4 Deleting an EFD Profile
Note An EFD profile can be deleted from the EFD table only if the profile is not associated with an OSS client.
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Choose Administration > GW/TL1 EFD Table.
Step 3 In the GW/TL1 Event Forwarding Discriminator table, select the EFD profile to delete; then, choose Edit > Delete EFD Profile.
Step 4 Click OK in the confirmation dialog box.
12.2.2.11 Viewing Active CTM GateWay/TL1 Users
You can monitor and log out the connected OSS TL1 clients in the Logged In GateWay/TL1 Users table.
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Choose Administration > Logged In GateWay TL1 Users. The CTM Active GWTL1 Users table opens. The following table provides descriptions.
Table 12-20 Field Descriptions for CTM Active GWTL1 Users Table
Field
|
Description
|
OSS Profile Name
|
Name of the OSS profile. Each client has a unique alphanumeric name. The profile name cannot contain spaces or a colon (:), semicolon (;), or comma (,).
|
OSS IP Address
|
IP address of the OSS client that is authenticated by CTM GateWay/TL1 during the initial connection request made by the OSS.
|
Session ID
|
Unique session ID.
|
Time of First Connection
|
Time of the user's first connection to the server.
|
Listener Mode
|
If enabled, the OSS client receives autonomous TL1 messages from allowed NEs when the OSS client connects to CTM. If disabled, autonomous TL1 messages are not forwarded until the OSS successfully logs into NEs by using the ACT-USER command.
|
Domain Manager Mode
|
If enabled, a TL1 command subset is available to the OSS for direct communication with CTM. TL1 commands include ACT-USER, CANC-USER, RTRV-HDR, and RTRV-NE. If disabled, the TL1 command subset is not available to the OSS.
|
12.2.2.12 Logging Out an Active CTM GateWay/TL1 User
Step 1 In the Domain Explorer window, choose Administration > GateWay/TL1 Users. The GateWay/TL1 Users table opens.
Step 2 Choose Administration > Logged In GateWay TL1 Users. The CTM Active GWTL1 Users table opens.
Step 3 Select a user and choose Administration > Log Out GateWay TL1 User.
12.2.2.13 Establishing Connectivity Between CTM GateWay/TL1 and the OSS
To achieve connectivity between the OSS and CTM GateWay/TL1, establish a direct Telnet session to the CTM server on port 26715. To enable this connection, start the CTM GateWay/TL1 service on the CTM server.
CTM GateWay/TL1 allows the OSS to connect to all NEs in the CTM management domain by using one TCP/IP socket connection. The TID multiplexes the single logical connection to the actual NEs managed by CTM.
To verify connectivity to the CTM server, the OSS pings the CTM server IP address. (If DMM is enabled, the OSS can also verify connectivity by issuing a RTRV-HDR TL1 command.) However, connectivity between the OSS and the CTM server does not guarantee that the CTM GateWay/TL1 service is operational. Assuming that the CTM GateWay/TL1 service is started, the OSS should also monitor the state of the TCP/IP port socket connection because it reflects the operational state of the CTM GateWay/TL1 service.
12.2.2.13.1 Monitoring Connectivity Between the OSS and the NE
The OSS does not connect directly to an NE; rather, CTM acts as a transparent agent to the OSS (manager). The OSS establishes a logical connection with CTM through the CTM GateWay/TL1 port and inherits connectivity with the entire NE management domain.
The OSS can monitor the connectivity state of each NE by using the RTRV-HDR TL1 command. This assumes that connectivity between the OSS and CTM is established. If the NE is available, a normal response is returned. If there is no response, communication with the target NE is lost.
Note Know the connectivity state between the OSS and CTM and the operational state of the CTM GateWay/TL1 service before interpreting a nonresponse from an NE as a loss of communication.
12.2.2.13.2 Logging Into the NE
After establishing a TCP/IP socket connection with CTM by using the CTM GateWay/TL1 port, the OSS sends an ACT-USER TL1 command to log into each NE as identified by its TID. To log into an NE, the OSS must use a previously configured username and password.
The NE authenticates the user ID (UID) and the password identifier (PID), which are passed within the ACT-USER command string. After the OSS logs in, all NE autonomous message reporting supported by CTM GateWay/TL1 is enabled by default, as indicated by the associated EFD profile.
12.2.2.14 Understanding Domain Manager Mode Commands and Responses
When DMM is enabled in the OSS client profile, the OSS uses the following TL1 commands to communicate directly with CTM to obtain information about TL1-capable NEs that CTM manages:
•ACT-USER
•CANC-USER
•RTRV-ALM-ALL
•RTRV-ALM-EMS
•RTRV-ALM-ENV
•RTRV-HDR
•RTRV-NE-EMS
•RTRV-SUBNTWK-EMS
The following sections describe the DMM commands in detail.
Note For information about TL1 commands and responses that can be used in CTM GateWay/TL1 sessions with CTM-supported NEs, refer to the NE hardware documentation.
12.2.2.14.1 ACT-USER
The OSS uses the ACT-USER command to log into CTM GateWay/TL1.
Table 12-21 ACT-USER—Domain Manager Mode
Item
|
Description
|
Input Format
|
ACT-USER:TID:UID:CTAG::PID;
where:
•TID is the target identifier of the CTM server where the command is directed (equivalent to the SID).
•UID is the OSS profile name that logs into the CTM server.
•CTAG is the correlation tag that correlates command and response messages.
•PID is the password identifier, which is the CTM password assigned to the OSS client.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
;
where:
•SID is the source identifier of the CTM server that generates the response message (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
|
Error Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^DENY cr lf
^^^ERRCDE cr lf
^^^"ERROR DESCRIPTION" cr lf
^^^/*ERROR TEXT*/ cr lf
;
where:
•ERRCDE is the error code associated with the error response. See Table 12-33 for values.
•ERROR DESCRIPTION is the supporting information for the error code (when applicable).
•ERROR TEXT is the detailed text description of the condition.
The default error response to an invalid or incorrect TID field is:
cr lf lf
^^^DATE^TIME cr lf
M^^CTAG^DENY cr lf
^^^ERRCDE cr lf
^^^"ERROR DESCRIPTION" cr lf
;
|
Example
|
Command:
ACT-USER:CTM:OSS:1990::ROOT;
Normal response:
CTM 2004-05-01 12:30:45
M 1990 COMPLD
;
Error response (for a blank PID field):
CTM 2004-05-01 12:30:45
M 1990 DENY
IDNV
/* Input, Data Not Valid */
;
|
Note If DMM is enabled, CTM GateWay/TL1 allows direct access to the NE. There is no need to use an individual ACT-USER command to every NE.
12.2.2.14.2 CANC-USER
The OSS uses the CANC-USER command to log out of CTM GateWay/TL1.
Note In DMM, the CANC-USER command logs out the OSS client from all of the NEs that are available in the CTM domain.
Table 12-22 CANC-USER—Domain Manager Mode
Item
|
Description
|
Input Format
|
CANC-USER:TID:UID:CTAG;
where:
•TID is the target identifier of the CTM server where the command is directed (equivalent to the SID).
•UID is the OSS profile name that logs into the CTM server.
•CTAG is the correlation tag that correlates command and response messages.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
;
where:
•SID is the source identifier of the CTM server that generates the response message (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
|
Error Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^DENY cr lf
^^^ERRCDE cr lf
^^^"ERROR DESCRIPTION" cr lf
^^^/*ERROR TEXT*/ cr lf
;
where:
•ERRCDE is the error code associated with the error response. See Table 12-33 for values.
•ERROR DESCRIPTION is the supporting information for the error code (when applicable).
•ERROR TEXT is the detailed text description of the condition.
|
Example
|
Command:
CANC-USER:CTM:OSS1:1991;
Normal response:
CTM 2004-05-01 12:30:45
M 1991 COMPLD
;
|
12.2.2.14.3 RTRV-ALM-ALL
The OSS uses the RTRV-ALM-ALL command to retrieve all alarm information associated with the CTM management domain.
Table 12-23 RTRV-ALM-ALL—Domain Manager Mode
Item
|
Description
|
Input Format
|
RTRV-ALM-ALL:[TID]:[AID]:CTAG::[NTFCNCDE][,,,,];
where:
•TID is the provisioned target identifier of the CTM server where the command is directed. If the TID is not specified, it is assumed by default.
•AID is the access identifier that identifies the CTM server entity where the command applies. The format is defined as:
NEID[\NEAID]
where:
–NEID is the identifier of the NE (equivalent to the SID).
–NEAID is the access identifier of the NE (equivalent to the AID).
•CTAG is the correlation tag that correlates command and response messages.
•NTFCNCDE is the notification code associated with the alarm requested.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
RSPBLK + ;
where:
•SID is the provisioned SID of the CTM server.
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
•CTAG is the correlation tag that correlates command and response messages.
•RSPBLK is the response block. The format is defined as:
^^^NEID\NEAID:NTFCNCDE,CONDTYPE,SRVEFF,OCRDAT,OCRTM,LOCN,DIRN:*CONDESCR* "cr lf
where:
–NEID is the identifier of the NE.
–NEAID is the access identifier of the NE.
–NTFCNCDE is the two-character notification code with the following possible values: CR (critical), MJ (major), MN (minor), and CL (standing condition cleared).
|
Normal Response
(continued)
|
–CONDTYPE is the single type of alarm condition being reported on this particular line.
–SRVEFF is the effect on service caused by the alarm condition. Values are SA (service affecting) and NSA (not service affecting).
–OCRDAT is the date when the alarm was raised in month of year-day of month (MOY-DOM) format.
–OCRTM is the time when the alarm was raised in hour of day-minute of hour (HOD-MOH) format.
–LOCN is the location where the monitored parameter originates and refers to the entity identified by the NEAID.
–DIRN is the direction to which the monitored parameter applies and is relative to the entity identified by the NEAID.
–CONDDESCR is the detailed text description of the trouble. This field is limited to 64 characters enclosed in escaped quotes (\"), for a maximum of 68 characters (counting the escaped quotes).
|
|
Example
|
Command:
RTRV-ALM-ALL:CTM:ONS1\:1999:MJ;
Normal response:
CTM 00-08-28 17:11:26
M 99 COMPLD
"ONS1\OC48:CR,LOS,SA,08-27,18-45,,:/*Loss of Signal*/"
"ONS1\STS-1-2:MJ,RFI-P,SA,08-27,18-50,,:/* Path Remote Failure Indication*/
;
|
12.2.2.14.4 RTRV-ALM-EMS
The OSS uses the RTRV-ALM-EMS command to retrieve node-based alarm information associated with the CTM management domain.
Note This command has been replaced by the RTRV-ALM-ALL command but is retained for backward compatibility.
Table 12-24 RTRV-ALM-EMS—Domain Manager Mode
Item
|
Description
|
Input Format
|
RTRV-ALM-EMS:TID:[AID]:CTAG::[NTFCNCDE],,;
where:
•TID is the target identifier of the CTM server where the command is directed (equivalent to the SID).
•AID is the access identifier that identifies the CTM server entity where the command applies. The format is defined as:
NEID\NEAID
where:
–NEID is the identifier of the NE (equivalent to the SID). Values are ALL (Cisco default) and the empty set { } (null), which is equivalent to ALL.
–NEAID is the access identifier of the NE (equivalent to the AID). The value is the empty set { } (null).
•CTAG is the correlation tag that correlates command and response messages.
•NTFCNCDE is the two-character notification code associated with a single alarm condition. Values are CR (critical), MJ (major), and MN (minor), with the lower conditions indicating a logical AND function where MJ equals MJ+CR, and MN equals MN+MJ+CR. Other values are ALL (Cisco default) and the empty set { } (null), which is equivalent to ALL.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
RSPBLK + ;
where:
•SID is the source identifier of CTM that is generating the response message (equivalent to TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
|
Normal Response
(continued)
|
•CTAG is the correlation tag that correlates command and response messages.
•RSPBLK is the response block. The message might contain zero or up to 1,000 or more occurrences of the response block, which has the following format:
^^^AID:NTFCNCDE,CONDTYPE,SRVEFF,OCRDAT,OCRTM,LOCN,DIRN:/*CONDESCR*, "cr lf
where:
–AID is the access identifier that identifies a CTM entry to which the command applies. It has the following format:
where:
NEID is the NE identifier equivalent to the source identifier of the NE.
NEAID is the NE access identifier equivalent to the access identifier of the NE.
–NTFCNCDE is the two-character notification code. Values are CR (critical), MJ (major), MN (minor), and CL (standing condition clear).
–CONDTYPE is the single type of alarm condition being reported on this particular line.
–SRVEFF is the effect on service caused by the alarm condition. Values are SA (service affecting) and NSA (not service affecting).
–OCRDAT is the date when the alarm was raised in month of year-day of month (MOY-DOM) format.
–OCRTM is the time when the alarm was raised in hour of day-minute of hour (HOD-MOH) format.
–LOCN is the location where the monitored parameter originates and refers to the entity identified by the NEAID.
–DIRN is the direction to which the monitored parameter applies and is relative to the entity identified by the NEAID.
–CONDDESCR is the detailed text description of the trouble. This field is limited to 64 characters enclosed in escaped quotes (\"), for a maximum of 68 characters (counting the escaped quotes).
|
Error Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^DENY cr lf
^^^ERRCDE cr lf
^^^"ERROR DESCRIPTION" cr lf
^^^/*ERROR TEXT*/ cr lf
;
where:
•ERRCDE is the error code associated with the error response. See Table 12-33 for values.
•ERROR DESCRIPTION is the supporting information for the error code (when applicable).
•ERROR TEXT is the detailed text description of the condition.
|
Example
|
Command:
RTRV-ALM-EMS:CTM:ONS1\:1999::MJ,,;
Normal response:
CTM 00-08-28 12:30:45
M 1999 COMPLD
"ONS1\OC48:CR,LOS,SA,08-27,18-45,,:/* Loss of Signal */"
"ONS1\STS-1-2:MJ,RFI-P,SA,08-27,18-50,,:/* Path Remote Failure Indication */"
;
Error response:
CTM 2004-08-28 12:30:45
M 1999 DENY
INUP
/* Invalid AID block. Invalid Parameters length */
;
|
12.2.2.14.5 RTRV-ALM-ENV
The OSS uses the RTRV-ALM-ENV command to retrieve environmental alarm information associated with the CTM management domain.
Table 12-25 RTRV-ALM-ENV—Domain Manager Mode
Item
|
Description
|
Input Format
|
RTRV-ALM-ENV:[TID]:[AID]:CTAG::[NTFCNCDE][,];
where:
•TID is the target identifier of the CTM server where the command is directed (equivalent to the SID).
•AID is the access identifier that identifies the CTM server entity where the command applies. The format is defined as:
NEID\NEAID
where:
–NEID is the identifier of the NE (equivalent to the SID). Values are ALL (Cisco default) and the empty set { } (null), which is equivalent to ALL.
–NEAID is the access identifier of the NE (equivalent to the AID). The value is the empty set { } (null).
•CTAG is the correlation tag that correlates command and response messages.
•NTFCNCDE is the two-character notification code for the requested environmental alarm.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
RSPBLK + ;
where:
•SID is the source identifier of CTM generating the response message (equivalent to TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
|
Normal Response
(continued)
|
•RSPBLK is the response block. The message might contain zero or up to 1,000 or more occurrences of the response block, which has the following format:
^^^AID:NTFCNCDE,CONDTYPE,SRVEFF,OCRDAT,OCRTM,LOCN,DIRN:/*CONDESCR*, "cr lf
where:
–AID is the access identifier that identifies a CTM entry to which the command applies. It has the following format:
where:
NEID is the NE identifier equivalent to the source identifier of the NE.
NEAID is the NE access identifier equivalent to the access identifier of the NE.
–NTFCNCDE is the two-character notification code. Values are CR (critical), MJ (major), MN (minor), and CL (standing condition clear).
–CONDTYPE is the single type of alarm condition being reported on this particular line.
–SRVEFF is the effect on service caused by the alarm condition. Values are SA (service affecting) and NSA (not service affecting).
–OCRDAT is the date when the alarm was raised in month of year-day of month (MOY-DOM) format.
–OCRTM is the time when the alarm was raised in hour of day-minute of hour (HOD-MOH) format.
–LOCN is the location where the monitored parameter originates and refers to the entity identified by the NEAID.
–DIRN is the direction to which the monitored parameter applies and is relative to the entity identified by the NEAID.
–CONDDESCR is the detailed text description of the trouble. This field is limited to 64 characters enclosed in escaped quotes (\"), for a maximum of 68 characters (counting the escaped quotes).
|
|
Example
|
Command:
RTRV-ALM-ENV:CTM:DEV29\ENV-IN-1:123::MJ,;
Normal response:
CTM 2004-11-19 17:35:56
M 89 COMPLD
"DEV29\ENV-IN-1:CR,APSB,NSA,04-08,06-48,,:/* Byte Failure */"
;
|
12.2.2.14.6 RTRV-HDR
The OSS uses the RTRV-HDR command to retrieve the TID of the CTM server.
Table 12-26 RTRV-HDR—Domain Manager Mode
Item
|
Description
|
Input Format
|
RTRV-HDR:TID::CTAG;
where:
•TID is the target identifier of the CTM server where the command is directed (equivalent to the SID).
•CTAG is the correlation tag that correlates command and response messages.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
;
where:
•SID is the source identifier of the CTM server that generates the response message (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
|
Error Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^DENY cr lf
^^^ERRCDE cr lf
^^^"ERROR DESCRIPTION" cr lf
^^^/*ERROR TEXT*/ cr lf
;
where:
•ERRCDE is the error code associated with the error response. See Table 12-33 for values.
•ERROR DESCRIPTION is the supporting information for the error code (when applicable).
•ERROR TEXT is the detailed text description of the condition.
|
Example
|
Command:
RTRV-HDR:CTM::1992;
Normal response:
CTM 2004-05-01 12:30:45
M 1992 COMPLD
;
Error response (for an invalid command):
CTM 2004-05-01 12:30:45
M 1992 DENY
ICNV
/* The command verb or modifier is invalid */
;
|
12.2.2.14.7 RTRV-NE-EMS
The OSS uses the RTRV-NE-EMS command to retrieve node-based inventory information associated with the CTM management domain.
Table 12-27 RTRV-NE-EMS—Domain Manager Mode
Item
|
Description
|
Input Format
|
RTRV-NE-EMS:TID::CTAG;
where:
•TID is the target identifier of the CTM server where the command is directed (equivalent to the SID).
•CTAG is the correlation tag that correlates command and response messages.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
RSPBLK+;
where:
•SID is the source identifier of the CTM server that generates the response (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
•RSPBLK is the response block.
The message might contain one or up to 1,000 or more occurrences of the response block, which has the following format:
^^^"NEID:NEMOD,COMMST,ALMCNT,OPRNST" cr lf
where:
•NEID is the identifier of the NE (equivalent to the SID).
•NEMOD is the model of the NE.
•COMMST is the communication state of the NE. Values are UNAVAIL (unavailable) and AVAIL (available).
•ALMCNT is the total alarm counts associated with all the severity alarms (CR, MJ, MN) impacting the NE managed by CTM. It has the following format:
{# of Critical Alarms} - {# of Major Alarms} - {# of Minor Alarms}
•OPRNST is the operational state of the NE. Values are IS (In Service) and OOS (Out of Service).
|
Error Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^DENY cr lf
^^^ERRCDE cr lf
^^^"ERROR DESCRIPTION" cr lf
^^^/*ERROR TEXT*/ cr lf
;
where:
•ERRCDE is the error code associated with the error response. See Table 12-33 for values.
•ERROR DESCRIPTION is the supporting information for the error code (when applicable).
•ERROR TEXT is the detailed text description of the condition.
|
Example
|
Command:
RTRV-NE-EMS:CTM::1993;
Normal response:
CTM 00-05-01 12:30:45
M 1993 COMPLD
"ONS3:CISCO-ONS-15454,UNAVAIL,2-4-6,IS"
"ONS4:CISCO-ONS-15454,AVAIL,3-5-7,IS"
;
Error response (for an invalid command):
CTM 2004-07-29 12:30:45
M 1995 DENY
ICNV
/* The command verb or modifier is invalid */
;
|
12.2.2.14.8 RTRV-SUBNTWK-EMS
The OSS uses the RTRV-SUBNTWK-EMS command to retrieve subnetwork-based inventory information associated with the CTM management domain.
Table 12-28 RTRV-SUBNTWK-EMS—Domain Manager Mode
Item
|
Description
|
Input Format
|
RTRV-SUBNTWK-EMS:TID::CTAG;
where:
•TID is the target identifier of the CTM server where the command is directed (equivalent to the SID).
•CTAG is the correlation tag that correlates command and response messages.
|
Normal Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^COMPLD cr lf
RSPBLK + ;
where:
•SID is the source identifier of the CTM server that generates the response message (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
•RSPBLK is the response block.
The message might contain zero or up to 1,000 occurrences of the response block, which has the following format:
^^^"SUBNTWKID:NEID,ADDR,NEMOD,VERSION,GNE,OPRNST,COMMST" cr lf
where:
•SUBNTWKID is the subnetwork identifier defined in the CTM Subnetwork Explorer for the subnetwork entities managed by CTM.
•NEID is the identifier of the NE (equivalent to the SID).
•ADDR is the IP address of the NE.
•NEMOD is the model of the NE.
•VERSION is the version of software running on the NE.
•GNE is the gateway NE SID associated with the NE.
•OPRNST is the operational state of the NE. Values are IS and OOS.
•COMMST is the communication state of the NE. Values are UNAVAIL and AVAIL.
|
Error Response
|
cr lf lf
^^^SID^DATE^TIME cr lf
M^^CTAG^DENY cr lf
^^^ERRCDE cr lf
^^^"ERROR DESCRIPTION" cr lf
^^^/*ERROR TEXT*/ cr lf
;
where:
•ERRCDE is the error code associated with the error response. See Table 12-33 for values.
•ERROR DESCRIPTION is the supporting information for the error code (when applicable).
•ERROR TEXT is the detailed text description of the condition.
|
Example
|
Command:
RTRV-SUBNTWK-EMS:CTM::1995;
Normal response:
CTM 00-07-29 12:30:45
M 1995 COMPLD
"SFO-01:ONS1,129.11.12.101,CISCO-ONS-15454,2.1.3,ONS1,IS,AVAIL"
"SFO-01:ONS2,129.11.12.102,CISCO-ONS-15454,2.1.3,ONS1,IS,UNAVAIL"
"SFO-01:ONS3,129.11.12.103,CISCO-ONS-15454,1.0.0,ONS1,IS,UNAVAIL"
"LVMR-01:ONS4,129.11.12.104,CISCO-ONS-15327,1.0.0,ONS4,IS,AVAIL"
"LVMR-01:ONS5,129.11.12.105,CISCO-ONS-15327,1.0.0,ONS4,IS,AVAIL"
"SJC-01:ONS6,129.11.12.106,CISCO-ONS-15800,2.4.0,ONS6,OOS,UNAVAIL"
"SJC-01:ONS7,129.11.12.107,CISCO-ONS-15800,2.4.0,ONS6,IS,UNAVAIL"
;
Error response:
CTM 2004-07-29 12:30:45
M 1995 DENY
IITA
/*Input, Invalid Target Identifier */
;
|
12.2.2.15 Understanding Domain Manager Mode Reports
When DMM is enabled in the OSS client profile, the OSS uses the following TL1 reports to communicate directly with CTM to obtain information about the TL1-capable NEs that CTM manages:
•REPT ALM EMS
•REPT DBCHG EMS
•CANC Autonomous Message
12.2.2.15.1 REPT ALM EMS
CTM GateWay/TL1 generates the REPT ALM EMS message to report the loss of communication (LOC) with an NE in the CTM management domain.
Table 12-29 REPT ALM EMS—Domain Manager Mode
Item
|
Description
|
Message
|
cr lf lf
^^^SID^DATE^TIME cr lf
ALMCDE^ATAG^REPT^ALM^EMS cr lf
RSPBLK + ;
where:
•SID is the source identifier of the CTM server that generates the message (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
•ALMCDE is the alarm code that identifies the severity of the autonomous message.
•ATAG is the automatic tag that sequences autonomous messages.
•RSPBLK is the response block.
|
Response Block
|
The message must contain at least one occurrence of the response block, which has the following format, sorted according to severity:
^^^"AID:NTFCNCDE,CONDTYPE,SRVEFF,OCRDAT,OCRTM,LOCN,DIRN:/ *CONDDESCR*/" cr lf
where:
•AID is the access identifier that identifies the CTM server entity where the command applies. The format is defined as:
where:
–NEID is the identifier of the NE (equivalent to the SID).
–NEAID is the access identifier of the NE (equivalent to the AID). The NEAID is always null.
|
Response Block
(continued)
|
•NTFCNCDE is the two-character notification code associated with the highest-severity alarm.
•CONDTYPE is the single type of condition being reported. The value is LOC.
•SRVEFF is the service-affecting code that indicates the effect on service caused by the alarm condition.
•OCRDAT is the date when the alarm condition occurred in month of year-day of month (MOY-DOM) format.
•OCRTM is the time of day when the alarm condition occurred in hour of day-minute of hour (HOD-MOH) format.
•LOCN is the location where the monitored parameter originates. LOCN refers to the entity identified by the NEAID.
•DIRN is the direction to which the monitored parameter applies. DIRN is relative to the entity identified by the NEAID.
•CONDDESCR is the detailed text description of the condition.
|
Example
|
CTM 00-07-29 12:30:45
*C 1997 REPT ALM EMS
"ONS1\:CR,LOS,NSA,07-29,12-29,,:/* Loss of Communications */"
;
|
12.2.2.15.2 REPT DBCHG EMS
CTM GateWay/TL1 generates the REPT DBCHG EMS message to report changes to CTM-based information such as added or deleted NEs in the CTM management domain.
Table 12-30 REPT DBCHG EMS—Domain Manager Mode
Item
|
Description
|
Message
|
cr lf lf
^^^SID^DATE^TIME cr lf
ALMCDE^ATAG^REPT^DBCHG cr lf
^^^"TIME=TIME,DATE=DATE,[SOURCE=<SOURCE>],
DBCHGSEQ=DBCHGSEQ:CMDCDE:AID:DATABLK" cr lf
;
where:
•SID is the source identifier of the CTM server that generates the response message (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
•ALMCDE is the alarm code that identifies the severity of the autonomous message.
•ATAG is the automatic tag that sequences autonomous messages.
•SOURCE identifies an input-command correlation tag, if present. SOURCE is optional for the CTM server.
•DBCHGSEQ is a sequential number of the database change message that relates to the database record ID number.
•COMMAND is the input command that indicates whether NEs were added or modified in the CTM database. Values are ENT-NE, ED-NE, and DEL-NE.
•AID is the access identifier that identifies the CTM server entity where the autonomous message applies. The format is defined as:
where:
–NEID is the identifier of the NE (equivalent to the SID).
–NEAID is the access identifier of the NE (equivalent to the AID). The value is the empty set { } (null).
|
Response Block
|
•DATABLK is the data block that provides informational parameters associated with the database change. DATABLK has the following format:
"ADDR=ADDR,NEMOD=NEMOD,VERSION=VERSION,GNE=GNE,OPRNST=OPRNST, COMMST=COMMST"
where:
–ADDR is the IP address of the NE.
–NEMOD is the model of the NE.
–VERSION is the version of software running on the NE.
–GNE is the gateway NE SID associated with the NE.
–OPRNST is the operational state of the NE. Values are IS and OOS.
–COMMST is the communication state of the NE. Values are UNAVAIL and AVAIL.
|
Example
|
Sample NE creation autonomous message:
CTM17 00-07-29 12:30:45
A 1961 REPT DBCHG EMS
"TIME=12-30-45,DATE=00-07-29,DBCHGSEQ=371:
ENT-NE:ONS1\:ADDR=129.11.12.129,NEMOD=CISCO-ONS-15454,
VERSION=3.0.0,GNE=ONS1,OPRNST=IS,COMMST=AVAIL"
;
Sample NE modification autonomous message:
CTM18 00-07-29 12:30:45
A 1962 REPT DBCHG EMS
"TIME=12-30-45,DATE=00-07-29,DBCHGSEQ=371:
ED-NE:ONS1\:ADDR=129.11.12.130,NEMOD=CISCO-ONS-15454,
VERSION=3.0.0,GNE=ONS1,OPRNST=IS,COMMST=AVAIL"
;
Sample NE deletion autonomous message:
CTM18 00-07-29 12:30:45
A 1962 REPT DBCHG EMS
"TIME=12-30-45,DATE=00-07-29,DBCHGSEQ=371:
DEL-NE:ONS1\:ADDR=129.11.12.130,NEMOD=CISCO-ONS-15454,
VERSION=3.0.0,GNE=ONS1,OPRNST=IS,COMMST=AVAIL"
;
|
|
12.2.2.15.3 CANC Autonomous Message
CTM GateWay/TL1 generates the CANC autonomous message when the EMS logs out the OSS client if DMM is disabled.
Note When DMM is disabled, CTM GateWay/TL1 logs out the OSS user from all of the NEs that are available in the CTM domain.
Table 12-31 CANC Autonomous Message
Item
|
Description
|
Message
|
cr lf lf
^^^SID^DATE^TIME cr lf
A^^ATAG^CANC cr lf
UID cr lf
;
where:
•SID is the source identifier of the CTM server that generates the message (equivalent to the TID).
•DATE is the current date in YYYY-MM-DD format.
•TIME is the current time in HH:MM:SS format.
•ATAG is the automatic tag that sequences autonomous messages.
•UID is the OSS client profile name.
|
Example
|
CTM 2004-02-04 00:33:36
A 96 CANC
oss
;
|
|
12.2.2.16 TL1 Command Symbols
The following table outlines the conventions and notations used with TL1 specifications. For information about NE TL1 command usage, refer to the NE documentation.
Table 12-32 TL1 Conventions and Notations
Symbol
|
Description
|
cr
|
A carriage return in ASCII.
|
lf
|
A line feed in ASCII.
|
^
|
A caret indicates that a blank must appear in the message.
Note For readability, some symbols are preceded or followed by blank spaces rather than a caret. The blank spaces are not part of the message.
|
[ ]
|
One or more parameters enclosed within brackets indicates that the parameters are optional. If an empty field (null) is entered for an optional parameter, a default value is automatically substituted in the input field.
|
{ | }
|
A list of two or more parameters enclosed within braces { } and separated by a vertical bar ( | ) indicates that one (and only one) of the parameters from the list must be selected.
|
+
|
A plus sign is a post-fix operator that indicates that the proceeding symbol or group of symbols (enclosed in parentheses) might occur one or more times.
|
;
|
A semicolon marks the end of a message.
|
" "
|
A pair of quotation marks delimits an expression that can be parsed.
|
/* */
|
A pair of these characters (/* and */) delimits free form text.
|
*
|
An asterisk indicates that the preceding symbol might occur zero or more times.
|
,
|
A comma separates parameters within a parameter block.
|
:
|
A colon separates parameter blocks within a command line.
|
\" \"
|
Escape quotes enclose user-defined messages.
|
<
|
The left angle bracket is the ready indicator used in a response to show that the target system is ready to accept new input.
|
>
|
The right angle bracket is the end-of-output character used to indicate that more data associated with the response will follow.
|
&
|
An ampersand (&) is a grouping symbol that allows the user to enter a group of values for a single parameter. Specify the access identifier prefix (that is, T1-<1-8>) each time.
Example: T1-1&T1-5 equals "T1 Number 1 and Number 5."
|
&-
|
An ampersand followed by a hyphen (&-) are grouping symbols that allow the user to enter a group of values for a single parameter. The access identifier prefix (that is, T1-<1-8>) is assumed to be the same type as the previous access identifier prefix type and it must not be repeated each time.
Example: T1-1&5 equals "T1 Number 1 and Number 5."
|
&&
|
Two ampersands together (&&) are ranging symbols that allow the user to specify a range of values for a single parameter. Repeat the access identifier prefix (that is, T1-<1-8>) each time in ascending order.
Example: T1-1&&T1-5 equals "T1 Number 1 through Number 5."
|
&&-
|
Two ampersands followed by a hyphen (&&-) are ranging symbols that allow the user to specify a range of values for a single parameter. The access identifier prefix (that is, T1-<1-8>) is assumed to be the same type as the previous access identifier prefix type and it must not be repeated each time.
Example: T1-1&&-5 equals "T1 Number 1 through Number 5."
|
Note You can use grouping and ranging symbols an unlimited number of times, provided that the overall description of the parameter specified in the TL1 command is fewer than 64 characters in length.
12.2.2.17 TL1 Error Codes
The following table describes the error codes that are used in TL1 command responses.
Table 12-33 TL1 Error Codes
Error Code
|
Definition
|
Description
|
GNRN
|
Gateway not ready for network element
|
CTM GateWay/TL1 is not ready for the NE.
|
GWBY
|
Gateway is busy
|
CTM GateWay/TL1 has too many outstanding requests.
|
ICNV
|
Input, command not valid
|
The command verb or modifier is invalid.
|
IDNV
|
Input, data not valid
|
A simple or compound parameter value appearing in an input command is invalid.
|
IICM
|
Input, invalid command
|
Invalid command.
|
IICT
|
Input, invalid correlation tag
|
Invalid correlation tag.
|
IITA
|
Input, invalid TID
|
Invalid target identifier.
|
INUP
|
Input, non-null unimplemented parameter
|
Invalid parameter length in AID.
|
IPMS
|
Input, parameter missing
|
A required parameter is missing from an input command.
|
IPNC
|
Input, parameter not consistent
|
Two valid parameter names appearing in an input command are mutually exclusive.
Note The ACT-USER, CANC-USER, and RTRV-HDR commands do not support the IPNC error code.
|
IPNV
|
Input, parameter not valid
|
A parameter name used in an input command is not valid.
|
PIUI
|
Privilege, illegal user identity
|
Error code normally returned when an invalid UID or PID has been supplied in an ACT-USER command.
|
PLNA
|
Privilege, logon not active
|
Privileged login is not active.
|
SSRE
|
System resources exceeded
|
An action requested by an input command was canceled because of limited system resources.
|
SSTP
|
System stopped
|
An action requested by an input command was canceled because of limited system resources.
|
12.2.3 Managing CTM GateWay/CORBA
Note This section provides a high-level overview of CTM GateWay/CORBA. For detailed information about CTM GateWay/CORBA, including how to enable username and password encryption, set the heartbeat event, and create OSS clients, refer to the Cisco Transport Manager GateWay/CORBA User Guide and Programmer Manual.
The Common Object Request Broker Architecture (CORBA) is a middleware platform defined by the Object Management Group (OMG). The CTM GateWay/CORBA option is a CORBA-based interface that provides higher-layer management systems with fault, inventory, performance, configuration, Layer 1 circuit provisioning, and Layer 2 VLAN management information for NEs. The CTM GateWay/CORBA option is based on the TeleManagement Forum (TMF) standards for the NMS-to-EMS interface.
Because it is CORBA-based, CTM GateWay/CORBA is independent of the hardware that the integrated OSS is running. This independence allows service providers to easily add CTM as a building block of their management environment.
Note Table 2-3 on page 2-3 shows the NEs that support CTM GateWay/CORBA.
The following figure shows the CTM GateWay/CORBA communications architecture within a service provider's OSS environment.
Figure 12-3 CTM GateWay/CORBA Communications Architecture
CTM GateWay/CORBA is based on the following TMF standards:
•TMF513 v2.0 (October 2001): Multi-Technology Network Management Business Agreement
•TMF608 v2.0 (October 2001): Multi-Technology Network Management Information Agreement
•TMF814 v2.0 (October 2001): Multi-Technology Network Management Solution Set
12.2.3.1 Configuring the CORBA Timeout
The CORBA timeout determines the number of seconds that the CTM server has to process a CORBA call and return it to the CTM client. If the CTM server does not return a response in time, CORBA automatically times out.
Step 1 Open the ems-client.cfg file.
By default, the ems-client.cfg file is located in the C:\Cisco\TransportManagerClient\config directory for Windows platforms and in the /opt/CiscoTransportManagerClient/config directory for Sun Solaris platforms.
Step 2 Set the CORBA_Call_Timeout_Seconds parameter to the desired value. The Cisco default timeout is 120 seconds; the recommended range is 120 to 300 seconds.
Note If the NE is busy or if the CTM server is processing many requests, you might need to increase the CORBA timeout parameter accordingly.
Step 3 Save and close the ems-client.cfg file.
12.2.3.2 Starting or Stopping CTM GateWay/CORBA
Step 1 In the Domain Explorer window, choose Administration > Control Panel.
Step 2 Click GateWay/CORBA Service to open the GateWay/CORBA Service pane.
Step 3 In the Global tab > Status area, click the Start button to start GateWay/CORBA or the Stop button to stop the service.
Note The CTM GateWay/CORBA Service can take up to 60 seconds to initialize after the GUI status has changed to indicate that the service is up. The status is an indication of the successful initiation of the service startup, not successful initialization. To avoid problems with the service hanging, wait at least 60 seconds after starting or stopping the service before restarting it.
12.2.3.3 Viewing the CTM GateWay/CORBA Service Pane
Use the GateWay/CORBA Service pane to start and stop the CTM GateWay/CORBA service and configure CORBA parameters. The following table provides descriptions.
Table 12-34 Field Descriptions for GateWay/CORBA Service Pane
Field
|
Description
|
Status Area
|
Service Status
|
Displays the current status of the service: Active, Not Active, or Not Installed.
|
Service Action
|
Allows you to stop or start a process. Notice that the Service Action button toggles between Stop and Start, and the Service Status field changes accordingly. This field is not available if the Service Status is Not Installed.
|
Gateway CORBA Configuration Area
|
Enable Encryption for Username and Password
|
When checked, usernames and passwords are transmitted between the EMS server and the OSS in encrypted format. The maximum encryption length is 53 bytes. If this check box is unchecked, CTM GateWay/CORBA usernames and passwords are transmitted without encryption. By default, encryption is disabled at installation.
|
Heartbeat for Notification Channel
|
Notifies the OSS if a failure in the notification service has occurred. The heartbeat is measured in minutes; the range is 0 to 999 minutes. A zero value implies that the heartbeat is disabled.
|
Maximum Number of Simultaneous Sessions
|
Specifies the number of CTM GateWay/CORBA sessions that can be active at the same time. The range is 4 to 25; the Cisco default is 4.
|
Maximum Events per Consumer
|
Sets the MaxEventsPerConsumer administrative quality of service (QoS) parameter on the notification channel. The notification server uses this property to bound the maximum number of events in a given channel allowed to queue at any one time. The Cisco default value is 0, meaning that the notification server does not limit the maximum number of events that can be queued. If no limits are imposed on the queue, the notification server might run out of memory, because the server must keep all events in memory until they are consumed by all registered consumers.
Caution Any change to this value should be done with extreme caution. If you set the value too low, the NMS cannot receive all notifications. If you set the value too high, the CTM notification server runs out of memory. The current value can handle alarm bursts of 10,000 events per minute.
|
Notification Service Name
|
Defines the service name used by the resolve_initial_reference function to get a reference to the notification service.
The CTM GateWay/CORBA installation installs the notification service. However, if you want to use your own notification service, you can modify this parameter.
Note You do not need to modify this parameter if you plan to use the notification service that is bundled with CTM GateWay/CORBA.
|
Notification Service Naming Context
|
Defines the naming context of the notification service. This property is used when the resolve_initial_reference function fails to resolve the notification service. CTM GateWay/CORBA contacts the naming service to resolve the name context defined in this property. The value of this property must match the value published by your notification server.
Note You do not need to modify this parameter if you plan to use the notification service that is bundled with CTM GateWay/CORBA.
|
Notification Service Factory IOR Filename
|
Enter the notification service factory Information Object Repository (IOR) filename located in the /opt/CiscoTransportManagerServer/openfusion/domains/OpenFusion/localhost/NotificationService/NotificationSingleton/NotificationService.ior directory.
The FactoryIORFile property defines the path to a text file that contains the IOR of the notification service. This property is used only after the resolve_initial_reference function and the naming service both fail. CTM GateWay/CORBA opens the file as defined by the URL format in this property and retrieves the IOR. This parameter allows you to run your notification service on a different host to improve performance.
Note You do not need to modify this parameter if you plan to use the notification service that is bundled with CTM GateWay/CORBA.
|
Notification Service Listening Port Number
|
Sets the port number that the notification service uses to listen for incoming requests. The port number is set in the IOR for the notification service. The use IOR and use IOR endpoint properties are set properly. If set to 0 (the Cisco default), the port number is allocated by the operating system.
|
Session Port Number
|
Configures the IIOP listening port. The CTM GateWay/CORBA service listens to CORBA requests on this port. If set to 0 (the Cisco default), the session port number is allocated by the operating system.
|
Name Service Server List
|
Defines where the name servers are running. Accepts a comma-separated list of hostnames.
|
Name Service Root IOR
|
Defines the path to find the naming service's IOR on each host defined on the server list. The complete path is constructed as <http://<item>_of_ServerList><RootIORLoc>.
|
Error Level
|
Defines the error level of messages to log. Error levels are:
•Critical
•Major
•Minor
•Informational
•Debug
•Trace
This property can be configured by modifying the corbagw.properties configuration file located in <CTM_server_installation_directory>/cfg. The property is:
corbagw.CTP.getLayeredParameters=false
By default, this property is disabled. If the NMS requires that CTP-related transmission parameters be included as part of any object reporting a TerminationPoint_T structure, this property should be set to true. However, the ManagedElementMgr_I.getTP interface is independent of this property setting and always returns transmission parameters as part of the TerminationPoint_T structure.
|
12.2.3.4 Viewing the CTM GateWay/CORBA Client Configuration Table
The CTM GateWay/CORBA Client Configuration table displays information about OSS CORBA client properties. To launch the table, choose Administration > GW/CORBA Client Configuration Table in the Domain Explorer window. The following table provides descriptions. Use the toolbar icons to create, modify, or delete OSS client users.
Tip You can also launch the GW/CORBA Client Configuration table from the Control Panel. In the Domain Explorer window, choose Administration > Control Panel. In the Control Panel window, choose Administration > GW/CORBA Client Configuration Table.
Table 12-35 Field Descriptions for the CTM GateWay/CORBA Client Configuration Table
Column Name
|
Description
|
OSS Profile Name
|
Displays the name of the selected OSS client.
|
12.2.3.5 Adding a CTM GateWay/CORBA User
OSS client profiles are stored in the GateWay/CORBA Client Configuration table.
Step 1 In the Domain Explorer window, choose Administration > GW/CORBA Client Configuration Table. The GateWay/CORBA Client Configuration table opens.
Step 2 Choose Edit > Add (or click the Create a New User tool). The Add GateWay/CORBA User dialog box opens. The following table provides descriptions.
Step 3 After making your selections, click OK. The new profile is listed in the GateWay/CORBA Client Configuration table. Click Refresh Data to see the changes.
Table 12-36 Field Descriptions for Add/Modify GateWay/CORBA User Dialog Box
Field
|
Description
|
OSS Profile Name
|
Enter a unique name for the new OSS profile. The name must contain from 1 to 53 characters.
|
Password
|
Enter the password that the OSS client uses to log into the CTM server. The password must:
•Contain from 1 to 53 characters
•Contain at least one special character other than an apostrophe (')
•Contain at least two letters (A-Z, a-z)
•Contain at least one number (0-9)
Note Regardless of the actual size of the password, the Password and Confirm Password fields display only a fixed-length string. The fixed-length string is 12 asterisks (*).
|
Confirm Password
|
Re-enter the password to confirm it.
|
12.2.3.6 Modifying a CTM GateWay/CORBA User's Properties
Step 1 In the Domain Explorer window, choose Administration > GW/CORBA Client Configuration Table. The GateWay/CORBA Client Configuration table opens.
Step 2 Select the CORBA user profile to modify; then, choose Edit > Modify (or click the Modify User Properties tool). The Modify GateWay/CORBA User dialog box opens. Table 12-36 describes the fields in the dialog box.
Step 3 Modify the field(s) described in Table 12-36.
Step 4 Click OK. The updated profile is listed in the GateWay/CORBA Client Configuration table. Click Refresh Data to see the changes.
12.2.3.7 Deleting a CTM GateWay/CORBA User
Step 1 In the Domain Explorer window, choose Administration > GW/CORBA Client Configuration Table. The GateWay/CORBA Client Configuration table opens.
Step 2 Select the CORBA user profile to delete; then, choose Edit > Delete (or click the Delete User tool).
Step 3 Click OK in the confirmation dialog box.
Note CTM GateWay/CORBA does not allow an OSS profile to be deleted if there are active users logged in using that OSS profile.
12.2.3.8 Viewing Logged-In CTM GateWay/CORBA Users
Step 1 In the Domain Explorer window, choose Administration > GW/CORBA Client Configuration Table. The GateWay/CORBA Client Configuration table opens.
Step 2 Choose Administration > Logged In GateWay CORBA Users (or click the Show Logged In GateWay CORBA Users tool). The Active GateWay/CORBA Users table opens. The following table provides descriptions.
Table 12-37 Field Descriptions for Active GateWay/CORBA Users Table
Field
|
Description
|
OSS Profile Name
|
Name of the OSS profile. Each client has a unique alphanumeric name.
|
OSS IP Address
|
IP address of the OSS client that is authenticated by CTM GateWay/CORBA during the initial connection request made by the OSS.
|
Login Time (time zone)
|
Time stamp when the CORBA user logged in.
|
12.2.3.9 Ending an Active GateWay/CORBA User Session
Step 1 In the Domain Explorer window, choose Administration > GW/CORBA Client Configuration Table. The GateWay/CORBA Client Configuration table opens.
Step 2 Choose Administration > Logged In GateWay CORBA Users (or click the Show Logged In GateWay CORBA Users tool). The Active GateWay/CORBA Users table opens.
Step 3 In the Active GateWay/CORBA Users table, select the user whose session will be ended and choose Administration > Log Out GateWay CORBA User (or click the Log Out GateWay CORBA User tool).
12.2.4 Trap Management
This section describes how to manage Cisco MGX Voice Gateway traps through CTM 7.0. The following topics are described in this section:
•Fault Management Interface
•Process for Fault Management
•Access Methods
•Trap Processing
•Trap Recovery
•Special Case of Manager Registration
•Set Special Registration
•Trigger RTM Protocol
12.2.4.1 Fault Management Interface
In CTM 7.0, fault management for the MGX NE(s) by external OSS applications is based on robust SNMP traps. This trap mechanism, known as Robust Trap Mechanism (RTM), is supported by the SNMP Service Agent running in conjunction with a CTM 7.0 management system. Through the Service Agent, up to 16 external SNMP Managers (with 1 of the 16 reserved for CTM 7.0) can register to receive network-related and service-related traps.
12.2.4.1.1 Traps
The primary interface for fault management is through SNMP traps emitted by the SNMP Service Agent.
The complete fault management interface presented to users of the Service Agent includes:
•Traps from Cisco MGX 8830, Cisco MGX 8880, Cisco MGX 8850 PXM1E-based, and Cisco MGX 8850 PXM45-based platforms.
•Traps from CTM 7.0.
The traps that are delivered by the Service Agent are standard SNMP-Version 1 traps. These traps are delivered on behalf of the network devices and CTM 7.0.
The Service Agent delivers traps in RTM mode. In this mode lost traps can be detected and recovered by the SNMP managers.
To receive these RTM traps from the Service Agent, an SNMP manager must register itself with the Service Agent.
The Service Agent delivers the following categories of traps:
•Traps that are generated in CTM 7.0 that reflect the CTM 7.0 health.
•Traps that are generated at Cisco MGX 8830, Cisco MGX 8880, Cisco MGX 8850 PXM1E-based, and Cisco MGX 8850 PXM45-based platforms. These traps are forwarded to the manager untouched.
Note MGX-specific traps are located on the CTM server in the /opt/CiscoTransportManagerServer/cwm/svplus/mibs directory.
Trap definitions for this category are not available in SV+Network.mib. They are available in the corresponding Cisco MGX MIBs.
Note SV+Network.mib is located in the /opt/CiscoTransportManagerServer/cwm/svplus/mibs directory. The Cisco MGX MIBs are shipped as part of the CTM 7.0 installation and located in the /opt/CiscoTransportManagerServer/cwm/svplus/mibs/mibdir directory.
•User connection traps that are generated in CTM 7.0.
12.2.4.1.2 CTM R7.0-Generated Traps
The severity of each trap is presented in a trapSeverity variable in each trap unless otherwise noted.
For trap 29201, 29202, or 29203 with severity clear (1), clears alarms for a given mgmAffectedObject. Alarms are represented by previous trap with same number and same value of mgmAffectedObject.
For traps with severity clear (1), VarBind mgmTrapDescription contains an empty string.
The following table describes health monitor traps.
Table 12-38 Health Monitor Traps
Trap Name
|
Trap Number
|
Severity
|
Comments
|
mgmServerMonitorThresholdCrossed
|
29201
|
Clear (1), critical (5), major (4), minor (3)
|
VarBind mgmAffectedObject gives the parameter that crossed the threshold.
VarBind mgmTrapDescription gives more detail about server parameters.
|
mgmMemoryAutoBackupFailure
|
29202
|
Clear (1), minor (3)
|
VarBind mgmAffectedObject gives the NE database ID for the NE on which memory backup failed.
VarBind mgmTrapDescription gives the name of the NE and the reason why the memory backup failed.
|
mgmMaxLoginAttemptExceeds
|
29203
|
Clear (1), major (3)
|
VarBind mgmAffectedObject gives the database user ID of the user who failed to log in.
VarBind mgmTrapDescription gives the username and IP address of the machine from which the login failed.
|
mgmCriticalProcessHanging
|
29204
|
Critical (5)
|
This trap is sent when the MGM Server will be shut down in 5 minute because a critical server process is hanging. There is no corresponding clear for this trap.
VarBind mgmTrapDescription gives the name of the process that was hanging or not running.
|
mgmCommThroughSecondaryIP
|
29205
|
Clear (1), major (4)
|
This trap is sent when Server when the server is communicating through a secondary IP address.
|
svStatisticsParsingError
|
28008
|
Major (4)
|
—
|
cwmfrNetworkCommFailure
|
28101
|
•Critical (5) on error 3, 4, 5
•Info (6) on error 1, 2, 6
|
The severity depends on the value of cwmfrNetworkCommFailureCode in the trap. Values are:
1: ftp-session-fail
2: ftp-transfer-fail
3: net-link0-down
4: net-link1-down
5: ntsmgr-net-fail
6: nts-trap-loss
|
cwmfrNetworkProcessingError
|
28102
|
•Critical (5) on error 7, 10, 11, 13, 16
•Warning (2) on error 1, 8, 9, 12, 14
•Info (6) on error 2, 3, 4, 5, 6, 15
|
The severity depends on the value of cwmfrNetworkProcessingErrorCode in the trap. Values are:
1: no-nw-partition
2: no-node-revision
3: no-node-subscription
4: incorrect-msg
5: ftp-file-size-mismatch
6: tftp-transfer-fail
7: upload-file-error
8: minus2-trap
9: card-lost-trap
10: snmp-retry-exceeded
11: ftp-retry-exceeded
12: syncup-failed
13: stats-file-error
14: stats-file-transfer-error
15: snmp-throttle-error
16: backoff-failed
|
cwmfrNetworkCommTimeout
|
28103
|
Warning (2)
|
—
|
cwmfrCwmInternalError
|
28203
|
•Critical (5) on error 3, 4, 5, 6, 7
•Warning (2) on error 1, 2
•Info (6) on error 8
|
The severity depends on the value of cwmfrCwmInternalErrorCode in the trap.
unknown-error (1), initialization-error (2), spawn-child-error (3), configuration-error(4),communication-error-ilog (5), communication-error-shared-mem (6), communication-error-corba (7), tftpmgr-queue-full (8).
|
The following table describes node traps.
Table 12-39 Node Traps
Trap Name
|
Trap Number
|
Severity
|
Comments
|
svNodeIpUnreachable
|
25302
|
Critical (5)
|
—
|
svNodeIpReachable
|
25303
|
Clear (1)
|
This trap clears svNodeIpUnreachable (25302).
|
nodeAdded
|
20050
|
Info (6)
|
—
|
nodeDeleted
|
20051
|
Info (6)
|
—
|
nodeNameChange
|
20052
|
Info (6)
|
—
|
nodeIpAddressChange
|
20053
|
Info (6)
|
—
|
nodeStatusChange
|
20054
|
This trap reports 2 severity conditions:
•svNodeGrpAlarmState clear (1), minor (2), major (3), critical (4), unreachable (5)
•svNodeFilteredAlarmState notSupported (0), clear (1), minor (2), major (3), critical (4), unreachable (5)
|
The following table describes connection traps.
Table 12-40 Connection Traps
Trap Name
|
Trap Number
|
Severity
|
cwmUserConnComplete
|
25113
|
Info (6)
|
cwmUserConnIncomplete
|
25114
|
Info (6)
|
cwmUserConnModified
|
25115
|
Info (6)
|
cwmUserConnectionCleared
|
25116
|
Info (6)
|
cwmUserConnectionFailed
|
25117
|
Minor (3)
|
cwmUserConnectionDown
|
25118
|
Minor (3)
|
Note Appendix F, "Traps Config Group," describes the SNMP tables and scalar objects used by the SNMP managers.
12.2.4.2 Process for Fault Management
This section contains the process for implementing fault management capabilities based on the Service Agent trap stream. The overall process for fault management includes:
1. Manager Registration with the Service Agent via trapConfigTable (see Table F-2 on page F-1) to receive traps—This registration process results in the Service Agent storing some context information about the manager, such as its IP address and its trap retrieval status.
2. Trap Processing—For each trap, check the sequence number when you are concerned about missing traps.
3. Trap Recovery—The manager can synchronously retrieve missing traps one at a time. The manager has control over where to start trap retrieval by setting the trap sequence number to be retrieved. Successive missing traps are obtained via repetitive trap retrieval requests.
12.2.4.2.1 Manager Registration
To receive the RTM traps from the Service Agent, an SNMP manager must register itself with the Service Agent.
As part of the registration process, the manager can specify a specific port as a destination for all traps. When a port is not specified, the Service Agent sends all traps to port 162 on the manager.
The Service Agent can support up to 16 external SNMP Managers (with one reserved for CTM 7.0). The managerNumOfValidEntries MIB variable stores the number of subscribed managers in the RTM table.
To receive the RTM traps from the Service Agent, an SNMP manager must register itself with the Service Agent.
To register an SNMP manager with the Service Agent, enter a SET request on the trapConfigTable (see Table F-2 on page F-1) following mandatory objects:
•managerRowStatus.<managerIPaddress> = addRow
•readingTrapFlag.<managerIPaddress> = false
•trapRedeliverFlag.<managerIPaddress> = false
A maximum of 16 managers can be registered with the Service Agent.
Because only 16 slots are available for manager registration, aging (keepalive) is implemented in the Service Agent so that the registration of inactive managers is automatically cancelled.
Each registered manager is required to poll the Service Agent by doing a GET on the manager entry to keep the entry alive. If a manager fails or becomes inactive, the manager is automatically unregistered and no further traps are sent.
12.2.4.2.2 Example of Registering with RTM Service Agent
To register with the RTM Service Agent, send a SET request on the following two variables:
•OID: 1.3.6.1.4.1.351.120.1.1.1.2.<IPADDR>
where <IPADDR> is the IP address of the manager in dotted decimal notation.
–Name: managerPortNumber
–Type: Integer
–Community: public (ignored)
–Value: <ManagerPortNumber>
•OID: 1.3.6.1.4.1.351.120.1.1.1.3.<IPADDR>
where <IPADDR> is the IP address of the manager in dotted decimal notation.
–Name: managerRowStatus
–Type: Integer
–Community: public (ignored)
–Value: 1
To register with the RTM Service Agent, use the syntax in the following example. This example uses manager IP address 192.99.88.101 and port number 162.
Example 12-1 Registering with the RTM
>snmpSET -p 8161 -c private nmclearc managerPortNumber.192.99.88.101 integer 162
managerRowStatus.192.99.88.101 integer 1
stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerPortNumber.192.99.88.101
stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerRowStatus.192.99.88.101 :
Note To keep the registration active, the SNMP manager must send a keepalive with the Service Agent at least once every 60 minutes.
12.2.4.2.3 Example of Unregistering with the RTM Service Agent
To unregister with the RtmProxy, send a SET request on the following variable:
•OID: 1.3.6.1.4.1.351.120.1.1.1.3.<IPADDR>
where <IPADDR> is the IP address of the manager in dotted decimal notation.
–Name: managerRowStatus
–Type: Integer
–Community: public (ignored)
–Value: 2
To unregister with the RTM, use the syntax in the following example. This example uses manager IP address 192.99.88.101.
Example 12-2 Unregistering with the RTM
> snmpSET -p 8161 -c private nmclearc managerRowStatus.192.99.88.101 integer 2
stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerRowStatus.192.99.88.101 :
12.2.4.2.4 Extending the Expiration Time
To extend the expiration time, enter a GET request with the following object:
managerRowStatus.<managerIPaddress>
A successful GET response indicates that the registration has been extended. Otherwise, the registration has already expired.
The default expiration time is 60 minutes. It is recommended that the keepalive be done at least once every 55 minutes.
The default expiration time can be changed in the /opt/CiscoTransportManagerServer/cwm/svplus/config/process.conf file. Use the command line option -k for starting the RtmProxy process.
Note You must change the default expiration time prior to starting the CTM 7.0 core.
For example, to change the expiration time to 7200 seconds (or 2 hours), execute the following command:
RtmProxy on off . RtmProxy -v -k 7200
Note To keep the registration active, the SNMP manager must send a keepalive with the Service Agent at least once every 60 minutes.
12.2.4.2.5 Manager Entry Configuration
Because the Service Agent delivers all of the traps from the entire network, the SNMP manager can filter out unwanted traps.
The SNMP manager can configure the Service Agent to deliver the traps that are of interest to the manager by defining trap groups and numbers in the /opt/CiscoTransportManagerServer/cwm/svplus/config/trap_filter.conf file. This file is used by the Service Agent to filter out the traps.
The trap_filter.conf file contains predefined trap groups and traps. You can modify this file.
Note Modifying the trap_filter.conf file allows you to remove the traps you are not interested in.
To control the trap groups, enter a SET with the following object in the trapConfigTable (see Table F-2 on page F-1):
trapFilterRegisterCategory.<managerIPaddress> = <Bit Mask, 1 bit per Trap Group>
You can SET this object as part of the registration or at a later time. If you leave the parameter at the default value, all trap groups are delivered.
12.2.4.2.6 Trap Group Limitations
You can define up to 32 trap groups in the trap_filter.conf file. Only one file can be defined per CTM 7.0 workstation. This file is used for all of the SNMP managers. An SNMP manager can control which trap groups to receive.
12.2.4.2.7 Register Agents when Using HPOV
You can use HP OpenView (HPOV) to view traps. HPOV should be installed on a machine other than CTM 7.0, and you must register with the RtmProxy that is running on the CTM 7.0 machine.
To register with the RtmProxy, complete the following steps:
Step 1 Make sure all CTM 7.0 MIBs are integrated with HPOV on the machine on which HPOV is installed.
If the MIBs are not integrated, you will see OIDs in Event Browser.
Step 2 Make sure the RtmProxy is running on the CTM 7.0 workstation.
Step 3 Issue the following SNMP commands on the CTM 7.0 workstation:
/opt/OV/bin/snmpset -p 8161 -c private <CTM 7.0_machine>
managerPortNumber.<ipaddress_of_HPOV m/c> integer 162
managerRowStatus.<ipaddress_of_HPOV_m/c> integer 1
The following example shows the command syntax with the CTM 7.0 machine as nectra2, and the machine for viewing traps has an IP address of 10.77.240.67:
/opt/OV/bin/snmpset -p 8161 -c "private" nectra2
managerPortNumber.10.77.240.67 integer 162
managerRowStatus.10.77.240.67 integer 1
Step 4 Open the Event browser on the machine with HPOV installed, and see if the browser is receiving traps.
Step 5 If you do not want to view the traps in HPOV (if you want to unregister), issue the following command on CTM 7.0 workstation:
/opt/OV/bin/snmpset -p 8161 -c private <CTM 7.0_machine>
managerRowStatus.<ipaddress_of_HPOV_m/c> integer 2
The following example shows unregistering with the RtmProxy using the same variables as the previous example:
/opt/OV/bin/snmpset -p 8161 -c "private" CTM 7.0nectra2
managerRowStatus.10.77.240.67
12.2.4.3 Access Methods
The default SET and GET community strings are private and public. To obtain the number of managers registered for traps, issue an SNMP GET on the following variable of the trapConfigTable (see Table F-2 on page F-1):
•OID: 1.3.6.1.4.1.351.120.1.2.0
•Name: managerNumOfValidEntries
•Type: Integer
•Community: public (ignored)
Use the syntax shown in the following example:
Example 12-3 Number of Managers Registered for Traps
snmpGET -p 8161 -c public nm20fst7 managerNumOfValidEntries.0
stratacom.rtm.trapsConfig.managerNumOfValidEntries.0 : INTEGER: 2
To obtain the sequence number of the last trap generated on the CTM 7.0 SNMP Service Agent, issue an SNMP GET on the following variable:
•OID: 1.3.6.1.4.1.351.120.1.3.0
•Name: lastSequenceNumber
•Type: Integer
•Community: public (ignored)
Use the syntax in the following example:
Example 12-4 Sequence Number of the Last Trap Generated
>snmpGET -p 8161 -c public nm20fst7 lastSequenceNumber.0
stratacom.rtm.trapsConfig.lastSequenceNumber.0 : INTEGER: 833
12.2.4.4 Trap Processing
The Robust Trap Mechanism (RTM) discovers and recovers the lost traps. This mechanism requires the SNMP managers to provide registration and some follow-up interface to the Service Agent.
The following steps summarize the RTM process:
•The Service Agent includes a sequence number in each of the traps.
•The Service Agent saves the last 10,000 traps in case they need to be delivered again.
•The SNMP manager checks for the continuity of the sequence number on the received trap.
•On detecting an out-of-sequence number, the SNMP manager informs the Service Agent about the missing traps.
•The Service Agent resends the missing traps to the manager.
12.2.4.4.1 Trap Forwarding
All the traps that are delivered by the Service Agent to the manager contain a common MIB object called lastSequenceNumber. This lastSequenceNumber is incremented by 1 for each trap that is delivered.
Because of trap filtering, the traps are not broadcast to all of the managers. Instead, they are sent on an individual basis depending on the categories of traps that a client registers with the RtmProxy by using the trapFilterRegisterCategory object.
The lastSequenceNumber is maintained by each registered manager. This number can be different for different managers.
The manager uses the following process for discovering lost traps:
1. The manager saves the lastSequenceNumber value from the first trap.
2. For each subsequent trap, the manager compares the lastSequenceNumber value with the sequence number that was stored from the previous trap.
3. If the values are in sequence, the manager saves the new lastSequenceNumber and repeats the process. If the values are out of sequence, the manager uses the recovery process.
Note The lost traps could be any number.
12.2.4.5 Trap Recovery
Whenever the SNMP manager discovers an out-of-sequence lastSequenceNumber in the trap, the manager must follow the predefined protocol of RTM mode for recovering lost traps.
12.2.4.5.1 Trap Recovery Process
The manager uses the following process for recovering lost traps:
1. The manager discards any traps coming from the Service Agent and enters RTM mode.
2. The manager sends a SET request with the following objects to the Service Agent:
–readingTrapFlag.<managerIPaddress> = true
–trapRedeliverFlag.<managerIPaddress> = false
–nextTrapSeqNum.<managerIPaddress> = ExpectedSequenceNumber
3. The Service Agent sends the SET response and stops sending any more traps to the manager.
4. The manager receives the SET response and sends a GET request with the following objects to recover the first missing trap:
–trapSequenceNum.<managerIPaddress>
–trapPduString.<managerIPaddress>
–endofQueueFlag.<managerIPaddress>
5. The Service Agent sends the GET response to the manager with the following objects:
–trapSequenceNum.<managerIPaddress> = ExpectedSequenceNumber + X
The value of X is 0 if the trap requested is still available in the circular buffer. Otherwise, the ExpectedSequenceNumber + X represents the oldest trap available in the buffer.
–trapPduString.<managerIPaddress> = TrapPDU
–endofQueueFlag.<managerIPaddress> = <false or true>
This object is false if more traps are to be recovered by the manager. This object is true if this trap is the only one missing.
6. The manager receives the GET response, and verifies the values of the following objects:
–trapSequenceNum
If this value is not equal to the ExpectedSequenceNumber, some traps are overwritten.
–endofQueueFlag
If this value is true, no more traps are to be recovered.
7. The manager sends a SET request with the following object:
–trapRedeliverFlag.<managerIPaddress>=true
8. The Service Agent sends the SET response.
If the value of endofQueueFlag is already set to true, the manager setting readingTrapFlag and trapRedeliverFlag to false and goes into real-time mode. No traps are sent from the circular queue.
If the value of endofQueueFlag is false, the Service Agent starts sending the saved traps from ExpectedSequenceNumber+1.
9. The manager receives the SET response and starts receiving the traps.
The manager is in real-time mode and should start checking lastSequenceNumber again.
10. After the Service Agent sends all of the lost traps to the manager (when the Service Agent catches up with the lastSequenceNumber), the Service Agent switches to real-time mode and sets readingTrapFlag and trapRedeliverFlag to false.
12.2.4.6 Special Case of Manager Registration
When an SNMP manager registers with the Service Agent, the manager can request the traps that were generated prior to the registration.
The manager retrieves the prior-registration traps by using the following process:
•The manager invokes special registration with the Service Agent.
•The manager recovers the traps in special RTM mode.
12.2.4.7 Set Special Registration
For special registration the manager performs a SET on the following objects:
•managerRowStatus.<managerIPaddress> = addRow
•readingTrapFlag.<managerIPaddress> = true
•nextTrapSeqNum.<managerIPaddress> = -<X> (X = number of previous traps to retrieve)
•trapRedeliverFlag.<managerIPaddress> = false
•trapFilterRegisterCategory.<managerIPaddress> = <trap filter> (Optional)
After the registration succeeds, lastSequenceNumber is set to X, instead of the usual value of 0. Because this registration involves some special processing in the Service Agent, the processing time is a few seconds. During that time, the Service Agent sends the SET response back to the manager.
12.2.4.8 Trigger RTM Protocol
After the SET response is received, the manager can trigger the special RTM protocol:
1. The manager is in regular mode and sends a SET request with the following objects:
–nextTrapSeqNum.<managerIPaddress> = 0
–trapRedeliverFlag.<managerIPaddress> = true
The manager intends to recover traps from sequence=0 to X and is ready to receive the traps.
2. The Service Agent sends the SET response and starts sending the saved traps from lastSequenceNumber = 0.
3. The manager receives the SET response and starts receiving the traps at the same time.
The manager starts checking the lastSequenceNumber.
4. After the Service Agent sends all of the saved traps to the manager (when the Service Agent catches up with lastSequenceNumber), the Service Agent switches to real-time mode and sets readingTrapFlag and trapRedeliverFlag to false.
