IP Addressing: NAT Configuration Guide, Cisco IOS XE Release 3S
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.
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
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 http command.
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.
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).
Figure 1. Redundancy Group
Configuration—One Outgoing Interface
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
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.
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. 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.
Figure 2. LAN-LAN Topology
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
configure terminal
redundancy
mode none
application redundancy
protocol number
name instance-name
timers hellotime [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
control interface-nameprotocol instance
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
data interface-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.
Step 17
redundancy group numberip
address
exclusive
[decrement
number]
Example:
Device(config-if)# redundancy group 1 ip 10.10.1.1 exclusive decrement 20
Associates the interface with the redundancy group identified by the
numberargument.
Step 18
redundancy rii number
Example:
Device(config-if)# redundancy rii 40
Specifies a number for the RII associated with this interface.
This number must match the RII of the other interface in the redundancy group.
Step 19
end
Example:
Device(config-if)# end
Exits interface configuration mode and enters privileged EXEC mode.
Configuring a Redundant Traffic Interface
SUMMARY STEPS
enable
configure terminal
interface
type number
ip address
ip-address mask
ip nat outside
ip virtual-reassembly
negotiation auto
redundancy rii number
redundancy group numberip
address
exclusive
[decrement
number]
end
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
interface
type number
Example:
Device(config)# interface gigabitethernet 0/1/5
Configures an interface and enters interface configuration mode.
Step 4
ip address
ip-address mask
Example:
Device(config-if)# ip address 10.1.1.2 255.0.0.0
Sets a primary or secondary IP address for an interface.
Step 5
ip nat outside
Example:
Device(config-if)# ip nat outside
Configures the outside interface for IP address translation.
Step 6
ip virtual-reassembly
Example:
Device(config-if)# ip virtual-reassembly
Enables Virtual Fragmentation Reassembly (VFR) on an interface.
Step 7
negotiation auto
Example:
Device(config-if)# negotiation auto
Enables the autonegotiation protocol to configure the speed, duplex, and automatic flow control of the Gigabit Ethernet interface.
Step 8
redundancy rii number
Example:
Device(config-if)# redundancy rii 200
Specifies a number for the redundancy interface identifier (RII) that is associated with this interface.
This number must match the RII of the other interface in the redundancy group.
Step 9
redundancy group numberip
address
exclusive
[decrement
number]
Example:
Device(config-if)# redundancy group 1 ip 10.1.1.200 exclusive decrement 10
Associates the interface with the redundancy group identified by the
numberargument.
Step 10
end
Example:
Device(config-if)# end
Exits interface configuration mode and enters privileged EXEC mode.
Configuring NAT with Stateful Interchassis Redundancy
You must use a mapping ID to associate Network Address Translation (NAT) with a redundancy group.
SUMMARY STEPS
enable
configure terminal
ip nat pool
name start-ip end-ip
{netmask
netmask
|
prefix-length
prefix-length}
ip nat inside source
list
{{access-list-number
|
access-list-name} |
route-map
name}
pool
name
[redundancy
redundancy-id
[mapping-id
map-id
|
overload
|
reversible
|
vrf
name]]
end
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
ip nat pool
name start-ip end-ip
{netmask
netmask
|
prefix-length
prefix-length}
Example:
Device(config)# ip nat pool VPN-18 10.10.0.0 10.10.255.255 netmask 255.255.0.0
Defines a pool of IP addresses for NAT.
Step 4
ip nat inside source
list
{{access-list-number
|
access-list-name} |
route-map
name}
pool
name
[redundancy
redundancy-id
[mapping-id
map-id
|
overload
|
reversible
|
vrf
name]]
Example:
Device(config)# ip nat inside source list acl-18 pool VPN-18 redundancy 2 mapping-id 152
Enables NAT of the inside source address.
You must use a mapping ID to associate NAT with the redundancy group.
Step 5
end
Example:
Device(config)# end
Exits interface configuration mode and returns to privileged EXEC mode.
Managing and Monitoring Stateful Interchassis Redundancy
All configuration commands in this task are optional. You can use the
show commands in any order.
SUMMARY STEPS
enable
redundancy application reload group number[peer |
self ]
show redundancy application group [group-id |
all ]
show redundancy application transport {clients
|
group
[group-id]}
show redundancy application protocol {protocol-id | group
[group-id]}
show redundancy application faults
group
[group-id]
show redundancy application if-mgr group
[group-id]
show redundancy application control-interface group
[group-id]
show redundancy application data-interface group
[group-id]
show monitor event-trace rg_infra all
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
redundancy application reload group number[peer |
self ]
Example:
Device# redundancy application reload group 2 self
Forces the active redundancy group (RG) to reload and the standby RG to become the active RG.
Use the
redundancy application reload command to verify if the redundancy configuration is working. You must enter this command on the active RG.
Step 3
show redundancy application group [group-id |
all ]
Example:
Device# show redundancy application group 2
Displays summary information for the specified group or for all groups.
Step 4
show redundancy application transport {clients
|
group
[group-id]}
Example:
Device# show redundancy application transport group 2
Displays transport information for the specified group or for all groups.
Step 5
show redundancy application protocol {protocol-id | group
[group-id]}
Example:
Device# show redundancy application protocol 2
Displays protocol information for the specified group or for all groups.
Step 6
show redundancy application faults
group
[group-id]
Example:
Device# show redundancy application faults group 2
Displays information about faults for the specified group or for all groups.
Step 7
show redundancy application if-mgr group
[group-id]
Example:
Device# show redundancy application if-mgr group 2
Displays information about the interface manager (if-mgr) for the specified group or for all groups.
Step 8
show redundancy application control-interface group
[group-id]
Example:
Device# show redundancy application control-interface group IF-2
Displays interface information associated with redundancy groups for the specified control interface.
Step 9
show redundancy application data-interface group
[group-id]
Example:
Device# show redundancy application data-interface group IF-2
Displays interface information associated with redundancy groups for the specified data interface.
Step 10
show monitor event-trace rg_infra all
Example:
Device# show monitor event-trace rg_infra all
Displays event trace information associated with all redundancy groups.
Configuration Examples for Stateful Interchassis Redundancy
Example: Configuring the
Control Interface Protocol
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.
Feedback