Rolling Back a Failed Upgrade of a Security Group - Zero Downtime (MVC)

This section describes the steps to roll back a failed upgrade of a Security GroupClosed 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. from R81.10 with Zero Downtime - as a Multi-Version ClusterClosed Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. (MVC).

This procedure supports only these downgrade paths for Security Groups:

  • from R81.10 to R81

  • from R81.10 to R80.20SP

Warnings:

  • Multi-Version Cluster (Zero Downtime) downgrade from R81.10 to R81 is not supported if a Security Group has Bond interfaces in the 802.3ad (LACP) mode (Known Limitation PMTR-88191).

  • Before you follow the downgrade procedure, revert all changes in the topology you made after the upgrade procedure. For example, after the upgrade you added / removed interfaces, you changed the configuration of interfaces, you added / removed Security Group Members in the Security Group.

Important:

  • Use this rollback procedure if you upgraded all Security Group Members in the Security Group and it is necessary to keep the current connections.

    This procedure does not interrupt the traffic and does not require down time.

    However, this procedure takes more time comparing with the procedure Rolling Back a Failed Upgrade of a Security Group - Minimum Downtime.

  • In this rollback procedure, you divide all upgraded Security Group Members in a specific Security Group into two logical groups - denoted below as "A" and "B".

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

    The other logical group 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.

    Example 1:

    • There are 8 Security Group Members in the Security Group.

    • The Logical Group "A" contains Security Group Members from 1_1 to 1_4.

    • The Logical Group "B" contains Security Group Members from 1_5 to 1_8.

    Example 2:

    • There are 5 Security Group Members in the Security Group.

    • The Logical Group "A" contains Security Group Members from 1_1 to 1_3.

    • The Logical Group "B" contains Security Group Members 1_4 and 1_5.

Step

Instructions

1

Connect to the command line on the Security Group.

2

If your default shell is /bin/bash (Expert mode), then go to the Gaia gClishClosed 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.:

gclish

3

Disable the SMOClosed See "SMO". Image Cloning feature:

Note - The SMO Image Cloning feature automatically clones all the required software packages to the SGMs during their boot. When you install or remove software packages gradually on SGMs, it is necessary to disable this feature, so that after a reboot the updated SGMs do not clone the software packages from the existing non-updated SGMs.

  1. Examine the state of the SMO Image Cloning feature:

    show smo image auto-clone state

  2. Disable the SMO Image Cloning feature, if it is enabled:

    set smo image auto-clone state off

  3. Examine the state of the SMO Image Cloning feature:

    show smo image auto-clone state

4

Go to the Expert mode:

5

Go to the context of one of the Security Group Members in the Logical Group "A":

member <Member ID>

Example:

member 1_1

6

Run the upgrade script with the "revert" parameter and follow the instructions on the screen:

sp_upgrade --revert

7

Restore the Gaia automatic snapshot on each Security Group Member in the Logical Group "A" that was upgraded to R81.10:

  1. Go to the context of the Security Group Member:

    member <Member ID>

    Example:

    member 1_2

  2. Go to Gaia ClishClosed The name of the default command line shell in Check Point Gaia operating system. This is a restricted shell (role-based administration controls the number of commands available in the shell). (do not use the Gaia gClish):

    clish

  3. Restore the Gaia automatic snapshot that was saved automatically before the upgrade.

    set snapshot revert AutoSnapShot_<Original-Version>_<Take>

    Example:

    set snapshot revert AutoSnapShot_AutoSnapShot_R81_47

  4. Wait for the Security Group Member to complete the reboot.

  5. Repeat Steps a-d for the next Security Group Member in the Logical Group "A" that was upgraded.

8

Connect to the command line on the Security Group.

9

If your default shell is /etc/gclish (Gaia gClish):

expert

10

Go to the context of one of the Security Group Members in the Logical Group "A" that were downgraded from R81.10:

member <Member ID>

Example:

member 1_1

11

Run the upgrade script with the "revert" parameter again and follow the instructions on the screen:

sp_upgrade --revert

12

Restore the Gaia automatic snapshot on each Security Group Member in the Logical Group "B" that was upgraded to R81.10:

  1. Go to the context of the Security Group Member:

    member <Member ID>

    Example:

    member 1_5

  2. Go to Gaia Clish (do not use the Gaia gClish):

    clish

  3. Restore the Gaia automatic snapshot that was saved automatically before the upgrade.

    set snapshot revert AutoSnapShot_<Original-Version>_<Take>

    Example:

    set snapshot revert AutoSnapShot_AutoSnapShot_R81_47

  4. Wait for the Security Group Member to complete the reboot.

  5. Repeat Steps a-d for the next Security Group Member in the Logical Group "B" that was upgraded.

13

Connect to the command line on the Security Group.

14

If your default shell is /etc/gclish (Gaia gClish), then go to the Expert mode:

expert

15

Run the upgrade script with the "revert" parameter again and follow the instructions on the screen:

sp_upgrade --revert

16

Make sure the downgrade was successful:

asg diag verify