The Stateful Interchassis Redundancy feature enables you to configure pairs of devices to act as backups for each other.
This module describes conceptual information about and tasks for configuring stateful interchassis redundancy.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information,
see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module,
and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature
Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for Stateful Interchassis Redundancy
All application redundancy configurations, including Network Address Translation (NAT) rules that have redundancy group associations
and mapping IDs, must be identical on both devices, or NAT sessions will not be synchronized between devices and NAT redundancy
will not work.
Restrictions for Stateful
Network Address Translation (NAT) high availability (inter and intrabox) does
not replicate HTTP sessions to the standby device. To replicate HTTP sessions
on the standby device during a switchover, you must configure the
ip nat switchover
replication http command.
payload translations with certain applications, there can be IP addresses in
the payload that require NAT translation. The application-level gateway (ALG)
for that specific application parses the packet for these IP addresses, NAT
translates these addresses, and the ALG writes the translated addresses back
into the packet.
the writing of the translated IP address back into the packet. The write back
of data can change the length of a packet, which results in the adjustment of
the packet's TCP sequence (SEQ) or acknowledgment (ACK) values by NAT for the
life of the TCP connection. NAT writes the new TCP SEQ/ACK values into the
packet during SEQ/ACK fixup.
during a TCP ALG session, SEQ/ACK values may require fixup with mainly ASCII
applications such as Domain Name System (DNS), FTP/FTP64, H.323, Real Time
Streaming Protocol (RTSP), and Session Initiation Protocol (SIP). This SEQ/ACK
adjustment information gets associated with the NAT session and is synchronized
to the standby device periodically.
stateful switchover, if the SEQ/ACK information is not completely synchronized
to the new active device it is likely that the TCP connection would be reset by
endpoints of the application.
interchassis redundancy cannot coexist with intrachassis redundancy, including
Software Upgrade (ISSU) is not supported.
the paired-address-pooling, bulk port-allocation, or NAT mode settings the
following steps must be followed:
the redundancy group and NAT interfaces on the standby device using the
command. Clear NAT sessions on the standby
device after shutting down the redundancy group.
paired-address-pooling, bulk port-allocation, or NAT mode on the standby device
first and then on the active device.
command for the redundancy group and NAT
interfaces on the standby device.
For a standalone NAT router, shut down the NAT interfaces before you make a configuration change.
Information About Stateful Interchassis Redundancy
Stateful Interchassis Redundancy Overview
You can configure the Stateful Interchassis Redundancy feature to determine the active device from a group of devices, based
on a number of failover conditions. When a failover occurs, the standby device seamlessly takes over, starts performing traffic
forwarding services, and maintains a dynamic routing table.
You can configure
pairs of devices to act as hot standbys for each other. Redundancy is
configured on an interface basis. Pairs of redundant interfaces are known as
redundancy groups (RGs). Redundancy occurs at an application level and does not
require a complete physical failure of the interface or device for a switchover
of the application to occur. When a switchover occurs, the application activity
continues to run seamlessly on the redundant interface.
The figure below
depicts an active/standby load-sharing scenario. The figure shows how an RG is
configured for a pair of devices that has one outgoing interface. Group A on
Router 1 is the active RG and Group A on Router 2 is the standby RG.
are joined by a configurable control link and a data synchronization link. The
control link is used to communicate the status of devices. The data
synchronization link is used to transfer stateful information from Network
Address Translation (NAT) and the firewall and synchronize the stateful
database. The pairs of redundant interfaces are configured with the same unique
ID number known as the redundant interface identifier (RII).
The status of
redundancy group members is determined through the use of hello messages sent
over the control link. The software considers either device not responding to a
hello message within a configurable amount of time to be a failure and
initiates a switchover. For the software to detect a failure in milliseconds,
control links run the failover protocol that is integrated with the
Bidirectional Forwarding Detection (BFD) protocol. You can configure the
following parameters for hello messages:
Hello time—Interval at
which hello messages are sent.
Hold time—Amount of time
before which the active or standby device is declared to be down.
The hello time
defaults to 3 seconds to align with the Hot Standby Router Protocol (HSRP), and
the hold time defaults to 10 seconds. You can also configure these timers in
milliseconds by using the
To determine the
pairs of interfaces that are affected by the switchover, you must configure a
unique ID for each pair of redundant interfaces. This ID is known as the RII
that is associated with the interface.
A switchover to the
standby device can occur when the priority setting that is configured on each
device changes. The device with the highest priority value acts as the active
device. If a fault occurs on either the active or standby device, the priority
of the device is decremented by a configurable amount known as the weight. If
the priority of the active device falls below the priority of the standby
device, a switchover occurs and the standby device becomes the active device.
This default behavior can be overridden by disabling the preemption attribute
for the RG. You can also configure each interface to decrease the priority when
the Layer 1 state of the interface goes down. The priority that is configured
overrides the default priority of an RG.
Each failure event
that causes a modification of an RG priority generates a syslog entry that
contains a time stamp, the RG that was affected, the previous priority, the new
priority, and a description of the failure event cause.
A switchover also
can occur when the priority of a device or interface falls below a configurable
A switchover to the
standby device occurs under the following circumstances:
Power loss or a reload
occurs on the active device (including reloads).
The run-time priority of
the active device goes below that of the standby device (with preempt
The run-time priority of
the active device goes below that of the configured threshold.
The redundancy group on
the active device is reloaded manually. Use the
redundancy application reload group rg-number
command for a manual reload.
Associations with Firewalls and NAT
Firewalls use the association of the redundancy group with a traffic interface.
Network Address Translation (NAT) associates the redundancy group with a mapping ID.
The figure below shows the LAN-LAN topology. In a LAN-LAN topology, all participating devices are connected to each other
through LAN interfaces on both the inside and the outside. In this scenario, traffic is often directed to the correct firewall
if static routing is configured on the upstream or downstream devices to an appropriate virtual IP address. Cisco ASR 1000
Aggregation Services Routers participate in dynamic routing with upstream or downstream devices. The dynamic routing configuration
supported on LAN-facing interfaces must not introduce a dependency on the routing protocol convergence; otherwise, fast failover
requirements will not be met.
How to Configure Stateful Interchassis Redundancy
Configuring the Control
for the control interface protocol consists of the following elements:
Use of the
bidirectional forwarding direction (BFD) protocol
timers hellotime [msec ]
The Cisco Support and Documentation website provides online
resources to download documentation, software, and tools. Use these resources
to install and configure the software and to troubleshoot and resolve technical
issues with Cisco products and technologies. Access to most tools on the Cisco
Support and Documentation website requires a Cisco.com user ID and password.
Feature Information for
Stateful Interchassis Redundancy
The following table provides release information about the feature or features described in this module. This table lists
only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise,
subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco
Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Table 1. Feature Information for
Stateful Interchassis Redundancy
XE Release 3.1S
XE Release 3.14S
Stateful Interchassis Redundancy feature enables you to configure pairs of
devices to act as backups for each other.
IOS XE Release 3.14S, this feature was supported on Cisco CSR1000v Series