OSS RC : learning by doing (new beginning)

CIF Self Management: #/opt/ericsson/nms_cif_sm/bin/smtool [option] [MC] Option [stop|start|online|offline|coldrestart|warmrestart|cancel|config|help|exit] i.e : #./smtool online Activity Manager, #./smtool list Log : Log [-print] [-type error|event|command|nwstat|security] [-number number] [-host host] [-filter filterfile[:number]] i.e #/opt/ericsson/nms_cif_sm/bin/log type error number 10 |more #./log filter myfilterfile.txt:2 (means: second row of myfilterfile.txt as filter criteria) See errors as they come in, use: #/opt/ericsson/nms_cif_sm/bin/newLogRecordsViewer.sh Openfusion #cd /opt/inprise/openfusion/bin/ Environment file: # ls la .javaenv Check version: #./version Start manager: #./manager

Log is on duty: administrative state is unlocked Log will never become full : wrap Log full: halt (until persistent storage is exhausted) Err&system log: #/opt/inprise/openfusion/domains/OpenFusion/localhost/LogService/data/log.dat TMOS adapter (MC) to handle old TMOS applications. Step to create user on OSS system: 1. creates new UNIX login account 2. creates UNIX home directory 3. Requests password for new account 4. adds user to TSS and assigns roles. Adding OSS User Account (as root): #oss_adduser.sh c Aghiel Prayogo aghiel sys_adm In order to create site specific categories, there are three files/directories have to be present in /opt/ericsson/sck/data/user_templates: .dtwmrc -> background menu template. Parsed by update_menus.sh to create the live template. .roles -> the list of roles the belongs to per default. (dir) -> a set of files and directories required to run OSS. When installing a new SCK, default categories may be updated, so in order to keep category maintaince to a minimum, try to use solftlinks when its possible. Give user access to Telnet Gateway (TGw): #emt_tgw_useradm_cli create user aghiel pw password TGw only applicable with AXE based NE Creates TGw access account in TSS Password Service TGw consults the Password Service when user logs in using WinFIOL Check given user access:

#pwAdmin list|grep Telnet_Gateway #update_users.sh -> modify user #oss_delusers.sh -> delete user Authority Admin: #targetAdmin #targetgroupAdmin #activityAdmin #activitySetAdmin #userAdmin #roleAdmin #timeProfileAdmin #typeAdmin Password Administration: Creating a password entry using pwAdmin only stores the password in the password service. Setting the password in the corresponding system has to be done as a separate measure,outside the control of pwAdmin. CORBA Servers in TSS: TSSAuthServer #/opt/ericsson/nms_tss_server/bin/startAuthorityServer.sh TSSBasicServer #/opt/ericsson/nms_tss_server/bin/startBasicServer.sh TSSPWServer #/opt/ericsson/nms_tss_server/bin/startPasswordServer.sh The server are started in the following order: Basic Service > Password Server > Authority Server

TSS Server run as user nmsadm TSS Manage Component(MC) is started automatically at system start by the CIF SM & GUI. Sybase Open Client: When the Authority Server logs into the Sybase database, it performs the following steps: 1. TSSAuthServer fetches the userid from the parameter TSSDatabaseUser. 2. TSSAuthServer fetches the TSS data source name from the parameter TSSDataSourceName (the Sybase server name). 3. TSSAuthServer fetches the password from TSSPWServer, using the parameter TSSDataSourceName and TSSDataSourceType as system and TSSDataBaseUser as account. 4. TSS logs into Sybase using the Sybase Open Client interface Fault Management System External Access -> handle communication between OSS and Network Elements, CORBA monitors processes in FM, Information Model Handler (IMH), as well as CIF SM and TSS. FM uses fmadb_1_1 and imhdb database. imhdb -> record summary of the alarm. Information Model Instance Manager (IMIM) is used to update the IMH with FM Specific information, i.e Alarm Supervision On/Off, heartbeat Supervision On/Off, etc. IMH is synchronized with information from the Network Resource Model via Information Model Synchronization (IMS). Synchronization between IMH and NRM is handled by IMS. This is done automatically by notification but fm_ims process can be restarted e.g after loading new configuration parameters (via PAS) from the CLI: imscli Alarm flow example AXE to OSS RC: Alarm > EAM > AXE alarm Manager > FM Kernel > Alarm Viewer FMA: Fault Management Adaptation AXE alarm Manager (AM): fma_axeadaptation, fma_axeadaptation_1, fma_axeadaptation_APG40 AM uses a translation map (FMA_TRANSLATE.AXE) to translate the AXE specific printout into Alarm Records, the FM internal format, as well as forward the alarm record into the FM kernerl through the FMA Interface, FMAI.

