Sep 2026 - DevCentral will be set to Read-Only on Sep 14th for a platform update. Details: DevCentral is Evolving.

Forum Discussion

SCalNet's avatar
SCalNet
Icon for Altostratus rankAltostratus
Aug 24, 2026

F5 rSeries appliance firmware upgrade question

Hi guys,

I have 2 x R2800 appliances (appliance_A and appliance_B); each appliance has 1 tenant (LTM). The tenants run HA (active/standby; tenant LTM_A is active, and tenant LTM_B is standby). 

 

I'd like to upgrade the firmware for appliances and tenants. Does it require a reactive license in F5OS before upgrade F5OS host?

management

4 Replies

  • mwolf's avatar
    mwolf
    Icon for Cirrus rankCirrus
    Aug 24, 2026

    Yes, the license should be reactivated before an upgrade.

     

    The operating system on a BIG-IP devices in know as TMOS (Traffic Management Operating System).

    Newer version of TMOS will check the version and timestamps in the license file. My rule of thumb is to update, reactive license, before any TMOS upgrade.  

    The affected devices need to be covered by the initial warranty or a support contract.  This coverage allows the new license file to have the correct timestamps and version for the new version of TMOS. 

     

    My High level upgrade steps for a pair redundant BIG-IP devices:

    1. Upload new TMOS image. Can be done before upgrade change window.
    2. Download configuration archives from the device being upgraded, UCS files.
    3. Install new license on standby device, alpha.
    4. Reboot the alpha device.
    5. On alpha. Install new TMOS version to a volume / boot location.
    6. Reboot alpha into new TMOS version. ROLL CONFIGURATION FORWARD.
      1. Select configuration from the current volume / boot location.
    7. Wait for alpha to reboot.
    8. Verify alpha booted correctly into the new TMOS version.
    9. Force the active device , beta, to be the standby device.
      1. When using HA groups the beta device should be taken online.
    10. Verify alpha is the active device.
    11. Install new license on standby / offline device, beta.
    12. Reboot the beta device.
    13. On beta. Install new TMOS version to a volume / boot location.
    14. Reboot beta into new TMOS version. ROLL CONFIGURATION FORWARD.
      1. Select configuration from the current volume / boot location.
    15. Wait for beta to reboot.
    16. Verify beta booted correctly into the new TMOS version.
    17. Verify beta is the standby device.
      1. If beta is off line. Bring beta online.
    18. Verify the Device service clustering (DSC) status.

    19. Test synchronization

      1. Make a change on alpha.
      2. Verify change propagated to beta.

      3. Make a change 0n beta.

      4. Verifiy change propagated to alpha.

    20. Redundancy testing
      1. Make alpha standby.
      2. Wait a at lest 5 minutes.
      3. Make sure that beta stays the active device and alpha the standby device.
      4. Make beta the standby device.
      5. Make sure that alpha stays the active device and beta the standby device.

    21. Make the preferred device the active device.

    22. BIG-IP DNS / GTM Client .........

    23. Verify iQuery with monitoring BIG-IP DNS devices.

     

    Semantics:

    TMOS is not firmware. It's an operating system. When booting in a version of TMOS. There is a process that checks the version of installed hardware firmware. When a different version of hardware firmware is required. It gets installed. The BIG-IP can reboot after a firware install. Booting in to a different version of TMOS can require multiple reboots due to firmware installs. 

     

    -Matt

     

  • Quiroman81's avatar
    Quiroman81
    Icon for Cirrus rankCirrus
    Aug 26, 2026

    Hi,

     

    For the F5OS host upgrade itself, license reactivation is not required. F5 states it explicitly in K000139939: "It's currently not required to re-activate the license when upgrading only the F5OS hypervisor software." - https://my.f5.com/manage/s/article/K000139939

    What you do need to verify is the Service Check Date: on rSeries the license lives on the host and the tenants inherit it (K000157898 - https://my.f5.com/manage/s/article/K000157898), so if that date is earlier than the License Check Date of the TMOS version you are upgrading LTM_A/LTM_B to, the tenant initializes but does not load its configuration. Table per version in K7727 - https://my.f5.com/manage/s/article/K7727

    F5 also lists it as a prerequisite in the F5OS-A Installation and Upgrade guide: "Update/reactivate your system license, if needed, to ensure that you have a valid service check date." - https://techdocs.f5.com/en-us/f5os-a-1-8-0/f5-rseries-systems-installation-upgrade/title-install-before-install-upgrade.html

    You can check it on the host with "show system licensing"; the rSeries reactivation procedure is in K000151705 - https://my.f5.com/manage/s/article/K000151705

    If you do reactivate, plan it: all tenants reload the license and their configuration, which briefly interrupts traffic (K22424342 - https://my.f5.com/manage/s/article/K22424342). Do appliance_B first while LTM_B is standby, then fail over and repeat on appliance_A.

    Hope this helps with your upgrade. 

     

    JQuiroga 😁

  • mwolf's avatar
    mwolf
    Icon for Cirrus rankCirrus
    Aug 26, 2026

    I agree that license reactivation is not required for all upgrade.  I do not update the license every time I upgrade a lab device. 

    The Service Check Date is used to verify that the device is covered by a active support contract.  My clients renew their support contracts every year. The license should be reactivated at least once a year.  Upgrades are a good time to reactivated the license.   

    I have had multiple clients only able to upgrade TMOS once every 18 months. My personal best practice to reactive the license during every update is due to more than a year between upgrades. 

    I believe the Service Check Date has to to fall within a date range based on the TMOS version's release date. 

    The license file has a version number.  Occasionally a newer version of TMOS requires the license version number to be incremented.  The license file has to be reactivated or updated when the license version is incremented. 

     

    • Quiroman81's avatar
      Quiroman81
      Icon for Cirrus rankCirrus
      Aug 26, 2026

      Hi Matt,

      Agreed on the practice - reactivating before an upgrade costs nothing. I would only split two fields that tend to get merged, because it changes what is actually enforced.

      Service Check Date is a stamp inside the license file: K7727 defines it as "the date the license was last activated or the date the service contract for the device expires, whichever date is earlier". License Check Date is a different value - static, compiled into each major/minor release, readable in /etc/version_date and published by F5 as a per-version table in K7727 - https://my.f5.com/manage/s/article/K7727

      The upgrade only compares those two: the Service Check Date must be equal to or later than the License Check Date of the version you are installing. It is a floor, not a range - the documented failure condition is the service check date being earlier, and no upper bound is defined. So the contract is not verified at upgrade time; it only decides how far forward that stamp can move when you reactivate. Same article: updates (maintenance or point releases, e.g. 17.1.1 to 17.1.2) perform no date verification at all, only upgrades do.

      On the license version number: "Licensed version" and "Licensed date" are semi-static values stamped when the unit is first licensed and are not part of the check. K94935304 puts it plainly: "The only dates that matter during re-activation and upgrade are 'Service Check Date' on a Big-IP and the 'License Check Date' for a specific software major revision." - https://my.f5.com/manage/s/article/K94935304

      JQuiroga 😁