General Settings and System Config Settings
Use the General Settings link on the Configuration tab to reach the General Settings and System Config pages, where you can set the following system-wide parameters.
General
- Network Time Protocol (NTP) servers—Add one or more NTP servers.
- Redundancy Config—Enable and disable HA, identify the primary and secondary devices, and specify synchronization.
- System Config - Set system-wide parameters.
System Config
- System Settings—Set the hostname, location, and default gateway, console timeout, and restart.
- SNMP—Enable and disable SNMP, specify the MIB system, and set SNMP traps and notifications.
- Syslog Servers—Add one or more Syslog servers, specify the system log level, and specify the process log level.
- Communications Monitoring Probe—Enable and disable the Communications Monitor, set the group ID, set the TLS profile, enable and disable QoS, and add one or more Monitor collectors.
- Alarm Threshold—Set the thresholds for one or more types of alarms.
Configure an NTP Server
You can specify one or more Network Time Protocol (NTP) servers for the Communications Broker on the General Settings page by adding their Fully Qualified Domain Names or addresses in a comma-separated list.
Note:
The Communications Broker media interface does not support management traffic for NTP. When configuring connectivity to these resources, do not configure these resources within a media interface subnet range.Redundancy Config / High Availability Settings
You can deploy the Communications Broker in pairs to deliver High Availability (HA) or Redundancy Config.
Two Communications Brokers operating in this way are called an HA node. In the HA node, one Communications Broker operates in the Active mode and the other one operates in Standby mode. In the event of the Active member of the node losing functionality, the system switches over to the Standby member. In the HA model, the two Communications Brokers share the call state and communicate with each other, which keeps sessions and calls from dropping in the event of a call flow disruption.
Oracle recommends configuring High Availability with the run setup command from the ACLI. The command populates the HA fields, which you can also find within the GUI under General Settings.
- The Active Communications Broker checks itself for internal process and IP connectivity issues. If it detects that it is experiencing certain faults, it hands over its role as the Active system to the Standby Communications Broker in the node.
- The Standby Communications Broker is the backup system, fully synchronized with the session status of the Active Communications Broker. The Standby Communications Broker monitors the status of the Active system so that, if needed, it can assume the Active role without the Active system instructing it to do so. If the Standby system takes over the Active role, it notifies network management using an SNMP trap.
Refer to the Oracle Enterprise Session Border Controller ACLI Configuration Guide for more detail about High Availability operations, including:
- Synchronization
- Checkpointing
Overview
To produce seamless switch overs from one Communications Broker to the other, the HA node uses shared virtual MAC and virtual IP addresses for the media interfaces in a way that is similar to VRRP (virtual router redundancy protocol). Sharing addresses eliminates the possibility that the MAC and IPv4 address set on one Communications Broker in an HA node will be a single point of failure. The standby Communications Broker sends ARP requests using a utility IPv4 address and its hard-coded MAC addresses to obtain Layer 2 bindings.
When there is a switchover, the standby Communications Broker issues gratuitous ARP messages using the virtual MAC address, establishing that MAC on another physical port within the Ethernet switch. To the upstream router, the MAC and IP are still alive, meaning that existing sessions continue uninterrupted.
Within the HA node, the Communications Brokers advertise their current state and health to one another in checkpointing messages; each system is apprised of the other’s status. Using Communications Broker’s HA protocol, the Communications Brokers communicate with UDP messages sent out and received on the interfaces carrying "heartbeat" traffic between the active and standby devices.
The standby Communications Broker assumes the active role when:
- It has not received a checkpoint message from the active Communications Broker for a certain period of time.
- It determines that the active Communications Broker’s health score has decreased to an unacceptable level.
- The active Communications Broker relinquishes the active role.
Establishing Active and Standby Roles
Communications Brokers establish active and standby roles in the following ways.
- If a Communications Broker boots up and is alone in the network, it is automatically the active system. If you then pair a second Communications Broker with the first to form an HA node, then the second system to boot up will establish itself as the standby automatically.
- If both Communications Brokers in the HA node boot up at the same time, they negotiate with each other for the active role. If both systems have perfect health, then the Communications Broker with the lowest HA interface IPv4 address will become the active Communications Broker. The Communications Broker with the higher HA interface IPv4 address will become the standby Communications Broker.
If the physical link between the two Communications Brokers fails during boot up or operation, both will attempt to become the active Communications Broker. In this case, processing will not work properly.
Configure Redundancy Config
The Communications Broker supports configuring an pair for High Availability (HA) operations.
- Access Configuration, General-settings, Redundancy Config.
- On the Redundancy Config page, do the following:
- State—Select to enable redundancy. Default: enable. Valid values: enable | disable.
- Advertisement Time—Set the time, in milliseconds, between transmitting redundancy protocol updates. Default: 500ms. Valid values: 50-2147483647ms.
- Percent Drift—Set the percentage of the advertisement time after which the peer is considered unresponsive. Default: 210. Valid values: 100-65535.
- Becoming Standby Time—Set the time, in milliseconds, to wait for complete synchronization. Default:180000. Valid values: 5-50-2147483647ms.
- Cfg Max Trans—Set the maximum number of redundancy config sync transactions to keep on active. Default: 10000. Valid values: 0-4294967295.
- Cfg Sync Comp Time—Set the timeout for subsequent config sync requests after complete redundancy configuration occurs. Default: 1000. Valid values: 0-4294967295.
- Peers—Click Add and do the following to add the
redundancy peer.
- Name—Enter the name of the peer.
- Type—Click Add and set the type of peer. Default: Primary. Valid values: Primary | Secondary | Unknown.
- Expand Destinations and do the following.
- Address—Set the destination address for the peer. Default: 0.0.0.0.
- Network Interface—Set the name for originating messages. Default: eth1:0.
- Click OK.
- Click Save to activate the configuration.
Force an HA Switchover
The Communications Broker allows you to cause a High Availability (HA) switchover manually. Executing the procedure forces the two Communications Brokers in your HA node to trade roles. The Active system becomes Standby, and the Standby becomes Active.
A successful manual switchover requires the following conditions:
- The Communications Broker from which you trigger the switchover must be in one of the following states: Active, Standby, or becoming Standby.
- A manual switchover to the Active state is allowed only on a Communications Broker in the Standby or becoming Standby state when it achieves full media, signaling, and configuration synchronization.
- A manual switchover to the Active state is allowed only on a Communications Broker in the Standby or becoming Standby state when its health score is above the value you configure for the threshold.
Configure System Config
The Communications Broker allows you to specify system identification and global settings by way of the parameters that you specify on the System Config page.
Set the following parameters to configure global system identification information.
SNMP Configuration
Use SNMP to support monitoring of devices attached to the network for conditions that warrant administrative attention on the Communications Broker
Use the MIB settings for informational purposes. The remainder of the parameters enable SNMP and the specific Communications Broker events that you want reported to the SNMP system.
Note that you configure the SNMP community and the trap receiver settings by way of the SNMP icon.
Logging (Syslog)
Logging events is a critical part of diagnosing mis-configurations and optimizing operations. Communications Brokers can send both syslog and process log data to appropriate hosts for storage and analysis.
Overview
The Oracle Enterprise Communications Broker generates two types of logs, syslogs and process logs. Syslogs conform to the standard used for logging servers and processes as defined in RFC 3164.
Process logs are Oracle proprietary logs. Process logs are generated on a per-task basis and are used mainly for debugging purposes. Because process logs are more data inclusive than syslogs, their contents encompass syslog log data when they are sent off box. A special application must be run on a remote server to receive process logs. Please contact your Oracle sales representative directly or calling Oracle Customer support for more information about the process log application.
Syslog and process log servers are both identified by an IPv4 address and port pair.
Process Log Messages
Process log messages are sent as UDP packets in the following format:
<file-name>:<log-message>
In this format, <file-name> indicates the log filename and <log-message> indicates the full text of the log message as it would appear if it were written to the normal log file.
Add a Syslog Server
The Oracle Enterprise Communications Broker requires a connection to at least one Syslog Server to process the log events that the system can generate for diagnosing mis-configurations and for optimizing operations. The Communications Broker supports adding up to eight Syslog servers.
Enterprise Operations Monitor
As a proactive call monitoring solution, the Enterprise Operations Monitor captures and analyzes all required signaling messages and media from the network, providing full correlation and quality metrics in real time.
The Enterprise Operations Monitor enables you to drill down into the captured data for troubleshooting and root-cause analysis of any reported problem related to a user, user group, trunk, network device, or Internet Protocol (IP) address. The Enterprise Operations Monitor Mediation Engine is the application that collects SIP, DNS, ENUM and protocol message traffic received from one or more EOM probes.
You can configure the Communications Broker to act as an EOM probe, or as an exporter, that can:
- Establish an authenticated, persistent, reliable TCP connection between itself and one or more Oracle Enterprise Operations Monitor Mediation Engines.
- Send UTC-timestamped, unencrypted copy of a protocol messages to the Oracle Enterprise Operations Monitor Mediation Engine.
- Accompany the copied message with related data to include the port or vlan on which the message was sent and received, the local and remote IP:port information, and the transport layer protocol.
Add a Monitor Collector
You can configure the probes embedded in the Oracle Enterprise Communications Broker to establish an IPFIX connection with one or more Oracle Enterprise Operations Monitor Mediation Engines (ME) to collect SIP, DNS, ENUM and protocol message traffic for the Enterprise Operations Monitor (EOM) to analyze.
- Configure at least one network interface.
- Obtain the IP address and port number of each target Oracle Enterprise Operations Monitor Mediation Engine that you want to connect.
In the following procedure, the Monitor Collector is the ME.
Configure Communications Monitoring Probe Settings
The Communications Session Monitor is Oracle's Communication Experience Manager. The manager is powered by the Oracle Communications Session Monitor Mediation Engine, a platform that collects SIP, DNS, ENUM, and protocol message traffic received from Oracle Communications Session Monitor Probes. The mediation engine stores the traffic in an internal database, and analyzes aggregated data to provide comprehensive multi-level monitoring, troubleshooting, and interoperability information.
Acting as a Probe, or as an exporter, the Communications Broker can:
- Establish an authenticated, persistent, reliable TCP connection between itself and the Oracle Communications Session Monitor Mediation Engines.
- Send UTC time-stamped, unencrypted copy of a protocol messages to the Mediation Engine.
- Accompany the copied message with related data to include: the port and VLAN on which the message was sent or received, local and remote IP:port information, and the transport layer protocol.