Skip to main content

Upgrading RioRey Systems

It's straightforward to upgrade RioRey systems, but there are some basic procedures and caveats for each platform that should be understood before upgrading your deployment.

Upgrade Overview​

  • We generally recommend upgrading to the latest available release when it is available (to the version marked "current" on the Release Notes page). You will want to upgrade rWeb first, then RIOS and Director devices when you are ready for potential network effects, as they can affect network traffic. RIOS and Director upgrades may also be dependent on your running rWeb version.
  • Unless otherwise noted in the release notes for the platform, you can upgrade directly to your desired version (no need for intermediate upgrades). However, please review the release notes for the intermediate version in case there are additional caveats (e.g. some upgrades may take longer than normal).
  • rWeb and Director upgrades are one way (from a lower to a higher version). A RIOS filter device, if desired, can roll back to an earlier version (provided the platform is supported in that version).
  • Occasionally, VM requirements may change between versions. Please check the release notes in case you need to provision additional resources prior to the upgrade if running a VM platform.

The sections below will go into more detail for each platform.

rWeb​

  • rWeb upgrades are from a lower to a higher version only.
  • While rWeb is upgrading, the GUI and API will be unavailable, but the system itself will not power off. We do, however, recommend rebooting rWeb after the upgrade is complete if at all possible.
  • Any configured RIOS or Director devices will continue to operate based on the last available configuration from the rWeb, so rWeb can be upgraded without needing to divert traffic or perform any other network shaping for traffic going through RIOS devices.
  • An rWeb in a High Availability (HA) deployment will automatically upgrade its secondary unit as part of the process, so no separate steps are required.

RIOS​

  • RIOS upgrades can be go to either a higher or a lower version, provided:

    1. The rWeb managing the device supports that version of RIOS.
    2. The platform itself supports that version of RIOS.

    The RIOS release notes indicate both the minimum version of rWeb required and which platforms are supported in the release. When going up in version, this is why you should upgrade rWeb first.

  • RIOS devices reboot as part of the upgrade process, so their accompanying network interfaces will be unavailable until they come back into normal operating mode. The majority of physical filter devices have either a built in bypass unit, or access to an external bypass unit. Assuming the "Engage bypass on power loss" option is checked for those network ports, the bypass will automatically engage during the upgrade and disable itself once it is running the new version and able to handle traffic again. The bypass is fast but does take a non-zero amount of time to engage, so BGP sessions transiting the device's ports may flap if they are set for fast-external-fallover.

  • For virtual RIOS devices, physical RIOS devices without bypasses, or if trying to preserve BGP session state, you may need to perform network redirection prior to triggering the upgrade. Otherwise, your network should be able to handle the related links being unavailable. Since a RIOS upgrade can affect network traffic, its recommended to set aside a maintenance window with all relevant network personnel made aware of the above caveats.

  • If a RIOS device is unable to establish normal operating mode and reconnect with its managing rWeb following an upgrade, it will revert to its previous running version as a precaution.

Director​

  • Director upgrades are from a lower to a higher version only. If managing your Director from an rWeb, check the minimum version of rWeb required in the Director release notes. This is why you should upgrade rWeb first.
  • In general, we recommend upgrading Director when you don't have any active actions triggered by network activity. As part of the upgrade, Director stops and restarts the core monitoring process (the Director system itself will not restart, similar to rWeb). Prior to stopping, it will withdraw all active actions, and after restarting, the process will begin evaluating traffic again according to Director's configuration, but it won't restart the previous set of actions.
  • If you have Director in an active-active setup, it's still recommended to upgrade when you don't have any active actions. However, in this setup you can incrementally upgrade your Directors while an action is ongoing. While one Director is upgraded, the second Director will continue any existing actions. You can wait until the network activity causing the action is complete, or if it is a long running action (due to min-action-time) wait until the actions on the unupgraded Director finish, and then upgrade that Director. Network activity starting new actions in this intermediate time period should be tracked by the already upgraded Director, so you won't lose them when upgrading the second Director.