Guest

Cisco WAN Manager

Cisco WAN Manager Processes

Document ID: 47380

Updated: Jan 31, 2006

   Print

Introduction

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 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
  • databroker is definitively removed from the process list. sdbroker takes fully over
  • Distributed DMD/sdbroker for faster and more reliable overall 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:
  • SCMGateway
  • SSMExtractd
  • SSPExtractd
  • SSCExtractd
Configuration file is SCMGateway.conf and log files are process-name.log. Along with SSM comes Wandest application. This one is aimed to copy part of the CWM database onto the SSM server. On CWM runs wdserver process and on SSM runs wdclient. Multi-process stats parsing
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

Updated: Jan 31, 2006
Document ID: 47380