HA Node Connections

You can begin software configuration for your HA node after you have:

Completed the steps for physical set-up and connection.
Noted the target name of the Oracle Communications Session Border Controllers that make up the HA node.
Configured the virtual MAC addresses that you need, according to the type of physical interface cards installed on your Oracle Communications Session Border Controller.

HA Node Connection Configuration

If you are using HA, you need to set the phy-interface configuration parameters described in this section to establish successful connections. These parameters are for rear and media interfaces.

To access the phy-interface menu in the ACLI:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type system and press Enter to access the system-level configuration elements.
```
ORACLE(configure)# system
```
Type phy-interface and press Enter. The system prompt changes to let you know that you can begin configuring individual parameters.
```
ORACLE(system)# phy-interface
ORACLE(phy-interface)#
```
From this point, you can configure phy-interface parameters. To view all phy-interface parameters, enter a ? at the system prompt.

Rear Interfaces

You can use port 1 (wancom1) or port 2 (wancom2) as interfaces to support HA. Do not use port 0 (wancom 0) as that port is reserved for carrying management traffic.

Make sure that the physical connections you have made on the rear panel of your Oracle Communications Session Border Controllers correspond to the configurations you enter for phy-interfaces. You can connect Oracle Communications Session Border Controllers through multiple rear interfaces. For multiple rear interface connectivity, cable both port 1 and port 2 (wancom1 and wancom2) on one Oracle Communications Session Border Controller to port1 and port 2 on the other Oracle Communications Session Border Controller in the HA node.

The Oracle Communications Session Border Controller’s HA function depends heavily on health scores to determine the active and standby roles in an HA node. You can set the amount that will be subtracted from a Oracle Communications Session Border Controller’s health score in the event that a management interface fails for any reason. For example, a connection might become invalid or a cable might be removed inadvertently.

The following example shows how a configured phy-interface will appear in the ACLI for an HA node:

phy-interface
        name                           wancom1
        operation-type                 Control
        port                           1
        slot                           0
        virtual-mac
        wancom-health-score            20

To establish rear interfaces for use in an HA node using the ACLI:

Access the phy-interface menu.
name—Set a name for the interface using any combination of characters entered without spaces. For example: wancom1.
operation-type—Set this parameter to Control.
slot—Set this parameter to 0.
port—Set this parameter to 1 or 2.
wancom-health-score—Enter the number value between 0 and 100. This value will be subtracted from the Oracle Communications Session Border Controller’s health score in the event that a rear interface link fails. We recommend that you change this value from its default (50), and set it to 20.

This value you set here is compared to the active and emergency health score thresholds you establish in the Oracle Communications Session Border Controller HA node (redundancy) configuration.

This parameter has no effect on a phy-interface set to Media as its operation-type.

For multiple rear interface support, configure the remaining, unused rear interfaces with the appropriate values.

The following example shows configuration for multiple rear interface support.

ORACLE(system)# phy-interface
ORACLE(phy-interface)# name wancom1
ORACLE(phy-interface)# operation-type control
ORACLE(phy-interface)# port 1
ORACLE(phy-interface)# wancom-health-score 20
ORACLE(phy-interface)# done
ORACLE(phy-interface)# name wancom2
ORACLE(phy-interface)# operation-type control
ORACLE(phy-interface)# port 2
ORACLE(phy-interface)# wancom-health-score 20
ORACLE(phy-interface)# done

Media Interface Virtual MAC Addresses

To configure HA for the media interfaces in an HA node, you must set one or more virtual MAC addresses, according to the type of physical layer cards you have installed on your Oracle Communications Session Border Controller.

To set a virtual MAC address using the ACLI:

Access the phy-interface configuration.
Configure all relevant parameters as noted in the Phy-Interfaces section of this guide’s System Configuration chapter.

Since virtual MAC addresses are used for media interfaces only, verify that the operation type is set to media.
virtual-mac—Enter the virtual MAC address that you have created using the steps in the Virtual MAC Addresses section.

Alarms and Traps for Wancom1 and 2 Interfaces

You can configure the SBC to trigger alarms and traps when your HA wancom interfaces, including wancom1 and/or wancom2, go down. This allows you to more quickly recognize disruptions and re-establish your HA deployment's functionality.

HA systems synchronize themselves with each other regularly and often, providing short windows within which they can detect link failures, often caused by the switching infrastructure between them. When you configure this feature, the SBC monitors this synchronization and raises an alarm when synchronization fails. To detect synchronization failures in wancom links, the system utilizes a ping mechanism. Using the configured ping interval and retry settings, the system calculates the wait time before raising an alarm if it does not receive a response to the ping message.

