Professional Documents
Culture Documents
Troubleshooting Notes
For internal use
1. Version Control.............................................................................2
2. Introduction...................................................................................3
4. Integration...................................................................................12
4.1. RNC Integration...................................................................................................12
4.2. NetAct integration................................................................................................14
4.3. WBTS Integration.................................................................................................15
5. Technical Notes..........................................................................16
5.1. Ports and Protocols..............................................................................................16
5.2. LDAP................................................................................................................... 16
5.3. OMS – OMU Communication...............................................................................18
5.4. Tracing (S)OMS-OMU communication in OMU....................................................18
5.5. SOMS Redundancy.............................................................................................20
5.6. Linux IP routing....................................................................................................21
6. Troubleshooting Cases...............................................................23
6.1. No IP connectivity between WBTS and Southbound SOMS address...................24
6.2. RNC Topology Upload from SOMS failing...........................................................26
6.3. RNC RNW Plan Upload failing from NetAct.........................................................27
6.4. WBTS Site Configuration File Upload Failing from NetAct...................................28
6.5. License Download to WBTS failing from NetAct..................................................30
6.6. SOMS Internal Firewall misconfiguration.............................................................34
6.7. Recreating the (S)OMS Topology Database........................................................36
6.8. Increment installation could not be performed in a single step.............................36
7. References.................................................................................37
8. Appendixes.................................................................................37
8.1. OMS Pronto Symptom List...................................................................................37
8.2. OMS MySQL Databases......................................................................................37
2
For internal use
1. Version Control
Issu
Date e Author Summary of changes
3
For internal use
2. Introduction
The purpose of this document is to share the knowledge gained during the installation,
commissioning and integration of a factory Stand Alone OMS in a customer’s live network.
Some project specific implementation aspects are included. Most steps common to the
integrated OMS are omitted. Background information on some technical areas and a few
troubleshooting cases are provided.
The Stand Alone OMS replaces the integrated OMS. It will perform the same functions as
the Integrated OMS but is installed as a separate HW unit, possibly in a different location
than the RNC. Up to 10 RNCs can be controlled by one Standalone OMS. There are also
limitations for the total number of WBTS and Cells that can be managed by one SOMS.
The HW used to implement the SOMS is an HP ProLiant DL360 G6 1U rackmount server with
either four 146 GB or four 300 GB 2,5” Serial Attached SCSI hard disk drives.
There are two Ethernet ports in the SOMS, configurable in two different ways. Normally the
two physical ports are grouped into one logical interface named bond0. This logical interface
is then configured with two different IPs. One of those IPs is used to connect to NetAct and
the other one to the RNC and WBTSs. The connection towards NetAct is referred to as the
4
For internal use
Northbound connection, the one towards the RNC and WBTS as the Southbound
connection. There is a second configuration option where one physical Ethernet port is
configured with one IP and used for the Southbound connection, the other physical port
configured with a different IP and used for the Northbound connection.
In the text that follows, actual command line inputs are highlighted in bold, command
outputs and text logs are enclosed in a border box. Where parts of command outputs have
been omitted, this is indicated with square brackets […] .
If you proceed with a brand new installation of the SOMS, you will be asked for integration
and commissioning data right at the start. The attached excel file contains an example blank
datafill with all the parameters required.
SOMS__Datafill_Exa
mple.xls
The disk structure with which the HP server comes from factory may not be the correct one.
The first step is to verify and reconfigure it if necessary. The target configuration is
composed of two logical drives, each logical drive a RAID0 array. These RAID0 arrays are in
turn composed of two physical hard disks which are not mirrored copies of one another. The
mirroring between the two RAID0 arrays is performed by the OMS SW. The two left-most
physical disks in the HP server will form logical drive 1 and the right-most disks logical drive
2.
As the disk structure is different, the commands to display and configure the disks will be
different than the ones used with the Integrated OMS. The disk structure can be
interrogated with the command:
#fsswcli –m-s
/dev/cciss/c0d0 UNLOCKED
/dev/cciss/c0d1 UNLOCKED
where c0d0 and c0d1 are the two RAID0 arrays. To look into the individual RAIDs:
#cd /proc/driver/ccis
#cat cciss0
cciss0: HP Smart Array P410i Controller
5
For internal use
[…]
Sequential access devices: 0
cciss/c0d0: 599.93GB RAID 0
cciss/c0d1: 599.93GB RAID 0
From the last output each RAID0 array has a capacity of around 600 GB, the sum of the two
300GB physical disks. To examine the actual physical disks the hp tool hpacucli is available:
#hpacucli
HP Array Configuration Utility CLI 8.35-7.0
Detecting Controllers...Done.
Type "help" for a list of supported commands.
Type "exit" to close the console.
=> ctrl all show config detail
[…]
Array: A
Interface Type: SAS
Unused Space: 0 MB
Status: OK
Logical Drive: 1
Size: 558.7 GB
Fault Tolerance: RAID 0
Heads: 255
[…]
The reinstallation procedure is the same as for an Integrated OMS, only the type of OMS has
to be chosen as fp4_hprm. The documentation states that during USB installation the OMS
hardware clock must be set to “UTC/GMT time (United Kingdom’s time)”; for some of the
year UK time is not UTC/GMT. UTC/GMT is always the time that should be set.
./CompleteGOMS_USBInstallation.sh
and commissioning data has to be entered as per the excel sheet included above.
A very useful feature of iLO is a remote console session that can be used to monitor a restart
as would a local session. This remote console allows direct login with the root user,
something not possible with telnet or ssh.
With this feature, unlike with the Integrated OMS, it is possible to connect and reboot the
SOMS even when IP connectivity to the southbound and northbound SOMS IPs is lost.
3.5. Reconfiguring the SOMS to use separate interfaces for North (NetAct) and South (RNC and
NodeB) connections
By default, the SOMS’s two Ethernet interfaces are grouped into one logical interface,
bond0, whether using the same or different IP addresses for the Northbound and
Southbound IP connections. The following procedure was used to reconfigure the SOMS so
that the two physical Ethernet interfaces were each assigned to its own IP, one for
Northbound one for Southbound IP. As this procedure touches upon several interesting
areas of the SOMS it will be included here.
The fsipnet command is used to interrogate network configuration from the LDAP database.
The same parameters can be checked by directly inspecting the database with the
Parameter Tool from application launcher.
fsipnet ethiface add eth1 node CLA-0 addphase nwmgrstart delphase never dependency
fsipNetworkObjectName=FSIPEthernetIface@eth0,fsFragmentId=Network,fsipHostName=CL
A-0,fsFragmentId=Nodes,fsFragmentId=HA,fsClusterId=ClusterRoot owner /CLA-0 address
inherit dynamic yes mtu 1500 hw fshwConnectorId=eth-2,fshwPIUId=piu-
0,fshwEquipmentHolderId=chassis-1,fshwEquipmentHolderId=cabinet-
1,fsFragmentId=HW,fsClusterId=ClusterRoot priority 524289 from eth0
8
For internal use
fsipnet nexthop add 0.0.0.0/0 table 254 tos 0 via 172.17.5.1 node CLA-0 iface bond0 name
bond0@172.17.5.1 weight 1
To proceed with the reconfiguration, the existing configuration is removed. Starting with the
default routes:
The same IP address was being used for Northbound and Southbound connections, so no
additional removal command was necessary.
The next step will be associating the different recovery groups with the South or North
interfaces. This is done by configuring the environment variables NLIST and SLIST with the
required services. Services to be associated with the Northbound interface are configured
on NLIST, Southbound on SLIST. The correct mapping is obtained by looking at the
assignment performed by the script oms_rnc_script.sh. This script is called by
zmodifynetworksettings during commissioning. In addition to the recovery groups that have
to be assigned manually, the daemons /Vsftpd, /sshd, /httpd listen on both interfaces by
default.
cd /opt/Nokia/SS_OMSINST/script
9
For internal use
# grep ‘NLIST=’oms_rnc_ipscript.sh
NLIST="user /Directory user /ClusterDNS user /SNMPMediator user /HTTPDPlat user
/NWI3Adapter user /PAP user /RuimReplicator user /RNWEvent user /NWI3TU user
/FMAdapter user /PMPres user /NWI3CM user /MeaHandler user /FMUIGate user
/PMGeneric user /OMSEventHandler user /Nwi3SWAgent user /Nwi3SecuCorba user
/CMaus user /THRKPI user /Nwi3LMAgent user /OMSAccessQuery user /OMSAppControl
user /MMI user /PMOnline user /RNWCM user /NELogManager user /NWI3HW user
/Nwi3Certificate user /EmiPMPlatMea user /Nwi3AuditTrailHandler"
#grep ‘SLIST=’oms_rnc_ipscript.sh
Add dedicated addresses to both Ethernet interfaces, associating the services of NLIST and
SLIST with each one:
Define the default route for main routing table (in a following section, there is a short
explanation of Linux routing tables):
Define the routes in the routing table for the southbound interface. The first of the following
commands defines the subnet that can be reached directly by the interface; the second one
defines a gateway on that interface:
10
For internal use
fsiproute add 0.0.0.0/0 via 172.17.29.17 iface eth1 owner /CLA-0 table 20
Create the routing rules. These specify which of the routing tables should be used
depending on the source and destination addresses configured on the IP packet:
The next steps verify the new configuration before it is applied by system restart. View the
dedicated IP addresses:
11
For internal use
fshascli -r /
Note that with this configuration, the default route when the IP rules 2000 and 20001 don’t
apply will still be the northbound interfaces’ gateway. The SOMS services however will use
as their source address the address configured in the interface (North or Southbound) to
which they are assigned to. This assignment is made via the NLIST and SLIST environment
variables.
4. Integration
In RU30, a new user has to be created in the OMU for the (S)OMS to login with. This is done
automatically by the RU20 to RU30 upgrade macros, but has to be done manually in the
case of a new RNC. The command to create the user is:
ZIAH:OMSUSR:PROFILE;
After entering the command, the MML program asks for the password, the value that
should be set unless there are project specific instructions is SYSTEM. (This information was
added to Issue 08 of WCDMA RAN and I-HSPA, Rel. RU30, Operating Documentation).
12
For internal use
After that the RNC ID and SOMS IPs (Primary, Secondary and Backup) have to be configured
in the RNC using the RUOSTEQX service terminal extension:
ZLE:1,RUOSTEQX;
Z1CR:<RNC_ID>,<OMS_IP_Address>,<RNC_name>;
>Z1C;
0000-RUO>C;
Connecting to RNW database...
In case the connection is not automatically established, BOI and BOE can be restarted in
both the active and standby OMU as a workaround:
ZLP:Q,SQQ;
ZQRR:506;
ZQRR:A0F;
The OMS IPs configured in the RNC can also be seen from SpringyUI. Only the backup OMS
IP Address can be edited there:
13
For internal use
As soon as this IP is configured in the RNC, the OMU will initiate the connection towards the
(S)OMS. This can be verified by ZQRS in the OMU and netstat in the SOMS. If the connection
is made correctly the RNC will appear in Springy’s main view. If only the RNC appears in
SpringyUI without any objects under it, and if the RNC’s RNW is not blank, then most likely
even though the BTSOM connection between OMU and (S)OMS is correctly established the
RNW plan upload that occurs immediately after the establishment is failing. It is only after
this initial plan transfer the topology database in (S)OMS is initialized with the objects
configured in the RNC.
NetAct integration is the same as for an Integrated OMS, Initial Registration Username and
Password as well as the IOR string were configured in parameter editor:
14
It is possible to verify the correct registration of the SOMS to NetAct by logging in to the
connectivity server and changing directory to:
cd /var/opt/nokia/oss/global/nw3n3c/log
In the directory there are several files with the name structure
n3cregmx_<xxx>_i1.log
and the correct registration should be found in the file with the newest date by doing
It must be verified that there is IP connectivity between the Southbound IP address of the
SOMS and the WBTS O&M address. All protocols used for communication between OMS
and WBTS must be allowed by any firewall that might exist. The firewall could be between
ESA and (S)OMS, between WBTS and NPGE or between WBTS and ESA. One particularity in
the case of Active – Standby SOMS configuration where the SOMS is the NTP server for the
WBTS: the Southbound addresses of both SOMS have to be configured in the NTP Server tab
15
In case of an ATM Iub WBTS, IP routing has to be defined between the SOMS and the OMU.
The WBTS will then be reachable via the IPoATM connection that starts at the OMU. In case
of an IP IuB WBTS the O&M connection can go via the NPGE(P) card over the same IP path
as User and Control Plane, or it can be carried in a separated O&M network going through
the ESA card. In both cases OMU has to have routing defined to reach the WBTS. In the case
where the NPGE is used, the NPGE has to have routing defined to be able to reach the SOMS
southbound interface, usually via the OMU card.
5. Technical Notes
Attached is an excerpt from the RU30 WCDMA RAN communication matrix detailing the IP
connections and ports used between OMS, OMU and NetAct:
WCDMA RAN IP
protocol and port list RU30_20110825_approved.xls
5.2. LDAP
There is an LDAP daemon server running in the OMS to which Parameter Editor connects
when it is used to edit the LDIF.
The user accounts are stored n LDIF in ClusterRoot->Security- >People , and they are
accessed by the OMS processes when user credentials need to be verified.
Wiith ps –ef | grep ldap it can be seen that the LDAP process was started in SOMS with
commands:
16
For internal use
The –d 0 option means no debugging, so no LDAP logging gets written to syslog by default.
There are two listeners, LDAP with TSL on localhost:49501 and ldap over TSL on
localhost:636.
Taking a wireshark trace on the loopback address in OMS, the processes can be seen
interrogating LDIF database:
17
For internal use
In RU30 the EMT protocol between (S)OMS and OMU is replaced with BTSOM. The
interrupted lines in the figure below indicate that the communication is encapsulated in
BTSOM protocol packets between OMS and the BOIMED program block in OMU, and
forwarded to the other program blocks inside the OMU or to the WBTS via the O&M
connection. This is just for O&M messages, and does not include the HTTP, FTP, HTTPS, SFTP
connections used for file (Licences, Site Configuration File, RNC Plan) transfer between WBTS
and SOMS.
18
For internal use
Monitoring on the OMU side can be performed with the DMXMacro. A monitoring condition
that could capture the relevant program blocks would be BOR(DER) 0A0F, and BOI(MED)- 0506,
which are included by default in the DMXMon macro:
19
For internal use
The user data in the BOR message starting at user_data[3]. can be matched to the OM message
starting with the. checksum contained in the fileInfo information element.
The OMU has a Primary and Secondary SOMS address configured. The configuration
between Primary and Secondary OMS has to be the same regarding usernames and
passwords, but not in terms of IPs or SOMS ID. This enables the OMU to switchover SOMS
automatically if the connection fails. This is feature RAN1874 Automatic OMS resiliency.
After the RNC has established a connection with the target SOMS, the latter will initiate a
plan upload transferring the topology and measurement plans. It will also initiate an alarm
upload. A trace on the source OMS shows:
Linux uses multiple routing tables, identified by numbers from 0 to 255. By default, two
tables are configured, 254 called the default routing table and 255 called the local routing
table. The local table is automatically manipulated by Linux, for example when an interface
is configured with the ifconfig command. The default table is the one manipulated when
routes are added to a Linux machine by the user, for example with the ip route add
command.
There is also another separate database that defines which routing table is used for each IP
packet. This is the Routing Policy Database, RPDB. This table contains a series of rules, each
with its own priority. A packet is compared sequentially to each rule, when a match is found,
the corresponding routing table is used. The command to examine the RPDB was given
above and is
21
For internal use
According to this output, the first routing table to be checked for any packet is the local
routing table, routing table 255. Examining in this routing table in a standard (S)OMS:
This routing table contains only local or broadcast routes, that is, for destination IPs that are
either configured locally on one of the host’s interfaces or are directly accessible (without
resorting to a gateway) via one of those interfaces. For each of the external interface
addresses, there is a broadcast route to reach its network and broadcast address.
After rule 0, the next rules to be examined where the two introduced during the SOMS
reconfiguration in section 2.5. If either the source (rule 20000) or destination (rule 20001)
IPs in the packet match 172.29.16/28 then routing table 20 will be used.
If neither the source nor the destination address in the packet is within that range, then the
main routing table will be used, table 254. Lastly, the local routing table will be tried.
22
For internal use
6. Troubleshooting Cases
In this section some troubleshooting cases are presented. They are for a Network setup
where all the TLSMode parameters are set to Off, meaning some message exchanges are
sent in the clear that normally would be encrypted.
With TLSModeOMOff the BTSOM traffic between the Southbound OMS interface and the
OMU will not go over TLS and can be viewed in wireshark. The same applies for BTSOM
traffic between OMU and WBTS as TLSMode RNCBTS=Off. TLSModeFT=Off means that the
WBTS will transfer files from OMS using HTTP instead of HTTPS, file transfer between OMU
and OMS will be performed using FTP instead of SFTP and file transfer between SOMS and
Netact will be performed with HTTP instead of HTTPS.
NSN’s proprietary Wireshark includes dissectors for BTSOM and GIOP, the protocol used
between SOMS and Netact. Therefore all traces taken at the SOMS should be analyzed with
it instead with of the standard open source Wireshark.
https://isource.access.nokiasiemensnetworks.com/
In this case the options determine that the capture will be only on interface bond0 (-i), for
packets with the specified filter (-R) and written to a file (-w). The produced file can be
transferred out of the SOMS and opened directly with Wireshark.
23
For internal use
IP connectivity between two interfaces below means that it is possible to ping one
interface’s IP address from the other interface, using the latter’s IP address as the source
address in the ping command
The transmission network chain in this case (or what we could see from RAN) was:
24
For internal use
Adding a route to the router between NPGE and WBTS, the problem was cleared.
Note that even in the correct case the NPGE only sends an ICMP Time Exceeded from the
IFFE interface to the ESA, not from the VLAN/IFGE interface towards the Iub transmission
network. This causes that the IFGE0/VLAN interface with IP 10.10.192.132 does not show up
in the traceroute output and was an argument used by the customer to say the packet was
being lost inside the NPGE.
In this case the Topology Upload when requested via graphical user interface from SOMS
failed. In the Wireshark trace it was visible that the SOMS was trying to ftp to the OMU to
25
For internal use
retrieve the plan using as source address 172.17.5.150 instead of the correct southbound
interface address of 172.17.29.22.
Which meant the CMausSrv was looking up the value of szIPAddress in the LDAPs database,
and that the value there was still 172.17.5.150.
26
For internal use
This was confirmed. After changing the parameter to the correct value of 172.17.29.22 the
problem was cleared.
After the previous problem had been cleared, RNW plan upload was failing from Netact.
Problem could be seen in OMU computer logs, Wireshark logs and OMS logs for Nwi3CM.
The southbound source address that was showing up in the CMPlanManager configuration
dump included in in CMausSrv_trace.txt still had the old value:
------------------------------------------------------------------------------------
| CMPlanManager configuration dump |
| setting | type | value |
------------------------------------------------------------------------------------
| CM_FTP_ROOT | S | /var/opt/OMSftproot |
| CM_FTP_HOST | S| 172.17.5.150 |
| CM_FTPS_HOST | S| 172.17.5.150 |
| CM_OMSID | S| NE-OMS-11 |
| CM_MAX_THREAD_COUNT | I| 100 |
So the change in Parameter Editor had not yet been propagated to CMPlanManager. After
restarting Nwi3CM with
#fshascli –r /Nwi3CM
| CM_FTPS_HOST | S| 172.17.29.22 |
27
For internal use
Attempting a WBTS SCF upload from NetAct from CM Operations Manager, there was the
following error message:
Taking a wireshark on the Northbound interface, the upload request was correctly arriving
at the Northbound interface of the SOMS:
28
Figure 17 SYN packets opening TCP connection From SOMS to WBTS
For internal use
the SOMS was correctly attempting to open a TCP session to the WBTS, but not reply was
ever received.
It is visible in the trace from the destination mac address that the packet is being correctly
sent to the gateway for the SouthBound interface. Confirmed in the SOMS:
#arp –a
Thu Aug 9 16:37:19 2012 #0000042210 OMS::TRACE DEBUG <Error Log Entry:0> CLA-0 :
(../src/NemuFTP.cpp:968): CNemuFTP::GetFile: file transfer failed:
http://10.29.52.21:6000/bts//ram/CUPL_BTSC_252.xml.gz ->
/var/opt/OMSftproot/cmplan/ul/ne/11924/RNC_464_WBTS_252_SCF, responseCode=0,
curlError: Couldn't connect to server(7)
Error code: 0x80004005 (0,0) 825ms pgrp=16775 pid=16775 tid=1429371200 uid=0 gid=0
The problem was the firewall existing in the transmission network between SOMS and
WBTS.
29
For internal use
In the normal process for license download, NetAct first informs (S)OMS that it has a license
to download, then transfers that license to a directory in SOMS. The following is from a
wireshark trace taken on a working OMS where the Northbound and Southbound OMS IPs
are 10.200.68.167, the OMU IP is 10.200.68.164 and the WBTS IP is 10.29.12.1. The process
can be seen starting with a license download request coming from NetAct to the
(Northbound) address of the OMS, protocol GIOP:
The OMS then sends to the OMU a fileLoadPrepare message. This message will be
processed by the OMU internal program blocks and forwarded to the correct WBTS via the
O&M connection. Among the information that this message provides to the WBTS are the
protocols it can use for the license transfer, the (OMS) IP, login and passwords that it should
use, and the directory in the OMS where the license file is located.
30
For internal use
On a correctly working transfer, the WBTS establishes an http session to the OMS with the
provided credentials and gets the license file:
In Nwi3LMagent.txt, the operation starts with the creation of the directory (145334 in the
excerpts below which are from a different transfer, it was 143648 in the screenshot above):
Wed Aug 15 11:14:01 2012 #0006082939 OMS::TRACE DEBUG <OMSFlexiHome.h:33> CLA-0 : OMSFlexiHome::lease_service
called, home interface=IDL:NWI3/LicenceManagement/LicenceOperation_MS_V1:1.0 (0,0) 813ms pgrp=12491 pid=12491
tid=129248144 uid=0 gid=0
Wed Aug 15 11:14:01 2012 #0006082976 OMS::TRACE DEBUG <ImplLicenceOperation_MS_V1.cpp:571> CLA-0 : REV 50975
checkLicenceName - License name: IE000284.XML (0,0) 888ms pgrp=12491 pid=12491 tid=42281872 uid=0 gid=0
Wed Aug 15 11:14:01 2012 #0006082980 OMS::TRACE DEBUG <ImplLicenceOperation_Base.cpp:53> CLA-0 : REV 50975
GetMoidBaseIdAndLocalMoid - BaseId: RNC-463, localmoid: WBTS-151 (0,0) 888ms pgrp=12491 pid=12491 tid=42281872
uid=0 gid=0
Wed Aug 15 11:14:01 2012 #0006082987 OMS::TRACE DEBUG <LicenseFileHelper.cpp:83> CLA-0 : REV 52127 createOneDir -
Directory: /var/opt/OMSftproot/Nwi3LMAgent/145334/ created (0,0) 889ms pgrp=12491 pid=12491 tid=42281872 uid=0
gid=0
Wed Aug 15 11:14:01 2012 #0006083027 OMS::TRACE DEBUG <BTSOMInterface.cpp:167> CLA-0 : REV 52127
downloadRequest - targetId: 0 - baseId: RNC-463, localMoid: WBTS-151 (0,0) 891ms pgrp=12491 pid=12491 tid=3012955024
uid=0 gid=0
Wed Aug 15 11:14:01 2012 #0006083028 OMS::TRACE DEBUG <BTSOMInterface.cpp:170> CLA-0 : REV 52127
downloadRequest - License: IE000284.XML (0,0) 891ms pgrp=12491 pid=12491 tid=3012955024 uid=0 gid=0
Wed Aug 15 11:14:01 2012 #0006083033 OMS::TRACE DEBUG <BTSOMInterface.cpp:127> CLA-0 : REV 52127 ReadFtpKeys -
sFtpUsername: omsFtpUser2, sFtpPassword: hg8rbsE8Z5D8c8X (0,0) 892ms pgrp=12491 pid=12491 tid=3012955024 uid=0
gid=0
31
For internal use
Wed Aug 15 11:14:01 2012 #0006083059 OMS::TRACE DEBUG <LicMgrBTSOMMsgHandler.cpp:244> CLA-0 : REV 52127
SendFileLoadPrepare - License file: /var/opt/OMSftproot/Nwi3LMAgent/145334/RNC-463_WBTS-151/IE000284.XML exist.
(0,0) 895ms pgrp=12491 pid=12491 tid=3000372112 uid=0 gid=0
Wed Aug 15 11:14:52 2012 #0070073635 OMS::TRACE DEBUG <TcpEngine.cpp:878> CLA-0 : epoll_wait-
loop(2289892240)::modifyWanted, DataSocket: DataSocket: fd=7(this=0x7be03358): user data: [empty SocketUserData] peer:
10.200.68.164:62966 local: 10.200.68.167:8002 evs: events[read,write,err,hup] (0,0) 683ms pgrp=13247 pid=13247
tid=2289892240 uid=0 gid=0
The hex dump following „MSG:“ can be matched to the hex dump visible in wireshark, it is
the actual BTSOM message sent to OMU. In the WBTS logs the download request would be
visible in the system module’s runtime log:
32
For internal use
In the problem case faced, the messaging between OMS and NetAct could be seen in the
Northbound interface (IP 172.17.5.150):
and also between OMU and OMS in the Southbound interface (172.17.29.22) the
fileLoadPrepare message is visible being sent to OMU with the correct WBTS ID, but the
connection attempt coming from the WBTSwas not seen in the trace:
33
For internal use
RNW Plan upload from the RNC to Netact was failing with a time out error. The configuration
was SOMS with single IP; 10.80.134.149 is the SOMS IP, 10.72.3.35 is the NetAct IP. Taking a
wireshark trace on the SOMS (in this configuration the IP and interface are the same for
North and Southbound):
Figure 23 TCP SYN packets opening HTTP connection from NetAct to SOMS
The SYN message that starts the http connection used to transfer the file from SOMS to
NetAct can be seen arriving to the SOMS, but there is no reply going out.
And the process was listening on port 80 (and 443 for https) :
C:\>telnet 172.17.5.151 80
Performing a telnet from the SOMS itself to the loopback address a connection on the port
can be opened:
34
The problem was the IPSec configuration in the SOMS, which is stored in the file
/var/mnt/local/sysimg/sets/[…]/opt/Nokia/etc/IPSec/ipsec-policy.xml
#ipmop -show-policy
By running the command zmodifyOMSHTTPandFTPPorts in the SOMS and enabling the HTTP
port the problem was cleared.
./opt/Nokia/SS_Inet/script/verify.sh
# ./verify.sh
====================
--- Start InitPOA!
ConfigPOA done
--- InitPOA done!
--- InitPOA succeeded!
--- ConfigORB done!
--- ConfigORB() succeeded!
TLSMode is "off"
35
For internal use
There are situations where the Topology Upload fails in the SOMS without an upload
request even being sent to OMU; RNW operation such locking/unlocking cells take too long
or timeout before completing. In those cases there are two scripts are available to erase and
recreate the Topology Database:
/var/mnt/remote/sysimg/opt/Nokia/SS_Affe/script/oms_reinsta\ll_topology_db.sh
/opt/Nokia/SS_Affe/script/oms_reinstall_topology_db.sh
When installing the corrs from the default directory described in the documentation
/root/swpack ,the installation failed. This is due to lack of space in the partition where this
directory is located /var/mnt/local/localimg. The problem was cleared by transferring
corrections to home/_nokfsoperator located in partition /var/mnt/local/sysimg/.
There is also a different known issue whereby increment installation may stall. The
workaround for this is described in the document “RNC OMS 1.0 Impact Document for 1.2
v2.0.pdf”, also part of part of the release notes for the RU30 base SW for standalone OMS.
7. References
a) Installing and Commissioning OMS.pdf
b) Integrating IPA-RNC.pdf
c) HP Integrated Lights-Out 2 User Guide.pdf
36
For internal use
8. Appendixes
Pronto checklist.doc
The same MySQL databases present in the Integrated OMS are present in the Standalone
OMS. In the latter case, they will include data for multiple RNCs.
To log in to these databases, the user and password can be input in the following
manner:
37
For internal use
The tables that compose the database, in this case AlarmDB, can be examined with:
+---------------------+
| Tables_in_db_cmplan |
+---------------------+
| cm_feedback_errors |
| cm_feedbacks |
| cm_operations |
| cm_plans |
| cm_plans_dns |
| cm_task_id_dns |
+---------------------+
+---------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------+---------+------+-----+---------+-------+
| plan_id | int(11) | NO | PRI | 0 | |
| task_id | int(11) | NO | PRI | 0 | |
+---------+---------+------+-----+---------+-------+
38