Table of Contents

Starting and Stopping CNOM Processes
Submitting Network Work Orders

Using CNOM Scripts

Common Arguments for Scripts

Using the CNOM socketDaSet Command
Using a TCP Socket
Using the CEMF CORBA Gateway

Viewing and Hiding Connection Objects

Hiding a Connection
Making a Hidden Connection Visible

Performing Data Recovery to Restore CNOM from Backup

CNOM Restore Policies

Suspending CNOM Operation During CEMF Backups

Working with the Cisco Network Order Manager

This chapter describes how to perform basic functions using CNOM. It contains the following sections:

• Starting and Stopping CNOM Processes
  
  
• Submitting Network Work Orders
  
  
• Viewing and Hiding Connection Objects
  
  
• Performing Data Recovery to Restore CNOM from Backup
  
  
• Suspending CNOM Operation During CEMF Backups
  
  

Starting and Stopping CNOM Processes

CNOM processes are started automatically when you launch CNOM. However, it is sometimes necessary to start or stop a CNOM process (for example, to correct problems or to perform troubleshooting), as follows:

Step 1   Log in as super user on the system where CNOM is running.

Step 2   Change directory to the following directory:

cd <CEMF_ROOT>/bin

Step 3   You can display a list of active CNOM processes by entering:

./cemf query

Step 4   To start a CNOM process, issue the following command (where <process_name> is the name of the process):

./sysmgrClient -x <process_name>

For example, the following command starts the CNOM gateway process:

./sysmgrClient -x ddmGateway

Step 5   To stop a CNOM process, issue the following command (where <process_name> is the name of the process):

./sysmgrClient -k <process_name>

For example, the following command stops the CNOM gateway process (ddmGateway):

./sysmgrClient -k ddmGateway

Submitting Network Work Orders

A network work order is a list of attributes or value pairs set on the processes:/ddmGateway object. At a minimum, a network work order contains the following:

• The name processes:/ddmGateway
  
  
• The name of the policy to execute
  
  
• A connection identifier (unique among connections)
  
  

Connection, service, and profile management scripts require you to set other attributes. The attributes you set depend on the policy you invoke and on the required features of the policy.

When a network work order appears as arguments to a CNOM command such as socketDaSet, you must supply appropriate escape characters to prevent the shell from interpreting the parentheses.

If a network work order command is generated in a different language (for example, a perl script), you must use additional escape characters:

$command = "/opt/cemf/bin/socketDaSet processes:/ddmGateway workOrder:DDMWorkOrder.connectionIdentifier \"(@ARGV[0])\" workOrder:DDMWorkOrder.workOrderPolicy \"(getATMConnectionData)\" workOrder:DDM.finalWorkOrder \"()\" ";

system($command);

You can submit a network work order to CNOM for processing in any of the following ways:

• Using CNOM Scripts
  
  
• Using the CNOM socketDaSet Command
  
  
• Using a TCP Socket
  
  
• Using the CEMF CORBA Gateway
  
  
• Using the C++ API
  
  

You can use any or all of these methods on a CNOM system. Network work orders are processed asynchronously, which means that new network work orders may be submitted before previous orders are complete.

Note   By default, all CNOM policies call socketDaSet. If you create your own policy, make sure the policy includes a call to socketDaSet.

Using CNOM Scripts

CNOM provides several scripts that you can use to invoke policies (see Table E-1). CNOM scripts are stored in the directory <CEMF_ROOT>/bin.

To run a script, simply enter the name of the script and its command-line arguments at the CEMF command line. The script's command-line arguments are passed to the policy as attribute values. In most cases. each argument corresponds to one of the work-order attributes (workOrder:DDMWorkOrder.attrb) expected by the policy.

To determine a script's command-line arguments, enter the name of the script in the command line. The system displays the command usage, which includes a list of expected work-order attributes and command options. Following is the command usage for the create_PPPService_fromProfile script:

./create_PPPService_fromProfile Usage: create_PPPService_fromProfile <NRPContainmentPath> <ProfileName> <Name of service> [-noSave|[-syslog] -save <file_path_name>]

The arguments displayed in the command usage correspond to the work-order attributes (workOrder:DDMWorkOrder.attrb) expected by the policy. The value you specify for an argument is assigned to that work-order attribute. For example, <NRPContainmentPath> defines the value of the workOrder:DDMWorkOrder.NRPContainmentPath attribute, <ProfileName> defines the value for ...ProfileContainmentPath, and <Name of Service> defines ...serviceName.

For detailed information about command-line arguments, see the documentation for that element manager (CDM or SCM). The arguments correspond to fields in the GUI windows.

---

Note   When you enter the command-line arguments, be sure to specify the arguments in the correct order, because each value is written to the attribute expected in that position.

---

Common Arguments for Scripts

Most CNOM scripts contain options to perform common functions, such as hiding connection objects and saving data recovery information to the system log file. To set CNOM to perform a particular function during the execution of a policy, simply include the appropriate option when you run the script to invoke the policy. For example, the following script creates a bridging service from command-line input and saves information about the service to the system log file:

./create_B_service ... -syslog

Table 3-1 describes the command-line options you can use when you run a CNOM script. Not all CNOM scripts support all options.

Using the CNOM socketDaSet Command

The CNOM command socketDaSet submits its arguments in the form of an ASCII message to the ddmGateway TCP socket interface on a specified CEMF server.

Use the socketDaSet command to:

• Submit network orders from a remote machine
  
  
• Test connectivity of remote systems to a CEMF server running CNOM
  
  
• Prototype in integration projects
  
  

When you use socketDaSet, you provide a series of work-order attributes and their values to the ddmGateway process. Enclose each attribute value in parentheses and use an escape character (such as quotation marks) to prevent the shell from interpreting the parentheses.

For example, the following input to socketDaSet invokes the policy MakeConnectionVisible with the necessary attributes. The policy makes visible the connection whose connection ID is CONN-16.

Using a TCP Socket

To submit network work orders directly to the ddmGateway process:

1. Send the orders to a specified port (10531, by default) on the machine on which CNOM is running. The network order has the same form as the arguments to socketDaSet.

2. The ddmGateway process starts processing text when it receives a new line character.

3. Responses are sent back to the calling process on the return channel of the socket on which the network order was submitted.

Using the CEMF CORBA Gateway

The CEMF CORBA Gateway provides a way to set attributes on objects in CEMF. You can use it to set network order attributes on processes:/ddmGateway. To build a client that can access CEMF services, use the CEMF CORBA Gateway Developer Kit.

Note   For projects involving integration of CNOM with other systems, use the TCP socket interface or the CEMF CORBA Gateway.

Viewing and Hiding Connection Objects

By default, connection objects (which represent connections in CNOM) are visible in the connectionObjects view, and in other views as defined through CEMF (for example, componentManaged). However, you can improve system performance by hiding connection objects in these views, as described in the sections that follow.

Note   If you are running CDM, also see the "Adding PVC Objects to the SubtendPVC View" section for information about how CNOM hides PVC objects to improve system performance, and for instructions on how to make these objects visible (although it is not recommended.)

CNOM provides the following policies, primitives, and scripts for hiding and displaying connections:

• MakeConnectionVisible—This policy invokes the MakeConnectionVisible primitive to make a hidden connection visible in CNOM views. The make_visible script invokes this policy.
  
  
• MakeConnectionInvisible—This policy invokes the MakeConnectionInvisible primitive to hide a connection object in CNOM views. The make_visible script with -hide option invokes this policy.
  
  
• connect scripts all contain a -hide option that you can include in the command line to hide the connection object created by the script.
  
  

Hiding a Connection

You can improve system performance by hiding connection objects in the connectionObjects view and in other views, such as componentManaged, as defined through CEMF. To do so:

• Include the -hide option when you run the connect script to create the connection. CNOM creates the connection object but does not display it. (By default, all created connection objects are stored in the connectionObjectsStore view, which is a hidden view.)
  
  
• Run the following script (where <connection_ID> is the ID of the connection you want to hide). To make a connection visible again, run the script without -hide.
  
  
./make_visible <connection_ID> -hide

Making a Hidden Connection Visible

Although it is not recommended, it is sometimes necessary to display a hidden connection (for example, to modify the connection). To make a hidden connection visible in connectionObjects and other views, run the following script from a CEMF shell (where <connection_ID> is the ID of the connection to make visible):

Performing Data Recovery to Restore CNOM from Backup

To ensure that you can easily restore your configuration after a system failure, CNOM provides a data recovery feature that logs all network orders that modify the CNOM configuration (for example, creating and deleting VCs and services). In the event of a system failure, the system replays those network orders in order to re-create the CNOM configuration as it existed before the failure.

If the CNOM system fails and you must restore the CEMF database from backup, you lose all of the configuration changes between the time of the last backup and the time of the system failure. For example, if you back up your CEMF data each night at 12 a.m. and experience a system failure at 12 p.m. the following day, you lose any of the configuration changes made between 12 a.m. and 12 p.m. This could result in such inconsistencies as VCs that exist on devices but not in the element manager, or services that exist in CEMF but not on the device.

Note   After you restore the CEMF database from backup, run the script getRestoreWO to restore the CNOM configuration.

The getRestoreWO script re-creates the configuration by re-executing each of the commands in the <CEMF_ROOT>/logs/connectionsLog.log file. When you run the script, specify the date and time to restore the data from. For example, if you back up the CEMF database each night at 12 a.m. and a system failure occurs at 12 p.m., you would want the script to re-execute the commands issued between midnight and noon.

The format of the command for invoking the getRestoreWO script is as follows:

The getRestoreWO script uses the restore and clear policies described in Table 3-2 to re-create the configuration. You can invoke these policies without using the getRestoreWO script if you want (for example, for troubleshooting or for specific configuration needs); however, you should fully understand what you are doing before you attempt it.

---

Caution   Cisco NRP Capacity Statistics might display incorrect values after data recovery. Run the NRP_statistics_fix script to set up valid NRP Capacity Statistics data for all NRPs in the system.

---

---

Note   See the "Updating CNOM: Data Synchronization" section for information about data synchronization, a process that updates the CNOM configuration with information about objects created and deleted outside of CNOM (for example, through an element manager like SCM or CDM).

---

CNOM Restore Policies

Table 3-2 lists the policies CNOM runs to perform data recovery after a system failure. These policies are invoked by the getRestoreWO script.

Suspending CNOM Operation During CEMF Backups

To back up CEMF data while CNOM is running, CNOM provides two commands for suspending and resuming processing:

• suspendOperation—Halts CNOM processing. When you issue this command, CNOM stops accepting new work orders and finishes processing all in-progress work orders. If you attempt to run a CNOM script while processing is suspended, a message appears indicating that the gateway is suspended.
  
  
• resumeOperation—Restarts CNOM processing after a CEMF backup.
  
  

---

Note   If you perform a CEMF backup without first suspending CNOM operation, CNOM scripts fail without displaying a message that the gateway is suspended.

---

To back up CEMF data while CNOM is running, perform the steps in this procedure:

Step 1   Log in as root on the system on which you want to back up CEMF data, and open a CEMF shell:

cd <CEMF_ROOT>/bin ./cemf shell

Step 2   Suspend CNOM operation and start the CEMF backup. The system waits until all in-progress work orders are processed before starting the backup.

./suspendOperation ./cemf backup

Step 3   When the backup is complete, resume CNOM operation:

./resumeOperation

Posted: Sun Sep 29 05:32:26 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.