92 Gateway

CH A P T E R 12
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:
• 12.1 How Do I Manage Southbound Interfaces?, page 12-1
• 12.2 How Do I Manage Northbound Interfaces?, page 12-10
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.
Cisco Transport Manager Release 9.2 User Guide

OL-20936-01 12-1
Chapter 12 Managing Southbound and Northbound Interfaces
How Do I Manage Southbound Interfaces?
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 161, 162 Outbound
Note CTM GateWay/SNMP uses port 162 as an
internal port.
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 161
Note CTM GateWay/SNMP uses port 162 as an internal port.
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 Configurable with:
Communications and Control Card
• TCC+/TCC2 fixed (57790, outbound).
(TCC+/TCC2) (NE)
• 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 Dynamic (current functionality).
(callback)
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).

12-2 OL-20936-01
Table 12-3 Port Information for CTC-Based NEs (continued)
Port NE
CTC launched from CTM Domain • From any CTC port to the IIOP port on the NE.
Explorer
• 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 From any NE port to SNMP trap port 162 (inbound) on the CTM server.
Note CTM GateWay/SNMP uses
port 162 as an internal port.
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 UDP 161 Outbound
Note CTM GateWay/SNMP uses port 162 as
an internal port.
SNMP traps UDP 162 Inbound
CiscoView (if CiscoView is cross-launched by TCP 1741 Inbound (CTM client to
CTM to manage ONS 155xx NEs) 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

OL-20936-01 12-3
Table 12-5 Port Information for the MGX Voice Gateway (continued)
Port MGX Voice Gateway Inbound or Outbound?

Telnet CLI 23 Outbound
FTP (for PM data collection, and 24 Outbound
configuration file upload)
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
Inbound or Application
Port Outbound Protocol 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

12-4 OL-20936-01
Table 12-6 CTM Server-to-CTM Client Ports (continued)
20000 (configurable) Inbound TCP CORBA CORBA ImR CORBA Implementation
Repository port
30000 Inbound TCP CORBA SM service Service Manager port
CORBA IIOP listener Inbound TCP CORBA CTC-based network Dynamic: Ports are selected
port services randomly
22 Inbound TCP SSH CTM server host Standard SSH port for
secure login
3075, 3079, 3094 Inbound TCP CORBA MGM Orbix Cisco MGX Voice
CORBA services Gateway: Orbix ports
Configurable Inbound/outbound TCP CORBA MGM Orbix Cisco MGX Voice
CORBA servers Gateway: Range of ports is
specified in the associated
Orbix domain config file
1521 Inbound TCP JDBC Oracle listener Database listener port
9000–9011 Inbound/outbound TCP MGX server Base service Cisco MGX Voice
(configurable) processes 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
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

OL-20936-01 12-5
client service agent.
Table 12-8 CTM Server-to-Client Service Agent Ports
Application
Port Inbound or Outbound Protocol Protocol Service Notes
8161 Inbound/outbound UDP MGX server SNMP service agent RTM proxy port used for sending traps
processes to HPOV, CIC, and so on
8170 Inbound/outbound UDP MGX server SNMP service MasterAgent listening port
processes MasterAgent
NEs.
Table 12-9 CTM Server-to-NE Ports
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 —
161 Outbound UDP SNMP ONS 15305 R3.0 —
(CTC-based)
161 Outbound UDP SNMP ONS 15305 —
3083 Outbound TCP TL1 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.

12-6 OL-20936-01
Table 12-9 CTM Server-to-NE Ports (continued)
CORBA listener Outbound TCP CORBA CTC-based The port is configurable with:
port on the
• TCC+/TCC2 fixed (57790,
TCC+/TCC2 card
outbound).
(NE)
• Standard Internet Inter-ORB
Protocol (IIOP) port (683,
outbound).
• User-defined constant.
CORBA listener Inbound TCP CORBA CTC-based Dynamic.
port on the CTM
server (callback)
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 —

OL-20936-01 12-7
Table 12-9 CTM Server-to-NE Ports (continued)
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
Inbound or Application Cross-Launched

Port Outbound Protocol Protocol 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 Outbound TCP CORBA CTC The port is configurable with:
on the TCC+/TCC2
• TCC+/TCC2 fixed (57790,
card (NE)
outbound)
• Standard Internet Inter-ORB
Protocol (IIOP) port (683,
outbound)
• User-defined constant
CORBA listener port Inbound TCP CORBA CTC Dynamic: The port range can be
on the CTM server configured
(callback)
80 Outbound TCP HTTP CTC —

12-8 OL-20936-01
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 Outbound Protocol Protocol Notes
1080 Inbound on TCP SOCKS v5 The port is configurable and is used for the connection
firewall/SOCKS between the CTM client host and the firewall host.
proxy host
10023–10086 Inbound (CTM TCP Telnet Used for the connection between the CTM client host and the
server host) CTM server host.
8051 Inbound (CTM TCP HTTP Used for the connection between the CTM client host and the
server host) CTM server host.
All CTC ports, for Inbound on the TCP — Used for the connection between the CTM client host and the
CTC cross-launch NE that CTC is subnetwork that contains the NE that CTC wants to reach.
connected to
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

OL-20936-01 12-9
How Do I Manage Northbound Interfaces?
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, page 12-10
• 12.2.2 Managing CTM GateWay/CORBA, page 12-20
• 12.2.3 Trap Management on MGX Voice Gateway Devices, page 12-34
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).

