Cisco Transport Manager User's Guide, 9.0
Chapter 12: Managing Southbound and Northbound Interfaces
Downloads: This chapterpdf (PDF - 879.0KB) The complete bookPDF (PDF - 39.65MB) | Feedback

Managing Southbound and Northbound Interfaces

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 on MGX Voice Gateway Devices


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, SNMP, TL1, HTTP, 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 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 choose 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 162 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 162 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.3  Viewing and Changing the Network Address—CTC-Based NEs, page 4-48.

CORBA listener port on CTM server (callback)

Dynamic (current functionality).

Note To make the port static, see 4.5.3.6  CTC IIOP Port Configuration, page 4-77.

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 and 40xx on the NE, where xx is the ML-series card slot number.

CTM GateWay/SNMP

Note CTM GateWay/SNMP uses port 162 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 162 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  MGX Voice Gateway.

Table 12-6 Port Information for the MGX Voice Gateway 

Port
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

1 Port 2500 is an inbound port because SNMP traps are generated at the MGX nodes and then forwarded to the CTM server.


12.1.2  Using a Static CORBA Listener Port on the CTM Server

See 4.5.3.6  CTC IIOP Port Configuration, page 4-77.

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. The CTM client uses JDBC to communicate directly with the CTM database, independently from the CTM server.


Note All ports from 1024 through 65536 must be open to ensure communication between the CTM server and client. The use of firewalls between the CTM server and client is not supported. Your CTM client will not work correctly if you place a firewall between the CTM server and client (blocking ports from 1024 through 65536).


Inbound ports are for operations initiated by the CTM client and then directed to the CTM server.

Outbound ports are for operations initiated by the CTM server and then directed to the CTM client.

The following table lists the ports used for communication between the CTM server host and the CTM client host.

Table 12-7 CTM Server-to-CTM Client Ports 

Port
Inbound or Outbound
Protocol
Application Protocol
Service
Notes

1745

Inbound

TCP

ONS 155xx

CiscoView (if CiscoView is cross-launched by CTM to manage ONS 155xx NEs)

8051

Inbound

TCP

HTTP

Web server

Apache HTTP port

27613 (configurable)

Inbound

TCP

Proprietary

CTM server

JMOCO port

20000 (configurable)

Inbound

TCP

CORBA

CORBA ImR

CORBA Implementation Repository port

30000

Inbound

TCP

CORBA

SM service

Service Manager port

CORBA IIOP listener port

Inbound

TCP

CORBA

CTC-based network services

Dynamic: Ports are selected randomly

22

Inbound

TCP

SSH

CTM server host

Standard SSH port for secure login

3075, 3079, 3094

Inbound

TCP

CORBA

MGM Orbix CORBA services

Cisco MGX Voice Gateway: Orbix ports

Configurable

Inbound/outbound

TCP

CORBA

MGM Orbix CORBA servers

Cisco MGX Voice Gateway: Range of ports is specified in the associated Orbix domain config file

1521

Inbound

TCP

JDBC

Oracle listener

Database listener port

9000-9011 (configurable)

Inbound/outbound

TCP

MGX server processes

Base service

Cisco MGX Voice Gateway: Internal process-to-process communication ports, configurable in process.conf (-b 9000)

Random

Inbound

TCP

SSH

SSH relay ports

Cisco MGX Voice Gateway: SSH proxy port on CTM server

Random

Inbound

TCP

Telnet

Telnet relay ports

Cisco MGX Voice Gateway: Telnet proxy port on CTM server

10023-10086

Inbound

TCP

Telnet

Telnet relay ports

Telnet port

3000-3200

Outbound

UDP

SNMP

ONS 1530x

ONS 1530x SNMP trap forwarding to CEC


The following table lists the ports used for communication between the CTM server workstation and the OSS CORBA client workstation.

Table 12-8 CTM Server-to-OSS CORBA Client Ports 

Port
Inbound or Outbound
Protocol
Application Protocol
Service
Notes

Dynamic

Inbound/outbound

TCP

CORBA

CTM GateWay/CORBA

CORBA notification: Ports are assigned randomly by the operating system; however, the notification service can be configured to specify a pool of ports

14005

Inbound

TCP

CORBA

CTM GateWay/CORBA

CORBA naming service


The following table lists the ports used for communication between the CTM server workstation and the client service agent.

Table 12-9 CTM Server-to-Client Service Agent Ports 

