Cisco GSS Configuration Guide (Software Version 1.1) - Configuring KeepAlives [Cisco ACE GSS 4400 Series Global Site Selector Appliances]

Table Of Contents

Configuring KeepAlives

Modifying Global KeepAlive Properties

Global KeepAlive Configuration—ICMP

Global KeepAlive Configuration—TCP

Global KeepAlive Configuration—HTTP HEAD

Global KeepAlive Configuration—KAL-AP

Global KeepAlive Configuration—CRA

Global KeepAlive Configuration—Name Server

Configuring and Modifying Shared VIP KeepAlives

Creating a Shared VIP KeepAlive

Shared KeepAlive Configuration—ICMP

Shared KeepAlive Configuration—TCP

Shared KeepAlive Configuration—HTTP HEAD

Shared KeepAlive Configuration—KAL-AP

Modifying a Shared KeepAlive

Deleting a Shared KeepAlive

Where to Go Next

Configuring KeepAlives

A keepalive is a method by which the GSS periodically checks to see if a resource associated with an answer is still active. All answers are validated by configured keepalives as being either online or offline.

The GSS uses keepalives to collect and track information on everything from the simple online status of VIPs to services and applications running on a server. Depending on the type of answer being tracked, the GSS also monitors load and connection information on SLBs that can be used to perform load-based redirection.

This chapter contains the following major sections:

•Modifying Global KeepAlive Properties

•Configuring and Modifying Shared VIP KeepAlives

Modifying Global KeepAlive Properties

The GSS includes a set of global keepalive properties that function as the default or minimum values used by the GSS when no other keepalive values are specified. You can modify your global keepalive properties for the GSS using the fields on the Global KeepAlive Properties details page from the Resources tab. Changing a global keepalive property and applying that change is immediate and it modifies the default values of keepalives currently in use by the GSS. For example, if a VIP answer uses a TCP keepalive with all of its associated defaults, and you change the default port value from port 80 to port 23, port 23 automatically becomes the default for the TCP keepalive.

Note Changing global keepalive properties is an optional process.

To modify the GSS keepalive properties:

1. From the primary GSSM GUI, click the Resources tab.

2. Click the KeepAlive Properties navigation link. The Configure Global KeepAlive Properties details page appears (Figure 6-1).

Figure 6-1 Configure Global KeepAlive Properties Details Page

3. Use the navigation links on the left side of the page to access the individual GSS global keepalive details page and to modify the global properties of the keepalive.

The following procedures describe how to modify the default properties for the individual global keepalives.

–Global KeepAlive Configuration—ICMP

–Global KeepAlive Configuration—TCP

–Global KeepAlive Configuration—HTTP HEAD

–Global KeepAlive Configuration—KAL-AP

–Global KeepAlive Configuration—CRA

–Global KeepAlive Configuration—Name Server

Global KeepAlive Configuration—ICMP

To modify the ICMP global keepalive configuration settings, see Figure 6-2 and Figure 6-3 and perform the following steps.

Figure 6-2 ICMP Global KeepAlive—Standard KAL Type

Figure 6-3 ICMP Global KeepAlive—Fast KAL Type

1. Select the ICMP keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast ICMP keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline.

– Standard—Uses the default detection time of 60 seconds.

– Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 4 seconds.

Note The GSS supports up to 500 ICMP keepalives when using the standard detection method and up to 100 ICMP keepalives when using the fast detection method.

2. If you selected the Standard KAL Type, in the Minimum Interval field change the minimum frequency with which the GSS attempts to schedule ICMP keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds.

3. If you selected the Fast KAL Type, modify the following parameters:

–In the Number of Retries field, specify the number of times the GSS retransmits an ICMP echo request packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1.

–In the Number of Successful Probes field, specify the number of consecutive successful ICMP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

4. Click the Submit button to save your ICMP global keepalive modifications.

Global KeepAlive Configuration—TCP

To modify the TCP global keepalive global configuration settings, see Figure 6-4 and Figure 6-5 and perform the following steps:

Figure 6-4 TCP Global KeepAlive—Standard KAL Type

Figure 6-5 TCP Global KeepAlive—Fast KAL Type

1. Select the TCP keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast TCP keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline.

– Standard—Uses the default detection time of 60 seconds.

– Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 4 seconds.

Note The GSS supports up to 500 TCP keepalives when using the standard detection method and up to 100 TCP keepalives when using the fast detection method.

2. In the Destination port field, enter the port on the remote device that is to receive the TCP keepalive request from the GSS. The port range is 1 to 65535. The default port is 80.

3. Specify the TCP keepalive connection termination method:

–Reset—The GSS immediately terminates the TCP connection by using a hard reset. This is the default termination method.

–Graceful—The GSS initiates the graceful closing of a TCP connection by using the standard three-way connection termination method.

4. If you selected the Standard KAL Type, specify the following parameters:

–In the Response Timeout field, specify the length of time allowed before the GSS re-transmits data to a device that is not responding to a request. The valid entries are 20 to 60 seconds. The default is 20 seconds.

–In the Minimum Interval field, specify the minimum frequency with which the GSS attempts to schedule TCP keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds.

