Upgrading to ACOS 4.1.0

This chapter provides information for upgrading your ACOS software to release 4.1.0.

NOTE:                               If you are configuring a new ACOS device, refer to the installation guide for your specific device for hardware installation instructions, and the Quick Start Guide for initial configu­ration instructions.

The following topics are covered:

     Supported Upgrade Paths

     Upgrade Image File Names

     Upgrading Legacy HA Configurations

     Upgrading to ACOS 4.1.0 From Legacy 2.7.2.x or 2.8.2.x Releases

     Upgrading Existing aVCS Configurations to ACOS 4.1.0

     Upgrading to ACOS 4.1.0 From 4.0.x Releases

 

Supported Upgrade Paths

The following upgrade paths to ACOS 4.1.0 are supported:

     Any legacy 2.7.2.x or 2.8.2.x release to ACOS 4.1.0 (see Upgrading to ACOS 4.1.0 From Legacy 2.7.2.x or 2.8.2.x Releases)

     Any ACOS 4.0.x release to ACOS 4.1.0 (see Upgrading to ACOS 4.1.0 From 4.0.x Releases)

NOTE:                               To perform an upgrade to ACOS Release 4.x using the GUI, you must start with Release 2.7.2-P3. Earlier releases are not supported.

These releases support the encryption and decryption of the .upg image file formats used for upgrading a device (Upgrade Image File Names).

Upgrade Image File Names

Make sure to use the correct image file for your specific ACOS device.

First, determine whether or not your device is FTA enabled. See Hardware Platform Support, or use the follow­ing show hardware command; devices that are FTA-enabled will have an output similar to the following:

ACOS# show hardware | inc FPGA

FPGA       : 4 instance(s) present

 

Then, make sure to use the correct ACOS image file:

     For FTA enabled platforms, use the image with the file name:

ACOS_FTA_version.upg

     For non-FTA enabled platforms (including vThunder), use the image with the file name:

ACOS_non_FTA_version.upg

 

Upgrading Legacy HA Configurations

ACOS 4.x releases no longer supports the legacy HA configuration (see Configuring High Availability). If you are upgrading to release 4.x from a legacy 2.7.2.x or 2.8.2.x release, and your configuration contains legacy HA content, use the vrrp-a ha-migration CLI command prior to beginning the upgrade process.

This section contains the following topics:

     Before Upgrading Your Configuration

     HA to VRRP-A Migration Exceptions

     HA to VRRP-A CLI Comparison

     Running the HA to VRRP-A Migration Command

     Revert to HA from VRRP-A

Before Upgrading Your Configuration

Before migrating your HA configuration to VRRP-A, do the following:

     Back up your current configuration. Although the vrrp-a ha-migration command creates its own backup of the existing configuration, it is recommended that you create your own copy of the existing configuration in case you need to revert to your original configuration.

     Before running the vrrp-a ha-migration command, review your existing HA configuration file to address any exceptions that will cause the command to fail. Address these exceptions by manually upgrading your HA configura­tion or by deleting these configuration statements from your configuration file before migrating your configuration. For a list of conversion exceptions, see HA to VRRP-A Migration Exceptions.

Once the conversion process from HA to VRRP-A is complete, if you wish to revert to your HA configuration, use the vrrp-a ha-migration-restore command. For more information, see Revert to HA from VRRP-A.

HA to VRRP-A Migration Exceptions

During the migration process, some conditions will cause the migration command to fail. An HA configuration that does not contain any of the following HA configuration exceptions will result in a successful conversion to VRRP-A. Issue the migration command only after you have removed or manually upgraded the following HA configuration statements.

NOTE:                               When you execute the command, it will check your HA configuration to ensure that no HA configuration exceptions exist. If exceptions are encountered, the command will quit without performing any conversion to VRRP-A.

