|
This chapter describes how to perform basic functions using CNOM. It contains the following sections:
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
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 \"()\" ";
system($command);
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. |
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. |
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.
Option | Description |
---|---|
| Hides the connection object created by the |
| 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. |
| 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 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. |
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 "()"
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.
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. |
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.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:
-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.)<
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
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>
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 |
---|---|
| The range of configuration commands to re-execute for data recovery.
For example, |
| The time period during which commands were issued. The system re-executes configuration commands issued during this time period.
For example, |
<hostname> | The name of the CNOM system whose configuration you are restoring. |
<socket-portno> | The port number of the socket. |
[-syslog] | 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. |
<logFileName> | 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 |
<outputFileName> | 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). |
Table 3-2 lists the policies CNOM runs to perform data recovery after a system failure. These policies are invoked by the getRestoreWO
script.
Policy Used to Create Connection... | Policy Used to Restore Connection... |
---|---|
SCM Policies | |
| |
| |
CDM Policies | |
| |
| |
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.