You configure two parameters within your redundancy to enable and tune this feature, including:

wancom-ping-interval—Sets the time interval in milleseconds between transmitting wancom ping messages. This parameter is disabled (0) by default.
wancom-ping-retry—Sets the number of times the systems exchange ping retry messages between the wancom links before it raises an alarm and trap. A failed retry is defined as the active receiving no response from the standby.
After ping retries expire, the system continues to exchange ping messages using the interval configuration. When the active receives a ping response again, the system clears the alarm.

ORACLE(redundancy)#wancom-ping-interval 50
ORACLE(redundancy)#wancom-ping-retry 5

The system calculates the wait period by multiplying the (wancom-ping-interval) times the retry times (wancom-ping-retry). When this timer expires, the active SBC raises the alarm.

When the active node beings to receive synchronization responses again, the SBC clears the alarm for the operational wancom interface. Note that you can also clear the alarm manually using the clear-alarm command.

Reporting

You can run the show redundancy config to monitor the round trip time of the wancom ping messages' request-response times on the Active node. You can refer to these values to identify incorrect wancom connectivity failure alarms. These delays can be caused by delays in network rather than link failures. Refer to the Request-Response Loss and the HW Timing Distribution values at the bottom of this output to determine whether an alarm was raised because of network delays rather than link failures.

ORACLEHA1# show redundancy config
11:10:44-198
Redundancy Statistics         -- Period -- -------- Lifetime --------
                    Active    High   Total      Total  PerMax    High
Queued Entries           0       0       0          3       2       2
Red Records              0       0       0          3       2       2
Records Dropped          -       -       0          0       0
Server Trans             9       9      83    4691627      49      16
Client Trans             0       0       0         20      20       1

11:10:44-198
Redundancy Transactions          ---- Lifetime ----
                          Recent      Total  PerMax
Requests received             83    4691627      49
Duplicate requests             0          0       0
Success responses             83    4691626      49
Error responses                0          1       1
Request sent                   0         20      20
Retransmissions sent           0          0       0
Success received               0         18      18
Errors received                0          1       1
Transaction timeouts           0          0       0
Avg Latency=0.000 for 0
Max Latency=0.000
Last redundant transaction processed: 3

11:10:44-198
Request-Response Loss %       ---- Lifetime ----
                        Recent      Total PerMax
                             0          0      0

11:10:44-198
HA  timing distribution:    0ns to    2ms to    4ms to    8ms to   16ms to   33ms to   67ms to
=======================        2ms       4ms       8ms      16ms      33ms      67ms       ---

Transaction Latency
   Request-Response RTT:         7         2         3         2         3         2         0

RTT is the time from which the active issues a wancom ping request and it receives a response. When RTT is long, due to a sluggish network, the system may issue false alarms. When referring to RTT values, note that low counts in higher latency ranges suggest good performance, while high counts might indicate network issues.

Recommended Configuration

Oracle recommends you configure your wancom ping settings having considered the following:

Recommended values to configure wancom-ping-interval and wancom-ping-retry for raising wancom sync failure alarms/traps include 100 milliseconds and 2 retries, respectively. With these values, the SBC sends the ping messages at a frequency of 100 msec to each wancom interface and raises the alarm(s) if two consecutive messages from either or both wancom interface do not receive a response.
Evaluate and consider other network factors, such as delay and round-trip time (RTT), when configuring these values.
Adjusting the wancom-ping-interval to be more aligned with the advertisement-time allows for a quicker response to any synchronization failures because this reduces the time to identify and address them. Oracle recommends you keep the wancom-ping-interval lower than half of the ‘advertisement-time’ for more effective monitoring and timely detection of failures.
Do not configure these parameters with very low values to minimize the number of transmissions. Choose your parameter values based on a comprehensive assessment of network conditions and requirements.

Alarms

The SBC raises the following alarms within the context of this feature:

APP_WANCOM1_SYNC_FAILURE (327752)—Alarm is raised when wancom1 link between active and standby SBC is down.
APP_WANCOM2_SYNC_FAILURE (327753)—Alarm is raised when wancom2 link between active and standby SBC is down.

These alarms will be logged in log.brokerd and acmelog files in /opt/logs/.

ID      Task  Severity    First Occurred        Last Occurred
327753  2800      4       2024-03-01 07:48:43   2024-03-01 07:48:43
Count Description
1 Sync failure for Wancom2

