HA Operation

When an OCSBC goes into active state on a public cloud, its REST client requests VIPs. If it does not receive the addressing, it re-issues these requests after 5 seconds, then 10, 20, 40, 80 and finally 160 seconds. If these request fail, it attempts to acquire VIPs every 300 seconds until it succeeds. Upon success, the OCSBC suspends these re-requests and begins to send address verification requests every 300 seconds. These requests verify that the SDN continues to associate this OCSBC with these VIPs.

When moving from Active to any other state, the OCSBC gracefully abandons any outstanding REST client operations.

Configuration Considerations

Key OCSBC configuration considerations across all cloud environments include:

• Do not configure virtual MAC addresses
• Configure VIPs via the cloud's console as secondary private IPs on the media vNICs
• Obtain wancom0 management address via DHCP
• Obtain the wancom0 default gateway via DHCP
• Obtain the cloud's name servers via DHCP, allowing the local DNS resolver to cache cloud infrastructure addressing

Regarding the use of DHCP to obtain addressing, this means that those subnets must have DHCP enabled and DNS name server IPs configured.

Authentication

The public cloud's API requires that the client authenticate with the cloud to successfully invoke the API. Although each cloud has differences between their authentication mechanisms, they are typically categorized as either Provisioning or Automatic. The OCSBC uses Automatic authentication.

With Automatic authentication, the SDN assigns an OCSBC instance with an appropriate role, providing credentials through its instance metadata. The instance does not need to be provisioned with any credentials. These credentials may be temporary and change periodically. As a result, the OCSBC instance does not cache its credentials, obtaining the latest credentials when invoking the API.

DNS Resolver

Because the REST API resolves hostnames into IP addresses, OCSBC needs an active DNS resolver. This ensures that it can forward properly. As part of this feature, the OCSBC enables its DNS resolver when deployed on public clouds. The OCSBC then obtains the name server IPs for the DNS resolution through DHCP. The DHCP client obtains the name server IPs and populates them in the /etc/resolv.conf file. The OCSBC uses the nameservers for DNS resolution when invoking REST API.

Note: The OCSBC must obtain the IP address for the wancom0 interface through DHCP which will provide the name server IPs. Without DHCP, the OCSBC has no mechanism to manually configure the name server IPs.

IP Addressing

The following diagram portrays an IP addressing example applicable to an HA deployment in a public cloud. Note that the external endpoints are SIP peers reachable through internet/public IPs.

The minimum number of subnets is four:

• 1 management (wancom0)
• 1 HA subnet (wancom1)
• 2 media subnets (s0p0 and s1p0)

Additional subnets may include:

• 1 additional HA subnet (wancom2)
• 6 additional media subnets, a total of 8 media subnets

Cloud categories of typical IP addressing includes:

• Private IP—Each vNIC has a primary private IP, and you can add and remove secondary private IPs. The primary private IP address on an instance does not change during the instance's lifetime and cannot be removed from the instance.
• Secondary Private IP—Each VNIC can be assigned additional IP addresses (apart from the primary private IP), from the same subnet, called secondary private IPs.
• Public IP—Each VNIC with a private IP can optionally be assigned with a Public IP. Public IPs can be either:
  • Ephemeral Public IP—A temporary public IP and exists only for the lifetime of the instance.
  • Reserved Public IP (Elastic IP in AWS)—Persistent and exists beyond the lifetime of the instance it's assigned to. You can unassign it and then reassign it to another instance whenever you like.

As you configure IP addressing, note that both OCI and AWS use the terminology, Primary Private IP, which maps to the OCSBC primary-utility-address and Secondary Private IP which maps to the OCSBC secondary-utility-address. Important considerations include:

• A management subnet is typically a public subnet. Each instance that requires management access from outside the cloud needs a public IP assigned. Oracle recommends you use a Reserved Public IP instead of Ephemeral Public IP. HA subnets are private subnets.
• Media subnets can be either public or private subnets depending on where the OCSBC peers are located, as follows:
  • If the OCSBC peers reside in the cloud on the same subnet, you need a private subnet.
  • If the OCSBC peers are reachable through Internet, you need a public subnet.
• For each media subnet the OCSBC is attached to, you need one secondary private IP to act as VIP. Additionally, for each media subnet that requires Internet access, the secondary private IP must be attached to a Reserved Public IP.

RTC Support

This feature is RTC supported. If you make any configuration changes that affect HA operation, the OCSBC immediately issues request for new VIP addressing via its REST client.