IP Addressing: NAT Configuration Guide, Cisco IOS XE Gibraltar 16.10.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
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
Interchassis Redundancy
By default,
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 httpcommand.
During NAT
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.
Fixup denotes
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.
For example,
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.
During a
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.
Stateful
interchassis redundancy cannot coexist with intrachassis redundancy, including
software redundancy.
In Service
Software Upgrade (ISSU) is not supported.
When changing
the paired-address-pooling, bulk port-allocation, or NAT mode settings the
following steps must be followed:
Shutdown
the redundancy group and NAT interfaces on the standby device using the
shutdown
command. Clear NAT sessions on the standby
device after shutting down the redundancy group.
Change the
paired-address-pooling, bulk port-allocation, or NAT mode on the standby device
first and then on the active device.
Configure
the
no shutdown
command for the redundancy group and NAT
interfaces on the standby device.
In a NAT Stateful Interchassis Redundancy configuration, it is mandatory that both peers use the same inside and outside NAT
interfaces. If the interfaces are not same, it can lead to duplicate NAT entries.
The following translations are not synchronized to the standby router :
Translations created based on an interface overload rule
ICMP requests
Note
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.
Note
Manually shutting down the control or data interface link on an active NAT router results in traffic outage as the NAT router
never transitions to active state.
Stateful Interchassis
Redundancy Operation
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.
Redundant devices
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
timers hellotime
msec command.
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
threshold level.
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
configured).
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
redundancyapplicationreloadgrouprg-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.
LAN-LAN Topology
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. This plaform 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
Interface Protocol
The configuration
for the control interface protocol consists of the following elements:
Authentication information
Group name
Hello time
Hold time
Protocol
instance
Use of the
bidirectional forwarding direction (BFD) protocol
SUMMARY STEPS
enable
configureterminal
redundancy
modenone
applicationredundancy
protocolnumber
nameinstance-name
timershellotime [msec]
numberholdtime
[msec]
number
Device(config-red-app-prot)# authentication text password
Specifies
authentication information.
Step 10
bfd
Example:
Device(config-red-app-prot)# bfd
(Optional)
Enables the integration of the failover protocol running on the control
interface with the BFD protocol to achieve failure detection in milliseconds.
Specifies the amount of time by which the redundancy group will delay role negotiations that start after a fault occurs or
after the system is reloaded.
Step 11
controlinterface-nameprotocolinstance
Example:
Device(config-red-app-grp)# control GigabitEthernet0/1/0 protocol 1
Specifies the control interface that is used by the redundancy group.
This interface is also associated with an instance of the control interface protocol.
Step 12
datainterface-name
Example:
Device(config-red-app-grp)# data GigabitEthernet0/1/2
Specifies the data interface that is used by the redundancy group.
Step 13
To create another redundancy group, repeat Steps 3 through 12.
—
Step 14
end
Example:
Device(config-red-app-grp)# end
Exits redundancy application group configuration mode and enters privileged EXEC mode.
Step 15
configure terminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 16
interface
type number
Example:
Device(config)# interface gigabitethernet 0/0/1
Selects an interface to associate with the redundancy group and enters interface configuration mode.
Device# configure terminal
Device(config)# redundancy
Device(config-red)# application redundancy
Device(config-red-app)# group 1
Device(config-red-app-grp)# name rg1
Device(config-red-app-grp)# preempt
Device(config-red-app-grp)# priority 120 failover-threshold 80
Device(config-red-app-grp)# track 44 decrement 20
Device(config-red-app-grp)# timers delay 10 reload 20
Device(config-red-app-grp)# control GigabitEthernet0/1/0 protocol 1
Device(config-red-app-grp)# data GigabitEthernet0/1/2
Device(config-red-app-grp)# end
Device# configure terminal
Device(config)# interface GigabitEthernet 0/0/1
Device(config-if)# redundancy group 1 ip 10.10.1.1 exclusive decrement 20
Device(config-if)# redundancy rii 40
Example: Configuring a Redundant Traffic Interface
Device# configure terminal
Device(config)# interface GigabitEthernet 0/1/5
Device(config-if)# ip address 10.1.1.2 255.0.0.0
Device(config-if)# ip nat outside
Device(config-if)# ip virtual-reassembly
Device(config-if)# negotiation auto
Device(config-if)# redundancy rii 200
Device(config-if)# redundancy group 1 ip 10.1.1.200 exclusive decrement 10
Example: Configuring NAT with Stateful Interchassis Redundancy
Device# configure terminal
Device(config)# ip nat pool VPN-18 10.10.0.0 10.10.255.255 netmask 255.255.0.0
Device(config)# ip nat inside source list acl-18 pool VPN-18 redundancy 2 mapping-id 152
Additional References for
Stateful Interchassis Redundancy
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.