Port
Inbound or Outbound
Protocol
Application Protocol
Service
Notes

8161

Inbound/outbound

UDP

MGX server processes

SNMP service agent

RTM proxy port used for sending traps to HPOV, CIC, and so on


The following table lists the ports used for communication between the CTM server workstation and the CTM GateWay/TL1 client workstation.

Table 12-10 CTM Server-to-CTM GateWay/TL1 Client Ports 

Port
Inbound or Outbound
Protocol
Application Protocol
Service
Notes

26715 (configurable)

Inbound

TCP

TL1

CTM GateWay/TL1

CTM GateWay/TL1 OSS listener port


The following table lists the ports used for communication between the CTM server workstation and the NEs.

Table 12-11 CTM Server-to-NE Ports 

Port
Inbound or Outbound
Protocol
Application Protocol
Service
Notes

161

Outbound

UDP

SNMP

Base service

162

Inbound

UDP

SNMP

Base service

4500-4510

Inbound

TCP

Proprietary

ONS 15302

80

Outbound

TCP

HTTP

ONS 15302

23

Outbound

TCP

Telnet

ONS 15302

4500-4510

Inbound

TCP

Proprietary

ONS 15305 R3.0 (CTC-based)

12345

Outbound

TCP

Proprietary

ONS 15305 R3.0 (CTC-based)

17476

Inbound

TCP

Proprietary

ONS 15305 R3.0 (CTC-based)

80

Outbound

TCP

HTTP

ONS 15305 R3.0 (CTC-based)

23

Outbound

TCP

Telnet

ONS 15305

4500-4510

Inbound

TCP

Proprietary

ONS 15305

23

Outbound

TCP

Telnet

ONS 15305

161

Outbound

UDP

SNMP

ONS 15302

161

Outbound

UDP

SNMP

ONS 15305 R3.0 (CTC-based)

161

Outbound

UDP

SNMP

ONS 15305

1000

Outbound

TCP

TL1

ONS 158xx

23

Outbound

TCP

Telnet

ONS 158xx

69

Inbound

TCP

TFTP

ONS 158xx

3083

Outbound

TCP

TL1

ONS 15216

23

Outbound

TCP

Telnet

ONS 15216

8023

Outbound

TCP

Telnet

ONS 15216

69

Inbound

TCP

TFTP

ONS 15216

161

Outbound

UDP

SNMP

ONS 15216

161

Outbound

UDP

SNMP

CTC-based

ML cards

7200

Inbound

UDP

SNMP

CTC-based

ML cards

7209

Outbound

UDP

SNMP

CTC-based

ML cards

7210

Inbound

UDP

SNMP

CTC-based

ML cards

CORBA listener port on the TCC+/TCC2 card (NE)

Outbound

TCP

CORBA

CTC-based

The port is configurable with:

TCC+/TCC2 fixed (57790, outbound)

Standard Internet Inter-ORB Protocol (IIOP) port (683, outbound)

User-defined constant

CORBA listener port on the CTM server (callback)

Inbound

TCP

CORBA

CTC-based

Dynamic

80

Outbound

TCP

HTTP

CTC-based

3082

Outbound

TCP

TL1

CTC-based

TL1 port on TCC+/TCC2 (NE)

2361

Outbound

TCP

TL1

CTC-based

TL1 port on TCC+/TCC2 (NE)

4083

Outbound

TCP

TL1

CTC-based

TL1 port on TCC+/TCC2 (NE), secure

9999

Outbound

TCP

CORBA call from CTM. HTTP transfer to the NE.

CTC-based

Software download, backup, and restore port on TCC+/TCC2 (NE)

9500-9550

Outbound

TCP

No specific diagnostics from CTM. CTM debug framework used to provide logging information.

CTC-based

Software activate/revert diagnostics port on the CTM server.

Dynamically allocated in the range of ports 9500 to 9550 (outbound) to allow multiple concurrent activate/revert operations.

20xx

Outbound

TCP

Telnet

CTC-based

ML cards: L2 Service resync port. From any port on CTM to port 20xx on the NE, where xx is the ML card slot number.

3082, 3083

Outbound

TCP

TL1

ONS 155xx

161

Outbound

UDP

SNMP

ONS 155xx

80, 81

Outbound

TCP

HTTP

ONS 155xx

23

Outbound

TCP

Telnet

ONS 155xx

69

Inbound

TCP

TFTP

ONS 155xx

161

