Supported Hypervisors for Private Virtual Infrastructures

Oracle supports installation of the 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)
• Microsoft Hyper-V: Microsoft Server (2012 R2 or later)

Compatibility with OpenStack Private Virtual Infrastructures

Oracle distributes Heat templates for the Newton and Pike versions of OpenStack. Download the source, nnSCZ910_HOT.tar.gz, and follow the OpenStack Heat Template instructions.

You extract two files from this source, including:

• nnSCZ910_HOT_pike.tar
• nnSCZ910_HOT_newton.tar

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

You can run the SBC 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	Memory
  VM.Standard2.4	4/8	4	2	2	Y	60
  VM.Standard2.8	8/16	8	2	2	Y	120
  VM.Standard2.16	16/32	16	2	2	Y	240
  VM.Optimized3.Flex-Small	4/8	4	8	6Foot 1	Y	16
  VM.Optimized3.Flex-Medium	8/16	8	15	14Foot 2	Y	32
  VM.Optimized3.Flex-Large	16/32	16	15	15	Y	64

  ^Footnote 1 This maximum is 5 when using DoS Protection

  ^Footnote 2 This maximum is 13 when using DoS Protection

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

  Note:

  Although the VM.Optimized3.Flex OCI shape is flexible, allowing you to choose from 1-18 OCPUs and 1-256GB of memory, the vSBC requires a minimum of 4 OCPUs and 16GB of memory per instance on these Flex shapes.
• Amazon Web Services (EC2)

  This table lists the AWS 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.

  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, Azure , and FS-v2 AWS shapes 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

The DPDK version used in this release is:

• 20.11

As of version S-Cz9.1.0p2, the DPDK version used in this release is:

• 21.11

Default vSBC Resources

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

• 4 vCPU 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 3 This driver is supported on VMware only.

^Footnote 4 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

Virtual SBCs for this release 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 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:

Acme Packet 3900 Platform

When you upgrade software, if the session-capacity is configured to a value greater than the 8000 supported sessions on the 3900, an upgrade from 8.4 to 9.0 (and above) may cause an outage as the session-capacity is reset to 0 (not 8000).

Acme Packet 4900 and 3950 Platforms

There is no upgrade on the Acme Packet 4900 and 3950 platforms from any SBC software version prior to S-Cz9.0.0. This is because S-Cz9.0.0 is the first version these platforms support.

Upgrading from releases earlier than S-Cz8.4.0

The S-Cz8.4.0 release included significant changes that hardened the security of the SBC. These changes require your careful evaluation regarding functionality when upgrading to S-Cz8.4.0 or newer. These changes are also applicable to customers upgrading from releases prior to S-Cz8.4.0 to this release. Take care to review this information in the S-Cz8.4.0 Release Notes: Upgrade and Downgrade Caveats

Upgrading to S-Cz9.1.0 with IKEv2 LI Tunnels

An HA upgrade to S-Cz9.1.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.1.0.
  3. Wait until the pair reaches HA state.
  4. Configure the Active node to boot to S-Cz9.1.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.1.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.1.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

Connection Failures with SSH/SFTP Clients

If you upgrade and your older SSH or SFTP client stops working, check that the client supports the mimumum ciphers required in the ssh-config element. The current default HMAC algorithm is hmac-sha2-256; the current key exchange algorithm is diffie-hellman-group14-sha256. If a verbose connection log of an SSH or SFTP client shows that it cannot agree on a cipher with the SBC, upgrade your client.

TSCF Configurations from Prior Software Versions

A TSCF configuration that was present on your system before upgrade to this S-Cz9.1.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

If upgrading to the new Acme Packet 3950/4900 hardware, review the slot numbering in the appendix of the Installation Guide in order to configuration the phy-interface elements.

Diffie-Hellman Key Size

In the context of TLS negotiations on SIP interfaces, the default Diffie-Hellman key size offered by the SBC is 1024 bits. The key size is set in the diffie-hellman-key-size attribute within the tls-global configuration element.

While the key size can be increased, setting the key size to 2048 bits significantly decreases performance.

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.

VMWare Virtual Machines

In versions prior to S-Cz9.0.0, VMWare virtual machines used the e1000 driver for management interfaces and the VmxNet3 driver for media interfaces. Versions S-Cz9.0.0 and later use VmxNet3 driver for all interfaces.

New Keys Required for High Availability

If you replace a peer in HA from a system running software prior to S-Cz9.1.0p9 running this version or higher, the old keys become irrelevant resulting in SFTP failures using the old keys on the new peer. High Availability collect operations fail unless the old keys are manually deleted on the active peer. This situation is rare. This issue also occurs if you copy an old configuration into any new peer.

This issue does not occur unless you change a system in an HA pair running software prior to S-Cz9.1.0p9 to a different SBC running this version or higher. To replace keys:

1. Check to see if this issue applies to your deployment. Applicable system have keys using key-name parameters named backup-sbc1 and backup-sbc2.
2. Prior to replacing your previous system with a new system, delete the authorized public-keys for the HA systems.
3. Replace your previous system with the new system.
4. Reboot both systems.

   At this point, the SBC generates the new keys automatically, allowing the HA pairs to communicate over the wancom interface(s).

Upgrading To S-Cz9.1.0 From Previous Releases

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