Assuming no Virtual Chassis (VCS) has been configured, the following exceptions will cause the HA migration command to fail:

     RBA partitions are encountered.

     Forward-L4-Packet-on-Standby is detected.

     L2 Inline Mode is detected. This includes support for HA Inline Mode (preferred port), HA restart-time, and HA restart­port-list.

     L3 Inline Mode is detected. This includes support for HA L3 Inline Mode and HA OSPF Inline mode.

     HA Parameters for Real Servers are detected. This includes support for HA priority cost.

     HA Parameters for Real Ports are detected.

     Firewall Load Balancing (FWLB) is detected.

HA to VRRP-A CLI Comparison

TABLE 16    shows the legacy HA commands and their VRRP-A equivalents.

NOTE:                               Many of the VRRP-A commands are further changed in the ACOS 4.x releases and are no longer the same as their legacy 2.7.x or 2.8.x equivalents; this migration is performed by the ACOS 4.x migration script.

TABLE 16    Actual HA to VRRP-A Conversion

HA

VRRP-A

Global Parameters

ha id {1|2} [set-id num]

vrrp-a set-id num 

ha group id num priority num

vrrp-a vrid num 

priority num

floating-ip ipaddr ha-group num

vrrp-a vrid num

floating-ip ipaddr

ha interface ethernet port-num
[router-interface | server-interface | both]
[no-heartbeat | vlan
vlan-id]

vrrp-a interface ethernet port-num
[router-interface | server interface | both] [no-heartbeat | vlan
vlan-id]

The VRRP-A tracking options are created per VRID. The migration script will place the configuration under each VRID. If an interface is under a trunk, only the trunk will be tracked.

ha check vlan vlan-id timeout seconds

track options

vlan vlan-id timeout seconds priority-cost default

ha check gateway ipaddr

gateway ipaddr priority-cost default

ha conn-mirror ip ipaddr

IP address is learned automatically

ha preemption enable

preempt-mode disable

ha time-interval 100-ms-units

vrrp-a hello-interval 100-ms-units

ha timeout-retry-count num

vrrp-a dead-timer num

ha arp-retry num

vrrp-a arp-retry num

ha forward-l4-packet-on-standby

Not supported

Global Parameters for L2 Inline Mode

ha inline-mode [preferred-port]

Not supported

ha restart-time 100-msec-units

Not supported

ha restart-port-list

Not supported

Global Parameters for L3 Inline Mode

ha l3-inline-mode

Not supported

ha ospf-inline vlan vlan-id

Not supported

ha link-event-delay

Not supported

Parameters for Virtual Servers (appear under slb virtual-server)

ha-group group-id

vrid group-id

ha-dynamic server-weight

It will not be changed

Parameters for Virtual Service

ha-conn-mirror

It will not be changed

Parameters for Real Servers

ha-priority-cost weight ha-group group-id

Not supported

Parameters for Real Ports

ha-group group-id

Not supported

Parameters for FWLB

ha-priority-cost weight ha-group group-id

Not supported

Parameters for IP NAT

Options with ip nat pool, ipv6 nat pool, or ip nat

ip nat pool pool-name 
starting-ip-nat pool-address
ending-ip-nat pool-address
netmask pool-mask
 vrid vrid-num

Parameters for IP Routes

ha check route prefix /mask 
priority-cost
weight 
[gateway ip
ipaddr | ipv6 ipv6addr]
[protocol {static | dynamic}]
[distance
num]

This appears under track options:

route prefix /mask priority-cost weight [gateway ipaddr | ipv6addr]
[protocol {static | dynamic}]
[distance
num]

 

Running the HA to VRRP-A Migration Command

When you are ready to migrate your legacy HA configuration to VRRP-A:

1.     Run the vrrp-a ha-migration CLI command. If you are migrating both devices in the HA pair, you must run this command separately on each device.

ACOS-Active(config)# vrrp-a ha-migration

ACOS boots from hard disk primary. VRRP-A migration only effects on hard disk primary.

