Applies To:
Show VersionsBIG-IP AAM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP APM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP Link Controller
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP Analytics
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP LTM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP AFM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP PEM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP DNS
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP ASM
- 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Introduction to other profiles
In addition to the profiles described in previous chapters, you can configure these BIG-IP® system profiles:
- OneConnect™
- NTLM
- Statistics
- Stream
- Request Logging
- DNS Logging
- ALG Logging
- QoE
- PCP
- HTTP Proxy Connect
- SplitSession Client
- SplitSession Server
- MAP-T
For each profile type, the BIG-IP system provides a pre-configured profile with default settings. In most cases, you can use these default profiles as is. If you want to change these settings, you can configure profile settings when you create a profile, or after profile creation by modifying the profile’s settings.
About OneConnect profiles
The OneConnect profile type implements the BIG-IP® system's OneConnect feature. This feature can increase network throughput by efficiently managing connections created between the BIG-IP system and back-end pool members. You can use the OneConnect feature with any TCP-based protocol, such as HTTP or RTSP.
How does OneConnect work?
The OneConnect feature works with request headers to keep existing server-side connections open and available for reuse by other clients. When a client makes a new connection to a virtual server configured with a OneConnect profile, the BIG-IP system parses the request, selects a server using the load-balancing method defined in the pool, and creates a connection to that server. When the client's initial request is complete, the BIG-IP system temporarily holds the connection open and makes the idle TCP connection to the pool member available for reuse.
When another connection is subsequently initiated to the virtual server, if an existing server-side flow to the pool member is open and idle, the BIG-IP system applies the OneConnect source mask to the IP address in the request to determine whether the request is eligible to reuse the existing idle connection. If the request is eligible, the BIG-IP system marks the connection as non-idle and sends a client request over that connection. If the request is not eligible for reuse, or an idle server-side flow is not found, the BIG-IP system creates a new server-side TCP connection and sends client requests over the new connection.
About client source IP addresses
The standard address translation mechanism on the BIG-IP system translates only the destination IP address in a request and not the source IP address (that is, the client node’s IP address). However, when the OneConnect feature is enabled, allowing multiple client nodes to re-use a server-side connection, the source IP address in the header of each client node’s request is always the IP address of the client node that initially opened the server-side connection. Although this does not affect traffic flow, you might see evidence of this when viewing certain types of system output.
The OneConnect profile settings
When configuring a OneConnect profile, you specify this information:
- Source mask
- The mask applied to the source IP address to determine the connection's eligibility to reuse a server-side connection.
- Maximum size of idle connections
- The maximum number of idle server-side connections kept in the connection pool.
- Maximum age before deletion from the pool
- The maximum number of seconds that a server-side connection is allowed to remain before the connection is deleted from the connection pool.
- Maximum reuse of a connection
- The maximum number of requests to be sent over a server-side connection. This number should be slightly lower than the maximum number of HTTP Keep-Alive requests accepted by servers in order to prevent the server from initiating a connection close action and entering the TIME_WAIT state.
- Idle timeout override
- The maximum time that idle server-side connections are kept open. Lowering this value may result in a lower number of idle server-side connections, but may increase request latency and server-side connection rate.
OneConnect and HTTP profiles
Content switching for HTTP requests
When you assign both a OneConnect profile and an HTTP profile to a virtual server, and an HTTP client sends multiple requests within a single connection, the BIG-IP system can process each HTTP request individually. The BIG-IP system sends the HTTP requests to different destination servers as determined by the load balancing method. Without a OneConnect profile enabled for the HTTP virtual server, the BIG-IP system performs load-balancing only once for each TCP connection.
HTTP version considerations
For HTTP traffic to be eligible to use the OneConnect feature, the web server must support HTTP Keep-Alive connections. The version of the HTTP protocol you are using determines to what extent this support is available. The BIG-IP system therefore includes a OneConnect transformations feature within the HTTP profile, specifically designed for use with HTTP/1.0 which by default does not enable Keep-Alive connections. With the OneConnect transformations feature, the BIG-IP system can transform HTTP/1.0 connections into HTTP/1.1 requests on the server side, thus allowing those connections to remain open for reuse.
The two different versions of the HTTP protocol treat Keep-Alive connections in these ways:
- HTTP/1.1 requests
- HTTP Keep-Alive connections are enabled by default in HTTP/1.1. With HTTP/1.1 requests, the server does not close the connection when the content transfer is complete, unless the client sends a Connection: close header in the request. Instead, the connection remains active in anticipation of the client reusing the same connection to send additional requests. For HTTP/1.1 requests, you do not need to use the OneConnect transformations feature.
- HTTP/1.0 requests
- HTTP Keep-Alive connections are not enabled by default in HTTP/1.0. With HTTP/1.0 requests, the client typically sends a Connection: close header to close the TCP connection after sending the request. Both the server and client-side connections that contain the Connection: close header are closed once the response is sent. When you assign a OneConnect profile to a virtual server, the BIG-IP system transforms Connection: close headers in HTTP/1.0 client-side requests to X-Cnection: close headers on the server side, thereby allowing a client to reuse an existing connection to send additional requests.
OneConnect and NTLM profiles
NT Lan Manager (NTLM) HTTP 401 responses prevent the BIG-IP® system from detaching the server-side connection. As a result, a late FIN from a previous client connection might be forwarded to a new client that re-used the connection, causing the client-side connection to close before the NTLM handshake completes. If you prefer NTLM authentication support when using the OneConnect feature, you should configure an NTLM profile in addition to the OneConnect profile.
OneConnect and SNATs
When a client makes a new connection to a virtual server that is configured with a OneConnect profile and a source network address translation (SNAT) object, the BIG-IP system parses the HTTP request, selects a server using the load-balancing method defined in the pool, translates the source IP address in the request to the SNAT IP address, and creates a connection to the server. When the client's initial HTTP request is complete, the BIG-IP system temporarily holds the connection open and makes the idle TCP connection to the pool member available for reuse. When a new connection is initiated to the virtual server, the BIG-IP system performs SNAT address translation on the source IP address and then applies the OneConnect source mask to the translated SNAT IP address to determine whether it is eligible to reuse an existing idle connection.
About NTLM profiles
NT LAN Manager (NTLM) is an industry-standard technology that uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the network. Instead, the system requesting authentication performs a calculation to prove that the system has access to the secured NTLM credentials. NTLM credentials are based on data such as the domain name and user name, obtained during the interactive login process.
The NTLM profile within the BIG-IP® system optimizes network performance when the system is processing NT LAN Manager traffic. When both an NTLM profile and a OneConnect™ profile are associated with a virtual server, the local traffic management system can take advantage of server-side connection pooling for NTLM connections.
How does the NTLM profile work?
When the NTLM profile is associated with a virtual server and the server replies with the HTTP 401 Unauthorized HTTP response message, the NTLM profile inserts a cookie, along with additional profile options, into the HTTP response. The information is encrypted with a user-supplied passphrase and associated with the serverside flow. Further client requests are allowed to reuse this flow only if they present the NTLMConnPool cookie containing the matching information. By using a cookie in the NTLM profile, the BIG-IP system does not need to act as an NTLM proxy, and returning clients do not need to be re-authenticated.
The NTLM profile works by parsing the HTTP request containing the NTLM type 3 message and securely storing the following pieces of information (aside from those which are disabled in the profile):
- User name
- Workstation name
- Target server name
- Domain name
- Cookie previously set (cookie name supplied in the profile)
- Source IP address
With the information safely stored, the BIG-IP system can then use the data as a key when determining which clientside requests to associate with a particular serverside flow. You can configure this using the NTLM profile options. For example, if a server's resources can be openly shared by all users in that server's domain, then you can enable the Key By NTLM Domain setting, and all serverside flows from the users of the same domain can be pooled for connection reuse without further authentication. Or, if a server's resources can be openly shared by all users originating from a particular IP address, then you can enable the Key By Client IP Address setting and all serverside flows from the same source IP address can be pooled for connection reuse.
The Statistics profile type
The Statistics profile provides user-defined statistical counters. Each profile contains 32 settings (Field1 through Field32), which define named counters. Using a Tcl-based iRule command, you can use the names to manipulate the counters while processing traffic.
For example, you can create a profile named my_stats, which assigns the counters tot_users, cur_users, and max_users to the profile settings Field1, Field2, and Field3 respectively. You can then write an iRule named track_users, and then assign the my_stats profile and the track_users iRule to a virtual server named stats-1.
In this example, the counter tot_users counts the total number of connections, the counter cur_users counts the current number of connections, and the counter max_users retains the largest value of the counter cur_users.
profile stats my_stats { defaults from stats field1 tot_users field2 cur_users field3 max_users } rule track_users { when CLIENT_ACCEPTED { STATS::incr my_stats tot_users STATS::setmax my_stats max_users [STATS::incr my_stats cur_users] } } virtual stats-1 { destination 10.10.55.66:http ip protocol tcp profile http my_stats tcp pool pool1 rule track_users }
The Stream profile type
You can use the Stream profile to search and replace strings within a data stream, such as a TCP connection.
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.
The Request Logging profile type
A Request Logging profile gives you the ability to configure data within a log file for HTTP requests and responses, according to parameters that you specify.
The DNS Logging profile type
A DNS logging profile gives you the ability to log DNS queries and responses, according to parameters that you specify.
The ALG Logging profile type
Application Layer Gateway (ALG) profiles provide the carrier-grade network address translation (CGNAT) with protocol and service functionality that modifies the necessary application protocol header and payload, thus allowing these protocols to seamlessly traverse the NAT, FTP, RTSP, SIP, and PPTP profiles that are supported with ALG profiles, and added to the CGNAT configuration as needed.
The QoE profile type
The BIG-IP® system's video Quality of Experience (QoE) profile enables you to assess an audience's video session or overall video experience, providing an indication of customer satisfaction. The QoE profile uses static information, such as bitrate and duration of a video, and video metadata, such as URL and content type, in monitoring video streaming. Additionally, the QoE profile monitors dynamic information, which reflects the real-time network condition.
The PCP profile type
You apply a Port Control Protocol (PCP) profile to a Large Scale NAT (LSN) pool of translation addresses. A client that uses the LSN pool can also send PCP requests to the BIG-IP® system to request a particular address/port from the pool.
About HTTP Proxy Connect profiles
The HTTP Proxy Connect profile enables a BIG-IP® device to connect to a remote, down-stream proxy device. A client connects to the BIG-IP device, which selects a remote proxy device from a pool of proxy devices. An HTTP CONNECT handshake tells the selected remote proxy device where to connect. When the connection is established, it becomes an opaque tunnel. Any protocol can use the tunnel between the BIG-IP device and the remote proxy.
When an HTTP profile is assigned to the virtual server, the HTTP CONNECT handshake is automatically configured. If an HTTP profile not assigned to the virtual server, for example, when you have opaque SSL traffic, you can use HTTP::proxy chain iRule commands to configure the destination to which the remote proxy device routes traffic.
The SplitSession Client profile type
The SplitSession Client profile defines the client parameters in an SSL intercept explicit proxy mode configuration. This profile enables you to configure a Peer Port, which specifies the port for the SplitSession peer that is connected to the out-of-band connection, and the Peer IP address, which specifies the IP address for the SplitSession peer that is connected to the out-of-band connection.
The SplitSession Server profile type
The SplitSession Server profile defines the server parameters in an SSL intercept explicit proxy mode configuration. This profile enables you to configure a Listen Port, which specifies the port that the SplitSession server listens on for the out-of-band connection, and the Listen IP address, which specifies the IP address that the SplitSession server listens on for the out-of-band connection.
About MAP-T
In a Mapping of Address and Port with Translation (MAP-T) deployment, the customer edge (CE) device implements a combination of stateful NAPT44 translation and stateless MAP translation, using a source IPv4 address and port number to forward IPv4 traffic across the upstream IPv6 network. The BR (border relay) is responsible for connecting one or more MAP domains to external IPv4 networks. It converts the inbound IPv6 packet from the CEs back to NAT'd IPv4, using the corresponding MAP configurations.