Table Of Contents
Service, Owner, and Content Rule Overview
Service Configuration Quick Start
Assigning an IP Address to the Service
Specifying an HTTP Redirect String
Prepending "http://" to a Redirect String or a Domain
Configuring an Advanced Load-Balancing String
Configuring a Service HTTP Cookie
Configuring Weight and Graceful Shutdown
How the CSS Accesses Server Types
Bypassing Content Rules on Caches
Configuring Network Address Translation for Transparent Caches
Configuring a Service to Bypass a Cache Farm
Configuring Maximum TCP Connections
Configuring Keepalives for a Service
Showing Service Configurations
Clearing Service Statistics Counters
Configuring Service Keepalives
Creating and Naming a Global Keepalive
Configuring a Global Keepalive IP Address
Configuring a Global Keepalive Description
Activating the Global Keepalive
Associating a Service with a Global Keepalive
Configuring Service and Global Keepalive Attributes
Configuring a Keepalive Frequency
Configuring a Keepalive Retry Period
Configuring the Maximum Number of Failures for a Keepalive
Configuring a TCP Keepalive with Graceful Socket Close (FIN)
Configuring a Keepalive Port Number
Configuring the HTTP Keepalive Method
Configuring a Keepalive HTTP Response Code
Configuring a Keepalive Hash Value
Showing Keepalive Configurations
Using Script Keepalives with Services
Script Keepalive Considerations
Viewing a Script Keepalive in a Service
Script Keepalives and Upgrading WebNS Software
Source Group Configuration Quick Start
Source Group Port Mapping Behavior
Configuring a Source Group for FTP Connections
Configuring Source Groups to Allow Servers to Resolve Domain Names Using the Internet
Clearing Source Group Counters
Configuring Relative Load for Services
Relative Load Configuration Quick Start
Configuring Global Load Reporting
Configuring the Relative Load Step
Configuring the Global Load Threshold
Configuring the Load Teardown Timer
Configuring the Load Ageout Timer
Configuring the Absolute Load Calculation Method
Overview of Calculating Absolute Load
Configuration Requirements and Restrictions
Absolute Load Configuration Quick Start
Using the load absolute-sensitivity Command
Configuring load absolute-sensitivity
Optimizing the Absolute Load Number Scale
Displaying Relative Load Statistics
Displaying Absolute Load Calculation Ranges
Using ArrowPoint Content Awareness Based on Server Load and Weight
Using ACA Based on Server Load
Using ACA Based on Server Weight and Load
Configuring the Load Command for Use with ACA
Configuring Dynamic Feedback Protocol for Server Load Balancing
Maintaining a Consistent Weight Range Among Services
Displaying Configured DFP Agents
Displaying Services Supported by Configured DFP Agents
Using the show service Command
Using the show rule services Command
Configuring Services
This chapter describes how to configure services, service, global, and script keepalives, source groups, and load for services. This chapter also contains an overview of the association between services, owners, and content rules. Information in this chapter applies to all CSS models except where noted.
This chapter contains the following major sections:
•
Service, Owner, and Content Rule Overview
•
•
•
Service, Owner, and Content Rule Overview
The CSS enables you to configure services, owners, and content rules in order to direct requests for content to a specific destination service (for example, a server or a port on a server). By configuring services, owners, and content rules, you optimize and control how the CSS handles each request for specific content. Services, owners, and content rules are described below:
•
(a local or remote server and port). You add services to content rules. Adding a service to a content rule includes it in the resource pool that the CSS uses for load-balancing requests for content. A service may belong to multiple content rules.•
•
The CSS uses content rules to determine:
–
–
–
When a request for content is made, the CSS:
1.
2.
3.
4.
Figure 1-1 illustrates the CSS service, owner, and content rule concepts.
Figure 1-1 Services, Owners, and Content Rules
Configuring Services
The following sections describe how to create and configure content services.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
Service Configuration Quick Start
Table 1-1 provides a quick overview of the basic steps required to configure a service. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 1-1.
The following running-configuration example shows the results of entering the commands in Table 1-1.
!************************** SERVICE **************************service serv1ip address 10.3.6.2activeservice serv2ip address 10.3.6.1activeCreating a Service
A service can be a destination location or entity that contains and provides Internet content (for example, a server, an application on a server such as FTP, or streaming audio). A service has a name that is associated with an IP address and optionally, a protocol and a port number.
By creating a service, you identify the service and enable the CSS to recognize it. You can then apply content rules to services that allow the CSS to:
•
•
Enter a service name from 1 to 31 characters. For example, to create service serv1, enter:
(config)# service serv1The CSS transitions into the newly created service mode.
(config-service[serv1])#Assigning an IP Address to the Service
To enable the CSS to direct requests for content to the appropriate service, you must assign an IP address or range of IP addresses to a service. Assigning an IP address to a service identifies the service to the CSS. When the CSS receives a request for content, it translates the VIP (and potentially, the port) to the service IP address (or addresses) and port.
For example, to assign an IP address to serv1, enter:
(config-service[serv1])# ip address 172.16.1.1To restore a service IP address to the default of 0.0.0.0, enter:
(config-service[serv1])# no ip address
Note
•
•
•
You must configure these services with a keepalive type of none.
The range option allows you to specify a range of IP addresses starting with the IP address you specified using the ip address command. Enter a number from 1 to 65535. The default range is 1. For example, if you enter an IP address of 172.16.1.1 with a range of 10, the IP addresses range from 172.16.1.1 through 172.16.1.10.
For example, enter:
(config-service[serv1])# ip address 172.16.1.1 range 10When using the ip address range command, use IP addresses that are within the subnet you are using. The CSS does not arp for IP addresses that are not on the circuit subnet. For example, if you configure the circuit for 10.10.10.1/24 and configure the VIP range as 10.10.10.2 range 400, the CSS will not arp for any IP addresses beyond 10.10.10.254. Using the same example only with a VIP range of 200, the CSS will arp for all IP addresses in the range.
Note
For the CSS to forward requests to a service on any of the addresses in a range, the CSS must successfully arp for the first address in the range. This behavior is independent of keepalives.
Specifying a Port
The TCP or UDP destination port number is associated with a service. Use the port command to specify a service TCP/UDP port number or range of port numbers. Enter the port number as an integer from 0 to 65535. The default is 0 (any).
For example, enter:
(config-service[serv1])# port 80To specify a port to be used for keepalives, use the service mode keepalive port command.
Use the range option to specify a range of port numbers starting with the port number you specified using the port command. Enter a range number from 1 to 65535. The default range is 1. For example, if you enter a port number of 80 with a range of 10, the port numbers will range from 80 through 89. You can use the port range command only on local (default) services.
For example, enter:
(config-service[serv1])# port 80 10To set the port to the default of 0 (any), enter:
(config-service[serv1])# no portSpecifying a Protocol
By default setting, the CSS uses any IP protocol for the service. To specify the service IP protocol that the service is to use, use the protocol command. The options for this command are:
•
•
For example, enter:
(config-service[serv1])# protocol tcpTo set the protocol to the default of any, enter:
(config-service[serv1])# no protocolSpecifying a Domain Name
The CSS uses the configured domain name in the redirect message as the new location for the requested content. The CSS prepends the domain name to the requested URL. If the domain name is not configured, the CSS uses the domain in the host-tag field from the original request. If no host tag is found, the CSS uses the service IP address to generate the redirect. Use the domain command to specify the domain name that will be prepended to a requested piece of content when an HTTP redirect service generates an "object moved" message for the service.
Note
Note
Note
Enter the service domain name as an unquoted text string with no spaces and a maximum length of 64 characters.
Note
For example, enter:
(config-service[serv1])# domain www.arrowpoint.comor
(config-service[serv1])# domain 172.16.3.6To clear the redirect domain for this service, enter:
(config-service[serv1])# no domain www.arrowpoint.comor
(config-service[serv1])# no domain 172.16.3.6Specifying an HTTP Redirect String
The CSS uses the entire configured redirect string as the new location for the requested content. If no string is configured, the CSS prepends the domain configured with the (config-service) domain command to the original request. If neither the redirect string nor the domain name is configured, the CSS uses the domain in the host-tag field from the original request combined with the requested HTTP content. If no host tag is found, the CSS uses the IP address of the service to generate the redirect.
Use the redirect-string command to specify an HTTP redirect string to be used when an HTTP redirect service generates an "object moved" message for the service.
Note
Note
Note
The syntax for this service mode command is:
redirect-string string
Enter the HTTP redirect string as an unquoted text string with no spaces. Enter a maximum of 64 characters. Use quotation marks when you want to include a question mark in the string.
For example, enter:
(config-service[serv1])# redirect-string www.arrowpoint.comTo remove the redirect string from the service, enter:
(config-service[serv1])# no redirect-string www.arrowpoint.comPrepending "http://" to a Redirect String or a Domain
By default, the CSS prepends "http://" to a redirect string or domain. To disable prepending "http://" to a redirect string or domain configured on a service, enter:
(config-service[serv1])# no prepend-httpUse the prepend-http command to prepend "http://" to a redirect string or domain configured for a service.
For example, enter:
(config-service[serv1])# prepend-httpConfiguring an Advanced Load-Balancing String
You can specify an advanced load-balancing method for a content rule that includes stickiness. A content rule is "sticky" when additional sessions from the same user or client are sent to the same service as the first connection, overriding normal load balancing. By default, the advanced balancing method is disabled.
To specify an advanced load-balancing string for a service, use the string command. Use this command in conjunction with the advanced load-balancing methods url, cookie, or cookieurl. For information on advanced load-balancing methods, refer to Chapter 4, Configuring Sticky Parameters for Content Rules.
Enter a string from 1 to 15 characters. For example, enter:
(config-service[serv1])# string 172.16.3.6To remove a string from a service, enter:
(config-service[serv1])# no stringConfiguring a Service HTTP Cookie
If you are using advanced-balance cookies, url, or cookieurl to match an exact string, you must configure the unique string that you want to use for matching each server. Use the string command to specify the HTTP cookie for the service. The syntax for this service mode command is:
string cookie_name
Enter the cookie_name as an unquoted text string with no spaces and a maximum of 15 characters.
For example, enter:
(config-service[serv1])# string userid3217To remove the cookie for a service, enter:
(config-service[serv1])# no stringFor information on configuring sticky on the CSS, refer to Chapter 4, Configuring Sticky Parameters for Content Rules.
Configuring Weight and Graceful Shutdown
The CSS uses this weight when you configure an ACA or weighted roundrobin load balancing method on a content rule. By default, all services have a weight of 1. A higher weight will bias flows toward the specified service. For background information on ACA load-balancing decisions based on server weight, see the "Using ArrowPoint Content Awareness Based on Server Load and Weight" section later in this chapter.
To specify the relative weight of the service, use the weight command in service mode. To set the weight for a service, enter a number from 0 (graceful shutdown) to 10. The default is 1.
If you want to perform a graceful shutdown of an overloaded service or take a service offline for maintenance, specify a weight of 0 so no new connections, except the connections for existing sticky sessions, will be directed to the service. Over time, as existing sticky sessions complete, the load on the service begins to diminish. Changing the weight from 0 to a value between 1 and 10 causes the service to be brought back into rotation for all load balancing methods.
Note
The CSS recognizes content requests that include a location cookie as part of a sticky session. Therefore, even if you add a service with a configured weight of zero as a location service to a content rule, the CSS continues to direct to that service any requests that contain location cookies originating from the service.For example, to specify a weight of 2, enter:
(config-service[serv1])# weight 2To specify a weight of 0 to gracefully shut down a specific service, enter:
(config-service[serv1])# weight 0To restore the weight to the default of 1, enter:
(config-service[serv1])# no weightIf you configure a weight on a service using the weight command, and there is a configured Dynamic Feedback Protocol (DFP) agent for the service, the configured weight for the DFP agent takes precedence over the weight configured on a service (weighted round-robin load-balancing method only).
When you add a service to one or more content rules, the CSS applies the service weight, as configured in service mode, to each content rule as a server-specific attribute. To specify a content rule-specific server weight (assuming the content rule is using a weighted load-balancing method), use the weight option of either the add service command. These two commands override the server-specific weight and apply only to the content rule to which you add the service. For information on using the add service command, see the "Specifying a Service Weight" section in Chapter 3, Configuring Content Rules.
Specifying a Service Type
By default, the service type is local. Use the type command to specify the type for a service. The syntax and options for this service mode command are:
•
Note
•
•
•
When you add a type redirect service to a content rule, you must also configure a URL to match on the content. For example, "/*" or "/vacations.html".
•
•
•
•
•
–
–
For more information on configuring SSL termination, refer to the
Cisco Content Services Switch Security Configuration Guide.•
–
–
For more information on configuring a backend SSL server, refer to the
Cisco Content Services Switch Security Configuration Guide.•
For example, to enable the CSS to redirect content requests for serv1, specify redirect in the serv1 content rule:
(config-service[serv1])# type redirectTo restore the service type to the default setting of local, enter:
(config-service[serv1])# no typeHow the CSS Accesses Server Types
When you configure a Layer 3 or Layer 4 content rule, the rule hits the local services. If:
•
•
Redirect services and redirect content strings cannot be used with Layer 3 or Layer 4 rules because they use the HTTP protocol.
When you configure a Layer 5 content rule, the CSS directs content requests to local services. If:
•
•
•
For information on adding a service to a content rule or adding primary and secondary sorry servers, see Chapter 3, Configuring Content Rules.
Configuring Service Access
When a service offers publishing services, you must associate an FTP access mechanism for moving content during publishing, subscribing, and demand-based replication activities. Use the access command to associate an FTP access mechanism with a service. You must use this command for each service that offers publishing services. This command is optional for subscriber services; the subscriber service inherits the access mechanism from the publisher.
When you use this command to associate an FTP access mechanism with a service, the base directory of an existing FTP record becomes the tree root. To maintain coherent mapping between WWW daemons and FTP daemons, make the FTP access base directory equivalent to the WWW daemon root directory as seen by clients. For information on creating an FTP record, refer to the (config) ftp-record command in the Cisco Content Services Switch Administration Guide.
Enter the name of the existing FTP record as an unquoted text string with no spaces.
For example, enter:
(config-service[serv1])# access ftp arrowrecordTo remove a service access mechanism, enter:
(config-service[serv1])# no access ftpBypassing Content Rules on Caches
By default, no content rules are applied to requests from a proxy or transparent-cache type service. Use the cache-bypass command to prevent the CSS from applying content rules to requests originating from a proxy or transparent-cache type service when it processes the requests.
Note
For example, enter:
(config-service[serv1])# cache-bypassTo allow the CSS to apply content rules to requests from a proxy or transparent-cache type service, enter:
(config-service[serv1])# no cache-bypassConfiguring Network Address Translation for Transparent Caches
By default, destination Network Address Translation (NAT) for the transparent cache service type is disabled. Use the transparent-hosttag command to enable destination NAT for the transparent cache service type.
Currently, you can use the transparent-hosttag command only with a CSS operating in a Client Side Accelerator (CSA) environment. For details on CSA, refer to the Content Services Switch Global Server Load-Balancing Configuration Guide.
Note
For example, enter:
(config-service[serv1])# transparent-hosttagTo disable destination NATing for the transparent cache service type, enter:
(config-service[serv1])# no transparent-hosttagConfiguring a Service to Bypass a Cache Farm
By default, the CSS bypasses cache for non-cacheable content. Use the bypass-hosttag command to allow the CSA on the CSS to bypass a cache farm and establish a connection with the origin server to retrieve non-cacheable content. The domain name from the host-tag field is used to look up the origin
IP address on the CSA.Currently, you can use the bypass-hosttag command only with a CSS operating in a CSA environment. For details on CSA, refer to the Cisco Content Services Switch Global Server Load-Balancing Configuration Guide.
For example, enter:
(config-service[serv1])# bypass-hosttagTo disable bypassing cache for non-cacheable content, enter:
(config-service[serv1])# no bypass-hosttagConfiguring Maximum TCP Connections
By default, there is no limit on the number of TCP connections on a service. To define the maximum number of TCP connections on a service, use the max connections command. Enter the maximum number of connections from 6 to 65534. The default is 65534, which indicates that there is no limit on the number of connections.
Note
For example:
(config-service[serv1])# max connections 7To set the maximum TCP connections to the default value, enter:
(config-service[serv1])# no max connections
Note
Configuring Keepalives for a Service
The default service keepalive is ICMP with a frequency and retry period of 5 seconds, and a maximum failure rate of 3 times. For information on configuring keepalives for a service, see the "Configuring Keepalives" section later in this chapter.
Activating a Service
Once you configure a service, you must activate it to enable the CSS to access it for content requests. Activating a service puts it into the resource pool for load-balancing content requests and starts the keepalive function.
Note
The following command activates service serv1:
(config-service[serv1])# active
Note
For information on adding to a content rule, see Chapter 3, Configuring Content Rules. For information on adding a service to a source group, see the "Configuring Source Groups" section later in this chapter.
Suspending a Service
Suspending a service removes it from the pool for future load-balancing content requests. Suspending a service does not affect existing content flows, but it prevents additional connections from accessing the service for its content. You may want to suspend a service prior to performing maintenance on the service. The following command suspends service serv1:
(config-service[serv1])# suspend
Note
Showing Service Configurations
Before activating a service, you may want to display the service configuration to ensure that all the parameters are correct. The show service command enables you to display information for a specific service or all services currently configured in the CSS, depending on the location from where you issue the command.
You can issue the following show service commands from any mode:
•
•
•
From a specific service mode, the show service command displays configuration information only for that service. For example:
(config-service[serv1])# show serviceWhen you issue this command from any other mode, it displays configuration information for all services.
To display information for a specific service, use the show service command with the service name. For example:
# show service serv86The show service summary command displays a summary of all service currently configured.
Note
Table 1-2 describes the fields in the show service command output.
Table 1-2 Field Descriptions for the show service Command
OutputName
The name of the service.
Index
The CSS assigned unique numeric index.
Type
The type for the service. If you do not define a type for the service, the default service type is local. The possible types are:
•
•
•
•
•
•
•
•
•
•
State
The state of the service. The State field displays the service as Alive, Dying, Down, or Suspended. The Dying state reports that a service is failing according to the parameters configured in the following service mode commands: keepalive retryperiod, keepalive frequency, and keepalive maxfailure. When a service enters the Down state, the CSS does not forward any new connections to it (the service is removed from the load-balancing rotation for the content rule). However, the CSS keeps all existing connections to the service (that is, connections to that service are not "torn down").
Rule
The address, protocol, and port information for the service.
Redirect Domain
The domain name to be used when an HTTP redirect service generates an OBJECT MOVED message for the service.
Session Redundancy
Indicates whether Adaptive Session Redundancy (ASR) is enabled or disabled for the service. For details on ASR, refer to the Cisco Content Services Switch Global Server Load-Balancing Configuration Guide.
SSL-Accel Slot
The slot in the CSS where the SSL module is located. An SSL service requires the SSL module slot number in order to correlate the SSL proxy list to a specific SSL module. For details on SSL, refer to the Cisco Content Services Switch Security Configuration Guide.
Session Cache Size
The size of the SSL session ID cache for the service. The cache size is the maximum number of SSL session IDs that can be stored in a dedicated session cache on an SSL module.
Redundancy Global Index
The unique global index value for ASR assigned to the service using the redundant-index command in service configuration mode.
Redirect String
The HTTP redirect string to be used when an HTTP redirect service generates an OBJECT MOVED message for the service.
Keepalive
The keepalive type, frequency, maxfailure, and retry period. The possible keepalive types are:
•
•
•
•
•
•
•
•
The keepalive frequency value is the interval in seconds between keepalive messages sent to the service. The default is 5. The range is from 2 to 255.
The keepalive maxfailure value is the number of times the service can fail to respond to a keepalive message before being considered down. The default is 3. The range is from 1 to 10.
The keepalive retry period value is the interval in seconds between retry messages sent to the service. The default is 5. The range is from 2 to 255.
Last Clearing of Stats Counters
The date and time when the State Transitions, Total Connections, or Total Reused Conns. counters were last cleared (reset to 0). The date and time stamp initially shown reflects when the service was activated or 01/01/00 00:00:00 if the service is down.
Mtu
The size of the largest datagram that can be sent or received on the service.
State Transitions
The total number of state transitions on the service. If the State Transitions field is 0, the 0 value can be due to a counter reset through either the global configuration mode zero service state-transitions command or the content mode zero state-transitions command. The counter can also be 0 if the service is down, or if the service is alive but no traffic is running.
Total Local Connections
Total number of TCP connections mastered by the CSS in an ASR configuration.
Current Local Connections
Number of current active TCP connections on the CSS in an ASR configuration.
Total Backup Connections
Total number of TCP connections backed up by the CSS for the master CSS in an ASR configuration.
Current Backup Connections
Number of curent TCP connections that the CSS is backing up in an ASR configuration.
Total Connections
The total number of connections that have been mapped to the service. In an Adaptive Session Redundancy configuration, Total Connections equals the sum of the Total Local Connections and the Total Backup Connections. If the Total Connections field is 0, the 0 value can be due to a counter reset through either the global configuration mode zero service total-connections command or the content mode zero total-connections command. The counter can also be 0 if the service is down, or if the service is alive but no traffic is running.
Max Connections
The configured maximum number of TCP connections on the service.
Total Reused Conns.
The total number of connections that were reused for multiple content requests during persistent connections. If the Total Reused Conns field is 0, the 0 value can be due to a counter reset through either the global configuration mode zero service total-reused-connections command or the content mode zero total-reused connections command. The counter can also be 0 if the service is down, or if the service is alive but no traffic is running.
Weight
The service weight used with load metrics to make load allocation decisions. The weight is used in ArrowPoint Content Awareness (ACA) and weighted roundrobin load balancing decisions. The range is from 1 to 10. The default is 1.
Load/Average Load
The current and average load for the service.
DFP
State of the Dynamic Feedback Protocol (DFP). Possible states are Enable or Disable. The DFP state is Disable if either DFP is not configured or DFP is configured and you have configured a weight on a service using the add service weight command in owner-content configuration mode. For details on DFP, see the "Configuring Dynamic Feedback Protocol for Server Load Balancing" section later in this chapter.
Clearing Service Statistics Counters
To clear a specific service statistics counter for all existing CSS services and to set that counter to zero, use the zero service command. The reset statistics appear as 0 in the show service display. The zero service command is available in all modes.
Use the following zero service commands from any mode:
•
•
•
For example, to clear the Total Connections counter for all services, enter:
(config)# zero service total-connections
Note
Configuring Keepalives
When you configure a service on the CSS, the CSS determines the state of the service by sending keepalive messages. By default, the CSS assigns each service with an ICMP keepalive with a frequency and retry period of 5 seconds, and a maximum failure rate of 3 times. To change the default keepalive settings for a service, you can configure individual keepalive attributes for the service or create a keepalive in keepalive mode and apply the service to it.
The following sections provides the following information to configure CSS keepalives:
•
•
•
•
•
CSS Keepalive Overview
The CSS supports a total of 2048 keepalives. These keepalives include:
•
•
Global keepalives supersede the individual keepalive parameters configured in service mode. For information on configuring global keepalives, see the "Configuring Global Keepalives" section later in this chapter.
The CSS divides the keepalive types into two categories, Class A and Class B keepalives. The CSS supports a maximum of 2048 Class A keepalives. The CSS supports a maximum of 512 Class B keepalives.
Table 1-3 lists the keepalive types in each class, the maximum number of each type, and the maximum number of each keepalive type that can execute concurrently.
Caution
When you configure a keepalive for a service (or associate a service with a global keepalive), the CSS periodically sends a message to the service based on the keepalive frequency to determine the state of the service. See the "Configuring a Keepalive Frequency" section. The CSS considers the service to be alive when a service responds to the keepalive message.
The CSS transitions the service to the dying state when the service fails to respond to a keepalive message. The CSS tests whether the failed service is functional by sending a keepalive message at time intervals based on the retry period. See the "Configuring a Keepalive Retry Period" section.
The CSS transitions the service to the down state if the service fails to respond a maximum number of retries to the keepalive message. See the "Configuring the Maximum Number of Failures for a Keepalive" section. Then the CSS removes the service from the load-balancing algorithm. The CSS continues to test whether the service is functional at time intervals based on the retry period.
Thus, using the default values of a 5-second keepalive frequency interval, a 5-second retry period interval, and maximum of three failures, a service can transition from the alive state to the dead state in 15 seconds; a 5-second interval between a keepalive response and the initial keepalive failure based on the keepalive frequency, and two failures, each occurring at 5-second intervals based on the retry period.
However, if the keepalives are Class B type keepalives, the time for a service to transition from an alive state to the dead state may take longer. This transition delay occurs because the CSS executes smaller numbers of Class B keepalives at the same time. For example, if you configure 256 HTTP-GET keepalives using the default values for frequency, retry period, and maximum failure, and all services fail, the time for all of the services to transition from the alive state to the dead state is 120 seconds; 32 services transitioning in 15 seconds followed by another 32 services until all 256 services have transitioned.
Configuring Service Keepalives
A service keepalive is the keepalive configured for a specific service. As you configure a service, you can configure its keepalive attributes. To configure keepalive attributes for a service, access Service configuration mode for the service and use the keepalive command. For information, see the "Configuring Service and Global Keepalive Attributes" section.
If you want to apply a CSS service to a global keepalive, see the "Configuring Global Keepalives" section.
After you configure a service including its keepalive attributes, you can activate the service. Activating a service puts it into the resource pool for load-balancing content requests and starts the keepalive function. For example, to activate service serv1, enter:
(config-service[serv1])# activeConfiguring Global Keepalives
A global keepalive allows you to configure keepalive attributes and apply multiple services to the keepalive. As long as one service is alive, the global keepalive service is alive. By having a single keepalive configuration for more than one service, you can reduce the amount of time to configure each service. Also the keepalive counts as one keepalive no matter how many services you apply to it.
Table 1-4 provides a quick overview of the basic steps required to configure a global keepalive. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 1-4.
Table 1-4 Global Keepalive Configuration Quick Start
1.
# config(config)#2.
(config)# keepalive keepimages(config-keepalive[keepimages])#3.
(config-keepalive[keepimages])# ip address 192.168.7.64.
(config-keepalive[keepimages])# type http5.
(config-keepalive[keepimages])# method get6.
(config-keepalive[keepimages])# uri "/index.html"7.
(config-keepalive[keepimages])# active8.
(config-service[imageserver1])# keepalive type named keepimages9.
(config-keepalive[keepimages])# show keepalive10.
(config-service[imageserver1])# show service
The following running-configuration example shows the results of entering the commands in Table 1-4 as shown in bold and any related commands.
!************************** SERVICE **************************server2ip address 10.3.6.1keepalive type named keepimagesactive!************************* KEEPALIVE *************************keepalive keepimagesip address 192.168.7.6type httpmethod geturi "/index.html"activeThe following sections provides information on:
•
•
•
•
•
•
For information on configuring the keepalive attributes, see the "Configuring Service and Global Keepalive Attributes" section.
Creating and Naming a Global Keepalive
To create and name a global keepalive, use the keepalive command to access keepalive mode. You can access keepalive mode from circuit, global, interface, and IP configuration modes. The prompt changes to (config-keepalive [name]). You can also use this command from keepalive mode to access another keepalive.
Enter the name of the new keepalive you want to create or the name of an existing keepalive. Enter an unquoted text string with no spaces and a length of 1 to 31 characters. To see a list of existing keepalive names, use the keepalive ? command.
For example, to create the global keepalive keepimages, enter:
(config)# keepalive keepimagesWhen you access this mode, the prompt changes to (config-keepalive [keepimages]).
(config-keepalive[keepimages])#To remove an existing keepalive, enter:
(config)# no keepalive keepimagesConfiguring a Global Keepalive IP Address
The CSS sends global keepalives to a service that monitors the state of services assigned to it. Use the ip address command to specify the IP address where the keepalive messages are sent. Enter the IP address in dotted-decimal notation.
For example, to enter an IP address for keepalive keepimages, enter:
(config-keepalive[keepimages])# ip address 192.168.7.6Configuring a Global Keepalive Description
Optionally, you can provide a description for the global keepalive. To specify the description, use the description command . Enter the description as a quoted text string with a maximum of 64 characters, including spaces.
For example, to enter a description for the global keepalive keepimages, enter:
(config-keepalive[keepimages])# description "This keepalive is for the image servers"To delete a description, enter:
(config-keepalive[keepimages])# no descriptionActivating the Global Keepalive
Activating a keepalive enables the CSS to start sending keepalive messages to the IP address. Use the active command to activate the global keepalive.
For example, to activate the global keepalive keepimages, enter:
(config-keepalive[keepimages])# activeSuspending a Global Keepalive
To deactivate the keepalive, use the suspend command.
For example, enter:
(config-keepalive[keepimages])# suspendAssociating a Service with a Global Keepalive
To associate a service with a global keepalive, use the keepalive type named command. The service maintains the global keepalive attributes when you add the service to content rules.
For example, to associate imageserver1 with global keepalive keepimages, enter:
(config-service[imageserver1])# keepalive type named keepimagesConfiguring Service and Global Keepalive Attributes
The following sections describe the attributes you can configure for keepalives:
•
•
•
•
•
•
•
•
Configuring a Keepalive Frequency
The keepalive frequency specifies the interval in seconds between keepalives messages sent to a service. Specify a frequency from 2 to 255 seconds. The default is 5 seconds.
Note
Note
For versions 7.20.1.04 and greater, the timeout is 2 seconds less than the keepalive frequency with a minimum of 1 second. From version 5.20 up to version 7.20.1.04, the timeout is one second less than the keepalive frequency.•
(config-service[serv1])# keepalive frequency 15To reset the frequency to its default value of 5, enter:
(config-service[serv1])# no keepalive frequency•
For example, to set the frequency time to 10 seconds, enter:
(config-keepalive[keepimages])# frequency 10To reset the frequency to its default value of 5, enter:
(config-keepalive[keepimages])# no frequencyConfiguring a Keepalive Retry Period
When a service has failed to respond to a given keepalive message (the service has transitioned to the dying state), the retry period specifies how frequently the CSS tests the service to see if it is functional. Enter the retry period as an integer from 2 to 255 seconds. The default is 5 seconds.
Note
•
(config-service[serv1])# keepalive retryperiod 60To reset the retry period to its default value of 5, enter:
(config-service[serv1])# no keepalive retryperiod•
(config-keepalive[keepimages])# retryperiod 60To reset the retry period to its default value of 5, enter:
(config-keepalive[keepimages])# no retryperiodConfiguring the Maximum Number of Failures for a Keepalive
The maximum failures is the number of times a service can fail to respond to a keepalive message before the CSS considers it offline. Specify a maximum failure number from 1 to 10. The default is 3.
•
(config-service[serv1])# keepalive maxfailure 5To reset the maximum failure number to its default value of 3, enter:
(config-service[serv1])# no keepalive maxfailure•
(config-keepalive[keepimages])# maxfailure 7To reset the maximum failure number to its default value of 3, enter:
(config-keepalive[keepimages])# no maxfailureConfiguring a Keepalive Type
The keepalive type specifies the type of keepalive message assigned to the keepalive. The keepalive types include ICMP, HTTP-GET, HTTP-HEAD, TCP, FTP, SSL, and script keepalives. For a service keepalive, a named keepalive type allows you to apply the service to a configured global keepalive.
•
(config-service[serv1])# keepalive type ftp•
(config-keepalive[keepimages])# type tcpEach time you assign a keepalive type to a service or global keepalive, the CSS counts it as one keepalive.
Caution
The options for the keepalive type or type command are:
•
The FTP keepalive type is a Class B type. The CSS supports a maximum of 256 FTP keepalives and concurrently executes a maximum of 32 keepalives of this type at a time.
When configuring the CSS for FTP keepalives, do not configure the keepalive frequency or the keepalive retryperiod to a value less than 15 seconds. Note that the CSS does not prevent you from configuring smaller values. Also, the default value for the keepalive frequency or the keepalive retryperiod is five seconds. You must use the keepalive frequency and keepalive retryperiod commands to override the defaults.
•
For configuring the method for the HTTP keepalive type, see the "Configuring the HTTP Keepalive Method" section. The HTTP-HEAD persistent, and HTTP-GET persistent keepalive types are a Class B types. Of each of these types, the CSS supports a maximum of 256 keepalives and concurrently executes a maximum of 32 keepalives at a time.
If an HTTP persistent keepalive fails to make a persistent connection, then it attempts to make a non-persistent connection. If the non-persistent connection succeeds, then the keepalive succeeds. At the next interval, the keepalive attempts a persistent connection.
•
For configuring the method for the HTTP keepalive type, see the "Configuring the HTTP Keepalive Method" section. The HTTP-GET non-persistent keepalive type is a Class B type. Of this type, the CSS supports a maximum of 256 keepalives and concurrently executes a maximum of 32 keepalives at a time.
The HTTP-HEAD non-persistent keepalive type is a Class A type. The CSS supports a maximum of 2048 HTTP-HEAD non-persistent keepalives and concurrently executes a maximum of 2048 keepalives of this type at a time.
•
The ICMP keepalive type is a Class A type. The CSS supports a maximum of 2048 ICMP keepalives and concurrently executes a maximum of 2048 keepalives of this type at a time.
•
Before using this command, ensure that the global keepalive is activated through the (config-keepalive) active command. Assigning a service to a global keepalive overrides any keepalive properties you assigned in service mode. For information on creating a global keepalive, see the "Configuring Global Keepalives" section.
•
•
The optional arguments variable passes arguments into the keepalive script. Enter a quoted text string with a maximum of 128 characters including spaces.
The use-output option allows the script to parse the output for each executed command. This optional keyword allows the use grep and file direction within a script. By default, the script does not parse the output. For details on using script keepalives, see the "Using Script Keepalives with Services" section later in this chapter.
The script keepalive type is a Class B type. The CSS supports a maximum of 256 script keepalives and concurrently executes a maximum of 16 keepalives of this type at a time.
Note
•
The SSL keepalive type is a Class A type. The CSS supports a maximum of 2048 SSL keepalives and concurrently executes a maximum of 2048 keepalives of this type at a time.
When the 11500 series CSS is using an SSL module, use the keepalive type of none. The SSL module is an integrated device in the CSS and does not require the use of keepalive messages for the service.
•
The TCP keepalive type is a Class A type. The CSS supports a maximum of 2048 TCP keepalives and concurrently executes a maximum of 2048 keepalives of this type at a time.
Configuring a TCP Keepalive with Graceful Socket Close (FIN)
By default and in compliance with RFC 1122, the CSS sends a reset (RST) to close the socket on a server port for TCP keepalives. A RST is faster than a FIN, because a RST requires only one packet, while a FIN can take up to four packets. If your servers require a graceful closing of a socket using a FIN, you can configure a keepalive to send a FIN to close a socket.
•
(config-service[serv1])# keepalive tcp-close finTo reset the keepalive to send a RST, enter:
(config-service[serv1])# keepalive tcp-close rst•
(config-keepalive[keepimages])# tcp-close finTo reset the keepalive to send a RST, enter:
(config-keepalive[keepimages])# tcp-close rstThe service mode keepalive tcp-close fin and keepalive mode tcp-close fin commands may be applied to a total of 100 TCP keepalives.
Configuring a Keepalive Port Number
By default, the port number for keepalives is based on the keepalive type. If the keepalive type is:
•
•
•
•
You can configure a port number from 0 to 65535.
•
(config-service[serv1])# keepalive port 8080To reset the keepalive port to its default value, enter:
(config-service[serv1])# no keepalive port•
(config-keepalive[keepimages])# port 8080To reset the keepalive port to its default value, enter:
(config-keepalive[keepimages])# no portConfiguring the HTTP Keepalive Method
By default, when you configure an HTTP keepalive type, the CSS uses an HTTP-HEAD method. The CSS issues an HTTP-HEAD method to the service and a 200 OK status is required. The CSS does not compute a reference hash value for this type of keepalive. If the 200 OK status is not returned, the CSS considers the service down.
You can also configure an HTTP GET method. The CSS issues an HTTP GET method to the service, computes an MD5 (Message Digest Algorithm Version 5) hash value on the page, and stores the hash value as a reference hash. Subsequent GETs require a 200 OK status (HTTP command completed OK response) and the hash value to equal the reference hash value. If the 200 OK status is not returned, or if the 200 OK status is returned but the hash value is different from the reference hash value, the CSS considers the service down.
When you specify the content information of an HTTP Uniform Resource Identifier (URI) for an HTTP keepalive, the CSS calculates a hash value for the content. If the content information changes, the hash value no longer matches the original hash value and the CSS assumes that the service is down. To prevent the CSS from assuming that a service is down due to a hash value mismatch, specify the keepalive method as HTTP HEAD.
For information of configuring an HTTP response code for an HTTP-HEAD non-persistent keepalive, see the "Configuring a Keepalive HTTP Response Code" section. For information of configuring an HTTP URI, see the "Configuring a Keepalive URI" section.
•
(config-service[serv1])# keepalive method getTo reset the HTTP keepalive method to HTTP HEAD, enter:
(config-service[serv1])# keepalive method head•
(config-keepalive[keepimages])# method getTo reset the HTTP keepalive method to HTTP HEAD, enter:
(config-keepalive[keepimages])# method headIf you change the keepalive method on an active service, make sure that you suspend and reactivate the service for the change to take effect.
Note
Configuring a Keepalive HTTP Response Code
By default, when the CSS issues an HTTP-HEAD keepalive, the CSS expects a response code of 200 in the response packet from the server it is querying. For HTTP-HEAD non-persistent keepalives, you can configure the CSS to expect a non-200 response code (for example, a 302 redirect response code). Enter the response code as an integer from 100 to 999.
•
(config-service[serv1])# keepalive http-rspcode 302To reset the response code to its default value of 200, enter:
(config-service[serv1])# no keepalive http-rspcode•
(config-keepalive[keepimages])# http-rspcode 302To reset the response code to its default value of 200, enter:
(config-keepalive[keepimages])# no http-rspcodeConfiguring a Keepalive URI
When you configure an HTTP keepalive type, the CSS uses the URI string to determine if the service is alive. By default, the CSS uses the URI string to the root directory,"/". For an HTTP Get, the CSS uses the URI information to calculate the hash value. You can specify the URI content information for an HTTP keepalive.
Note
Enter the content information of the URI as a quoted text string with a maximum of 64 characters. Do not include the host information in the string. The CSS derives the host information from the service IP address and the keepalive port number.
•
(config-service[serv1])# keepalive uri "/index.html"To clear the content information for the keepalive, enter:
(config-service[serv1])# no keepalive uri•
(config-keepalive[keepimages])# uri "/index.html"To clear the content information assigned to this keepalive, enter:
(config-keepalive[keepimages])# no uriConfiguring a Keepalive Hash Value
By default, the CSS uses the MD5 (Message Digest Algorithm Version 5) hash for an HTTP GET keepalive. The CSS compares the hash value against the computed hash value of all HTTP GET responses. A successful comparison causes the keepalive to maintain an Alive state.
For a service keepalive, use the service mode keepalive hash command to override the default MD5 hash. To configure the hash value for a service keepalive:
1.
(config)# service serv1(config-service[serv1])# ip address 10.0.3.21(config-service[serv1])# keepalive type http(config-service[serv1])# keepalive method get(config-service[serv1])# keepalive uri "/testpage.html"(config-service[serv1])# keepalive hash "1024b91e516637aaf9ffca21b4b05b8c"(config-service[serv1])# active2.
(config-service[serv1])# show keepaliveKeepalives:Name: serv1Index: 0 State: ALIVEDescription: Auto generated for service serv1Address: 10.0.3.21 Port: 80Type: HTTP:GET:/testpage.htmlHash: 1024b91e516637aaf9ffca21b4b05b8cFrequency: 5Max Failures: 3Retry Frequency: 5Dependent Services:3.
(config-service[serv1])# keepalive hash "1024b91e516637aaf9ffca21b4b05b8c"An excerpt of the service configuration from the running-config is as follows:
service serv1ip address 10.0.3.21keepalive type httpkeepalive method getkeepalive uri "/testpage.html"keepalive hash "1024b91e516637aaf9ffca21b4b05b8c"activeTo clear a hash value and return to the default hash value, enter:
(config-service[serv1])# no keepalive hashFor a global keepalive, use the hash command to override the default MD5 hash for an HTTP GET keepalive. To configure the hash value for a global keepalive:
1.
(config-keepalive[keepimages])# method get(config-keepalive[keepimages])# uri "/testpage.html"(config-keepalive[keepimages])# hash "1024b91e516637aaf9ffca21b4b05b8c"2.
(config)# service imageserver1(config-service[imageserver1])# ip address 10.0.3.21(config-service[imageserver1])# keepalive type named keepimages(config-service[imageserver1])# active3.
(config-keepalive[keepimages])# show keepaliveKeepalives:Name: imageserver1Index: 0 State: ALIVEDescription: Auto generated for service serv1Address: 10.0.3.21 Port:80Type: HTTP GET:/testpage.htmlHash: 1024b91e516637aaf9ffca21b4b05b8cFrequency: 5Max Failures: 3Retry Frequency: 5Dependent Services:4.
(config-keepalive[keepimages])# hash "1024b91e516637aaf9ffca21b4b05b8c"An excerpt of the service configuration from the running-config is as follows:
service imageserver1ip address 10.0.3.21keepalive type httpkeepalive method getkeepalive uri "/testpage.html"keepalive hash "1024b91e516637aaf9ffca21b4b05b8c"activeTo clear a hash value and return to the default hash value, enter:
(config-keepalive[keepimages])# no hashShowing Keepalive Configurations
To display keepalive information for a service, use the show service command. For more information on this command and what it displays, see the "Showing Service Configurations" section in this chapter.
To display global keepalive configurations, use the show keepalive command. To display a list of existing keepalives, use the show keepalive ? command.
Note
Command Aborted!!! Configuration changed. Please reissue command.This command provides the following options:
•
•
•
For example, enter:
(config)# show keepaliveKeepalives:Name: keepimages Index: 1 State: ALIVE ( ICP Check )Description: This keepalive is for image serversAddress: 172.16.1.7 Port: 80Type: HTTP:HEAD-302:/index.htmlFrequency: 5Max Failures: 3Retry Frequency: 5Dependent Services: imageserver1Name: rualive Index: 2 State: ALIVEDescription: Auto generated for service serv2Address: 172.16.1.8 Port: 80Type: HTTP:HEAD:/index.htmlFrequency: 5Max Failures: 3Retry Frequency: 5Dependent Services: serv2(config)# show keepalive-summaryKeepalives:Alive1 DOWN 192.25.1.7Alive2 ALIVE 192.25.1.8Table 1-5 describes the fields in the show keepalive command output.
Using Script Keepalives with Services
Script keepalives are scripts that you can create to provide custom keepalives for your specific service requirements. To create the scripts, use the rich CSS Scripting Language that is included in your CSS software. For details on using the CSS Scripting Language, including using socket commands and examples of keepalive scripts, refer to the Cisco Content Services Switch Administration Guide.
Currently, a CSS provides keepalives for FTP, HTTP, ICMP, SSL, and TCP. For information on configuring keepalive messages, see the "Configuring Keepalives" section earlier in this chapter.
Using script keepalives allow you to extend the CSS keepalive functionality beyond the default keepalives. For example, you can develop a script specifically to connect a CSS to a Post Office Protocol 3 (POP3) mail server.
Once you create a script offline, you can upload it to the CSS and configure the script keepalive option on a service.
The CSS supports a maximum of 256 script keepalives. If you specify a script to parse the output for each executed command, you can configure only 16 keepalives that use script output.
Note
Script Keepalive Considerations
When you configure a script keepalive, follow the same general guidelines as those for keepalive types, with the exceptions noted in these sections. For details on keepalives, see the "Configuring Keepalives" section earlier in this chapter.
•
•
•
•
To see a complete list of all scripts available in the /<current running version>/script directory, press the Tab key or "?". Optionally, you can type a script name not found in the list, then you can upload the script later. You can manipulate scripts using the archive, clear, and copy commands. You can also upload a script from a local hard drive to the /script directory on the CSS, or download a script from the /script directory on the CSS to a local hard drive.
•
•
•
Note
Configuring Script Keepalives
Script keepalives are scripts that you can create to provide custom keepalives for your specific service requirements. Use the keepalive type script command to configure script keepalives. The syntax for this service configuration mode command is:
keepalive type script script_name {"arguments"} {use-output}
Enter the name of an existing script keepalive. The optional arguments variable passes arguments into the keepalive script. Enter a quoted text string with a maximum of 128 characters including spaces.
The optional use-output keyword allows the script to parse the output for each executed command. This optional keyword allows the use of grep and file direction within a script. You can configure a maximum of 16 script keepalives (out of a maximum of 255 script keepalives) to use script output. By default, the script does not parse the output.
For example, to configure a script keepalive named ap-kal-httplist, enter:
(config-service[serv1)# keepalive type script ap-kal-httplist "10.10.102.105 /default.htm"In the previous example, the keepalive command configures the serv1 service keepalive to be of type script with the script name ap-kal-httplist and the arguments "10.10.102.105 /default.htm". The output is not parsed by the script.
To disable a script keepalive on a service, enter:
(config-service[serv1])# keepalive type noneViewing a Script Keepalive in a Service
When you add a script keepalive to a service, the CSS recognizes that the script is the keepalive for the service in the show service screen. The script name appears in the Keepalive field, and any potential arguments appear directly below in the Script Arguments field. If there are no script arguments, then the Script Arguments field does not appear.
For example, enter:
(config-service[serv1])# show serviceName: serv1 Index: 1Type: Local State: AliveRule (10.10.102.105 ANY ANY)Session Redundancy: DisabledRedirect Domain:Redirect String: Keepalive: (SCRIPT ap-kal-httplist 10 3 5)Script Arguments: "10.10.102.105 /default.htm"Script Error: NoneScript Run Time: 1 secondScript Using Output Parsing: NoLast Clearing of Stats Counters 03/15/2002 13:45:01Mtu: 1500 State Transitions: 0Connections: 0 Max Connections: 0Total Connections: 0 Total Reused Conns: 0Weight: 1 Load: 2
Note
You can also use the show running-config command to display the script keepalive and its arguments.
For example, enter:
(config-service[serv1])# show running-configservice serv1ip address 10.10.102.105keepalive frequency 10keepalive type script ap-kal-httplist "10.10.102.105/default.htm"activeThe example above shows the script keepalive and arguments that have been configured on a service. If no arguments are specified in the script, then the quoted text following the script name will not appear.
Script Keepalive Status Codes
A script can return a status code of zero or non-zero. On a return of non-zero, the CSS flags the service state as Dying or Down; on a return of zero, the CSS flags the service state as Alive. For example, enter:
! Connect to the remote hostsocket connect host einstein port 25 tcp! Purposely failexit script 1Because the above script fails when it executes the exit command, the script returns a non-zero value. By default, the script will fail with a syntax error if the connect command fails. Be sure to check the logic of your scripts to ensure that the CSS returns the correct value.
Script Keepalives and Upgrading WebNS Software
When you upgrade the WebNS software in your CSS, the upgrade process creates a new /<current running version>/script directory. You must copy your custom scripts (including custom script keepalives) to the new /<current running version>/script directory so that the CSS can find them.
Use the following procedure to ensure that your custom script keepalives operate properly after upgrading the software.
1.
2.
3.
Configuring Source Groups
Group configuration mode allows you to configure a maximum of 255 source groups on a CSS. A source group is a collection of local servers that initiate flows from within the local web farm. The CSS enables you to treat a source group as a virtual server with its own source IP address.
For example, if you configure several streaming audio transmitters as a group, the CSS will process flows from the group members and give them all the same source IP address.
The following sections describe how to configure a source group:
•
•
•
•
Source Group Configuration Quick Start
Use the procedure in Table 1-6 to configure a source group for TCP/UDP traffic. To configure a source group for FTP traffic, see the next section. Note that each source group requires a content rule that contains the same services and VIP as the source group.
The following running-configuration example shows the results of entering the commands in Table 1-6.
!*************************** GROUP ***************************group ftpgroupvip address 172.16.36.58add service server1add service server2active!*************************** OWNER ***************************owner arrowpointcontent ftpsource1add service server2vip address 172.16.36.58activeCreating a Source Group
To access group configuration mode, use the group command from any mode except ACL and boot configuration modes. The syntax for this command is:
group groupname
Enter an existing or a new source group name from 1 to 31 characters.
For example, enter:
(config)# group ftpgroup (config-group[ftpgroup])#To view a list of existing source groups, enter:
(config)# group ?
Note
To remove a source group, enter:
(config)# no group ftpgroup
Note
Source Group Commands
Use the following commands in group mode:
•
•
Note
•
Be aware that you cannot use a service with:
–
–
•
vip address ip_or_host {range number}
The options and variables for this command are:
–
–
For example enter:
(config-group[ftpgroup])# vip address 172.16.36.58 range 3•
•
–
To reset the starting port number to its default value of 2016, use the
no portmap base-port command.–
The more modules you add to the CSS chassis, the fewer session processing each module performs and the fewer ports the CSS makes available to each module. To display the number of ports that the CSS allocates to each module, enter the show group portmap command as described in the "Showing Source Groups" section. For more information about the port mapping behavior of the CSS, see the "Source Group Port Mapping Behavior" section.
Enter a number from 2048 to 63488. The default is 63488. This default value should be fine for most applications. If you enter a value that is not a multiple of 32, the CSS rounds up the value to the next possible multiple of 32.
To reset the number of ports to the default value, use the no portmap number-of-ports command.
–
Note
The CSS maintains but ignores any base-port or number-of ports (see the previous options) values configured in the source group. If you later reenable PAT for that source group, any configured base-port or number-of ports values will take effect. The default behavior for a configured source group is to NAT the source IP address and to PAT the source port for port numbers greater than 1023.
To restore the default CSS behavior of NATing source IP addresses and PATing source ports for a configured source group, use the portmap enable command.
•
Source Group Port Mapping Behavior
When you configure a source group, a CSS provides network address translation (NAT) of source IP addresses and port address translation (PAT) of source ports. NAT and PAT add a measure of security to your network by not exposing private network addresses and ports to the public side of a CSS. To NAT source IP addresses and source ports for flows originating from a server (server-side) on the private side of the CSS, add existing services to a source group. To NAT source IP addresses and source ports for flows originating from a client (client-side) on the public side of the CSS, add existing services to a source group as destination services. You can also configure access control lists (ACLs) to perform source NATing.
Each CSS module (except the SSL module) has one session processor (SP) that is responsible for mastering flows.
•
•
•
The default number of source ports available for one source group is 63488 (65533 minus the named ports). With one source group configured, the CSS allocates the total number of ports proportionally among all the SPs in the CSS chassis according to the SP relative weight value. To display the relative weight value of an SP, enter the show chassis session-processors command as described in the Cisco Content Services Switch Administration Guide.
For client-side flows, the CSS sends packets to different SPs for flow processing and the flows have access to the source ports in that SP. The CSS performs a simple XOR hash of the TCP or UDP source and destination port numbers to determine the SP that becomes master for that flow. If the port numbers are the same (for example, DNS UDP port 53), then the CSS uses the low order bits of the source and destination IP addresses to calculate the hash value. The CSS uses the hash value to index into a weighted table of SPs and selects the appropriate SP.
When the CSS performs PAT, the master SP for the flow uses a source port from either a source group or the global portmapper, depending on your configuration. (For information about global port mapping, see Chapter 5, Configuring Flow and Port Mapping Parameters, in the "Configuring Global Port Mapping" section.) The CSS chooses a source port so that the hash of it and the destination port will select the same SP for the server-side flow as the SP that mastered the client-side flow.
For the server-side flow from a given destination port, only certain source port numbers hash to the same SP that was used for the client-side flow. For this reason, all ports available to a particular SP are not necessarily eligible for use when establishing the back-end connection. Therefore, the hash algorithm selects only a percentage of the available ports on any one SP.
To make more available source ports eligible for flows or to provide additional source ports for each SP:
•
•
Table 1-7 illustrates how the number of eligible ports in a CSS 11506 decreases as you increase the number of installed modules (SPs). In all cases, the CSS is configured with one service and a single destination port for all flows (for example, port 80). The numbers of eligible ports in Table 1-7 are approximate and are used for illustration only. Your results may vary depending on your configuration.
Table 1-7 Adding Modules to a CSS 11506 Decreases the Number of Eligible Source Ports
1
63488
2
33728
3
21824
4
16616
5
13144
6
11408
Table 1-8 shows that, by increasing the number of destination ports, even in a fully-loaded CSS 11506 (six SPs), you can dramatically increase the number of source ports that are eligible for port mapping. In this example, the destination ports were chosen consecutively (for example, ports 80 through 89 for row 1).
Table 1-8 Increasing Destination Ports Increases Eligible Source Ports
10
28788
20
31757
32
40000
By comparing row six in Table 1-7 with row 1 in Table 1-8, you can see that increasing the number of destination ports to 10 more than doubles the number of source ports eligible for port mapping.
Note that it is algorithmically significant which destination ports you select to increase the number of eligible source ports and it is not a linear relationship. You may need to select several ranges of destination ports to produce the maximum number of eligible source ports.
Adaptive Session Redundancy (ASR) imposes further restrictions on the number of available and eligible source ports because of the mapping of resources to the backup CSS with an unknown chassis configuration. In a CSS 11503 or a CSS 11506 with ASR and one source group configured, the number of source ports eligible for flows for the entire chassis is 1984 (63488 ÷ 32) per destination port, regardless of the number of installed modules. To make more source ports available for mapping flows, you can configure more source groups and additional destination ports for services. For more information, refer to the Cisco Content Services Switch Redundancy Configuration Guide.
Configuring a Source Group for FTP Connections
To use source groups to support FTP sessions to a VIP that is load balanced across multiple services, configure a content rule for the VIP and then a source group.
Note
To configure FTP sessions to a VIP:
1.
content ftp_rule vip address 192.168.3.6 protocol tcp port 21 application ftp-control add service serv1 add service serv2 add service serv3 active2.
Note
The following running-config example shows source group ftp_group.
group ftp_group vip address 192.168.3.6 add service serv1 add service serv2 add service serv3 activeConfiguring Source Groups to Allow Servers to Resolve Domain Names Using the Internet
The CSS provides support to enable servers to resolve domain names using the Internet. If you are using private IP addresses for your servers and wish to have the servers resolve domain names using domain name servers that are located on the Internet, you must configure a content rule and source group. The content rule and source group are required to specify a public Internet-routable IP address (VIP address) for the servers to allow them to resolve domain names.
To configure a server to resolve domain names:
1.
The following example creates Server1 and configures it with a private IP address 10.0.3.251 and activates it.
(config)# service Server1 (config-service[Server1])# ip address 10.0.3.251 (config-service[Server1])# active2.
The following example creates content rule dns1 with a public VIP 192.200.200.200 and adds server Server1.
(config-owner[arrowpoint.com])# content dns1 (config-owner-content[arrowpoint.com-dns1])# vip address 192.200.200.200 (config-owner-content[arrowpoint.com-dns1])# add service Server1 (config-owner-content[arrowpoint.com-dns1])# active3.
To prevent server source port collisions, the CSS NATs the server's source IP address and port by translating the:
•
•
The following example creates source group dns1 with public VIP address 192.200.200.200 and adds the service Server1.
(config)# group dns1 (config-group[dns1])# vip address 192.200.200.200 (config-group[dns1])# add service Server1 (config-group[dns1])# activeShowing Source Groups
To display source group configuration information, use the show group commands in SuperUser, User, Global Configuration, and Group modes. The options are:
•
•
•
For example, enter:
(config)# show groupTable 1-9 describes the fields in the show group command output.
Clearing Source Group Counters
To set the statistics displayed by the show group command to zero, use the zero all command. The reset counter statistics appear as zero in the show group display.
For example, enter:
(config-group[ftpgroup])# zero allConfiguring Relative Load for Services
The following sections describe how to configure relative load for services:
Relative Load Overview
Relative load is a mechanism that the CSS uses to express the current load experienced by a service. The CSS calculates relative load by using the variances in normalized response times from client to service to determine a service's load number. A service with a heavier processing load would be biased toward a more significant, larger load number. For details on configuring absolute load, see the "Configuring the Absolute Load Calculation Method" section.
To configure global load parameters for the eligibility and ineligibility of CSS services, use the load report, load teardown timer, and load ageout timer commands (discussed later in this section).
Note
You can adjust relative load calculations by changing the load step size, which is the difference, in milliseconds, between load numbers. The CSS can determine the load step dynamically, or you can configure the initial load step using the load step command.
The load on a service has a range of 2 to 255, with an eligible load of 2 to 254. An eligible service is an active service that can receive flows. A service with a load of 255 is offline.
A service becomes ineligible to receive flows when its load number exceeds the configured load threshold. The CSS uses the configured ageout timer value to return the service to the eligible state.
For the CSS to consider the service loads as different, response times of the services must differ by the configured load step or greater. If the response times differ by less than the configured load step, the CSS considers the services to have the same load.
Note
Figure 1-2 shows servers A, B, and C with response times of 100 ms, 1100 ms, and 120 ms, respectively. One group of servers has load step configured to 10 ms. The second group of servers has load step configured to 100 ms.
Figure 1-2 Load Calculation Example with Three Servers
For the servers set to the 10 ms load step, the difference in response time between:
•
•
For the servers set to 100 ms load step, the difference in response time between:
•
•
Increasing the load step causes the load for servers to be closer to each other. Decreasing the load step causes the load for servers to be further from each other.
To enable you to configure an accurate load threshold for a server, you can calculate a load number for a server. To calculate a server load number:
1.
2.
3.
For example, to calculate the load number for serverC with the 10 ms load step:
1.
2.
3.
Configuring Relative Load
The following sections describe how to configure load:
•
•
•
•
•
•
Relative Load Configuration Quick Start
Table 1-10 provides a quick overview of the basic steps required to configure relative load for services. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 1-10.
The following running-configuration example shows the results of entering the commands in Table 1-10.
!*************************** GLOBAL ***************************load teardown-timer 120load ageout-timer 180load step 100 dynamicload threshold 25Configuring Global Load Reporting
A teardown report is a summary of response times for services when flows are being torn down. The CSS uses the teardown report to derive the load number for a service. By default, load reporting is enabled on the CSS. This command applies to both relative load and absolute load. Use the load reporting command to enable load reporting; the CSS generates teardown reports and derives load numbers.
If you are not concerned about load reporting, disable it and it may increase performance (depending on flows and load reporting already occurring). To disable load reporting, enter:
(config)# no load reportingTo reenable load reporting, enter:
(config)# load reportingConfiguring the Relative Load Step
By default, the CSS starts at a load step of 10 ms and then dynamically calculates the load step as it accumulates minimum and maximum response times for the services. Use the load step command to set the relative load step, which is the difference, in milliseconds, between load numbers. Load numbers have a range from 2 to 254.
When you configure the load step to reduce the flows to a slower service, consider the differences in response times between services. For example:
•
•
The options and syntax for this global configuration mode command are:
•
•
Enter the load step, in milliseconds, from 10 to 1000000000. The default is 10 ms. For example, to set the load step to 100 ms, enter:
(config)# load step 100To set the load step to the default of 10 ms, enter:
(config)# no load stepConfiguring the Global Load Threshold
The CSS uses the global load number to determine whether a service is eligible to receive flows. Use the load threshold command to define the global load number. If the service load exceeds the threshold, the service becomes ineligible to receive flows until the CSS ages the service into the eligible state. This command applies to both relative load and absolute load.
Enter the threshold as a number from 2 to 254. The default is 254, which is the maximum threshold services can reach before becoming unavailable. To view the global load on services, use the show load command (see Table 1-11 for details).
For example, to set the load threshold to 25, enter:
(config)# load threshold 25
Note
To set the load threshold to the default of 254, enter:
(config)# no load threshold
Note
Configuring the Load Teardown Timer
A teardown report is a summary of response times for services when flows are being torn down. The CSS uses the teardown report to derive the load number for a service. This command applies to both relative load and absolute load.
When the CSS has sufficient teardown activity for a service, it generates a teardown report and the teardown timer is reset. If a teardown report is not triggered at the end of the teardown timer interval due to insufficient activity, the CSS generates a teardown report based on its current activity. If there is no activity, no report is generated and the timer resets.
Use the load teardown-timer command to set the maximum time between teardown reports. The teardown timer is the the number of seconds between teardown reports. Enter an integer from 0 to 1000000000. The default is 20. The value of 0 disables the timer.
Note
For example, to set the teardown timer to 120 seconds, enter:
(config)# load teardown-timer 120To reset the teardown time interval to its default of 20 seconds, enter:
(config)# no load teardown-timerConfiguring the Load Ageout Timer
By default, the CSS times out stale load information for a service at time interval of 60 seconds. When the ageout timer interval expires, the CSS erases the information and resets the service load to 2. Load information is stale when the teardown report number recorded on a service has not incremented during the ageout time interval because no flows (long or short) are being torn down on the service. This command applies to both relative load and absolute load.
At the beginning of the time interval, the ageout timer saves the number of the current teardown report. When the CSS generates a new teardown report, the report number in the CSS increments and any services in the report will save this number. At the end of the ageout time interval, the CSS compares the initial teardown number, saved at the beginning of the time interval, with the current teardown number saved by each service. If the number of a service is less than or equal to the timer number, the load information is stale. The CSS erases it and the service load is reset to 2.
Use the load ageout-timer command to set the time interval, in seconds, in which the CSS times out stale load information for a service. Enter the ageout timer as the number of seconds to time out load information for a service. Enter an integer from 0 to 1000000000. The default is 60. A value of 0 disables the timer.
For example, enter:
(config)# load ageout-timer 180To set the ageout time to the default of 60, enter:
(config)# no load ageout-timerShowing Global Service Loads
Use the show load command to display the global load configuration and service load information. For example, enter:
(config)# show loadTable 1-11 describes the fields in the show load command output.
Configuring the Absolute Load Calculation Method
Configure the absolute load calculation method on a CSS to enhance the way the CSS determines service load, either locally, or in a global server load balancing (GSLB) environment. This method is an alternative to the relative load-calculation algorithm and calculates the load on a service without normalizing load values against the fastest services on the CSS. Consider using absolute load instead of relative load when you have a single CSS serving multiple applications, or when you are using GSLB to balance between multiple CSSs.
The section contains the following subsections:
•
•
•
•
•
Overview of Calculating Absolute Load
Calculating absolute load numbers for services may allow the CSS to make more intelligent load-balancing decisions than using relative load numbers. Absolute load only takes into account the actual observed load on a service, whereas relative load compares services to the service with the fastest response time.
Absolute load also allows you to configure the response times that correlate with values within the CSS load number scale. Unlike the relative load number scale, where all the load numbers between 2 and 254 represent equal steps or increases in response times, absolute load creates 16 different divisions or ranges within the CSS load number scale. Ranges are groups of consecutive load numbers that share a common step size (delta) between numbers.
Note
This feature provides a default set of 16 ranges with a configurable sensitivity option that you can use to modify the upper boundary of the load number scale while adjusting the step sizes (granularity) within the ranges. In general, the better the granularity between load numbers, the better load balancing a CSS performs. However, if the granularity is too fine, the slower servers will be excluded from the load number scale and load numbers will be meaningless for these load-balancing decisions. Keeping the ranges within the load number scale allows some fine granularity for faster servers and coarser granularity for slower servers, while accommodating both short-lived and long-lived flows.
A CSS calculates the average response time for a service based on the measured lifetime of flows to that service. The CSS filters the response values for deviation and damps them to avoid sudden changes. The average response time is then mapped to the absolute load ranges.
For example, suppose a site has two groups of services serving two different types of applications. Group A supports application A, which involves mainly short-lived, quick connections; Group B supports application B, which is much more server-intensive and takes longer to complete. Further, it should never take more than 200 ms for a service handling application A to respond, but it could take up to 200,000 ms for services handling application B to respond. Rather than grouping these services together and using a response time much too large for application A, absolute load allows the CSS to use ranges within the load number scale to better handle load monitoring and balancing for each application.
Configuration Requirements and Restrictions
Observe the following configuration requirements and restrictions when you configure your services.
•
•
•
•
Absolute Load Configuration Quick Start
Table 1-12 provides a quick overview of the basic steps required to configure absolute load. Each step includes the CLI command required to complete the task. For a complete description of each feature and all the options associated with the CLI commands, see the sections following Table 1-12.
Table 1-12 Absolute Load Configuration Quick Start
1.
# config(config)#2.
(config)# load calculation absolute3.
•
•
(config)# dns-peer load variance 0(config)# dns-server zone load variance 04.
(config)# show load5.
(config)# show load absolute
The following running-configuration example shows the results of entering the commands in Table 1-12.
!*************************** GLOBAL ***************************dns-server zone load variance 0load calculation absoluteConfiguring Load Calculation
By default, the CSS uses the relative load calculation method to assign load numbers to all configured services. This method assigns load numbers to services based on a comparison with the fastest local service. Use the load calculation command to specify the calculation method that the CSS uses to assign load numbers to all configured services. The syntax for this global configuration mode command is:
load calculation relative|absolute
The options are:
•
•
For example, to configure the absolute load calculation method, enter:
(config)# load calculation absoluteTo return the load calculation method to the default of relative, enter:
(config)# no load calculation
Note
Using the load absolute-sensitivity Command
By default, the absolute load calculation method uses an internal load number scale designed to support a wide range of configurations and applications. However, you can adjust the absolute load number scale to suit your configuration.
Configuring load absolute-sensitivity
Increasing the CSS load absolute-sensitivity value increases the upper boundary of the maximum response time and the step size (granularity) of the absolute load number scale, thereby reducing the load value for a given service response time. Conversely, decreasing the load absolute-sensitivity value decreases upper boundary of the the maximum response time and the step size (granularity) of the absolute load number scale, thereby increasing the load value for a given service response time.
Use the load absolute-sensitivity command to modify the absolute load number scale. The syntax for this global configuration mode command is:
load absolute-sensitivity number
The number variable specifies the sensitivity of the absolute load number scale. Enter an integer from 1 to 25. The default is 21.
For example, to configure a load sensitivity of 18, enter:
(config)# load absolute-sensitivity 18To return the load absolute-sensitivity to the default value of 21, enter:
(config)# no load absolute-sensitivityFor number values from 1 to 20, the absolute load number ranges are linear, which means that the step sizes are equal among all the ranges. For values from 21 to 25, the ranges are nonlinear, which means different ranges have different step sizes that increase as the range number increases. For details, see the "Displaying Absolute Load Calculation Ranges" section later in this chapter.
Optimizing the Absolute Load Number Scale
As an experienced user, you can optimize the absolute load number scale to more closely resemble the actual load numbers and maximum response times of your configured services. Before you attempt to modify the absolute load number scale, read this procedure in its entirety to familiarize yourself with the steps. To optimize the absolute load number scale:
1.
2.
3.
4.
5.
6.
7.
8.
Configuring Load Variance
Load variance is a configured value that represents a range of load numbers among sites or zones that the CSS considers to be similar for the least-loaded algorithm in a DNS load-balancing decision. For example, if you configure a load variance of 50, and the load difference among three sites is 50 or less, the CSS calculates the minimum response time for each site, then selects the site with the fastest service, ignoring the similar load values.
Note
To set the deterministic difference in peer load numbers that a CSS considers to be similar for the least-loaded algorithm in a zone-based DNS load-balancing decision, use the dns-server zone load variance command. For the number variable, enter an integer from 0 to 254. The default is 50. Use the no dns-server zone load variance command to restore the load variance to the default of 50. For more information on the dns-server zone command, refer to the Cisco Content Services Switch Global Server Load-Balancing Configuration Guide.
Displaying Relative Load Statistics
Use the show load command to display the load calculation information for each service configured on your CSS.
Table 1-13 describes the service-specific fields in the show load command output.
Use the Average Response Time and the Peak Average Response Time values when you configure services and their associated load and when monitoring configured services. These two fields appear in the show load command output regardless of the configured load calculation method.
After monitoring traffic, use the show load command to determine whether the absolute-sensitivity value needs to be modified for your configuration. Observe the peak response times of all the servers and determine the worst performing service. By comparing the worst server response time to the associated response time of the load number 254, you can determine whether the load number scale needs to be expanded.
Note
Displaying Absolute Load Calculation Ranges
Use the show load absolute command to display absolute load number ranges. This command displays all load numbers and their associated maximum response times based upon the currently configured value for load absolute-sensitivity (see the "Configuring load absolute-sensitivity" section). The show load absolute command also displays the ranges and their calculated step sizes for load numbers within a range. Table 1-14 displays the show load absolute command output based on the load absolute-sensitivity default value of 21.
Table 1-15 describes the fields in the show load absolute command output.
The load number scale starts at 2 and ends at 255, where the value of 255 means a service is unavailable. Within the load number scale, there are 16 equal-sized ranges. The response time boundaries of each range are based on deriving a step size and the number of steps within a range. The stepsizes differ among ranges, with stepsizes getting larger as load numbers increase. This scheme provides finer granularity to faster services where it is needed and provides coarser granularity to slower services.
Table 1-16 displays the show load absolute command output based on a load absolute-sensitivity value of 22. Notice that both the Step Size and the Maximum Response Time values have increased for each range.
Table 1-17 displays the show load absolute command output based on a load absolute-sensitivity value of 1. This value represents the smallest (finest) granularity allowed between service response times and the load numbers that represent them. Notice that the step size remains constant (linear) for all ranges.
Table 1-18 displays the show load absolute command output based on a load absolute-sensitivity value of 2. The step size remains constant for all ranges, but its value has increased. The maximum response time associated with each range has also increased.
Using ArrowPoint Content Awareness Based on Server Load and Weight
The ArrowPoint Content Awareness (ACA) load-balancing algorithm balances traffic between a group of servers. You can configure the CSS to make ACA load-balancing decisions based on:
•
•
Using ACA Based on Server Load
ACA determines the best service for each content request based on server load and size of the content being requested. ACA estimates the file size based on previous requests for the same content. A service with a lower load receives more flows than a service with a higher load.
Using ACA Based on Server Weight and Load
Server weight is a mechanism to express the processing capabilities of a server. Weights allow you to configure the CSS to prefer one group of servers over another. When you configure weights, the number of hits per server is relative to the weight configured on that server. A higher weight will bias flows toward the specified server. For example, in Figure 1-2, ServerA with a weight of two is hit twice as often as ServerB which has a weight of one. ServerC has a weight of 10 and is hit 10 times as often as ServerB. All servers with the same weight are hit equally in a roundrobin manner.
The CSS can use a server's weight in tandem with server load to determine server availability. When you configure ACA on a content rule to use both weight and load, the CSS calculates the number of requests per weight level based on the number of servers with that weight. The CSS then balances the requests among the servers based on their individual loads. The number of requests per weight level is equal to weight level times the number of servers times 10. The CSS then increments the weight level and uses the same mechanism to balance requests among the servers in the next weight level.
For information on configuring weight for a service, see the "Configuring Weight and Graceful Shutdown" section earlier in this chapter. Also see the "Specifying a Service Weight" section in Chapter 3, Configuring Content Rules.
Configuring the Load Command for Use with ACA
To configure a load on a service and bypass the CSS load calculation method (relative or absolute), use the load command in service configuration mode. Use this command with the ACA load-balancing method when you want to take into account server load parameters, for example:
•
•
•
•
You can set the load command value with your application or server using SNMP or the CSS XML interface. For information about ACA, see the "Using ArrowPoint Content Awareness Based on Server Load and Weight" section. For information about SNMP and the XML interface, refer to the Cisco Content Services Switch Administration Guide.
Caution
The load command has the following syntax:
load number
The number variable is the load value that you assign to a service. A service with a higher load number receives fewer hits than a service with a lower load number. The CSS considers a service with a load of 254 as unavailable, and, therefore, the service receives no hits. Enter an integer from 2 to 254. The default is 2.
For example, to configure a load of 50, enter:
(config-service[server1])# load 50Use the no form of the command to reset the load value to the default of 2. For example, enter:
(config-service[server1])# no loadTo display the configured value for the load command, use the show load command. For details about the show load command, see the "Showing Global Service Loads" section.
Configuring Dynamic Feedback Protocol for Server Load Balancing
The Dynamic Feedback Protocol (DFP) is a mechanism that allows load-balanced servers (both local and remote) to dynamically report changes in their status and their ability to provide services to a CSS. A status report sent to a CSS from a server contains a relative weight/number of connections to define the load and availability of each server. A CSS incorporates server feedback into the load-balancing decision process in order to:
•
•
•
The following sections describe DFP and how to configure it:
•
•
•
DFP Overview
The DFP manager (running on the CSS as a task and part of the load manager) is responsible for establishing TCP connections with the DFP agents that reside on each server. A DFP manager can communicate simultaneously with a maximum of 127 DFP agents. DFP agents can be software running on the actual server itself or may be separate hardware devices that collect and consolidate information from one or more servers for load-balancing purposes. DFP agents are available from a number of third-party sources.
DFP agents collect relative weights from the load-balanced servers and periodically send new or adjusted weights to the DFP manager in the form of load vectors. The CSS load manager distributes the incoming connections or services (local or remote) to the servers in the order of weight assigned to the load-balanced servers. The load manager uses the reported weights to choose the best available server, resulting in optimal performance of servers and less response time.
Note
The CSS uses load-balancing algorithms such as roundrobin, weighted roundrobin, Arrowpoint Content Aware (ACA), and least connections to distribute the incoming connections or service requests. Weighted roundrobin can take advantage of the server weights reported by the DFP agents.
The weighted roundrobin load-balancing method uses weight to specify how many consecutive connections to give to the highest-weighted server before moving on to the next highest-weighted server. As a server's load changes, the DFP agent recalculates the weight for each server and reports the updated weights to the DFP manager, thereby influencing how the load manager distributes the service requests. For more information on CSS server load-balancing, refer to Chapter 3, Configuring Content Rules.
Functions of a DFP Agent
A DFP agent reports server weight/connection information to the DFP manager. Multiple DFP agents can exist on a server platform. An agent provides several benefits to the load-balancing process. A DFP agent can inform the CSS that the server:
•
•
•
Types of DFP Messages
The following messages are defined for communication between the DFP agent and the DFP manager in the CSS:
•
•
•
DFP messages consist of a DFP header called a signal header followed by message vectors. Vectors are optional commands that exist in the defined messages. Each message vector contains a vector header, which is the first part of each vector in the DFP message, followed by data specific to the defined vector. The vector header allows the DFP manager or the DFP agent to discard any vectors or commands that it does not understand.
Defined vectors for DFP include:
•
•
•
If a CSS receives a message that contains a vector type that it does not understand, The CSS discards the unknown vector.
DFP System Flow
When you configure a DFP agent on a CSS, the DFP manager initiates a single TCP connection with the DFP agent (regardless of the number of servers the agent supports) with the parameters specified in the DFP agent configuration. The DFP manager sends a keepalive vector in a DFP message to change the default keepalive time if required.
After the connection is established, the DFP agent periodically sends update information in the form of a load-vector. If an agent has no information to send, it still must send an empty DFP packet to prevent the connection from being torn down.
If a DFP agent is responsible for collecting information from multiple servers, the servers are grouped by their port number and protocol type, and a separate load vector is required for each grouping. A DFP agent can report weights for a maximum of 128 servers in a single weight report. Upon receiving information about an adjusted weight, the e DFP manager updates the weights of the server reported in the list of load-balanced servers.
If DFP is disabled, a CSS uses the weight configured on a service in owner-content configuration mode using the add service weight command (for that content rule only) or the weight configured on the service in service configuration mode, in that order. If no weight is configured on the service, the CSS uses a default weight of 1 to load balance the service. If a connection between a DFP agent and the DFP manager closes because of a timeout, a CSS uses the default weight for load balancing until the DFP manager reestablishes the connection with the DFP agent and obtains a new weight report.
If the configured DFP agent supports MD5 security, you can specify a shared key text string in the DFP manager. MD5 encryption is a one-way hash function that provides strong encryption protection. The CSS provides an MD5 secure connection between the DFP manager and the DFP agent on the server. In this secure environment, the CSS discards DFP messages from the server unless the messages contain the MD5 code.
Figure 1-3 summarizes the relationship between the DFP manager (in the CSS) and a DFP agent.
Figure 1-3 Example of DFP Manager to DFP Agents System Flow
Configuring a DFP Agent
To configure a DFP agent listening for DFP connections on a particular IP address and TCP port combination on a server and to enable the DFP manager on the CSS, use the dfp command. You can configure a maximum of 127 DFP agents for the DFP manager in the CSS. Use the no dfp command to disable the DFP agent connection to a particular IP address.
The syntax for the dfp command is:
dfp ip_or_host {port} {key "secret"|[des-encrypted encrypted_key|"encrypt_key"]} {timeout seconds} {retry count}
{delay time} {max-agent-wt weight}The variables and options are:
•
•
Note
•
For DFP to function properly, ensure that you configure the same key on each DFP agent that you configured on the DFP manager. If the key on an agent does not match the key on the DFP manager, no connection will be established and the DFP agent will not be able to send a weight report to the CSS. In this case, when the DFP manager fails to establish a connection with an agent for a given key, the CSS logs the following informational message in SYSLOG: Secret key might not be same as DFP agent's key. Check secret key.
•
•
•
•
•
•
•
If a DFP agent reports a weight greater than the maximum configured weight, then the CSS rejects the weight report and does not use the weight in load-balancing decisions. In this case, the CSS also logs an error in SYSLOG. Enter an integer from 1 to 65535. The default is 255.
For example, the following command configures the DFP manager to communicate with the DFP agent at the specified address running with the following options and variables:
•
•
•
•
•
•
(config)# dfp 192.168.1.2 14001 key "hello" timeout 6000 retry 3 delay 60To disable the DFP agent, enter:
(config)# no dfp 192.168.1.2Maintaining a Consistent Weight Range Among Services
The CSS has a weight range of 1 through 10; the DFP manager has a weight range of 0 through 255. Because of this difference in weight ranges, you may need to manually adjust the weights configured on the DFP agent for different services to maintain the same service weight range that exists outside of the DFP.
For example, suppose that you configure on the same content rule three services (serv1, serv2, and serv3) with weights of 1, 2, and 5, respectively. If the DFP agent reports a weight of 20 for serv1, serv1 will now receive 20 connections for every 2 connections on serv2 and 5 connections on serv3. This configuration places a disproportionate load on serv1, especially if serv2 and serv3 represent fast servers with plenty of unused resources.
To solve this problem and to maintain the same weight range for all three services, you can do either of the following:
•
•
Displaying Configured DFP Agents
For reporting purposes, you can view the configured DFP agents on a CSS using the show dfp command. This command displays a list of all DFP agents or the DFP agents at the specified IP address or host name arranged by their IP addresses, the port number on which the agent is connected to the DFP manager, the current state of the DFP agent, the keepalive time for the DFP TCP connection, and the DES-encrypted key of the agent, if any.
The syntax for this command is:
show dfp ip_or_host
The ip_or_host variable allows you to specify the DFP agent or agents running at a particular IP address or host name.
For example, to display configuration information for all DFP agents, enter:
# show dfpTable 1-19 describes the fields in the show dfp command output.
Displaying Services Supported by Configured DFP Agents
To view the individual weights of load-balanced services reported by a configured DFP agent, use the show dfp-reports command. This command groups the weights by the port number of reported services, the type of protocol, and the IP address of servers.
The syntax for this command is:
show dfp-reports {ip_or_host {port number {protocol text {ip ip_or_host}}}}
The options and variables for this command are:
•
•
•
•
The following example shows the weight reported by a DFP agent configured at 192.168.1.2, for server 192.168.1.3. Weights are first grouped by port number of reported servers, and then by protocol.
# show dfp-reports 192.168.1.2 port 80 protocol tcp ip 192.168.1.3Table 1-20 describes the fields in the show dfp-reports command output.
Displaying DFP Information
To display DFP information, see the following sections:
•
•
Using the show service Command
Use the show service command to display service-specific information. The show service command output includes a DFP field that indicates the state of DFP. Possible states are Enable or Disable.
The state is Enable when DFP is configured and there is no weight configured on the service in owner-content configuration mode. The state is Disable if DFP is not enabled or if DFP is enabled and you have configured a service weight in owner-content configuration mode using the add service weight command.
For details on the show service command, see the "Showing Service Configurations" section earlier in this chapter.
Using the show rule services Command
Use the show rule services command in owner-content mode to display weights configured for services in service mode, owner-content mode, and DFP, as well as other service-related information. The output of the command includes the weight assigned to each service preceded by a code letter. The code letters have the following meanings:
•
•
•
For details on the show rule services command, see Chapter 3, Configuring Content Rules.
Where to Go Next
For information on creating and configuring owners, see Chapter 2, Configuring Owners.
