Table Of Contents
Configuring Keepalives
Modifying Global Keepalive Properties
Modifying ICMP Global Keepalive Settings
Modifying TCP Global Keepalive Settings
Modifying HTTP HEAD Global Keepalive Settings
Modifying KAL-AP Global Keepalive Settings
Modifying Scripted Keepalive Global Keepalive Settings
Modifying CRA Global Keepalive Settings
Modifying Name Server Global Keepalive Settings
Configuring and Modifying Shared VIP Keepalives
Creating a Shared VIP Keepalive
Configuring ICMP Shared Keepalive Configuration Settings
Configuring TCP Shared Keepalive Configuration Settings
Configuring HTTP HEAD Shared Keepalive Configuration Settings
Configuring KAL-AP Shared Keepalive Configuration Settings
Configuring Scripted Keepalive Shared Keepalive Configuration Settings
Modifying a Shared Keepalive
Deleting a Shared Keepalive
Where to Go Next
Configuring Keepalives
This chapter describes how to configure keepalives on your GSS network. A keepalive is a method by which the GSS periodically checks to see if a resource associated with an answer is still active. The GSS uses keepalives to determine if a resource is 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. You can configure a keepalive to continually monitor the online status of a resource and report that information to the primary GSSM.
Depending on the type of answer being tracked, the GSS also monitors load and connection information on SLBs and then uses this information to perform load-based redirection.
This chapter contains the following major sections:
•
Modifying Global Keepalive Properties
•Configuring and Modifying Shared VIP Keepalives
•Where to Go Next
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. If required, you can modify the global keepalive properties for the GSS using the fields on the Global KeepAlive Properties details page (Resources tab). Changing a global keepalive property and applying that change immediately modifies the default values of the 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. If the GSS is transmitting numerous TCP keepalives using port 23, you should globally change the Number of Retries value for all TCP keepalives on the Configure Global KeepAlive Properties details page.
Note Changing global keepalive properties is an optional process.
To modify the GSS keepalive properties, perform the following steps:
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 5-1).
Figure 5-1 Configure Global KeepAlive Properties Details Page
3. Click 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 section describes how to modify the default properties for the individual global keepalives and contains the following topics:
•Modifying ICMP Global Keepalive Settings
•Modifying TCP Global Keepalive Settings
•Modifying HTTP HEAD Global Keepalive Settings
•Modifying KAL-AP Global Keepalive Settings
•Modifying Scripted Keepalive Global Keepalive Settings
•Modifying CRA Global Keepalive Settings
•Modifying Name Server Global Keepalive Settings
Modifying ICMP Global Keepalive Settings
To modify the ICMP global keepalive configuration settings, perform the following steps:
1. At the KAL Type section at the top of the page (see Figure 5-2), choose either the Standard or Fast ICMP keepalive transmission rate to define the failure detection time for the GSS.
The failure detection time is the amount of time between when a device failure occurs and when the GSS determines the failure occurred and marks the answer offline.
Figure 5-2 ICMP Global KeepAlive—Standard KAL Type
The Standard or Fast KAL-AP keepalive transmission rates are as follows:
•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 750 ICMP keepalives when using the standard detection method and up to 150 ICMP keepalives when using the fast detection method.
2. If you chose the Standard KAL Type (see Figure 5-2), in the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule ICMP keepalives. The valid entries are from 40 to 255 seconds. The default is 40 seconds.
3. If you chose the Fast KAL Type (see Figure 5-3), specify the following parameters:
•In the Number of Retries field, specify the number of times that 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 valid entries are from 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 valid entries are from 1 to 5 probes. The default is 1.
Figure 5-3 ICMP Global KeepAlive—Fast KAL Type
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
4. Click the Submit button to save your ICMP global keepalive modifications.
Modifying TCP Global Keepalive Settings
To modify the TCP global keepalive global configuration settings, perform the following steps:
1. At the KAL Type section at the top of the page (see Figure 5-4), choose either the Standard or Fast TCP keepalive transmission rate to define the failure detection time for the GSS.
The failure detection time is the amount of time between when a device failure occurs and when the GSS determines the failure occurred and marks the answer offline.
Figure 5-4 TCP Global KeepAlive—Standard KAL Type
The Standard or Fast KAL-AP keepalive transmission rates are as follows:
•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 1500 TCP keepalives when using the standard detection method and up to 150 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 from 1 to 65535. The default port is 80.
3. From the Connection Termination Method drop-down list, specify one of the following TCP keepalive connection termination methods:
•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 chose the Standard KAL Type (see Figure 5-4), specify the following parameters:
•In the Response Timeout field, specify the length of time allowed before the GSS retransmits data to a device that is not responding to a request. The valid entries are from 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 the TCP keepalives. The valid entries are from 40 to 255 seconds. The default is 40 seconds.
5. If you chose the Fast KAL Type (see Figure 5-5), modify the following parameters:
•In the Number of Retries field, specify the number of times that 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 valid entries are from 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 valid entries are from 1 to 5 probes. The default is 1.
Figure 5-5 TCP Global KeepAlive—Fast KAL Type
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
6. Click the Submit button to save your TCP global keepalive modifications.
Modifying HTTP HEAD Global Keepalive Settings
To modify the HTTP HEAD keepalive global configuration settings, perform the following steps:
1. At the KAL Type section at the top of the page (see Figure 5-6), choose either the Standard or Fast HTTP HEAD keepalive transmission rate to define the failure detection time for the GSS.
The failure detection time is the amount of time between when a device failure occurs and when the GSS determines the failure occurred and marks the answer offline.
Figure 5-6 HTTP HEAD Global KeepAlive—Standard KAL Type
The Standard or Fast KAL-AP keepalive transmission rates are as follows:
•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 from 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. From the Connection Termination method drop-down list, specify one of these HTTP HEAD keepalive connection termination methods:
•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.
Caution When using the graceful termination method and the server packets arrive at the GSS out of order (for example, the FIN packets arrive before the HTTP data), the GSS does not buffer or acknowledge receipt of the out-of-order packets and drops them. If the server does not retransmit the unacknowledged packets, the HTTP HEAD keepalive may place the answer in an offline state.
5. If you chose the Standard KAL Type (see Figure 5-6), 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 from 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 the HTTP HEAD keepalives. The valid entries are from 40 to 255 seconds. The default is 40 seconds.
6. If you chose the Fast KAL Type (see Figure 5-7), specify the following parameters:
•In the Number of Retries field, specify the number of times that 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 valid entries are from 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 valid entries are from 1 to 5 probes. The default is 1.
Figure 5-7 HTTP HEAD Global KeepAlive—Fast KAL Type
Note For more information on keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
7. Click the Submit button to save your HTTP HEAD global keepalive modifications.
Modifying KAL-AP Global Keepalive Settings
To modify the KAL-AP keepalive global configuration setting, perform the following steps:
1. At the KAL Type section at the top of the page (see Figure 5-8), choose either the Standard or Fast KAL-AP keepalive transmission rate to define the failure detection time for the GSS.
The failure detection time is the amount of time between when a device failure occurs and when the GSS determines the failure occurred and marks the answer offline.
Figure 5-8 KAL-AP Global KeepAlive—Standard KAL Type
The Standard or Fast KAL-AP keepalive transmission rates are as follows:
•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 alphanumeric value is used to encrypt interbox communications using CAPP. You must also configure the same encryption value on the Cisco CSS or CSM. The default CAPP Hash Secret string is hash-not-set.
3. If you chose the Standard KAL Type (see Figure 5-8), 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 from 40 to 255 seconds. The default is 40 seconds.
4. If you chose the Fast KAL Type (see Figure 5-9), specify the following parameters:
•In the Number of Retries field, specify the number of times that 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 valid entries are from 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 valid entries are from 1 to 5 probes. The default is 1.
Figure 5-9 KAL-AP Global KeepAlive—Fast KAL Type
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
5. Click the Submit button to save your KAL-AP global keepalive modifications.
Modifying Scripted Keepalive Global Keepalive Settings
To modify the Scripted keepalive global keepalive configuration settings, perform the following steps:
1. At the KAL Type section at the top of the page (see Figure 5-10), choose either the Standard or Fast Scripted keepalive transmission rate to define the failure detection time for the GSS.
The failure detection time is the amount of time between when a device failure occurs and when the GSS determines the failure occurred and marks the answer offline.
Figure 5-10 Scripted KAL Global KeepAlive—Standard KAL Type
The Standard or Fast Scripted keepalive transmission rates are as follows:
•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 24 seconds.
Note In the standard detection method, the GSS supports 256 Scripted keepalives if the Scripted keepalive is scalar and 128 if it is non-scalar. In the fast detection method, the GSS supports 60 Scripted keepalives if the Scripted keepalive is scalar and 30 if it is non-scalar.
2. If you chose the Standard KAL Type (see Figure 5-10), in the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule Scripted keepalives. The valid entries are from 40 to 255 seconds. The default is 40 seconds.
3. If you chose the Fast KAL Type (see Figure 5-11), specify the following parameters:
•In the Number of Retries field, specify the number of times that the GSS retransmits a Scripted keepalive 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 valid entries are from 1 to 5 retries. The default is 1.
•In the Number of Successful Probes field, specify the number of consecutive successful Scripted keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The valid entries are from 1 to 5 probes. The default is 1.
Figure 5-11 Scripted KAL Global KeepAlive—Fast KAL Type
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
4. Click the Submit button to save your Scripted keepalive global keepalive modifications.
Modifying CRA Global Keepalive Settings
To modify the Content Routing Agent (CRA) keepalive global configuration settings, perform the following steps:
1. In the Timing Decay field (see Figure 5-12), 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 from 1 to 10. The default is 2.
Figure 5-12 Global KeepAlives Details Page—CRA KeepAlive
2. In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule the CRA-type keepalives. The valid entries are from 1 to 60 seconds. The default is 10 seconds.
3. Click the Submit button to save your CRA global keepalive modifications.
Modifying Name Server Global Keepalive Settings
To modify the Name Server keepalive global configuration settings, perform the following steps:
1. In the Query Domain field (see Figure 5-13), change the globally defined domain name that is used to query when utilizing the name server (NS) keepalive. The default is ".".
Figure 5-13 Global KeepAlives Details Page—Name Server KeepAlive
2. In the Minimum Interval field, change the minimum frequency with which the GSS attempts to schedule the name server query keepalives. The valid entries are from 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 IP address or resource that provides the status for multiple answers. Shared keepalives periodically provide state information (online, offline) to the GSS for multiple VIP answer types. Once created, you can associate 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, the GSS assumes that all VIPs associated with that shared keepalive are 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 contains the following topics:
•Creating a Shared VIP Keepalive
•Configuring Scripted Keepalive Shared Keepalive Configuration Settings
•Deleting a Shared Keepalive
Creating a Shared VIP Keepalive
To create a shared VIP keepalive, perform the following steps:
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 (see Figure 5-14).
Figure 5-14 Shared KeepAlives Lists Page
3. Click the Create Shared KeepAlive icon. The Creating New Shared KeepAlives details page appears (see Figure 5-15).
Figure 5-15 Creating New Shared KeepAlives Details Page
4. At the Type section at the top of the page, choose from one of the five keepalive types as the shared VIP keepalive:
•ICMP—Sends an ICMP echo message (ping) to the specified address. The online status is determined by the response received from the device and indicates 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), and returns the online status of the device.
•HTTP-Head—Sends a TCP format HTTP HEAD request to an origin web server at a specified address. The 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. The 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.
•Scripted Kal—Sends a detailed query that allows the GSS to use third-party applications to fetch load information from target devices.
This section describes how to configure the properties for the individual VIP-shared keepalives and contains the following sections:
•Configuring ICMP Shared Keepalive Configuration Settings
•Configuring TCP Shared Keepalive Configuration Settings
•Configuring HTTP HEAD Shared Keepalive Configuration Settings
•Configuring KAL-AP Shared Keepalive Configuration Settings
•Configuring Scripted Keepalive Shared Keepalive Configuration Settings
The default values used for each VIP keepalive is determined by the values specified in the Global Keepalive Properties details page.
Configuring ICMP Shared Keepalive Configuration Settings
To define the ICMP shared keepalive configuration, perform the following steps:
1. In the specified field, enter the IP address of the SLB that hosts the VIP (see Figure 5-16).
Figure 5-16 Shared KeepAlives Details Page—ICMP KeepAlive (Fast KAL Type)
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 that 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 valid entries are from 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 valid entries are from 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
3. Click the Submit button to save your ICMP shared keepalive configuration and return to the Shared KeepAlives list page.
Configuring TCP Shared Keepalive Configuration Settings
To define the TCP shared keepalive configuration, perform the following steps:
1. In the specified field, enter the IP address of the SLB that hosts the VIP (see Figure 5-17).
Figure 5-17 Shared KeepAlives Details Page—TCP KeepAlive (Fast KAL Type)
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 from 1 to 65535. If you do not specify a destination port, the GSS uses the globally configured value.
3. From the Termination Connection Method drop-down list, specify one of the TCP keepalive connection termination methods:
•Global—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 that 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 valid entries are from 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 valid entries are from 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
5. Click the Submit button to save your TCP-shared keepalive configuration and return to the Shared KeepAlives list page.
Configuring HTTP HEAD Shared Keepalive Configuration Settings
To define the HTTP HEAD shared keepalive configuration, perform the following steps:
Figure 5-18 Shared KeepAlives Details Page—HTTP HEAD KeepAlive (Fast KAL Type)
1. In the specified field, enter the IP address of the SLB that hosts the VIP (see Figure 5-18).
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 valid entries are from 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 field, 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, enter:
/company/owner
5. From the Connection Termination Method drop-down list, specify one of the HTTP keepalive connection termination methods:
•Global—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.
Caution When using the graceful termination method and the server packets arrive at the GSS out of order (for example, the FIN packets arrive before the HTTP data), the GSS does not buffer or acknowledge receipt of the out-of-order packets and drops them. If the server does not retransmit the unacknowledged packets, the HTTP HEAD shared keepalive may place the answer in an offline state.
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 that 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 valid entries are from 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 valid entries are from 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
7. Click the Submit button to save your HTTP HEAD shared keepalive configuration and return to the Shared KeepAlives list page.
Configuring KAL-AP Shared Keepalive Configuration Settings
To define the KAL-AP shared keepalive configuration, perform the following steps:
1. Enter the primary (master) and secondary (backup) IP addresses of the SLBs that host the VIP (see Figure 5-19). The secondary IP address is optional. The purpose of the secondary IP address is to query a second Cisco CSS or CSM in a VIP redundancy and virtual interface redundancy configuration.
Figure 5-19 Shared KeepAlives Details Page—KAL-AP KeepAlive (Fast KAL Type)
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 alphanumeric value is used to encrypt interbox communications using CAPP. You must also configure the same encryption value 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 that 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 valid entries are from 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 valid entries are from 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
4. Click Submit to create the new KAL-AP shared keepalive and return to the Shared KeepAlives list page.
Configuring Scripted Keepalive Shared Keepalive Configuration Settings
To define the Scripted keepalive shared keepalive configuration, perform the following steps:
1. Enter the IP address of the SLB that hosts the VIP (see Figure 5-20).
Figure 5-20 Shared KeepAlives Details Page—SCRIPTED-KAL KeepAlive (Fast KAL Type)
2. Enter the KAL name.
3. Choose the Scripted Kal Type. Options here include snmp-mib-not-index-by-vip, snmp-mib-index-by-vip, snmp-mib-scalar, CSS, CSM, or IOS-SLB.
4. Enter the Community. The Community is the SNMP community name defined at the target device.
5. If the Scripted Kal Type is set to one of the non-Cisco SLBs, enter the OID and/or Address and Load filter types (see Figure 5-21).
The OID is the SNMP request sent for this OID. There are two types of OIDs: scalar and vector or table. For a scalar-type OID, the filter is not required, while for a vector-type, it is a requirement. It is useful in obtaining load information about some of the VIPs configured at the GSS.
Figure 5-21 Shared KeepAlives Details Page—SCRIPTED-KAL KeepAlive (Non-Cisco SLB)
Table 5-1 lists the wrappers, OIDs, address, and load filters that are appropriate for different SLB devices.
Note You are not required to use these OIDs and filter IDs. If you have the necessary information, you can use any other MIB. However, only the MIB and OIDs listed in Table 5-1 have been tested and certified by Cisco Systems.
Table 5-1 MIBs, OIDs, and Filter IDs for Scripted Keepalive Types
Device
|
Scripted Keepalive Types
|
OID
|
Address Filter
|
Load Filter
|
Recommended Software Version
|
CSS
|
CSS wrapper
|
*
|
*
|
*
|
SLB: 7.40.0.04
|
SNMP_mib_not_index_by_vip
|
1.3.6.1.4.1.9.9.368.1.16.4
|
1.4
|
1.65
|
CSM
|
CSM wrapper
|
*
|
*
|
*
|
IOS: 12.2
CSM: 4.2(1)
|
SNMP_mib_not_index_by_vip
|
1.3.6.1.4.1.9.9.161.1.4.1
|
1.4
|
1.17
|
IOS-
SLB
|
IOS-SLB wrapper
|
*
|
*
|
*
|
IOS: 12.2
|
SNMP_mib_not_index_by_vip
|
1.3.6.1.4.1.9.9.161.1.4.1
|
1.4
|
1.17
|
F5
|
SNMP_mib_index_by_vip
|
1.3.6.1.4.1.3375.2.2.10.11.3
|
**N/A
|
1.11
|
SLB: 9.2.0 Build167.4
|
|
|
You can also configure Scripted keepalives with any OID that represents load information on an SLB. Depending on the type of table, that is whether the load information is scalar, indexed by VIP, or not indexed by VIP, address and load filters may be required. Figure 5-22 shows a configuration example using a CSS MIB tree.
Figure 5-22 CSS MIB Tree
In this tree, the OIDs are not indexed by VIP. One of the CSS tables that stores load information is apCntTable and the corresponding OID is 1.3.6.1.4.1.9.9.368.1.16.4. From Figure 5-22, you can see that the IP address of the pertinent VIP is referenced by the object apCntIPAddress (OID.1.4) and the load pertaining to this VIP is referenced by the object apCntAvgLocalLoad (OID.1.65). Thus, the IP address obtained here should populate the Address Filter, while the load information populates the Load Filter.
Note If the load information in a MIB table is indexed by VIP, the only required filter is the load filter. Scalars will have neither address or load filters since there is no table associated with the OID.
6. If the Scripted Kal 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 that the GSS retransmits a Scripted Kal 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 valid entries are from 1 to 5 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 Scripted keepalive attempts (probes) that must be recognized by the GSS before bringing an answer back online (and reintroducing it into the GSS network). The valid entries are from 1 to 5 probes. If you do not specify a value, the GSS uses the globally configured value.
Note For more information on the keepalive detection time, see the "Keepalives" section in Chapter 1, Introducing the Global Site Selector.
7. Click the Submit button to save your Scripted Kal shared keepalive configuration and return to the Shared KeepAlives list page.
Modifying a Shared Keepalive
To modify an existing shared keepalive, perform the following steps:
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 5-14).
3. Click the Modify Shared KeepAlive icon located to the left of the shared keepalive that you want to modify. The Modify Shared KeepAlive details page appears (see Figure 5-23).
Figure 5-23 Modifying Shared KeepAlive Details Page
4. Use the fields provided to modify the shared keepalive configuration.
5. Click Submit to save your configuration changes and 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. Before deleting any data that you think you might want to use at a later point in time, perform a database backup of your GSSM. See the
Global Site Selector Administration Guide for details.
To delete a shared keepalive, perform the following steps:
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 that 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, which means 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 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 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 6, Configuring Answers and Answer Groups, describes how to create and configure GSS answers and answer groups. Answers refer to resources to which the GSS resolves DNS requests that it receives. Once created, answers are grouped together as resource pools called answer groups.
