ICM and Synchronization

Introduction

The Synchronizer is one of the core functions of the Cisco Intelligent Contact Management (ICM) system. Two Synchronizers communicate with each other to ensure that both sides of the system see the same input messages in the same order. Each Synchronizer receives input messages logically, and forwards them to the other Synchronizer. At any given time, one Synchronizer is enabled and the other is disabled.

Note: In the case of routers, you can see a Paired Enabled status. In the case of duplexed Peripheral Gateways (PG), you can see them run as Peer Disabled, in which case, the enabled Synchronizer must determine the order of input messages.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Networking basics

• Cisco ICM

Components Used

The information in this document is based on these software and hardware versions:

• Cisco ICM 4.6.2 and later

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Synchronizer States

Here are descriptions of possible Synchronizer states:

Connecting

This is the initial state of the Synchronizer. The Synchronizer attempts to establish a connection with the remote Synchronizer over the dedicated path. A connection timer expires if the Synchronizers are unable to establish a connection within a reasonable period (approximately 30 seconds).

Testing

The Synchronizer is unable to communicate with the remote Synchronizer over the dedicated path, and uses the Test-Other-Side procedure to decide whether to become enabled or disabled.

Paired-Enabled

The Synchronizer is in communication with the remote Synchronizer (paired), and performs ordering of the messages (enabled).

Paired-Disabled

The Synchronizer is in communication with the remote Synchronizer (paired), but does not perform ordering of the messages (disabled).

Isolated-Enabled

In this state, the Synchronizer does not communicate with the remote Synchronizer (isolated), and performs ordering of the messages. In effect, the Synchronizer operates its side of the system in a non-fault-tolerant mode.

Isolated-Disabled

The Synchronizer does not communicate with the remote Synchronizer (isolated), and does not perform ordering of the messages (disabled). In effect, the Synchronizer prevents the operation of its side of the system.

If a router senses this state, a message is sent to all PGs that have active connections with this side to re-align with the other side. MDS goes out of service, and causes all processes that use the router mds (such as, rtr, lgr, agi, incrpnic) to exit and be re-started by Node Manager.

Possible Scenarios

This section lists the possible scenarios that you can encounter.

What if my Router is affected by a failure over the private network?

Whenever communication over the dedicated path is lost, both Synchronizers check to see whether they are connected to a majority of the configured devices. If so, the Synchronizers behave normally (for example, the enabled Synchronizer remains enabled, and the disabled Synchronizer invokes Test-Other-Side (TOS)).

If a Synchronizer discovers that it is not connected to a majority of the configured devices, the Synchronizer shifts immediately to the Isolated-Disabled state, and the disabled side also sends a message to any PG with an active connection to reconnect to the other (active) side. At this point MDS goes out of service on the disabled side, and the processes restart. After restart, the TOS process starts over again (a series of keep-alive packets sent over the public network through a PG to the peer to acknowledge the status), so some level of "fault tolerance" remains in place, although severely limited and slow.

If the private network fails, and the disabled side does not have a connection to a majority of PGs over the visible WAN, it transitions immediately to the Isolated-Disabled MDS state. While in this state, the side does not go active. It is considered incapable of routing, so even if the enabled side goes down, this side remains inactive, and just polls the other side, while it waits for the process to recover.

Some similar scenarios can occur on the enabled side also. The enabled side attempts to stay enabled after a failure, as long as it keeps the majority PG connection. If it does not, it also shifts to Isolated-Disabled. If the disabled side also loses connection with a majority of PGs, a double failure situation occurs.

Table 1 lists the results of TOS and actions.

Table 1 – Results of TOS and Actions

Router	Action
Peer is enabled	Stay disabled - MDS goes out of service; lgr and rtr process exit, and are restarted by Node Manager.
Peer is disabled	Become enabled.
Unreachable	Become enabled.
Time-out	Stay disabled - MDS goes out of service, lgr and rtr process exit, and are restarted by Node Manager.

What if it is a PG affected by a failure other than the private network?

When there is a loss of dedicated path to partner, the PGs cannot communicate with each other if the dedicated path between the PGs that make up a PG pair is lost. In this case, the PG active at the time remains active, and the other PG continually attempts to re-establish the dedicated path over the private network connectivity, and send a TOS request to the Router to check the peer status. The active PG continually tries to re-establish the dedicated path.

Why is there different treatment in the case of the Router?

The system is seriously impaired when a private network does not work or when a connection to the active PGs is lost. Consider it a simplexed system, because there is no longer any timed failover response (heartbeats). If the active side goes down, the disabled side is not activated until it has reached that point in its cycling in which it checks the PG connections, runs the TOS, finds the other side to be disabled, and finally activates. The entire procedure could take a couple of minutes before routing is restored.

Why does this happen?

The overall architecture is studied to prevent a situation where two routers with different configuration information route the call, because this can send a different label to the network.

Related Information

• Technical Support & Documentation - Cisco Systems