Applies To:

Show Versions Show Versions

Manual Chapter: Managing Application Layer Traffic
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The BIG-IP® local traffic management system offers several features that you can use to intelligently control your application layer traffic. Examples of these features are the insertion of headers into HTTP requests and the compression of HTTP server responses.
These features are available through various configuration profiles. A profile is a group of settings, with values, that correspond to a specific type of traffic, such as HTTP traffic. A profile defines the way that you want the BIG-IP system to manage that traffic type.
Note: An additional profile type, SMTP, is available when BIG-IP® Protocol Security Module is licensed on the system. For information on configuring an SMTP profile, see the Configuration Guide for BIG-IP® Protocol Security Module.
In addition to these application layer profiles, the BIG-IP system includes other features to help you manage your application traffic, such as health monitors for checking the health of HTTP and FTP services, and iRulesTM for querying or manipulating header or content data. For more information, see the remainder of this guide.
Note: There is another type of HTTP profile called a Fast HTTP profile. The use of a Fast HTTP profile is incompatible with the use of an HTTP profile. For more information on the Fast HTTP profile, see Chapter 8, Managing Protocol Profiles.
You can configure HTTP profiles to ensure that HTTP traffic management suits your specific needs. These configuration settings are organized into several categories on the New HTTP Profile screen in the Configuration utility: General Properties, Settings, Compression, and RAM Cache. You can configure these settings when you create a profile, or after profile creation by modifying the profiles settings. For specific procedures on configuring a profile, see Chapter 5, Understanding Profiles.
For the profile settings that appear in the Properties and Settings areas of the HTTP Profile screen, you can specify values where none exist, or modify any default values to suit your needs. For information about other HTTP profile settings, see Configuring HTTP compression, and Configuring the RAM Cache feature.
You can implement any one of these profiles as is, or you can create custom profiles by changing the value of the settings to suit your needs.
You can use the default http profile as is, or create a custom HTTP profile. The http profile is considered a default profile because it does not inherit setting values from a parent profile.
Table 6.1 shows the profile settings for an HTTP type of profile. For those settings that have default values, you can retain those default settings or modify them. Following this table are descriptions of the settings and the procedure for changing them.
Specifies the fallback host to send as an HTTP 302 response when either all nodes are down, or the selected node is down but not yet detected as such by the associated monitors.
Specifies the HTTP error codes that cause the BIG-IP system to redirect an HTTP response to the host specified with the Fallback Host setting.
Specifies how to handle chunking for HTTP responses. Possible values are Unchunk, Rechunk, Selective, and Preserve.
Performs HTTP header transformations for the purpose of keeping connections open. This feature requires configuration of a One ConnectTM profile.
Enabled (Checked)
Insert XForwarded-For
Inserts an XForwarded-For header into an HTTP request, to use with connection pooling. This feature adds the IP address of the client as the value of the XForwarded-For header.
Specifies the maximum width allowed for an HTTP header that is inserted into an HTTP request.
Specifies the separator that the BIG-IP system should use between HTTP headers when a header exceeds the maximum width allowed.
Specifies the maximum number of HTTP requests that the system allows for a single Keep-Alive connection.
Specifies, when checked (enabled), that the system inspects HTTP traffic for security vulnerabilities, by using a security profile in the Protocol Security module. This option is available only when you are licensed for the module.
To create an HTTP profile, you must specify a unique name for the profile. The Name setting is one of only two settings for which you must actively specify a value when creating an HTTP profile; all other settings have default values.
To specify a profile name, simply locate the Name setting and type a unique name for the profile.
Every profile that you create is derived from a parent profile. You can use the default http profile as the parent profile, or you can use another HTTP profile that you have already created.
To specify a parent profile, locate the Parent Profile setting and select a profile name.
The value of the Basic Auth Realm setting is a string that you provide. The BIG-IP system sends this string to a client as part of client authentication.
To configure this setting, locate the Basic Auth Realm setting and type a value.
Another feature that you can configure within an HTTP profile is HTTP redirection. HTTP redirection allows you to redirect HTTP traffic to another protocol identifier, host name, port number, or URI path.
Redirection to a fallback host occurs if all members of the targeted pool are unavailable, or if a selected pool member is unavailable. (The term unavailable refers to a member being disabled, marked as down, or having exceeded its connection limit.) When one or more pool members are unavailable, the BIG-IP system can redirect the HTTP request to the fallback host, with the HTTP reply Status Code 302 Found.
Although HTTP redirection often occurs when the system generates an LB_FAILED iRule event, redirection can also occur without the occurrence of this event, such as when:
The selected node sends an RST after a TCP 3WHS has completed, but before the node has sent at least a full response header.
The BIG-IP system finds the selected node to be unreachable while receiving the body portion of a request or a pipelined request.
When configuring the BIG-IP system to redirect HTTP traffic to a fallback host, you can specify an IP address or a fully-qualified domain name (FQDN). The value that you specify becomes the value of the Location header that the servers sends in the response. For example, you can specify a redirection as http://redirector.siterequest.com.
In addition to redirecting traffic when a target server becomes unavailable, you can also specify the HTTP error codes from server responses that should trigger a redirection to the fallback host. Typical error codes to specify in the Fallback Error Codes setting are 500, 501, and 502.
When you type the error codes in the Fallback Error Codes box, you separate the codes with a space, such as 500 501 502. You can also specify a range of error codes, as in this example: 505-515.
An optional setting in an HTTP profile is HTTP header insertion. The HTTP header being inserted can include a client IP address. Including a client IP address in an HTTP header is useful when a connection goes through a secure network address translation (SNAT) and you need to preserve the original client IP address.
The format of the header insertion that you specify is generally a quoted string. Alternatively, however, you can insert a Tools Command Language (Tcl) expression into a header that dynamically resolves to the desired value. When you assign the configured HTTP profile to a virtual server, the BIG-IP system then inserts the header specified in the profile into any HTTP request that the BIG-IP system sends to a pool or pool member.
Note: In addition to inserting a string such as a client IP address into an HTTP request, you can configure the BIG-IP system to insert SSL-related headers into HTTP requests. Examples are: client certificates, cipher specifications, and client session IDs. To insert these types of headers, you must create an iRule. For more information on using iRule commands to perform header insertion, see Chapter 17, Writing iRules, and the F5 Networks DevCentral web site, http://devcentral.f5.com.
To insert a header into an HTTP request, locate the Request Headers Insert setting and type a value.
Another optional setting is the Header Erase setting. Using this setting, you can configure a profile to erase the contents of a header from an HTTP request that is being sent from a client to a server. With this feature, you can erase header content from HTTP requests before forwarding the requests over the network. Such headers might contain sensitive information, such as user IDs or telephone numbers, that must be erased before the information is forwarded.
When you use this setting, the BIG-IP system erases the contents of the specified header and replaces that content with blank spaces. The header itself is retained.
The client header with the contents to be erased must be specified as a quoted string. To erase a header from an HTTP request, locate the Request Headers Erase setting and type a value.
Using the Configuration utility, you can specify any headers within an HTTP response that you want the BIG-IP system to allow. To do this, type a value in the Response Headers Allowed box. If you are specifying more than one header, separate the headers with a blank space. For example, if you type the string Content-Type Set-Cookie Location, the BIG-IP system then allows the headers Content-Type, Set-Cookie, and Location.
Sometimes, you might want to inspect and/or modify HTTP application data, such as compressing the content of an HTTP response. Such inspections or modifications require that the response be unchunked, that is, not in chunked encoding. Using the Response Chunking settings, the BIG-IP system can unchunk a chunked response before performing an action on that response.
Possible values for this setting are Unchunk, Rechunk, Selective, and Preserve. The default value is Selective.
Table 6.2 describes each of these values and the action that the BIG-IP system takes, depending on whether an original response is chunked or unchunked.
The BIG-IP system unchunks the response and processes the HTTP content, and passes the response on as unchunked. The connection closes when all data is sent to the client as indicated by the Connection: Close header.
The BIG-IP system processes the HTTP content and passes the response on untouched.
The BIG-IP system unchunks the response, processes the HTTP content, re-adds the chunk trailer headers, and then passes the response on as chunked. Any chunk extensions are lost.
Same as Rechunk.
The BIG-IP system processes the HTTP content and then passes the response on untouched.
The BIG-IP system leaves the response chunked, processes the HTTP content, and passes the response on untouched. Note that if HTTP compression is enabled, the BIG-IP system does not compress the response.
The BIG-IP system processes the HTTP content and then passes the response on untouched.
This setting enables or disables part of the OneConnectTM feature and applies to HTTP/1.0 connections only. When this setting is enabled and a OneConnect profile is assigned to the virtual server, the setting performs Connection header transformations, for the purpose of keeping a client connection open. More specifically:
3.
The BIG-IP system transforms the Connection: Close header to Connection: Keep-Alive.
4.
Through use of the OneConnect profile, the server-side connection detaches, goes into the pool of available server-side connections used for servicing other requests, and eventually closes. This process is hidden from the client.
5.
The client-side connection remains open, operating under the assumption that the server-side connection is still open and therefore able to accept additional requests from that client.
The default value for this setting is Enabled. To enable or disable OneConnect transformations, locate and enable the OneConnect Transformations setting.
Important: For this setting to take effect, you must also configure a OneConnectTM profile, which enables connection pooling. For more information on connection pooling and configuring a OneConnect profile, see Chapter 5, Understanding Profiles.
For general information on the OneConnectTM feature, see Chapter 1, Introduction to Local Traffic Management.
Sometimes, a client request is redirected from the HTTPS protocol to the HTTP protocol, which is a non-secure channel. If you want to ensure that the request remains on a secure channel, you can cause that redirection to be rewritten so that it is redirected back to the HTTPS protocol.
Note that the rewriting of any redirection takes place only in the HTTP Location header of the redirection response, and not in any content of the redirection.
To enable the BIG-IP system to rewrite HTTP redirections, you simply specify, through the Configuration utility, the way that you want the system to handle URIs during the rewrite. Once enabled, this feature rewrites the protocol name port number
Possible values for this setting are Matching, All, Nodes, or None.
When configuring the BIG-IP system to rewrite HTTP redirections, you specify whether the system should rewrite only those URIs matching the URI originally requested by the client (minus an optional trailing slash), or whether the system should rewrite all URIs. In the latter case, the system always rewrites redirected-to URIs, and rewrites those URIs as if they matched the originally-requested URIs.
If the URI contains a node IP address instead of a host name, you can configure the BIG-IP system to change that IP address to the virtual server address.
Table 6.3 shows examples of how redirections of client requests are transformed when the BIG-IP system is listening on port 443, and the Rewrite Redirections setting is enabled.
Table 6.4 shows examples of how redirections of client requests are transformed when the system is listening on port 4443, and the rewrite feature is enabled.
When configured to rewrite HTTP redirections, the BIG-IP system rewrites the HTTP protocol name to HTTPS. For example, a client might send a request to https://www.sample.com/bar and be initially redirected to http://www.sample.com/bar/, which is a non-secure channel. If you want the client request to remain on a secure channel, you can configure the BIG-IP system to rewrite the redirected URI to go to https://www.sample.com/bar/ instead. (Note the addition of the trailing slash.)
You can use the Configuration utility to encrypt one or more cookies that the BIG-IP system sends to a client system. When the client sends the encrypted cookie back to the BIG-IP system, the system decrypts the cookie.
To encrypt a cookie, use the Encrypt Cookie setting to specify the name of the cookie that you want to the BIG-IP system to encrypt. If you want to specify more than one cookie, simply separate the cookie names with a space.
After specifying one or more cookie names, use the Cookie Encryption Passphrase and the Confirm Cookie Encryption Passphrase boxes to type a passphrase for the cookie.
With the Maximum Header Size setting, you can specify the maximum size that the BIG-IP system allows for HTTP headers. The default value is 32768 and is represented in bytes.
Normally, a client cannot initiate a request until the previous request has received a response. HTTP/1.1 pipelining allows clients to initiate multiple requests even when prior requests have not received a response. Note, however, that each initiated request is still processed sequentially; that is, a request in the queue is not processed until the previous request has received a response.
By enabling support for pipelining on the BIG-IP system, you remove the need to enable pipelining on the destination server itself.
To enable or disable pipelining, locate the Pipelining setting and check the box. By default, this feature is set to Enabled.
When using connection pooling, which allows clients to make use of existing server-side connections, you can insert the XForwarded For header into a request. When you configure the BIG-IP system to insert this header, the target server can identify the request as coming from a client other than the client that initiated the connection. The default setting is Disabled.
The LWS Maximum Columns setting specifies the maximum number of columns allowed for a header that is inserted into an HTTP request.
To configure the LWS Maximum Columns setting, specify a maximum value. The default value for this setting is 80.
The LWS Separator setting specifies the separator that the BIG-IP system should use between HTTP headers when a header exceeds the maximum width specified by the LWS Maximum Columns setting.
To configure the LWS Separator setting, specify a value for the separator. This setting has no default value.
The Maximum Requests setting specifies the maximum number of requests that the system allows for a single Keep-Alive connection. When the specified limit is reached, the final response contains a Connection: close header is followed by the closing of the connection. The default setting is 0, which in this case means that the system allows an infinite number of requests per Keep-Alive connection.
In a typical client-server scenario, browsers and servers can be configured to compress and uncompress HTTP content. HTTP compression reduces the amount of data to be transmitted, thereby significantly reducing bandwidth usage. The following two sections describe the benefits of configuring the BIG-IP system to perform HTTP compression tasks.
When HTTP compression is enabled in a client-server environment, a browser inserts an Accept-Encoding header into a client request, specifying the compression methods that the browser understands. Consequently, the server reads the header and compresses the response body with one of those compression methods. The server then inserts a Content-Encoding header in the response, to communicate to the browser the compression method that the server used. Upon receiving the compressed response, the browser reads the Content-Encoding header and uncompresses the data accordingly.
Enabling HTTP compression without a BIG-IP system typically requires installation and configuration of compression software on the destination server.
An optional feature is the BIG-IP systems ability to off-load HTTP compression tasks from the target server. All of the tasks needed to configure HTTP compression on the BIG-IP system, as well as the compression software itself, are centralized on the BIG-IP system.
The primary way to enable the HTTP compression option is by setting the Compression setting of an HTTP profile to Enabled. This causes the BIG-IP system to compress HTTP content for any responses in which the the values that you specify in the URI List or Content List settings of an HTTP profile match the values of the Request-URI or Content-Type response headers.
Note: The string that you specify in the URI List or the Content List setting can be either a pattern string or a regular expression. Note that list types are case-sensitive for pattern strings. For example, the system treats the pattern string www.f5.com differently from the pattern string www.F5.com. You can override this case-sensitivity by using the Linux regexp command.
Important: When you enable compression by configuring an HTTP profile, the system uses a default compression strategy named Speed. The Speed compression strategy ensures that the BIG-IP system uses the hardware compression provider whenever possible, to maximize performance. You can change the compression strategy by using a command line interface. For a detailed description of the available compression strategies, see Working with data compression strategies.
If you want to enable HTTP compression for specific connections, you can write an iRule that specifies the HTTP:compress enable command. For more information, see Chapter 17, Writing iRules, and the F5 Networks DevCentral web site, http://devcentral.f5.com.
1.
First, the BIG-IP system reads the Accept-Encoding header of a client request, looks for specification of either the deflate or gzip compression method, and notes whether either method is marked as being preferred.
2.
If the Keep Accept Encoding setting in the HTTP profile is set to Disabled, the BIG-IP system then removes the Accept-Encoding header from the request and passes the request on to the server. Removing the Accept-Encoding header prevents the server from performing the HTTP compression and from inserting the Content-Encoding header into its response.
3.
Upon receiving the server response, the BIG-IP system inserts the Content-Encoding header, specifying the compression method that it has chosen to use. The BIG-IP system chooses a compression method by looking for the specification of either the gzip or deflate compression method in the Accept-Encoding header of the client request. If the client request does not specify a compression method, the BIG-IP system can use either the gzip or deflate method to compress the response data. In this case, the default method that the BIG-IP system uses is gzip.
4.
Finally, the BIG-IP system then compresses the response and sends it to the client. The client then reads the Content-Encoding header in the response, determines the compression method used, and uncompresses the data accordingly.
Using the BIG-IP system HTTP compression feature, you can include or exclude certain types of URIs or files that you specify. Exclusion is useful because some URI or file types might already be compressed. Using CPU resources to compress already-compressed data is not recommended because the cost of compressing the data usually outweighs the benefits. Examples of regular expressions that you might want to specify for exclusion are.*\.pdf,.*\.gif, or.*\.html.
Although creating a custom HTTP profile is the primary way to implement data compression on the BIG-IP system, there are other ways to implement data compression:
You can implement the default http-wan-optimized-compression profile as is. This profile contains settings that are already configured to optimize data compression. This is a simpler configuration task, but it gives you less control over the type of data being compressed. For more information, see Using the http-wan-optimized-compression profile.
You can create a custom profile based on the http-wan-optimized-compression profile, and then modify the compression settings. For more information, see Using the http-wan-optimized-compression profile.
For a more advanced compression implementation, you can create a custom profile based on the default http profile, and then configure a different compression strategy using a command line interface. Different compression strategies affect the way that the system uses hardware and software compression providers to provide the most efficient compression possible. For more information, see Working with data compression strategies.
As previously described, one way to implement data compression is to create a custom profile based on the default http profile. Table 6.5 shows the compression settings that you can specify within a custom HTTP profile that you create. Configuring these settings means either specifying a value where no default value exists, or changing a default value.
Displays the settings for including or excluding certain Request-URI responses. Possible values are URI List or Not Configured.
If the URI Compression setting is set to Enabled, specifies the URI targeted for compression, as well as the types of responses to include for and exclude from URI compression.
Note: When you use pattern strings, this list type is case-sensitive. For more information, see the previous section of this chapter.
Displays the settings for including or excluding certain Content-Type responses. Possible values are Content List or Not Configured.
If the Content Compression setting is set to Enabled, specifies the type of content targeted for compression, as well as the type of responses to include for or exclude from content compression.
Note: When you use pattern strings, this list type is case-sensitive. For more information, see the previous section of this chapter.
In the Include List box, default values are:
text/
application/(xml|x-javascript)
Specifies the compression method that you want to use to compress the response. Possible values are gzip and deflate.
Specifies the minimum length in bytes of a server response that is acceptable for compressing that response. The length applies to content length only, not headers.
Specifies the maximum number of compressed bytes that the BIG-IP system buffers before deciding whether or not to insert a Content-Length header into the response that specifies the compressed size.
Specifies the number of kilobytes of memory that the BIG-IP system uses for internal compression buffers when compressing a server response.
Specifies the number of kilobytes in the window size that the BIG-IP system uses when compressing a server response.
Enables or disables the insertion of a Vary header into cacheable server responses.
Keep Accept Encoding
When enabled, allows the target server to perform the HTTP compression instead of the BIG-IP system.
Browser Workarounds
Specifies, when checked (enabled), that the system monitors the percent CPU usage and adjusts compression rates automatically when the CPU usage reaches either the CPU Saver High Threshold or the CPU Saver Low Threshold.
Enabled (Checked)
Specifies the amount of CPU usage that causes the system to change the amount of content being compressed, and the amount of compression being applied.
Specifies the amount of CPU usage that causes the system to revert back to user-defined compression values.
The Compression setting causes the BIG-IP system to perform compression on server responses. Possible values are:
Enabled
This value causes the BIG-IP system to compress, or refrain from compressing, HTTP server content for any responses matching the values that you specify in the URI List or Content List settings of the HTTP profile.
Disabled
When the Compression setting is set to Disabled, the BIG-IP system does not perform HTTP compression.
Selective
This setting causes the BIG-IP system to perform HTTP compression only when specified by an iRule containing the HTTP::compress command.
To enable HTTP compression, locate the Compression setting and select Enabled. If you are enabling compression through the use of the iRule command HTTP::compress <enable>, select Selective.
If you enable compression, you probably do not want the BIG-IP system to compress every kind of server response. Using the URI Compression setting, you can set its value to URI List, which instructs the BIG-IP system to include in compression, or exclude from compression, certain responses that are specified in the URIs of client requests.
More specifically, you can type regular expressions to specify the types of server responses that you want the BIG-IP system to include in, or exclude from, compression. For example, you can specify that you want the BIG-IP system to compress all .htm responses by typing the regular expression .*.htm. The BIG-IP system then compares that response type to the URI specified within each client request, and if the system finds a match, takes some action.
To use the URI Compression feature, locate the URI Compression setting and select URI List. You can then use the Include List box or the Exclude List box to type your regular expressions. If you do not specify any list (either URI or content), the BIG-IP system compresses all responses. For more information on content lists, see Using content compression.
When the URI compression setting is enabled, and you type one or more values in the Include List, the BIG-IP system compresses only those responses that match the URI part of the client request line.
The values you specify in the Include List box are in the form of regular expressions. For example, if the Include List box contains the values .*.txt, .*.htm, and .*.html, and those expressions match URIs in client requests, then the BIG-IP system compresses only the responses for those URIs that match the specified regular expressions.
To apply this setting successfully, the BIG-IP system must find a match in at least one of the values specified in the Include List box. If the BIG-IP system finds no match, then no response is compressed.
When the URI compression setting is enabled, and you type one or more values in the Exclude List, the BIG-IP system excludes from compression those responses that match the URI part of the client request line.
The values you specify in the Exclude List box are in the form of regular expressions. For example, if the Exclude List box contains the value .*.pdf, and that expression matches URIs in client requests, then the BIG-IP system excludes from compression any .pdf responses for those URIs.
To apply this setting successfully, the BIG-IP system must find a match in at least one of the values specified in the Exclude List box. If the BIG-IP system finds no match, then no responses are excluded from compression.
If you enable compression, you probably do not want the BIG-IP system to compress every kind of server response. Using the Content Compression setting, you can set its value to Content List, which instructs the BIG-IP system to include in compression, or exclude from compression, certain responses that are specified in the Content-Type header of server responses.
More specifically, you can type regular expressions to specify the types of server responses that you want the BIG-IP system to include in, or exclude from, compression. For example, you can specify that you want the BIG-IP system to compress all .htm responses by typing the regular expression .*.htm. The BIG-IP system then compares that response type to the value of the Content-Type header specified within each server response, and if the system finds a match, takes some action.
To use the Content Compression feature, locate the Content Compression setting and select Content List. You can then use the Include List box or the Exclude List box to type your regular expressions. If you do not specify any list (either URI or content), the BIG-IP system compresses all responses. For more information on content lists, see Using URI compression.
When compression is enabled and you specify one or more values in the Include List box, the BIG-IP system includes only those responses that match the value of the servers Content-Type header. The value of this setting is a list of those header values. For example, if the Include List box contains the values application/pdf and image/**, then only responses of those content types are compressed.
When compression is enabled and you specify one or more values in the Exclude List box, the BIG-IP system excludes those responses that match the value of the servers Content-Type header. The value of this setting is a list of those header values. For example, if the Exclude List box contains the values application/pdf and image/**, then responses of those content types are excluded from compression.
Using the Preferred Method setting, you can specify the compression method that you want the BIG-IP system to use when compressing responses. The two possible values are gzip and deflate. The default value is gzip.
When compression is enabled, the Minimum Content Length setting specifies the minimum length of a server response in uncompressed bytes that the BIG-IP system requires for compressing that response. The BIG-IP system finds the content length of a server response in the Content-Length header of the server response. Thus, if the content length specified in the response header is below the value assigned to the Minimum Content Length setting, the BIG-IP system does not compress the response. The length in bytes applies to content length only, not headers.
For example, using the default value of 1024, the BIG-IP system compresses only those responses with HTTP content containing at least 1024 bytes.
Sometimes the Content-Length header does not indicate the content length of the response. In such cases, the BIG-IP system compresses the response, regardless of size.
To specify a minimum content length, locate the Minimum Content Length setting, and type a numeric value.
When compression is enabled, the Compression Buffer Size setting specifies the maximum number of compressed bytes that the BIG-IP system buffers before deciding whether or not to preserve a Keep-Alive connection and rewrite the Content-Length header.
For example, using the default value of 4096, the BIG-IP system buffers up to 4096 bytes of compressed data before deciding whether or not to preserve the connection and rewrite the Content-Length header.
The BIG-IP systems decision to rewrite the Content-Length header depends on whether response chunking is enabled (using the Response Chunking profile setting). Table 6.6, shows the behavior of the BIG-IP system with respect to compression buffer size and response chunking.
Keeps the connection open (if the Connection header is not set to Close).
Closes the connection by changing the value of the Connection header to Close.
Does not insert a Content-Length header with a compressed response size.
Inserts a Content-Length header with a compressed response size.
To specify a compression buffer size, locate the Compression Buffer Size setting and type a numeric value.
Using the gzip Compression Level setting, you can specify the extent to which data is compressed, as well as the compression rate. Possible values are 1 - Least Compression (Fastest), 9 - Most Compression (Slowest), and Other. The default compression level is 1 - Least Compression (Fastest).
You can specify any whole number ranging from 1 through 9, with these results:
Specifying a lower number causes data to be less compressed but at a higher performance rate. Thus, a value of 1 causes the least compression but the fastest performance.
Specifying a higher number causes data to be more compressed but at a slower performance rate. Thus, a value of 9 (the highest possible value) causes the most compression, but the slowest performance.
Warning: Selecting any value other than 1 - Least Compression (Fastest) can degrade system performance.
Tip: You can change the way that the BIG-IP system uses gzip levels to compress data. You do this by configuring the compression strategy. The compression strategy determines the particular compression provider (hardware or software) that the system uses for HTTP responses. The available strategies are: Speed (the default strategy), Size, Ratio, and Adaptive. For information on how to configure the compression strategy, see Working with data compression strategies.
The gzip Memory Level setting specifies a value representing the amount of kilobytes of memory that the BIG-IP system uses to compress data when using the gzip or deflate compression method. The value of the gzip Memory Level setting must be a power-of-2 integer, in bytes, ranging from 1 to 256.
Generally, a higher value causes the BIG-IP system to use more memory, but results in a faster and higher compression ratio. Conversely, a lower value causes the BIG-IP system to use less memory, but results in a slower and lower compression ratio. The default value is 8.
To specify a memory level, locate the gzip Memory Level setting and select a numeric value.
The gzip Window Size setting specifies a value representing the number of kilobytes in window size that the BIG-IP system uses when compressing a server response using the gzip or deflate compression method. The value of the gzip Window Size setting must be a power-of-2 integer, in bytes, ranging from 1 to 128.
Generally, a higher value causes the BIG-IP system to use more memory, but results in a higher compression ratio. Conversely, a lower value causes the BIG-IP system to use less memory, but results in a lower compression ratio. The default value is 16.
To specify a window size, locate the gzip Window Size setting and select a numeric value.
When compression is enabled, the Vary Header setting inserts the Vary: Accept-Encoding header into a compressed server response. If the Vary header already exists in the response, the BIG-IP system appends the value Accept-Encoding to that header.
The reason for inserting the Vary: Accept-Encoding header into a server response is to follow a recommendation by RFC2616, which states that the Vary header should be inserted into any cacheable response that is subject to server-driven negotiation. Server responses that are subject to HTTP compression fall into this category.
If the Vary Header setting is disabled, the BIG-IP system does not insert the Vary header into a server response.
To disable the Vary header, locate the Vary Header setting and clear the Enabled box.
The HTTP/1.0 Requests setting is included for backward compatibility, allowing HTTP compression for responses to HTTP/1.0 client requests. The default value for this setting is Disabled.
If this setting is set to Enabled, the BIG-IP system only compresses responses in either of the following cases:
When the server responds with a Connection: close header
To enable compression for HTTP/1.0 requests, locate the HTTP/1.0 Requests setting and check the box.
Normally, when you enable HTTP compression, the BIG-IP system strips out the Accept-Encoding header from the HTTP request. This causes the BIG-IP system to perform the HTTP compression instead of the target server.
By default, the Keep Accept Encoding setting is disabled. If you want to allow the target server instead of the BIG-IP system to perform the HTTP compression, simply enable this setting.
When you enable the Browser Workarounds setting, the system uses built-in workarounds for several common browser issues that occur when compressing content. The default setting is disabled (cleared). More specifically, enabling this setting prevents the system from compressing server responses when any of these conditions exist:
The client browser is Netscape version 4.x (that is, versions 4.10 and higher), and the Content-Type header of the server response is not set to text/html or text/plain.
The client browser is Microsoft® Internet Explorer® (any version), the Content-Type header of the server response is set to either text/css or application/x-javascript, and the client connection uses SSL.
The client browser is Microsoft® Internet Explorer® (any version), the Content-Type header of the server response is set to either text/css or application/x-javascript, and the Cache-Control header of the server response is set to no-cache.
When you enable the CPU Saver setting, the system monitors the percent CPU usage and adjusts compression rates automatically when the CPU usage reaches the percentage defined in either the CPU Saver High Threshold or the CPU Saver Low Threshold. The default setting is enabled (checked).
The CPU Saver High Threshold setting specifies the percent of CPU usage at which the system starts automatically decreasing the amount of content being compressed, as well as the amount of compression which the system is applying. The default setting is 90 percent.
The CPU Saver Low Threshold specifies the percent CPU usage at which the system resumes content compression at the user-defined rates. The default setting is 75 percent.
If you need more control over the way that the BIG-IP system compresses data than what the standard HTTP profile configuration provides, you can enable a compression strategy other than the default strategy. The default compression strategy is Speed.
This section describes the compression providers available on the BIG-IP system, the four available compression strategies, and detailed information on using the Adaptive compression strategy in particular.
Note: A BIG-IP command line interface is the only tool available for setting the compression strategy. If you do not explicitly set the strategy, or you are using the Configuration utility rather than the command line interface to configure compression, the BIG-IP system uses the Speed strategy as the default strategy.
The BIG-IP system utilizes compression providers to compress HTTP server responses. The compression providers are either hardware cards or software programs that you can install on multiprocessor BIG-IP systems to perform HTTP data compression. The software and hardware compression providers that the BIG-IP system can use to compress data are:
A hardware compression card
A hardware compression card increases the speed at which data is compressed. A hardware compression card is optional on the 6400, 6800, and 8400 BIG-IP platforms. On the 8800 platform, a hardware compression card is always included.
zlib
The zlib tool is a software compression provider included in the BIG-IP system software. The BIG-IP system uses zlib only when the hardware compression card is too busy to compress additional data.
It important to understand that hardware compression providers cannot match the highest quality compression level that software compression providers perform. Conversely, software compression providers require more system resources than hardware compression providers to deliver the highest quality compression.
When using the command line interface to configure compression for a BIG-IP system, you can choose from four compression strategies: Speed, Size, Ratio, and Adaptive. The BIG-IP system uses the compression strategy that you select to determine which compression provider to use for a given HTTP response. Once an HTTP response is assigned to a compression provider, the response remains associated with that compression provider until the response is completed.
Table 6.7 describes the four compression strategies.
Compression Strategies
The system uses the hardware compression provider to the fullest extent possible. Only when the hardware is busy does the system use a software compression provider to compress HTTP server responses. The Speed strategy is best used for bulk compression and for limiting CPU overhead.
The system performs as much compression in the software as possible using a ratio of TMM and Offload. Only when the software is busy does the system use the hardware compression provider to compress HTTP server responses. The Size strategy gives the best ratio at the expense of CPU overhead.
The system uses a weighted Round Robin approach to decide which compression provider to use to compress data. The Ratio strategy limits CPU overhead while giving good compression ratios.
The system first uses a software compression provider to compress HTTP server responses. The system switches to the hardware compression providers based on both the gzip compression level that you set in the HTTP profile and the hardware compression provider that the system contains.
As load on the system increases, the system responds by reducing the desired gzip compression level (specified in the HTTP profile). The system utilizes the hardware compression provider only when the provider can deliver the specified or systematically-reduced gzip compression level.
The adaptive compression strategy specifies that the BIG-IP system can use both software and hardware compression providers in the most efficient way possible to provide the best quality of compression, while still ensuring availability of resources for load balancing. When adaptive compression is enabled, the system selects from the available compression providers to compress HTTP server responses based on a desired level of quality (gzip level) that you specify. Adaptive compression provides the most benefit when you have a BIG-IP 6400, 6800, or 8400 system that contains a hardware compression card.
When the load on the system decreases, the adaptive compression strategy allows the system to incrementally increase the quality of the compression of server responses.
When the load on the system increases, the adaptive compression strategy allows the system to incrementally decrease the quality of the compression of server responses. This frees the system resources to handle the load balancing of the increased traffic.
When traffic reaches a peak volume, and based on the gzip compression level that you set in the HTTP profile, the system begins to compress data using its hardware compression provider.
When you configure the adaptive compression strategy, the particular compression providers that the BIG-IP system uses depends not only on the gzip level you have configured (that is, the desired balance of compression quality and speed), but also the platform type.
Table 6.8 describes the compression providers that each platform uses to compress data.
If a hardware compression card is installed, the system uses the hardware card; if the hardware card is too busy or if no hardware card is installed, the system uses zlib.
If a hardware compression card is installed, the system uses either the hardware card or zlib, depending on the gzip level you have configured; if no hardware card is installed, the system uses zlib.
The system uses either the hardware card or zlib, depending on the gzip level you have configured; if the hardware card is too busy, the system uses zlib.
To understand how adaptive compression operates, you must understand the gzip compression level setting in the HTTP profile. For more information about configuring an HTTP profile using the Configuration utility, including setting gzip compression levels, see the Configuration Guide for BIG-IP® Local Traffic Management.
When you enable adaptive compression, the system utilizes the gzip compression level that you set in the HTTP profile in different ways depending on which hardware compression provider the system contains. When you create an HTTP profile, you set a gzip compression level in the range of 9 - 0. The higher the gzip compression level, the better the quality of the compression, and therefore the more resources the system must use to reach that specified quality.
For example, you might set the gzip compression level to 9 if you are utilizing the BIG-IP system RAM cache feature to store response data. The reason for this is that the stored data in the RAM cache is continually re-used in responses, and therefore you want the quality of the compression of that data to be very high.
As the traffic flow on the BIG-IP system increases, the system automatically decreases the compression quality from the gzip compression level that you set in the profile. When the gzip compression level decreases to the point where the hardware compression provider is capable of providing the specified compression level, the system uses the hardware compression providers rather than the software compression providers to compress the HTTP server responses.
When you enable adaptive compression on a BIG-IP 6400, 6800, or 8400 system that contains a hardware card, the gzip compression level setting of the HTTP profile affects how the system performs compression.
Table 6.9, shows the effect of gzip levels on the 6400, 6800, and 8400 platforms.
Between 9 and 2, inclusive
The software compression providers perform the compression based on both the specified level and the load on the system. When the number of tasks handled by the software compression providers exceeds a certain value (defined by the bigdb key Compression.ProviderBusy), the hardware compression provider begins to compress the responses. When the load lessens and more resources become available, the software compression provider again begins to compress the responses.
The BIG-IP system attempts to use the software compression providers before using the hardware compression provider, unless the bigdb configuration key Compression.Adaptive.AHA.UseAtGzip1 is enabled. If this key is enabled, then the system attempts to use the hardware compression provider.
The BIG-IP system attempts to use the hardware compression provider before using the software compression providers. Also, when using the hardware compression provider, the system performs the minimum compression possible.
Note: The system always performs some amount of compression when the gzip level is set to 0.
When you enable adaptive compression on a BIG-IP 8800 system that contains a hardware card, the gzip compression level setting of the HTTP profile affects how the system performs compression.
Table 6.10, shows the effect of gzip levels on an 8800 platform.
Between 9 and 4, inclusive
When you set the gzip compression level to between 9 and 4, inclusive, the software compression provider performs the compression until the system load begins to increase. Then the BIG-IP system adaptively reduces the gzip level (that is, the quality of the compression).
When the number of tasks handled by the software compression providers exceeds a certain value (defined by the bigdb key Compression.ProviderBusy), the hardware compression provider begins to compress the responses. When the number of tasks handled by the software compression providers falls below that same value, the software compression providers resume compressing the responses.
Between 3 and 0, inclusive
When you set the gzip compression level to between 3 and 0, inclusive, the hardware compression provider performs the compression until the number of tasks exceeds a certain value (defined by the bigdb key Compression.ProviderBusy). Then the software compression providers begin to compress the responses. When the number of tasks performed by the hardware compression providers falls below that same value, the hardware compression provider resumes compressing the responses.
Note: The hardware provider does not support gzip levels 1 and 0. Therefore, if you specify 1 or 0, the hardware provider actually compresses the data at a level of slightly above 2. When the hardware compression provider becomes busy, the software providers can compress the data at level 1 or 0.
To configure adaptive compression, you not only configure the compression settings in a custom HTTP profile, but also use one of the command line interfaces. Using a command line interface is the way to change the compression strategy from Speed (the default strategy) to Adaptive.
Note that the Adaptive compression strategy uses the gzip Compression Level setting that you configure in the HTTP profile. For more information on gzip levels and the gzip Compression Level setting in particular, see Understanding gzip levels and Specifying a compression level.
You can use the bigpipe utility to view compression statistics for the BIG-IP system. You can view information about traffic throughput, as well as compression ratio totals for each hardware compression provider.
Table 6.11, describes the compression statistics that are available.
Compression statistic
Note: The system wraps content in compression headers, but does not compress the content when one of two situations occurs: either the system exceeds the amount of compression (in megabytes) for which it is licensed, or the CPU saver is active.
Figure 6.1 shows an example of the results of the bigpipe command http show. Note that any compression statistics appear in the last line of the output.
Figure 6.1 Sample output of the http show command on a BIG-IP 8800 system
This section describes how to configure the properties of the RAM Cache feature on the BIG-IP system. A RAM cache is a cache of HTTP objects stored in the BIG-IP systems RAM that are reused by subsequent connections to reduce the amount of load on the back-end servers.
The RAM Cache feature provides the ability to reduce the traffic load to back-end servers. This ability is useful if an object on a site is under high demand, if the site has a large quantity of static content, or if the objects on the site are compressed.
High-demand objects
This feature is useful if a site has periods of high demand for specific content. With the RAM cache configured, the content server only has to serve the content to the BIG-IP system once per expiration period.
Static content
This feature is also useful if a site consists of a large quantity of static content such as CSS files, javascript files, or images and logos.
Content compression
For compressible data, the RAM cache can store data for clients that can accept compressed data. When used in conjunction with the compression feature on the BIG-IP system, the RAM cache takes stress off of the BIG-IP system and the content servers.
The RAM Cache feature is fully compliant with the cache specifications described in RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1. This means you can configure the RAM Cache feature to cache the following content types:
200, 203, 206, 300, 301, and 410 responses
Responses to GET methods, by default
Content based on the User-Agent and Accept-Encoding values. The RAM cache holds different content for Vary headers.
HEAD, PUT, DELETE, TRACE, and CONNECT methods, by default
The default RAM cache configuration caches only responses to HTTP GET methods. However, you can use the RAM cache to cache other methods, too, including non-HTTP methods. You do this by specifying a URI in the URI Include or Pin list within an HTTP profile, or by writing an iRule.
What is the effect of adding URIs to the Include List in the HTTP profile?
What is the order of preference that the BIG-IP system uses when processing the Pin List, Include List, and Exclude List?
The BIG-IP system determines which responses to cache by evaluating both the HTTP request and the response. Table 6.12 shows the criteria within both a request and a response that the system uses before determining whether to include or exclude a response from the cache.
The system invokes a CACHE::disable command within an HTTP_REQUEST event.
The request matches an item in the Exclude list of the HTTP profile.
The request matches an item in the Pin list of the HTTP profile.
The request matches an item in the Include list of the HTTP profile.
The request specifies a method other than GET, including non-standard HTTP methods.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The value of the Vary header consists of the User-Agent and/or Accept-Encoding request header only.
Include multiple response for a single URL
The value of the Vary header changes in a subsequent response for the same resource.
Invalidates any existing cache entries
The value of the Vary header consists of any other request headers or the special value * (asterisk)
200 (OK)
203 (Non-Authoritative Information)
206 (Partial Content)
300 (Multiple Choices)
301 (Permanent Redirect)
410 (Gone)
The value of the Content-Length header in the response is 0.
Always, except when the response has no Content-Length header, that is, with chunked Transfer-Encoding, or the response relies on connection termination by the server.
The object size of the response is outside the configured minimum and maximum response object size and the maximum cache size.
Note: The term object size refers to response headers as well as the body of the response.
Always, whenever the object size exceeds the maximum cache size.
Otherwise, always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The response contains an Expires header that has an invalid value.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The response contains a Cache-Control header with any of these values: no-store, no-cache, or private.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
The request contains an Authorization header, and the Cache-Control header in the response lacks any of these values: s-maxage, must-revalidate, public.
Always, except when overridden by an item in the Pin or Include lists, or by an iRule.
For URIs in the Include List of an HTTP profile, the BIG-IP system caches responses for all request methods. All other constraints still apply.
When using URI lists to determine which response you want the BIG-IP system to cache, the system uses the following order of preference, in decreasing order:
Exclude List
Pin List
Include List
The BIG-IP system takes certain actions on cached content, depending on the type of content. Table 6.13 lists and describes these actions.
The BIG-IP system adds a Date header to cached content that includes the current time on the BIG-IP system.
The system also adds an Age header to cached content that reflects the amount of time that the item has been in the cache. Note that this setting is enabled by default in the HTTP profile. You can disable this setting by disabling the Insert Age Header in the profile.
The RAM cache removes the least frequently used items in the cache. This prevents stale items from taking up room in the cache when newer items are selected for caching. The cache also uses a scoring system to remove stale items after a period of time. When a cached item reaches its age limit, the item expires and the system removes it from the cache. You can use the HTTP profile attributes to control the size of each cache instance and the rate at which the BIG-IP system removes expired items from the cache. For more information about these attributes, see the following section, Understanding RAM Cache settings.
To configure the RAM cache, you need to configure the RAM Cache settings of the HTTP profile. These settings provide the ability to turn on the cache and fine-tune it for a specific implementation. In addition to configuring the RAM cache objects in the HTTP profile, you may want to use bigpipe utility commands, configure bigdb configuration keys, or create iRules. For information on bigdb keys related to the RAM Cache feature, see Appendix B of the Bigpipe Utility Reference Guide. For information on creating iRulesTM for the RAM cache, see the F5 Networks web site http://devcentral.f5.com.
The default items stored by the cache are HTTP GET responses. However, you can specify URIs in the URI list if you want to cache POST and GET methods for a particular URI.
You can create a custom profile based on the default http profile, and then modify the RAM Cache settings.
You can implement the http-lan-optimized-caching profile as is. This profile contains settings that are already configured to optimize RAM caching.
You can create a custom profile based on the http-lan-optimized-caching profile, and then modify the RAM Cache settings.
As previously described, one way to implement the RAM cache is to create a custom profile based on the default http profile. Table 6.14 shows the RAM cache settings that you can specify within a custom HTTP profile that you create. Configuring these settings means either specifying a value where no default value exists, or changing a default value.
Specifies the maximum size in megabytes for the RAM cache. When the cache reaches the maximum size, the system starts removing the oldest entries.
Specifies whether the system retains or excludes certain URIs in the RAM cache. The process forces the system either to cache URIs that typically are ineligible for caching, or to not cache URIs that typically are eligible for caching.
Specifies the Uniform Resource Identifiers (URIs) that the system either includes in or excludes from caching.
Pin List
Lists the URIs for responses that you want the system to store indefinitely in the RAM cache.
Include List
Lists the URIs that are typically ineligible for caching, but the system caches them. When you add URIs to the Include List, the system caches the GET methods and other methods, including non-HTTP methods.
Exclude List
Lists the URIs that are typically eligible for caching, but the system does not cache them.
Specifies how the system processes client-side Cache-Control headers when RAM caching is enabled.
All
Specifies that the system disregards all Cache-Control headers.
Cache-Control:max-age
Specifies that the system ignores only the Cache-Control:max-age header.
None
Specifies that the system honors all Cache-Control headers.
Specifies, when enabled, that the system inserts Date and Age headers in the cached entry. The Date header contains the current date and time on the BIG-IP system. The Age header contains the length of time the content has been in the cache.
Specifies how quickly the system ages a cache entry. The aging rate ranges from 0 (slowest aging) to 10 (fastest aging).
The BIG-IP system contains a set of custom HTTP profiles that F5 Networks has already created for you. The purpose of these profiles is to optimize the performance of data compression and RAM caching. Based on the http default profile, these F5-defined profiles are pre-configured specifically to ensure optimal compression and RAM cache performance. These profiles are:
The http-acceleration profile is an HTTP-type profile. This profile is effectively a custom profile that the BIG-IP system has already created for you. By implementing the http-acceleration profile, you can accelerate HTTP traffic, without having to create a custom profile to do so.
In some cases, you can simply enable the http-accleration profile from within another BIG-IP system module, such as the BIG-IP WebAccelerator system.
The http-acceleration profile inherits its settings and their default values from the http profile, but some of the setting values have been changed. This profile is a good choice to use when you want to optimize HTTP acceleration, while still using the default values from the http profile for the other configuration settings.
You can use the http-accleration profile as is, or you can create another custom profile, specifying the http-acceleration profile as the parent profile.
Most of the default values of the http-acceleration profile are the same as the default values of the http profile. However, a few default values are different, and these are listed in Table 6.15.
Table 6.15 Values of an http-acclerator profile that differ from those of the http profile
The http-wan-optimized-compression profile is an HTTP-type profile. This profile is effectively a custom profile that the BIG-IP system has already created for you. By implementing the http-wan-optimized-compression profile, you can optimize the performance of data compression, without having to create a custom profile to do so.
The http-wan-optimized-compression profile inherits its settings and their default values from the http profile, but some of the setting values have been changed. This profile is a good choice to use when you want to optimize data compression, while still using the default values from the http profile for the other configuration settings.
You can use the http-wan-optimized-compression profile as is, or you can create another custom profile, specifying the http-wan-optimized-compression profile as the parent profile.
Most of the default values of the http-wan-optimized-compression profile are the same as the default values of the http profile. However, a few default values are different, and these are listed in Table 6.16.
Table 6.16 Values of an http-wan-optimized-compression profile that differ from those of the http profile
Specifies the maximum number of compressed bytes that the BIG-IP system buffers before deciding whether or not to insert a Content-Length header into the response that specifies the compressed size.
1 - Least Compression (Fastest)
Specifies the number of kilobytes of memory that the BIG-IP system uses for internal compression buffers when compressing a server response.
Specifies the number of kilobytes in the window size that the BIG-IP system uses when compressing a server response.
Enables or disables the insertion of a Vary header into cacheable server responses.
Specifies how to handle chunking for HTTP responses. Possible values are Unchunk, Rechunk, Selective, and Preserve.
The http-lan-optimized-caching profile is an HTTP-type profile. This profile is effectively a custom profile that the BIG-IP system has already created for you. By implementing the http-lan-optimized-caching profile, you can optimize the performance of RAM caching, without having to create a custom profile to do so.
The http-lan-optimized-caching profile inherits its settings and their default values from the http profile, but some of the setting values have been changed. This profile is a good choice to use when you want to optimize RAM caching, while still using the default values from the http profile for the other configuration settings.
You can use the http-lan-optimized-caching profile as is, or you can create another custom profile, specifying the http-lan-optimized-caching profile as the parent profile.
Most of the default values of the http-lan-optimized-caching profile are the same as the default values of the http profile. However, a few default values are different, and these are listed in Table 6.17.
Table 6.17 Values of an http-lan-optimized-caching profile that differ from those of the http profile
Specifies the maximum size in megabytes for the RAM cache. When the cache reaches the maximum size, the system starts removing the oldest entries.
The http-wan-optimized-compression-caching profile is another type of HTTP profile. The http-wan-optimized-compression-caching profile combines the default configuration values of the http, http-wan-optimized-compression, and http-lan-optimized-caching profiles. This profile is a good choice to use when you want to optimize both data compression and RAM caching, while still using the default values from the http profile for the other configuration settings.
The BIG-IP system includes a profile type that you can use to manage File Transfer Protocol (FTP) traffic. You can tailor FTP profile settings to your specific needs. For those settings that have default values, you can retain those default settings or modify them. You can modify any settings either when you create the profile, or at any time after you have created it. For specific procedures on configuring a profile, see Chapter 5, Understanding Profiles.
Table 6.18 lists these configurable settings, along with a short description of each, and the default values. Following this table are descriptions of specific settings.
Specifies the user-supplied name of the profile. Specifying a name for your profile is required.
Ensures compatibility between IP version 4 and IP version 6 clients and servers when using the FTP protocol.
Specifies, when checked (enabled), that the system inspects FTP traffic for security vulnerabilities, by using a security profile in BIG-IP® Protocol Security Module. This option is available only when you are licensed for the module.
Before configuring an FTP profile, it is helpful to have a description of certain node settings that you might want to change.
To create an FTP profile, you must specify a unique name for the profile. The Name setting is one of only two settings for which you must actively specify a value when creating an FTP profile; all other settings have default values.
Every profile that you create is derived from a parent profile. In the Parent Profile setting, you can select the default ftp profile as the parent profile, or you can select another FTP profile that you have already created.
Because IP version 6 addresses are not limited to 32 bits (unlike IP version 4 addresses), compatibility issues can arise when using FTP in mixed IP-version configurations.
Enabled by default, the Translate Extended setting causes the BIG-IP system to automatically translate FTP commands when a client-server configuration contains both IP version 4 (IPv4) and IP version 6 (IPv6) systems. For example, if a client system running IPv4 sends the FTP PASV command to a server running IPv6, the BIG-IP system automatically translates the PASV command to the equivalent FTP command for IPv6 systems, EPSV.
It is highly unlikely that you will need to change the default value (Enabled) for this setting. The only case where you might want to disable this setting is when sending an EPSV command to an IPv4 system, such as when testing an FTP server.
The Data Port setting allows the FTP service to run on an alternate port. You can use the default port number 20, or specify another port number.
When the BIG-IP system includes a license for the BIG-IP Application Security Manager, you can enable a security scan for FTP traffic by using the Advanced Firewall feature in the application security configuration. For more information, see Working with the Advanced Firewall, in the Configuration Guide for BIG-IP® Application Security Management.
The BIG-IP system includes a services profile that you can use to manage Session Initiation Protocol (SIP) traffic. Session Initiation Protocol is an application-layer protocol that manages sessions consisting of multiple participants, thus enabling real-time messaging, voice, data, and video. A session can be a simple two-way telephone call or Instant Message dialogue, or a complex, collaborative, multi-media conference call that includes voice, data, and video.
SIP sessions, which are application level sessions, run through one of three Layer 4 protocols: SCTP, TCP, or UDP. The SIP profile configures how the system handles SIP sessions. The specified Layer 4 protocol profile configures the virtual server to open the required port to allow data to flow through the BIG-IP system. When you assign a SIP profile to a virtual server, you can also assign either an SCTP, TCP, or UDP profile to the server. If you do not assign one of these protocol profiles to the server, the BIG-IP system automatically assigns one for you. For more information about protocol profiles, see Chapter 8, Managing Protocol Profiles.
The SIP profile automatically configures the BIG-IP system to handle persistence for SIP sessions using Call-ID. The Call-ID is a globally unique identifier that groups together a series of messages, which are sent between communicating applications. You can customize how the system handles persistence for SIP sessions. To do this, you create a SIP persistence profile. In order to use a SIP persistence profile, you must also use a SIP profile. You assign both the SIP profile and the SIP persistence profile to the same virtual server. For more information about configuring SIP persistence, see Understanding SIP persistence profile settings.
On the New SIP Profile screen in the Configuration utility, the SIP configuration settings are organized into two categories: General Properties, and Settings. When you create a SIP profile, you can implement it as is, or modify the settings. You can also modify the profile at a later date. For specific procedures on configuring a profile, see Chapter 5, Understanding Profiles.
Table 6.19, lists the configurable settings in a SIP profile, along with a short description of each setting and the default value. Following this table are more detailed descriptions of the settings and the procedures for changing them.
Specifies the maximum SIP message size that the BIG-IP system accepts. The system drops the connection if the SIP message is larger than this value.
Specifies that you want the BIG-IP system to snoop SIP dialog information and forward it to a known SIP dialog. Enabling this setting causes the Community setting to appear on the screen.
Disabled
(Unchecked)
Specifies a string to indicate the proxy functional group to which this profile belongs. This setting appears on the screen only when you have enabled the Dialog Aware setting.
Enables or disables the closing of a connection when a BYE transaction finishes. A BYE transaction is a message that an application sends to another application when it is ready to close the connection between the two. When the BIG-IP system encounters a BYE transaction, if the Terminate on BYE setting is enabled, then the system ends the connection. Use this parameter with UDP connections only, not with TCP connections.
Enabled
(Checked)
Enables or disables the insertion of a Via header into a SIP request. A Via header indicates where the message originated. The response message uses this routing information.
When the Insert Via Header setting is enabled, specifies a string that you want the system to insert as the value for the top Via header in a SIP request. This value specifies the SIP protocol, as well as a virtual address and port.
Enables or disables the insertion of a Secure Via header into a SIP request. A Secure Via Header indicates where the message originated. Use this parameter with SSL/TLS to secure the system. The response message uses this routing information.
Disabled
(Unchecked)
Enables or disables the insertion of a Record-Route SIP header, which indicates the next hop for the following SIP request messages.
Disabled
(Unchecked)
To create a SIP profile, you must specify a unique name for the profile. The Name setting is the only setting for which you must actively specify a value when creating a SIP profile; all other settings have default values.
To specify a profile name, simply locate the Name setting and type a unique name for the profile.
Every profile that you create is derived from a parent profile. You can use the default sip profile as the parent profile, or you can use another SIP profile that you have already created.
To specify a parent profile, locate the Parent Profile setting and select a profile name.
The BIG-IP system accepts incoming SIP messages that are 65535 bytes or smaller. If a SIP message exceeds this value, the system drops the connection.
You can change the maximum message size that the system accepts by typing a different value in the Maximum Size (Bytes) box.
When you enable the Dialog Aware setting, the BIG-IP system snoops SIP dialog information and automatically forwards SIP messages to the known SIP dialog. Enabling this setting causes the Configuration utility to display the Community setting.
With the Community setting, you can specify the name of a proxy functional group. You use this setting in the case where you need multiple virtual servers, each referencing a SIP-type profile, and you want more than one of those profiles to belong to the same proxy functional group. This setting only appears on the screen when you have enabled the Dialog Aware setting.
The BIG-IP system terminates a SIP connection when either the application that initiated the session (client) or the application that answered the initiated session (server) issues a BYE transaction. This is appropriate when a SIP session is running on UDP. However, if you are running SIP on a SCTP or TCP connection, you must disable the Terminate on BYE setting.
To disable the Terminate on BYE setting, click the Custom box, and then clear the Enabled box.
An optional feature in a SIP profile is header insertion. You can specify whether the BIG-IP system inserts headers into SIP requests. Specifically, you can enable or disable insertion of Via headers, Secure Via headers, and Record-Route headers. When you assign the configured SIP profile to a virtual server, the BIG-IP system then inserts the header specified in the profile into any SIP request that the BIG-IP system sends to a pool or pool member.
You can configure the BIG-IP system to insert a Via header into SIP requests to indicate where a SIP message originated. The SIP responses use this routing information to locate the session initiator.
By default, the Insert Via Header setting is disabled. To enable this setting, click the Custom box.
When you enable the Insert Via Header setting, you then specify a User Via value. The User Via value is a string that the system inserts as the value of the top Via header value in a SIP request. The string specifies the SIP protocol, as well as a virtual address and port. An example of a User Via string is SIP/2.0/UDP 10.10.10.10:5060.
When you are using SSL/TLS (over TCP) to create a secure channel with the server node, you can configure the BIG-IP system to insert a Secure Via header into a SIP request. The Secure Via Header setting indicates where the SIP message originated.
By default, the Secure Via Header setting is disabled. To enable this setting, click the Custom box.
You can also configure the BIG-IP system to insert a Record-Route header into SIP requests. The Insert Record-Route Header setting specifies the next hop for the following SIP requests.
By default, the Insert Record-Route Header setting is disabled. To enable this setting, click the Custom box.
You can customize how the BIG-IP system handles persistence for SIP sessions. You do this by creating a specific type of persistence profile called a SIP persistence profile. It is important to note that you must always create and use a SIP services profile (as described in Understanding SIP profile settings) when using a SIP persistence profile. To do this, you create both profiles, and then assign the profiles to the same virtual server. For more information about the SIP persistence profile, see SIP persistence.
The BIG-IP system includes a profile type that you can use to manage Real Time Streaming Protocol (RTSP) traffic. Real Time Streaming Protocol (RTSP) is a protocol used for streaming-media presentations. Using RTSP, a client system can control a remote streaming-media server and allow time-based access to files on a server.
The setup of streaming media over UDP. In this case, the control connection opens the required ports to allow data to flow through the BIG-IP system.
When you assign an RTSP profile to a virtual server, you should also assign a TCP profile. If you do not assign a TCP profile, the BIG-IP system automatically assigns one for you.
Table 6.20 lists the configurable settings in an RTSP profile, along with a short description of each setting and the default values.
Specifies the number of seconds that a UDP connection is idle before the connection is eligible for deletion.
Specifies the largest RTSP request or response header, in bytes, that the BIG-IP system allows before terminating the connection.
Specifies the maximum amount of data, in bytes, that the BIG-IP system buffers, before considering the connection to be unusable and subsequently terminating the connection.
If you are using unicast streams and you enable this setting, the client is able to specify the destination address and port for the streamed data. For security reasons however, the destination address used is the source of the request.
If you are using multicast streams and you enable this setting, the client has permission to supply a different destination for the streamed data.
When this setting is enabled and a disconnected control connection has been resumed, the BIG-IP system persists the resumed control connection to the correct server. Typical clients do not support this behavior.
When this setting is enabled, the system automatically persists Real Networks-tunneled RTSP data over HTTP, which is over the RTSP port. The default value is Enabled. When you disable this setting, a user can override the default behavior with an iRule.
Enabled (Checked)
When checked (enabled), specifies that the system examines the origin of the message to determine whether the message came from the client or the server.
Enabled (Checked)
Specifies whether the RTSP profile is associated with an RTSP proxy configuration. Possible values are: None, External, and Internal.
Specifies a name for the header that the system inserts into a SETUP request. The name must begin with the string X-. The value of this header typically consists of information about the client IP address and is read by another RTSP profile. Note that the system removes this header from the request prior to sending the request to the server for processing.
Specifies the port number that a Microsoft® Media Services server uses. Normally, Microsoft Media Services uses a fixed Realtime Transport Protocol (RTP) port number. With this setting, you can specify a port number instead of using the fixed RTP port number.
Specifies an RTCP port companion of the RTP Port value. Normally, Microsoft Media Services uses a fixed Real-Time Control Protocol (RTCP) port number. With this setting, you can specify a port number instead of using the fixed RTCP port number.
A common configuration for the RTSP profile is one that includes RTSP clients and media servers, as well as RTSP proxies to manage accounting and authentication tasks. In this proxied configuration, you most likely want the streaming media from the servers to pass directly to the client, bypassing the RTSP proxy servers.
To implement this configuration, you configure the BIG-IP system by creating two virtual servers, one for processing traffic to and from the external network, and one for processing traffic to and from the internal network. For each virtual server, you assign a separate RTSP profile.
The RTSP profile on the external virtual server passes client IP address information to the RTSP profile on the internal virtual server.
The RTSP profile on the internal virtual server extracts the client IP address information from the request, processes the media servers response, and opens the specified ports on the BIG-IP system. Opening these ports allows the streaming media to bypass the RTSP proxy servers as the data travels from the server to the client.
The client IP address information is stored in the Proxy Header setting that you specify in the RTSP profile.
The BIG-IP system includes the iSession profile type, which creates an optimization tunnel between two BIG-IP systems that are separated by a wide area network. More specifically, an iSession profile causes the system to:
Table 6.21 lists the configurable settings in an iSession profile, along with a short description of each setting and the default values.
off: Specifies that the system does not use compression.
deflate: Specifies that the system uses the deflate data compression algorithm.
lzo: Specifies that the system uses the Lempel-Ziv-Oberhumer (lzo) data compression algorithm.
bzip2: Specifies that the system uses the bzip2 data compression algorithm.
adaptive: Specifies that the system uses the compression algorithm that is the most suitable for the current traffic.
Specifies that the system saves and reuses connections between the local and remote WAN Optimization Modules.
For terminated iSession traffic, specifies the matching criteria that a client-side BIG-IP system uses to select a target virtual server on the server-side BIG-IP system.
none: Specifies that the system sends the terminated iSession traffic directly to the server.
host match no isession: Specifies that the system matches only host virtual servers with no iSession profile.
host match all: Specifies that the system selects the closest match from all the host virtual servers.
match all: Specifies that the system selects the closest match from all the virtual servers.
Specifies the pool that was created to act as an endpoint to the tunnel between the two systems. This setting is used for paired tunneling. Options are: None, and entries for each already defined pool.
For the complete procedure on implementing a Local Traffic Manager paired-tunneling configuration using an iSession profile, see the guide titled BIG-IP® Local Traffic Manager: Implementations.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)