Acme Packet Platforms

Supported Hypervisors for Private Virtual Infrastructures

Oracle supports installation of SBC on the following hypervisors:

• KVM: Linux kernel version 3.10.0-123 or later, with KVM/QEMU (2.9.0_16 or later) and libvirt (3.9.0_14 or later)
• VMware: vSphere ESXi (Version 6.5 or later)

Compatibility with OpenStack Private Virtual Infrastructures

Oracle distributes Heat templates for the Newton and Pike versions of OpenStack. Use the Newton template when running either the Newton or Ocata versions of OpenStack. Use the Pike template when running Pike or a later version of OpenStack.

Supported Public Cloud Platforms

The SBC can be run on the following public cloud platforms.

• Oracle Cloud Infrastructure (OCI) - After deployment, you can change the shape of your machine by, for example, adding disks and interfaces. OCI Cloud Shapes and options validated in this release are listed in the table below.

  Shape	OCPUs/VCPUs	vNICs	Tx/Rx Queues	Max Forwarding Cores	DoS Protection
  VM.Standard1.4	4/8	4	2	2	Y
  VM.Standard1.8	8/16	8	2	2	Y
  VM.Standard1.16	16/32	16	2	2	Y
  VM.Standard2.4	4/8	4	2	2	Y
  VM.Standard2.8	8/16	8	2	2	Y
  VM.Standard2.16	16/32	16	2	2	Y

  Networking using image mode [SR-IOV mode - Native] is supported on OCI. PV and Emulated modes are not currently supported.

• Amazon Web Services (EC2) - This table lists the AWS (ECs) instance sizes that apply to the SBC.

  Instance Type	vCPUs	Memory (GB)	Max NICs
  c5.xlarge	4	8	4
  c5.2xlarge	8	16	4
  c5.4xlarge	16	32	8
  c5.9xlarge	36	72	8
  c5.12xlarge	48	96	8
  c5.18xlarge	72	144	15
  c5n.xlarge	4	10.5	4
  c5n.2xlarge	8	21	4
  c5n.4xlarge	16	42	8
  c5n.9xlarge	36	96	8
  c5n.18xlarge	72	192	15

  Driver support detail includes:

  • ENA is supported on C5/C5n family only.

  Note:

  C5 instances use the Nitro hypervisor.
• Microsoft Azure - The following table lists the Azure instance sizes that you can use for the SBC.

  Size (Fs series)	vCPUs	Memory	Max NICs
  Standard_F4s	4	8	4
  Standard_F8s	8	16	8
  Standard_F16s	16	32	8

  Size	vCPUs	Memory	Max NICs
  Standard_F8s_v2	8	16	4
  Standard_F16s_v2	16	32	4

  Size types define architectural differences and cannot be changed after deployment. During deployment you choose a size for the OCSBC, based on pre-packaged Azure sizes. After deployment, you can change the detail of these sizes to, for example, add disks or interfaces. Azure presents multiple size options for multiple size types.

  Azure sizes that support and expose hyperthreading to the user includes the version 2, F series.

  For higher performance and capacity on media interfaces, use the Azure CLI to create a network interface with accelerated networking. You can also use the Azure GUI to enable accelerated networking.

Platform Hyperthreading Support

Of the supported hypervisors, only VMware does not expose SMT capability to the SBC. Of the supported clouds, OCI, AWS, and, for their FS-v2 sized, Azure enable SMT by default and expose it to the SBC.

DPDK Reference

The SBC relies on DPDK for packet processing and related functions. You may reference the Tested Platforms section of the DPDK release notes available at https://doc.dpdk.org. This information can be used in conjunction with this Release Notes document for you to set a baseline of:

• CPU
• Host OS and version
• NIC driver and version
• NIC firmware version

Default VSBC Resources

The default compute for the SBC image files is as follows:

• 4 CPU Cores
• 8 GB RAM
• 20 GB hard disk (pre-formatted)
• 8 interfaces as follows:
  • 1 for management (wancom0 )
  • 2 for HA (wancom1 and 2)
  • 1 spare
  • 4 for media

Interface Host Mode for Private Virtual Infrastructures

The SBC VNF supports interface architectures using Hardware Virtualization Mode - Paravirtualized (HVM-PV):

