CSS Advanced Configuration Guide (Software Version 5.00) - Configuring VIP and Virtual IP Interface Redundancy [Cisco CSS 11000 Series Content Services Switches]

Table Of Contents

Configuring VIP and Virtual IP Interface Redundancy

VIP and Virtual IP Interface Redundancy Overview

Virtual IP Address (VIP) Redundancy

Virtual IP Interface Redundancy

VIP and Virtual IP Interface Redundancy Quick Start

Configuring VIP and Virtual IP Interface Redundancy

Configuring a Circuit IP Interface

Configuring an IP Virtual Router

Configuring an IP Redundant Interface

Configuring an IP Redundant VIP

Configuring IP Critical Services

Synchronizing a VIP Redundancy Configuration

Script Functions

Before You Begin

Running the Configuration Synchronization Script

Config Sync Lock File

Setting the BACKUP_VIPR_IP Variable

Logging Configuration Synchronization Script Result Messages

Showing Redundant VIP and Virtual IP Interface Configurations

Showing IP Critical Services

Showing Redundant Interfaces

Showing Redundant VIPs

Showing Virtual Router Configurations

VIP and Virtual IP Interface Redundancy Running-Config Examples

Configuring VIP and Virtual IP Interface Redundancy

This chapter describes how to plan for and configure Virtual IP (VIP) and Virtual
IP Interface Redundancy on the CSS. Information in this chapter applies to all CSS models except where noted.

This chapter contains the following sections:

•VIP and Virtual IP Interface Redundancy Overview

•VIP and Virtual IP Interface Redundancy Quick Start

•Configuring VIP and Virtual IP Interface Redundancy

•Showing Redundant VIP and Virtual IP Interface Configurations

•VIP and Virtual IP Interface Redundancy Running-Config Examples

VIP and Virtual IP Interface Redundancy Overview

The CSS enables you to configure redundancy for:

•Virtual IP Address (VIP) Redundancy

•Virtual IP Interface Redundancy

Virtual IP Address (VIP) Redundancy

When you configure more than one CSS for processing or forwarding client requests to the same Virtual IP address (VIP), the VIP is considered redundant. A typical use of VIP redundancy would be in a configuration where a master CSS processes all client requests to a VIP using a directly-connected dedicated Web server farm. If the Web server farm becomes unavailable, the backup CSS takes over using its own dedicated Web servers.

To setup 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 may configure a maximum of 255 virtual routers for each VLAN. You can only associate a virtual router with a single VLAN.

Virtual routers providing redundancy for an IP address are considered peers. Each virtual router peer has the same identifier 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:

•Master will process all client requests directed to the VIP

•Backup may be either a:

–Backup virtual router, which forwards all client requests directed to the VIP to the master CSS

–Shared backup virtual router, which processes all client requests it receives

A CSS can serve simultaneously as a master to one virtual router and as a backup to a different virtual router. All redundant VIP addresses will share the state of the virtual router to which it is associated.

shows an example of a redundant VIP configuration with:

•CSS-Boston configured as:

–VLAN1 IP address 192.168.8.1.

–Master virtual router 1 for VIP 192.168.8.4.

–Backup virtual router 2 for VIP 192.168.8.6. Because virtual router 2 is operating as a backup, it will forward all client requests it receives for VIP 192.168.8.6 to CSS-Cambridge master virtual router 2.

•CSS-Cambridge configured as:

–VLAN1 IP address 192.168.8.2.

–Backup virtual router 1 for VIP 192.168.8.4. Because virtual router 1 is operating as a backup, it will forward all client requests it receives for VIP 192.168.8.4 to CSS-Boston master virtual router 1.

–Master virtual router 2 for VIP 192.168.8.6.

Figure 4-1 Master and Backup Virtual Router Redundant VIP Configuration Example

shows an example of a redundant VIP configuration with:

•CSS-Boston configured as:

–Master virtual router 1 for VIP 192.168.8.4.

–Shared backup virtual router 2 for VIP 192.168.8.6. Because virtual router 2 is operating as a shared backup, it will process all client requests it receives for VIP 192.168.8.6.

•CSS-Cambridge configured as:

–Shared backup virtual router 1 for VIP 192.168.8.4. Because virtual router 1 is operating as a shared backup, it will process all client requests it receives for VIP 192.168.8.4.

–Master virtual router 2 for VIP 192.168.8.6.

Figure 4-2 Master CSS and Shared Backup CSS Redundant VIP Configuration Example