12-10 OL-20936-01
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.

OL-20936-01 12-11
Figure 12-1 CTM GateWay/SNMP Communications Architecture
Service provider's Cisco Transport Manager

OSS
Cisco 3600
(or equivalent)
SNMP SNMP
UDP UDP
Data communications
IP IP
network (DCN)
Ethernet (TCP/IP) Ethernet
10BASE-T 10BASE-T
Cisco 3600
(or equivalent)
ONS 15454 ONS 15454

SONET SDH
ONS 15216
EDFA2
ONS 15454
ONS 15327 SONET
SONET ring SDH ring
ONS 15454 ONS 15454

SDH SDH
SNMP
UDP
IP
HDLC
ONS 15305
DCC ONS 15540
DWDM
ring 196161
ONS 15530
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.

12-12 OL-20936-01
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 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:
• 12.2.1.3.1 Viewing the OSS SNMPv3 Users Table, page 12-14
• 12.2.1.3.2 Adding an OSS SNMPv3 User, page 12-14
• 12.2.1.3.3 Modifying an OSS SNMPv3 User, page 12-15

OL-20936-01 12-13
• 12.2.1.3.4 Deleting an OSS SNMPv3 User, page 12-15
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.

12-14 OL-20936-01
Table 12-14 Field Descriptions for the Add/Modify OSS SNMPv3 User Dialog Box (continued)
Field Description
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 Re-enter the password to confirm it.
Password
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
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
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.

OL-20936-01 12-15
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:
• 12.2.1.4.1 Viewing the SNMPv3 NBI Users Table, page 12-16
• 12.2.1.4.2 Adding an SNMPv3 NBI User, page 12-16
• 12.2.1.4.3 Modifying an SNMPv3 NBI User, page 12-17
• 12.2.1.4.4 Modifying the Agent Configuration for MGX SNMPv3 NBI Support, page 12-18
• 12.2.1.4.5 Deleting an SNMPv3 NBI User, page 12-18
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

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

12-16 OL-20936-01
Table 12-16 Field Descriptions for the Add/Modify SNMPv3 NBI User Dialog Box (continued)
Field Description
Authentication Password Enter the password used to authenticate the SNMPv3 NBI user. The password must contain:
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 Re-enter the password to confirm it.
Password
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:
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 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.

OL-20936-01 12-17
12.2.1.4.4 Modifying the Agent Configuration for MGX SNMPv3 NBI Support
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 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 2 Select the SNMPv3 NBI user to delete; then, choose Edit > Delete (or click the Delete User tool).
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:
• 12.2.1.5.1 Configuring SNMP for the ONS 15216 EDFA2 and EDFA3, page 12-19

12-18 OL-20936-01
• 12.2.1.5.2 Configuring SNMP for the ONS 15305, page 12-19

