High Availability Support for Azure Deployments

You can configure the SBC to support HA operations over Azure deployments. Azure provides typical virtual interface-based high availability operation, based on its own configuration requirements. This section provides explanation and instruction on the aspects of these deployments related to the SBC.

In an SBC HA pair, the active node handles traffic through a Virtual IP (VIP). If a failover occurs, the VIP is moved to the new active node. To ensure that all devices in the network recognize this change, the SBC sends out a Gratuitous ARP (GARP) message.

However, in cloud environments, the network is managed by the SDN (Software-Defined Network). The SDN controller controls all networking aspects including vNICs, IP addresses, MAC addresses etc. Without the SDN’s knowledge, the attempt to move the VIP address through the GARP message is discarded. As a result, the network doesn’t update properly, and traffic continues to be directed to the old active node.

Hence to work with SDN, the SBC need to invoke an appropriate API provided by the cloud. The cloud infrastructure provides REST API, which can be invoked by implementing simple REST client using commonly known utilities such as CURL. The REST API typically use either JSON or XML as content type. The APIs are typically secure, and the client needs to authenticate with the cloud so that only authorized clients can communicate with the cloud services through the API.

Those aspects of the feature's configuration that are related to the SBC and are documented below, include the following:

  1. Prerequisites
  2. Azure Cloud API authentication
  3. Metadata Server
  4. Caveats

Prerequisites

To prepare for feature deployment on Azure, perform the following pre-requisite steps:

  1. Create two SBC instances.
  2. Enable system-assigned managed identities on both SBC instances. These managed identities allow the instances to access the azure VNIC management REST APIs:
    1. Select the instance
    2. In left navigation pane, select Security
    3. Select Identity
    4. Navigate to System assigned
    5. Status to On
  3. For Azure-HA functionality, create a custom role with the following permissions and assign it to both SBC instances.
    {
        "properties": {
          "roleName": "azure-ha",
          "description": "custom role to switchover SBC floating IPs",
          "assignableScopes": [ 
        "/subscriptions/ed1754e1-ae6b-4642-a110-487c4a800bd9/resourceGroups/VSBC_DEV_RG"
          ],
          "permissions": [
            {
              "actions": [
                "Microsoft.Compute/virtualMachines/read",
                "Microsoft.Network/networkInterfaces/read",
                "Microsoft.Network/networkInterfaces/write",
                "Microsoft.Network/networkInterfaces/ipconfigurations/read",
                "Microsoft.Network/virtualNetworks/subnets/read",
                "Microsoft.Network/virtualNetworks/subnets/join/action",
                "Microsoft.Network/publicIPAddresses/read",
                "Microsoft.Network/publicIPAddresses/join/action"
              ],
              "notActions": [],
              "dataActions": [],
              "notDataActions": []
            }
          ]
        }
      }

    Note:

    Be sure to replace the resource group details with the Actual values in the given custom role.
  4. Add a Custom role using the Azure console:
    1. Navigate to Resource Group > Access Control (IAM)
    2. Click the +Add button and click on Add custom role
    3. Provide a cutom role name and select the json file where we defined the custom role
    4. Click on Review and Create
    5. Click to Create the role
  5. Assign the custom role to the VM:
    1. Select the instance
    2. In left navigation pane, select Security
    3. Select Identity
    4. Navigate to System assigned
    5. Navigate to Permissions
    6. Click on Azure role Assignment
    7. Click on Add role assignment
    8. Select scope as Resource Group, and select the appropriate Resource Group on which the custom role is created
    9. Under the role, select the custom role you created
    10. Click Save
  6. Ensure that the names of the primary and secondary SBCs on the Azure console exactly match with the SBC target names configured in the SBC boot parameters using the ACLI.
  7. Configure the SBCs by enabling redundancy-config.
  8. On the primary SBC instance, configure the required Secondary Private IPs (VIPs) for the media-interfaces. An example of addressing for a four interface SBC is shown in the codeblock below.
    S0P0 Interface: 
vip: 10.1.4.69 , 10.1.4.70, 10.1.4.71
pri-utility-addr: 10.1.4.15   (Primary IP SBC-1)
sec-utility-addr: 10.1.4.17   (Primary IP SBC-2) 

S0P1 Interface:
vip: 10.1.6.6 , 10.1.6.7
pri-utility-addr: 10.1.6.4   (Primary IP SBC-1)
sec-utility-addr: 10.1.6.5   (Primary IP SBC-2)

 S1P0 Interface:
vip: 10.1.5.69, 10.1.5.70
pri-utility-addr: 10.1.5.16  (Primary IP SBC-1)
sec-utility-addr: 10.1.5.17  (Primary IP SBC-2) 