Virtual IP 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 this type of configuration, the CSS designated as master maintains control over the interface IP address.

The typical use for virtual interface redundancy is in a configuration where servers are positioned behind a Layer 2 switch and CSSs with the redundant virtual interface are positioned in front of the Layer 2 switch. The servers would be configured with a default route pointing to the redundant virtual interface IP address.

A CSS designated as master of a virtual interface sends out gratuitous ARPs for the virtual interface's IP address. This enables the Layer 2 switch to learn where to forward packets that are directed to the virtual interface. This allows a server's default route to always point to the CSS designated as the master of the virtual interface.

shows an example of a virtual interface redundancy configuration with a master CSS and a backup CSS.

Note Interface redundancy does not support shared backup.

Figure 4-3 Virtual Interface Redundancy Configuration Example using a Master and a Backup CSS

VIP and Virtual IP Interface Redundancy Quick Start

Table 4-1 provides a quick overview of the steps required to configure VIP and virtual interface redundancy for each CSS in the redundant configuration. 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, refer to the sections following Table 4-1.
Table 4-1 VIP Redundancy and Virtual IP Interface Redundancy Configuration Quick Start
Task and Command Example
1. Enter into config mode.
# config 
(config)#
2. Enter circuit mode for the desired circuit VLAN.
(config)# circuit VLAN1
(config-circuit[VLAN1])#
3. Configure a circuit IP address.
(config-circuit[VLAN1])# ip address 192.168.8.1/24
(config-circuit-ip[VLAN1-192.168.8.1])#
4. Configure the virtual router. Optionally, you may assign a priority different than the default of 100. Include the preempt keyword when configuring the master virtual router. The master virtual router must have the highest priority among its peers.
(config-circuit-ip[VLAN1-192.168.8.1])# ip virtual-router 1 
priority 230 preempt
5. Configure the redundant virtual IP interface on the virtual router.
(config-circuit-ip[VLAN1-192.168.8.1])# ip redundant-interface 1 
192.168.8.6
6. Configure the redundancy VIP on the virtual router. If you defined the content rule VIP using the range option, you must configure an identical range for the redundant VIP.
(config-circuit-ip[VLAN1-192.168.8.1])# ip redundant-vip 1 
192.168.8.10 range 10
If you want the backup virtual router to process client requests, you must configure it as a shared backup.
(config-circuit-ip[VLAN1-192.168.8.1])# ip redundant-vip 1 
192.168.8.10 shared
7. Configure the critical service for the virtual router.
(config-circuit-ip[VLAN1-192.168.8.1])# ip critical-service 1 
serv1
8. Display the configuration (optional).
(config)# show virtual-routers
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 Content Services Switch Basic Configuration Guide.

Configuring VIP and Virtual IP Interface Redundancy

The following sections describe how to configure VIP and virtual IP redundancy. You must configure each CSS in a redundant configuration.

•Configuring a Circuit IP Interface

•Configuring an IP Virtual Router

•Configuring an IP Redundant Interface

•Configuring an IP Redundant VIP

•Configuring IP Critical Services

•Synchronizing a VIP Redundancy Configuration

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 VLAN1 
(config-circuit[VLAN1])#
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 a mask in dot-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[VLAN1])# ip address 192.168.8.1/24
When you specify an IP address, the mode changes to the specific circuit-ip-VLAN-IP address as shown:
(config-circuit-ip[VLAN1-192.168.8.1])#
Configuring an IP Virtual Router

Use the ip virtual-router command to create a virtual router on a CSS and configure its identifier and priority 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 ID and 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:

•vrid - The virtual router identifier (VRID). Enter an integer between 1 and 255. You can configure 255 virtual routers per VLAN. Virtual routers are considered peers when they have the same VRID and are on the same VLAN.

•priority number - The optional priority of the virtual router with its peer. The default priority value is 100. Enter an integer between 1 and 255. A virtual router with the highest priority usually becomes master. However, a higher priority virtual router will not assume mastership from a lower priority master unless you include the preempt option.

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.

•preempt - The optional keyword that allows a higher priority virtual router to assert mastership over a lower priority virtual router. By default, a virtual router does not become master if the current master has a lower priority. 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 Never configure the preempt option on the same virtual router on both CSSs. Such a configuration may result in both CSSs becoming master, which will cause network problems.

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:

•Assign a priority of 255 to a virtual router and that virtual router gains mastership, the CSS automatically reconfigures that virtual router's priority to 254. This action ensures that you can assign a different virtual router a priority of 255.