5. If you selected the Fast KAL Type, modify the following parameters:

–In the Number of Retries field, specify the number of times the GSS retransmits a TCP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1.

Note When using the Graceful termination sequence, there are two packets that require acknowledgement: SYN and FIN.

–In the Number of Successful Probes field, specify the number of consecutive successful TCP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

6. Click the Submit button to save your TCP global keepalive modifications.

Global KeepAlive Configuration—HTTP HEAD

To modify the HTTP HEAD keepalive global configuration settings, see Figure 6-6 and Figure 6-7 and perform the following steps:

Figure 6-6 HTTP HEAD Global KeepAlive—Standard KAL Type

Figure 6-7 HTTP HEAD Global KeepAlive—Fast KAL Type

1. Select the HTTP HEAD keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast HTTP HEAD keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline.

– Standard—Uses the default detection time of 60 seconds.

– Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 8 seconds.

Note The GSS supports up to 500 HTTP HEAD keepalives when using the standard detection method and up to 100 HTTP HEAD keepalives when using the fast detection method.

2. In the Destination port field, enter the port on the remote device that is to receive the HTTP HEAD-type keepalive request from the GSS. The port range is 1 to 65535. The default port is 80.

3. In the Path field, enter the default path that is relative to the server website being queried in the HTTP HEAD request. For example: /company/owner

4. Specify the HTTP HEAD keepalive connection termination method:

–Reset—The GSS immediately terminates the HTTP HEAD connection by using a hard reset. This is the default termination method.

–Graceful—The GSS initiates the graceful closing of a HTTP HEAD connection by using the standard three-way connection termination method.

5. If you selected the Standard KAL Type, specify the following parameters:

–In the Response Timeout field, change the length of time allowed before the GSS retransmits data to a device that is not responding to a request. The valid entries are 20 to 60 seconds. The default is 20 seconds.

–In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule HTTP HEAD keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds.

6. If you selected the Fast KAL Type, specify the following parameters:

–In the Number of Retries field, specify the number of times the GSS retransmits an HTTP HEAD packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1.

Note When using the Graceful termination sequence, there are three packets that require acknowledgement: SYN, HEAD, and FIN.

–In the Number of Successful Probes field, specify the number of consecutive successful HTTP HEAD keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

7. Click the Submit button to save your HTTP HEAD global keepalive modifications.

Global KeepAlive Configuration—KAL-AP

To modify the KAL-AP keepalive global configuration setting, see Figure 6-8 and Figure 6-9 and perform the following steps:

Figure 6-8 KAL-AP Global KeepAlive—Standard KAL Type

Figure 6-9 KAL-AP Global KeepAlive—Fast KAL Type

1. Select the KAL-AP keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast KAL-AP keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline.

– Standard—Uses the default detection time of 60 seconds.

– Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 4 seconds.

Note The GSS supports up to 128 primary and 128 secondary KAL-AP keepalives when using the standard detection method and up to 40 primary and 40 secondary KAL-AP keepalives when using the fast detection method.

2. If you intend to use Content and Application Peering Protocol (CAPP) encryption, in the CAPP Hash Secret field enter an alphanumeric encryption key value. This is the alphanumeric value used to encrypt interbox communications using CAPP. The same encryption value must also be configured on the Cisco CSS or CSM. The default CAPP Hash Secret string is hash-not-set.

3. If you selected the Standard KAL Type, in the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule KAL-AP By Tag or KAL-AP By VIP keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds.

4. If you selected the Fast KAL Type, specify the following parameters:

–In the Number of Retries field, specify the number of times the GSS retransmits an KAL-AP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1.

–In the Number of Successful Probes field, specify the number of consecutive successful KAL-AP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

5. Click the Submit button to save your KAL-AP global keepalive modifications.

Global KeepAlive Configuration—CRA

To modify the CRA keepalive global configuration settings, see Figure 6-10 and perform the following steps:

Figure 6-10 Global KeepAlives Details Page—CRA KeepAlive

1. In the Timing Decay field, change the value to specify how heavily the GSS should weigh recent DNS Round Trip Time (RTT) probe results relative to earlier RTT metrics, with 1 indicating that recent results should not be weighed any more than previous RTT results. The valid entries are 1 to 10. The default is 2.

2. In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule CRA-type keepalives. The valid entries are 1 to 60 seconds. The default is 10 seconds.

3. Click the Submit button to save your CRA global keepalive modifications.

Global KeepAlive Configuration—Name Server

To modify the Name Server keepalive global configuration settings, see Figure 6-11 and perform the following steps:

Figure 6-11 Global KeepAlives Details Page—Name Server KeepAlive

1. In the Query Domain field, change the globally defined domain name that is used to query when utilizing the name server (NS) keepalive. The default is ".".

2. In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule name server query keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds.

3. Click the Submit button to save your Name Server global keepalive modifications.

Configuring and Modifying Shared VIP KeepAlives

