Upgrading Scalable Chassis Environment to R81.20 - Zero Downtime

Warning - Multi-Version Cluster (Zero Downtime) upgrade from R81 / R81.10 to R81.20 is not supported if a Security Group A logical group of Security Gateway Modules that provides Active/Active cluster functionality. A Security Group can contain one or more Security Gateway Modules. Security Groups work separately and independently from each other. To the production networks, a Security Group appears a single Security Gateway. has Bond interfaces in the 802.3ad (LACP) mode on Uplink ports (Known Limitation PMTR-88191).

Important - See these rollback procedures:

• Rolling Back a Failed Upgrade of a Security Group to R81.20 - Zero Downtime

• Rolling Back a Failed Upgrade of a Security Group to R81.20 - Minimum Downtime.

Important Notes for Scalable Chassis:

• We recommend to schedule a maintenance window for all sites.

• In a Dual Chassis environment:

  Procedure

  1. Upgrade the Scalable Chassis on the Standby Site (Site 2)

  2. Initiate a fail-over in each Security Group from the non-upgraded Active Site (Site 1) to the upgraded Standby Site (Site 2):

     1. Connect to the command line on each Security Group.

     2. If your default shell is Gaia gClish The name of the global command line shell in Check Point Gaia operating system for Security Gateway Modules. Commands you run in this shell apply to all Security Gateway Module in the Security Group., then go to the Expert mode:

        expert

     3. Initiate a fail-over:

        chassis_admin -c <ID of Active Site> down

        chassis_admin -c <ID of Former Active Site> up

  3. Upgrade the Scalable Chassis on the new Standby Site (Site 1).

Important Notes for Security Groups:

• Before you upgrade the Security Groups, you must upgrade the Management Server that manages the Security Groups.

  See the R81.20 Installation and Upgrade Guide.

• This procedure applies to Security Groups in the Gateway mode and the VSX mode.

  In VSX mode, you must run all the commands in the context of VS0.

• During the upgrade process, it is:

  • Forbidden to install policy on the Security Group, unless the upgrade procedure explicitly shows how to do it.

  • Forbidden to reboot Security Group Members, unless the upgrade procedure explicitly shows how to do it.

  • Forbidden to change the configuration of the Security Group and its Security Group Members.

  • Forbidden to install Hotfixes on the Security Group Members, unless Check Point Support or R&D explicitly instructs you to do so.

  • Forbidden to install the Jumbo Hotfix Accumulator on the Security Group Members, unless Check Point Support or R&D explicitly instructs you to do so.

• To prevent down time, do not upgrade all the Security Group Members in a specific Security Group at the same time.

• In this upgrade procedure, you divide all Security Group Members in a specific Security Group into two or more logical groups.

  In the procedure below, we use two logical groups denoted below as "A" and "B".

  You upgrade one logical group of the Security Group Members at one time.

  The other logical group(s) of the Security Group Members continues to handle traffic.

  Each logical group should contain the same number of Security Group Members - as close as possible.

  Examples

  Environment	Description
  Single Chassis	There are 8 SGMs in the Security Group. The Logical Group "A" contains SGMs from 1_1 to 1_4. The Logical Group "B" contains SGMs from 1_5 to 1_8.
  Single Chassis	There are 5 SGMs in the Security Group. The Logical Group "A" contains SGMs from 1_1 to 1_3. The Logical Group "B" contains SGMs from 1_4 to 1_5.
  Dual Chassis	There are 4 SGMs in the Security Group (on each Chassis). The Logical Group "A" contains SGMs on Chassis1 from 1_1 to 1_4. The Logical Group "B" contains SGMs on Chassis2 from 2_1 to 2_4.

• In a Dual Chassis environment:

  • We recommend to upgrade all Security Group Members in each Security Group on one Chassis, and then upgrade all Security Group Members in the same Security Group on the next Chassis.

    Do this on one Security Group at a time.

  • To prevent a fail-over between Chassis during the upgrade, we recommend these steps for each Security Group:

    Procedure

    1. Connect to the command line on a Security Group.

    2. If your default shell is the Expert mode, then go to Gaia gClish:

       gclish

    3. Get the current Dual Chassis Active/Standby mode:

       show chassis high-availability mode

       Available Modes:

       Mode ID	Mode Title	Mode Description
       0	Active/Standby - Active Up	No primary Chassis. The currently Active Chassis stays Active unless it goes DOWN, or the Standby Chassis has a higher Chassis quality grade.
       1	Active/Standby - Primary Up	Active Chassis, always stays Active unless it goes DOWN, or the Standby Chassis has a higher Chassis quality grade.
       2	Not available	Not supported.
       3	Standby Chassis VSLS Mode	In VSX, provides Virtual System Load Sharing.

    4. Decide which of the Chassis is Active.

    5. Change the Dual Chassis Active/Standby mode to "Active/Standby - Primary Up":

       set chassis high-availability mode 1

    6. Change the Chassis Priority (enter the number of the currently Active Chassis):

       set chassis high-availability vs chassis_priority {1 | 2}

    7. Upgrade all Security Group Members on the "Standby" Chassis.

    8. On the upgraded Chassis, change the Dual Chassis Active/Standby mode to "Primary Up":

       set chassis high-availability mode 1

    9. On the upgraded Chassis, change the Chassis Priority (enter the number of the currently Active Chassis):

       set chassis high-availability vs chassis_priority {1 | 2}

    10. Upgrade all Security Group Members on the new "Standby" Chassis (former "Active" Chassis).

    11. Change the Dual Chassis Active/Standby mode to the previous mode:

        set chassis high-availability mode <Mode ID>