•Configure critical services as:

–scripted, the priority changes to 0 when one service in the scripted group goes down

–uplink, the priority changes to 0 when all of the services in the uplink group go down

–local, the priority changes to 0 when all of the services in the local group go down. Local services include all services other than scripted and uplink.

For information on configuring critical services, refer to "Configuring IP Critical Services" later in this chapter.

For example:
(config-circuit-ip[VLAN1-192.168.8.1])# ip virtual-router 1 
priority 1 preempt
To remove the virtual router from the CSS, enter:
(config-circuit-ip[VLAN1-192.168.8.1])# no ip virtual-router 1
Configuring an IP Redundant Interface

Use the ip redundant-interface command to configure a redundant virtual interface address used for a backend server's default route. Servers use the IP address of the virtual interface as a default route to guarantee packets will be sent to the CSS containing the master virtual router. You may assign a redundant interface with the same virtual router of a VIP that has a rule that refers to the server. This ensures that the master for a VIP is also the CSS that is master for the redundant virtual interface.

The syntax for this IP mode command is:

ip redundant-interface vrid ip_address
The variables are:

•vrid - The ID for a previously configured virtual router.

•ip_address - The address for the redundant interface. Enter an IP address in dotted-decimal notation (for example, 192.168.8.6).

For example:
(config-circuit-ip[VLAN1-192.168.8.1])# ip redundant-interface 1 
192.168.8.6
To remove an interface from a virtual router, enter:
(config-circuit-ip[VLAN1-192.168.8.1])# no ip redundant-interface 
1 192.168.8.6
Configuring an IP 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.

Note Before you use this command, the VIP must be configured in a minimum of one content rule. Additionally, if you defined the content rule VIP using the range option, you must configure an identical range for the redundant VIP.

The syntax for this IP mode command is:

ip redundant-vip vrid vip_address {range number} {shared}
The variables and options are:

•vrid - The ID for an existing virtual router.

•vip_address - The address for the redundant VIP. This address must be already configured in a content rule. Enter an IP address in dotted-decimal notation (for example, 192.168.8.10).

•range number - The optional keyword and variable if an IP address range is specified in the content rule. You cannot specify a range that differs from the content rule. Also, you cannot specify address ranges to overlap. Enter a number from 0 to 65535. The default is 1.

•shared - The optional keyword to enable shared VIP redundancy. When you use this option, the master and backup virtual routers share the processing of traffic directed to the VIP, so the backup does not forward packets to the master. Each VIP should be configured identically on both CSSs.

For example:
(config-circuit-ip[VLAN1-192.168.8.1])# ip redundant-vip 1 
192.168.8.10 range 10 shared
To remove a VIP from a virtual router, enter:
(config-circuit-ip[VLAN1-192.168.8.1])# no ip redundant-vip 1 
192.168.8.10
Configuring IP Critical Services

Use the ip critical-service command to associate a service with a virtual router. When a critical service goes down, the associated virtual router will also go down. There are three types of critical services that you can configure:

•A scripted service, as defined by the (config-service) keepalive type script or (config-keepalive) type script command, running a script that is constantly scanning for service and network availability. The script software sets the service to a down state whenever network or service availability is a problem. The virtual router goes down if any associated scripted service goes down.

•A redundancy uplink service, as defined by the (config-service) type redundancy-up command. The virtual router goes down when all associated uplink services go down.

•Local services for any service other than scripted or redundancy uplink, such as a Web service. The virtual router goes down when all associated local services go down.

The syntax and options for the IP interface command are:

ip critical-service vrid service_name
The variables are:

•vrid - The ID for an existing virtual router.

•service_name - The name of the service. To see a list of services, enter ip critical-service vrid ?.

For example:
(config-circuit-ip[VLAN1-192.168.8.1])# ip critical-service 1 
serv1
To remove a critical service from a virtual router, enter:
(config-circuit-ip[VLAN1-192.168.8.1])# no ip critical-service 1 
serv1
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 a script (commit_VipRedundConfig) on the master CSS that copies the master CSS running-config to the backup CSS running-config.

There are two types of configuration synchronization:

•Complete - On CSSs that have a compatible configuration syntax, this type produces a running-config on the backup CSS that exactly matches the running-config on the master CSS. Table 4-2 provides examples of CSS combinations for complete configuration synchronization.

Table 4-2 Examples of CSSs with Compatible Configurations

Master

Backup

CSS 11800

CSS 11800

CSS 11150

CSS 11150

CSS 11050

CSS 11050

