Table of Contents

Working with the Cisco Network Order Manager

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

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:

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 \"()\" ";


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

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.

Table 3-1: Command-Line Options for Scripts
Option Description


Hides the connection object created by the connect script. The connection is hidden in the connectionObjects view to improve system performance. To make a hidden connection visible, run the script make_visible <connection_ID>.


Tells the system not to save information about the object for data recovery. By default, CNOM saves data recovery information for each created object to use to re-create the CNOM configuration in case of a system failure. If you use this option, the object cannot be recovered after a system failure.

-save <file_path_name>

Tells the system to save information about the created object to the specified file, which must already exist. The CNOM data recovery feature uses this information to re-create the object after a CEMF database restore. Use this option if you want to save data recovery information to a file other than the default, which is <CEMF_ROOT>/logs/connectionsLog.log.

Note   Make sure the specified file exists and that it has read/write privileges set for root. Also, make sure that there is enough free disk space to store information about the object. Otherwise, the following results occur (in all cases an error message is returned):


Saves information about the created object to the system log file. The CNOM data recovery feature uses this information to re-create the object after a system failure.

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:

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.

    /opt/cemf/bin/socketDaSet localhost 10531 processes:/ddmGateway workorder:DDMWorkOrder:connectionIdentifier "(CONN-16)" workorder:DDMWorkOrder:workOrderPolicy "(MakeConnectionVisible)" workorder:DDMWorkOrder:finalWorkOrder "()"

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:

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:

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

    ./make_visible <connection_ID>

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:

    ./getRestoreWO [-range {start-range | start} {end-range | end} | -time {start-time | start} {end-time | end}] <hostname> <socket-portno> [-syslog] <logFileName> <outputFileName>

getRestoreWO option Description

-range {start-range | start}
{end-range | end}

The range of configuration commands to re-execute for data recovery.

  • start and end—Keywords that specify the start and end of the connectionsLog.log file, respectively.

  • start-range and end-range—The date and time commands were issued. The system re-executes commands issued during this time. Use the format described in start-time and end-time below.

For example, -range start end re-executes all of the commands in the file, and -range "11/05/2001 00:00:00" end re-executes commands issued between 12 a.m. on November 5, 2001, and the end of the file.

-time {start-time | start} {end-time | end}

The time period during which commands were issued. The system re-executes configuration commands issued during this time period.

  • start and end—Keywords that specify the start and end of the connectionsLog.log file, respectively.

  • start-time and end-time—The date and time commands were issued. The system re-executes commands issued during this time. Use the format "DD/MM/YYYY HH:MM:SS" (where for HH:MM:SS, 00:00:00 is midnight).

For example, -time start end re-executes all of the configuration commands issued between the last CEMF backup and the system failure; and -time "01/01/2001 00:00:00" "02/01/2001 00:00:00" re-executes configuration commands entered between 12 a.m. January 1, 2001 and 12 a.m. January 2, 2001.


The name of the CNOM system whose configuration you are restoring.


The port number of the socket.


This option tells the command (getRestoreWO) that the following log file (<logFileName>) is a system log file. Use the option when restoring WO from a system log file.


The name of the log file containing the configuration commands to execute to restore the configuration to the state it was in before the system failure. The default is <CEMF_ROOT>/logs/connectionsLog.log.


The name of the file in which the system saves summary information for data recovery.

To re-create specific parts of the configuration, you can open the log file in a text editor (such as vi or emacs) and cut and paste specific commands from the file to the CEMF command line. Note that this might be useful for setting up test configurations or for troubleshooting.

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.

Table 3-2: CNOM Restore Policies
Policy Used to Create Connection... Policy Used to Restore Connection...
SCM Policies





CDM Policies





Suspending CNOM Operation During CEMF Backups

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

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:


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.