Three major cases of alarm adaptation in OSS-RC: 1. AXE alarm coming to the OSS and are handled by the AXE (or telnet adaptation in the case of APG40) AAU. 2. SNMP trap coming from NEs that are supervised via SNMP. They are mostly handled by SNMP SMT 3. TMOS internal and CIF/SM internal errors are handled by the OSS-RC AAU. SNMP Alarm Adaptation the SUPI interface: SNMP traps, whether coming from the SNMP SMT or the CORBA IRP Manager are forwarded through the SUPI interface and collected by the fma_supiproxy. This process translates the traps according to translation maps and forwards the alarm information to the FM kernel. Communication Superfision of SNMP NEs is performed by connecting to the SNMP Agent for the NE in question and issuing an SNP get request to get the value of a MIB-variable. If snmpget fails, communication status will be set to down. This will be cleared upon the next successful snmpget request. The comm. Superfision thread does the following: 1. retrieves the TIMEOUT parameter 2. Issues an snmpget request towards the agent. 3. sets communication status to down if request fail 4. sets communication status tp up if down and request succeeds Performing Synchronization of SNMP NEs The agent synchronization thread does the following: 1. the FM action SYNC is sent by SNMP SMT to agents OpQueue 2. the thread actionhandler assigned for the specific agent pulls the operation from the queue, in the case a synchronization. 3. the thread fetched all active alarms from the agents MIB by doing an SNMP walk. 4. the retrieved list is converted to FM sync notifications and sent to the FM Kernel 5. FM Kernel updates the db with the active alarms for the agent. Receiving Alarms from SNMP NEs The alarm supervision process does the following: 1. A SNMP trap is received by the AdventNet SNMP stack and is pushed into a queue of incoming traps for the specific agent.

2. the thread translator assigned for the specific SNMP agent 3. the trap is parsed and a FM notification is created. 4. FM notification received by the FM Kernel. Conversion rules are invoked. 5. the event/problem is stored in the db and is accessible for any FM GUI. This adaptation form is used for nodes: GSN, Extreme, Netscreen, True Time, Jambala, Netra, AXD, Tigris, RADIUS, Juniper and MMC. Poer 161 is used for receiving SNMP traps and 162 for sending e.g. snmpget. It might be useful to snoop on these ports to see if the information flows as needed/wanted. OSS-RC Alarm Adaptation Unit(AAU) To handle internal errors that might be important to the running of the OSS, errors can be forwarded into the FM alarm Viewer. OSS-RC AAU is set up on installation of the system. FM Processes The most important processes of the FM Kernel are: 1. Log Server -> updates the alarm log in the fma database 2. Context Server -> updates the alarm list in the fma database, forwarding alarm records to subscribing application (ATRs) 3. handles acknowledgements and comments from users. Records in the Operator Log of FM database. 4. NSC Server -> manages alarm counters for NEs (the information in GNIP/ASV) The following processes must be running in order to be able to start and run the context, log and NSC servers:

IMH_alarm_server IMH_action_server IMH_nm_server IMH_FMAI_server SQL_server (for the FM Kernel processes)

Actions toward fmadb_1_1 What happens in the fmadb tables when alarms are received and operator actions performed?

An incoming alarm is stored permanently in the alarm log table. The alarm is also stored in the alarm_list

When an operator notices the alarm he will acknowledge it and the action is stored in the operator_log The alarm in the alarm list is also marked as acknowledged. When the operator has solved the problem he will clear the alarm. The action will be stored in the operator_log and the alarm will be removed from the alarm_list.

Since entries are never automatically removed from the alarm_log and operator_log tables we have the need for a cleanup procedure handled by the log administration application. Alarm Viewer Processes The processes that service the alarm viewer processes use CORBA communication. Reason: we want the alarm viewers to be platform independent. The fmasv_1, fm_alarmlist_d and fm_mibserver)d can be said to be protocol converters between IPC and CORBA. These processes are seen both in CIF/SM and with the psit command but they are managed from CIF SM. FM_AV_proxy caches authority for an unknown time period and if TSS changes have been made e.g Give an operator the right to acknowledge alarms this server needs to be refreshed. Alarm Text Routing

Forward incoming alarms to selected devices (mail, file or printer) Set up automatic acknowledgement fro alarms in the alarm list.

Alarm Viewer Application CLI: imcmd, imcli, alnip,allist, fmlist, alack, fmack, alcom, alrout, fmrout, fma_sync, list_mesg. Example : #fmlist oor SubNetwork=ONRM_RootMo,MeContext=RNC3 #fmack oor SubNetwork=ONRM_RootMo,MeContext=RNC3 420252 #fma_sync system osomc objectname SubNetwork=ONRM_RootMo,MeContext=RNC3 #list_mesg 240000 NWS-A Administration STS:Statistical Traffic Subsystem -> counter based related OMS: Operation Maintenance Subsystem -> traffic related (TRAR, TRART, TRDIP) ASDDB: Administrative DB (configuration data for SDM is stored)