The GSS supports the use of shared keepalives to minimize traffic between the GSS and the SLBs that it is monitoring. A shared keepalive identifies a common address or resource that can provide status for multiple answers. Shared keepalives are used to periodically provide state information (online, offline) to the GSS for multiple VIP answer types. Once created, you can associated the shared keepalives with VIPs when you create a VIP answer type.

Note Shared keepalives are not used with name server or CRA answers.

All answers are validated by configured keepalives and are not returned if the keepalive indicates that the answer is not viable. If a shared keepalive fails to return a status, all VIPs associated with that shared keepalive are assumed to be offline.

If you intend to use the KAL-AP keepalive method with a VIP answer you must configure a shared keepalive. The use of shared keepalives are an option for the ICMP, TCP, and HTTP HEAD keepalive types.

This section includes the following procedures:

•Creating a Shared VIP KeepAlive

•Modifying a Shared KeepAlive

•Deleting a Shared KeepAlive

Creating a Shared VIP KeepAlive

To create a shared VIP keepalive:

1. From the primary GSSM GUI, click the DNS Rules tab.

2. Click the Shared KeepAlives navigation link. The Shared KeepAlives list page appears listing all existing shared keepalives (Figure 6-12).

Figure 6-12 Shared KeepAlives Lists Page

3. Click the Create Shared KeepAlive icon. The Creating New Shared KeepAlives details page appears (Figure 6-13).

Figure 6-13 Creating New Shared KeepAlives Details Page

4. At the Type section at the top of the page, choose from one of the four keepalive types as the shared VIP keepalive:

– ICMP—Sends an ICMP echo message (ping) to the specified address. Online status is determined by the response received from the device, indicating simple connectivity to the network.

– TCP—Sends a TCP handshake to the specified IP address and port number of the remote device to determine service viability (three-way handshake and connection termination method), returning the online status of the device.

– HTTP-Head—Sends a TCP format HTTP HEAD request to an origin web server at a specified address. Online status of the device is determined in the form of an HTTP Response Status Code of 200 (for example, HTTP/1.0 200 OK) from the server as well as information on the web page status and content size.

– KAL-AP—Sends a detailed query to the Cisco CSS or CSM to extract load and availability. Online status is determined when these SLBs respond with information about a hosted domain name, host VIP address, or a configured tag on a content rule.

The following procedures describe how to configure the properties for the individual VIP shared keepalives. The default values used for each VIP keepalive is determined by the values specified in the Global Keepalive Properties details page.

–Shared KeepAlive Configuration—ICMP

–Shared KeepAlive Configuration—TCP

–Shared KeepAlive Configuration—HTTP HEAD

–Shared KeepAlive Configuration—KAL-AP

Shared KeepAlive Configuration—ICMP

To define the ICMP shared keepalive configuration, see Figure 6-14 and perform the following steps:

Figure 6-14 Shared KeepAlives Details Page—ICMP KeepAlive (Fast KAL Type)

1. Enter the IP address used to test the online status for the linked VIPs.

2. If the ICMP global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section:

–In the Number of Retries field, specify the number of times the GSS retransmits an ICMP echo request packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value.

–In the Number of Successful Probes field, specify the number of consecutive successful ICMP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

3. Click the Submit button to save your ICMP shared keepalive configuration. You return to the Shared KeepAlives list page.

Shared KeepAlive Configuration—TCP

To define the TCP shared keepalive configuration, refer to Figure 6-15 and perform the procedure outlined below.

Figure 6-15 Shared KeepAlives Details Page—TCP KeepAlive (Fast KAL Type)

1. Enter the IP address used to test the online status for the linked VIPs.

2. In the Destination port field enter the port on the remote device that is to receive the TCP keepalive request. The port range is 1 to 65535. If you do not specify a destination port, the GSS uses the globally configured value.

3. Specify the TCP keepalive connection termination method:

– Default—Always use the globally defined TCP keepalive connection method.

–Reset—The GSS immediately terminates the TCP connection by using a hard reset.

–Graceful—The GSS initiates the graceful closing of a TCP connection by using the standard three-way connection termination method.

4. If the TCP global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section:

–In the Number of Retries field, specify the number of times the GSS retransmits a TCP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value.

Note When using the Graceful termination sequence, there are two packets that require acknowledgement: SYN and FIN.

–In the Number of Successful Probes field, specify the number of consecutive successful TCP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

5. Click the Submit button to save your TCP shared keepalive configuration. You return to the Shared KeepAlives list page.

Shared KeepAlive Configuration—HTTP HEAD

To define the HTTP HEAD shared keepalive configuration, see Figure 6-16 and perform the following steps:

Figure 6-16 Shared KeepAlives Details Page—HTTP HEAD KeepAlive (Fast KAL Type)

1. Enter the IP address used to test the online status for the linked VIPs.

2. In the Destination port field enter the port on the remote device that receives the HTTP HEAD-type keepalive request from the GSS. The port range is 1 to 65535. If you do not specify a destination port, the GSS uses the globally configured value.

3. In the Host Tag field, enter an optional domain name that is sent to the VIP as part of the HTTP HEAD query in the Host tag field. This tag allows an SLB to resolve the keepalive request to a particular website even when multiple sites are represented by the same VIP.

