Viewing Redundancy Statistics

This section explains how to check the redundancy status for Acme Packet High Availability (HA) pairs by using the show redundancy command. Viewing the redundancy statistics provides the following information:

  • General HA statistics
  • Statistics related to HA transactions that have been processed
  • Numerical identifier for the last redundant transaction processed (each transaction is numbered)

In an HA architecture that is functioning properly, the number for the last redundant transaction processed on a standby Oracle Communications Session Border Controller peer should not be far behind (if not exactly the same as) the one shown for the active Oracle Communications Session Border Controller peer.

The show redundancy command’s output displays a time stamp showing when the current period began, the statistics and transactions for high availability and the numerical identifier for the last redundant transaction processed.

Accessing Redundancy Subcommands

The following example shows the show redundancy subcommands. You can display the redundancy statistics for applicable components, including the Middlebox Control (MBC), SIP and for the configuration. Display the subcommands using the ACLI's question mark argument.

ORACLE# show redundancy ?

Configuration Checkpoint Example

The following example shows the configuration checkpointing statistics you can display by using the show redundancy config subcommand.

ORACLE# show redundancy config
18:35:05-105
Redundancy Statistics         -- Period -- -------- Lifetime --------
                    Active    High   Total      Total  PerMax    High
Queued Entries           0       0       0          5       2       1
Records Dropped          -       -       0          0       0
Server Trans             1       1      44        593      78       27
Client Trans             0       0       0          0       0       0
Redundancy Transactions          ---- Lifetime ----
                          Recent      Total  PerMax
Requests received             44        593      78
Duplicate requests             0          2       1
Success responses             44        593      78
Error responses                0          0       0
Request sent                   0          0       0
Retransmissions sent           0          0       0
Success received               0          0       0
Errors received                0          0       0
Transaction timeouts           0          0       0
Avg Latency=0.000 for 0
Max Latency=0.000
Last redundant transaction processed: 5
ORACLE#

About High Availability Transactions

The following table lists the redundancy statistics for the HA transactions for the Lifetime monitoring span. A standby Oracle Communications Session Border Controller (OCSBC) always acts as the client side in a client-server relationship with an active OCSBC peer; the active OCSBC acts as the server. The standby OCSBC peer always sends HA requests to its active OCSBC peer, which always acts as receiver of HA transactions from the standby peer.

Statistic Description
Queued entries Number of transactions the active OCSBC has not yet sent to its standby OCSBC peer.
Red Records Total number of HA transactions created. This set of statistics should be the same as those for Queued entries.
Records Dropped Number of HA transaction records that were lost (i.e., dropped) because the standby OCSBC fell behind in synchronization.
Server Trans This statistic shows the number of HA transactions in which the OCSBC acted as the server side in the client-server relationship. The active HA OCSBC peer is the server.
Client Trans This statistic shows the number of HA transactions in which the OCSBC acted as the client side in the client-server relationship. The standby HA OCSBC peer is the client.
Request-Response Round-Trip Times Combined processing and network round-trip transaction times (RTT). The system displays Request-Response RTT values as the number of times the RTT time result fell into the following ranges:
  • 0 – 2 ms
  • 2 – 4 ms
  • 4 – 8 ms
  • 8 – 16 ms
  • 16 – 33 ms
  • 33 - 67 ms
  • > 67 ms

These statistics measure the time from issuing a request to receiving a response, and therefore, apply only to the standby OCSBC. Recent statistics on the active are always zero. Period statistics on the active are not reset during a switchover.

Request-Response Loss Recent and lifetime percent packets dropped by the OCSBC during HA transactions.

These statistics apply only to the standby. Recent statistics on the active are always zero. Period statistics on the active are not reset during a switchover.

Viewing Border Element Redundancy Protocol Information

You can view Border Element Redundancy Protocol statistics by using the show berpd command.

The border element redundancy protocol responds to alarms, advertisements, and checkpointing. This protocol manages switchovers between active and standby Oracle Communications Session Border Controllers and checkpoints health, media flow, and signaling state information. Using the border element redundancy protocol, HA Oracle Communications Session Border Controller peers communicate through their configured interfaces with User Datagram Protocol (UDP) messages.

In HA operation, each HA Oracle Communications Session Border Controller peer in an HA Oracle Communications Session Border Controller pair uses the border element redundancy protocol to advertise its current state and health so that an active peer can be elected. Using the border element redundancy protocol, HA Oracle Communications Session Border Controller peers communicate with UDP (advertisement or checkpoint) messages which are sent out on one or more rear interfaces (destinations). These checkpoint messages are sent by both HA Oracle Communications Session Border Controller peers in the HA Oracle Communications Session Border Controller pair on a regular basis.

The border element redundancy protocol is sometimes referred to as BERP (e.g., the berpd task/process) by the internal system components

Viewing Redundancy Health

In HA architectures, the show health command displays the following information:

  • Health score

    The health score of a Oracle Communications Session Border Controller is used to determine the active/standby roles of the Oracle Communications Session Border Controllers participating in an HA pair architecture. The healthiest Oracle Communications Session Border Controller peer (the Oracle Communications Session Border Controller peer with the highest health score) is the active Oracle Communications Session Border Controller peer. The Oracle Communications Session Border Controller peer with the lower health score is the standby Oracle Communications Session Border Controller peer.

    The health score is based on a 100-point scoring system. When all system components are functioning properly, the health score of the system is 100.

    If the health score of an active Oracle Communications Session Border Controller peer drops below a configurable threshold, the standby Oracle Communications Session Border Controller peer takes control and initiates an automatic switchover (assumes the active role). The standby Oracle Communications Session Border Controller peer only takes over the active role if its own health score is greater than that of the active Oracle Communications Session Border Controller peer. In the case where an active Oracle Communications Session Border Controller’s health score has reached an unsatisfactory level and therefore the standby Oracle Communications Session Border Controller has taken over, the Oracle Communications Session Border Controller that was originally active assumes the role of the standby system.

  • Whether the current HA Oracle Communications Session Border Controller is active, standby, or out of service
  • The last 20 switchover events in the switchover log