• 12.2.1.5.3 Configuring SNMP for CTC-Based NEs, page 12-19
• 12.2.1.5.4 Configuring SNMP for the ONS 15530 and ONS 15540, page 12-20
For additional information, refer to the NE user documentation.
Note • When configuring SNMP on NEs, make sure that no other SNMP daemon is running on the
designated CTM server host.
• 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.

OL-20936-01 12-19
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 Enter the maximum number of traps per second that will be sent to the SNMP manager. A zero value
Second indicates that there is no maximum and all traps are sent to the SNMP manager.
(not applicable to
the ONS 15600)
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.

12-20 OL-20936-01
Figure 12-2 CTM GateWay/CORBA Communications Architecture
Service provider's OSS Cisco Transport Manager
CORBA
GIOP
IIOP
TCP
IP
Ethernet
83273
10BASE-T
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 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.

OL-20936-01 12-21
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 When checked, usernames and passwords are transmitted between the EMS server and the OSS in
Username and encrypted format. The maximum encryption length is 53 bytes. If this check box is unchecked,
Password CTM GateWay/CORBA usernames and passwords are transmitted without encryption. By default,
encryption is disabled at installation.
Heartbeat for Notifies the OSS if a failure in the notification service has occurred. The heartbeat is measured in
Notification Channel minutes; the range is 0 to 999 minutes. A zero value implies that the heartbeat is disabled.
Maximum Number of Specifies the number of CTM GateWay/CORBA sessions that can be active at the same time. The
Simultaneous range is from 4 to 25; the default is 4.
Sessions
Maximum Events per Sets the MaxEventsPerConsumer administrative quality of service (QoS) parameter on the
Consumer 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.

12-22 OL-20936-01
Table 12-19 Field Descriptions for GateWay/CORBA Service Pane (continued)
Field Description
Notification Service Defines the service name used by the resolve_initial_reference function to get a reference to the
Name 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 Defines the naming context of the notification service. This property is used when the
Naming Context 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.
Notification Service Enter the notification service factory Information Object Repository (IOR) filename located in the
Factory IOR /opt/CiscoTransportManagerServer/openfusion/domains/OpenFusion/localhost/NotificationService/
Filename 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.
Name Service Server Defines where the name servers are running. Accepts a comma-separated list of hostnames.
List
Name Service Root Defines the path to find the naming service’s IOR on each host defined on the server list. The complete
IOR 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 IMR is always disabled. This allows you to configure CTM GateWay/CORBA to use static ports. This
checkbox 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.

OL-20936-01 12-23
Table 12-19 Field Descriptions for GateWay/CORBA Service Pane (continued)
Field Description
Event Notification Enter the minimum Event Notification port value. The default value is 20001.
(min)
Event Notification Enter the maximum Event Notification port value. The default value is 20099.
(max)
Server-to-Client Enter the minimum Server-to-Client port value. The default value is 20101.
(min)
Server-to-Client Enter the maximum Server-to-Client port value. The default value is 20199.
(max)
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-24 OL-20936-01
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

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

OL-20936-01 12-25
12.2.2.6 Modifying a CTM GateWay/CORBA User’s Properties
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 2 Select the CORBA user profile to delete; then, choose Edit > Delete (or click the Delete User tool).
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 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-26 OL-20936-01
12.2.2.9 Ending an Active GateWay/CORBA User Session
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.

OL-20936-01 12-27
Figure 12-3 Sample CORBA Gateway Static Port Settings
Fixed port
CTM server OSS client

Name service port
14005
Resolv
e
Notification service Source port range
port
Get_consumeradmin
51000
1570 ……
(CP) 51500
Notification service
event port r ange
Push_Structured_E
(SÆ C) vent
16000 n OA port range
s sio Ping SÆ C
…….. se g
16500 EMS epin Event SÆ C
Get e ke
us
(EMS) session port Ho
17000
1600
(CP) Ping
Session ping port range

(SÆ C)
15000
……..
194552
15500
CP : Settable through the Control Panel

SÆ C: Server to client
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.

12-28 OL-20936-01
You can change the default values of the following ports:

• OSS CORBA client ports:
– 12.2.2.10.1 Object Adapter Port, page 12-29
– 12.2.2.10.2 Source Port Range, page 12-30
– 12.2.2.10.3 NAT Between the CTM Server and OSS CORBA Client, page 12-30
• CTM server ports:
– 12.2.2.10.4 NameService Port, page 12-30
– 12.2.2.10.5 NotificationService Port, page 12-30
– 12.2.2.10.6 EMSSession Port, page 12-31
– 12.2.2.10.7 Ping Server-to-Client Port Range, page 12-31
– 12.2.2.10.8 Notification Event Port Range, page 12-32
Note You can also set CTM server port values from the CTM GateWay/CORBA Service pane
> Port Configuration tab. For more information, see 12.2.2.3 Viewing the
CTM GateWay/CORBA Service Pane, page 12-22.
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 12.2.2.10.5 NotificationService Port, page 12-30 and 12.2.2.10.6 EMSSession Port,
page 12-31.
Step 2 Enter the following command to stop the CTM server:
ctms-stop
Step 3 Disable IMR. See 12.2.2.10.9 Disabling IMR, page 12-32.

Step 4 Set the session ping port range. See 12.2.2.10.7 Ping Server-to-Client Port Range, page 12-31.
Step 5 Set the name service port. See 12.2.2.10.4 NameService Port, page 12-30.
Step 6 Set the notification service event port range. See 12.2.2.10.8 Notification Event Port Range, page 12-32.
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.

OL-20936-01 12-29
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 12.2.2.3 Viewing the CTM GateWay/CORBA Service
Pane, page 12-22.

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.
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 12.2.2.3 Viewing the CTM GateWay/CORBA
Service Pane, page 12-22.

12-30 OL-20936-01
Step 1 Stop the CTM GateWay/CORBA service. See 12.2.2.2 Starting or Stopping CTM GateWay/CORBA,
page 12-21 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 12.2.2.2 Starting or Stopping CTM GateWay/CORBA,
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
Pane, page 12-22.
Step 2 Change the value of Session Port Number to the desired value.
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
Pane, page 12-22.
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.

OL-20936-01 12-31
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 12.2.2.3 Viewing the CTM GateWay/CORBA
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.
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-32 OL-20936-01
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
12.2.2.11.2 Configuration, page 12-33.
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
Note • You can also configure CTM server ports from the CTM GateWay/CORBA Service pane > Port
Configuration tab. For more information, see 12.2.2.3 Viewing the CTM GateWay/CORBA
• 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

OL-20936-01 12-33
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 12.2.2.2 Starting or Stopping CTM
GateWay/CORBA, page 12-21 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:
• 12.2.3.1 Fault Management Interface, page 12-34
• 12.2.3.2 Process for Fault Management, page 12-38
• 12.2.3.3 Access Methods, page 12-41
• 12.2.3.4 Trap Processing, page 12-42
• 12.2.3.5 Trap Recovery, page 12-43
• 12.2.3.6 Special Case of Manager Registration, page 12-44
• 12.2.3.7 Setting Special Registration, page 12-44
• 12.2.3.8 Triggering the RTM Protocol, page 12-44
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.

12-34 OL-20936-01
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), VarBind mgmAffectedObject gives the
major (4), minor (3) 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.

OL-20936-01 12-35
Table 12-24 Health Monitor Traps (continued)

mgmMaxLoginAttemptExceeds 29203 Clear (1), major (3) VarBind mgmAffectedObject gives the
database user ID of the user who failed to
log in.
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.
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 The severity depends on the value of
error 3, 4, 5 cwmfrNetworkCommFailureCode in the
trap. Values are:
• Info (6) on error 1,
2, 6 1: ftp-session-fail
2: ftp-transfer-fail
3: net-link0-down
4: net-link1-down
5: ntsmgr-net-fail
6: nts-trap-loss

12-36 OL-20936-01
Table 12-24 Health Monitor Traps (continued)

cwmfrNetworkProcessingError 28102 • Critical (5) on The severity depends on the value of
error 7, 10, 11, 13, cwmfrNetworkProcessingErrorCode in the
16 trap. Values are:
• Warning (2) on 1: no-nw-partition
error 1, 8, 9, 12, 14 2: no-node-revision
• Info (6) on error 2,
3: no-node-subscription
3, 4, 5, 6, 15
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 The severity depends on the value of
error 3, 4, 5, 6, 7 cwmfrCwmInternalErrorCode in the trap.
Values are:
• Warning (2) on
error 1, 2 1: unknown-error
• Info (6) on error 8 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