4. In the Path feld, enter the default path that is relative to the server website being queried in the HTTP HEAD request. If you do not specify a default path, the GSS uses the globally configured value. For example: /company/owner

5. Specify the HTTP HEAD keepalive connection termination method:

– Default—Always use the globally defined HTTP HEAD keepalive connection method.

–Reset—The GSS immediately terminates the TCP formatted HTTP HEAD connection by using a hard reset.

–Graceful—The GSS initiates the graceful closing of a TCP formatted HTTP HEAD connection by using the standard three-way connection termination method.

6. If the HTTP-HEAD global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section:

–In the Number of Retries field, specify the number of times the GSS retransmits an HTTP HEAD packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value.

Note When using the Graceful termination sequence, there are three packets that require acknowledgement: SYN, HEAD, and FIN.

–In the Number of Successful Probes field, specify the number of consecutive successful HTTP HEAD keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

7. Click the Submit button to save your HTTP HEAD shared keepalive configuration. You return to the Shared KeepAlives list page.

Shared KeepAlive Configuration—KAL-AP

To define the KAL-AP shared keepalive configuration, see Figure 6-17 and perform the following steps:

Figure 6-17 Shared KeepAlives Details Page—KAL-AP KeepAlive (Fast KAL Type)

1. Enter the primary (master) and secondary (backup) IP addresses that will be tested for online status in the fields provided. The secondary IP address is optional. The purpose of the secondary IP address is to query a second Cisco CSS or CSM in a virtual IP (VIP) redundancy and virtual interface redundancy configuration.

2. If you intend to use Content and Application Peering Protocol (CAPP) encryption, check the CAPP Secure box and enter an alphanumeric encryption key value in the CAPP Hash Secret field. This is the alphanumeric value used to encrypt interbox communications using CAPP. The same encryption value must also be configured on the Cisco CSS or CSM.

3. If the KAL-AP global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section:

–In the Number of Retries field, specify the number of times the GSS retransmits an KAL-AP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value.

–In the Number of Successful Probes field, specify the number of consecutive successful KAL-AP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.

Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section.

4. Click Submit to create the new shared keepalive. You return to the Shared KeepAlives list page.

Modifying a Shared KeepAlive

To modify an existing shared keepalive:

1. From the primary GSSM GUI, click the DNS Rules tab.

2. Click the Shared KeepAlives navigation link. The Shared KeepAlives list page appears (see Figure 6-12).

3. Click the Modify Shared KeepAlive icon located to the left of the shared keepalive you want to modify. The Modify Shared KeepAlive details page appears (Figure 6-18).

Figure 6-18 Modifying Shared KeepAlive Details Page

4. Use the fields provided to modify the shared keepalive configuration.

5. Click Submit to save your configuration changes. You return to the Shared KeepAlive list page.

Deleting a Shared KeepAlive

To delete a shared keepalive from your GSS network, and that shared keepalive is in use by the GSS, you must first disassociate any answers that are using the keepalive. Use the procedure that follows to disassociate your answers and remove a shared keepalive from your GSS network.

Caution Deletions of any kind cannot be undone in the primary GSSM. If you might want to use the deleted data at a later point in time, we recommend performing a database backup of your GSSM. Refer to Chapter 9, GSS Administration and Troubleshooting for details.

To delete a shared keepalive:

1. From the primary GSSM GUI, click the DNS Rules tab.

2. Click the Shared KeepAlives navigation link. The Shared KeepAlives lists page appears listing all existing shared keepAlives.

3. Click the Modify Shared KeepAlive icon located to the left of the shared keepalive you want to remove. The Modifying Shared KeepAlive details page appears.

4. If the shared keepalive is associated with an answer, perform one of the following:

– To disassociate all answers from the selected shared keepalive and set the keepalive type of each of those answers to ICMP using the answer's own VIP, click the Set Answers KAL ICMP icon in the upper right corner of the page.

– To disassociate all answers from the selected shared keepalive and set the keepalive type of each of those answers to none, meaning that the GSS assumes they are always alive, click the Set Answers KAL None icon in the upper right corner of the page.

The GSS software prompts you to confirm your decision to disassociate all the answers from the existing shared keepalive.

5. Click the Delete button in the upper right corner of the page. The GSS software prompts you to confirm your decision to delete the shared keepalive.

6. Click OK to confirm your decision. You return to the Shared KeepAlives lists page.

Where to Go Next

Chapter 7, Configuring Answers and Answer Groups, provides you with all the information you need to create and configure GSS answers and answer groups, which are resources that respond to DNS queries.

	Cisco GSS Configuration Guide (Software Version 1.1)
	Configuring KeepAlives
