Cisco Transport Manager User's Guide, 9.2
Chapter 12: Managing Southbound and Northbound Interfaces
Downloads: This chapterpdf (PDF - 611.0KB) The complete bookPDF (PDF - 35.31MB) | 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.1.5  Changing the HTTP Server Port

12.2  How Do I Manage Northbound Interfaces?

12.2.1  Managing CTM GateWay/SNMP

12.2.2  Managing CTM GateWay/CORBA

12.2.3  Trap Management on MGX Voice Gateway Devices


Managing Southbound and Northbound Interfaces


CTM uses protocols such as CORBA, SNMP, 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, 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-4 on page 2-11 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 15305 NEs.

Table 12-2 Port Information for the ONS 15305

Port
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-57.

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

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

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

Note Ports 40xx are required only if shell access is set to Secure.

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 the  MGX Voice Gateway.

Table 12-5 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-86.

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-6 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 (configurable)

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

8170

Inbound/outbound

UDP

MGX server processes

SNMP service MasterAgent

MasterAgent listening port


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

Table 12-9 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 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 15305 R3.0 (CTC-based)

161

Outbound

UDP

SNMP

ONS 15305

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.

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.

40xx

Outbound

TCP

Telnet

CTC-based

ML cards: L2 Service Resync port when the shell access is set to secure. From any port on CTM to port 40xx 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-10 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


The following table lists the TCP ports to use in a SOCKS proxy server configuration. This information is helpful when setting up a firewall routing table.

Table 12-11 TCP Ports to Open in a SOCKS Proxy Server Configuration 

Port
Inbound or Outbound
Protocol
Application Protocol
Notes

1080

Inbound on firewall/SOCKS proxy host

TCP

SOCKS v5

The port is configurable and is used for the connection between the CTM client host and the firewall host.

10023-10086

Inbound (CTM server host)

TCP

Telnet

Used for the connection between the CTM client host and the CTM server host.

8051

Inbound (CTM server host)

TCP

HTTP

Used for the connection between the CTM client host and the CTM server host.

All CTC ports, for CTC cross-launch

Inbound on the NE that CTC is connected to

TCP

Used for the connection between the CTM client host and the subnetwork that contains the NE that CTC wants to reach.


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-6 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.1.5  Changing the HTTP Server Port

If other applications use the HTTP server port, you can change the default port. Complete the following steps:


Step 1 Open a shell on the CTM server workstation and enter the following command to shut down the CTM server:

ctms-stop

Step 2 Enter the following commands to change directories to the HTTP server directory and create a copy of the configuration file:

cd /Apache/conf
cp httpd.conf httpd.conf.ori

Step 3 Locate the following lines in the httpd.conf file:

Listen IP-address:8051
Listen 127.0.0.1:8051
ServerName IP-address:8051

In each of these lines, replace the default port 8051 with the new HTTP server port.

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

ctms-start

Step 5 On each CTM client, locate the following line in the CTM-client-installation-directory/config/ems_client.cfg:

Apache_port=\:8051

Replace 8051 with the new HTTP server port.


Caution Be sure to repeat this change on each CTM client.

Step 6 Launch the CTM client. To verify that the HTTP services are working, choose Help > Current Window in the Domain Explorer.


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-2 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/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 generated or received by the server workstation 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-2 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-12 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 a valid IP address or hostname for the SNMP forwarding host; then, click Add. To remove an SNMP host, select the IP address or hostname of the host and click Remove.

Step 4 Repeat for each host to be added or removed; then, click Save.


Table 12-12 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 or hostname of the host where each SNMP trap will be forwarded. You can enter up to 16 valid IP addresses or hostnames. Use the Add and Remove buttons to add or remove IP addresses or hostnames.


12.2.1.3  Configuring Northbound OSS SNMPv3 Users—Optical NEs

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-13 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-14 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 length of the password, the Password and Confirm Password fields display only a fixed-length string of 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-14 provides descriptions.

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


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 Northbound SNMPv3 Users—MGX NEs

CTM forwards traps from MGX devices to the external OSS. The northbound interface for CTM MGX supports SNMPv3 to receive OSS registration requests and send traps to the OSS.

SNMPv3 offers authentication and privacy mechanisms to keep SNMP packet traffic on the wire confidential. Enhanced security prevents packets on the wire from being sniffed, SNMP community strings from being compromised, and configurations from being modified. SNMPv3 provides a user security model that uses encryption algorithms to authenticate and encrypt SNMP packets on the wire.