S1P1 Interface:
vip: 10.1.7.6, 10.1.7.7
pri-utility-addr: 10.1.7.4  (Primary IP SBC-1)
sec-utility-addr: 10.1.7.5  (Primary IP SBC-2)
  9. When required, map Secondary Private IPs (VIPs) to Reserved Public IPs by configuring the options parameter of the redundancy-config element using key-value pairs, where the key is the VIP IP-address, and the value is its associated Public IP name.

    If multiple VIPs are configured for media interfaces and require Public IP mapping, list all VIP IP addresses and their corresponding Public IP names as comma-separated key-value pairs in the redundancy-config options parameter as below, then execute save-config and activate-config. 

    redundancy-config        
           peer                
               name sh-ha-SBC-0 
               type Primary               
               destination                       
                 address 10.1.2.4:9090
                 network-interface wancom1:0        
            peer 
               name sh-ha-SBC-1
               type Secondary               
               destination   
                  address 10.1.2.5:9090                       
                  network-interface wancom1:0 
           options 10.1.4.79=shr-test-pip-1,10.1.4.80=shr-test-pip-3,
                   10.1.5.79=shr-test-pip-2,10.1.5.80=shr-test-pip-4
  10. If necessary, configure azure-fetchIfc-interval-msecs in the redundancy-config options parameter, to update the interval time to fetch the interfaces during switch-over/fail-over. This configuration is optional, as azure-fetchIfc-interval-msecs is set to 200ms by default in Azure LUA script.
    redundancy-config        
           peer                
               name sh-ha-SBC-0 
               type Primary               
               destination                       
                 address 10.1.2.4:9090
                 network-interface wancom1:0        
            peer 
               name sh-ha-SBC-1
               type Secondary               
               destination   
                  address 10.1.2.5:9090                       
                  network-interface wancom1:0 
           options azure-fetchIfc-interval-msecs=300

Note:

Do not configure the virtual-mac parameter under any phy-interface

Azure Cloud API authentication

Azure Resource Manager uses Role-Based Access Control mechanism to authorize VM access to Azure services.

Steps to setup access for VM instances:

  1. Enable system-assign managed identity. Managed identities allow the instances to access the azure VNIC management REST APIs.

    System-assigned managed identities have their lifecycle tied to the resource that created them. This identity is restricted to only one resource, and we can grant permissions to the managed identity by using Azure role-based access control (RBAC).

  2. For Azure-HA functionality create a custom role with following permissions and assign it to both SBC instances.
    {
        "properties": {
          "roleName": "azure-ha",
          "description": "custom role to switchover SBC floating IPs",
          "assignableScopes": [ 
        "/subscriptions/ed1754e1-ae6b-4642-a110-487c4a800bd9/resourceGroups/VSBC_DEV_RG"
          ],
          "permissions": [
            {
              "actions": [
                "Microsoft.Compute/virtualMachines/read",
                "Microsoft.Network/networkInterfaces/read",
                "Microsoft.Network/networkInterfaces/write",
                "Microsoft.Network/networkInterfaces/ipconfigurations/read",
                "Microsoft.Network/virtualNetworks/subnets/read",
                "Microsoft.Network/virtualNetworks/subnets/join/action",
                "Microsoft.Network/publicIPAddresses/read",
                "Microsoft.Network/publicIPAddresses/join/action"
              ],
              "notActions": [],
              "dataActions": [],
              "notDataActions": []
            }
          ]
        }
      }
  3. Now the VM can request a bearer token from Azure's IMS (Instance Metadata Service)
  4. The VM uses the pre-authorized token in subsequent requests to Azure services.

Metadata Server

The Azure Instance Metadata Service provides crucial information about an instance. Each region has a dedicated REST endpoint. By leveraging the region details from the metadata, a REST client can determine the appropriate endpoint and construct the necessary REST URLs.

To successfully authenticate the REST API, details such as the location, subscription ID, VM ID, resource group are required.

~ #
          curl -H Metadata:true "http://169.254.169.254/metadata/instance/compute?api-version=2024-07-17"
{
                 "location":"eastus2",
                 "name":"test-ha-SBC-0",
                 "offer":"",
                 "osType":"Linux",
                 "placementGroupId":"",
                 "platformFaultDomain":"0",
                 "platformUpdateDomain":"0",
                 "publisher":"",
                 "resourceGroupName":"VSBC_DEV_RG",
                 "sku":"",
                 "subscriptionId":"ed1754e1-ae6b-4642-a110-487c4a800bd9",
                 "tags":"team:vSBC-DEV-TEAM",
                 "version":"","vmId":"cf39f373-8170-4ca5-a0e7-37c3c887b0a1",
                 "vmScaleSetName":"
                 ","vmSize":"Standard_F4s",
                 "zone":"1"
}