-
CSS Advanced Configuration Guide (Software Version 7.20)
-
Index
-
Preface
-
Configuring the CSS Domain Name Service
-
Configuring the DNS Sticky Feature
-
Configuring a CSS as a Content Routing Agent
-
Configuring a Client Side Accelerator
-
Configuring Network Proximity
-
Configuring VIP and Virtual Interface Redundancy
-
Configuring Adaptive Session Redundancy
-
Configuring Box-to-Box Redundancy
-
Configuring Content Replication
-
Configuring SSL Traffic through the CSS
-
Configuring Firewall Load Balancing
-
Using the CSS Scripting Language
-
Using an XML Document to Configure the CSS
-
Table Of Contents
Configuring VIP and Virtual Interface Redundancy
When to Use VIP and Virtual Interface Redundancy
When to Use Box-to-Box Redundancy
Overview of VIP and Virtual Interface Redundancy
Examples of VIP and Virtual Interface Redundancy Configurations
Active-Backup VIP and Virtual Interface Redundancy with Fate Sharing
Active-Active VIP and Virtual Interface Redundancy
VIP and Virtual Interface Redundancy Quick Start
Configuring VIP and Virtual Interface Redundancy
Configuring a Circuit IP Interface
Configuring a Redundant Virtual Interface
Synchronizing a VIP Redundancy Configuration
Running the Configuration Synchronization Script
Setting the BACKUP_VIPR_IP Variable
Logging Configuration Synchronization Script Result Messages
Displaying VIP and Virtual Interface Redundancy Configurations
Displaying IP Critical Services
Displaying Redundant Virtual Interfaces
Displaying Virtual Router Configurations
Configuring VIP and Virtual Interface Redundancy
This chapter describes how to plan for and configure virtual IP (VIP) redundancy and virtual interface redundancy on the CSS. Information in this chapter applies to all CSS models except where noted.
This chapter provides the following major sections:
•
Overview of VIP and Virtual Interface Redundancy
•
•
•
Overview of CSS Redundancy
Redundancy helps to ensure:
•
•
A CSS provides three types of redundancy.
•
•
•
The following sections provide information about when and when not to use the different types of redundancy.
When to Use VIP and Virtual Interface Redundancy
Typically, you configure VIP redundancy on the public side of CSS peers that are positioned in front of a server farm. You configure virtual interface redundancy on the private-side interfaces attached to the Layer 2 device in front of the servers.
Configure VIP redundancy:
•
•
•
•
Configure interface redundancy:
•
•
•
When to Use ASR
ASR provides session-level redundancy for applications where active flows (including TCP and UDP) must continue without interruption, even if the master CSS fails over to the backup CSS.
Configure ASR:
•
•
When to Use Box-to-Box Redundancy
Configure box-to-box redundancy when you:
•
•
Do not configure box-to-box redundancy when you:
•
•
Overview of VIP and Virtual Interface Redundancy
This section provides information about:
•
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 6-1). If the master CSS becomes unavailable, the backup CSS becomes master and processes all client requests for the VIP.
Note
To set up CSSs for VIP redundancy, you must configure a virtual router on each CSS that will participate in the redundant configuration. A virtual router is an entity within a CSS to which you associate an existing VIP. A VIP becomes redundant when you associate it with a virtual router. You can configure a maximum of 255 virtual routers for each VLAN.
Note
Figure 6-1 Example of VIP and Virtual Interface Redundancy
Virtual routers providing redundancy for a VIP address are considered peers. Each virtual router peer has the same virtual router identifier (VRID) and runs on the same VLAN, but runs on a different CSS. Once the virtual routers are configured, the CSSs negotiate for mastership using Virtual Router Redundancy Protocol (VRRP). A virtual router in a redundant VIP configuration that is designated as:
•
•
–
–
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 6-1.
Virtual Interface Redundancy
Virtual interface redundancy is a form of IP address redundancy that applies only to IP interfaces (not VIPs). A typical interface IP address on a CSS defines the interface in use on a particular VLAN. In a virtual interface redundancy configuration, the CSS designated as master maintains control over the redundant virtual interface. Each CSS will also have its own circuit IP address that you can use for Telnet, SNMP, or the Device Management User Interface software.
The typical use for virtual interface redundancy is with a VIP redundancy configuration in which:
•
•
•
You must configure a virtual router with the same VRID on the two CSSs on the backside subnet that is common to both CSSs. This VRID must be different from the VRID configured for VIP redundancy. Once you associate the new VRID with the virtual redundant interface IP address, the CSSs uses VRRP to negotiate mastership of the virtual redundant interface.
A CSS designated as the master of a virtual interface automatically sends out gratuitous ARPs for the virtual interface's IP address 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 virtual interface from the servers and allows a server's default route to always point to the CSS designated as the master of the virtual interface. 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 6-1.
Note
You can also configure virtual interface redundancy on the uplinks of the CSSs when the VIPs reside on a subnet different from that of the uplinks. In this case, you cannot configure VIP redundancy on the public side of the CSSs. You will need to configure static routes on the upstream routers pointing to the redundant virtual interface on the CSS as the router's next hop gateway to the subnet where the VIPs reside.
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 interface on the private side of the network also fails over from the master to the backup CSS. If you do not configure virtual interface redundancy with VIP redundancy, asymmetric flows may result (Figure 6-2). Asymmetric flows occur when a CSS is master on the public side, but backup on the private side, which will break the connection between the client and the server.
To ensure that the redundant VIP and the redundant virtual interface fail over at the same time, you must bind the front and the back instances of VRRP (the virtual routers) 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.
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 VIP and the virtual interface fail over together to the backup CSS. For details on configuring critical services, see the "Configuring Critical Services" section.
Figure 6-2 Example of Asymmetric Flows Without Fate Sharing
Examples of VIP and Virtual Interface Redundancy Configurations
The following sections provides examples of the most commonly used VIP and virtual interface redundancy configurations.
Active-Backup VIP and Virtual Interface Redundancy with Fate Sharing
Figure 6-3 shows an active-backup VIP and virtual interface redundancy configuration. CSS-1 is configured as the master for VIP address 192.1.1.100 and virtual interface address 10.1.1.254. If CSS-1 fails, CSS-2 (the backup CSS) will assume mastership of all flows destined to VIP address 192.1.1.100 and virtual interface address 10.1.1.254.
Figure 6-3 Example of Active-Backup VIP and Virtual Interface Redundancy
CSS-1 Configuration
circuit VLAN1ip address 10.1.1.1 255.255.255.0ip virtual-router 1 priority 101 preemptip redundant-interface 1 10.1.1.254ip critical-service 1 upstream_downstreamcircuit VLAN2ip address 192.1.1.1 255.255.255.0ip virtual-router 2 priority 101 preemptip redundant-vip 2 192.1.1.100ip critical-service 2 upstream_downstreamCSS-2 Configuration
circuit VLAN1ip address 10.1.1.2 255.255.255.0ip virtual-router 1ip redundant-interface 1 10.1.1.254ip critical-service 1 upstream_downstreamcircuit VLAN2ip address 192.1.1.2 255.255.255.0ip virtual-router 2ip redundant-vip 2 192.1.1.100ip critical-service 2 upstream_downstreamActive-Active VIP and Virtual Interface Redundancy
A CSS can serve simultaneously as a master to one virtual router and as a backup to a different virtual router. This is called active-active VIP and virtual interface redundancy. All redundant VIP addresses will share the state of the virtual router to which they are associated. The same virtual router cannot be active on both CSSs simultaneously.
Figure 6-4 shows an active-active VIP and virtual interface redundancy configuration with:
•
–
–
–
–
•
–
–
–
–
Figure 6-4 Example of Active-Active VIP and Virtual Interface Redundancy
CSS-1 Configuration
circuit VLAN1ip address 10.1.1.1 255.255.255.0ip virtual-router 1 priority 101 preemptip virtual-router 2ip redundant-interface 1 10.1.1.254ip redundant-interface 2 10.1.1.253ip critical-service 1 upstream_downstreamip critical-service 2 upstream_downstreamcircuit VLAN2ip address 192.1.1.1 255.255.255.0ip virtual-router 3 priority 101 preemptip virtual-router 4ip redundant-vip 3 192.1.1.100ip redundant-vip 4 192.1.1.101ip critical-service 3 upstream_downstreamip critical-service 4 upstream_downstreamCSS-2 Configuration
circuit VLAN1ip address 10.1.1.2 255.255.255.0ip virtual-router 1ip virtual-router 2 priority 101 preemptip redundant-interface 1 10.1.1.254ip redundant-interface 2 10.1.1.253ip critical-service 1 upstream_downstreamip critical-service 2 upstream_downstreamcircuit VLAN2ip address 192.1.1.2 255.255.255.0ip virtual-router 3ip virtual-router 4 priority 101 preemptip redundant-vip 3 192.1.1.100ip redundant-vip 4 192.1.1.101ip critical-service 3 upstream_downstreamip critical-service 4 upstream_downstreamShared VIP Redundancy
In a shared VIP redundancy configuration, both the master and the backup virtual routers process flows destined to the same VIP. However, only the master virtual router (CSS-1) responds to ARP requests for the VIP address 192.1.1.100.
A shared VIP redundancy configuration has the following requirements:
•
•
•
•
•
Figure 6-5 shows a shared VIP redundancy configuration with:
•
•
Notice that CSS-2 (shared backup virtual router for VIP 192.1.1.100) forwards the ARP request for 192.1.1.100 to CSS-1 for a response.
Figure 6-5 Example of Shared VIP Redundancy
CSS-1 Configuration
circuit VLAN1ip address 10.1.1.1 255.255.255.0circuit VLAN2ip address 192.1.1.1 255.255.255.0ip virtual-router 1ip redundant-vip 1 192.1.1.100 sharedCSS-2 Configuration
circuit VLAN1ip address 10.1.1.2 255.255.255.0circuit VLAN2ip address 192.1.1.2 255.255.255.0ip virtual-router 1ip redundant-vip 1 192.1.1.100 sharedVIP and Virtual Interface Redundancy Quick Start
Table 6-1 provides a quick overview of the steps required to configure active-backup VIP and virtual interface redundancy with fate sharing for CSS-1 . Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI command, see the sections following Table 6-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.
Because this chapter is dedicated to configuring VIP and virtual interface redundancy, it contains only those circuit IP commands that pertain to this feature. For a complete description of all circuit IP commands, refer to the Cisco Content Services Switch Administration Guide.
Configuring VIP and Virtual Interface Redundancy
You must configure each CSS that is part of a redundant oconfiguration. The following sections describe how to configure VIP and virtual interface redundancy.
•
•
•
•
Configuring a Circuit IP Interface
Before you can configure VIP and virtual interface redundancy, you must configure a circuit IP interface and assign it an IP address. To enter a specific circuit configuration mode, enter the circuit command and VLAN as shown in the following example:
(config)# circuit VLAN2 (config-circuit[VLAN2])#
Note
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 /24When you specify an IP address, the mode changes to the specific circuit-ip-VLAN-IP address as shown:
(config-circuit-ip[VLAN2-192.1.1.1])#Configuring a Virtual Router
Use the ip virtual-router command to create a virtual router on a CSS and configure its identifier and priority that is used when negotiating control of associated VIPs. You must configure the virtual router before you can configure redundant VIPs.
A virtual router's role as a master or backup is determined during negotiations between all virtual routers with the same VRID and residing on the same VLAN.
The syntax and options for the IP interface command are:
ip virtual-router vrid {priority number} {preempt}
The variables and options are:
•
•
When a virtual router is the master, it handles the traffic directed to its associated VIPs. To set a virtual router so that it will always be master, set its priority to 255 and configure it with the preempt option.
•
For example, if a CSS with a virtual router that has a low priority boots before other CSSs, that virtual router becomes the master. When another CSS with a virtual router that has a higher priority boots, it will not take the mastership from the first router unless you specify the preempt option on the higher priority virtual router. This option does not have an effect if the priority of the two virtual routers is identical. You can use this option with or without the priority option. You can configure only one virtual router as the master of a particular VIP.
Caution
Because a virtual router's 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:
•
•
–
–
–
For information about configuring critical services, see the "Configuring Critical Services" section.
For example:
(config-circuit-ip[VLAN2-192.1.1.1])# ip virtual-router 2 priority 1 preemptTo remove the virtual router from the CSS, enter:
(config-circuit-ip[VLAN2-192.1.1.1])# no ip virtual-router 2Configuring a Redundant VIP
Use the ip redundant-vip command to associate an existing VIP to a virtual router and if required, configure the virtual router as a shared backup. A shared backup virtual router processes client requests. A redundant VIP configuration can consist of only two CSSs.
Note
The syntax for this IP mode command is:
ip redundant-vip vrid vip_address {range number} {shared}
The variables and options are:
•
•
•
•
Caution
For example:
(config-circuit-ip[VLAN2-192.1.1.1])# ip redundant-vip 2 192.1.1.100 range 10 sharedTo remove a VIP from a virtual router, enter:
(config-circuit-ip[VLAN1-192.1.1.1])# no ip redundant-vip 1 192.1.1.100Configuring a Redundant Virtual Interface
Use the ip redundant-interface command to configure a redundant virtual interface to be used as the default route for backend servers. Servers use the IP address of the virtual interface as a default route to guarantee that packets will be sent to the CSS containing the master virtual router. Configure a redundant interface with the same virtual router of a redundant VIP that has a rule that refers to the server. This configuration ensures that the master CSS for a VIP is thesame CSS that is master for the redundant virtual interface. This configuration is called fate sharing. If the master CSS fails over to the backup CSS, both the VIP and the redundant interface fail over together.
The syntax for this IP mode command is:
ip redundant-interface vrid ip_address
The variables are:
•
•
Note
•
For example:
(config-circuit-ip[VLAN1-10.1.1.1])# ip redundant-interface 1 10.1.1.254To remove an interface from a virtual router, enter:
(config-circuit-ip[VLAN1-10.1.1.1])# no ip redundant-interface 1 10.1.1.254
Note
Configuring Critical Services
Use the ip critical-service command to associate a critical service with a virtual router. When a critical service goes down, the associated virtual router also goes down. There are three types of critical services that you can configure:
•
The CSS provides a scripted keepalive called ap-kal-pinglist that you can use to check the health of, for example, an upstream router (192.1.1.254) running Hot Standby Router Protocol (HSRP) and a downstream Layer 2 switch (10.1.1.200) as critical services.
For example, create the service as follows:
(config)# service upstream_downstream(config-service[upstream_downstream])# ip address 192.1.1.254(config-service[upstream_downstream])# keepalive type script ap-kal-pinglist "192.1.1.254 10.1.1.200"(config-service[upstream_downstream])# active•
Note
•
The syntax for the ip critical-service command is:
ip critical-service vrid service_name
The variables are:
•
•
For example:
(config-circuit-ip[VLAN2-192.1.1.1])# ip critical-service 1 upstream_downstreamTo remove a critical service from a virtual router, enter:
(config-circuit-ip[VLAN2-192.1.1.1])# no ip critical-service 1 upstream_downstream
Note
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.
Synchronizing a VIP Redundancy Configuration
To ensure that your backup CSS can perform the same tasks as your master CSS in the event of a master CSS failure, the running-config on the backup must be identical (with some modifications) to the running-config on the master. To automate this configuration synchronization process, you can run the commit_VipRedundConfig script on the master CSS to copy the master CSS running-config to the backup CSS running-config.
There are two types of configuration synchronization:
•
•
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.
Before You Begin
Before you run the configuration synchronization script, ensure that you have configured VIP/interface redundancy and the Application Peering Protocol (APP). For details on configuring VIP/interface redundancy, see the "Configuring VIP and Virtual Interface Redundancy" section. For details on configuring APP, refer to Chapter 1, Configuring the CSS Domain Name Service in the "Configuring the Application Peering Protocol" section.
The synchronization script does not support the following configurations:
•
•
Running the Configuration Synchronization Script
To run the configuration synchronization script, use the script play commit_vip_redundancy command in SuperUser mode. The syntax is:
script play commit_vip_redundancy "arguments"
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:
•
"local master IP address remote backup IP address"
For details on automating the entry of the IP address, see "Setting the BACKUP_VIPR_IP Variable" later in this section.
•
•
Caution
•
•
Note
•
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:
CSS11506# commit_VipRedundConfigThe following output appears:
CSS11506# commit_VipRedundConfigVerifying app and redundancy configs ...Checking vip redundancy state ...Working \Verifying running-config copy success ...Commit successful!In this example, the script:
•
•
For more information about scripts, refer to Chapter 12, Using the CSS Scripting Language.
Config Sync Lock File
When you run the script, the software creates a lock file (vipr_config_sync_lock) in the script directory so that you cannot run the script from another session on the CSS. If the lock file exists and you run the script, the following message appears:
The script is in use by another session.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 this argument, the following message appears and the script exits:
VIPR Config Sync lock file removed.Now you can run the script again.
Setting the BACKUP_VIPR_IP Variable
To eliminate the need to specify IP addresses each time you run the configuration synchronization script, you can set the value of two variables (BACKUP _VIPR_IP and MASTER_VIPR_IP) to IP addresses and save them in your user profile. Once you set the variables and save them in your user profile, the variables will always be available after you log in to the CSS.
To set the variables, enter:
# set BACKUP_VIPR_IP "ip_address" {session}# set MASTER_VIPR_IP "ip_address" {session}where ip_address is the IP address of the backup or master CSS.
To save the variable in your user profile, enter:
# copy profile user-profileNow you can run the configuration synchronization script without typing an IP address.
Logging Configuration Synchronization Script Result Messages
You can specify that script result messages (script success or failure messages) be sent to the current logging device automatically each time you run the configuration synchronization script. To log the script result messages, enable logging on NETMAN with level info-6 or debug-7 by entering:
(config)# logging subsystem netman level info-6
Note
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 DOWNFor ease of tracking, each log message contains the string "vipr config sync".
Displaying VIP and Virtual Interface Redundancy Configurations
The CSS provides show commands to enable you to display redundant VIP and virtual interface configurations. The following sections describe the commands and provide tables describing the output fields.
•
•
•
Displaying IP Critical Services
Use the show critical-services command to display a list of all critical services configured on the CSS. You can provide an interface IP address option to display only the critical services present on a specific interface. You may also include a VRID to display only the critical service information for a specific virtual router.
The syntax for this command is:
show critical-services {ip_address {vrid}}
The optional variables are:
•
•
For example, to view all critical services on the CSS, enter:
# show critical-services
Table 6-2 describes the fields for the show critical-services command output.
Displaying Redundant Virtual Interfaces
Use the show redundant-interfaces command to display a list of all redundant virtual interfaces configured on the CSS. This command also displays the status (Enable or Disable) of the DNS server (if configured) on the virtual interface and the number of DNS packets processed by the interface. You may provide an interface IP address option to display only the virtual interfaces present on a particular interface. You may also include a VRID to display only the virtual interface information for a particular virtual router.
The syntax for this command is:
show redundant-interfaces {ip_address {vrid}}
The optional variables are:
•
•
For example, to view all redundant interfaces on the CSS, enter:
(config) # show redundant-interfacesTable 6-3 describes the fields in the show redundant-interfaces command output.
Displaying Redundant VIPs
Use the show redundant-vips command to display a list of all redundant VIPs configured on the CSS. You could provide an interface IP address option to display only the VIPs present on a particular interface. You can also include a VRID to display only the VIP information for a particular virtual router.
The syntax for this command is:
show redundant-vips {ip_address {vrid}}
The optional variables are:
•
•
For example, to view all redundant VIPs on the CSS, enter:
(config)# show redundant-vipsTable 6-4 describes the fields in the show redundant-vips command output.
Displaying Virtual Router Configurations
Use the show virtual-routers command to display a list of all virtual routers configured on the CSS. You may provide an interface IP address option to display only the virtual routers present on a particular interface. You may also include a VRID to display only the information for a particular virtual router.
The syntax for this command is:
show virtual-routers {ip_address {vrid}}
The optional variables are:
•
•
For example, to view all virtual routers on the CSS, enter:
(config)# show virtual-routersTable 6-5 describes the fields in the show virtual-routers command output.