You can view, add, modify, and delete northbound MGX SNMPv3 users in the CTM database. See the following procedures:

Viewing the SNMPv3 NBI Users Table

Adding an SNMPv3 NBI User

Modifying an SNMPv3 NBI User

Modifying the Agent Configuration for MGX SNMPv3 NBI Support

Deleting an SNMPv3 NBI User

12.2.1.4.1  Viewing the SNMPv3 NBI Users Table

To view the SNMPv3 NBI Users table, choose Administration > MGX SNMPv3 NBI Users in the Domain Explorer window. The following table provides descriptions.

Table 12-15 Field Descriptions for the SNMPv3 NBI Users Table 

Column Name
Description

Username

Name of the northbound interface (NBI) user who authenticates the SNMPv3 trap.

Authentication Protocol

Authentication protocol used to authenticate the SNMPv3 NBI user.

Privacy Protocol

Encryption method used for the packets sent by the SNMPv3 NBI user.


12.2.1.4.2  Adding an SNMPv3 NBI User


Step 1 In the Domain Explorer window, choose Administration > MGX SNMPv3 NBI Users. The SNMPv3 NBI Users table opens.

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

Step 3 After providing the required information, click OK.


Table 12-16 Field Descriptions for the Add/Modify SNMPv3 NBI User Dialog Box 

Field
Description

Username

Enter a unique name for the new SNMPv3 NBI user. The name must contain from 5 to 64 alphanumeric characters. The name cannot contain spaces or special characters. The default user, cisco, is created in the CTM database automatically during the CTM server installation.

Authentication Protocol

Choose the authentication protocol to use for authenticating the MGX SNMPv3 NBI user. Values are MD5 (the default), SHA, or NoAuth.

Authentication Password

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

From 5 to 64 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 length of the password, the Password and Confirm Password fields display only a fixed-length string of 15 asterisks (*).

Confirm Authentication Password

Re-enter the password to confirm it.

Privacy Protocol

Select the encryption method to use for packets sent by the SNMPv3 NBI user. You can choose one of the following:

NoPriv—No privacy protocol for the user.

Note The Privacy Protocol can be set to NoPriv only when the Authentication Protocol is set to NoAuth.

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

AES128—Use Advanced Encryption Standard (AES) for encryption. AES128 is a standard protocol used as a privacy protocol in SNMPv3.

Privacy Password

Enter the password used to decrypt the message payload. The password must contain:

From 5 to 64 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 length of the password, the Privacy Password and Confirm Privacy Password fields display only a fixed-length string of 15 asterisks (*).

Confirm Privacy Password

Re-enter the privacy password to confirm it.


12.2.1.4.3  Modifying an SNMPv3 NBI User


Step 1 In the Domain Explorer window, choose Administration > MGX SNMPv3 NBI Users. The SNMPv3 NBI Users table opens.

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

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


Note The Username fields is read-only.


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


12.2.1.4.4  Modifying the Agent Configuration for MGX SNMPv3 NBI Support


Step 1 In the Domain Explorer window, choose Administration > MGX SNMPv3 NBI Users. The SNMPv3 NBI Users table opens.

Step 2 Select the SNMPv3 NBI user to modify; then, choose Edit > Agent Configuration (or click the Agent Configuration tool). The Agent Configuration dialog box opens. The following table provides descriptions.

Step 3 After providing the required information, click OK.

Step 4 Click OK in the following message box:

The changes will take effect only after the MGX NE service instance is restarted. To 
cancel the changes, click Cancel. To apply the changes, click OK; then, restart the MGX NE 
service in the Control Panel window.

Step 5 Open the Control Panel window (Administration > Control Panel) and restart the MGX NE service.


Table 12-17 Field Descriptions for the Agent Configuration Dialog Box 

Field
Description

Agent Mode

Specify the agent mode: SNMPv1 (the default) or SNMPv3.

SNMPv1—Insecure mode; the agent accepts SNMPv1 and SNMPv3 requests.

SNMPv3—Secure mode; the agent accepts only SNMPv3 requests.

Note MGX NEs do not support SNMPv2.

Overall Logging

Disable or enable logging of agent server process messages.

Note To increase performance, logging is disabled by default.

Read Community String

Specify the agent configuration string for read-only operations. The string must contain from 5 to 32 characters. The default is public.

Write Community String

