F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP Local Traffic Management: Profiles Reference
  3. Other Profiles
Manual Chapter : Other Profiles

Applies To:

Show Versions Show Versions

BIG-IP APM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0

BIG-IP Analytics

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0

BIG-IP LTM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0

BIG-IP PEM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0

BIG-IP AFM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0

BIG-IP DNS

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0

BIG-IP ASM

  • 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0
Manual Chapter

Other Profiles

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.
The BIG-IP system can pool server-side connections from multiple virtual servers if those virtual servers reference the same OneConnect profile and the same pool. Also, the re-use of idle connections can cause the BIG-IP system to appear as though the system is not load balancing traffic evenly across pool members.

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.

About TDR

The Transaction Data Record (TDR) is generated in a user specified format based on the matched attributes in the received application message. A TDR profile or filter configuration allows the user to provision the message attributes and TDR format.
The TDR is configured as a profile and can be attached to a virtual server or transport config. There is no limit for creating TDR profiles, but at an instance, only one profile can be attached to a virtual server or transport config. Same or different TDR profiles can be attached to the virtual server and transport config.
The TDR is configured as a profile and can be attached to a virtual server or transport config. There is no limit for creating TDR profiles, but at an instance, only one profile can be attached to a virtual server or transport config. Same or different TDR profiles can be attached to the virtual server and transport config.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information