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 Configuration Quick Start
Configuring VIP and Virtual Interface Redundancy
Configuring a Circuit IP Interface
Configuring a Redundant Virtual Interface
Configuration Requirements and Restrictions
Configuring the Virtual Routers That You Want to Monitor
Configuring a Critical Reporter
Configuring a Critical Service
Configuring a Critical Physical Interface
Configuration Requirements and Restrictions
Configuring the Physical Interfaces That You Want to Monitor
Configuring a Critical Reporter
Synchronizing a VIP Redundancy Configuration
Running the Configuration Synchronization Script
Setting the LOCAL_VIPR_IP and REMOTE_VIPR_IP Variables
Logging Configuration Synchronization Script Result Messages
Displaying VIP and Virtual Interface Redundancy Configurations
Displaying Redundant Virtual Interfaces
Displaying Virtual Router Configurations
Resetting the Virtual Router State Changes Counter
Displaying IP Critical Services
Displaying Reporter Configurations
Using the show reporter Command
Resetting the Reporter State Transitions Counter
Displaying a Reporter Configuration in the Running-Config
Displaying Critical Reporter Information
Displaying Critical Reporters in the Running-Config
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:
•
Note
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
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 Example of VIP and Virtual Interface Redundancy
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:
•
•
–
–
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.
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 Cisco View Device Manager (CVDM) user interface.
The typical use for virtual interface redundancy is with a VIP redundancy configuration in which:
•
•
•
•
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.
A CSS designated as the master of a redundant virtual interface automatically sends out gratuitous ARPs for the redundant virtual interface's IP address when the CSS becomes the master, either at startup or upon failover. This process enables a Layer 2 switch to learn where to forward packets that are directed to the redundant virtual interface from the servers or the clients and allows a server's default route to always point to the CSS designated as the master of the redundant 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 1-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 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.
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 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 1-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 1-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 redundant-interface 2 192.1.1.254ip 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 redundant-interface 2 192.1.1.254ip critical-service 2 upstream_downstreamActive-Active VIP and Virtual Interface Redundancy
A CSS can serve simultaneously as a master to one VR and as a backup to a different VR. This is called active-active VIP and virtual interface redundancy. All redundant VIP addresses will share the state of the VR to which they are associated. The same VR cannot be active on both CSSs simultaneously.
Figure 1-4 shows an active-active VIP and virtual interface redundancy configuration with:
•
–
–
–
–
•
–
–
–
–
Figure 1-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 redundant-interface 3 192.1.1.254ip redundant-interface 4 192.1.1.253ip 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 redundant-interface 3 192.1.1.254ip redundant-interface 4 192.1.1.253ip critical-service 3 upstream_downstreamip critical-service 4 upstream_downstreamShared VIP Redundancy
In a shared VIP redundancy configuration, both the master and the backup VRs process flows destined to the same VIP. However, only the master VR (CSS-1) responds to ARP requests for the VIP address 192.1.1.100.
Note
A shared VIP redundancy configuration has the following requirements:
•
•
•
•
•
Figure 1-5 shows a shared VIP redundancy configuration with:
•
•
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.
Figure 1-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 Configuration Quick Start
Table 1-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 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.
!************************* INTERFACE *************************interface 2/1bridge vlan 2!************************** CIRCUIT **************************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_downstream!************************** SERVICE **************************service upstream-downstreamip address 192.1.1.10keepalive type script ap-kal-pinglist "192.1.1.20 10.1.1.20"keepalive frequency 2keepalive maxfailure 2keepalive retryperiod 2activeConfiguring VIP and Virtual Interface Redundancy
You must configure each CSS that is part of a redundant configuration. The following sections describe how to configure VIP and virtual interface redundancy.
•
•
•
•
•
Configuring a Circuit IP Interface
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 Routing and Bridging Configuration Guide.
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
To create a virtual router (VR) on a CSS and configure the identifier and priority that is used when negotiating control of associated VIPs, use the ip virtual-router command. You must configure the VR before you can configure redundant VIPs.
A VR's role as a master or backup is determined during negotiations between all VRs with the same VRID and residing on the same VLAN.
Note
The syntax and options for the IP interface command are:
ip virtual-router vrid {priority number} {preempt}
The variables and options are:
•
•
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.
•
For example, if a CSS with a VR that has a low priority boots before other CSSs, that VR becomes the master. When another CSS with a VR 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 VR. This option does not have an effect if the priority of the two VRs is identical. You can use this option with or without the priority option. You can configure only one VR as the master of a particular VIP.
Caution
Because a VR'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 a Critical Service" section.
For example:
(config-circuit-ip[VLAN2-192.1.1.1])# ip virtual-router 2 priority 1 preemptTo remove the VR from the CSS, enter:
(config-circuit-ip[VLAN2-192.1.1.1])# no ip virtual-router 2Configuring a Redundant VIP
To associate an existing VIP with a VR and, if required, configure the VR as a shared backup, use the ip redundant-vip command. A shared backup VR processes client requests. A redundant VIP configuration can consist of only two CSSs.
Note
The syntax of 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 VR, enter:
(config-circuit-ip[VLAN1-192.1.1.1])# no ip redundant-vip 1 192.1.1.100Configuring a Redundant Virtual Interface
Servers use the IP address of a redundant virtual interface as a default gateway to guarantee that packets are sent to the CSS containing the master VR. To accomplish this goal, configure a redundant virtual interface with the same VR as a redundant VIP that is configured in a rule that refers to the server. This configuration ensures that the master CSS for a VIP is the same CSS that is master for the redundant virtual interface. If the master CSS fails over to the backup CSS, both the VIP and the redundant interface fail over together. This configuration is called fate sharing. For details, see the "Fate Sharing" section.
We recommend that you also configure a redundant virtual interface on the public side of each CSS. This configuration provides a single IP address as the next hop for the upstream routers.
To configure a redundant virtual interface, use the ip redundant-interface command.
The syntax of 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 VR, enter:
(config-circuit-ip[VLAN1-10.1.1.1])# no ip redundant-interface 1 10.1.1.254
Note
Configuring VRID Peering
To ensure that the state of the virtual routers (VRs) on both the public and the private sides of a CSS remain synchronized, configure VRID peering in a VIP and virtual interface redundancy configuration. VRID peering groups VRs that are configured on the same CSS so that, when one VR in the group changes state (for example, from master to backup), all VRs in the group change state at the same time. This feature helps to prevent asymmetric flows, which cause network address translation (NAT) to fail and break the client-server connection.
This section contains the following topics:
•
•
•
•
•
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.
Overview of VRID Peering
VRID peering works by grouping two or more VR peers with a software agent called a reporter that monitors the states of the VRs. VRs are considered peers when they are configured on the same CSS. The reporter ensures that the states of the VR peers are synchronized by sending internal state update messages to the monitored VRs when necessary.
The internal state of a virtual router is called an independent VR state because it does not depend on the state of its VR peers. The VR peer reporter state is called a dependent VR state because it depends on the states of all VRs configured on the reporter.
Table 1-2 lists the independent VR states and describes the conditions required for each state.
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.
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.
Configuration Requirements and Restrictions
The following requirements and recommendations apply to the configuration and use of VRID peering on a Cisco 11500 series CSS.
•
•
•
•
•
•
•
•
VRID Peering Quick Start
Table 1-5 provides a quick overview of the steps required to configure VRID peering. 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 1-5.
Table 1-5 VRID Peering Configuration Quick Start
1.
# config (config)#2.
(config)# reporter r1(config-reporter[r1])#3.
(config-reporter[r1])# type vrid-peering4.
(config-reporter[r1])# vrid 192.168.100.5 1(config-reporter[r1])# vrid 172.16.27.12 25.
(config-reporter[r1])# active6.
(config-circuit-ip[VLAN1-192.168.100.5])# ip critical-reporter 1 r1(config-circuit-ip[VLAN2-172.16.27.12])# ip critical-reporter 2 r17.
(config-circuit-ip[VLAN2-172.16.27.12])# show reporter r18.
(config-circuit-ip[VLAN2-172.16.27.12])# show running-config reporter
The following running-config example shows the results of entering the commands in Table 1-5.
!************************** CIRCUIT **************************circuit VLAN1ip address 192.168.100.5 255.255.255.0ip virtual-router 1 priority 101 preemptip critical-reporter 1 r1circuit VLAN2ip address 172.16.27.12 255.255.255.0ip virtual-router 2 priority 101 preemptip critical-reporter 2 r1!************************** REPORTER **************************reporter r1type vrid-peeringvrid 192.168.100.5 1vrid 172.16.27.12 2activeConfiguring 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
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 r1To remove an existing reporter from the running-config, enter:
(config-reporter[r1])# no reporter r1
Note
Configuring the Reporter Type
A VRID peer is a type of reporter that monitors the states of associated VRs and ensures that the VR states are synchronized. To configure the reporter type, use the type command in reporter configuration mode. You can configure a maximum of four reporters of type vrid-peering on a CSS.
Note
This command has the following syntax.
type reporter_type
For example, to configure a reporter as a VRID peering type, enter:
(config-reporter[r1])# type vrid-peeringTo remove the VRID peering type or to reconfigure the reporter type as a critical phy type:
1.
Note
2.
3.
4.
Configuring the Virtual Routers That You Want to Monitor
To configure the VRs that you want a reporter to monitor, use the vrid command in reporter configuration mode.
This command has the following syntax:
vrid ip_address vrid
Note
The variables for this command are:
•
•
For example:
(config-reporter[r1])# vrid 192.168.12.7 1
Note
To remove a VR from a reporter, enter:
(config-reporter[r1])# no vrid 192.168.12.7 1Activating 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])# activeSuspending 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
For example, enter:
(config-reporter[r1])# suspendConfiguring a Critical Reporter
To associate a reporter with a VR, use the ip critical-reporter command in circuit configuration mode. You can associate more than one critical reporter with a VR provided that the critical reporters are of different types. See the "Configuring a Critical Physical Interface" section.
If any critical reporter is suspended or goes down, all VRs associated with it go down. To ensure that the VR states are synchronized, configure a critical reporter on both the front-side and the back-side VRs.
The syntax of this command is:
ip critical-reporter vrid reporter_name
The variables are:
•
•
For example, to associate reporter r1 with a VR that has a VRID of 1, enter:
(config-circuit-ip[VLAN1-192.168.7.9])# ip critical-reporter 1 r1To remove a critical reporter from the running-config, enter:
(config-circuit-ip[VLAN1-192.168.7.9])# no ip critical-reporter 1 r1Configuring a Critical Service
Configure a critical service to monitor the health of upstream and downstream devices. When one or all critical services go down (depending on the type of critical service you configure), the associated VR also goes down, which causes a failover from master CSS to backup CSS. 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
•
To associate a critical service with a VR, use the ip critical-service command. The syntax of 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 VR, 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.
Configuring a Critical Physical Interface
Configure a critical physical interface (critical phy) on a CSS to provide an additional failover catalyst for a virtual router (VR) in a VIP and interface redundancy configuration. A critical phy improves the failover time of a VR (as compared with a critical service) by reacting quickly to a Down state of monitored physical interfaces. This feature is intended to complement critical services, not replace them. For details on critical services, see the "Configuring a Critical Service" section.
This section contains the following topics:
•
•
•
•
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.
Configuration Requirements and Restrictions
The following requirements and recommendations apply to the configuration and use of critical phys on a Cisco 11500 series CSS:
•
•
•
•
•
•
Critical Phy Quick Start
Table 1-6 provides a quick overview of the steps required to configure a critical phy on a reporter. 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 1-6.
Table 1-6 Critical Phy Configuration Quick Start
1.
# config (config)#2.
(config)# reporter r1(config-reporter[r1])#3.
(config-reporter[r1])# type critical-phy-all-up4.
(config-reporter[r1])# phy 1/1(config-reporter[r1])# phy 1/25.
(config-reporter[r1])# active6.
(config-reporter[r1])# exit(config)#7.
(config)# circuit VLAN1(config-circuit[VLAN1])# ip address 192.168.7.9(config-circuit-ip[VLAN1-192.168.7.9])#8.
(config-circuit-ip[VLAN1-192.168.7.9])# ip critical-reporter 1 r19.
(config-circuit-ip[VLAN1-192.168.7.9])# show reporter r110.
(config-circuit-ip[VLAN1-192.168.7.9])# show running-config reporter11.
(config-circuit-ip[VLAN1-192.168.7.9])# show running-config circuit
The following running-config example shows the results of entering the commands in Table 1-6.
!************************** CIRCUIT **************************circuit VLAN1ip address 192.168.7.9 255.255.255.0ip virtual-router 1 priority 101 preemptip critical-reporter 1 r1!************************** REPORTER **************************reporter r1type vrid-peeringphy 1/1phy 1/2activeConfiguring 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.
For example, enter:
(config)# reporter r1To remove an existing reporter and all of its attributes from the running-config, enter:
(config-reporter[r1])# no reporter r1Configuring the Reporter Type
A critical phy is a type of reporter that determines how the reporter reacts to a Down state of the associated physical interfaces. To configure a critical phy type on a reporter, use the type command in reporter configuration mode. This command has the following syntax.
type reporter_type
Note
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.
You can configure a maximum of 128 reporters of any combination of types on a CSS, depending on available memory.
When you configure a critical phy, the states of the monitored physical interfaces affect the reporter state, which in turn affects the VR state, depending upon the type of configured reporter as shown in Table 1-7.
For example, enter:
(config-reporter[r1])# type critical-phy-all-upTo remove the critical phy type (either critical-phy-all-up or critical-phy-any-up) or to reconfigure the reporter type as a vrid-peering type:
1.
Note
2.
3.
4.
Configuring the Physical Interfaces That You Want to Monitor
To configure one or more physical interfaces that you want a reporter to monitor, use the phy command in reporter configuration mode. You can configure a maximum of 128 interfaces on a reporter.
Note
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 e1To configure Ethernet port 1 on a CSS 11503 or 11506, enter:
(config-reporter[r1])# phy 1/1
Note
To remove Ethernet port 1 from the list of interfaces to monitor on a CSS 11501, enter:
(config-reporter[r1])# no phy e1To remove Ethernet port 1 from the list of interfaces to monitor on a CSS 11503 or 11506, enter:
(config-reporter[r1])# no phy 1/1Activating 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])# activeSuspending 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
Configuring a Critical Reporter
To associate a reporter with a VR, use the ip critical-reporter command in circuit configuration mode. You can associate more than one critical reporter with a VR. If any critical reporter is suspended or goes down, all VRs associated with it go down and cause a failover from master to backup.
Note
The syntax of this command is:
ip critical-reporter vrid reporter_name
The variables for this command are:
•
•
For example, enter:
(config-circuit-ip[VLAN1-192.168.7.9])# ip critical-reporter 1 r1To remove a critical reporter, enter:
(config-circuit-ip[VLAN1-192.168.7.9])# no ip critical-reporter 1 r1Synchronizing a VIP Redundancy Configuration
To ensure that your remote CSS can perform the same tasks as your local CSS in the event of a master CSS failure, the running-config on the remote CSS must be identical (with some modifications) to the running-config on the local CSS. To automate this configuration synchronization process, you can run the commit_VipRedundConfig script on the local CSS to copy the local CSS running-config to the remote CSS running-config.
There are two types of configuration synchronization:
•
To perform a complete configuration, run the script play commit_vip_redundancy command with the -a argument. For more information on running this script and argument, see the "Running the Configuration Synchronization Script" section. Consider running a complete synchronization when you need to replicate interface and circuit configurations including redundant VIPs on a circuit.
This type of synchronization copies reporter configurations for both VRID peering (see the "Configuring VRID Peering" section) and critical phy (see the "Configuring a Critical Physical Interface" section) with the following exceptions:
–
–
•
For example, the master is a CSS 11506 and the backup is a CSS 11503. The script maintains the current remote interface and circuit configurations automatically. For CSSs with configured reporters, the script does not copy the reporter configurations to the remote CSS regardless of chassis types.
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 the Cisco Content Services Switch Global Server Load-Balancing Configuration Guide.
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"
Note
By default, the synchronization script synchronizes all parameter values in the configuration except the interface and circuit configurations (including redundant VIPs). When you need to replicate interface and circuit configurations, you can manually configure them on the backup CSS, or consider running the synchronization script with the -a argument to replicate them.
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 LOCAL_VIPR_IP and REMOTE_VIPR_IP Variables" later in this section.
•
Note
•
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:
# commit_VipRedundConfigThe following output appears:
# 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 the Cisco Content Services Switch Administration Guide.
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 the -f argument, the following message appears and the script exits:
VIPR Config Sync lock file removed.Now you can run the script again.
Setting the LOCAL_VIPR_IP and REMOTE_VIPR_IP Variables
To eliminate the need to specify IP addresses each time you run the configuration synchronization script, you can set the value of two variables (LOCAL_VIPR_IP and REMOTE_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. 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" sessionTo save the variable in your user profile, enter:
# copy profile user-profileNow you can run the configuration synchronization script without typing an IP address.
Note
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 VIP and virtual interface redundancy configurations. The following sections describe the commands and provide tables describing the output fields.
•
•
•
•
Displaying Redundant Virtual Interfaces
To display a list of all redundant virtual interfaces configured on the CSS, use the show redundant-interfaces command. This command also displays the status (Enable or Disable) of the DNS server (if configured) on the redundant virtual interface and the number of DNS packets processed by the interface. You may provide an interface IP address option to display only the redundant virtual interfaces present on a particular interface. You may also include a VRID to display only the redundant virtual interface information for a particular VR.
The syntax of 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 1-8 describes the fields in the show redundant-interfaces command output.
Displaying Redundant VIPs
To display a list of all redundant VIPs configured on the CSS, use the show redundant-vips command. 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 VR.
The syntax of 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 1-9 describes the fields in the show redundant-vips command output.
Displaying Virtual Router Configurations
To display a list of all VRs configured on the CSS, including their configuration and state information, use the show virtual-routers command. If VRID peering (see the "Configuring VRID Peering" section) or critical phy (see the "Configuring a Critical Physical Interface" section) is configured on the CSS, this command also displays any critical reporters associated with the VRs.
You may provide an interface IP address option to display only the VRs present on a particular interface. You may also include a VRID to display only the information for a particular VR.
The syntax of this command is:
show virtual-routers {ip_address {vrid}}
The optional variables are:
•
•
For example, to view all VRs on the CSS, enter:
(config)# show virtual-routersTable 1-10 describes the fields in the show virtual-routers command output.
Resetting the Virtual Router State Changes Counter
The show virtual-routers command displays a State Changes field that records the number of times that a VR changed state since the CSS was booted. To set this counter to zero, use the zero virtual-router state-changes command in any mode.
The syntax of this command is:
zero virtual-router state-changes [all|circuit ip_address [all|vrid number]]
The variables and options for this command are:
•
•
•
•
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 allDisplaying IP Critical Services
To display a list of all critical services configured on the CSS, use the show critical-services command. 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 VR.
The syntax of 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-servicesTable 1-11 describes the fields for the show critical-services command output.
Displaying Reporter Configurations
To display reporter configurations for VRID peering and critical phy, use the following commands:
•
•
•
•
•
•
Using the show reporter Command
To display reporter configuration and statistics for VRID peering or critical phy, use the show reporter command. The syntax of this command is:
show reporter {reporter_name|summary}
The variables and options for this command are:
•
•
Table 1-12 describes the fields for the show reporter command output.
Table 1-12 Field Descriptions for the show reporter Command
Name
Name of the reporter whose configuration you are displaying.
State
Current state of the reporter. Possible reporter states for VRID peering are Master, Backup, Suspended, or Down. Possible reporter states for critical phy are Up, Suspended, or Down.
Type
Type of reporter. Possible reporter types are:
•
•
•
State Transitions
Number of times the reporter state changed since the last time the CSS was booted. If the State Transitions field is 0, the 0 value can be due to a counter reset through the global configuration mode zero reporter state-transitions command. The counter can also be 0 if the reporter is down.
Circuit (VRID peering only)
Circuit IP address of the CSS.
VRID (VRID peering only)
Identifier of the VR associated with the reporter.
State (VRID peering only)
Current state of the VR associated with the reporter. Possible states of the VR are Master, Backup, Down, or Unknown.
Interface (critical phy only)
Interfaces associated with the reporter.
Link (critical phy only)
Current state of the physical link interface. Possible link states are Up or Down.
Resetting the Reporter State Transitions Counter
The show reporter command displays a State Transitions field that records the number of times that a reporter changed state since the CSS was booted. To set this counter to zero, use the zero reporter state-transitions command in any command mode.
The syntax of this command is:
zero reporter state-transitions [all|reporter reporter_name]
The variables and options for this command are:
•
•
For example, to reset the State Transitions counter for reporter r1, enter:
(config)# zero reporter state-transitions reporter r1Displaying a Reporter Configuration in the Running-Config
To display a reporter configuration in the running-config, use the show running-config reporter command in any mode. This command displays all reporter configurations on the CSS. To display a specific reporter configuration, use the show running-config reporter reporter_name command.
Displaying Critical Reporter Information
To display critical reporter configuration information for VRID peering and critical phy, use the show critical-reporter command in any mode. The syntax of this command is:
show critical-reporters ip_address vrid
The variables for this command are:
•
•
Table 1-13 describes the fields for the show critical-reporters command output.
Displaying Critical Reporters in the Running-Config
To display configured critical reporters in the running-config, use the show running-config circuit command. This command displays all configured circuits and any critical reporters associated with a virtual router.