Migrate from HA to VRRP-A therein? (y/n) y

HA Migration Starts...

89 lines of configuration are processed

Replacing old config file with new config file.

Configure file has been replaced!

HA configuration has been replaced by VRRP-A configuration! Please reload the system to

finalize the migration!

Warning: After reloading, all vrids in all partitions will be forced standby!

Please manually remove forced-standby setting with command: no vrrp-a force-self-standby

all-partitions

 

2.     Reload your device with the reload CLI command.

ACOS# reload

 

System configuration has been modified. Save? [yes/no]:no

s

Do you wish to proceed with reload? [yes/no]:yes

 

ACOS is reloading now. Please wait....

ACOS has reloaded successfully.

 

3.     Remove the forced-self-standby setting:

ACOS(config)# no vrrp-a force-self-standby all-partitions

 

4.     Verify your VRRP-A configuration with the show running-config | sec vrrp-a command. For example:

ACOS# show running-config | sec vrrp-a

vrrp-a device-id 2

vrrp-a set-id 1

vrrp-a enable

vrrp-a vrid default

  tracking-options

     interface ethernet 3 priority-cost 15

     interface ethernet 2 priority-cost 15

     interface ethernet 1 priority-cost 15

vrrp-a vrid 1

  priority 100

  tracking-options

     interface ethernet 3 priority-cost 15

     interface ethernet 2 priority-cost 15

     interface ethernet 1 priority-cost 15

vrrp-a interface ethernet 1 router-interface

vrrp-a interface ethernet 2 server-interface no-heartbeat

vrrp-a interface ethernet 3  vlan 100

 

Revert to HA from VRRP-A

To restore an existing HA configuration, you can revert from VRRP-A configuration using the vrrp-a ha-migration-restore command. This command will only work if you have previously migrated your HA configuration to VRRP-A using the migration script.

Below is an example:

ACOS-Active(config)# vrrp-a ha-migration-restore

ACOS boots from hard disk primary. Migration restore only effects on hard disk primary.

Trying to find backup config file to replace current config file.

The backup files is found.

Proceed to replace current config file? (y/n) y

System has been successfully restored! Please reload system!

 

 

Upgrading to ACOS 4.1.0 From Legacy 2.7.2.x or 2.8.2.x Releases

ACOS 4.1.0 introduces an automated migration script to convert legacy 2.7.2.x and 2.8.2.x configurations to the most current format.

Before upgrading, be sure you have obtained the appropriate upgrade image (Upgrade Image File Names) and also converted any legacy HA configurations to VRRP-A (Upgrading Legacy HA Configurations).

This section contains the following content:

     Upgrade Recommendations and Notes

     Upgrade Instructions

     Generating New Profiles

     Migrating Partitions

     Migrating Admins

Upgrade Recommendations and Notes

Observe the following best practices for a successful upgrade:

     Only upgrade the image that is currently being used at the boot image; it is not recommended to upgrade the sec­ondary image area, for example, if the primary image area is the current boot image area.

     After the upgrade, make sure to boot from the image area that was upgraded to ensure the success of the upgrade; it is not recommended to upgrade the primary image area, for example, then boot from the secondary image area.

     If there are existing 4.1.0 profiles on the device, the upgrade will remove those profiles; no pre-existing 4.1.0 changes will be kept.

Upgrade Instructions

When you are ready to upgrade:

1.     Use the write memory all-partitions command to save your current running-config to the startup-config.

ACOS-2-7-x(config)# write memory all-partitions

Building configuration...

Write configuration to primary default startup-config

[OK]

 

2.     Upgrade your ACOS release 2.7.2-Px or 2.8.2-Px software to release 4.x using the upgrade command and the image file name from Upgrade Image File Names. For example, to upgrade the primary boot image on an FTA device:

ACOS-2-7-x(config)# upgrade hd pri tftp://2.2.2.2/images/ACOS_FTA_version.upg

 