• ESXi - No manual configuration required.
• KVM - HVM mode is enabled by default. Specifying PV as the interface type results in HVM plus PV.

Supported Interface Input-Output Modes for Private Virtual Infrastructures

• Para-virtualized
• SR-IOV
• PCI Passthrough
• Emulated - Emulated is supported for management interfaces only.

Supported Ethernet Controller, Driver, and Traffic Type based on Input-Output Modes

For KVM and VMware, accelerated media/signaling using SR-IOV and PCI-pt modes are supported for the following card types.

^Footnote 1 This driver is not supported on KVM.

^Footnote 2 iavf driver is support in SR-IOV n/w mode

For PV mode (default, all supported hypervisors), the following virtual network interface types are supported. You can use any make/model NIC card on the host as long as the hypervisor presents it to the VM as one of these vNIC types.

Emulated NICs do not provide sufficient bandwidth/QoS, and are suitable for use as management only.

• W - wancom (management) interface
• M - media interface

CPU Core Resources for Private Virtual Infrastructures

The SBC S-Cz9.0.0 VNF requires an Intel Core i7 processor or higher, or a fully emulated equivalent including 64-bit SSSE3 and SSE4.2 support.

If the hypervisor uses CPU emulation (for example, qemu), Oracle recommends that you set the deployment to pass the full set of host CPU features to the VM.

Hardware recommendations for Netra Server X5-2

Hardware recommendations for Oracle Server X7-2

Hardware recommendations for Oracle Server X8-2

ORACLE# setup product

--------------------------------------------------------------
WARNING:
Alteration of product alone or in conjunction with entitlement
changes will not be complete until system reboot

Last Modified
--------------------------------------------------------------
 1 : Product       : Uninitialized

Enter 1 to modify, d' to display, 's' to save, 'q' to exit. [s]: 1

  Product
    1 - Session Border Controller
    2 - Session Router - Session Stateful
    3 - Session Router - Transaction Stateful
    4 - Subscriber-Aware Load Balancer
    5 - Enterprise Session Border Controller
    6 - Peering Session Border Controller
  Enter choice     : 1

Enter 1 to modify, d' to display, 's' to save, 'q' to exit. [s]: s
save SUCCESS

Before upgrading the Oracle Communications Session Border Controller software:

Upgrading to S-Cz9.0.0 with IKEv2 LI Tunnels

An HA upgrade to S-Cz9.0.0, when configured with LI Tunnels using IKEv2, can cause IPSec tunnels to fail if an IPsec rekey initiated from a peer has resulted in the IPSec SAs being out of sync across the HA pair. After an upgrade with these conditions, these LI tunnels do not function on the Active node.

Prior to upgrading these deployments determine whether the IKEv2/IPsec SA's are in sync on the Active and Standby node by running the ACLI command show security ipsec sad <network-interface>:vlan detail and check whether the SPI's are same on both the Active and standby node.

• If they are in sync, proceed with the upgrade.
• If the IPsec SA's are not in sync across the HA nodes, perform the following procedure:
  1. If enabled, disable x2-keep-alive from the LI shell. (See procedures in LI documentation.)
  2. Upgrade the Standby node to S-Cz9.0.0.
  3. Wait until the pair reaches HA state.
  4. Configure the Active node to boot to S-Cz9.0.0. (Do not reboot this device yet.)
  5. Delete tunnels on the Active node, which is still running the older software version, using one of the following commands from the CLI root.

     security ipsec delete ike-interface <ike-interface IP address> all

     security ipsec delete tunnel destIP <ipsec tunnels destination ip> spi <inbound spi>

  6. Ensure that tunnel(s) were deleted from both nodes. (If necessary run this command one more time for any new spi.)

     show security ipsec sad <network interface name> detail

  7. Reboot the Active node.
  8. If the IKE interface is in INITIATOR mode, execute the ping command to the applicable IPSec endpoints on the newly Active (S-Cz9.0.0) node to establish new tunnels.

     If the IKE interface is in RESPONDER mode, have peers restart tunnels instead of executing the ping command.

  9. Upon completion of boot cycle of the standby node, verify HA state and proper tunnel synchronization.

