8 Distributing the LNP Database after LSMS-Based Operation or RTDB Copy

After an RTDB copy or a synchronization operation initiated from the LSMS GUI, the remaining NE LNP databases must be synchronized with the newly synchronized NE database. This chapter describes the method to distribute the LNP database to the Service Module cards in the network element.

Introduction

The network element has multiple copies of the LNP database. Synchronization operations are performed on one database. After an RTDB copy or a synchronization operation initiated from the LSMS GUI, the remaining NE LNP databases must be synchronized with the newly synchronized NE database in one of the following ways:

• Automatic Data Distribution

  After the following LNP database synchronization operations, data is distributed automatically from the network element’s newly synchronized LNP database to all other LNP databases at the network element:

  • Automatic resynchronization (see Automatic Resynchronization Process)

  • Reconcile (see Auditing and Reconciling Network Elements from the LSMS)

• Network Element Database is not Required after Copying an RTDB from its mate ELAP

  If network element’s database synchronization is accomplished only by copying an RTDB from its mate ELAP’s RTDB (but not when copying from the mate RTDB is performed after copying an RTDB from the remote mated network element or after a bulk load from the LSMS), it is not necessary to distribute the data to the Service Module cards because they are already synchronized with the RTDB that was used to restore from. Therefore, after the copy, the Service Module cards are now synchronized with both RTDBs.

• Other Network Element Database Distribution

  After other LNP database synchronization operations, the network element main LNP database must be distributed by operator intervention to other LNP databases within the network element (both the mate RTDB and the service module cards). See unresolvable-reference.html#GUID-4DCE85D7-E15B-482F-B188-B54BBCAD7463.

Distributing an RTDB to Service Module Cards

This section describes how to distribute the data from the ELAP RTDB to the Service Module cards after the RTDB has been updated by one of the following actions:

• Copied from an RTDB on the mated network element (see Copying One RTDB from Another RTDB)
• Updated by one of the following operations sent from the LSMS:
  • Bulk loaded from the LSMS (see Managing Bulk Load from the LSMS)
  • Support ELAP Reload Via Database Image (SERVDI) bulk download from the LSMS (see SERVDI Bulk Download)

1. Distribute the imported RTDB onto each Service Module card, which will also silence the LNP database alarms.
   Use one of the following methods:
   1. Method A loads the imported LNP database onto one Service Module card at a time by reloading each Service Module card.
      This method allows the global title translation and LNP functions to continue running while the new RTDB is being loaded. When the Service Module card is reinitializing, its database goes temporarily out of service for the period of time that it takes to reload the database on the Service Module card. The time required to reload the database depends upon the size of the database and can take as long as 23 minutes for an RTDB containing 384 million LNP subscriptions
   2. Method B loads the imported RTDB onto all Service Module cards in the EAGLE by reinitializing all the Service Module cards at once.

      Caution:

      This method not only loads the imported LNP database onto the Service Module cards at the same time, but takes all the Service Module cards out of service and the LNP subsystem will be offline. This method should be used only in emergency situations.

      Method A: Perform steps a and b in this method for each Service Module card, one Service Module card at a time.

      1. Take the Service Module card out of service with the rmv-card command specifying the location of the Service Module card. If there is only one Service Module card in the EAGLE, the force=yes parameter must be specified with the rmv-card command. For this example, enter this command:

         rmv-card:loc=1301

         After successful completion of this command, the EAGLE returns the following output:

         
         rlghncxa03w 06-08-01  11:11:28 GMT  EAGLE5 39.0
         Card has been inhibited.
         

      2. Return the Service Module card to service with the alw-card command with the location of the Service Module card and the option data=persist to allow a warm restart if possible. This command validates that the RTDB on the specified Service Module card is correct. If the RTDB is correct, no further loading is required. If the LNP database is not correct, it is automatically reloaded from the ELAP RTDB; loading may require up to an hour. For this example, enter this command:

         alw-card:loc=1301:data=persist

         After successful completion of this command, the EAGLE returns the following output:

         
         rlghncxa03w 06-06-01  11:11:28 GMT  Eagle5 39.0.0
         Card has been allowed.
         

         When the Service Module card is returned to service, the major alarm is silenced and UAM 0431, LNP database has been corrected, is generated.

      3. Repeat 1 and 2 of Method A for each of the other Service Module cards in the EAGLE.

         If any of the Service Module cards continue to boot, contact the unresolvable-reference.html#GUID-4DCE85D7-E15B-482F-B188-B54BBCAD7463.

      Method B: Load the imported RTDB onto all Service Module cards in the EAGLE by reinitializing all the Service Module cards at once by entering the following command:.

      init-card:appl=vsccp

      Caution:

      This command initializes all the Service Module cards at once and not only loads the imported RTDB onto the Service Module cards at the same time, but takes all the Service Module cards out of service and the LNP subsystem will be offline. This method should only be used in emergency situations.

      Note:

      A more graceful way of initializing the Service Module cards is to reroute all global title translation traffic, including LNP traffic, to the mate network element using the inh-map-ss command. The inh-map-ss command takes the mated application subsystem out of service. When the mated application subsystem is out of service, all global title translation traffic, including LNP traffic, is rerouted to the mate network element.

      The mated application subsystem must be inhibited with theinh-map-ss command before the Service Module cards are reinitialized with theinit-card:appl=vsccp command. After theinit-card:appl=vsccp command has finished executing and all the Service Module cards have reinitialized, return the mated application subsystem to service with thealw-map-ss command.

      When the imported database has been loaded onto each Service Module card, UAM 0431 is displayed for each Service Module card showing that the UAM 0429 has been cleared and the database on the Service Module card matches the database on the MASPs.

      If any of the Service Module cards continue to boot, contact the unresolvable-reference.html#GUID-4DCE85D7-E15B-482F-B188-B54BBCAD7463.

2. Verify that the Service Module cards are in-service by entering the rept-stat-sccp command.
   The state of the Service Module cards, shown in the PST field of the rept-stat-sccp command output, should be IS-NR (in-service normal). If the state of any Service Module card is not IS-NR, contact the unresolvable-reference.html#GUID-4DCE85D7-E15B-482F-B188-B54BBCAD7463.

   Note:

   The rept-stat-sccp command output contains fields that are not used by this procedure. If you want to see the fields displayed by the rept-stat-sccpcommand, see the rept-stat-sccp command description in the Commands User's Guide for EAGLE.