Specify the agent configuration string for read-write operations. The string must contain from 5 to 32 characters. The default is private.


12.2.1.4.5  Deleting an SNMPv3 NBI User


Step 1 In the Domain Explorer window, choose Administration > MGX SNMPv3 NBI Users. The SNMPv3 NBI Users table opens.

Step 2 Select the SNMPv3 NBI 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.5  Configuring SNMP on Optical 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 15305

Configuring SNMP for CTC-Based NEs

Configuring SNMP for the 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.5.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-17 for more information.

12.2.1.5.2  Configuring SNMP for the ONS 15305

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

12.2.1.5.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.7.2.4  SNMPv3 NE Trap Destinations Table, page 8-73.



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-18 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 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.5.4  Configuring SNMP for the ONS 15530 and ONS 15540

Configuring SNMP on 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/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.2 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-2 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-2 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.2.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 default timeout is 120 seconds; the recommended range is from 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.2.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.2.3  Viewing the CTM GateWay/CORBA Service Pane

Use the CTM GateWay/CORBA Service pane to start and stop the CTM GateWay/CORBA service and configure CORBA ports and parameters. The following table provides descriptions.


Note In CTM R9.2, CTM server ports can be configured from the Ports Configuration tab. Unless otherwise noted, all port configuration changes require a CTM GateWay/CORBA restart.


Table 12-19 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 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 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.

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

Port Configuration Tab

Enable IMR checkbox

IMR is always disabled. This allows you to configure CTM GateWay/CORBA to use static ports. This is a read-only option.

Name Service

Enter the port that the name service uses to listen for incoming requests. The default value is 14005.

Note This option requires a server restart.

Notification Service

Enter the port that the notification service uses to listen for incoming requests. The default value is 20001.

EMS Session

Enter the EMS session port value. The default value is 20100.

Event Notification (min)

Enter the minimum Event Notification port value. The default value is 20001.

Event Notification (max)

Enter the maximum Event Notification port value. The default value is 20099.

Server-to-Client (min)

Enter the minimum Server-to-Client port value. The default value is 20101.

Server-to-Client (max)

Enter the maximum Server-to-Client port value. The default value is 20199.

Debug Tab

Dump Cache button

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

Overall Logging

Click the Enable radio button to enable overall debugging and to select debug modules for the PM service. Click the Disable radio button to disable overall debugging.

Debug Modules

If overall logging is enabled, lists the modules that can be used for debugging. Select a module from the Available list; then, click the Add button to add the module to the Selected list. Use the Remove button to return the module to the Available list. Debug logging will be performed on the modules in the Selected list.


12.2.2.3.1  Configuring MGX Orbix Ports to Use Specific Range of Ports

In Cisco MGX Voice Gateway, to configure Orbix ports to use specific range of ports restricted through firewall, complete the following steps before starting CTM processes:


Step 1 Stop Orbix processes using the stoporbix2000 script.

For example, enter:

/opt/CiscoTransportManagerServer/cwm/svplus/scripts/stoporbix2000

Step 2 Change the directory to opt/CiscoTransportManagerServer/cwm/svplus/orbix_domain/domains and open the cwm_ctm-machine-name_domain.cfg file.

Step 3 Add the following line at the end of the cwm_ctm-machine-name_domain.cfg file:

policies:iiop:server_address_mode_policy:port_range = "Port range"

For example, to add the port range as 5500:6000, enter:

policies:iiop:server_address_mode_policy:port_range = "5500:6000"


Note For 10 simultaneous client increments, you can add 100 more ports in the range.


Step 4 Start Orbix using the startorbix2000 script.

For example, enter:

/opt/CiscoTransportManagerServer/cwm/svplus/scripts/startorbix2000


12.2.2.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-20 Field Descriptions for the GateWay/CORBA Users Table 

Column Name
Description

OSS Profile Name

Displays the name of the selected OSS client.


12.2.2.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-21 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 length of the password, the Password and Confirm Password fields display only a fixed-length string of 15 asterisks (*).

Confirm Password

Re-enter the password to confirm it.


12.2.2.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-21 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.2.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.2.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-22 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.2.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.2.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-3:

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-3 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:

NameService Port

NotificationService Port

EMSSession Port

Ping Server-to-Client Port Range

Notification Event Port Range


Note You can also set CTM server port values from the CTM GateWay/CORBA Service pane > Port Configuration tab. For more information, see Viewing the CTM GateWay/CORBA Service Pane.


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 NotificationService Port and EMSSession 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 NameService 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.2.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.2.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.2.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.2.10.4  NameService Port