BSDDB: predef BO reports CSDDB: Customer Spesific Report (BO) Receiving Measurement files from IOG20/AXE 1. a measurement produces a file at the of a recording period and sends it to the OSS via MTP/X.25 2. the ehm_af_or stores the measurement file the EAM filestore. 3. the ehm_af_or checks the subscription database to find the program that is waiting for the file notification for this recording. 4. the SGwIOGFileCollector process receives the file notification and makes a hard link to the file in the SGw Inputfiles directory. 5. a measurement-type specific parser takes the natives switch format file from the Inputfiles directory and extracts the data and then writes it to the outputfiles directory in Sybase BCP format. 6. Statistical Data Mart (SDM) picks up the file from the SGw Outputfiles directory and puts it into the SDM databases. Receiving Measurement Files from APG40/AXE 1. a measurement produces a file at the end of recording period and sends it to the OSS via TCP/IP 2. the ehip_af_or stores the measurement file in the EAM filestore. 3. the ehip_af_or checks the subscription database to find the program thas is waiting for the file notification for this recording. 4. the SGwAPG40FileCollector process receives the file notification and initiates an FTP session with the APG40 to transfer file into the inputfiles directory 5. a measurement-type specific parser takes the native switch format file from the inputfiles directory and extracts the data and then writes it to the outputfiles directory in Sybase BCP format. 6. SDM picks up the file from the SGw Outputfiles directory and puts it into the SDM database. SGw initiates a file copy to the inputfiles in SGw, data is processed by SGw kernel to bcp format. SDM_Dispatcher initiate a bcp, initiate and control bcp load into SDM database (BSDDB, CSDDB). SMIA #/opt/ericsson/bin/nms_nws_smia_main

Administer statistical measurements in the different AXE10 type NEs supported by OSS RC. SMIA application has the following CORBA servers:

TBSSrv -> send error reports to SM, retrieves parameter values from PDB, acts as master server which controls other servers NIMSrv -> fetches NE information from CS SMCASrv -> Receives requests for start measurements, stop measurements, STS DB configuration and audit from the GUI. SMADSrv -> gets the requested data from the smiadb (SMIA database), sets data into smiadb (SMIA database), stores all measurement related information SMCPSrv -> sends MML command sequence for the various functions in SMIA to the NE, receives command response from the NE, parses the comment reply printout.

SMIA log #tail f /var/opt/ericsson/smia/log/SMCASrv.log Edit file /etc/opt/ericsson/smia/cxc.env and set the value of SMIA_DEBUG_LEVEL to 2 to enable logs and set the value of SMIA_DEBUG_LEVEL to 1 to disable logs. Logging feature should be switch on only to collect logs, for gathering more details about a trouble or potential trouble. User is warned that huge logs files in tune of 15-16MB might cause SMIA CORBA servers to crash or behave erratically. Changing timezeon of NE It will not update SGw automatically about the timezone changes for those measurement nobs which are scheduled , From SMIA: Tools > Jobs > Inform to SGw Deleting SMIA Job through Activity Manager or: #/opt/ericsson/smia/etc/smia_delete_am_jobs.sh SGw Processing

Decoding -> verify the data records are correct, uses dedicated ASN.1 and ISO-ASCII decoders for STS & OMS. Formatting -> modify individual field in data records, translate data records from one format to another.

Encoding -> encoded to a bulk copy format specified by SDM, which is comma separated ASCII. Distribution -> stores all output in a filestore, SDM picks the output files periodically. Alarm handling -> generates error/alarms in case of abnormal events, reported to the SM LogAgent which can be viewed from the SM LogViewer, also adds the error to its internal log file.

SGw directory structure: /opt/ericsson/sgw/ /var/opt/ericsson/sgw/

Corrupt -> directory contains corrupt measurement data files. Etc -> contains data files, temporary files and used by SGw application. The data are not to be edited by the user. Inputfiles -> contains different input directories for files collected before parsing. Outputfiles -> contains sub directories where the processed data files are stored. Log -> contains log files created by SGw Data -> contains SGw MC xml fil. Unmatched -> contains files that could not be stored in their respective inputfiles

/etc/opt/ericsson/sgw/config -> config file used by SGw cxc.env -> contains environment variables for SGw application. SGw Start/Stop # su nmsadm #/opt/ericsson/nms_cif_sm/bin/startSelfManagement.sh, right click on NWS_SGW select online/offline Verification: /usr/ucb/ps auxwww|grep SGw should list 19 processes (online) or nothing (offline)