CSS 11050

CSS 11150

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.

•Partial (default) - On CSSs with a compatible or an incompatible configuration syntax, this type synchronizes all parameter values in the configuration except the interface and circuit configurations. For example, the master is a CSS 11800; the backup is a CSS 11150. The script maintains the current backup interface and circuit configurations automatically.

Script Functions

The configuration synchronization script performs all the necessary steps to update the backup CSS with the master's running configuration. The script:

•Saves the master running-config to the startup-config

•Archives the startup-config

•Copies the startup-config to a temporary file (tmp.cfg)

•Calls a function that converts the master VRRP/APP IP addresses to the backup VRRP/APP IP addresses in tmp.cfg

•Changes all VRID priorities on the master to 254

•Changes all VRID priorities in the backup's new config to 1

•Removes all preempt configs from all VRIDs in the backup's new config

•Uses rcmd to:

–Copy tmp.cfg to a temp file on the backup (newconfig)

–Check newconfig and copy it to the startup-config

–Clear the backup CSS's running-config and script play newconfig

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, refer to "Configuring VIP and Virtual IP Interface Redundancy" earlier in this chapter. For details on configuring APP, refer to Chapter 7, Configuring the CSS Domain Name Service.

The synchronization script does not support the following configurations:

•Active/active shared VIP

•Any configuration where some independent VIP addresses are a master while other VIP addresses are a backup

Running the Configuration Synchronization Script

To run the configuration synchronization script, use the script play commit_vip_redundancy command. 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, as follows:

commit_VipRedundConfig "arguments"
The arguments for the commit_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, refer to "Setting the BACKUP_VIPR_IP Variable" later in this section.

•-a (All) - Synchronizes the configuration completely. Use this argument only when the master and backup CSSs have exactly the same configuration syntax. This argument synchronizes the entire configuration and the interface mode.

•-d (Debug) - Debug switch for the commit_redundancy script, which displays the current task being performed as the script progresses. Debug messages display even when you specify the -s argument.

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, refer to "Setting the BACKUP_VIPR_IP Variable" later in this section.

•-nv (No Verify) - Informs the script not to verify that the configuration synchronization was successful. The default behavior is to verify the synchronization.

•-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.

Note You can specify the script arguments in any order.

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:
CS800# commit_VipRedundConfig
The following output appears:
CS800# commit_VipRedundConfig
Verifying app and redundancy configs ...
Checking vip redundancy state ...
Working \
Verifying running-config copy success ...
Commit successful!
In this example, the script:

•Performs a partial configuration synchronization (default)

•Verifies that the configuration synchronization was successful (default)

For more information on scripts, refer to Appendix A, Using the CSS Scripting Language.

Config Sync Lock File

When you run the script, the software creates a 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 system.

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-profile
Now 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 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:
vipr config sync: app session is DOWN
For ease of tracking, each log message contains the string "vipr config sync".

Showing Redundant VIP and Virtual IP Interface 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 examples of the screen displays and tables describing the screen fields.

•Showing IP Critical Services

•Showing Redundant Interfaces

•Showing Redundant VIPs

•Showing Virtual Router Configurations

Showing IP Critical Services

Use the show critical-services command to display a list of all critical services configured on the CSS. You may provide an interface IP address option to display only the critical services present on a particular interface. You may also include a VRID to display only the critical service information for a particular virtual router.

The syntax for this command is:
show critical-services {ip_address {vrid}}
The optional variables are:

•ip_address - The address for the redundant interface. Enter an IP address in dotted-decimal notation (for example, 192.168.11.1).

•vrid - The ID for an existing virtual router.

For example, to view all critical services on the CSS, enter:

# show critical-services
Table 4-3 describes the fields.

Table 4-3 Field Descriptions for the Show Critical Services Command

Field

Description

Interface Address

The IP interface address associated with the virtual router.

VRID

The assigned identifier associated with the virtual router.

Service Name

The name of the critical service.

Service Type

The type of critical service. Possible services are:

•service type, every type of service other than a scripted service or an uplink service. Typically, this is a Web server.

•Script, a service whose state depends upon a running script.

•Redundancy-up, a service whose state depends upon the state of an ICMP keepalive on a router.

Showing Redundant Interfaces

Use the show redundant-interfaces command to display a list of all redundant virtual IP interfaces configured on the CSS. 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:

•ip_address - The address for the redundant interface. Enter an IP address in dotted-decimal notation (for example, 192.168.11.1).

•vrid - The ID for an existing virtual router.