HA States

Refer to the following table for information about each potential HA state.

State Description
Initial HA Oracle Communications Session Border Controller is booting and looking for its configured peers.
BecomingActive HA Oracle Communications Session Border Controller has negotiated to become the active system, but it is waiting for the length of time equal to its configured becoming-active-time to become fully active.

It is important to note that packets cannot be processed in this state. An HA Oracle Communications Session Border Controller must be in the Active state before packet processing can occur.

Active HA Oracle Communications Session Border Controller has waited for the length of time set in the becoming-active-time field and is healthy enough.

This HA Oracle Communications Session Border Controller is handling all media flow and signaling processing.

RelinquishingActive HA Oracle Communications Session Border Controller has been in the Active state, but has begun the switchover process to the Standby state. This state is very brief (i.e., the HA Oracle Communications Session Border Controller quickly transitions from the Active state through the RelinquishingActive state to the BecomingStandby state).
BecomingStandby HA Oracle Communications Session Border Controller has negotiated to become the standby system, but is waiting to become synchronized and fully standby. It remains in this state for the length of time equal to its configured becoming-standby-time.
Standby HA Oracle Communications Session Border Controller is fully synchronized with an active peer.
OutOfService HA Oracle Communications Session Border Controller is not able to synchronize with its peer within the length of time set in the becoming-standby-time field. The HA Oracle Communications Session Border Controller can only transition to this state from the BecomingStandby state.

An active Oracle Communications Session Border Controller will consider its HA Oracle Communications Session Border Controller peer to be in this state if the peer has timed out and not sent a checkpoint message to the active peer within a time period (equal to the percent-drift value multiplied by the advertisement-time value).

HA Logs

The OCSBC logs information about HA operation to assist in troubleshooting and other operational procedures.

The OCSBC performs the following procedures to log HA operations. The OCSBC logs this information to each task's log file regardless of the redundancy-config's log-level setting.

  • Both HA systems log a message for each redundancy journal every 5 minutes, including synchronization state, current size, lifetime record drops, maximum latency, enqueue rate and dequeue rate.
  • The Active OCSBC logs the reason for the status change when the active OCSBC changes the status of the standby OCSBC to Out of Service, along with journal statistics.
  • The Standby OCSBC logs the time it starts resynchronization and the time it becomes synchronized.
  • The Active OCSBC logs the Request-Response RTT and Request-Response Loss Percentage statistics when the standby OCSBC changes to Out of Service.
  • For sipd and mbcd, the number of redundancy objects to be synchronized is logged on the active SBC at the start of re-synchronization.

These log messages are logged to task log files regardless of the log-level of redundancy-config.

Command Examples

Display information about redundancy health by using the show health command.

(available in User Mode)

Active

The following example shows a currently active Oracle Communications Session Border Controller.

ORACLE# show health
        Media Synchronized            enabled
        SIP Synchronized              enabled
        Config Synchronized           enabled
        Collect Synchronized          enabled
        Radius CDR Synchronized       enabled
        Rotated CDRs Synchronized     enabled
        Active Peer Address           163.4.12.2
Redundancy Protocol Process (v2):
        State                           Active
        Health                          100
        Lowest Local Address            11.0.0.1:9090
        1 peer(s) on 1 socket(s):
        systest3B: v2, Standby, health=100, max silence=1050
                  last received from 11.0.0.2 on wancom1:0
        Switchover log:
        Jul 11 14:18:21.442: Active to RelinquishingActive
        Jul 11 14:24:00.872: Standby to BecomingActive, active peer 			systest3B has timed out. The following example that follows shows a 		currently standby Oracle Communications Session Border Controller.

Standby

The following example shows a becoming standby Oracle Communications Session Border Controller.

ORACLE# show health
        Media Synchronized             true
        SIP Synchronized               disabled
        Config Synchronized            true
        Active Peer Address            0.0.0.0
Redundancy Protocol Process (v2):
        State                           Active
        Health                          100
        Lowest Local Address            11.0.0.1:9090
        1 peer(s) on 1 socket(s):
        systest3B: v2, Standby, health=100, max silence=1050
                  last received from 11.0.0.2 on wancom1:0
        Switchover log:
        Jul 11 14:18:21.442: Active to RelinquishingActive
        Jul 11 14:24:00.872: Standby to BecomingActive, active peer systest3B
 has timed out
ORACLE2#

The following table lists the health statistics along with a brief description.

Statistic Description
Media Synchronized Whether or not the media flow is synchronized for both supported protocols: SIP and H.323, (true/false). If media flow information is not available, the Media Synchronized displayed message is displayed in the show health output.
SIP Synchronized Whether or not SIP signaling information is synchronized (true/false). If SIP signaling is not available, the SIP Synchronized disabled message is displayed in the show health output.
Config Synchronized Whether or not configuration information is synchronized (true/false).
Active Peer Address IPv4 address of the current HA Oracle Communications Session Border Controller’s active peer (an HA Oracle Communications Session Border Controller that is currently active does not have an active Oracle Communications Session Border Controller peer and will show 0.0.0.0)