The SBC clears these alarms when the criteria that caused the alarm clears.

Traps

Assuming you have configured SNMP, the SBC issues the apWancomSyncFailTrap and apWancomSyncFailClearTrap traps at the same time as the synchronization failure alarms. The SBC sends the apWancomSyncFailTrap trap, along with the alarm, when the connection between either wancom1 or 2 fails. Similarly, the SBC sends the apWancomSyncFailClearTrap when the connection resumes. These traps include details about the applicable wancom interface. The numeric OIDs for these traps are:

apWancomSyncFailTrap = 1.3.6.1.4.1.9148.3.16.2.2.7.0.1
apWancomSyncFailClearTrap = 1.3.6.1.4.1.9148.3.16.2.2.7.0.2

The system manages these traps from the ap-apps.mib file.

HA Node Parameters

To establish a pair of Oracle Communications Session Border Controllers as an HA node, you need to configure basic parameters that govern how the Oracle Communications Session Border Controllers:

Transition on switchover
Share media and call state information
Checkpoint configuration data

The following example shows what an HA configuration might look like in the ACLI.

redundancy-config
        state                                   enabled
        log-level                               INFO
        health-threshold                        75
        emergency-threshold                     50
        port                                    9090
        advertisement-time                      500
        percent-drift                           210
        wancom-ping-interval                    0
        wancom-ping-retry                       2
        initial-time                            1250
        becoming-standby-time                   180000
        becoming-active-time                    100
        cfg-port                                1987
        cfg-max-trans                           10000
        cfg-sync-start-time                     5000
        cfg-sync-comp-time                      1000
        gateway-heartbeat-interval              0
        gateway-heartbeat-retry                 0
        gateway-heartbeat-timeout               1
        gateway-heartbeat-health                0
        media-if-peercheck-time                 0
        options

You need to configure the two Oracle Communications Session Border Controllers to be HA node peers. To enable configuration checkpointing, you must to configure two peers in the ACLI, one for the primary and one for the secondary Oracle Communications Session Border Controller. The HA node peers configuration also allows you to configure destinations for where to send health and state information. Unless you create Oracle Communications Session Border Controller peers and destinations configurations, HA will not work properly.

The following example shows what an HA configuration might look like in the ACLI.

peer
                name                           netnetsd1
                state                          enabled
                type                           Primary
                destination
                        address                        169.254.1.1:9090
network-interface              wancom1:0
peer
                name                           netnetsd2
                state                          enabled
                type                           Secondary
                destination
                        address                        169.254.1.2:9090
                        network-interface              wancom1:0

HA Node Parameter Configuration

To configure general HA node parameters using the ACLI:

In Superuser mode, type configure terminal and press Enter.
```
ORACLE# configure terminal
```
Type system and press Enter to access the system-level configuration elements.
```
ORACLE(configure)# system
```
Type redundancy and press Enter.
```
ORACLE(system)# redundancy
```
From here, you configure basic HA node parameters. To view all basic HA node parameters, enter a ? at the system prompt.
state—Leave this parameter set to enabled for HA to work. To stop HA operation, set this parameter to disabled. The default value is enabled. The valid values are:
- enabled | disabled
log-level—Set the log level you want to use for the HA system process. The value you set in this field overrides any log level value you set for the entire Oracle Communications Session Border Controller in the system configuration process log level parameter. The default value is INFO which allows you to receive a moderate amount of detail. The valid values are:
- emergency | critical | major | minor | warning | notice | info | trace | debug | detail
health-threshold—Enter a value between 0 and 100 to set the health score at which the Oracle Communications Session Border Controllers in the HA node gracefully exchange active-standby roles. The default value is 75. The valid range is:
- Minimum—1
- Maximum—100
  
  For example, if this field is set to 75 and the active Oracle Communications Session Border Controller’s health score falls below that point, the standby Oracle Communications Session Border Controller will take over the active role. However, Oracle Communications Session Border Controller will only take over the active role if its own health score is 75 or better.
emergency-threshold—Enter the health score for the standby Oracle Communications Session Border Controller to become active immediately. The default value is 50. The valid range is:
- Minimum—0
- Maximum—100
  
  If the standby Oracle Communications Session Border Controller is initializing and the active Oracle Communications Session Border Controller’s health score is below the health threshold, the standby Oracle Communications Session Border Controller will take the active role and there will be a graceful switchover. If the active Oracle Communications Session Border Controller’s health score is below the emergency threshold, then the switchover will be immediate.
  
  If the standby Oracle Communications Session Border Controller has a health score below the emergency threshold and the active Oracle Communications Session Border Controlleris unhealthy, the active Oracle Communications Session Border Controller will not give up its active role.