For example, to view all redundant interfaces on the CSS, enter:
(config) # show redundant-interfaces
Table 4-4 describes the fields.

Table 4-4 Field Descriptions for the Show Redundant Interface Command

Field

Description

Interface Address

The IP interface address associated with the redundant virtual interface.

VRID

The assigned identifier associated with the virtual router.

Redundant Address

The IP address of the redundant virtual interface.

Range

Not applicable. This field is always set to 1.

State

Current state of the virtual router. Possible states are:

•Master, the virtual router is master.

•Backup, the virtual router is backup.

•No Service, one or more critical services associated with the virtual router is down.

•IF Down, the IP interface associated with the virtual router is down.

Master IP

The IP address of the master virtual router.

State Changes

The number of times the redundant virtual interface state has changed.

Last Change

The date and time of the redundant virtual interface state last state change.

Showing 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:

•ip_address - The address for the redundant interface. Enter an IP address in dotted-decimal notation (for example, 192.168.11.1).

•vrid - The ID for an existing virtual router.

For example, to view all redundant VIPs on the CSS, enter:
(config)# show redundant-vips
Table 4-5 describes the fields.

Table 4-5 Field Descriptions for show redundant-vips Command

Field

Description

Interface Address

The IP interface address associated with the redundant VIP.

VRID

The assigned identifier associated with the virtual router.

Redundant Address

The IP address of the VIP.

Range

The range associated with the VIP.

State

Current state of the virtual router. Possible states are:

•Master, the virtual router is master.

•Backup, the virtual router is backup.

•No Service, one or more critical services associated with the virtual router is down.

•IF Down, the IP interface associated with the virtual router is down.

Master IP

The IP address of the master virtual router.

State Changes

The number of times the VIP state has changed.

Last Change

The data and time of the VIP last state change.

Showing 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:

•ip_address - The address for the redundant interface. Enter an IP address in dotted-decimal notation (for example, 192.168.11.1).

•vrid - The ID for an existing virtual router.

For example, to view all virtual routers on the CSS, enter:
(config)# show virtual-routers
Table 4-6 describes the fields.

Table 4-6 Field Descriptions for the show virtual-routers Command

Field

Description

Interface Address

The IP interface address associated with the virtual router.

VRID

The assigned identifier associated with the virtual router.

Priority

The priority currently being advertised by the virtual router. Because the priority is dependent on the state of the critical services, the priority may be different than the one configured.

Config. Priority

The configured priority.

State

Current state of the virtual router. Possible states are:

•Master, the virtual router is master.

•Backup, the virtual router is backup.

•No Service, one or more critical services associated with the virtual router is down.

•IF Down, the IP interface associated with the virtual router is down.

•Idle, the virtual router does not have any virtual interfaces or VIPs associated with it.

Master IP

The IP address of the master virtual router.

State Changes

The number of times the virtual router state has changed.

Last Change

The data and time of the virtual router last state change.

Preempt

True if preemption is enabled for the virtual router; false otherwise.

VIP and Virtual IP Interface Redundancy Running-Config Examples

The following running-config examples show VIP redundancy configured on two CSSs.

CSS-Boston Running-Config
!************************* GLOBAL **************************
!************************ INTERFACE ************************
interface e1 
	bridge vlan 1
!************************* CIRCUIT *************************
circuit VLAN1 
	ip address 192.168.8.1 255.255.255.0 
	ip virtual-router 1 priority 230 preempt 
	ip redundant-vip 1 192.168.8.10 shared 
	ip critical-service 1 serv1
!************************* SERVICE *************************
service serv1 
	ip address 20.1.1.1 
	active
!************************** OWNER **************************
owner arrow 
content L5_1 
	protocol tcp 
	vip address 192.168.8.10 
	port 80 
	url "/*" 
	add service serv1 
	active
CSS-Cambridge Running-Config
!************************** GLOBAL **************************
!************************ INTERFACE ************************
interface e1 
	bridge vlan 1
!************************* CIRCUIT *************************
circuit VLAN1 
	ip address 192.168.8.2 255.255.255.0 
	ip virtual-router 1 priority 200 
	ip redundant-vip 1 192.168.8.10 shared 
	ip critical-service 1 serv2
!************************* SERVICE *************************
service serv2 
	ip address 20.2.2.2 
	active
!************************** OWNER **************************
owner arrow 
content L5_1 
	protocol tcp 
	vip address 192.168.8.10 
	port 80 
	url "/*" 
	add service serv2 
	active