To implement IPsec, SSR leverages a third-party client called libreswan. The client periodically deprecates weak algorithms from its code base such as dh2 (a.k.a modp1024) and dh22. While the SSR supports these algorithms, it is very likely that these algorithms will be deprecated in the near future. The article is meant to raise awareness of this upcoming change and provide instruction to proactively modify configuration to avoid outages.

In some cases, Salt states fail to be applied on routers after an upgrade to 5.6.16+, 6.1.12+, 6.2.8+, and 6.3.x-r2+. This will impact any salt states that rely on the CentOS name to detect or conditionally perform operations on the SSR.

For example, the following top.sls would be impacted:

base:
  '*':
    - dummy

  'os:CentOS':
    - match: grain
    - centos_example

Upgrading an HA Conductor to 6.3.0 fails on the second node.

Highway process can get stuck on startup due to DNS related race conditions for IPSec tunnels.

Large systems with multiple CPU's and many interfaces configured may not initialize the configured interfaces.

Changes to use a new database in the app-id engine have introduced high memory utilization for the application-director.

Packet forwarding on the SSR stops after several hours of runtime in AWS when using Elastic Network Adapter (ENA) driver.

Recent changes to fix MTU to use the max device supported value causes the SSR to set MTU to 9K. However since NetVSC does not support Scatter RX, it fails to bind because the SSR uses packet buffers of size 2K, and cannot span multiple mbufs.

Existing device to PCI mappings are not persistent across software upgrades.

Upgrade from 5.6.8 to 6.1.7 may result in missing FIB entries and service-paths, causing connectivity issues.