Or, on a non-FTA device:

ACOS-2-7-x(config)# upgrade hd pri tftp://2.2.2.2/images/ACOS_non_FTA_version.upg

 

3.     Near the end of the upgrade procedure, you will be prompted to reboot your ACOS device. You can answer yes to reboot, or no if you want to reboot manually.

You must reboot the device to bring up the ACOS 4.x software and complete the upgrade procedure.

Upgrade to ACOS 4.x is complete once the device is rebooted.

To verify, you can use the show startup-config all command and

 

Generating New Profiles

ACOS devices have a default configuration profile in each of the primary and secondary boot image areas. In addition to these default configuration profiles, you can create additional local configuration profiles in both boot image areas.

The migration script generates new profiles in the following manner:

     For each legacy local configuration profile, the migration tool will generate one new profile with name with “_40” appended to the name. For example, an existing profile called “slb_profile” would become “slb_profile_40”. The origi­nal profile is not modified so that reverting back to the earlier version is possible.

Use the show startup-config all command to view a list of all local configuration profiles, and to view the profile currently being used. The “Version” column in the output shows you the ACOS version of the configuration profile.

For example:

ACOS(config)# show startup-config all

Secondary startup-config profile: def_profile

Profile-Name                           Size         Time             Version

----------------------------------------------------------------------------

4.1.0-profile                          3848    2015-02-28 10:35:48    2.7.2

4.1.0-profile_40                       3862    2016-02-04 17:21:05    4.1.0

Default_primary_old                     877    2016-02-04 17:21:04    2.7.0

...

NOTE:                               If the existing profile name is 31 characters long, which is the maximum allowed limit, the profile name will be shortened so that “_40” can be appended. For example, the pro­file name “ThisIsAVeryLongPartitionName31” may be shortened to “ThisIsAV­ery1449554673.09_40” or something similar.

     For default primary and secondary configurations, the migration tool will create one copy of the original profile as a local configuration profile with name “Default_<primary/secondary>_old” and change the default profile to a format compatible with 4.x.

Migrating Partitions

The migration tool will migrate at most 1023 partitions to the new format, or the maximum number allowed by the specific system.

For example, a system that allows a maximum of 32 L3V partitions has the following configuration profiles:

     profile1, which contains 16 L3V partitions

     profile2, which contains 17 L3V partitions

The migration tool will migrate all 33 of these partitions to the new configuration, since the number is less then 1023. How­ever, since the platform supports a maximum of 32 partitions, you should expect to see parse error messages similar to the following for each partition exceeding the maximum number supported by the device:

“partition <partition-name> id <partition-id>”

“no partition <partition-name> id <partition-id>”

If the total number of partition migrated exceeds 1023, the following parse error messages are expected:

“Warning: Partition <partition-name> is out of limit”

 

In release 4.x, the directory structure for L3V partitions is completely new. All L3v partitions contain independent profiles that are not tied to the shared partition. To avoid conflicts in system, all partition IDs are re-arranged during the migration process and available IDs are assigned to all partitions. Once all available IDs are assigned, meaning the maximum number of sup­ported partitions has been reached, the remaining partitions are discarded.

Migrating Admins

During the migration process, error messages relating to admin migration will be seen.

Error Message When Migrating the Default Admin

The following message is normal and can be safely ignored:

Feb 02 2016 23:30:54 Error   [CLI]:Parse error when executing command:  object-access-con­trol "none" "none" "none" "none" "none" "none" "none" "none"

 

Error Message for Admins with Custom Privileges

The following error message is generated when an admin is configured in 2.7.2.x or 2.8.2.x using a custom privilege (in this case, using privilege read from the admin configuration mode):

ACOS(config)# admin admin1 password admin1

ACOS(config-admin:admin1)# privilege read

ACOS(config-admin:admin1)#

 

Below is the error message:

Feb 03 2016 00:07:34 Error   [CLI]:Parse error when executing command:  role-admin ReadOn­lyAdmin

 

To work around this issue:

1.     Re-configure the admin in the 4.x CLI (same commands as 2.7.2.x or 2.8.2.x).

2.     Use write memory to save your changes

3.     Use reload to reload the ACOS device.

Error Messages for Admins with Multiple Partition Privileges

The following error message is generated when an admin is configured in 2.7.2.x or 2.8.2.x with multiple partition privileges. For example:

ACOS(config)# admin admin1 password admin2

ACOS(config-admin:admin2)# privilege partition-read p1 p2

 

Below is the error message:

Feb 02 2016 22:08:21 Error   [CLI]:Parse error when executing command:  role-admin Parti­tionReadOnly "p1" "p2"

 

To work around this issue:

1.     Re-configure the admin in the 4.x CLI (multiple partition names are not allowed in a single command in 4.x):

ACOS-4-x(config)# admin admin2 password examplepassword

ACOS-4-x(config-admin:admin2)# privilege partition-read p1

Modify Admin User successful!

ACOS-4-x(config-admin:admin2)# privilege partition-read p2

Modify Admin User successful!

ACOS-4-x(config-admin:admin2)#

2.     Use write memory to save your changes

3.     Use reload to reload the ACOS device.

Reverting to Your 2.7.2.x or 2.8.2.x Release

When the device is booted with ACOS 4.1.0, linking to a legacy 2.7.2.x or 2.8.2.x profile is not supported. In order to re-use the old profile, you must first revert back to your 2.7.2.x or 2.8.2.x release and then link to the old profile.

To revert to your existing 2.7.2.x or 2.8.2.x release:

1.     Use the write memory all-partitions command to save your current running-config to the startup-config.

ACOS-4-x(config)# write memory all-partitions

Building configuration...

Write configuration to primary default startup-config

[OK]

 

2.     Set the boot image to the location where your 2.7.2.x or 2.8.2.x image resides. For example, if your 4.x image was loaded in the primary boot image area, and your legacy image resides in the secondary boot image area:

ACOS(config)# bootimage hd sec

Secondary image will be used if system is booted from hard disk

 

3.     Using the reboot command to reboot the device from the specified boot image area.

After the device is rebooted, you can link to the configuration profile of your choice. (See Generating New Profiles for more information about how the migration tool handles existing profiles.)

After reverting to your 2.7.2.x or 2.8.2.x release, your legacy admin configuration will no longer exist. You must re-configure all admins that have a specified role, or privileges for multiple partitions.

Upgrading Existing aVCS Configurations to ACOS 4.1.0

To upgrade to ACOS 4.1.0 from any earlier 4.0.x release or legacy 2.7.2.x or 2.8.2.x if aVCS is configured, follow the procedure described in this section. In this example, the virtual chassis contains two devices; the current VRRP-A active device and vMaster “ACOS1,” and the current VRRP-A standby and vBlade device “ACOS2.”

In general terms, the procedure does the following:

1.     Save and backup your configuration on both devices.

2.     Disable aVCS on ACOS2.

3.     Force VRRP-A to fail over from ACOS1 to ACOS2.

4.     Upgrade and reboot ACOS1.

5.     Force VRRP-A fail over from ACOS2 back to ACOS1.

6.     Without saving the configuration on ACOS2, upgrade and reboot ACOS2.

After the reboot, your original configuration will be loaded and ACOS2 will re-join the aVCS chassis and become the VRRP-A standby device. Your VRRP-A configuration is not disrupted due to the manual forced failover caused by changing the VRID priorities.

Below are the specific instructions:

NOTE:                               This example shows an upgrade from an earlier 4.0.x release to Release 4.1.0. If you are upgrading from a 2.7.2.x or 2.8.2.x release, the procedures remain unchanged but the CLI commands and prompt may differ slightly.