Cisco GSS Configuration Guide (Software Version 1.1) Index Preface Introducing the Global Site Selector Setting Up Your GSS Configuring Resources Configuring Source Address Lists Configuring Domain Lists Configuring KeepAlives Configuring Answers and Answer Groups Building and Modifying DNS Rules GSS Administration and Troubleshooting Monitoring GSS Performance Glossary	Download this chapter Configuring KeepAlives Download the complete book Cisco Global Site Selector Configuration Guide Book-Length PDF, Software Version 1.1 (PDF - 5 MB) Table Of Contents Configuring KeepAlives Modifying Global KeepAlive Properties Global KeepAlive Configuration—ICMP Global KeepAlive Configuration—TCP Global KeepAlive Configuration—HTTP HEAD Global KeepAlive Configuration—KAL-AP Global KeepAlive Configuration—CRA Global KeepAlive Configuration—Name Server Configuring and Modifying Shared VIP KeepAlives Creating a Shared VIP KeepAlive Shared KeepAlive Configuration—ICMP Shared KeepAlive Configuration—TCP Shared KeepAlive Configuration—HTTP HEAD Shared KeepAlive Configuration—KAL-AP Modifying a Shared KeepAlive Deleting a Shared KeepAlive Where to Go Next Configuring KeepAlives A keepalive is a method by which the GSS periodically checks to see if a resource associated with an answer is still active. All answers are validated by configured keepalives as being either online or offline. The GSS uses keepalives to collect and track information on everything from the simple online status of VIPs to services and applications running on a server. Depending on the type of answer being tracked, the GSS also monitors load and connection information on SLBs that can be used to perform load-based redirection. This chapter contains the following major sections: •Modifying Global KeepAlive Properties •Configuring and Modifying Shared VIP KeepAlives Modifying Global KeepAlive Properties The GSS includes a set of global keepalive properties that function as the default or minimum values used by the GSS when no other keepalive values are specified. You can modify your global keepalive properties for the GSS using the fields on the Global KeepAlive Properties details page from the Resources tab. Changing a global keepalive property and applying that change is immediate and it modifies the default values of keepalives currently in use by the GSS. For example, if a VIP answer uses a TCP keepalive with all of its associated defaults, and you change the default port value from port 80 to port 23, port 23 automatically becomes the default for the TCP keepalive. Note Changing global keepalive properties is an optional process. To modify the GSS keepalive properties: 1. From the primary GSSM GUI, click the Resources tab. 2. Click the KeepAlive Properties navigation link. The Configure Global KeepAlive Properties details page appears (Figure 6-1). Figure 6-1 Configure Global KeepAlive Properties Details Page 3. Use the navigation links on the left side of the page to access the individual GSS global keepalive details page and to modify the global properties of the keepalive. The following procedures describe how to modify the default properties for the individual global keepalives. –Global KeepAlive Configuration—ICMP –Global KeepAlive Configuration—TCP –Global KeepAlive Configuration—HTTP HEAD –Global KeepAlive Configuration—KAL-AP –Global KeepAlive Configuration—CRA –Global KeepAlive Configuration—Name Server Global KeepAlive Configuration—ICMP To modify the ICMP global keepalive configuration settings, see Figure 6-2 and Figure 6-3 and perform the following steps. Figure 6-2 ICMP Global KeepAlive—Standard KAL Type Figure 6-3 ICMP Global KeepAlive—Fast KAL Type 1. Select the ICMP keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast ICMP keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline. – Standard—Uses the default detection time of 60 seconds. – Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 4 seconds. Note The GSS supports up to 500 ICMP keepalives when using the standard detection method and up to 100 ICMP keepalives when using the fast detection method. 2. If you selected the Standard KAL Type, in the Minimum Interval field change the minimum frequency with which the GSS attempts to schedule ICMP keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds. 3. If you selected the Fast KAL Type, modify the following parameters: –In the Number of Retries field, specify the number of times the GSS retransmits an ICMP echo request packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1. –In the Number of Successful Probes field, specify the number of consecutive successful ICMP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 4. Click the Submit button to save your ICMP global keepalive modifications. Global KeepAlive Configuration—TCP To modify the TCP global keepalive global configuration settings, see Figure 6-4 and Figure 6-5 and perform the following steps: Figure 6-4 TCP Global KeepAlive—Standard KAL Type Figure 6-5 TCP Global KeepAlive—Fast KAL Type 1. Select the TCP keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast TCP keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline. – Standard—Uses the default detection time of 60 seconds. – Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 4 seconds. Note The GSS supports up to 500 TCP keepalives when using the standard detection method and up to 100 TCP keepalives when using the fast detection method. 2. In the Destination port field, enter the port on the remote device that is to receive the TCP keepalive request from the GSS. The port range is 1 to 65535. The default port is 80. 3. Specify the TCP keepalive connection termination method: –Reset—The GSS immediately terminates the TCP connection by using a hard reset. This is the default termination method. –Graceful—The GSS initiates the graceful closing of a TCP connection by using the standard three-way connection termination method. 4. If you selected the Standard KAL Type, specify the following parameters: –In the Response Timeout field, specify the length of time allowed before the GSS re-transmits data to a device that is not responding to a request. The valid entries are 20 to 60 seconds. The default is 20 seconds. –In the Minimum Interval field, specify the minimum frequency with which the GSS attempts to schedule TCP keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds. 5. If you selected the Fast KAL Type, modify the following parameters: –In the Number of Retries field, specify the number of times the GSS retransmits a TCP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1. Note When using the Graceful termination sequence, there are two packets that require acknowledgement: SYN and FIN. –In the Number of Successful Probes field, specify the number of consecutive successful TCP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 6. Click the Submit button to save your TCP global keepalive modifications. Global KeepAlive Configuration—HTTP HEAD To modify the HTTP HEAD keepalive global configuration settings, see Figure 6-6 and Figure 6-7 and perform the following steps: Figure 6-6 HTTP HEAD Global KeepAlive—Standard KAL Type Figure 6-7 HTTP HEAD Global KeepAlive—Fast KAL Type 1. Select the HTTP HEAD keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast HTTP HEAD keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline. – Standard—Uses the default detection time of 60 seconds. – Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 8 seconds. Note The GSS supports up to 500 HTTP HEAD keepalives when using the standard detection method and up to 100 HTTP HEAD keepalives when using the fast detection method. 2. In the Destination port field, enter the port on the remote device that is to receive the HTTP HEAD-type keepalive request from the GSS. The port range is 1 to 65535. The default port is 80. 3. In the Path field, enter the default path that is relative to the server website being queried in the HTTP HEAD request. For example: `/company/owner` 4. Specify the HTTP HEAD keepalive connection termination method: –Reset—The GSS immediately terminates the HTTP HEAD connection by using a hard reset. This is the default termination method. –Graceful—The GSS initiates the graceful closing of a HTTP HEAD connection by using the standard three-way connection termination method. 5. If you selected the Standard KAL Type, specify the following parameters: –In the Response Timeout field, change the length of time allowed before the GSS retransmits data to a device that is not responding to a request. The valid entries are 20 to 60 seconds. The default is 20 seconds. –In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule HTTP HEAD keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds. 6. If you selected the Fast KAL Type, specify the following parameters: –In the Number of Retries field, specify the number of times the GSS retransmits an HTTP HEAD packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1. Note When using the Graceful termination sequence, there are three packets that require acknowledgement: SYN, HEAD, and FIN. –In the Number of Successful Probes field, specify the number of consecutive successful HTTP HEAD keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 7. Click the Submit button to save your HTTP HEAD global keepalive modifications. Global KeepAlive Configuration—KAL-AP To modify the KAL-AP keepalive global configuration setting, see Figure 6-8 and Figure 6-9 and perform the following steps: Figure 6-8 KAL-AP Global KeepAlive—Standard KAL Type Figure 6-9 KAL-AP Global KeepAlive—Fast KAL Type 1. Select the KAL-AP keepalive rate by clicking one of the KAL Type option buttons. You can specify whether the GSS is to use the standard or fast KAL-AP keepalive transmission rate. The failure detection time, as it relates to the GSS, is the amount of time between when a device failure occurs and when the GSS determines the failure occurred. This is the longest period of time the GSS will take to mark an answer offline. – Standard—Uses the default detection time of 60 seconds. – Fast—Uses the user-selectable Number of Retries parameter to control the keepalive transmission rate. The default detection time is 4 seconds. Note The GSS supports up to 128 primary and 128 secondary KAL-AP keepalives when using the standard detection method and up to 40 primary and 40 secondary KAL-AP keepalives when using the fast detection method. 2. If you intend to use Content and Application Peering Protocol (CAPP) encryption, in the CAPP Hash Secret field enter an alphanumeric encryption key value. This is the alphanumeric value used to encrypt interbox communications using CAPP. The same encryption value must also be configured on the Cisco CSS or CSM. The default CAPP Hash Secret string is hash-not-set. 3. If you selected the Standard KAL Type, in the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule KAL-AP By Tag or KAL-AP By VIP keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds. 4. If you selected the Fast KAL Type, specify the following parameters: –In the Number of Retries field, specify the number of times the GSS retransmits an KAL-AP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. The default is 1. –In the Number of Successful Probes field, specify the number of consecutive successful KAL-AP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. The default is 1. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 5. Click the Submit button to save your KAL-AP global keepalive modifications. Global KeepAlive Configuration—CRA To modify the CRA keepalive global configuration settings, see Figure 6-10 and perform the following steps: Figure 6-10 Global KeepAlives Details Page—CRA KeepAlive 1. In the Timing Decay field, change the value to specify how heavily the GSS should weigh recent DNS Round Trip Time (RTT) probe results relative to earlier RTT metrics, with 1 indicating that recent results should not be weighed any more than previous RTT results. The valid entries are 1 to 10. The default is 2. 2. In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule CRA-type keepalives. The valid entries are 1 to 60 seconds. The default is 10 seconds. 3. Click the Submit button to save your CRA global keepalive modifications. Global KeepAlive Configuration—Name Server To modify the Name Server keepalive global configuration settings, see Figure 6-11 and perform the following steps: Figure 6-11 Global KeepAlives Details Page—Name Server KeepAlive 1. In the Query Domain field, change the globally defined domain name that is used to query when utilizing the name server (NS) keepalive. The default is ".". 2. In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule name server query keepalives. The valid entries are 40 to 255 seconds. The default is 40 seconds. 3. Click the Submit button to save your Name Server global keepalive modifications. Configuring and Modifying Shared VIP KeepAlives The GSS supports the use of shared keepalives to minimize traffic between the GSS and the SLBs that it is monitoring. A shared keepalive identifies a common address or resource that can provide status for multiple answers. Shared keepalives are used to periodically provide state information (online, offline) to the GSS for multiple VIP answer types. Once created, you can associated the shared keepalives with VIPs when you create a VIP answer type. Note Shared keepalives are not used with name server or CRA answers. All answers are validated by configured keepalives and are not returned if the keepalive indicates that the answer is not viable. If a shared keepalive fails to return a status, all VIPs associated with that shared keepalive are assumed to be offline. If you intend to use the KAL-AP keepalive method with a VIP answer you must configure a shared keepalive. The use of shared keepalives are an option for the ICMP, TCP, and HTTP HEAD keepalive types. This section includes the following procedures: •Creating a Shared VIP KeepAlive •Modifying a Shared KeepAlive •Deleting a Shared KeepAlive Creating a Shared VIP KeepAlive To create a shared VIP keepalive: 1. From the primary GSSM GUI, click the DNS Rules tab. 2. Click the Shared KeepAlives navigation link. The Shared KeepAlives list page appears listing all existing shared keepalives (Figure 6-12). Figure 6-12 Shared KeepAlives Lists Page 3. Click the Create Shared KeepAlive icon. The Creating New Shared KeepAlives details page appears (Figure 6-13). Figure 6-13 Creating New Shared KeepAlives Details Page 4. At the Type section at the top of the page, choose from one of the four keepalive types as the shared VIP keepalive: – ICMP—Sends an ICMP echo message (ping) to the specified address. Online status is determined by the response received from the device, indicating simple connectivity to the network. – TCP—Sends a TCP handshake to the specified IP address and port number of the remote device to determine service viability (three-way handshake and connection termination method), returning the online status of the device. – HTTP-Head—Sends a TCP format HTTP HEAD request to an origin web server at a specified address. Online status of the device is determined in the form of an HTTP Response Status Code of 200 (for example, HTTP/1.0 200 OK) from the server as well as information on the web page status and content size. – KAL-AP—Sends a detailed query to the Cisco CSS or CSM to extract load and availability. Online status is determined when these SLBs respond with information about a hosted domain name, host VIP address, or a configured tag on a content rule. The following procedures describe how to configure the properties for the individual VIP shared keepalives. The default values used for each VIP keepalive is determined by the values specified in the Global Keepalive Properties details page. –Shared KeepAlive Configuration—ICMP –Shared KeepAlive Configuration—TCP –Shared KeepAlive Configuration—HTTP HEAD –Shared KeepAlive Configuration—KAL-AP Shared KeepAlive Configuration—ICMP To define the ICMP shared keepalive configuration, see Figure 6-14 and perform the following steps: Figure 6-14 Shared KeepAlives Details Page—ICMP KeepAlive (Fast KAL Type) 1. Enter the IP address used to test the online status for the linked VIPs. 2. If the ICMP global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section: –In the Number of Retries field, specify the number of times the GSS retransmits an ICMP echo request packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value. –In the Number of Successful Probes field, specify the number of consecutive successful ICMP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 3. Click the Submit button to save your ICMP shared keepalive configuration. You return to the Shared KeepAlives list page. Shared KeepAlive Configuration—TCP To define the TCP shared keepalive configuration, refer to Figure 6-15 and perform the procedure outlined below. Figure 6-15 Shared KeepAlives Details Page—TCP KeepAlive (Fast KAL Type) 1. Enter the IP address used to test the online status for the linked VIPs. 2. In the Destination port field enter the port on the remote device that is to receive the TCP keepalive request. The port range is 1 to 65535. If you do not specify a destination port, the GSS uses the globally configured value. 3. Specify the TCP keepalive connection termination method: – Default—Always use the globally defined TCP keepalive connection method. –Reset—The GSS immediately terminates the TCP connection by using a hard reset. –Graceful—The GSS initiates the graceful closing of a TCP connection by using the standard three-way connection termination method. 4. If the TCP global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section: –In the Number of Retries field, specify the number of times the GSS retransmits a TCP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value. Note When using the Graceful termination sequence, there are two packets that require acknowledgement: SYN and FIN. –In the Number of Successful Probes field, specify the number of consecutive successful TCP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 5. Click the Submit button to save your TCP shared keepalive configuration. You return to the Shared KeepAlives list page. Shared KeepAlive Configuration—HTTP HEAD To define the HTTP HEAD shared keepalive configuration, see Figure 6-16 and perform the following steps: Figure 6-16 Shared KeepAlives Details Page—HTTP HEAD KeepAlive (Fast KAL Type) 1. Enter the IP address used to test the online status for the linked VIPs. 2. In the Destination port field enter the port on the remote device that receives the HTTP HEAD-type keepalive request from the GSS. The port range is 1 to 65535. If you do not specify a destination port, the GSS uses the globally configured value. 3. In the Host Tag field, enter an optional domain name that is sent to the VIP as part of the HTTP HEAD query in the Host tag field. This tag allows an SLB to resolve the keepalive request to a particular website even when multiple sites are represented by the same VIP. 4. In the Path feld, enter the default path that is relative to the server website being queried in the HTTP HEAD request. If you do not specify a default path, the GSS uses the globally configured value. For example: `/company/owner` 5. Specify the HTTP HEAD keepalive connection termination method: – Default—Always use the globally defined HTTP HEAD keepalive connection method. –Reset—The GSS immediately terminates the TCP formatted HTTP HEAD connection by using a hard reset. –Graceful—The GSS initiates the graceful closing of a TCP formatted HTTP HEAD connection by using the standard three-way connection termination method. 6. If the HTTP-HEAD global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section: –In the Number of Retries field, specify the number of times the GSS retransmits an HTTP HEAD packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value. Note When using the Graceful termination sequence, there are three packets that require acknowledgement: SYN, HEAD, and FIN. –In the Number of Successful Probes field, specify the number of consecutive successful HTTP HEAD keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 7. Click the Submit button to save your HTTP HEAD shared keepalive configuration. You return to the Shared KeepAlives list page. Shared KeepAlive Configuration—KAL-AP To define the KAL-AP shared keepalive configuration, see Figure 6-17 and perform the following steps: Figure 6-17 Shared KeepAlives Details Page—KAL-AP KeepAlive (Fast KAL Type) 1. Enter the primary (master) and secondary (backup) IP addresses that will be tested for online status in the fields provided. The secondary IP address is optional. The purpose of the secondary IP address is to query a second Cisco CSS or CSM in a virtual IP (VIP) redundancy and virtual interface redundancy configuration. 2. If you intend to use Content and Application Peering Protocol (CAPP) encryption, check the CAPP Secure box and enter an alphanumeric encryption key value in the CAPP Hash Secret field. This is the alphanumeric value used to encrypt interbox communications using CAPP. The same encryption value must also be configured on the Cisco CSS or CSM. 3. If the KAL-AP global keepalive configuration is set to the Fast KAL Type, specify the following parameters in the Fast Keepalive Settings section: –In the Number of Retries field, specify the number of times the GSS retransmits an KAL-AP packet before declaring the device offline. As you adjust the Number of Retries parameter, you change the detection time determined by the GSS. By increasing the number of retries you increase the detection time. Reducing the number of retries has the reverse effect. The range is 1 to 10 retries. If you do not specify a value, the GSS uses the globally configured value. –In the Number of Successful Probes field, specify the number of consecutive successful KAL-AP keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The range is 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value. Note For background details on keepalive detection time, refer to Chapter 1, Introducing the Global Site Selector, the "Keepalives" section. 4. Click Submit to create the new shared keepalive. You return to the Shared KeepAlives list page. Modifying a Shared KeepAlive To modify an existing shared keepalive: 1. From the primary GSSM GUI, click the DNS Rules tab. 2. Click the Shared KeepAlives navigation link. The Shared KeepAlives list page appears (see Figure 6-12). 3. Click the Modify Shared KeepAlive icon located to the left of the shared keepalive you want to modify. The Modify Shared KeepAlive details page appears (Figure 6-18). Figure 6-18 Modifying Shared KeepAlive Details Page 4. Use the fields provided to modify the shared keepalive configuration. 5. Click Submit to save your configuration changes. You return to the Shared KeepAlive list page. Deleting a Shared KeepAlive To delete a shared keepalive from your GSS network, and that shared keepalive is in use by the GSS, you must first disassociate any answers that are using the keepalive. Use the procedure that follows to disassociate your answers and remove a shared keepalive from your GSS network. Caution Deletions of any kind cannot be undone in the primary GSSM. If you might want to use the deleted data at a later point in time, we recommend performing a database backup of your GSSM. Refer to Chapter 9, GSS Administration and Troubleshooting for details. To delete a shared keepalive: 1. From the primary GSSM GUI, click the DNS Rules tab. 2. Click the Shared KeepAlives navigation link. The Shared KeepAlives lists page appears listing all existing shared keepAlives. 3. Click the Modify Shared KeepAlive icon located to the left of the shared keepalive you want to remove. The Modifying Shared KeepAlive details page appears. 4. If the shared keepalive is associated with an answer, perform one of the following: – To disassociate all answers from the selected shared keepalive and set the keepalive type of each of those answers to ICMP using the answer's own VIP, click the Set Answers KAL ICMP icon in the upper right corner of the page. – To disassociate all answers from the selected shared keepalive and set the keepalive type of each of those answers to none, meaning that the GSS assumes they are always alive, click the Set Answers KAL None icon in the upper right corner of the page. The GSS software prompts you to confirm your decision to disassociate all the answers from the existing shared keepalive. 5. Click the Delete button in the upper right corner of the page. The GSS software prompts you to confirm your decision to delete the shared keepalive. 6. Click OK to confirm your decision. You return to the Shared KeepAlives lists page. Where to Go Next Chapter 7, Configuring Answers and Answer Groups, provides you with all the information you need to create and configure GSS answers and answer groups, which are resources that respond to DNS queries.
	© 1992-2009 Cisco Systems, Inc. All rights reserved. Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks of Cisco Systems, Inc.