OSS TIPS

March 23, 2018 | Author: wcdma123 | Category: User (Computing), Computer File, Password, Databases, Kernel (Operating System)


Comments



Description

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 there are three files/directories have to be present in /opt/ericsson/sck/data/user_templates: . default categories may be updated. (dir) -> a set of files and directories required to run OSS. . Requests password for new account 4. adds user to TSS and assigns roles.dtwmrc -> background menu template. creates UNIX home directory 3.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.sh to create the live template.dat TMOS adapter (MC) to handle old TMOS applications. 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: . Parsed by update_menus. try to use solftlinks when it’s possible. Step to create user on OSS system: 1. creates new UNIX login account 2.roles -> the list of roles the belongs to per default.sh –c “Aghiel Prayogo” aghiel sys_adm In order to create site specific categories. Adding OSS User Account (as root): #oss_adduser. so in order to keep category maintaince to a minimum. When installing a new SCK. sh TSSBasicServer #/opt/ericsson/nms_tss_server/bin/startBasicServer.sh The server are started in the following order: Basic Service > Password Server > Authority Server . CORBA Servers in TSS: TSSAuthServer #/opt/ericsson/nms_tss_server/bin/startAuthorityServer.outside the control of pwAdmin.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.sh TSSPWServer #/opt/ericsson/nms_tss_server/bin/startPasswordServer.sh -> modify user #oss_delusers. Setting the password in the corresponding system has to be done as a separate measure.#pwAdmin –list|grep Telnet_Gateway #update_users. e Alarm Supervision On/Off. it performs the following steps: 1. . the FM internal format. TSSAuthServer fetches the userid from the parameter TSSDatabaseUser. This is done automatically by notification but fm_ims process can be restarted e. TSSAuthServer fetches the password from TSSPWServer. TSSAuthServer fetches the TSS data source name from the parameter TSSDataSourceName (the Sybase server name). fma_axeadaptation_1. i. imhdb -> record summary of the alarm. Sybase Open Client: When the Authority Server logs into the Sybase database. CORBA monitors processes in FM. Information Model Handler (IMH). TSS logs into Sybase using the Sybase Open Client interface Fault Management System External Access -> handle communication between OSS and Network Elements. FMAI. 4. as well as CIF SM and TSS.TSS Server run as user nmsadm TSS Manage Component(MC) is started automatically at system start by the CIF SM & GUI. 2. FM uses fmadb_1_1 and imhdb database. Synchronization between IMH and NRM is handled by IMS. etc. 3.AXE) to translate the AXE specific printout into Alarm Records. heartbeat Supervision On/Off. Information Model Instance Manager (IMIM) is used to update the IMH with FM Specific information.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. IMH is synchronized with information from the Network Resource Model via Information Model Synchronization (IMS). using the parameter TSSDataSourceName and TSSDataSourceType as system and TSSDataBaseUser as account. fma_axeadaptation_APG40 AM uses a translation map (FMA_TRANSLATE. as well as forward the alarm record into the FM kernerl through the FMA Interface. the thread fetched all active alarms from the agents MIB by doing an SNMP walk. 3. Superfision thread does the following: 1. Issues an snmpget request towards the agent. 2. AXE alarm coming to the OSS and are handled by the AXE (or telnet adaptation in the case of APG40) AAU. This will be cleared upon the next successful snmpget request. sets communication status tp up if down and request succeeds Performing Synchronization of SNMP NEs The agent synchronization thread does the following: 1. . They are mostly handled by SNMP SMT 3. in the case a synchronization. retrieves the TIMEOUT parameter 2. This process translates the traps according to translation maps and forwards the alarm information to the FM kernel. the FM action SYNC is sent by SNMP SMT to agents ‘ OpQueue 2. If snmpget fails. SNMP Alarm Adaptation – the SUPI interface: SNMP traps. 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. the retrieved list is converted to FM sync notifications and sent to the FM Kernel 5. sets communication status to down if request fail 4. SNMP trap coming from NEs that are supervised via SNMP. communication status will be set to down. A SNMP trap is received by the AdventNet SNMP stack and is pushed into a queue of incoming traps for the specific agent. The comm. 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. TMOS internal and CIF/SM internal errors are handled by the OSS-RC AAU.Three major cases of alarm adaptation in OSS-RC: 1. 3. the thread actionhandler assigned for the specific agent pulls the operation from the queue. whether coming from the SNMP SMT or the CORBA IRP Manager are forwarded through the SUPI interface and collected by the fma_supiproxy. 4. Netscreen. errors can be forwarded into the FM alarm Viewer. Extreme. 4. True Time.2. forwarding alarm records to subscribing application (ATRs) 3. Log Server -> updates the alarm log in the fma database 2.g. Poer 161 is used for receiving SNMP traps and 162 for sending e. RADIUS. handles acknowledgements and comments from users. The alarm is also stored in the alarm_list . AXD. FM Processes The most important processes of the FM Kernel are: 1. Jambala. 4. It might be useful to snoop on these ports to see if the information flows as needed/wanted. Tigris. 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. Records in the Operator Log of FM database. Conversion rules are invoked. the thread translator assigned for the specific SNMP agent 3. the trap is parsed and a FM notification is created. OSS-RC AAU is set up on installation of the system. This adaptation form is used for nodes: GSN. 5. 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. FM notification received by the FM Kernel. the event/problem is stored in the db and is accessible for any FM GUI. Context Server -> updates the alarm list in the fma database. OSS-RC Alarm Adaptation Unit(AAU) To handle internal errors that might be important to the running of the OSS. Juniper and MMC. Netra. snmpget. TRDIP) ASDDB: Administrative DB (configuration data for SDM is stored) .• • • 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. FM_AV_proxy caches authority for an unknown time period and if TSS changes have been made e.MeContext=RNC3 420252 #fma_sync –system osomc –objectname SubNetwork=ONRM_RootMo. fma_sync. These processes are seen both in CIF/SM and with the psit command but they are managed from CIF SM. alnip.MeContext=RNC3 #list_mesg 240000 NWS-A Administration STS:Statistical Traffic Subsystem -> counter based related OMS: Operation Maintenance Subsystem -> traffic related (TRAR. imcli. Example : #fmlist –oor SubNetwork=ONRM_RootMo.MeContext=RNC3 #fmack –oor SubNetwork=ONRM_RootMo. file or printer) Set up automatic acknowledgement fro alarms in the alarm list. The action will be stored in the operator_log and the alarm will be removed from the alarm_list. fmrout. Alarm Viewer Application CLI: imcmd. fmlist. alcom.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. Reason: we want the alarm viewers to be platform independent.allist. list_mesg. alrout. Alarm Viewer Processes The processes that service the alarm viewer processes use CORBA communication. The fmasv_1. 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. fmack. alack. fm_alarmlist_d and fm_mibserver)d can be said to be protocol converters between IPC and CORBA. TRART. When the operator has solved the problem he will clear the alarm. SDM picks up the file from the SGw Outputfiles directory and puts it into the SDM database. CSDDB). initiate and control bcp load into SDM database (BSDDB. the SGwAPG40FileCollector process receives the file notification and initiates an FTP session with the APG40 to transfer file into the inputfiles directory 5. 4. SMIA #/opt/ericsson/bin/nms_nws_smia_main .25 2. the ehm_af_or stores the measurement file the EAM filestore. 5. the ehip_af_or stores the measurement file in the EAM filestore. a measurement produces a file at the of a recording period and sends it to the OSS via MTP/X. the SGwIOGFileCollector process receives the file notification and makes a hard link to the file in the SGw Inputfiles directory. the ehip_af_or checks the subscription database to find the program thas is waiting for the file notification for this recording.BSDDB: predef BO reports CSDDB: Customer Spesific Report (BO) Receiving Measurement files from IOG20/AXE 1. a measurement produces a file at the end of recording period and sends it to the OSS via TCP/IP 2. Receiving Measurement Files from APG40/AXE 1. 3. 4. 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. Statistical Data Mart (SDM) picks up the file from the SGw Outputfiles directory and puts it into the SDM databases. 3. SGw initiates a file copy to the inputfiles in SGw. data is processed by SGw kernel to bcp format. the ehm_af_or checks the subscription database to find the program that is waiting for the file notification for this recording. 6. SDM_Dispatcher initiate a bcp. 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. SMADSrv -> gets the requested data from the smiadb (SMIA database). sets data into smiadb (SMIA database). stop measurements. STS DB configuration and audit from the GUI. receives command response from the NE. translate data records from one format to another.sh SGw Processing • • Decoding -> verify the data records are correct. uses dedicated ASN. User is warned that huge logs files in tune of 15-16MB might cause SMIA CORBA servers to crash or behave erratically.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. SMIA application has the following CORBA servers: • • • • • TBSSrv -> send error reports to SM. acts as master server which controls other servers NIMSrv -> fetches NE information from CS SMCASrv -> Receives requests for start measurements. From SMIA: Tools > Jobs > Inform to SGw Deleting SMIA Job through Activity Manager or: #/opt/ericsson/smia/etc/smia_delete_am_jobs. .log Edit file /etc/opt/ericsson/smia/cxc. Changing timezeon of NE It will not update SGw automatically about the timezone changes for those measurement nobs which are scheduled .1 and ISO-ASCII decoders for STS & OMS. SMIA log #tail –f /var/opt/ericsson/smia/log/SMCASrv. Formatting -> modify individual field in data records. stores all measurement related information SMCPSrv -> sends MML command sequence for the various functions in SMIA to the NE. Logging feature should be switch on only to collect logs. parses the comment reply printout.Administer statistical measurements in the different AXE10 type NEs supported by OSS RC. retrieves parameter values from PDB. for gathering more details about a trouble or potential trouble. env -> contains environment variables for SGw application. Alarm handling -> generates error/alarms in case of abnormal events. Distribution -> stores all output in a filestore. Unmatched -> contains files that could not be stored in their respective inputfiles /etc/opt/ericsson/sgw/config -> config file used by SGw cxc. Log -> contains log files created by SGw Data -> contains SGw MC xml fil. The data are not to be edited by the user. also adds the error to its internal log file.• • • Encoding -> encoded to a bulk copy format specified by SDM.sh. SDM picks the output files periodically. reported to the SM LogAgent which can be viewed from the SM LogViewer. SGw directory structure: /opt/ericsson/sgw/ /var/opt/ericsson/sgw/ • • • • • • • Corrupt -> directory contains corrupt measurement data files. Etc -> contains data files. Outputfiles -> contains sub directories where the processed data files are stored. which is comma separated ASCII. SGw Start/Stop # su – nmsadm #/opt/ericsson/nms_cif_sm/bin/startSelfManagement. right click on NWS_SGW select online/offline Verification: /usr/ucb/ps –auxwww|grep SGw should list 19 processes (online) or nothing (offline) . Inputfiles -> contains different input directories for files collected before parsing. temporary files and used by SGw application.
Copyright © 2024 DOKUMEN.SITE Inc.