Upgrade and Downgrade Caveats

The following items provide key information about upgrading and downgrading with this software version.

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).

Systems with FIPs Licensing

Do not upgrade any device licensed to use FIPS to S-Cz9.2.0. This causes the system to fail, preventing successful boot.

Platform-Specific Downgrade Limitations

Do not attempt to downgrade your ESBC to a release not supported by your platform. See the Platform Support table for which platforms support which releases.

Acme Packet 4900 and 3950 Platforms

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

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.

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 ESBC, upgrade your client.

Upgrading from releases earlier than S-Cz8.4.0

The S-Cz8.4.0 release included significant changes that hardened the security of the ESBC. 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

Diffie-Hellman Key Size

In the context of TLS negotiations on SIP interfaces, the default Diffie-Hellman key size offered by the ESBC 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.

Session Translations

Both translation-rules and session-translation elements have significantly changed in release S-Cz9.2.0. A backup configuration from release S-Cz9.1.0 or earlier will not be compatible with S-Cz9.2.0 or later, and vice versa. Create a backup of the existing configuration before performing an upgrade as the changes to the translation-rules and session-translation elements are not backward compatible, during a downgrade.

When upgrading to S-Cz9.2.0, the ESBC converts the older translation-rules and session-translation configuration elements to their new format. Translation rules and session translations will continue to work as before. A rules-called translation rule in release S-Cz9.1.0 and earlier will be upgraded in S-Cz9.2.0 to two separate translation rules: one that modifies the To header and one that modifies the Request URI.

Default TLS Version

When downgrading from S-Cz9.2.0 to an earlier release, the tls-version attribute within a tls-profile will be changed from tlsv13 to compatibility. Earlier releases do not support tlsv13 as a value for tls-version.

Downgrade Caveat for NTP Configurations using an FQDN

If you create a realm-config for providing resolution of FQDNs for NTP servers through the wancom0 interface, Oracle recommends that you remove this wancom0 realm-config before downgrading to a version that does not support FQDNs for NTP servers. If you retain this configuration, you lose SSH and GUI access after the downgrade.

To recover from this issue, use console access to remove the wancom0 realm-config. Also remove the wancom0 phy-interface and network-interface.

If you configure FQDN resolution for NTP servers through a media interface, you can downgrade to a version that does not support this resolution without removing that configuration.

TDM Card Requirements

A replacement Sangoma TDM card begins to ship in the summer of 2023. If your current Digium TDM card needs to be replaced, Oracle will ship a new Digium card while supplies last. After that, to convert from using a Digium TDM card to a Sangoma TDM card, you will need to return your device to Oracle.

The following releases and newer support the Sangoma TDM card::

• 9.2p1
• 9.1p7

Upgrade Version Caveat from Session Delivery Manager

The Session Delivery Manager cannot direct upgrades from S-Cz9.1.0p6, S-Cz9.0.0p8 or S-Cz9.0.0p9 for HA deployments. See Knowledge Document # 2952935.1 for a detailed explanation.

SSH Host Key Algorithms

If you upgrade to release S-Cz9.2.0p2 or later, the ESBC offers rsa-sha2-512 as the default host key algorithm. Connecting with a client that only offers a SHA1 hash algorithm, like ssh-rsa, is no longer supported; your SSH client must offer a SHA2 hash algorithm. If you receive a "no matching host key type found" error message, make sure your client supports SHA2 host key algorithms.

This changes affects only the algorithms offered by the client, not the host key of the ESBC.

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 ESBC 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 ESBC generates the new keys automatically, allowing the HA pairs to communicate over the wancom interface(s).