1. Platform Preparation and Installation Guide
  2. Public Cloud Platforms
  3. Deploying the SBC on Cloud Infrastructures in HA Mode
  4. Key SBC Configuration and Operation Detail in HA Mode

Key SBC Configuration and Operation Detail in HA Mode

When the SBC is deployed in an HA configuration in a public cloud, the system's configuration and operation is predominantly the same as in an on-premise HA configuration. The only operational difference is its behavior when going active. Because the SBC knows it is deployed on a public cloud, it automatically replaces its GARP procedures when it goes active with REST calls to fetch VIPs. Going active includes first startup of the primary, as well as the standby taking over because of an HA event.

HA Operation

When an SBC 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 SBC suspends these re-requests and begins to send address verification requests every 300 seconds. These requests verify that the SDN continues to associate this SBC with these VIPs.

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

Configuration Considerations

Key SBC 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 SBC uses Automatic authentication.

With Automatic authentication, the SDN assigns an SBC 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 SBC 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, SBC needs an active DNS resolver. This ensures that it can forward properly. As part of this feature, the SBC enables its DNS resolver when deployed on public clouds. The SBC 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 SBC uses the nameservers for DNS resolution when invoking REST API.

Note: The SBC must obtain the IP address for the wancom0 interface through DHCP which will provide the name server IPs. Without DHCP, the SBC 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 SBC primary-utility-address and Secondary Private IP which maps to the SBC 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 SBC peers are located, as follows:
    • If the SBC peers reside in the cloud on the same subnet, you need a private subnet.
    • If the SBC peers are reachable through Internet, you need a public subnet.
  • For each media subnet the SBC 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 SBC immediately issues request for new VIP addressing via its REST client.