Note You can also set the Name Service port value from the CTM GateWay/CORBA Service pane > Port Configuration tab. For more information, see Viewing the CTM GateWay/CORBA Service Pane.



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

ctms-stop

Step 2 Open the NameService.xml file from the /opt/CTM-server-directory/openfusion/domains/localhost/NameService directory.

Step 3 Change the value of the Port property to the desired value. The default value is 14005.

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

ctms-start

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 > 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.2.10.5  NotificationService Port


Note You can also set the Notification Service port value from the CTM GateWay/CORBA Service pane > Port Configuration tab. For more information, see Viewing the CTM GateWay/CORBA Service Pane.



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

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

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

Step 4 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.


12.2.2.10.6  EMSSession Port


Note You can also set the EMS Session port value from the CTM GateWay/CORBA Service pane > Port Configuration tab. For more information, see Viewing the CTM GateWay/CORBA Service Pane.



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.2.10.7  Ping Server-to-Client Port Range


Note You can also set the Server-to-Client port values from the CTM GateWay/CORBA Service pane > Port Configuration tab. For more information, see Viewing the CTM GateWay/CORBA Service Pane.



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.2.10.8  Notification Event Port Range


Note You can also set the Notification Event port range from the CTM GateWay/CORBA Service pane > Port Configuration tab. For more information, see Viewing the CTM GateWay/CORBA Service Pane.



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.2.10.9  Disabling IMR

By default, IMR is disabled. To enable IMR, you must manually edit the jacorb.properties file.


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.2.11  Changing the CTM GateWay/CORBA Client Ports

In earlier CTM releases, CTM GateWay/CORBA was installed and configured to use random ports and did not support a firewall between the OSS client and the CTM server. In CTM R9.2, you can install and configure CTM GateWay/CORBA to use static ports, which facilitates the use of a firewall between the OSS client and the CTM server.

12.2.2.11.1  Installation

When you install CTM GateWay/CORBA, all of the ports are configured with default fixed values. See Table 12-23 for the list of default fixed values.


Note To configure CTM GateWay/CORBA to use static ports, you must disable IMR. See Configuration.


Table 12-23 List of Parameters and Fixed Values

Parameters
Default Fixed Values

EMS Session Port

20100

Name Service Port

14005

Notification Service Port

20001

Session Ping Port range

20101-20199

Event Notification Port range

20002-20099

IMR

Off

Proxy Host Address

Not set



Note It is recommended that you change the default fixed values after the CTM GateWay/CORBA installation is complete. If you change the values while installing CTM GateWay/CORBA, the installation might fail.


12.2.2.11.2  Configuration


NoteYou can also configure CTM server ports from the CTM GateWay/CORBA Service pane > Port Configuration tab. For more information, see Viewing the CTM GateWay/CORBA Service Pane.

CTM GateWay/CORBA must be stopped in order to configure ports.


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

Step 2 Invoke the manageCTMCorbaPorts.sh file from the CTM-server-installation-directory/bin directory.


Note If CTM GateWay/CORBA is running, you only have the option to read port configuration settings.


The following appears:

--------------------------------------------------
 Manage CTM GateWay/CORBA Ports Utility
--------------------------------------------------
  1. Read Configuration Set
  2. Read Configuration Running
  3. Restore All Default Values
  4. Change All Settings
  5. Change Name Service Port
  6. Change Proxy Host Address
  7. Change Notification Service Port
  8. Change EMS Session Port
  9. Change S->C Ping Port Range
 10. Change Notification Event Port Range 
  0. Exit
-------------------------------------------------

Step 3 Select an item from the menu.

For example, enter 1 to select Read Configuration Set.

For more information on these menu items, see the Cisco Transport Manager Release 9.2 GateWay/CORBA User Guide and Programmer Manual.


Note If you select a menu item that changes the configuration, you will be prompted to restart either CTM GateWay/CORBA or the CTM server. See Starting or Stopping CTM GateWay/CORBA for instructions.



12.2.3  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

Setting Special Registration

Triggering the RTM Protocol

12.2.3.1  Fault Management Interface

In CTM R9.2, 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.3.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.3.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-24 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-25 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-26 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.3.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.3.2.1  Manager Registration with a Secured Agent

