Document ID: 47380 | PDF Downloads
|
FeedbackIntroduction
This document explains how the Cisco WAN Manager (CWM) core is started and what CWM processes make up the core. Use extreme care tuning your CWM and only when TAC recommends.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on the software and hardware versions:
-
CWM 11.0
-
CWM 12.0
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
Start CWM Core
Environment
All CWM processes require the right environment. This one is configured by svplus.cshrc, startup scripts and configuration files. Changing the information affects the behavior of the CWM server. Any modification can cause serious problems.
Startup Sequence
Start the CWM server using CWM scripts. The following describes the main function of the startup sequence:
-
If CWM runs for the first time, check if Corba is running. If not, starts it, and then initializes the database.
-
Launch the scripts start_SV+
The start_SV+ performs these main functions:
-
Launch chkcore if not running;
-
Check if Corba is running; if not, starts it.
-
Starts watchdog process.
-
Starts iosmgr process.
At this time, all the CWM processes are running. Watchog is the executable that actually launches and controls the CWM core.
Processes not Controlled by Watchdog
After CWM installation, the three first set of processes are running. These processes serve the CWM core:
For CWM 11.0:
| Informix | Process | /usr/users/informix92/bin/oninit |
| Description | This is the RDBMS used by CWM. It's started by /etc/rc3.d/S98init_db | |
| Config | /usr/users/informix/etc/onconfig | |
| Log | /usr/users/informix/online.log | |
| Corba | Process | /usr/users/svplus/scripts/runorbixd /usr/users/corba/bin/orbixd |
| Description | Corba is a technology used by CWM for interprocess communication. Processes are registered to the Corba bus. One can check the registration using lsit command. psit lists the running processes.Corba is implemented here with the Orbix package. runorbixd is a watchdog process which cares of starting and restarting the main orbixd process. runorbixd is launched by /etc/rc3.d/S99cwmorbixd. | |
| Config | /usr/users/corba/config/common.cfg | |
| CWM web | Process | /usr/users/svplus/webServer/bin/httpd |
| Description | This web engine is to serve CWM java clients. It is launched by /etc/rc3.d/S99cwmhttpd | |
| Config | /usr/users/svplus/webServer/conf | |
| Log | /usr/users/svplus/webServer/Logs |
Differences with CWM 12.0:
In 12.0, the difference is only with Corba. Because Orbix 3.3 is end-of-life, CWM development replaced it with new Orbix 2000 (Orbix E2A ASP). All GUIs communicate with Servers using CORBA. SCM modules (Control server and Collection server) use CORBA to communicate with each other.orbixd daemon process is replaced by three processes (Use the psg bin.it command to list them - lsit and psit are no longer available):
moonfish% psg bin.it 22651 ? S 0:03 /usr/users/orbix/asp/5.1/bin/itlocator -ORBdomain_name 22652 ? S 18:05 /usr/users/orbix/asp/5.1/bin/itnode_daemon -ORBdomain_n 22659 ? S 0:39 /usr/users/orbix/asp/5.1/bin/itnaming -ORBdomain_name c
These three processes must be running for CWM operations. If not, the user can re-initialize the Orbix doing the following: Stop the core and orbix. As root user, run the conf_orbix.csh script to reconfigure orbix with the domain name. For example:
# stoporbix2000 # conf_orbix.csh cisco.com
Replace cisco.com with the domain name that you want, and start CWM core.
Caution: Informix, Orbix, and CWM web processes are independent from the CWM
core. To stop them, you must use a manual operation or a system reboot.
Watchdog Process
The main CWM control process is to watchog. As explained above, the executable is set off with start_SV+ script. Watchdog allows processes to be started/terminated in the proper sequence. It makes sure all processes are running well and if needed, it restarts processes in case of crash.
Watchdog uses four configuration files:
-
watchdog.conf: designed to save all the parameters that are used to control processes
-
process.conf: lists all the CWM processes that watchdog needs to manage with their options
-
startup.conf specifies the startup dependency
-
shutdown.conf: specifies the shutdown dependencies among CWM processes
Here is a copy of process.conf for version 11.0:
tftpmgr on on . tftpmgr cwmsmap on on . cwmsmap -b 9000 -v /usr/users/svplus/log/cwmsmap.log eventd on on . eventd -l 4 -b 9000 configd on off . configd -b 9000 CWMGateway on on . CWMGateway extractd on on . extractd sctDaemon on off . sctDaemon -v sctd.log topod on on . topod -V 4 snmpcomm on off . snmpcomm cwmftpd on on . cwmftpd dmd on on . dmd databroker on on . databroker -b 9000 sdbroker on on . sdbroker xdbroker on on . xdbroker vnd on on . vnd emsd on on . emsd -b 9000 emd on on . emd -b 9000 csridd on off . csridd rtm on on . rtm -b 9000 -l 7200 -s 7000 cmgrd on on . cmgrd -c private -i 5 xcmgrd on on . xcmgrd svmond on on . svmond CwmGs on on . CwmGs cmsvr on on . cmsvr TopoServer on off . TopoServer LogServer on off . LogServer DiagServer on off . DiagServer scmctrlsvr on on . scmctrlsvr AuditLogger on off . AuditLogger scmcollsvr on on . scmcollsvr nickfish spwatchdog on off . spwatchdog nickfish MasterAgent on off . MasterAgent -d -tcpany -pkt_size 4096 -log_file -log_format 1 -log_nostdout -log_nostderr LineProxy on off . LineProxy -v ./config/SNMPProxy.conf PortProxy on off . PortProxy -v ./config/SNMPProxy.conf ConnProxy1 on off . ConnProxy1 -d ConnProxy1.log ./config/SNMPProxy.conf ConnProxy2 on off . ConnProxy2 -d ConnProxy2.log ./config/SNMPProxy.conf ConnProxy3 on off . ConnProxy3 -d ConnProxy3.log ./config/SNMPProxy.conf CardProxy on off . CardProxy -v ./config/SNMPProxy.conf DiagProxy on off . DiagProxy -v ./config/SNMPProxy.conf RtmProxy on off . RtmProxy -v cdparrsd on off . cdparrsd -maxsets 1 -port 8163 -logfile cdparrsd.log cmparrsd on off . cmparrsd -maxsets 3 -port 8164 -logfile cmparrsd.log dgparrsd on off . dgparrsd -maxsets 1 -port 8165 -logfile dgparrsd.log lnparrsd on off . lnparrsd -maxsets 1 -port 8166 -logfile lnparrsd.log pparrsd on off . pparrsd -maxsets 1 -port 8167 -logfile pparrsd.log rtmparrsd on off . rtmparrsd -maxsets 1 -port 8168 -logfile rtmparrsd.log
This set of processes are building up the CWM core. We can divide them into sub-systems that each specificy responsibility, for example Topology, Statistics, and Service agent. You must trust the watchdog process to keep all these processes up and running. Some processes on this list can also spawn sub-processes such as topod, part of the Topology subsystem responsible for discovering the network, fork three clients such as linktopoc, ilmitopoc and filetopoc. Again, you must trust parent processes like topod to restart the clients in case of process crash.
Description of Each CWM Subsystem
These sections describe all of the CWM processes. They are sorted by functionality. If available, the configuration and log files are named.
Topology Subsystem
| topod | Description | This is the main daemon managing the network discovery and in particular the network topology. It spawns four clients: svmain, filetopoc, ILMItopoc and filetopoc. topod reads also network.conf to initiate the network discovery. |
| Config | Topod.conf | |
| Log | topod.log | |
| svmain | Description | This is a protocol dependent process doing the interface between the topology subsystem and the switches running SWSW. It talks to them using the proprietary Stratacom protocol. |
| Log | svmain(x).log - x is a number | |
| linktopoc | Description | This process is responsible for the Autoroute network discovery |
| Log | linktopoc.log | |
| ILMITopoc | Description | This process does the PNNI network discovery |
| Config | ILMITopoc.conf | |
| Log | ILMITopoc.log | |
| filetopoc | Description | This process manages the standalone nodes eg. mgx8250 |
| Log | filetopoc.log | |
| TopoServer | Description | It serves the GUI for topology information |
| Log | filetopoc.log | |
| LogServer | Description | It’s used for logging messages from Topology guis |
| Log | LogServer.logL |
Protocol Dependent Processes
| svmain | Description | This is a protocol dependent process doing the interface between the topology subsystem and the switches running SWSW. It talks to them using the proprietary Stratacom protocol. |
| Log | svmain(x).log - x is a number | |
| tftpmgr | Description | This process spawns tftpchild processes that serve all the tftp connections needed by CWM eg. for configuration files download |
| Config | tftpmgr.config | |
| Log | svmain(x).log - x is a number | |
| snmpcomm | Description | This process performs all the snmp requests asked by upper processes like cmgrd, ILMITopoc, etc |
| Config | snmpcomm.conf | |
| Log | snmpcomm.log | |
| cwmftpd | Description | This process is used for ftp transfer mgx config files and between CWMs |
| Config | cwmftpd.conf | |
| Log | cwmftpd.log cwmftpd.request_log |
Equipment Management
| emsd | Process | This daemon gets broadcast from topod about new SWSW based switches that need to be discovered. This discovery job will be accomplished by emsd's clients ie. emsc. So emsd forks emsc processes and manages them. |
| Config | emsd.conf | |
| Log | emsd.log | |
| emsc | Description | Process in charge of discovering IGX and BPX nodes ie. inventory, configuration, etc. |
| Log | emsc(x).yxz.log - where x is the child number and xyz a number. | |
| emd | Description | This daemon gets broadcasts from topod about new MGX switches that need to be discovered. This disocvery job will be accomplished by emd's clients ie. emc and ooemc. So emd forks emc and oomc processes and manages them |
| Config | emd.conf | |
| Log | emd.log | |
| emc | Description | process in charge of discoverying MGX 8220, 8250/8850 with pxm1. |
| Log | emc(x).xyz.log where x is the child number and xyz a number | |
| ooemc | Description | Process in charge of discoverying PNNI nodes |
| Log | ooemc(x).xyz.log where x is the child number and xyz a number |
Connection Syncup
| databroker | Process | As sdbroker and xdbroker processes, databroker is doing the connection joining to build the end-to-end connection table ie. user_connection. |
| Config | dbroker.conf, dmd.conf | |
| Log | dbroker.xyz.log, dbrokerMsg.xyz.log where xyz is a number. .DBKR_SYNCHUP_MESSAGE | |
| sdbroker | Description | sdbroker is doing the connection joining to build the end-to-end connection table ie. user_connection. It is the new version (new coding) of old databroker. This latter is gone in 12.0 |
| Config | sdbroker.conf, dmd.conf | |
| Log | sdbroker.xyzlog, sdbrokerMsg.xyz.log, .DBKR_SYNCHUP_MESSAGE | |
| xdbroker | Description | xdbroker is doing the connection joining to build the end-to-end connection table for xpvc. |
| Config | xdbroker.conf, dmd.conf | |
| Log | xdbroker.xyz.log, xdbrokerMsg.xyz.log, .XDBKR_SYNCHUP_MESSAGE | |
| dmd | Description | this process dispatches messages from element managers (emc, ooemc, emsc) to the databroker processes ie. databroker, sdbroker and xdbroker. |
| Log | dmd.log |
Alarm Subsystem
| eventd | Process | eventd has the charge of formating events from BPX and IGX into standard snmp traps and then forward them to alarm clients |
| Config | eventd.conf | |
| Log | eventd.log | |
| rtm | Description | This process registers itself to newly discovred MGXs (gets switch info from topod) in order to get later all snmp traps generated by those switches. This process is replaced bynts in 12.0 |
| Config | rtm.conf | |
| Log | rtm.log |
Connection Management
| cmgrd | Process | The main functionality of cmgrd is to accept user requests from the clients (ConnProxy/CmServer) to add, modify and delete the connections on the switch. Most of the interaction with the switch is using SNMP. The only exception being RPM on MGX 8250 which does not have SNMP support. |
| Config | cmgrd.conf | |
| Log | cmgrd.log | |
| xcmgrd | Description | xcmgrd is a backend process which accepts provisioning requests which are across networks (AR, PNN etc), determines the connection path within a network and sends these individual network connection requests to cmgrd |
| Config | xcmgrd.conf | |
| Log | xcmgrd.log | |
| iosmgr | Description | Process responsible for handling the CLI like commands to the switch to provision connections. RPM on MGX is provisioned using this process. |
| Config | iosmgr.conf | |
| Log | iosmgr.log | |
| cmsvr | Description | CmServer provides an interface to CmGUI to retrieve information about connections and alarms. It acts a client to cmgrd for provisioning connections and to databroker/xdbroker for alarms and other events. |
| Config | xdbroker.conf, dmd.conf | |
| Log | cmsvr.log |
Statics Collection Subsytem
| scmctrlsvr | Process | SCM Control Server. This is a server that serves the Java GUI for controlling data collection. For example enabling/disabling Statistics Data and starting/stopping data collection. The server will be run on the same host as the CWM, and will use the CWM database for storing the SCM Metadata and the Enable List for all the nodes. | |
| Config | scmctrlsvr.conf | ||
| Log | scmctrlsvr.log | ||
| scmcollsvr | Description | SCM Collection Server. This is a server that performs the data collection from the nodes. It will be distributed to various hosts and it will receive requests from the SCM Control Server to start or stop data collection from a node. Once collecting, the SCM Collection Server will be independent of the SCM Control Server. | |
| Config | scmcollsvr.conf | ||
| Log | scmcollsvr.log | ||
| spwatchdog | Description | This process is responsible of managing two SCM processes spawned by this watchdog ie. statsager and statsparser | |
| Log | statsparserwd.log | ||
| statsager | Description | SCM Stats Ager. This removes old data from database and file system. | |
| Config | agerconfig.stats | ||
| Log | statsager.log | ||
| statsparser | Description | SCM Stats Parser. This is a program that parses the Statistics Data collected by the SCM Collection Server and writes the data into the SCM Stats database. There will be one SCM Stats Parser associated with one SCM Collection Server. | |
| Config | parserconfig.stats | ||
| Log | statsparser.log.<xyz> where xyz is a number | ||
CWM Gateway
| CWMGateway | Process | This new process will be the communication gateway for CWM and processes belonging to one CWM to communicate with processes belonging to another CWM using this gateway. |
| Config | CWMGateway.conf | |
| Log | CWMGateway.log | |
| extractd | Description | Extract data from remote CWM station to local CWM station. Request composes of list of tablename. Needs CWMGateway and cwmftpd |
| Config | extractd.conf, tablesync.conf | |
| Log | extractd.log |
Other Processes
| configd | Description | Configd transfers the configuration files form the BPX/IGX nodes. This file transfer takes place using a proprietary protocol. |
| Log | configd.log | |
| cwmsmap | Description | CWM socket mapper |
| Log | cwmsmap.log | |
| sctDaemon | Description | This daemon serves the SCT management and amongst others does SCTs discovery |
| Config | sctd.conf | |
| Log | .SCT_SYNCUP_MESSAGE | |
| vnd | Description | Daemon that handles VSI interfaces on SWSW |
| Config | vnd.conf | |
| Log | vnd.log | |
| csridd | Description | Config Save/Restore & Image Download are serviced by one common process - csridd |
| Config | csridd.conf | |
| Log | csridd.log | |
| svmond | Description | SV+ health monitor process - check system resources used by CWM |
| Config | svmond.conf | |
| Log | svmond.log | |
| CwmGs | Description | CwmGs provides services to interact with the Security database and propagate data to other CWM workstations |
| Config | CwmGs.conf | |
| Log | CwmGs.log | |
| DiagServer | Description | Serves connection diagnostic |
| Log | DiagServer.log | |
| AuditLogger | Description | It serves the Audit Trail feature |
| Config | AuditLogger.conf | |
| Log | AuditLogger.log |
Service Agent
| MasterAgent | Description | Master Agent Listens on UDP Port Sends Request to relevent Sub Agent |
| Config | Snmpd.cnf | |
| Log | Snmpd.log | |
| ConnProxy | Description | Connection Proxy is CWM Process Responsible for Connection Provisioning using SNMP Interface |
| Config | SNMPProxy.conf | |
| Log | ConnProxy#.log (# - no.) | |
| PortProxy | Description | Port Proxy is a CWM Process that provides Port Level network Management that includes Port Configuration, Port Status and Port level operations |
| Config | SNMPProxy.conf | |
| Log | PortProxy.log | |
| LineProxy | Description | Line Proxy is used to do line level operations such as upline, downline, etc |
| Config | SNMPProxy.conf | |
| Log | LineProxy.log | |
| CardProxy | Description | Card Proxy is an Snmp Based Application to do Card level network Management |
| Config | SNMPProxy.conf | |
| Log | CardProxy.log | |
| DiagProxy | Description | Diag Proxy is a CWM Process which was designed for diagnostic supports like Bert (Bit Error Rate Test) applications |
| Config | SNMPProxy.conf | |
| Log | DiagProxy.log | |
| RtmProxy | Description | RtmProxy is an interface for customer applications to get traps from all switches(all platforms) managed by CWM |
| Config | SNMPProxy.conf | |
| Log | RtmProxy.log | |
| cdparrsd cmparrsd dgparrsd lnparrsd pparrsd rtmparrsd | Description | These processes forward requests from MasterAgent to its clients |
| Log | cdparrsd.log cmparrsd.log dgparrsd.log lnparrsd.log pparrsd.log rtmparrsd.log |
Differences with CWM 12.0
These are the main process changes introduced with 12.0:
| Topology subsystem | mpgd: serves multipeer group |
| Protocol dependent processes | No changes |
| Equipment management | Multi-threaded emc for faster & more reliable MGX1/Axis syncup |
| Connection syncup |
|
| Alarm subsystem | rtm is replaced by nts |
| Connection management | Multi-threaded cmgrd for faster provisioning |
| Statistics collection subsystem |
A SCM gateway has been introduced with the new SSM (Standalone
Statistic Manager). There are four processes part of that gateway:
|
| CWM Gateway | No changes |
| Other processes | New procesesses part of CWM 12.0 core: cfupload parity RmiRegistry |
| Service Agent | ErrorProxy: SNMP provisioning error information |
Related Information
- Cisco WAN Manager Technical Support & Documentation
- Cisco WAN Manager Documentation
- Cisco WAN Manager Patches
- Technical Support - Cisco Systems
| Updated: Jan 31, 2006 | Document ID: 47380 |