Outbound

UDP

SNMP

MGX Voice Gateway

2500

Inbound

UDP

SNMP

MGX Voice Gateway

SNMP traps. CTM/MGX uses port 2500 for traps. It can be configured in svplus/nts.conf as TRAP_PORT <port_number> (for example, TRAP_PORT 2500). Must be set less than 32768 and different from 162.

22

Outbound

TCP

SSH

MGX Voice Gateway

23

Outbound

TCP

Telnet

MGX Voice Gateway

24

Outbound

TCP

FTP

MGX Voice Gateway

For PM data collection and configuration file upload.

CTM/MGX FTP is based on Berkeley FTP. There are no configuration parameters in the configuration files for changing the port numbers.


The following table lists the ports used for communication between the CTM client workstation and the NEs.

Table 12-12 CTM Client-to-NE Ports 

Port
Inbound or Outbound
Protocol
Application Protocol
Cross-Launched Application
Notes

161

Outbound

UDP

SNMP

CEC

4500-4510

Inbound

TCP

Proprietary

CEC

161

Outbound

UDP

SNMP

CTC

4500-4510

Inbound

TCP

Proprietary

CTC

12345

Outbound

TCP

Proprietary

CTC

17476

Inbound

TCP

Proprietary

CTC

69

Inbound

UDP

TFTP

CTC

23

Outbound

TCP

Telnet

CTC

80

Outbound

TCP

HTTP

CTC

CORBA listener port on the TCC+/TCC2 card (NE)

Outbound

TCP

CORBA

CTC

The port is configurable with:

TCC+/TCC2 fixed (57790, outbound)

Standard Internet Inter-ORB Protocol (IIOP) port (683, outbound)

User-defined constant

CORBA listener port on the CTM server (callback)

Inbound

TCP

CORBA

CTC

Dynamic: The port range can be configured

80

Outbound

TCP

HTTP

CTC


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-7 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 In the CTM Server Port field, change the server port. 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. This section contains the following information:

Managing CTM GateWay/SNMP

Managing CTM GateWay/TL1

Managing CTM GateWay/CORBA

Trap Management on MGX Voice Gateway Devices

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, SNMPv2c, and SNMPv3 traps. SNMPv2c traps contain the CTM host IP address in the source address of the IP packet.

SNMPv3 traps contain the OSS username, authentication protocol, authentication password, privacy protocol, and privacy password.

To enable 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 applies 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-13 provides descriptions.

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/SNMPv1 or CTM GateWay/SNMPv2 Host

You can configure up to 16 SNMP trap destination hosts for CTM GateWay/SNMP. CTM enforces a duplication check error to ensure that you do not enter duplicate OSS IP addresses.


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

Step 2 In the Control Panel window, click GateWay/SNMP Service. The following table provides descriptions.

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-13 Field Descriptions for the 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.

Engine ID

Displays the unique identifier for the given CTM GateWay/SNMP application that CTM is communicating with. The engine ID is used to configure the OSS application to receive traps from CTM GateWay/SNMP. The engine ID is generated the first time you install the CTM server.

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 Northbound OSS SNMPv3 Users

You can use the OSS SNMPv3 Users table to add, modify, or delete OSS SNMPv3 users.

This section contains the following procedures:

Viewing the OSS SNMPv3 Users Table

Adding an OSS SNMPv3 User

Modifying an OSS SNMPv3 User

Deleting an OSS SNMPv3 User

12.2.1.3.1  Viewing the OSS SNMPv3 Users Table

To view the OSS SNMPv3 Users table, choose Administration > GateWay/SNMP Users in the Domain Explorer window. The following table provides descriptions.

Table 12-14 Field Descriptions for the OSS SNMPv3 Users Table 

Column Name
Description

Username

Name of the user who authenticates the SNMPv3 trap. The name must contain from 6 to 53 alphanumeric characters. The name cannot contain spaces or special characters.

Authentication Protocol

Type of encryption used to authenticate the SNMPv3 user.

IP Address

IP address to which to forward the SNMPv3 trap.

Privacy Protocol

Privacy protocol set for the SNMPv3 user.

SNMP Port

OSS destination port number. The default port number is 162.

SNMP Version

SNMP version number.

Engine ID

Unique identifier for the given CTM GateWay/SNMP application that CTM is communicating with. The engine ID is used to configure the OSS application to receive traps from CTM GateWay/SNMP. The engine ID is generated the first time you install the CTM server.


