Reconnecting Network Elements

The following procedures explain how to reconnect the LSMS with network element software that manages database updates from the LSMS. Reconnecting is required in one of the following situations:

When you switch from the main LSMS to the shadow LSMS after a disaster has occurred
When you switch from the shadow LSMS back to the main LSMS after the main LSMS has been restored
When you restore an LSMS that had no shadow

Perform the procedures described in the following sections. (In these procedures, the “source LSMS” is the LSMS you switch from and the “destination LSMS” is the LSMS you switch to.)

“Preparing to Reconnect Network Elements”
“Reconnecting Network Elements Procedures”

These procedures will be followed by automatic resynchronization as described in Automatic Resyncronization after Reconnect.

Preparing to Reconnect Network Elements

Locate the completed Disaster Recovery Sheet.
Alert the My Oracle Support (MOS) that you are switching to the destination LSMS.
The My Oracle Support (MOS) will remain online to provide support during this procedure.
From the network element, enter the following command to verify that the destination LSMS is reachable, where <LSMS_IP_Address> is the IP address of the LSMS:
> ping <LSMS_IP_Address>
From the destination LSMS, enter the following command to verify that the network element (NE) is reachable:
# ping <ELAP_IP_Address>
If the destination LSMS is not already running, log in as a user in the lsmsadm group to the destination LSMS and start an LSMS GUI session.
Verify that the destination LSMS is in stable condition by checking the following:
1. Verify that there are no active alarm conditions.
  Because the destination LSMS is not connected with the EMS, there are always error messages regarding the network element queue level alarms and its connection with the LSMS. For a destination LSMS, these messages are normal. If the Surveillance feature is active, these normal messages will be notifications LSMS 0004 and LSMS 8003 or LSMS 8004. (For more information, see Automatic Monitoring of Events)
2. Verify that the NPACs are connected to the LSMS by examining the NPAC status area on a graphical user interface; verify that the NPAC icon for each supported NPAC displays green.
3. Use following method to verify that no LSMS hardware failure indications are present:
  If the Surveillance feature is active, verify that no hardware failure notifications (LSMS 4003, LSMS 2000, LSMS 0001, LSMS 4004, LSMS 4005, LSMS 4006, LSMS 4007, or LSMS 4009) have been posted. For more information about these notifications, see Automatic Monitoring of Events
4. Verify that the LSMS is not currently in recovery mode with any NPAC by ensuring that none of the following GUI notifications have been posted for any NPAC, where <PRIMARY|SECONDARY> indicates whether the NPAC to be connected is the primary NPAC or the secondary NPAC:
```
[Critical]: <Timestamp> 2006: NPAC <PRIMARY|SECONDARY> Bind Timed Out - Auto retry after 2 min
[Critical]: <Timestamp> 2007: NPAC <PRIMARY|SECONDARY> Connection Aborted by PEER - Auto retry same host 
after 2 min
[Critical]: <Timestamp> 2008: NPAC <PRIMARY|SECONDARY> Connection Aborted by PEER - Auto retry other host 
after 2 min
[Critical]: <Timestamp>: 2009 NPAC <PRIMARY|SECONDARY> Connection Aborted by Provider - Auto retry same 
host after 2 min
[Critical]: <Timestamp> 2010: NPAC <PRIMARY|SECONDARY> Connection Aborted due to recovery failure - Auto 
retry after 2 min
[Critical]: <Timestamp> 2012: NPAC <PRIMARY|SECONDARY> Connection Attempt Failed : Access Control Failure
[Critical]: <Timestamp> 2014: NPAC <PRIMARY|SECONDARY> Connection Attempt Failed : Access Denied
[Critical]: <Timestamp> 2015: NPAC <PRIMARY|SECONDARY> Connection disconnected by NPAC
[Critical]: <Timestamp> 2018: NPAC iiii Recovery Failed
[Critical]: <Timestamp> 2019: NPAC iiii Recovery Partial Failure
[Critical]: <Timestamp> 2020: NPAC iiii Security Violation. Association aborted
```
  Also, if the Surveillance feature is active, verify that none of the following Surveillance notifications have been posted for any NPAC, where xxxxxxx is the hostname of the server reporting the notification, <PRIMARY|SECONDARY> indicates the primary or secondary NPAC, <NPAC_cust_ID> is a numeric indicator for the NPAC region, and <NPAC_IP_address> is the IP address of the NPAC:
```
LSMS2000|14:58 Jul 22, 1997|xxxxxxx|Notify:Sys Admin - NPAC interface failure
LSMS2001|14:58 Jul 22, 1997|xxxxxxx|Notify:Sys Admin - NPAC= <PRIMARY|SECONDARY> - <NPAC_cust_ID>
LSMS2002|14:58 Jul 22, 1997|xxxxxxx|Notify:Sys Admin - NPAC= <NPAC_IP_address>
```
  If any of these notifications has been posted, verify that the following GUI notifications have been posted for the same NPAC:
```
[Cleared] 2025: <Timestamp>: NPAC <PRIMARY|SECONDARY> Connection Successfully established
[Cleared] 8055: <Timestamp>: NPAC <PRIMARY|SECONDARY> Recovery Complete
```

Continue with the next procedure.