iPECS UCP - Redundant System Processor

iPECS UCP
Feature Description and Operation Manual Issue 1.3
193
2.68 Redundant System Processor
Description
The iPECS UCP system supports redundant processor operation. The redundant system
processor is a hot standby processor. The LAN2 port of the master iPECS UCP module is
connected directly to theLAN2 port of the standby UCP module for local redundancy, in which
case the LAN2 ports may be connected over the LAN or WAN. The standby iPECS UCP
module monitors the active iPECS UCP module LAN1 and LAN2 port and takes over system
control if the:
 active UCP module power fails.
 active UCP module is reset.
 LAN1 or 2 connection to the active iPECS UCP module fails or is removed, or,
 standby UCP module does not receive a polling message from the active UCP
module for 1 minute.
If failure occurs, the standby UCP module will take over and maintain control of the system.
When the original master recovers from failure, it functions in the standby mode. The active
UCP module will maintain the system database for both the active and standby processor.
Operation
Conditions
Operation of redundant processors is automatic when installed.
1. The Master/Slave switch on the main iPECS UCP module must be set in the
Master position and the stand-by UCP module must be set in the Slave position to
match the system Admin settings.
2. All eight wires of the Cat 5 cable must be terminated on the RJ45 connectors.
3. It is not possible to use the built-in Voice Mail, a UVM or external VM should be
installed when CPU redundancy is required. If you enable redundancy
(Redundancy Attributes CPU Redundancy Usage),the built-in Voice Mail is
placed “OUT of Service”.
4. With Geographic Redundancy active, both the Master and Slave can be active at
the same time.
5. With local redundancy both the Master and Slave can be active at the same time if
theLAN2 cable is out of order. These dual active processor conditions can be
addressed using the IP Watch time. When the timer is set, the Master sends an
ARP packet from the LAN1 port to the Slave at the timer interval allowing the Slave
can to determine the state of the Master. If the Slave receives an ARP packet,
even though the LAN2 port fails it will not become the active processor thus
preventing the potential for a dual processor active condition.