Two downgrade procedures are presented below.

1. Rollback after full Upgrade:
   1. HA pair is in highly available state with 840p1 version
   2. Reboot Standby node with downgraded version
   3. Wait until highly available state established
   4. Delete tunnels on the Active node using one of the following commands from the CLI root.

      security ipsec delete ike-interface <ike-interface IP address> all

      security ipsec delete tunnel destIP <ipsec tunnels destination ip> spi <inbound spi>

   5. Ensure that tunnel(s) were deleted from both nodes. (If necessary run this command one more time for any new spi.)

      show security ipsec sad <network interface name> detail

   6. Reboot the Active node.
   7. If the IKE interface is in INITIATOR mode, execute the ping command to the applicable IPSec endpoints on the newly Active (Downgraded) node to establish new tunnels.

      If the IKE interface is in RESPONDER mode, have peers restart tunnels instead of executing the ping command.

   8. Upon completion of boot cycle verify HA state and proper tunnel synchronization.
2. Rollback after Upgrading the active node only:
   1. HA pair is in highly available state with Active node 9.0.0 and Standby node with old version
   2. Configure boot table on Active node with rollback version
   3. Delete tunnels on the Active node using one of the following commands from the CLI root.

      security ipsec delete ike-interface <ike-interface IP address> all

      security ipsec delete tunnel destIP <ipsec tunnels destination ip> spi <inbound spi>

   4. Ensure that tunnel(s) were deleted from both nodes. (If necessary run this command one more time for any new spi.)

      show security ipsec sad <network interface name> detail

   5. Reboot the Active node.
   6. If the IKE interface is in INITIATOR mode, execute the ping command to the applicable IPSec endpoints on the newly Active node to establish new tunnels.

      If the IKE interface is in RESPONDER mode, have peers restart tunnels instead of executing the ping command.

   7. Upon completion of boot cycle of verify HA state and proper tunnel synchronization

SSH Keys

Before upgrading from a pre-8.4 release to this release, delete any imported public keys using the ssh-pub-key delete <key-name> command. Because the commands for SSH key management changed between 8.3 and 8.4, you will not be able to delete old 8.3-type SSH keys using 8.4 (or later) commands. After upgrading, re-import any required public keys. For example, if your SBC pushes records to an SFTP server, import that server's public key as a known host.

If you're upgrading from 8.4 and you didn't previously import the public keys of your SFTP server, import them as a known-host key. Any public keys imported in 8.4 will be available in 9.0.

See "Manage SSH Keys" in the Configuration Guide.

TSCF Configurations from Prior Software Versions

A TSCF configuration that was present on your system before upgrade to this S-Cz9.0.0 release and above, which do not support TSM, may still be present in the configuration file if you do not remove it manually before upgrade. The system does not apply these TSCF configurations on a non-TSM release.

If you subsequently downgrade to a TSM supported release, however, the system applies the TSCF configuration.

Although there is no operational impact, Oracle recommends that you manually remove the TSCF configuration before you upgrade to a non-TSM supported release. If working with an HA pair, be sure your TSM configuration and feature setup is synchronized across the pair during an upgrade. Refer to the procedures in “Setting Up Product-Type, Features and Functionality” and “Setup Features on an HA Pair" in the ACLI configuration Guide.

Acme Packet 3950/4900 Slots

Because there is no slot 1, do not copy over a configuration which contains a phy-interface element that uses slot 1 unless you delete and reconfigure the phy-interfaces.

Encrypting the Surrogate Agent Password

If upgrading from any version prior to S-CZ8.4.0p5, run the spl save acli encr-surrogate-passwords command to save the surrogate-agent passwords in an encrypted format. Later versions do not require this command.

You do not need to run the same spl command on the new standby SBC because it will sync with the new active SBC.

Upgrade Version Caveat from Session Delivery Manager

The Session Delivery Manager cannot direct upgrades from SCZ910p6, SCZ900p8 or SCZ900p9 for HA deployments. See Knowledge Document # 2952935.1 for a detailed explanation.

Upgrading To S-Cz9.0.0 From Previous Releases

When upgrading from a previous release to S-Cz9.0.0, your encryption entitlements carry forward and you do not need to install a new license key.