|
|
This chapter describes how to configure redundancy between two mirrored Content Smart Web Switches (CSS). Information in this chapter applies to all CSS models, except where noted.
This chapter contains the following sections:
The CSS redundancy protocol provides chassis-level redundancy between two CSSs. This feature protects the network and ensures that users have continuous access to servers and content.
Using the redundancy protocol CLI commands, you can configure two CSSs in a master and backup redundancy configuration. In a redundant configuration, the master CSS sends redundancy protocol messages every second to inform the backup CSS that it is alive.
If the master CSS fails and does not send a message within 3 seconds, the backup CSS:
If a former master comes back online, it becomes a backup CSS automatically when it receives the master CSS messages, unless you explicitly designated the CSS to be the master when you configured it. For details, refer to "Configuring IP Redundancy" later in this chapter.
 |
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 Configuring Source Groups, ACLs, EQLs, URQLs, NQLs, and DQLs. |
Figure 5-1 shows an example of a redundant configuration with multiple VLANs. Table 5-1 uses this figure to define the command examples necessary to configure the redundancy protocol.
Table 5-1 provides the steps required to configure the redundant configuration shown in Figure 5-1. Each step includes the CLI command required to complete the task. For a complete description of each feature, refer to the sections following
Table 5-1.
Listed below are the basic steps to configure redundancy:
1. Install the crossover cable on the master and redundant CSS before you power them on.
|
Caution If you power on the CSSs before you install the cable, both units boot up as the master CSS and cause network problems. |
2. Configure each server's default gateway as the CSS's circuit VLAN IP address.
3. Configure redundancy on the existing master CSS and save the running-config to startup-config.
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.
 |