advertisement-time—Enter the number of milliseconds to set how often Oracle Communications Session Border Controllers in an HA node inform each other of their health scores.

We recommend you leave this parameter set to it’s default, 500. The valid range is:
- Minimum—50
- Maximum—999999999
percent-drift—Enter the percentage of the advertisement time that you want one member of the HA node to wait before considering the other member to be out of service. For the standby Oracle Communications Session Border Controller, this is the time it will wait before taking the active role in the HA node. The default value is 210. The valid range is:
- Minimum—100
- Maximum—65535
wancom-ping-interval—Set the time between transmitting wancom ping messages (milliseconds).
- Default: 0 (Disabled)
- Values to enable: Min: 40 | Max: 999999999 ms
  
  Note:
  This value must be less than your advertisement-time value.
wancom-ping-retry—Set the number of times the system generates wancom ping retries after there has been no response.
- Default: 2
- Values: Min: 1 | Max: 655
  
  Note:
  This value must be less than or equal to percent-drift/100.
initial-time—Enter the number of milliseconds to set the longest amount of time the Oracle Communications Session Border Controller will wait at boot time to change its state from initial to either becoming active or becoming standby. The default value is 1250. The valid range is:
- Minimum—5
- Maximum—999999999
becoming-standby-time—Enter the number of milliseconds the Oracle Communications Session Border Controller waits before becoming standby, allowing time for synchronization. If it is not fully synchronized within this time, it will be declared out of service.

We recommend that you do not set this parameter below 45000. If a large configuration is being processed, we recommend setting this parameter to 180000 to allow enough time for configuration checkpointing. The default value is 45000. The valid range is:
- Minimum—5
- Maximum—999999999
becoming-active-time—Enter the number of milliseconds that the standby Oracle Communications Session Border Controller takes to become active in the event that the active Oracle Communications Session Border Controller fails or has an intolerably decreased health score. The default value is 100. The valid range is:
- Minimum—5
- Maximum—999999999

HA Node Peer Configuration

To configure a Oracle Communications Session Border Controller as an HA node peer:

From the redundancy menu, type peers and press Enter.

ORACLE(system)# redundancy
ORACLE(redundancy)# peers

state—Enable or disable HA for this Oracle Communications Session Border Controller. The default value is enabled. The valid values are:
- enabled | disabled
name—Set the name of the HA node peer as it appears in the target name boot parameter.

This is also the name of your system that appears in the system prompt. For example, in the system prompt ORACLE1#, ORACLE1 is the target name for that Oracle Communications Session Border Controller.
type—These values refer to the primary and secondary utility addresses in the network interface configuration. To determine what utility address to use for configuration checkpointing, set the type of Oracle Communications Session Border Controller: primary or secondary.

Note:
You must change this field from unknown, its default. The valid values are:
- primary—Set this type if you want the Oracle Communications Session Border Controller to use the primary utility address.
- secondary—Set this type if you want the Oracle Communications Session Border Controller to use the secondary utility address.
- unknown—If you leave this parameter set to this default value, configuration checkpointing will not work.

HA Node Health And State Configuration

To configure where to send health and state information within an HA node:

From the peers configuration, type destinations and press Enter.
```
ORACLE(rdncy-peer)# destinations
ORACLE(rdncy-peer-dest)#
```
address—Set the destination IPv4 address and port of the other Oracle Communications Session Border Controller in the HA node to which this Oracle Communications Session Border Controller will send HA-related messages. This value is an IPv4 address and port combination that you enter as: IPAddress:Port. For example, 169.254.1.1:9090.
- The IPv4 address portion of this value is the same as the IPv4 address parameter set in a network interface configuration of the other Oracle Communications Session Border Controller in the HA node.
- The port portion of this value is the port you set in the Oracle Communications Session Border Controller HA Node/redundancy configuration for the other Oracle Communications Session Border Controller in the node.
network-interface—Set the name and subport for the network interface where the Oracle Communications Session Border Controller receives HA-related messages. Valid names are wancom1 and wancom2. This name and subport combination must be entered as name:subport; for example, wancom1:0.

The network interface specified in this parameter must be linked to a phy-interface configured with rear interface parameters. The phy-interface’s operation type must be control or maintenance, and so the subport ID portion of this parameter is 0. The subport ID is the VLAN tag.