12.2.1.3.2  Adding an OSS SNMPv3 User

SNMPv3 user profiles are stored in the OSS SNMPv3 Users table.


Step 1 In the Domain Explorer window, choose Administration > GateWay/SNMP Users. The OSS SNMPv3 Users table opens.

Step 2 Choose Edit > Add (or click the Create a New User tool). The Add OSS SNMPv3 User dialog box opens. The following table provides descriptions.

Step 3 After providing the required information, click OK.


Table 12-15 Field Descriptions for the Add/Modify OSS SNMPv3 User Dialog Box 

Field
Description

OSS IP Address

Enter the IP address to which to forward the SNMPv3 trap.

Username

Enter a unique name for the new user. The name must contain from 6 to 53 alphanumeric characters. The name cannot contain spaces or special characters.

SNMP Port

Enter the OSS destination port number.

Authentication Protocol

Authentication protocol for the OSS SNMPv3 user. Choose the authentication protocol to use for authenticating the user. Values are No Auth, MD5 (the default), or SHA.

Authentication Password

Enter the password used to authenticate the SNMPv3 user. The password must contain:

From 1 to 12 characters

At least one special character other than an apostrophe (')

At least two letters (A-Z, a-z), including at least one uppercase letter

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 contains 15 asterisks (*).

Confirm Authentication Password

Re-enter the password to confirm it.

Privacy Protocol

Select the privacy protocol set for the SNMPv3 user. You can choose one of the following:

NoPriv—No privacy protocol for the user.

Note The Privacy Protocol can be set to No Priv only when the Authentication Protocol is set to No Auth.

DES—Use Data Encryption Standard (DES) for encryption.

Privacy Password

Enter the password used to decrypt the message payload.

Confirm Privacy Password

Re-enter the privacy password to confirm it.


12.2.1.3.3  Modifying an OSS SNMPv3 User


Step 1 In the Domain Explorer window, choose Administration > GateWay/SNMP Users. The OSS SNMPv3 Users table opens.

Step 2 Select the SNMPv3 user to modify; then, choose Edit > View/Modify (or click the Modify User Properties tool). The Modify OSS SNMPv3 User dialog box opens. Table 12-15 provides descriptions.

Step 3 Modify the fields described in Table 12-15.


Note The IP Address and Username fields are read-only.


Step 4 Click OK. The updated user profile is listed in the OSS SNMPv3 Users table.


12.2.1.3.4  Deleting an OSS SNMPv3 User


Step 1 In the Domain Explorer window, choose Administration > GateWay/SNMP Users. The OSS SNMPv3 Users table opens.

Step 2 Select the SNMPv3 user to delete; then, choose Edit > Delete (or click the Delete User tool).

Step 3 Click OK in the confirmation dialog box.


12.2.1.4  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.


NoteWhen configuring SNMP on NEs, make sure that no other SNMP daemon is running on the designated CTM server host.

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.4.1  Configuring SNMP for the ONS 15216 EDFA2 and EDFA3

For the ONS 15216 EDFA2 and EDFA3, SNMP trap entries are added automatically when the NE is added to CTM. See 5.3.9  Using SNMP, page 5-18 for more information.

12.2.1.4.2  Configuring SNMP for the ONS 15302 and ONS 15305

For information on how to configure SNMP for the ONS 15302 and ONS 15305, see the Cisco ONS 15302 Installation and Operations Guide or Cisco ONS 15305 Installation and Operations Guide.

12.2.1.4.3  Configuring SNMP for CTC-Based NEs


Note This section details how to configure SNMP v1/v2 from the NE to the server. For information on configuring SNMPv3 for CTC-based NEs, see 8.4.8.2.4  SNMPv3 NE Trap Destinations Table, page 8-79.



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-16 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.4.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 forwarded 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 R9.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 marking the NE's operational state as Out of Service and as 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 with 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 15305 CTC, ONS 15310 MA SDH, ONS 15454 SDH, or ONS 15600 SDH subtab

CTC-Based SONET tab > ONS 15310 CL, ONS 15310 MA, ONS 15327, ONS 15454, or 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 or ONS 15600 SDH releases earlier than R8.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 SONET, ONS 15310 MA SDH, ONS 15327, ONS 15454 SONET, ONS 15454 SDH, ONS 155XX, ONS 15600 SONET, ONS 15600 SDH, 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 GateWay/TL1 - NE Connection area is not available for ONS 15454 SDH releases earlier than R5.0 or ONS 15600 SDH releases earlier than R8.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-17 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 polling 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.

CTM automatically tunes the NE polling cycle time. The recommended polling is for a maximum of seven NEs per second. The polling time adjusts automatically if the configured polling time does not meet the recommended value. The new value is stored in the database automatically.

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. The valid range is from 1 to 25.

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:

gwtl1-start

Step 3 Enter the following command to run the script that will stop CTM GateWay/TL1:

gwtl1-stop

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-18 Timeout Behavior 

Listener Mode
DMM
Timeout Applicable
Apply Timeout to ACT-USER
Apply Timeout to All Valid TL1 Commands

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 commands, 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. The message cannot exceed 255 ASCII characters. Non-ASCII characters are not supported.

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 > Error Level drop-down list, select an error level.

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 use the GateWay/TL1 Users table to add, modify, or delete CTM GateWay/TL1 OSS profiles. To view the GateWay/TL1 Users table, choose Administration > GateWay/TL1 Users in the Domain Explorer window. The following table provides descriptions.

Table 12-19 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 (in IPv4 or IPv6 format) 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, the EFD Name field indicates the name of that profile.


12.2.2.9  Managing OSS Client Profiles

The following sections explain 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-20 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 6 to 64 characters

At least two alphabetic characters (A-Z, a-z)

At least one numeric character (0-9)

At least one special character (. % & ! + #)

No colons (:), semicolons (;), or commas (,).

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 contains 15 asterisks (*).

Confirm Password

Re-enter the password to confirm it.

OSS IP Address

Enter the OSS IP address in IPv4 or IPv6 format.

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 > View/Modify (or click the Modify User Properties tool). The Modify GateWay/TL1 User dialog box opens. Table 12-20 provides descriptions.

Step 3 Modify the fields described in Table 12-20.


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.


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 (or click the Show GateWay/TL1 EFD Table tool). The following table provides descriptions.


Table 12-21 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, critical NE 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, major NE 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 NE 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-22 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 (or click the Show GateWay/TL1 EFD Table tool).

Step 3 In the GW/TL1 Event Forwarding Discriminator table, choose Edit > Add EFD Profile (or click the Add Event Forwarding Discriminator Profile tool). The Create Event Forwarding Discriminator Profile wizard opens. 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 when the GW/TL1 Event Forwarding Discriminator table is refreshed.


Table 12-23 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 are shown 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 (or click the Show GateWay/TL1 EFD Table tool).

Step 3 In the GW/TL1 Event Forwarding Discriminator table, select the EFD profile to modify; then, choose Edit > Modify EFD Profile (or click the Modify Event Forwarding Discriminator Profile tool). 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 when the GW/TL1 Event Forwarding Discriminator table is refreshed.


Table 12-24 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 (or click the Show GateWay/TL1 EFD Table tool).

Step 3 In the GW/TL1 Event Forwarding Discriminator table, select the EFD profile to delete; then, choose Edit > Delete EFD Profile (or click the Delete Event Forwarding Discriminator Profile tool).

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 (or click the Show Logged In GateWay TL1 Users tool). The CTM Active GateWay/TL1 Users table opens. The following table provides descriptions.


Table 12-25 Field Descriptions for CTM Active GateWay/TL1 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 (or click the Show Logged In GateWay TL1 Users tool). The CTM Active GateWay/TL1 Users table opens.

Step 3 Select a user and choose Administration > Log Out GateWay TL1 User (or click the Log Out GateWay TL1 User tool).


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-26 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-38 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 2008-05-01 12:30:45

M  1990 COMPLD

;


Error response (for a blank PID field):

CTM 2008-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-27 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-38 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 2008-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-28 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 2008-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-29 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 1000 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:

NEID/NEAID

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-38 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 2008-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 2008-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-30 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 1000 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:

NEID/NEAID

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 2008-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-31 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-38 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 2008-05-01 12:30:45

M  1992 COMPLD

;


Error response (for an invalid command):

   CTM 2008-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-32 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 1000 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-38 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 2008-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 2008-05-01 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-33 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 1000 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-38 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 2008-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 2008-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 a loss of communication (LOC) with an NE in the CTM management domain.

Table 12-34 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:

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). 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 2008-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-35 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:

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). 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 2008-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 2008-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 2008-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-36 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 2008-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-37 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-38 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. A correlation tag (CTAG) is generated by a message sender to correlate the response. This tag is generated when one of the following conditions is not met:

