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)

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.

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.

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

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.

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

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.

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

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

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.

Note•When 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.

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.

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.

12.2.2.2 Starting or Stopping CTM GateWay/CORBA

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.

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.

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.

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.

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.

Note•It 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.

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

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

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.

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.

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

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:

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.