OL-20936-01 12-37
The following table describes node traps.
Table 12-25 Node Traps

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.

12-38 OL-20936-01
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
– Name: managerRowStatus
– Type: Integer
– Value: 1
• OID: 1.3.6.1.4.1.351.120.1.1.1.9.IPADDR
– Name: managerTrapVersion

OL-20936-01 12-39
– Type: Integer
– 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
– 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
– 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

1.3.6.1.4.1.351.120.1.1.1.3.10.77.202.230 -i 2

12-40 OL-20936-01
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:
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)

OL-20936-01 12-41
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.

12-42 OL-20936-01
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.

OL-20936-01 12-43
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.

12-44 OL-20936-01
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.

OL-20936-01 12-45

12-46 OL-20936-01

92 Gateway

Uploaded by

Copyright:

Available Formats

92 Gateway

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

92 Gateway

Uploaded by

Copyright:

Available Formats

CH A P T E R 12

Managing Southbound and Northbound

12.1 How Do I Manage Southbound Interfaces?

12.1.1 Southbound Port Details

Cisco Transport Manager Release 9.2 User Guide

Table 12-1 Port Information for the ONS 15216

Port ONS 15216 Inbound or Outbound?

Table 12-2 Port Information for the ONS 15305

Port ONS 15305

Table 12-3 Port Information for CTC-Based NEs

Cisco Transport Manager Release 9.2 User Guide

Table 12-3 Port Information for CTC-Based NEs (continued)

Table 12-4 Port Information for the ONS 155xx

Port ONS 155xx Inbound or Outbound?

Table 12-5 Port Information for the MGX Voice Gateway

Port MGX Voice Gateway Inbound or Outbound?

Cisco Transport Manager Release 9.2 User Guide

Port MGX Voice Gateway Inbound or Outbound?

12.1.2 Using a Static CORBA Listener Port on the CTM Server

12.1.3 Client-Server Communication Protocols

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

Cisco Transport Manager Release 9.2 User Guide

Table 12-6 CTM Server-to-CTM Client Ports (continued)

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

Cisco Transport Manager Release 9.2 User Guide

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

Table 12-9 CTM Server-to-NE Ports

Cisco Transport Manager Release 9.2 User Guide

Table 12-9 CTM Server-to-NE Ports (continued)

Cisco Transport Manager Release 9.2 User Guide

Table 12-9 CTM Server-to-NE Ports (continued)

Table 12-10 CTM Client-to-NE Ports

Inbound or Application Cross-Launched

Cisco Transport Manager Release 9.2 User Guide

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

12.1.4 Changing the CTM Server Port

12.1.5 Changing the HTTP Server Port

Cisco Transport Manager Release 9.2 User Guide

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

Step 5 On each CTM client, locate the following line in the

Replace 8051 with the new HTTP server port.

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

12.2 How Do I Manage Northbound Interfaces?

12.2.1 Managing CTM GateWay/SNMP

Cisco Transport Manager Release 9.2 User Guide

Cisco Transport Manager Release 9.2 User Guide

Figure 12-1 CTM GateWay/SNMP Communications Architecture

Service provider's Cisco Transport Manager

ONS 15454 ONS 15454

SONET ring SDH ring

ONS 15454 ONS 15454

12.2.1.1 Starting and Stopping the CTM GateWay/SNMP Service

Cisco Transport Manager Release 9.2 User Guide

12.2.1.2 Adding and Removing a CTM GateWay/SNMPv1 or CTM GateWay/SNMPv2 Host

Table 12-12 Field Descriptions for the GateWay/SNMP Service Pane

12.2.1.3 Configuring Northbound OSS SNMPv3 Users—Optical NEs

Cisco Transport Manager Release 9.2 User Guide

• 12.2.1.3.4 Deleting an OSS SNMPv3 User, page 12-15

12.2.1.3.1 Viewing the OSS SNMPv3 Users Table