Cisco Content Services Switch Redundancy Configuration Guide
Cisco Content Services Switch Redundancy Configuration Guide
Cisco Content Services Switch Redundancy Configuration Guide
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Text Part Number: OL-5651-02
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT
NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT
ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR
THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE
INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU
ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A
COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as
part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE
PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED
OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL
DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR
INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work,
Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP,
CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the
Cisco Systems logo, Cisco Unity, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare,
GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys,
MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX,
ScriptShare, SlideCast, SMARTnet, StrataView Plus, TeleRouter, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered
trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (0502R)
CONTENTS
Preface xiii
Audience xiv
How to Use This Guide xiv
Related Documentation xv
Symbols and Conventions xviii
Obtaining Documentation xix
Cisco.com xix
Documentation DVD xx
Ordering Documentation xx
Documentation Feedback xxi
Cisco Product Security Overview xxi
Reporting Security Problems in Cisco Products xxii
Obtaining Technical Assistance xxii
Cisco Technical Support Website xxiii
Submitting a Service Request xxiii
Definitions of Service Request Severity xxiv
Obtaining Additional Publications and Information xxv
CHAPTER
iii
Contents
iv
OL-5651-02
Contents
Contents
CHAPTER
vi
OL-5651-02
Contents
CHAPTER
OL-5651-02
vii
Contents
viii
OL-5651-02
F I G U R E S
Figure 1-1
Figure 1-2
Figure 1-3
1-9
Figure 1-4
1-12
Figure 1-5
Figure 2-1
Figure 3-1
Figure 3-2
Figure 3-3
Figure 3-4
1-5
1-8
1-15
2-6
3-5
3-22
ix
Figures
OL-5651-02
T A B L E S
Table 1-1
Table 1-2
Table 1-3
Table 1-4
Table 1-5
Table 1-6
Table 1-7
Effect of Interface State on Reporter and Virtual Router State Based on Reporter
Type 1-40
Table 1-8
Table 1-9
Table 1-10
Table 1-11
Table 1-12
Table 1-13
Table 2-1
Table 2-2
Table 2-3
Table 2-4
Table 2-5
Table 3-1
3-7
Table 3-2
3-10
Table 3-3
1-16
1-26
1-26
1-27
1-28
1-37
1-51
1-52
1-54
1-57
1-60
1-62
2-12
2-20
2-21
2-22
2-24
3-38
xi
Tables
xii
OL-5651-02
Preface
This guide provides instructions for configuring the redundancy features of the
Cisco 11500 Series Content Services Switches (CSS). Information in this guide
applies to all CSS models except where noted.
The CSS software is available in a Standard or optional Enhanced feature set. The
Enhanced feature set contains all of the Standard feature set and also includes
Network Address Translation (NAT) Peering, Domain Name Service (DNS),
Demand-Based Content Replication (Dynamic Hot Content Overflow), Content
Staging and Replication, and Network Proximity DNS. Proximity Database and
Secure Management, which includes Secure Shell Host and SSL strong
encryption for the Device Management software, are optional features.
This preface contains the following major sections:
Audience
Related Documentation
Obtaining Documentation
Documentation Feedback
xiii
Preface
Audience
Audience
This guide is intended for the following trained and qualified service personnel
who are responsible for configuring the CSS:
Web master
System administrator
System operator
Description
Chapter 1,
Configuring VIP and Virtual
Interface Redundancy
Chapter 2,
Configuring Adaptive Session
Redundancy
Chapter 3,
Configuring Box-to-Box
Redundancy
xiv
OL-5651-02
Preface
Related Documentation
Related Documentation
In addition to this guide, the Content Services Switch documentation includes the
following publications.
Document Title
Description
xv
Preface
Related Documentation
Document Title
Description
SNMP
RMON
Spanning-tree bridging
xvi
OL-5651-02
Preface
Related Documentation
Document Title
Description
Services
Source groups
Owners
Content rules
Sticky parameters
Content caching
Content replication
DNS Sticky
Client-Side Accelerator
Network proximity
xvii
Preface
Symbols and Conventions
Document Title
Description
Radius
TACACS+
SSL termination
Backend SSL
SSL initiation
Caution
A caution means that a specific action you take could cause a loss of data or
adversely impact use of the equipment.
xviii
OL-5651-02
Preface
Obtaining Documentation
Warning
Note
A warning describes an action that could cause you physical harm or damage
the equipment.
prompt.
Courier bold text
Italics text indicates the first occurrence of a new term, book title, emphasized
text, and variables for which you supply values.
1.
A numbered list indicates that the order of the list items is important.
a. An alphabetical list indicates that the order of the secondary list items is
important.
A bulleted list indicates that the order of the list topics is unimportant.
An indented list indicates that the order of the list subtopics is
unimportant.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco
also provides several ways to obtain technical assistance and other technical
resources. These sections explain how to obtain technical information from Cisco
Systems.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/univercd/home/home.htm
xix
Preface
Obtaining Documentation
Documentation DVD
Cisco documentation and additional literature are available in a Documentation
DVD package, which may have shipped with your product. The Documentation
DVD is updated regularly and may be more current than printed documentation.
The Documentation DVD package is available as a single unit.
Registered Cisco.com users (Cisco direct customers) can order a Cisco
Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool
or Cisco Marketplace.
Cisco Ordering tool:
http://www.cisco.com/en/US/partner/ordering/
Cisco Marketplace:
http://www.cisco.com/go/marketplace/
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
Registered Cisco.com users (Cisco direct customers) can order Cisco product
documentation from the Ordering tool:
http://www.cisco.com/en/US/partner/ordering/
xx
OL-5651-02
Preface
Documentation Feedback
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front
cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
A current list of security advisories and notices for Cisco products is available at
this URL:
http://www.cisco.com/go/psirt
If you prefer to see advisories and notices as they are updated in real time, you
can access a Product Security Incident Response Team Really Simple Syndication
(PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
xxi
Preface
Obtaining Technical Assistance
Tip
Emergencies security-alert@cisco.com
Nonemergencies psirt@cisco.com
1 877 228-7302
1 408 525-6532
xxii
OL-5651-02
Preface
Obtaining Technical Assistance
Note
Use the Cisco Product Identification (CPI) tool to locate your product serial
number before submitting a web or phone request for service. You can access the
CPI tool from the Cisco Technical Support Website by clicking the Tools &
Resources link under Documentation & Tools. Choose Cisco Product
Identification Tool from the Alphabetical Index drop-down list, or click the
Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool
offers three search options: by product ID or model name; by tree view; or for
certain products, by copying and pasting show command output. Search results
show an illustration of your product with the serial number label location
highlighted. Locate the serial number label on your product and record the
information before placing a service call.
xxiii
Preface
Obtaining Technical Assistance
For S1 or S2 service requests or if you do not have Internet access, contact the
Cisco TAC by telephone. (S1 or S2 service requests are those in which your
production network is down or severely degraded.) Cisco TAC engineers are
assigned immediately to S1 and S2 service requests to help keep your business
operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447
For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts
xxiv
OL-5651-02
Preface
Obtaining Additional Publications and Information
xxv
Preface
Obtaining Additional Publications and Information
xxvi
OL-5651-02
C H A P T E R
1-1
Chapter 1
Users do not experience long network delays or black holes due to a single
point of failure.
The following sections provide information about when (and when not) to use the
different types of redundancy.
When you have a common subnet between the two CSSs on which the VIPs
reside
1-2
OL-5651-02
Chapter 1
Instead of VIP redundancy on the client side of the CSS when the VIPs are
on a subnet different from the subnet of your uplinks
After you have first configured active-backup VIP and virtual interface
redundancy
Expect the behavior of the CSSs to be active/standby (only the master CSS
processes flows)
Can configure a dedicated Fast Ethernet (FE) link between the CSSs for the
redundancy protocol
1-3
Chapter 1
Note
VIP Redundancy
Fate Sharing
When using VIP or VIP interface redundancy with zone-based Global Server
Load Balancing (GSLB), both the master and backup CSSs provide DNS
information over their APP sessions. In this configuration, we recommend that
you configure the master and backup CSSs in their own separate zones. A CSS in
a GSLB configuration expects to receive zone-based information from only one
CSS source within another zone. If the CSS receives information from more than
one CSS within the zone, the CSS ignores the additional information, potentially
causing unexpected results to DNS queries.
VIP Redundancy
When you configure a pair of CSSs to process client requests for the same VIP
address, the VIP address is considered redundant. A typical use of VIP
redundancy is with a virtual interface redundancy configuration where the master
CSS processes all client requests to a VIP with a Web-server farm behind the
CSSs and connected to the CSSs through a Layer 2 switch (Figure 1-1). If the
master CSS becomes unavailable, the backup CSS becomes master and processes
all client requests for the VIP.
Note
The CSS does not support VIP redundancy and box-to-box redundancy
configurations simultaneously. For information about box-to-box redundancy,
refer to Chapter 3, Configuring Box-to-Box Redundancy.
1-4
OL-5651-02
Chapter 1
To set up CSSs for VIP redundancy, you must configure a virtual router (VR) on
each CSS that will participate in the redundant configuration. A VR is an entity
within a CSS with which you associate an existing VIP. A VIP becomes redundant
when you associate it with a VR. You can configure a maximum of 255 VRs for
each VLAN.
Note
Figure 1-1
The VIP address must already exist in at least one active content rule or source
group.
VLAN2
192.1.1.2
Web Servers
VLAN1
10.1.1.2
CSS-2
Redundant Interface
192.1.1.254
Backup
VIP Active
192.1.1.100
Client
Redundant Interface
10.1.1.254
Active
VLAN2
192.1.1.1
VLAN1
10.1.1.1
119693
CSS-1
L2 Switch
Virtual routers providing redundancy for a VIP address are considered a VR pair.
Each VR pair has the same VR identifier (VRID) and runs on the same VLAN,
but runs on a different CSS. Once the VRs are configured, the CSSs negotiate for
mastership using Virtual Router Redundancy Protocol (VRRP). A VR in a
redundant VIP configuration that is designated as:
1-5
Chapter 1
master CSS
Shared backup VR, which processes all client requests it receives and
does not forward requests for the VIP to the master CSS
A CSS designated as the master of a VIP automatically sends a gratuitous ARP
for the VIP when the CSS becomes the master, either at startup or upon failover.
This process enables the Layer 2 switch to learn where to forward packets that are
directed to the VIP from clients. The CSS transmits one ARP request packet and
one ARP reply packet for every gratuitious ARP invocation.
For an example of VIP and virtual interface redundancy, see Figure 1-1.
CSSs with the redundant virtual interface are positioned in front of the Layer
2 switch
The servers are configured with a default route (gateway) pointing to the
redundant virtual interface IP address on the private side of the CSS
You must configure VRs with the same VRIDs on the subnets that are common to
both CSSs. Once you associate the new VRIDs with the redundant virtual
interface IP addresses, the CSSs uses VRRP to negotiate mastership of the
redundant virtual interfaces.
1-6
OL-5651-02
Chapter 1
Note
Fate Sharing
Fate sharing means that, when the redundant VIP fails over on the public side of
the network from the master to the backup CSS, the redundant virtual interfaces
on the public and the private sides of the network also fail over from the master
to the backup CSS. If you do not configure virtual interface redundancy with VIP
redundancy, asymmetric flows may result (Figure 1-2). Asymmetric flows occur
when a CSS is master on the public side, but backup on the private side, which
breaks the connection between the client and the server.
To ensure that the redundant VIP and the redundant virtual interfaces fail over at
the same time, you must bind the front and the back instances of VRRP (the VRs)
so that the same CSS processes both inbound and outbound flows. You
accomplish this by defining as critical services the IP addresses of the upstream
router (the CSS default gateway) and the downstream Layer 2 switch that
connects to the servers.
1-7
Chapter 1
For example, the CSS provides a scripted keepalive (ap-kal-pinglist) that will
check the health of the upstream router and the downstream Layer 2 switch. When
you configure this keepalive, if either device fails, the critical service goes down
and the redundant VIP and the redundant virtual interfaces fail over together to
the backup CSS. For details on configuring critical services, see the Configuring
a Critical Service section.
Figure 1-2
Web Servers
L2 Switch
VLAN2
192.1.1.2
VLAN1
10.1.1.2
CSS-2
Redundant Interface
192.1.1.254
Backup
Client
VIP Active
192.1.1.100
Active
Active
Redundant Interface
10.1.1.254
Backup
VLAN2
192.1.1.1
VLAN1
10.1.1.1
119694
CSS-1
1-8
OL-5651-02
Chapter 1
VLAN2
192.1.1.2
Web Servers
VLAN1
10.1.1.2
CSS-2
Redundant Interface
192.1.1.254
Backup
Client
VIP Active
192.1.1.100
Redundant Interface
10.1.1.254
Active
VLAN2
192.1.1.1
VLAN1
10.1.1.1
119693
CSS-1
L2 Switch
1-9
Chapter 1
CSS-1 Configuration
circuit VLAN1
ip address 10.1.1.1 255.255.255.0
ip virtual-router 1 priority 101 preempt
ip redundant-interface 1 10.1.1.254
ip critical-service 1 upstream_downstream
circuit VLAN2
ip address 192.1.1.1 255.255.255.0
ip virtual-router 2 priority 101 preempt
ip redundant-vip 2 192.1.1.100
ip redundant-interface 2 192.1.1.254
ip critical-service 2 upstream_downstream
CSS-2 Configuration
circuit VLAN1
ip address 10.1.1.2 255.255.255.0
ip virtual-router 1
ip redundant-interface 1 10.1.1.254
ip critical-service 1 upstream_downstream
circuit VLAN2
ip address 192.1.1.2 255.255.255.0
ip virtual-router 2
ip redundant-vip 2 192.1.1.100
ip redundant-interface 2 192.1.1.254
ip critical-service 2 upstream_downstream
1-10
OL-5651-02
Chapter 1
1-11
Chapter 1
Figure 1-4
VLAN2
192.1.1.2
VLAN1
10.1.1.2
L2 Switch
Redundant Interface
192.1.1.253
CSS-2
Active
Active
VIP Active
192.1.1.101
Redundant Interface
10.1.1.253
VIP Active
192.1.1.100
Redundant Interface
10.1.1.254
Default Gateway
10.1.1.253
Client
Active
VLAN2
192.1.1.1
CSS-1
VLAN1
10.1.1.1
Default Gateway
10.1.1.254
119695
Redundant Interface
192.1.1.254
Active
CSS-1 Configuration
circuit VLAN1
ip address 10.1.1.1 255.255.255.0
ip virtual-router 1 priority 101 preempt
ip virtual-router 2
ip redundant-interface 1 10.1.1.254
ip redundant-interface 2 10.1.1.253
ip critical-service 1 upstream_downstream
ip critical-service 2 upstream_downstream
1-12
OL-5651-02
Chapter 1
circuit VLAN2
ip address 192.1.1.1 255.255.255.0
ip virtual-router 3 priority 101 preempt
ip virtual-router 4
ip redundant-vip 3 192.1.1.100
ip redundant-vip 4 192.1.1.101
ip redundant-interface 3 192.1.1.254
ip redundant-interface 4 192.1.1.253
ip critical-service 3 upstream_downstream
ip critical-service 4 upstream_downstream
CSS-2 Configuration
circuit VLAN1
ip address 10.1.1.2 255.255.255.0
ip virtual-router 1
ip virtual-router 2 priority 101 preempt
ip redundant-interface 1 10.1.1.254
ip redundant-interface 2 10.1.1.253
ip critical-service 1 upstream_downstream
ip critical-service 2 upstream_downstream
circuit VLAN2
ip address 192.1.1.2 255.255.255.0
ip virtual-router 3
ip virtual-router 4 priority 101 preempt
ip redundant-vip 3 192.1.1.100
ip redundant-vip 4 192.1.1.101
ip redundant-interface 3 192.1.1.254
ip redundant-interface 4 192.1.1.253
ip critical-service 3 upstream_downstream
ip critical-service 4 upstream_downstream
1-13
Chapter 1
Note
Shared VIP redundancy is not supported with VRID peering. See the
Configuring VRID Peering section.
A shared VIP redundancy configuration has the following requirements:
Direct connection between the CSSs to enable the backup CSS to forward
ARP requests to the master CSS
Direct connection from the servers to the CSSs eliminating the need for fate
sharing
Notice that CSS-2 (shared backup VR for VIP 192.1.1.100) forwards the ARP
request for 192.1.1.100 to CSS-1 for a response.
1-14
OL-5651-02
Chapter 1
Router
192.1.3.1
ARP 192.1.1.100
VLAN2
192.1.1.2
Ip route 192.1.1.0
255.255.255.0 192.1.2.1.1
Ip route 192.1.1.0
255.255.255.0 192.1.3.1.1
Web Servers
CSS-2
Backup
VIP Active
192.1.1.100
Client
ECMP
Upstream
Router
Mirrored
Content
Master
VLAN2
192.1.1.1
192.1.2.1
VLAN1
10.1.1.2
CSS-1
VLAN1
10.1.1.1
Router
83843
Figure 1-5
Web Servers
CSS-1 Configuration
circuit VLAN1
ip address 10.1.1.1 255.255.255.0
circuit VLAN2
ip address 192.1.1.1 255.255.255.0
ip virtual-router 1
ip redundant-vip 1 192.1.1.100 shared
1-15
Chapter 1
VIP and Virtual Interface Redundancy Configuration Quick Start
CSS-2 Configuration
circuit VLAN1
ip address 10.1.1.2 255.255.255.0
circuit VLAN2
ip address 192.1.1.2 255.255.255.0
ip virtual-router 1
ip redundant-vip 1 192.1.1.100 shared
2.
ip address 192.1.1.75
keepalive type script
keepalive frequency 2
keepalive maxfailure 2
keepalive retryperiod 2
active
1-16
OL-5651-02
Chapter 1
Table 1-1
4.
5.
6.
7.
8.
9.
1-17
Chapter 1
VIP and Virtual Interface Redundancy Configuration Quick Start
Table 1-1
You would configure CSS-2 in a similar manner, with the exception of the
priority and preempt options of the ip virtual-router command.
The following running-config example shows the results of entering the
commands listed in Table 1-1.
1-18
OL-5651-02
Chapter 1
1-19
Chapter 1
Note
When you use the circuit command, enter the word VLAN in uppercase letters
and do not include a space between VLAN and the VLAN number (for example,
VLAN1).
To assign an IP address to a circuit, use the ip address command from the specific
circuit mode. Enter the IP address and a subnet mask in CIDR bitcount notation
or dotted-decimal notation. The subnet mask range is /8 to /32. For example, to
configure an IP address and subnet mask for VLAN1, enter:
(config-circuit[VLAN2])# ip address 192.1.1.1 /24
Note
vrid - The virtual router identifier (VRID). Enter an integer between 1 and
255. You can configure 255 VRs per VLAN. Virtual routers are considered
peers when they have the same VRID and reside in the same VLAN.
1-20
OL-5651-02
Chapter 1
priority number - The optional priority of the VR with respect to its peers.
The default priority value is 100. Enter an integer between 1 and 255. A VR
with the highest priority usually becomes master. However, a higher priority
VR will not assume mastership from a lower priority master unless you
include the preempt option.
When a VR is the master, it handles the traffic directed to its associated VIPs.
To set a VR so that it will always be master, set its priority to 255 and
configure it with the preempt option.
Caution
Never configure the preempt option on the same VR on both CSSs. Such a
configuration may result in both CSSs becoming master, which will cause
network problems.
Because a VRs priority is dependent on the state of the critical services, the
priority field status in the show virtual router display may be different than the
priority you configured. The priority may be different when you:
go down. Local services include all services other than scripted and
uplink.
Cisco Content Services Switch Redundancy Configuration Guide
OL-5651-02
1-21
Chapter 1
Note
Before you use this command, the VIP must already be configured in at least one
active content rule or source group. Additionally, if you defined the content rule
or source group VIP using the range option, you must configure an identical range
for the redundant VIP. For information about configuring VIPs in content rules
and source groups, refer to the Cisco Content Services Switch Content
Load-Balancing Configuration Guide.
The syntax of this IP mode command is:
ip redundant-vip vrid vip_address {range number} {shared}
The variables and options are:
vip_address - The address for the redundant VIP. This address must already
be configured in at least one active content rule or source group. Enter an IP
address in dotted-decimal notation (for example, 192.1.1.100).
1-22
OL-5651-02
Chapter 1
Caution
shared - The optional keyword to enable shared VIP redundancy. When you
use this option, the master and backup VRs share the processing of traffic
directed to the VIP, so the backup does not forward packets to the master.
Configure each VIP identically on both CSSs.
Do not connect Layer 2 devices between the CSSs and the routers in a shared VIP
redundancy configuration. In addition, each router must be connected to only one
CSS. Otherwise, all traffic will go to the master CSS, thus defeating the purpose
of shared VIP redundancy.
For example:
(config-circuit-ip[VLAN2-192.1.1.1])# ip redundant-vip 2 192.1.1.100
range 10 shared
1-23
Chapter 1
Note
You cannot use an IP address that already exists for a VIP, redundant
VIP, source group, service, log host, or IP interface address on a
circuit. If you do, the following error message appears: Address
conflicts with local I/F, VIP, service, or source group.
For example:
(config-circuit-ip[VLAN1-10.1.1.1])# ip redundant-interface 1
10.1.1.254
Note
Background
1-24
OL-5651-02
Chapter 1
Configuring a Reporter
Activating a Reporter
Suspending a Reporter
Background
In a VIP and virtual interface redundancy configuration, you typically configure
a pair of virtual routers (VRs) running VRRP to negotiate mastership of the
redundant VIPs on the client side of the network and another pair of VRs to
negotiate mastership of the redundant interfaces on the server side of the network.
In addition, you can use critical services to provide fate sharing so that the
redundant VIPs and the redundant interfaces change state together from master to
backup. A CSS uses polling keepalives to monitor the states of critical services.
Because a link on either the public side or the private side of a CSS can go down
and then up very quickly in between keepalive polling times, it is possible for a
VR on one CSS to be the master for the redundant VIP and a VR on the other CSS
to be the master for the redundant virtual interface. This loss of synchronization
between VRs can occur even when you have configured critical services. While
this unsynchronized VR state is permitted, it may not be desirable in all cases.
Unsynchronized VRs produce asymmetric flows, which cause NAT to fail. In this
case, packets from a server will be routed to the CSS that is master for the
redundant virtual interface (default gateway), while packets from a client will be
routed to the other CSS that is master for the redundant VIP.
1-25
Chapter 1
Independent State
Conditions
Down
Backup
Master
The reporter that is responsible for monitoring the VR peers determines the
dependent state of the VRs. Table 1-3 lists the dependent VR states and describes
the conditions required for each state.
Table 1-3
Dependent State
Conditions
Down
Backup
Master
1-26
OL-5651-02
Chapter 1
When two or more VRs are configured on a reporter, their dependent state is that
of the lowest independent state of all the VR peers in the group. Table 1-4 shows
the effects of independent VR states on reporter dependent states for two VRs.
Table 1-4
Down
Down
Down
Down
Backup
Down
Down
Master
Down
Backup
Down
Down
Backup
Backup
Backup
Backup
Master
Backup
Master
Down
Down
Master
Backup
Backup
Master
Master
Master
Ensure that you have configured VIP and virtual interface redundancy
properly. See the Configuring VIP and Virtual Interface Redundancy
section.
All VRs associated with a VRID peering reporter must have the same priority
and preempt configurations.
Do not configure the same IP address and VRID on more than one reporter.
You can configure a maximum of four reporters of type VRID peer on a CSS.
OL-5651-02
1-27
Chapter 1
2.
Enter reporter configuration mode and create a new reporter. See the
Configuring a Reporter section.
(config)# reporter r1
(config-reporter[r1])#
3.
Configure the VRID peering type on the reporter. See the Configuring the
Reporter Type section.
(config-reporter[r1])# type vrid-peering
4.
Specify the VRs that you want to monitor. See the Configuring the Virtual
Routers That You Want to Monitor section.
(config-reporter[r1])# vrid 192.168.100.5 1
(config-reporter[r1])# vrid 172.16.27.12 2
5.
6.
7.
1-28
OL-5651-02
Chapter 1
Table 1-5
Configuring a Reporter
A reporter is a software agent that monitors the states of all VRs associated with
it. When a VR state change is necessary, the reporter sends a state update message
to its associated VRs. To configure a reporter and enter reporter configuration
mode, use the reporter command in global configuration mode. You can
configure a maximum of 128 reporters on a CSS.
This command has the following syntax:
reporter reporter_name
1-29
Chapter 1
The reporter_name variable specifies the name of the reporter you are creating.
Enter an unquoted text string with no spaces from 1 to 31 characters.
For example, enter:
(config)# reporter r1
Note
Note
To remove the VRID peering type or to reconfigure the reporter type as a critical
phy type:
1.
Note
1-30
OL-5651-02
Chapter 1
2.
Remove the VRID peering reporter attributes using the no vrid ip_address
vrid command. See the Configuring the Virtual Routers That You Want to
Monitor section.
3.
Remove the VRID peering reporter type using the no type command or
reconfigure the reporter type as a critical phy type using the type
critical-phy-all-up or the type critical-phy-any-up command. For details
about configuring a critical phy, see the Configuring a Critical Physical
Interface section.
4.
If you reconfigured the reporter type as a critical phy type, add the physical
interfaces using the phy interface_name command, then activate the reporter
using the active command. See the Configuring the Physical Interfaces That
You Want to Monitor section and the Activating a Reporter section.
Note
You cannot configure the same circuit IP address and VRID on more than one
reporter.
The variables for this command are:
vrid - The VR identifier (VRID). Enter the VRID of an existing VR. You can
configure a maximum of eight VRIDs on one reporter. For details on
configuring a VR, see the Configuring a Virtual Router section.
For example:
(config-reporter[r1])# vrid 192.168.12.7 1
Note
You cannot remove the last remaining VR from an active reporter. To remove the
VR, first suspend the reporter, and then remove the VR.
Cisco Content Services Switch Redundancy Configuration Guide
OL-5651-02
1-31
Chapter 1
Activating a Reporter
You must activate a reporter before it can monitor the state of its configured
VRIDs. To activate a reporter, use the active command in reporter configuration
mode. A reporter remains in the Suspended state until you activate it.
For example, enter:
(config-reporter[r1])# active
Suspending a Reporter
You can suspend an active reporter to temporarily stop using the reporter or to
change the reporter configuration. To suspend the reporter, enter the suspend
command in reporter configuration mode. When you are ready to resume using
the reporter again, reactivate the reporter using the active command. See the
Activating a Reporter section.
Note
1-32
OL-5651-02
Chapter 1
vrid - The virtual router identifier (VRID) of an existing VR. Enter an integer
between 1 and 255.
1-33
Chapter 1
Note
Local critical services for any service other than scripted or redundancy
uplink, such as a Web service. The VR goes down when all associated local
critical services go down.
For example:
(config-circuit-ip[VLAN2-192.1.1.1])# ip critical-service 1
upstream_downstream
Note
If you configure different critical services on the two CSSs and you intend to
synchronize the CSS configurations using the commit_VipRedundConfig script,
do not use the -a script argument. This argument copies the master CSS
configuration to the backup CSS configuration, which makes the two configs
identical. For details on synchronizing a VIP and virtual interface redundancy
configuration, see the Synchronizing a VIP Redundancy Configuration section.
1-34
OL-5651-02
Chapter 1
The show service command displays the current service type only. It does,
however, display the keepalive type, so you can determine from it the behavior of
a configured critical service. To display critical service-specific information, use
the show critical-services command. See the Displaying IP Critical Services
section.
SNMP values returned for services show the current service type only. To
determine the critical service behavior of a particular service, you need to
examine the service keepalive type. For more information about SNMP, refer to
the Cisco Content Services Switch Administration Guide.
Overview
Configuring a Reporter
Activating a Reporter
Suspending a Reporter
1-35
Chapter 1
Overview
A critical phy monitors the health of its associated physical interfaces and causes
a VR to fail over to the backup CSS if one or all (depending on the configuration)
monitored interfaces go down. Unlike a critical service, a critical phy does not
depend on the state of a keepalive for its operation. Therefore, a critical phy is not
susceptible to reporting delays and packet loss due to network congestion and
packet storms, which, in the case of a critical service, may cause the CSS to
incorrectly report a server as unavailable. When you associate a critical phy with
a VR, the critical phy provides rapid VR failover in the event of a physical link
failure.
To configure a critical phy, you create a software agent called a reporter, a
general-purpose monitoring mechanism. Then you specify the reporter type of
critical-phy and configure the reporter to monitor the health of one or more
physical interfaces. To complete the configuration, you modify your VIP and
virtual interface redundancy configuration to associate a critical reporter with an
existing VR.
Ensure that VIP and virtual interface redundancy is configured properly (see
the Configuring VIP and Virtual Interface Redundancy section).
If you associate more than one critical reporter with the same VR, ensure that
you do not configure the same physical interfaces (ports) on two different
reporter types (for example, ports 1/1 and 1/2 on a reporter of type
critical-phy-all-up and ports 1/1 and 1/2 on a reporter of type
critical-phy-any-up). Otherwise, unexpected VR failovers may occur.
1-36
OL-5651-02
Chapter 1
2.
Enter reporter configuration mode and create a new reporter. See the
Configuring a Reporter section.
(config)# reporter r1
(config-reporter[r1])#
3.
Configure the reporter type. See the Configuring the Reporter Type
section.
(config-reporter[r1])# type critical-phy-all-up
4.
5.
6.
7.
8.
1-37
Chapter 1
Table 1-6
Configuring a Reporter
A reporter is a software agent that the CSS uses to monitor the health of physical
interfaces when you configure the reporter as a critical phy type and associate
physical interfaces with it. To configure a reporter and enter reporter
configuration mode, use the reporter command in global configuration mode.
This command has the following syntax:
reporter reporter_name
The reporter_name variable specifies the name of the reporter you are creating.
Enter an unquoted text string with no spaces from 1 to 31 characters.
Cisco Content Services Switch Redundancy Configuration Guide
1-38
OL-5651-02
Chapter 1
To remove an existing reporter and all of its attributes from the running-config,
enter:
(config-reporter[r1])# no reporter r1
Note
If you associate more than one reporter with the same VR, we recommend that
you do not configure the same physical interfaces (ports) on two different reporter
types (for example, ports 1/1 and 1/2 on a reporter of type critical-phy-all-up and
ports 1/1 and 1/2 on a reporter of type critical-phy-any-up). Otherwise,
unexpected VR failovers may occur.
The reporter_type variable has one of the following values:
You can change the critical phy reporter type without suspending the reporter.
However, if you want to reconfigure a critical phy reporter as a VRID peering
reporter, you must first suspend the reporter to remove the critical phy reporter
attributes. See the Suspending a Reporter section.Then you can configure the
reporter as a VRID peering reporter and activate it. For details about VRID
peering, see the Configuring VRID Peering section.
1-39
Chapter 1
Reporter Type
Interface State
Reporter State
critical-phy-all-up
All Up
Up
Up
critical-phy-all-up
All Down
Down
Down
critical-phy-all-up
Down
critical-phy-any-up All Up
Up
Up
Down
Down
Up
Up
Note
2.
Remove the critical phy reporter attributes using the no phy interface_name
command. See the Configuring the Physical Interfaces That You Want to
Monitor section.
3.
Remove the critical phy reporter type using the no type command or
reconfigure the reporter type as a VRID peering type using the type
vrid-peering command. For details about configuring VRID peering, see the
Configuring VRID Peering section.
1-40
OL-5651-02
Chapter 1
4.
If you reconfigured the reporter type as a VRID peering type, add the VRIDs
using the vrid ip_address vrid command, and then activate the reporter using
the active command. See the Configuring the Virtual Routers That You Want
to Monitor section and the Activating a Reporter section.
Note
If you associate more than one reporter with the same VR, we recommend that
you do not configure the same physical interfaces (ports) on two different reporter
types (for example, ports 1/1 and 1/2 on a reporter of type critical-phy-all-up and
ports 1/1 and 1/2 on a reporter of type critical-phy-any-up). Otherwise,
unexpected VR failovers may occur.
This command has the following syntax:
phy interface_name
The interface_name variable is the name of the physical interface that you want
to monitor. Enter an interface name in interface port format (for example, e1 on a
CSS 11501) or slot/port format (for example, 1/1 on a CSS 11503 and
CSS 11506). See the following configuration examples.
To configure Ethernet port 1 on a CSS 11501, enter:
(config-reporter[r1])# phy e1
Note
You cannot remove the last remaining physical interface from an active reporter.
To remove the interface, first suspend the reporter, and then remove the interface.
1-41
Chapter 1
To remove Ethernet port 1 from the list of interfaces to monitor on a CSS 11501,
enter:
(config-reporter[r1])# no phy e1
To remove Ethernet port 1 from the list of interfaces to monitor on a CSS 11503
or 11506, enter:
(config-reporter[r1])# no phy 1/1
Activating a Reporter
Before a CSS can use a reporter to monitor the health of the configured critical
interfaces, you must activate the reporter using the active command. A reporter
remains in a suspended state until you activate it.
For example, enter:
(config-reporter[r1])# active
Suspending a Reporter
You can suspend an active reporter to temporarily stop using the reporter or to
change the reporter configuration. To suspend the reporter, enter the suspend
command in reporter configuration mode. When you are ready to resume using
the reporter again, reactivate the reporter using the active command. See the
Activating a Reporter section.
For example, enter:
(config-reporter[r1])# suspend
Note
1-42
OL-5651-02
Chapter 1
Note
If you associate more than one reporter with the same VR, we recommend that
you do not configure the same physical interfaces (ports) on two different reporter
types (for example, ports 1/1 and 1/2 on a reporter of type critical-phy-all-up and
ports 1/1 and 1/2 on a reporter of type critical-phy-any-up). Otherwise,
unexpected VR failovers may occur.
The syntax of this command is:
ip critical-reporter vrid reporter_name
The variables for this command are:
vrid - The virtual router identifier (VRID) of an existing VR. Enter an integer
between 1 and 255. Virtual routers are considered peers when they have the
same VRID and reside in the same VLAN.
Complete - On CSSs that have an identical chassis (the same CSS model),
produces a running-config on the remote CSS that mirrors the running-config
on the local CSS.
1-43
Chapter 1
CSS and that interface does not exist on the remote CSS or is of a
different interface type (Gigabit Ethernet or Fast Ethernet), the script
exits and the synchronization does not complete.
If you configure one or more VRID IP addresses on a reporter on the
local CSS for VRID peering, the script preserves any configured VRID
IP addresses on the remote CSS. If the remote CSS configuration does
not contain a VRID IP address that corresponds with one in the local CSS
configuration, the remote CSS lacks that VRID IP address when the
script finishes. The script does copy the reporter configuration from the
local CSS to the remote CSS. The script exits with the File copy Vipr
Config Sync Complete message and indicates that any byte differences
between the local and remote configurations exist because the script did
not find a corresponding VRID IP address on the remote CSS.
1-44
OL-5651-02
Chapter 1
Script Functions
The configuration synchronization script performs all the necessary steps to
update the backup CSS with the master's running configuration. The script:
The script performs some verifications before executing the above steps. It checks
to see if the local switch is a backup for any VRIDs and asks you if you want to
continue, thereby changing the state on the two CSSs. The script also checks the
backup to see if it is the master for any VRIDs. If the state is Interface (IF) Down,
the script asks you if you want to continue without synchronizing those VRIDs on
interfaces that are Down.
1-45
Chapter 1
Any configuration where some independent VIP addresses are a master while
other VIP addresses are a backup
Note
You can also run the configuration synchronization script using the predefined
alias that comes with all CSSs by entering:
# commit_VipRedundConfig arguments
You can specify the script arguments in any order. The arguments for the
commit_vip_redundancy script are:
ip address - The IP addresses of the master and backup APP sessions. This is
the only required argument for this script. Use the following syntax when
entering the addresses:
local master IP address remote backup IP address
For details on automating the entry of the IP address, see Setting the
LOCAL_VIPR_IP and REMOTE_VIPR_IP Variables later in this section.
1-46
OL-5651-02
Chapter 1
Note
Caution
Before you use the -f argument to remove a config sync lock file, ensure that no
one else is running the config sync script on the CSS. Otherwise, if you remove
the lock file and then run the script again while the script is in use, the resulting
configurations may have some discrepancies.
-f - After an abnormal script termination, removes the lock file so that you can
run the script again. This argument overrides all other specified arguments
and the script exits immediately after removing the lock file. For details on
the lock file, see Setting the LOCAL_VIPR_IP and REMOTE_VIPR_IP
Variables later in this section.
-nv (No Verify) - Informs the script not to verify that the configuration
synchronization was successful. However, the script does inform you if the
script fails.
Note
-s (Silent) - Suppresses script progress messages and displays only the result
of running the script: Commit Successful or Commit Failed. The -d argument
overrides the -s argument.
For example, on the master CSS, run the following script, which uses the defaults
of verify on and partial synchronization, plus the IP addresses set as variables and
the script alias name:
# commit_VipRedundConfig
1-47
Chapter 1
For more information about scripts, refer to the Cisco Content Services Switch
Administration Guide.
If the script terminates abnormally, the software does not remove the lock file.
The next time you run the script, the above message appears. If you are certain
that the script is not in use by another session, use the -f argument to remove the
lock file.
When you run the script with the -f argument, the following message appears and
the script exits:
VIPR Config Sync lock file removed.
1-48
OL-5651-02
Chapter 1
be available after you log in to the CSS. Set the LOCAL_VIPR_IP variable to the
IP address of the master CSS and set the REMOTE_VIPR_IP variable to the IP
address of the backup CSS.
To set the variables, enter:
# set LOCAL_VIPR_IP master_ip_address session
# set REMOTE_VIPR_IP backup_ip_address session
Now you can run the configuration synchronization script without typing an
IP address.
Note
Note
Log messages are generated with or without the -s (silent) argument specified. See
the Running the Configuration Synchronization Script section.
For example, if the APP session to the backup CSS is not running, the CSS
generates the following log message:
vipr config sync: app session is DOWN
For ease of tracking, each log message contains the string vipr config sync.
1-49
Chapter 1
Displaying VIP and Virtual Interface Redundancy Configurations
1-50
OL-5651-02
Chapter 1
Table 1-8
Field
Description
Interface Address
VRID
State
Master IP
State Changes
Last Change
DNS Server
DNS Packets
Processed
1-51
Chapter 1
Displaying VIP and Virtual Interface Redundancy Configurations
Table 1-9 describes the fields in the show redundant-vips command output.
Table 1-9
Field
Description
Interface Address
VRID
Redundant Address
Range
1-52
OL-5651-02
Chapter 1
Table 1-9
Field
Description
State
Master IP
State Changes
Last Change
1-53
Chapter 1
Displaying VIP and Virtual Interface Redundancy Configurations
Table 1-10 describes the fields in the show virtual-routers command output.
Table 1-10 Field Descriptions for the show virtual-routers Command
Field
Description
Interface Address
VRID
Priority
Config. Priority
State
Master IP
State Changes
Last Change
Preempt
1-54
OL-5651-02
Chapter 1
Field
Description
Critical-Services
State
Type
Critical-Reporters
1-55
Chapter 1
Displaying VIP and Virtual Interface Redundancy Configurations
Field
Description
State
Type
all - Zeroes the State Changes counter of all VRs configured on the CSS
all - Zeroes the State Changes counter of all VRs on the specified circuit
vrid number - Zeroes the State Changes counter of the specified VR on the
specified circuit
For example, to reset the State Changes counter for all VRs configured on the
circuit with an IP address of 192.168.1.7, enter:
(config)# zero virtual-router state-changes circuit 192.168.1.7 all
1-56
OL-5651-02
Chapter 1
Table 1-11 describes the fields for the show critical-services command output.
Table 1-11
Field
Description
Interface Address
VRID
Service Name
1-57
Chapter 1
Displaying VIP and Virtual Interface Redundancy Configurations
Table 1-11
Field
Description
Service Type
Service State
1-58
OL-5651-02
Chapter 1
1-59
Chapter 1
Displaying VIP and Virtual Interface Redundancy Configurations
Table 1-12 describes the fields for the show reporter command output.
Table 1-12 Field Descriptions for the show reporter Command
Field
Description
Name
State
Type
State Transitions
1-60
OL-5651-02
Chapter 1
all - Zeroes the State Transitions counter of all reporters configured on the
CSS
For example, to reset the State Transitions counter for reporter r1, enter:
(config)# zero reporter state-transitions reporter r1
vrid - Specifies the VRID of the VR associated with the critical reporter
Cisco Content Services Switch Redundancy Configuration Guide
OL-5651-02
1-61
Chapter 1
Displaying VIP and Virtual Interface Redundancy Configurations
Table 1-13 describes the fields for the show critical-reporters command output.
Table 1-13 Field Descriptions for the show critical-reporters Command
Field
Description
Interface Address
VRID
Reporter Name
Reporter Type
State
1-62
OL-5651-02
C H A P T E R
2-1
Chapter 2
Users do not experience long network delays or black holes due to a single
point of failure.
The following sections provide information about when (and when not) to use the
different types of redundancy.
When you have a common subnet between the two CSSs on which the VIPs
reside
2-2
OL-5651-02
Chapter 2
Instead of VIP redundancy on the client side of the CSS when the VIPs are
on a subnet different from the subnet of your uplinks
After you have first configured active-backup VIP and virtual interface
redundancy
Expect the behavior of the CSSs to be active/standby (only the master CSS
processes flows)
Can configure a dedicated Fast Ethernet (FE) link between the CSSs for the
VRRP heartbeat
2-3
Chapter 2
Set up using content rules, services, and source groups that you specify as
redundant
Note
For implicit or explicit Layer 5 rules, where there is delayed binding, binding is
not complete until the CSS processes the SYN/ACK from the server. If a failover
occurs in the middle of a spanned content request, the master CSS will not receive
the SYN/ACK from the server and the flow will not be replicated on the backup
CSS. No data is lost and users can simply refresh their browsers to restart the
connection.
Note
During an FTP failover, the control channel and/or the data channel need to share
information with the backup CSS. If the current state information has not been
fully transferred across the ISC link to the backup CSS, then the flow may be lost.
2-4
OL-5651-02
Chapter 2
Stateful Failover
Inter-Switch Communications
Redundant Indexes
Stateful Failover
Active flows that match a redundant content rule, service, or source group on the
master CSS are replicated as dormant flows on the backup CSS peer. A dormant
flow contains all the flow-state information necessary for the backup CSS to take
over the flow if the master CSS fails, including the flow ID assigned by the
session processor (SP) that created the flow. If the master CSS fails, the dormant
flows on the backup CSS become active when the backup CSS assumes
mastership of the VIP. In turn, the active flows on the former master CSS
transition to a dormant state to fully back up the active flows on the new master
CSS.
A master CSS maps a newly activated TCP flow after it receives the first packet
for the flow. If it can resolve a single route back to the source address, a CSS
attempts to map a UDP flow when it activates the flow. Otherwise, the CSS maps
the UDP flow after it receives the first packet of the flow.
2-5
Chapter 2
Inter-Switch Communications
In an ASR configuration, CSS peers share redundant flow-state information over
a maximum of two private Inter-Switch Communications (ISC) links after
booting. ISC is a messaging service used by CSSs to exchange flow-state
information. Only one ISC link is active at a time. The other ISC link (if
configured) remains in backup mode until needed.
To prevent incorrect flow and port mapping information from being replicated to
the backup CSS, a CSS does not activate its ISC link if it detects a mismatched
chassis configuration with the other CSS. During its discovery phase and before
activating the link, the ISC protocol exchanges chassis information between the
two CSSs to ensure that:
The two chassis have the same number of modules session processors (SPs)
with the same weights. SCMs have a weight of 4; all other CSS modules have
a weight of 6. To display the weights of the modules in your CSS, enter the
show chassis session-processors command.
The modules (SPs) are installed in the same order. Skipping slots is permitted
provided that the overall order is the same and the CSS can match up all the
SPs in both chassis.
For example, Figure 2-1 shows two CSS 11506s with slightly different module
installation configurations. Each CSS 11506 has four installed modules, but the
CSS-B configuration skips slot 3. As far as ISC is concerned, the configurations
match because both CSSs have the same number of SPs with the same weights
and installed in the same overall order.
Example of CSS 11506 Matching Module Configurations for ISC
CSS-A
CSS-B
119623
Figure 2-1
2-6
OL-5651-02
Chapter 2
To determine if an ISC link is up, a CSS uses a mechanism called LifeTick. LifeTick
sends an asynchronous message that contains information about the selected path. If
the CSS does not receive a LifeTick message within two seconds, the CSS considers
the ISC link to be down. If a second link is configured, the CSS uses that link for ISC.
Note
For best results, we recommend that you use the Gigabit Ethernet (GE) ports for
the ISC links in all cases. If you are using a CSS 11501, use the GE port for ISC
and the Fast Ethernet (FE) ports for normal traffic.
The ISC links use the GE ports or the FE ports on the CSS session processors
(SPs) to send ISC messages containing flow-state information. Once you
configure the ISC ports, those ports are dedicated to ISC and you cannot use those
same ports for non-ISC traffic.
Note
You must connect the ISC ports directly to the two CSSs. You cannot use Layer 2
devices on the ISC links between the two CSSs. Also, the ISC links must be
dedicated to passing only ISC traffic.
For new flows, CSSs exchange flow states in real time over the ISC links. For
existing flows, CSSs exchange flow states at bootup and at VIP redundancy
failover.
Redundant Indexes
ASR uses unique global redundant indexes to keep track of content rules, services,
and source groups configured on the redundant CSS peers. Set up the redundant
indexes in rules, services, and groups using the redundant-index command. You
must then configure identical redundant content rules, services, and source groups
on CSS peers in the ASR configuration.
Each redundant index that you configure on a rule, service, or group must be
unique among all rules, services, or groups configured on a redundant pair of
CSSs. For example, if you configure a rule with a redundant index of 1 on a pair
of CSSs, you cannot configure an index of 1 on another rule. However, you could
configure an index of 1 on a group or service if that value has not already been
used on a group or a service.
2-7
Chapter 2
Note
Ensure that both CSSs have the same number of SPs. Otherwise, the CSSs
cannot activate the ISC link.
You cannot configure ASR and an SSL module on the same service. ASR
does not support the replication of flows to an SSL module in the CSS.
Configure VIP and virtual interface redundancy on both CSS peers. For
details, refer to Chapter 1, Configuring VIP and Virtual Interface
Redundancy.
Ensure that VIP ranges specified in redundant content rules and source
groups are the same as the VIPs associated with virtual routers for VIP
redundancy. If the redundant content rule or source group VIPs are a superset,
ASR is supported only for the VIPs that are associated with the virtual
routers. For the remaining VIPs, the behavior is undefined when a failover
occurs, because it is unclear whether those VIPs are mastered on the new
master CSS or not.
2-8
OL-5651-02
Chapter 2
Configure ISC on both CSSs. This allows the CSSs to share flow-state
information.
Configure a maximum of two ISC ports on a CSS. Multiple ports must reside
on the same module in the CSS 11503 or CSS 11506 or on the same
CSS 11501. Also, the ports must be of the same type (Gigabit Ethernet or Fast
Ethernet) in both CSSs. For best results, we recommend that you use GE ports
for the ISC links in all cases.
Ensure that the ISC ports are not configured in any VLANs. If necessary,
remove the designated ports from all VLANs before configuring ISC. For
details on disabling an interface port from a VLAN, refer to the Content
Services Switch Routing and Bridging Configuration Guide.
You must connect the ISC ports directly to the two CSSs. You cannot use
Layer 2 devices on the ISC links between the two CSSs. Also, the ISC links
must be dedicated to passing only ISC traffic.
If you configure any ISC ports on an SCM, you can have only one SCM
installed in the CSS 11506.
The CSS 11501 does not support redundant GE ISC links for ASR because
the CSS includes only a single GBIC port.
When you configure critical services, be sure to change the default keepalive
settings to the following recommended settings for ASR. For example, enter:
service CriticalService
ip address 192.168.2.1
keepalive frequency 2
keepalive maxfailure 2
keepalive retryperiod 2
active
2-9
Chapter 2
Note
Configure as redundant any source groups that you specify in ACL clauses.
Otherwise, ASR does not require source groups. It is helpful to configure
ACLs similarly on the master and backup CSSs. This ensures that the CSSs
share the port-map state during flow setup time, and, at failover time, a CSS
finds the same ACL and source group configured on the peer. Otherwise,
when a flow fails over to the backup, it is possible that the flow may match
on a different ACL clause that has no source group configured or a different
source group (possibly a nonredundant one).
Source groups selected by ACL-checking always take precedence over other
source group matches for a flow. Therefore, if the master and backup CSSs
have different ACL definitions, when a flow fails over to the backup and the
source group selected on the master is not found on the backup, the CSS
rejects the flow. Also, if the flow matches on a different source group through
an ACL, that source group takes precedence over the redundant source group
that was sent from the master.
2-10
OL-5651-02
Chapter 2
Do not configure ASR and stateless redundancy failover on the same CSS.
Such a configuration is not supported. For details on stateless redundancy
failover, refer to Chapter 3, Configuring Box-to-Box Redundancy, in the
Configuring Stateless Redundancy Failover section.
ASR does not support NAT peering. For details on NAT Peering, refer to the
Content Services Switch Content Load-Balancing Configuration Guide.
If your CSSs have mismatched chassis configurations, ASR does not work
after the upgrade
If your CSSs meet the ASR requirement of having the same number of SPs in
each chassis, you must upgrade both CSSs to WebNS Version 7.40
During the upgrade process, ASR does not work and you lose any sessions
that are in progress
2-11
Chapter 2
Table 2-1
2.
3.
4.
Configure services that are targets of redundant content rules. For more
information on services, refer to the Cisco Content Services Switch Content
Load-Balancing Configuration Guide.
(config)# service server1
(config-service[server1])# ip address 192.168.100.100
(config-service[server1])# redundant-index 1
(config-service[server1])# active
5.
Configure redundant content rules and add the redundant services. For more
information on content rules, refer to the Cisco Content Services Switch
Content Load-Balancing Configuration Guide.
(config)# owner arrowpoint
(config-owner[arrowpoint])# content rule1
(config-owner-content[arrowpoint-rule1]# vip address 192.1.1.100
(config-owner-content[arrowpoint-rule1]# protocol tcp
(config-owner-content[arrowpoint-rule1]# port 80
(config-owner-content[arrowpoint-rule1]# url /redundant.html
(config-owner-content[arrowpoint-rule1]# add service server1
(config-owner-content[arrowpoint-rule1]# redundant-index 5
(config-owner-content[arrowpoint-rule1]# active
2-12
OL-5651-02
Chapter 2
Table 2-1
Configure redundant source groups and add the redundant services. For
more information on source groups, refer to the Cisco Content Services
Switch Content Load-Balancing Configuration Guide.
(config)# group group1
(config-group[group1])#
(config-group[group1])#
(config-group[group1])#
(config-group[group1])#
7.
8.
Configure the same redundant services, content rules, and source groups on
the other CSS peer (synchronize the configurations).
9.
2-13
Chapter 2
interface 1/2
isc-port-two
interface 2/1
bridge vlan 2
!************************** CIRCUIT **************************
circuit VLAN1
ip address 10.1.1.1 255.255.255.0
ip virtual-router 1 priority 101 preempt
ip redundant-interface 1 10.1.1.254
ip critical-service 1 upstream_downstream
circuit VLAN2
ip address 192.1.1.1 255.255.255.0
ip virtual-router 2 priority 101 preempt
ip redundant-vip 2 192.1.1.100
ip critical-service 2 upstream_downstream
!************************** SERVICE **************************
service server1
ip address 10.1.1.50
redundant-index 1
active
service upstream_downstream
ip address 192.1.1.50
keepalive type script ap-kal-pinglist 192.1.1.20 10.1.1.20"
keepalive frequency 2
keepalive maxfailure 2
keepalive retryperiod 2
active
!*************************** OWNER ***************************
owner arrowpoint
content rule1
vip address 192.1.1.100
protocol tcp
port 80
url /redundant.html
add service server1
redundant-index 5
active
2-14
OL-5651-02
Chapter 2
For new flows in real time (after the CSS receives a SYN/ACK from the
server)
To prevent incorrect flow and port mapping information from being replicated to
the backup CSS, the CSS does not bring up the ISC link if it detects a mismatched
chassis configuration with the other CSS. During the discovery phase, the ISC
protocol exchanges chassis information between the two CSSs and ensures that
both chassis have the same number of SPs before bringing up the link.
To enable ISC between two CSSs in an ASR configuration, use the isc-port-one
and isc-port-two commands in interface configuration mode. You can configure
a maximum of two ISC ports on each CSS. The two ports must be of the same type
(Gigabit Ethernet or Fast Ethernet) and must be on the same module in the CSS
11503 or CSS 11506 or on the same CSS 11501. When you configure two ISC
ports, the first port is active and the second port remains in a backup state. The
backup link is used only if the active link fails. For best results, we recommend
that you configure ISC on the GE ports.
The CSS 11501 does not support redundant GE ISC links for ASR because that
CSS model includes only one GE port.
You must connect the ISC ports directly to the two CSSs. You cannot use Layer
2 devices on the ISC links between the two CSSs. Also, the ISC links must be
dedicated to passing only ISC traffic.
2-15
Chapter 2
Note
2-16
OL-5651-02
Chapter 2
For more information on configuring services, refer to the Cisco Content Services
Switch Content Load-Balancing Configuration Guide.
Note
2-17
Chapter 2
Note
2-18
OL-5651-02
Chapter 2
ISC
Redundant services
Dormant flows
2-19
Chapter 2
Field
Description
Inter-Switch
Communications
Configuration
Inter-Switch
Communications
Status
Port # Communication Indicates why the ISC link failed. Use this field to help
Failure Reason
you troubleshoot the ISC link if it fails. Possible
reasons are:
2-20
OL-5651-02
Chapter 2
Table 2-3 describes the fields in the show dormant flows output.
Table 2-3
Field
Description
Src Address
SPort
Dst Address
DPort
Prt In
OutPort
To display summary information about redundant dormant flows, use the flow
statistics dormant command.
2-21
Chapter 2
Table 2-4 describes the field in the flow statistics dormant output.
Table 2-4
Field
Description
Redundant Flow
Statistics - Slot n,
Subslot n
Dormant Flow
Count
UDP Flows
TCP Flows
Redundant Flow
Statistics - Aggregate
Total Flows
2-22
OL-5651-02
Chapter 2
show rule
show service
show group
Session Redundancy - The state of ASR for the content rule, service, or
source group. Possible values are: Enabled or Disabled
Redundancy Global Index - The unique global index value for ASR
configured for the content rule, service, or source group using the
redundant-index command.
For complete details on the show rule, show service, and show group
commands, refer to the Cisco Content Services Switch Content Load-Balancing
Configuration Guide.
2-23
Chapter 2
all - Displays summary ASR information for content rules, services, and
source groups.
For example, to view summary ASR information for redundant content rules,
enter:
(config)# show session-redundant rule
Field
Description
Content Rule
Content Rule
State
VIP Address
Redundancy
Global Index
Redundancy State The state of the CSS peer: Master, Backup, or Suspend.
Rule Redundant
Services 1
Service
Service State
IP Address
Redundancy
Global Index
2-24
OL-5651-02
Chapter 2
Table 2-5
Field
Description
Source Group
Source Group
State
VIP Address
Redundancy
Global Index
Source
Services
Destination
Services
2-25
Chapter 2
2-26
OL-5651-02
C H A P T E R
Configuring Redundancy
3-1
Chapter 3
Users do not experience long network delays or black holes due to a single
point of failure.
The following sections provide information about when (and when not) to use the
different types of redundancy.
When you have a common subnet between the two CSSs on which the VIPs
reside
3-2
OL-5651-02
Chapter 3
Instead of VIP redundancy on the client side of the CSS when the VIPs are
on a subnet different from the subnet of your uplinks
After you have first configured active-backup VIP and virtual interface
redundancy
Expect the behavior of the CSSs to be active/standby (only the master CSS
processes flows)
Can configure a dedicated Fast Ethernet (FE) link between the CSSs for the
VRRP heartbeat
OL-5651-02
3-3
Chapter 3
Caution
When you use access control lists (ACLs) in a redundant configuration, ensure
that you permit all traffic on the redundant circuit between the master and backup
CSSs. For information on ACLs, refer to the Cisco Content Services Switch
Security Configuration Guide.
3-4
OL-5651-02
Chapter 3
VLAN3 - 192.168.10.x
CSS1 e2 to e7
CSS2 e2 to e7
Hub1
Server1, Server2
Server1
192.168.10.30
Server2
192.168.10.31
Hub1
CSS1 (master)
VLAN3 - 192.168.10.1
VLAN2
CSS2 (backup)
VLAN3 - 192.168.10.1
172.7.6.2 e1
172.7.6.1 e1
Router1
192.168.20.100
VLAN1 - 192.168.20.x
CSS1 e8 to e12
CSS2 e8 to e12
Hub2
Router1, Router2
Redundant link
Hub2
VLAN1 - 192.168.20.1
VIP 192.168.20.254
Router2
192.168.20.101
Second default
gateway
Internet
49641
VLAN1 - 192.168.20.1
VIP 192.168.20.254
3-5
Chapter 3
Caution
Install only one crossover cable on the master and redundant CSS before you
power them on.
If you power on the CSSs before you install the cable, both units boot up as the
master CSS and cause network problems. Do not remove the crossover cable from
a redundant configuration or each CSS will become master
Note
You must connect only one crossover cable directly to the Gigabit
Ethernet (GE) ports (software version 7.10.1.02 and greater) or the
Fast Ethernet (FE) ports on the redundant CSSs. Do not use Layer 2
devices between the two CSSs on the redundant link.
2.
3.
4.
FTP the startup-config to a PC. Edit the file by including the backup CSS
circuit VLAN IP addresses.
5.
FTP the startup-config to the backup CSS. Reboot the backup CSS with the
new startup-config.
As an alternative method, you can use CLI commands to manually configure the
backup CSS with all necessary configurations including the redundancy protocol.
3-6
OL-5651-02
Chapter 3
Note
If you make configuration changes to the master CSS startup-config, you must
make the same changes to the backup CSS startup-config. To learn how to
synchronize the running-configs of the master CSS and the backup CSS, see
Synchronizing a Redundant Configuration later in this chapter.
Table 3-1
Install the crossover cable before you power up the CSSs. Make the
CSS-to-CSS connection using a Category 5 crossover cable. This table uses
port 1/1 on the master CSS and port 1/1 on the backup CSS as examples.
2.
3.
4.
5.
6.
Enter circuit mode for the redundant VLAN. For information on configuring
circuits, refer to the Cisco Content Services Switch Routing and Bridging
Configuration Guide.
(config-if[e1])# circuit VLAN2
(config-circuit[VLAN2])#
7.
3-7
Chapter 3
Table 3-1
9.
10. From SuperUser mode, save the master CSS running-config to the
startup-config.
# copy running-config startup-config
circuit VLAN IP address for the redundant connection (in Figure 3-1, circuit
VLAN2, IP address 172.7.6.2/24). Do not change the backup CSS VIP. The
master and backup CSS must have the same VIP. If you have multiple VIPs,
you must configure them on both the master and backup CSSs.
13. FTP the new file to the backup CSS and, if necessary, rename it
startup-config.
14. Reboot the backup CSS.
15. Enter the show redundancy command to display the redundancy
3-8
OL-5651-02
Chapter 3
interface 2/1
bridge vlan 3
!************************** CIRCUIT **************************
circuit VLAN1
redundancy
ip address 172.27.16.23 255.255.255.0
circuit VLAN2
ip address 172.7.6.1 255.255.255.0
redundancy-protocol
circuit VLAN3
redundancy
Caution
If you power on the CSSs before you install the cable, both CSSs boot up as the
master CSS and cause network problems. Do not remove the crossover cable from
a redundant configuration or each CSS will become master.
Note
You must connect the crossover cable directly to the Gigabit Ethernet (GE) ports
(software version 7.10.1.02 and greater) or the Fast Ethernet (FE) ports before
you power on the redundant CSSs. Do not use Layer 2 devices between the two
CSSs on the redundant link.
3-9
Chapter 3
Configuring Redundancy
Table 3-2 lists the pinouts for the CSS Fast Ethernet connectors and the crossover
pinouts.
Table 3-2
Signal Name
Pin Number
Crossover Cable
Pinouts
RX +
RX -
TX +
Unconnected
Unconnected
TX -
Unconnected
Unconnected
Configuring Redundancy
Configuring the redundancy protocol requires you to:
Note
Configure the master and backup CSSs for redundancy using the
ip redundancy command.
Enable the redundancy protocol on the master and backup circuit VLAN
using the redundancy-protocol command.
Enable the circuit VLAN for redundancy using the redundancy command.
The CSS does not support IP redundancy and VIP redundancy simultaneously.
For information on VIP redundancy, refer to Chapter 1, Configuring VIP and
Virtual Interface Redundancy.
3-10
OL-5651-02
Chapter 3
Configuring IP Redundancy
Use the ip redundancy command to enable CSS-to-CSS redundancy on two CSSs
interfaced with a crossover cable. By default, redundancy is disabled on CSSs
until you issue this command on both CSSs.
When you include the master option with this command, you can designate which
CSS is the master CSS. Initially, booting two CSSs interfaced with a crossover
cable determines which is the master and which is the backup. The CSS that boots
first is the master CSS. If the CSSs boot at the same time, the CSS with the
numerically higher IP address becomes the master.
Note
You cannot use the ip redundancy master command with either the type
redundancy-up command (redundancy uplink service) or the redundancy-phy
command (physical link redundancy). If necessary, disable the appropriate
command using no type redundancy-up or no redundancy-phy before using the
ip redundancy master command.
When you issue the ip redundancy master command on a CSS, it becomes the
master CSS. You can issue this command on either the current master or backup.
If you issue this option on the backup CSS, it becomes the master and the other
CSS becomes the backup automatically.
If you designate a master CSS, it regains its master status after it goes down and
then comes up again. For example, when the master CSS goes down, the backup
CSS becomes master. However, when the former designated master CSS comes
up again, it becomes the master again.
If you have no requirement to designate a CSS as the master when both CSSs are
up, do not include the master option when enabling redundancy on the master
CSS. In this configuration, if the master CSS goes down, the backup CSS
becomes master. When the former master CSS comes up again, it becomes the
backup CSS.
The syntax for this global configuration mode command is:
3-11
Chapter 3
Configuring Redundancy
issue this command on the backup CSS, it becomes the master and the
other CSS becomes the backup CSS automatically.
When CSS-to-CSS redundancy is currently enabled.
For example:
(config)# ip redundancy
Caution
You cannot issue the ip redundancy master command on both the master and
backup CSSs. This can cause severe network problems. Before you disable
redundancy, ensure that you disconnect or disable all redundant circuits to prevent
duplicate IP addresses from occurring on the network.
To disable CSS-to-CSS redundancy, enter:
(config)# no ip redundancy
Note
Note
3-12
OL-5651-02
Chapter 3
Note
The redundancy command causes the specified VLAN to become silent when in
backup mode.
When you configure redundancy, configure it on circuits (VLANs) that contain
network IP addresses shared by the redundant CSSs (in Figure 3-1, these are
VLAN1 and VLAN3). Do not configure redundancy on the circuit (VLAN)
configured specifically for redundancy communications (in Figure 3-1, this is
VLAN2).
The example below configures VLAN1 as a redundant circuit, which contains a
shared network IP address (in Figure 3-1, this is 192.168.20.1).
For example:
(config-circuit[VLAN1])# redundancy
Note
3-13
Chapter 3
Configuring Redundancy
Note
3-14
OL-5651-02
Chapter 3
Complete - On CSSs that have an identical chassis (the same CSS model),
produces a running-config on the backup CSS that exactly matches the
running-config on the master CSS.
3-15
Chapter 3
For more information about the restrict user-database command, refer to the
Cisco Content Services Switch Security Configuration Guide. For more
information about configuring administrators (username_offdm command) and
technicians (username_technician command), refer to the Cisco Content
Services Switch Command Reference.
Caution
ip address - The IP address of the backup CSS. This is the only required
argument for this script. For details on automating the entry of the IP address,
see Setting the REMOTE_IP Variable later in this section.
Before you use the -f argument to remove a config sync lock file, ensure that no
one else is running the config sync script on the CSS. Otherwise, if you remove
the lock file and then run the script again while the script is in use, the resulting
configurations may have some discrepancies.
3-16
OL-5651-02
Chapter 3
-f - After an abnormal script termination, removes the lock file so that you
can run the script again. This argument overrides all other specified
arguments and the script exits immediately after removing the lock file. For
details on the lock file, see Setting the REMOTE_IP Variable later in this
section.
-int (Interface) - Does not clear the interfaces on the backup CSS so that the
link does not go down. Do not use this argument with the -a argument. If you
do and the interface settings are different on the master and the backup CSSs,
the configurations will not match and the script will not finish successfully.
-nv (No Verify) - Informs the script not to verify that the configuration
synchronization was successful. The script does inform you if the script fails.
Note
-s (Silent) - Suppresses script progress messages and displays only the result
of running the script: Config Sync Successful or Config Sync Failed.
Note
Note
3-17
Chapter 3
Displays the current task being performed as the script progresses (-d)
3-18
OL-5651-02
Chapter 3
For more information on scripts, refer to the Cisco Content Services Switch
Administration Guide.
If the script terminates abnormally, the software does not remove the lock file.
The next time you run the script, the above message appears. If you are certain
that the script is not in use by another session, then you can use the -f argument
to remove the lock file.
When you run the script with the -f argument, the following message appears and
the script exits:
Config Sync lock file removed.
If you already created the BACKUP_IP variable in an earlier release, the script
will use the new variable instead, if present.
Cisco Content Services Switch Redundancy Configuration Guide
OL-5651-02
3-19
Chapter 3
Note
Log messages are generated with or without the -s (silent) argument specified. See
Running the Configuration Synchronization Script earlier in this chapter.
For example, if the APP session to the backup CSS is not running, the following
log message will be generated:
config sync: app session is DOWN
For ease of tracking, each log message contains the string config sync.
You manually make the other CSS the master, using either the redundancy
force-master command or the ip redundancy master command.
3-20
OL-5651-02
Chapter 3
Note
If you explicitly designated the master CSS using the ip redundancy master
command, you cannot use the redundancy force-master command on the backup
CSS. In this case, you must unassign the master CSS by issuing the no ip
redundancy master command before you can use the redundancy force-master
command on the backup CSS.
Note
3-21
Chapter 3
Figure 3-2
Internet
Router1
Router2
Hub1
CSS1
(master)
Redundant link
CSS2
(backup)
49642
Hub2
Server1
Note
Server2
Server3
Server4
If you explicitly designated the master CSS using the ip redundancy master
command, you cannot use the type redundancy-up command on the CSS. In this
case, you must unassign the master CSS by issuing the no ip redundancy master
command before you can use the type redundancy-up command.
3-22
OL-5651-02
Chapter 3
Use the show redundancy command to display critical services. See the
Displaying Redundant Configurations section.
For example:
CSS1(config)# show redundancy
Note
3-23
Chapter 3
Note
Note
This feature affects only TCP/IP sessions. UDP behaves normally because UDP
is not a a session-oriented protocol.
3-24
OL-5651-02
Chapter 3
Redundancy
Load balancing
Source groups
Services
Keepalives
Convergence
Environmental Considerations
Stateless redundancy failover requires a very specific redundant CSS
configuration, where the state of the CSS can be determined after a failure. This
feature supports redundant routes in the high-availability topology surrounding
the CSSs. However, the topology must not balance packets in a TCP/IP socket
connection across more than one Ethernet port on the CSS.
Routed paths to the load-balanced VIP should be weighted to ensure that a single
path is preferred for the lifetime of a TCP/IP connection.
Note
Stateless redundancy failover does not support network address translation (NAT)
where maintaining state is required nor does it support Layer 5 content rules.
3-25
Chapter 3
Configuration Restrictions
The following configuration restrictions apply to all CSSs, except where noted.
Do not configure a service that changes the destination port on a content rule.
This causes the CSS to NAT (port map) the destination port. If the CSS fails
over, the backup CSS has no knowledge of the original destination port.
Content rules - Create identical content rules on both CSSs with the
following parameters. Refer to the Cisco Content Services Switch Content
Load-Balancing Configuration Guide.
VIP - Assign a virtual IP address to each content rule. No wildcard
addresses are allowed and no VIP ranges on the content rule are allowed.
3-26
OL-5651-02
Chapter 3
CSS.
Note
alphabetical order regardless of the order in which you enter them in the
configuration.
Keepalives - Create keepalives using the global keepalive command,
then associate the services with the keepalives using the keepalive type
named command. Both CSSs must be able to send and receive keepalive
messages with the same servers. This helps to ensure that a redistribution
of the balance method does not occur in a failover event.
Weight - Routed paths to the load-balanced VIP should be weighted to
Source groups - Create a source group with the same VIP as the content rule
VIP on each CSS to NAT source addresses for packets returning from the
server. In case of a failover, the source group will handle the connection setup
for TCP/IP transmissions that arrive at the CSS from the servers. All servers
in the farm must be members of the configured source group. Refer to the
Cisco Content Services Switch Content Load-Balancing Configuration
Guide.
3-27
Chapter 3
Note
Do not configure source groups for outbound traffic from the servers,
because the backup CSS does not know which ports were NATed by
the source group on the master CSS if a failure occurs at the master
CSS. This restriction also applies to active FTP because the server
initiates the data connection.
Note
1.
2.
3.
4.
3-28
OL-5651-02
Chapter 3
Complex topologies surrounding the CSS converge after the CSS has determined
a root bridge and has begun transmission of Address Resolution Protocol (ARP)
and keepalive traffic. If a TCP/IP retransmission from a server arrives at the CSS
before the CSS acquires the server, the CSS sets up the connection properly
through the configured source group path. If a retransmission from a client arrives
at the CSS before all servers have been acquired and the source IP address of the
client indicates a server that is not yet alive, the CSS sets up the connection
according to the failover method configured in the content rule (next or linear).
Configuration Example
The following example configuration (see Figure 3-3) assumes that the:
ip route 0.0.0.0.0.0.0.0.192.168.20.100
ip redundancy
interface e2
bridge vlan 1
description uplink VLAN
interface e5
bridge vlan 1
description uplink VLAN
3-29
Chapter 3
interface e9
bridge vlan 3
description server VLAN
interface e12
bridge vlan 3
description server VLAN
interface e1
bridge vlan 2
description Redundancy Protocol Heartbeat
circuit VLAN1
redundancy
ip address 192.168.20.1 255.255.255.0
circuit VLAN3
redundancy
ip address 192.168.10.1 255.0.0.0
circuit VLAN2
redundancy-protocol
ip address 172.7.6.1 255.255.255.253
service s1
ip address 192.168.10.30
active
service s2
ip address 192.168.10.31
active
owner Redundant-Pool
content web
vip address 192.168.20.254
protocol tcp
port 80
redundancy-l4-stateless
add s1
add s2
balance srcip
active
group Redundant-Pool
vip address 192.168.20.254
redundancy-l4-stateless
add service s1
add service s2
active
3-30
OL-5651-02
Chapter 3
Figure 3-3
Server 1
192.168.10.30
Server 2
192.168.10.31
VLAN 3
Hub 1
Master
192.168.10.1
Backup
192.168.10.1
172.7.6.1
192.168.20.1
VIP address
192.168.20.254
172.7.6.2
VLAN 2
Redundant
link
192.168.20.1
VIP address
192.168.20.254
Hub 2
VLAN 1
Internet
37515
Router
192.168.20.100
3-31
Chapter 3
3-32
OL-5651-02
Chapter 3
Configuration Example
The following example configuration (see Figure 3-4) assumes that the:
CSSs are acting as routers between two external VLANs in a VIP and virtual
interface redundancy configuration.
3-33
Chapter 3
service uplink
ip address 192.168.20.100
type redundancy-up
active
service s1
ip address 192.168.10.30
active
service s2
ip address 192.168.10.31
active
owner Redundant-Pool
content web
vip address 192.168.20.254
protocol tcp
port 80
redundancy-l4-stateless
add s1
add s2
balance srcip
active
group Redundant-Pool
vip address 192.168.20.254
redundancy-l4-stateless
add service s1
add service s2
active
3-34
OL-5651-02
Chapter 3
Figure 3-4
Server 1
192.168.10.30
Server 2
192.168.10.31
VLAN 3
Hub 1
Master
192.168.10.1
Backup
192.168.10.2
VIP
192.168.10.254
192.168.20.1
VIP address
192.168.20.254
192.168.20.2
VIP address
192.168.20.254
Hub 2
VLAN 1
Internet
37516
Router
192.168.20.100
3-35
Chapter 3
Alternative Configurations
Stateless redundancy failover allows other possible configurations and
topologies. To use this feature in other high-availability environments, see the
other sections in this chapter and to Chapter 1, Configuring VIP and Virtual
Interface Redundancy, for details and examples of CSS redundancy
configurations. Refer to RFC-2338 Virtual Router Redundancy Protocol for
additional information.
Other Considerations
The following conditions apply to stateless redundancy failover:
After a failover, passive mode FTP will not continue because the NAT state
of the data channel cannot be preserved. However, port mode FTP will
continue to function.
3-36
OL-5651-02
Chapter 3
At any given time, some TCP/IP connections may be either in a state where
the client is sending data to the server, or the server is sending data to the
client. Packets that arrive while the topology is converging or before some
services are acquired by keepalive traffic may be forwarded incorrectly. For
example, a service may stop responding to keepalive traffic, but continue to
service a long-lived TCP connection. In this case, the backup CSS would not
have knowledge of the state of the long-lived connection, and would guess
incorrectly when attempting to resume the connection.
In a highly critical environment, set goals for connection loss ratio and
convergence time. Then, test various topologies and topology protocol
combinations to verify that the target connection loss ratios and convergence
time goals are reached. This testing should account for all reasonable failure
modes that the high-availability network is designed to withstand. If
warranted by the critical nature of the traffic, you may want to construct a
permanent testbed to validate the system of network components prior to the
deployment of new configurations.
When redundancy is not configured, the CSS displays the following status:
(config)# show redundancy
Redundancy: Disabled Redundancy Protocol: Not Running
The output of the show redundancy command varies depending on whether you
issue the command on the master or the backup CSS.
3-37
Chapter 3
Field
Description
Redundancy
Redundancy
Protocol
Redundancy State
MasterMode
Number of times
redundancy state
changed to
Master/Backup
Redundancy
interface
Current State
Duration
VRID
Priority
The priority for the virtual router with its peer. The
default priority value is 100. Enter an integer between 1
and 255.
Uplink Enabled
3-38
OL-5651-02
Chapter 3
Table 3-3
Field
Description
Number Alive
Service
Name/State
3-39
Chapter 3
3-40
OL-5651-02
INDEX
configuring 3-10
disabling 3-12
Adaptive Session Redundancy
overview 3-1
overview 2-4
audience xiv
box-to-box redundancy
configuration synchronization
OL-5651-02
IN-1
Index
set xv
E
example
configuring 1-38
critical reporter, configuring 1-42
overview 1-35
critical services
F
failover
stateful 2-4
stateless 3-24
documentation
audience xiv
IN-2
OL-5651-02
Index
overview 2-6
restrictions 2-9
IP critical services
displaying 1-50
IP redundancy. See box-to-box redundancy
IP redundant interface
displaying 1-50
protocol
Q
quick start
K
keepalive
IP critical services 1-33
redundant uplink services 3-21
L
LifeTick 2-7
Cisco Content Services Switch Redundancy Configuration Guide
OL-5651-02
IN-3
Index
reporter
redundancy
box-to-box 3-1
router
running-config example
ASR 2-13
session 2-4
S
scripts
commit_redundancy 3-15
configuring 3-13
commit_vip_redundancy 1-46
redundant
IN-4
OL-5651-02
Index
overview 2-4
service, redundant 2-16
source group
VIP redundancy
overview 1-4
overview 3-24
virtual router
uplink services, configuring redundant 3-21
IN-5
Index
IN-6
OL-5651-02