Redundancy State For Software Upgrade Or Downgrade; Guidelines And Limitations - Cisco 4700M Administration Manual

Chapter 6 Configuring Redundant ACEs

Redundancy State for Software Upgrade or Downgrade

The STANDBY_WARM and WARM_COMPATIBLE redundancy states are used when upgrading or
downgrading the ACE software. When you upgrade or downgrade the ACE from one software version
to another, there is a point in the process when the two ACEs have different software versions and,
therefore, a CLI incompatibility.
When the software versions are different while upgrading or downgrading, the STANDBY_WARM and
WARM_COMPATIBLE states allows the configuration and state synchronization process to continue on
a best-effort basis, which means that the active ACE will continue to synchronize configuration and state
information to the standby even though the standby may not recognize or understand the CLI commands
or state information. These states allow the standby ACE to come up with best-effort support. In the
STANDBY_WARM state, as with the STANDBY_HOT state, the configuration mode is disabled and
configuration and state synchronization continues. A failover from the active to the standby based on
priorities and preempt can still occur while the standby is in the STANDBY_WARM state.

Guidelines and Limitations

Configuring redundant ACEs has the following guidelines and limitations:
•
•
•
•
•
•
•
•
OL-20823-01
Redundancy is not supported between an ACE module and an ACE appliance operating as peers.
Redundancy must be of the same ACE device type and software release.
You can configure a maximum of two ACEs (peers) for redundancy.
Each peer appliance can contain one or more fault-tolerant (FT) groups. Each FT group consists of
two members: one active context and one standby context. For more information about contexts, see
the Cisco 4700 Series Application Control Engine Appliance Virtualization Configuration Guide.
An FT group has a unique group ID that you assign.
One virtual MAC address (VMAC) is associated with each FT group. The format of the VMAC is:
00-0b-fc-fe-1b-groupID. Because a VMAC does not change upon switchover, the client and server
ARP tables do not require updating. The ACE selects a VMAC from a pool of virtual MACs
available to it. You can specify the pool of MAC addresses that the local ACE and the peer ACE use
by configuring the shared-vlan-hostid command and the peer shared-vlan-hostid command,
respectively. To avoid MAC address conflicts, be sure that the two pools are different on the two
ACEs. For more information about VMACs and MAC address pools, see the Cisco 4700 Series
Application Control Engine Appliance Routing and Bridging Configuration Guide.
In bridged mode (Layer 2), two contexts cannot share the same VLAN.
To achieve active-active redundancy, a minimum of two contexts and two FT groups are required on
each ACE.
When you configure redundancy, the ACE keeps all interfaces that do not have an IP address in the
Down state. The IP address and the peer IP address that you assign to a VLAN interface should be
in the same subnet, but different IP addresses. For more information about configuring VLAN
interfaces, see the Cisco 4700 Series Application Control Engine Appliance Routing and Bridging
Configuration Guide.
The ACE does not replicate SSL and other terminated (proxied) connections from the active context
to the standby context.
Cisco 4700 Series Application Control Engine Appliance Administration Guide
Guidelines and Limitations
6-5