The CTAG contains from 1 to 6 characters.

A separator character (:) must be present after a CTAG.

If the message sender is the TL1 gateway, the valid range for the CTAG is from 1 to 16000.

If the message sender is a TL1 gateway OSS (client), the CTAG value must be greater than zero or must be an alphanumeric string that begins with an alphabetic character; for example, A123BB.

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 Release 9.0 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 v3.0: Multi-Technology Network Management Business Agreement

TMF608 v3.0: Multi-Technology Network Management Information Agreement

TMF814 v3.0: 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 following directory:

Windows: C:\Cisco\TransportManagerClient\config

Sun Solaris: /opt/CiscoTransportManagerClient/config

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-39 Field Descriptions for GateWay/CORBA Service Pane 

Field
Description
Global Tab

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.

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 from 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

Debug Tab

Dump Cache button

Exports the cache (memory) information of the selected CTM GateWay/CORBA service instance to a log file.


12.2.3.4  Viewing the CTM GateWay/CORBA Users Table

The CTM GateWay/CORBA Users table displays information about OSS CORBA client properties. To launch the table, choose Administration > GateWay/CORBA Users 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 GateWay/CORBA Users table from the Control Panel. In the Domain Explorer window, choose Administration > Control Panel. In the Control Panel window, choose Administration > GateWay/CORBA Users.