Note If you make configuration changes to the master CSS startup-config, you must make the same changes to the backup CSS startup-config. If you are using a CSS 11800 and a CSS 11050, or CSS 11150, be aware that the interface configurations are different between the two CSSs. For details, refer to the Content Services Switch Basic Configuration Guide. To learn how to synchronize the running-configs of the master CSS and the backup CSS, refer to "Synchronizing a Redundant Configuration", later in this chapter. |
| Task and Command Example |
|---|
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 Ethernet-1 on the master CSS and port Ethernet-1 on the backup CSS. |
2. Configure each server's default gateway as the CSS circuit VLAN IP address. |
3. Enter the ip redundancy command on the master CSS to enable CSS-to-CSS redundancy. (config)# ip redundancy |
4. Configure an interface on the master CSS for a redundant connection to the backup CSS. For information on configuring interfaces, refer to the Content Services Switch Basic Configuration Guide. (config)# interface ethernet-1 |
5. Assign the interface to the redundant connection VLAN. For information on bridging the interface to a VLAN, refer to the Content Services Switch Basic Configuration Guide. (config-if[ethernet-1])# bridge vlan 2 |
6. Enter circuit mode for the redundant VLAN. For information on configuring circuits, refer to the Content Services Switch Basic Configuration Guide. (config-if[ethernet-1])# circuit VLAN2 |
7. Assign an IP address and subnet mask to circuit VLAN2. For information on configuring a circuit IP address, refer to the Content Services Switch Basic Configuration Guide. (config-circuit[VLAN2])# ip address 172.7.6.1/24 |
8. Enable the redundancy protocol on the redundant IP interface. (config-circuit-ip[VLAN2-172.7.6.1])# redundancy-protocol |
9. Define the other circuits as redundant circuits. (config-if[ethernet-1])# circuit VLAN1 |
10. From SuperUser mode, save the master CSS running-config to the startup-config. # copy running-config startup-config |
11. FTP the startup-config to a PC for editing. |
12. Using a text editor, edit the startup-config by including the backup CSS circuit VLAN IP address for the redundant connection (in Figure 5-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 as startup-config. |
14. Reboot the backup CSS. |
15. Enter the show redundancy command to display the redundancy configuration and ensure that the backup CSS is configured properly. |
16. Cable all hubs (or switches) to the backup CSS. |
When setting up a redundant configuration, use a Category 5 crossover cable to connect the master and backup CSS interfaces.
|
Note Install the crossover cable on the master and backup CSSs before you power them on. 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. |
Table 5-2 lists the pinouts for the CSS Fast Ethernet connectors and the crossover pinouts.
| Signal Name | Pin Number | Crossover Cable Pinouts |
|---|---|---|
RX + | 1 | 3 |
RX - | 2 | 6 |
TX + | 3 | 1 |
Unconnected | 4 | 4 |
Unconnected | 5 | 5 |
TX - | 6 | 2 |
Unconnected | 7 | 7 |
Unconnected | 8 | 8 |
Configuring the redundancy protocol requires you to:
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 interface_name command (physical link redundancy). If necessary, disable the appropriate command using no type redundancy-up or no redundancy-phy interface_name 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:
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 The no ip redundancy command deletes the redundancy and redundancy-protocol commands from the running-config of the CSS. |
Before the CSS disables redundancy, it displays the following message:
WARNING: Disabling redundancy may result in duplicate
IP addresses on the network. Be sure you disconnect or disable all redundant circuits before you disable redundancy. Do you want to disable redundancy? [y/n]:
Type `y' to disable redundancy. Type `n' to cancel disabling redundancy.
To unassign the CSS as the master CSS, enter:
(config)# no ip redundancy master
|
Note The no ip redundancy master command does not disable CSS-to-CSS redundancy. |
To configure a circuit as a redundant circuit, use the redundancy command. The redundancy command is available in circuit configuration mode.
|
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 5-1, these are VLAN1 and VLAN3). Do not configure redundancy on the circuit (VLAN) configured specifically for redundancy communications (in Figure 5-1, this is VLAN2).
The example below configures VLAN1 as a redundant circuit, which contains a shared network IP address (in Figure 5-1, this is 192.168.20.1).
For example:
(config-circuit[VLAN1])# redundancy
To remove a circuit from the redundancy configuration, enter:
(config-circuit[VLAN1])# no redundancy
To configure the redundancy protocol on the circuit (VLAN) connecting the two CSSs, enter the redundancy-protocol command in IP interface configuration mode. Enter the command for the circuit you configured specifically for redundancy communications (in Figure 5-1, this is VLAN2).
For example:
(config-circuit-ip[VLAN2-172.7.6.1])# redundancy-protocol
To stop running a redundancy protocol on an interface, enter:
(config-circuit-ip[VLAN2-172.7.6.1])# no redundancy-protocol
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 to the running-config on the master. To automate this configuration synchronization process, you can run a script (commit_redundancy) on the master CSS that copies the master CSS running-config to the backup CSS running-config.
There are two types of configuration synchronization:
|
|
|---|---|
|
|
|
|
|
|
|
|
|
Note You can perform a complete configuration synchronization when the master CSS is a CSS 11150 and the backup CSS is a CSS 11050 provided that the master CSS does not have configured physical ports that do not exist on the backup CSS. |
|
Note Before you run the configuration synchronization script, ensure that you have set up the redundancy circuit between the two CSSs and that the Application Peering Protocol (APP) is running on that circuit. For details on configuring the redundancy circuit, refer to "Configuring Redundancy", earlier in this chapter. For details on configuring APP, refer to Configuring the CSS Domain Name Service, in the section "Configuring Application Peering Protocol". |
To run the configuration synchronization script, use the script play commit_redundancy command. The syntax is:
script play commit_redundancy "arguments"
You can also run the configuration synchronization script using the predefined alias that comes with all CSSs, as follows:
commit_RedundConfig "arguments"
The arguments for the commit_redundancy script are:
|
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. |
|
Note You can specify the script arguments in any order. |
For example, suppose you have a redundant configuration where the master is a CSS 11800 and the backup is a CSS 11150. Run the following script on the CSS 11800:
CS800# script play commit_redundancy "10.7.100.93 -d -v -s"
The following output appears:
Verifying that IP redundancy is activated on Master switch. Verifying that app session is up with backup switch. Making sure app session is up. Checking Master redundancy-config for redundancy-protocol set and if so storing it in variable MASTER_IP. Verify that the IP Address specified is the Backup IP Address. Making sure app session is up. Saving Master running-config to startup-config and archiving startup-config. Copying running-config to startup-config. Archiving startup-config. Copying startup-config to a temp file tmp.cfg. Swapping Master and Backup ip addresses in tmp.cfg for app Removing CIRCUIT and INTERFACE modes from tmp.cfg. Checking if IP redundancy master is set. Using rcmd to copy tmp.cfg to a file on Backup switch. Retrieving circuit info for redundancy-protocol link. Archiving copy to Backup startup-config. Archiving Backup current startup-config. Restoring startup-config (new copy) to startup-config. Clearing running-config. Script playing the copy script of the Master running-config. Making sure app session is down. Copy success being verified by comparing byte sizes of archived running-configs of the Master switch and the Backup switch. Making sure app session is up. Comparing the byte count now. Config Sync Successful.
In this example, the script:
For more information on scripts, refer to Using the CSS Scripting Language.
When you run the script, the software creates a a lock file (config_sync_lock) in the script directory so that you cannot run the script from another session to 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, then you can 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:
Config Sync lock file removed.
Now you can run the script again.
To eliminate the need to specify an IP address each time you run the configuration synchronization script, you can set the value of a variable (BACKUP_IP) to an IP address and save it in your user profile. Once you set the variable and save it in your user profile, the variable will always be available after you log in to the system.
To set the BACKUP_IP variable, enter:
# set BACKUP_IP "ip_address" {session}
To save the variable in your user profile, enter:
# copy profile user-profile
Now you can run the configuration synchronization script without typing an IP address.
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 Log messages are generated with or without the -s (silent) argument specified. Refer to "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".
Use the redundancy force-master command to configure a backup CSS as a master temporarily. This is a temporary setting because it is not copied to the running-config. This command is useful in a redundant configuration when you need to take the master CSS offline for maintenance or an upgrade.
By issuing the redundancy force-master command on the backup CSS in global configuration mode, you set that CSS to master and ensure that users have continuous access to servers and content. The forced master CSS remains the master:
|
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. |
Figure 5-2 shows a typical redundant configuration. When CSS1 fails or CSS1 cannot communicate with both Router1 service and Router2 service, CSS2 becomes the master CSS automatically.
|
Note 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. |
Use the type redundancy-up command to configure each router service for uplink redundancy. For example:
(config-service[router1])# type redundancy-up (config-service[router1])# ip address 192.168.1.1 (config-service[router1])# active
Fo example:
CSS1(config)# show running-config service
Use the redundancy-phy command in interface mode to add an interface to the physical link configuration list. If any physical link in the configuration list goes down, the CSS fails over to the backup CSS. You can configure a maximum of five interfaces.
|
Note This configuration information is saved to the running-config. |
When you issue this command, specify the interface name.
For example, on a CSS 11050 or CSS 11150, use the interface-port format:
(config-if)# redundancy-phy ethernet-1
For example, on a CSS 11800, use the slot/port format:
(config-if)# redundancy-phy 3/1
For more information on specifying interface names, refer to the Content Services Switch Basic Configuration Guide.
To see a list of valid interfaces for this CSS, enter:
(config-if)# redundancy-phy ?
|
Note You cannot use the redundancy-phy command if you used the ip redundancy master command to configure the master CSS. In this case, you must issue the no ip redundancy master command before you can use the redundancy-phy command. |
To disable a configured interface and delete it from the physical link list, enter:
(config-if)# no redundancy-phy ethernet-1
|
Note When you use the redundancy-phy command and both CSSs are connected to a Layer 2 switch, be sure to monitor physical link failure only on the critical physical links and not on the redundant link between the two CSSs. This will avoid the detection of a physical link down and possible thrashing when one of the CSSs is rebooting or transitioning between master and backup states. |
To display CSS-to-CSS redundancy, use the show redundancy command.
For example:
(config)# show redundancy
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.
Posted: Tue Dec 12 05:40:05 PST 2000
Copyright 1989-2000©Cisco Systems Inc.