Survivable core server is not registered with the main server

Last Updated : Aug 19, 2013 |

A survivable core server registers with the main server. Under normal conditions a survivable core server may not register with the main server if the survivable core server is resetting. The survivable core server resets when it receives a new translation file or when it is first enabled. This should be a temporary condition.

See Maintenance Commands for Avaya Aura® Communication Manager, Branch Gateways and Servers for errors related to survivable core server registration. Error 257 should be logged when a survivable core server is administered on the main server but is not registered.

Troubleshooting the survivable core server

Procedure

  1. On the main server, run the display survivable-processor essName to verify that the survivable core server is properly administered.

    A survivable core server must be administered on the main server before it can register with the main server. Record the administered values to use when you troubleshoot.

  2. On the main server, run the display events command with a category of denial to display the denial events related to survivable core server. The survivable core server registration denial events are in the 36xx range.

    For descriptions of the survivable core server denial events, see Maintenance Alarms for Avaya Aura® Communication Manager, Branch Gateways Servers.

  3. On the main server, run the list trace ras ip-address command to monitor registration requests from the survivable core server.

    This command displays registration requests from the survivable core server and the associated response from the main server.

    Note:

    Under normal operation, a Keep Alive (KA) message is periodically sent from the survivable core server to the main server. This should not be confused with a registration failure.

  4. On the survivable core server, run the ping nnn.nnn.nnn.nnn command to verify connectivity between the survivable core server and main servers, where nnn.nnn.nnn.nnn is the IP address of the Procr in the main server that the survivable core server is trying to register with.
    Caution:

    n the next steps be careful to use the Close Window button to cancel out of the Network Configuration page to avoid a reboot of the survivable core server. Do not update the system.

    To determine which IP address the survivable core server is attempting to register with use the Server Configuration command from the System Management Interface on the survivable core server to display the Configure ESS page.

  5. Firewalls or other security measures may preclude the main server and survivable core server from communicating. Verify that the following ports are open:
    • Port 1719 Registration between the survivable core server and the main server.

    • Port 21874 Filesync (rsync) is open between the main server and survivable core server.

  6. On the survivable core server, run the Server Configuration pages of the System Management Interface to verify the following:
    1. On the Network Configuration page, verify that the correct Server ID (SVID) is entered. This should be a unique value for each server. The SVID can be between 1 and 256. Gaps in the SVIDs are allowed but the servers may also be consecutively numbered. Each server in the system, duplex or simplex, main server or survivable core server, requires a unique SVID.
    2. On the Configure ESS page, verify that the correct platform type (duplex or simplex) is selected and the correct Processor Ethernet and main server’s IP addresses are entered. The survivable core server uses these addresses to establish a connection and register with the main server (see step 1).
    3. On the Status Summary page, verify that the Cluster ID and the individual server IDs are correct.
      Note:

      The individual server IDs should be the same as the ones that were entered on the Network Configuration page of the Server configuration procedure.

  7. On the survivable core server, run the display system-parameters customer-options command. Verify the administration of the following fields:
    1. The ESS Administration field is set to y
    2. The Enterprise Survivable Server field is set to y
      Tip:

      The customer options can only be set with the Avaya license file. If the fields above are incorrect obtain a new license file with the correct data.

  8. From the System Management Interface, under Administration > Server (Maintenance), click License File, and verify that the license mode is normal.
  9. On the survivable core server, run the status ess clusters command to verify that a translation file has been sent to this survivable core server.

    The translation file is only sent after the survivable core server successfully registers. If a translation file has never been sent, this is an indication of either serious network connectivity issues, Communication Manager administration, and/or configuration errors.