Oracle Communications Diameter Signaling Router (DSR)
 

PLA-Support>Sun Systems>CommsGBU>Global Signaling Solutions>SN-SND: Tekelec DSR
 

In this Document

Symptoms

Changes

Cause

Solution

References

Created from <SR 3-14529085821>

Applies to:

Symptoms

During software upgrade activity to DSR 7.1 or later, an individual server or servers may fail when viewed from the active Network Operations Administration and Maintenance (NOAM) server's upgrade screen and indicate "Unable to start application."  Viewing the Task through the GUI will indicate 90% complete and an ERROR stating upgrade failed due application not started.

If logged into the shell of the upgrading server, the /var/TKLC/appw/logs/Process/upgrade.log file will show statements near the end "UPGRADE IS COMPLETE" and "Upgrade returned success!" which contradict the failure reported by the NOAM upgrade screen.

Looking at the NOAM under the Status & Manage / Server screen, the target server will not appear.

This issue also affects SDS.

Changes

The primary change is the upgrade itself, from a software release prior to DSR 7.1 to a release at 7.1 or later.

Cause

In DSR 7.1, the method of resolving hostnames is changed from use of the /etc/hosts file managed throughout the DSR deployment (in unison across all sites) to the use of the Domain Name System (DNS). Normally this should not cause any problem. However, if the standard DNS port (TCP/UDP port 53) is blocked on the XMI and/or IMI paths between or among servers within the deployment (especially hierarchically i.e. NOAM to SOAM/MP, SOAM to MP) then DNS will fail to resolve and the latter steps of the individual server upgrade will fail in this manner.

Solution

The best solution is verify that TCP and UDP port 53 is open throughout the DSR or SDS XMI/IMI network before upgrade begins.

If this problem is encountered during the upgrade and a server is unable to finish, the solution is to determine where the blockage is and get the port opened. Once the blockage has been removed, the upgrade can continue by applying the Appendix titled "RECOVERING FROM A FAILED UPGRADE" in the respective software upgrade guide.

If unable to make network changes quickly, a very temporary work-around may be available depending on the circumstances. Prior to backing out to re-attempt another day, contact Oracle technical support to evaluate and determine if the workaround as applicable.

If the customer is unable to open port 53 in the network the night of upgrade, the server's own XMI entry can be added to its own /etc/hosts file manually.

1. Check the /etc/hosts file to see if the server's own IP address and hostname alias are present.
   
   If present, STOP. This is not the issue and the condition needs further investigation.
2. If not, add them:
   1. Check out hosts file:
      
      [admusr@upgradedButFailedServer ~]$ sudo rcstool co /etc/hosts
   2. Insert the hostname alias and IP address as a line into the /etc/hosts file:
      
      [admusr@upgradedButFailedServer ~]$ sudo vi /etc/hosts
   3. Save
   4. Check in:
      
      [admusr@upgradedButFailedServer ~]$ sudo rcstool ci /etc/hosts

Upon completion, the server should again appear in Status & Manage / Servers screen. It can be selected and the application manually started to allow upgrade to continue.

References

This solution has no attachment