To receive RTM traps from the Service Agent, an SNMP manager must register itself with the Service Agent when the service agent is in secured mode.

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

managerTrapSecurityName. .<managerIPaddress> = "cisco"

managerTrapVersion.<managerIPaddress> =3

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 cancelled automatically.

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.3.2.2  Example of Registering with RTM Service Agent when the Agent Is in Secured Mode

To register with the RTM Service Agent, send a SET request on the following 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

SecurityName: cisco

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

SecurityName: cisco

Value: 1

OID: 1.3.6.1.4.1.351.120.1.1.1.9.IPADDR

where IPADDR is the IP address of the manager in dotted decimal notation.

Name: managerTrapVersion

Type: Integer

SecurityName: cisco

Value: 1


Note If the OSS requires to receive SNMPv3 traps, set this OID to 3.


OID: 1.3.6.1.4.1.351.120.1.1.1.8.IPADDR

where IPADDR is the IP address of the manager in dotted decimal notation.

Name: managerTrapSecurityName

Type: OctetString

SecurityName: cisco (default)

Value: cisco

To register with the RTM Service Agent, use the syntax in the following example. This example uses manager IP address 192.99.88.101, port number 162, security name Cisco, version 3, and OSS IP address 10.77.202.230.

Example 12-1 Registering with the RTM

#setenv SR_MGR_CONF_DIR 
/opt/CiscoTransportManagerServer/cwm/svplus/scripts/proxyscripts/lib
#setenv SR_SNMP_TEST_PORT 8161

#./opt/CiscoTransportManagerServer/cwm/svplus/tools/snmp/setany -v3  192.99.88.101 cisco 
1.3.6.1.4.1.351.120.1.1.1.3.10.77.202.230 -i 1\
1.3.6.1.4.1.351.120.1.1.1.8.10.77.202.230 -o cisco \
1.3.6.1.4.1.351.120.1.1.1.9.10.77.202.230 -i 3


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

#./opt/CiscoTransportManagerServer/cwm/svplus/tools/snmp/setany -v3  192.99.88.101 cisco 
1.3.6.1.4.1.351.120.1.1.1.3.10.77.202.230 -i 2

12.2.3.2.4  Registering 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:

#setenv SR_MGR_CONF_DIR 
/opt/CiscoTransportManagerServer/cwm/svplus/scripts/proxyscripts/lib
#setenv SR_SNMP_TEST_PORT 8161

#./opt/CiscoTransportManagerServer/cwm/svplus/tools/snmp/setany -v3 CTM-workstation cisco 
1.3.6.1.4.1.351.120.1.1.1.3. IP-address-of-HPOV-workstation -i 1\
1.3.6.1.4.1.351.120.1.1.1.8. IP-address-of-HPOV-workstation -o cisco \
1.3.6.1.4.1.351.120.1.1.1.9. IP-address-of-HPOV-workstation -i 3

The following example shows the command syntax with the CTM machine as tballraker21. The machine for viewing traps has an IP address of 10.77.202.230:

./setany -v3 tballraker21 cisco 1.3.6.1.4.1.351.120.1.1.1.3.10.77.202.230 -i 1\
1.3.6.1.4.1.351.120.1.1.1.8.10.77.202.230 -o cisco \
1.3.6.1.4.1.351.120.1.1.1.9.10.77.202.230 -i 3

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/CiscoTransportManagerServer/cwm/svplus/tools/snmp/setany -v3 CTM-workstation cisco 
1.3.6.1.4.1.351.120.1.1.1.3. IP-address-of-HPOV-workstation -i 2

The following example shows unregistering with the RtmProxy using the same variables as the previous example:

#./opt/CiscoTransportManagerServer/cwm/svplus/tools/snmp/setany -v3  192.99.88.101 cisco 
1.3.6.1.4.1.351.120.1.1.1.3.10.77.202.230 -i 2


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

#./opt/CiscoTransportManagerServer/cwm/svplus/tools/snmp/getmany -v3 192.99.88.101 cisco 
1.3.6.1.4.1.351.120.1.2.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

#./opt/CiscoTransportManagerServer/cwm/svplus/tools/snmp/getmany -v3  192.99.88.101 cisco 
1.3.6.1.4.1.351.120.1.2.0
stratacom.rtm.trapsConfig.lastSequenceNumber.0 : INTEGER: 833

12.2.3.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.3.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.3.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.3.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.3.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.3.7  Setting 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.3.8  Triggering the 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.