1.     Obtain the appropriate upgrade package (see Upgrade Image File Names).

2.     On all devices in the virtual chassis, save the startup configuration to a new profile. Use the all-partitions option if you have L3V partitions configured. Do not link the profile; this profile will serve as the local backup of the 4.1.0 configura­tion. For example, on the current vMaster “ACOS1:”

ACOS1-vMaster[8/1](config)# write memory backup_profile all-partitions

Building configuration...

Write configuration to profile "backup_profile"

Do you want to link "backup_profile" to startup-config profile? (y/n): n 

[OK]

 

3.     Backup your system to a remote device. For example:

ACOS1-vMaster[8/1](config)# backup system scp://exampleuser@examplehost/dir1/dir2/

 

4.     On the vBlade device “ACOS2,” disable aVCS.

ACOS2-vBlade[8/1](config:2)# vcs disable

ACOS2-vBlade[8/1](config:2)#Mar 21 2016 16:14:41 B3 a10logd: [VCS]<3> dcs thread peer closed connection prematurely

Mar 21 2016 16:14:41 B3 a10logd: [CLI]<3> rimacli: socket select operation failed

Mar 21 2016 16:14:41 B3 a10logd: [CLI]<3> rimacli: terminted because received SIGTERM signal

 

ACOS2# show vcs summary

VCS is not active.

ACOS2#

 

5.     On “ACOS2:”

a.     Access the configuration level for the VRRP-A VRID in the shared partition and each L3V partition. For example:

ACOS2# configure

ACOS2(config)# vrrp-a vrid 1

ACOS2(config-vrid:1)#

b.     Change the VRID priority to a value that is higher than the priority on the vMaster. For example, if the VRID priority on the vMaster is 100, we can change the priority to 105:

ACOS2(config-vrid:1)# blade-parameters

ACOS2(config-vrid:1-blade-parameters)# priority 105

ACOS2(config-vrid:1-blade-parameters)# exit

ACOS2(config-vrid:1)# exit

ACOS2(config)#

 

This will cause VRRP-A to fail over so that ACOS2, now with the higher priority, becomes the new active device.

6.     Install the Release 4.1.0 image on ACOS1 and reboot the device for the change to take effect. See Upgrade Instructions.

7.     On ACOS2:

a.     Access the configuration level for the VRRP-A VRID in the shared partition and each L3V partition. For example:

ACOS2(config)# vrrp-a vrid 1

ACOS2(config-vrid:1)#

 

b.     In the shared partition and all L3V partitions, change the VRID priority back to its original value, or any value that is lower than the value on ACOS1. For example, if the VRID priority on ACOS1 is 100, we can change the priority to 99 on ACOS2:

ACOS2(config-vrid:1)# blade-parameters

ACOS2(config-vrid:1-blade-parameters)# priority 99

ACOS2(config-vrid:1-blade-parameters)# exit

ACOS2(config-vrid:1)# exit

ACOS2(config)#

 

This will cause VRRP-A to fail over so that the ACOS1 will once again become the active device.

8.     Without saving the configuration, install the Release 4.1.0 image on ACOS2 and reboot the device for the change to take effect. See Upgrade Instructions.

After ACOS2 is rebooted, your original configuration (saved in step 2) will be loaded and ACOS2 will rejoin the virtual chassis and the upgrade of the chassis to Release 4.1.0 is complete.

Upgrading to ACOS 4.1.0 From 4.0.x Releases

To upgrade to ACOS 4.1.0 from earlier 4.0.x releases if aVCS is not configured:

1.     Obtain the appropriate upgrade package (see Upgrade Image File Names).

2.     Use this upgrade package and follow the instructions in Upgrade Instructions.

To upgrade to ACOS 4.1.0 from earlier 4.0.x release if aVCS is configured, follow the instructions in Upgrading Existing aVCS Configurations to ACOS 4.1.0.

 

Table of Contents

Index

Glossary

-Search-

Back