Table 12-40 Field Descriptions for the GateWay/CORBA Users 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 Users table.


Step 1 In the Domain Explorer window, choose Administration > GateWay/CORBA Users. The GateWay/CORBA Users 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 visible when the GateWay/CORBA Users table is refreshed.


Table 12-41 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 6 to 53 alphanumeric characters. The name cannot contain spaces or special characters.

Password

Enter the password that the OSS client uses to log into the CTM server. The password must contain:

From 1 to 12 characters

At least one special character other than an apostrophe (')

At least two letters (A-Z, a-z), including at least one uppercase letter

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 contains 15 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 > GateWay/CORBA Users. The GateWay/CORBA Users table opens.

Step 2 Select the CORBA user profile to modify; then, choose Edit > View/Modify (or click the Modify User Properties tool). The Modify GateWay/CORBA User dialog box opens. Table 12-41 provides descriptions.

Step 3 After making any necessary modifications, click OK. The updated profile is visible when the GateWay/CORBA Users table is refreshed.


12.2.3.7  Deleting a CTM GateWay/CORBA User


Step 1 In the Domain Explorer window, choose Administration > GateWay/CORBA Users. The GateWay/CORBA Users 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 > GateWay/CORBA Users. The GateWay/CORBA Users 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-42 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 > GateWay/CORBA Users. The GateWay/CORBA Users 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.3.10  Changing the Default Settings of CTM Server and OSS CORBA Client Ports

For each connected OSS, JacORB uses several ports that have the following functions, as illustrated in Figure 12-4:

Session port—The main channel used for handshakes between the OSS and the CORBA gateway. The CORBA gateway assigns this port to a random value between free ports in the system.

Notification service port—The channel used to receive notifications from the CORBA gateway.

Name service port—The port used to request a new session. The value is always fixed; the default port number is 14005.

Session ping port—The channel used to establish a keep-alive handshake between the gateway and the OSS. The CORBA gateway assigns this port to a random value between free ports in the system.

Notification service event port—A second port range used to push alarms or events from the CORBA gateway to the OSS. This port is a keep-alive channel like the previous association to the notification channel.

Figure 12-4 Sample CORBA Gateway Static Port Settings


Caution Errors resulting from changing the CTM server ports or the OSS CORBA client ports can cause unpredictable system behavior.


NoteIt is recommended that you back up the current configuration files before changing the default settings.

You can change the default settings only for OSS CORBA client ports that use JacORB.


You can change the default values of the following ports:

OSS CORBA client ports:

Object Adapter Port

Source Port Range

NAT Between the CTM Server and OSS CORBA Client

CTM server ports:

Name Service Port

Notification Service Port

EMS Session Port

Ping Server-to-Client Port Range

Notification Event Port Range

To set static values for CORBA gateway ports, it is strongly recommended that you follow these steps:


Step 1 With the CTM server running, use the Control Panel to set the notification service port and the session port. See Notification Service Port and EMS Session Port.

Step 2 Enter the following command to stop the CTM server:

ctms-stop

Step 3 Disable IMR. See Disabling IMR.

Step 4 Set the session ping port range. See Ping Server-to-Client Port Range.

Step 5 Set the name service port. See Name Service Port.

Step 6 Set the notification service event port range. See Notification Event Port Range.

Step 7 Enter the following command to start the CTM server:

ctms-start

Step 8 Whenever you establish a new CORBA gateway session, use the netstat command to verify the actual ports in use and compare them to the newly added session.


12.2.3.10.1  Object Adapter Port

If you want to use a fixed port for the OSS CORBA client, change the value of the -DOAPort property. The -DOAPort property should be added to the file that launches the OSS CORBA client application. If there are two client instances running on the same machine, there should be two different port settings.

12.2.3.10.2  Source Port Range


Step 1 Open the jacorb.properties file from the OSS CORBA client directory.

Step 2 Change the value of the following properties:

jacorb.net.socket_factory=org.jacorb.orb.factory.PortRangeSocketFactory 
jacorb.net.socket_factory.port.min=xxx 
jacorb.net.socket_factory.port.max=yyy


12.2.3.10.3  NAT Between the CTM Server and OSS CORBA Client

If Network Address Translation (NAT) exists between the CTM server and OSS CORBA client, configure the jacorb.ior_proxy_host=xxx.xx.xx.xxx property from the jacorb.properties file to receive CTM server callback messages and server-to-client pings. The xxx.xx.xx.xxx variable is the IP address of NAT inside global address.

12.2.3.10.4  Name Service Port


Step 1 Login to the CTM server using shell access.

Step 2 Enter the following command to stop the CTM server:

ctms-stop

Step 3 Complete the following substeps to change the port value in the database:

a. Enter the following command:

sqlplus

b. Enter the following command to set the port value:

UPDATE ctm_config_table SET activevalue=<port number> WHERE sectionname= 
'gatewayCORBA' AND propertyname=<name_service_port_number>;

where <name_service_port_number> is the new port number value.

c. Enter the following command to store the new port value in the database:

commit; 

d. Enter the following command to exit:

exit

Step 4 Open the NameService.xml file from the /opt/<CTM_server_directory>/openfusion/domains/localhost/NameService directory.

Step 5 Change the value of the <Port> property to the desired value. The default value is 14005.

Step 6 Enter the following command to start the CTM server:

ctms-start

Step 7 Complete the following substeps to verify the new value of the port:

a. Enter the following command in the /opt/CiscoTransportManagerServer/openfusion/bin directory:

./manager

b. Choose Domains > OpenFusion > localhost > NameService in the Object Hierarchy tree.

c. Click the CORBA tab in the right pane. The Server Port property displays the new port value.


12.2.3.10.5  Notification Service Port


Step 1 Login to the CTM server using shell access.

Step 2 Stop the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.

Step 3 Change the value of Notification Service Listening Port Number to the desired value.

Step 4 Restart the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.

Step 5 Complete the following substeps to verify the new value of the port:

a. Enter the following command in the /opt/CiscoTransportManagerServer/openfusion/bin directory:

./manager

b. Choose Domains > OpenFusion > localhost > NotificationService in the Object Hierarchy tree.

c. Click the CORBA tab in the right pane. The Server Port property displays the new port value.


Note The Notification Service port value changes when IMR is disabled and the CTM server is restarted for the first time. CTM GateWay/CORBA sets the port value to the first free port in the range 20000 to 20100. This new port value is stored and used each time CTM starts.



12.2.3.10.6  EMS Session Port


Step 1 Stop the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.

Step 2 Change the value of Session Port Number to the desired value.

Step 3 Restart the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.


12.2.3.10.7  Ping Server-to-Client Port Range


Step 1 Stop the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.

Step 2 Open the jacorb.properties file from the /opt/<CTM_server_directory>/openfusion/classes directory.

Step 3 Do the following in the Socket Factories section:

a. Uncomment the .jacorb.net.socket_factory=org.jacorb.orb.factory.PortRangeSocketFactory row.

b. Change the .jacorb.net.socket_factory.port.min value to the desired minimum range value.

c. Change the .jacorb.net.socket_factory.port.max value to the desired maximum range value.

Step 4 Restart the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.


12.2.3.10.8  Notification Event Port Range


Step 1 Stop the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.

Step 2 Open the NotificationService.xml file from the /opt/<CTM_server_directory>/openfusion/domains/localhost/NotificationService directory.

Step 3 Change the value of the JVMFlags property to the following:

<PropertyValue>-Dosgi.parentClassloader=ext 
-Djacorb.net.socket_factory=org.jacorb.orb.factory.PortRangeSocketFactory 
-Djacorb.net.socket_factory.port.min=xxx 
-Djacorb.net.socket_factory.port.max=yyy</PropertyValue>

Note Do not use carriage returns when entering the new value of the JVMFlags property. The new value must be entered on the existing row.


Step 4 Restart the CTM GateWay/CORBA service. See Starting or Stopping CTM GateWay/CORBA for instructions.


12.2.3.10.9  Disabling IMR


Step 1 Make a backup copy of the jacorb.properties file located in the <CTM_server_installation_directory>/openfusion/classes directory.

Step 2 In the jacorb.properties file, configure the following properties to "off":

jacorb.use_imr=off
jacorb.use_imr_endpoint=off


12.2.4  Trap Management on MGX Voice Gateway Devices

The following sections describe how to manage Cisco MGX Voice Gateway traps through CTM:

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 R9.0, fault management on MGX NEs 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 management system. Through the Service Agent, up to 16 external SNMP managers (with 1 of the 16 reserved for CTM) 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.

The traps that are delivered by the Service Agent are standard SNMPv1 traps. These traps are delivered on behalf of the network devices and CTM.

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 that reflect the health of CTM.

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 installation and are located in the /opt/CiscoTransportManagerServer/cwm/svplus/mibs/mibdir directory.


User connection traps that are generated in CTM.

12.2.4.1.2  CTM-Generated Traps

The severity of each trap is presented in a trapSeverity variable in each trap unless otherwise noted.

For traps 29201, 29202, or 29203 with severity clear (1), alarms are cleared for a given mgmAffectedObject. Alarms are represented by the previous trap with the same number and the 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-43 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 MGX server will be shut down in 5 minutes 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 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. Values are:

1: unknown-error

2: initialization-error

3: spawn-child-error

4: configuration-error

5: communication-error-ilog

6: communication-error-shared-mem

7: communication-error-corba

8: tftpmgr-queue-full


The following table describes node traps.

Table 12-44 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 two 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-45 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—Robust Trap Mechanism," 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). The managerNumOfValidEntries MIB variable stores the number of subscribed managers in the RTM table.

To register an SNMP manager with the Service Agent, enter a SET request on the trapConfigTable (see Table F-2 on page F-1) for the following mandatory objects:

managerRowStatus.<managerIPaddress> = addRow

readingTrapFlag.<managerIPaddress> = false

trapRedeliverFlag.<managerIPaddress> = false

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 performing 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
: INTEGER: 162
stratacom.rtm.trapsConfig.trapConfigTable.trapConfigEntry.managerRowStatus.192.99.88.101 :
INTEGER: addRow


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 :
INTEGER: delRow

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 to start the RtmProxy process.


Note You must change the default expiration time prior to starting the CTM core.


For example, to change the expiration time to 7200 seconds (or 2 hours), enter 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 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 separate from CTM, and you must register with the RtmProxy that is running on the CTM workstation.

To register with the RtmProxy, complete the following steps:


Step 1 Make sure all CTM MIBs are integrated with HPOV on the machine where HPOV is installed.

If the MIBs are not integrated, you will see OIDs in the Event Browser.

Step 2 Make sure the RtmProxy is running on the CTM workstation.

Step 3 Enter the following SNMP commands on the CTM workstation:

/opt/OV/bin/snmpset -p 8161 -c private <CTM_workstation>
managerPortNumber.<IP_address_of_HPOV_workstation> integer 162
managerRowStatus.<IP_address_of_HPOV_workstation> integer 1

The following example shows the command syntax with the CTM machine as nectra2. 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 check whether the browser is receiving traps.

Step 5 If you do not want to view the traps in HPOV (if you want to unregister), enter the following commands on the CTM workstation:

/opt/OV/bin/snmpset -p 8161 -c private <CTM_workstation>
managerRowStatus.<IP_address_of_HPOV_workstation> 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 9.0nectra2
managerRowStatus.10.77.240.67
integer 2


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, enter 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 SNMP Service Agent, enter 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 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 redelivered.

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 additional 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 sets 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.

4. The manager starts checking the lastSequenceNumber.

5. 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.