SOL8082: Overview of TCP connection set-up for BIG-IP LTM virtual server types

SOL8082: Overview of TCP connection set-up for BIG-IP LTM virtual server types

---

Updated: 7/6/09 5:26 PM

Standard virtual server
Performance Layer4 virtual server
Performance HTTP virtual server
Forwarding Layer 2 virtual server
Forwarding IP virtual server
Reject virtual server

Standard virtual server

The BIG-IP LTM TMOS operating system implements a 'full proxy' architecture for virtual servers configured with a TCP profile. By assigning a custom TCP profile to the virtual server, you can configure the BIG-IP LTM to maintain compatibility to disparate server operating systems in the data center. At the same time, the BIG-IP LTM can leverage it’s TCP/IP stack on the client side of the connection to provide independent and optimized TCP connections to client systems.

In a full proxy architecture, the BIG-IP LTM appears as a TCP peer to both the client and the server by associating two independent TCP connections with the end-to-end session. Although certain client information such as the source IP address, or source TCP port may be re-used on the server-side of the connection, the BIG-IP LTM manages the two sessions independently, making itself transparent to the client and server.

The Standard virtual server requires a TCP or UDP profile, and may optionally be configured with HTTP, FTP or SSL, profiles if Layer 7 or SSL processing is required.

The TCP connection set-up behavior for a Standard virtual server varies depending on whether a TCP profile or a TCP and Layer 7 profile such as HTTP, is associated with the virtual server.

Standard virtual server with TCP profile

The TCP connection set-up behavior for a Standard virtual server operates as follows: the three-way TCP handshake occurs on the client side of the connection before the BIG-IP LTM initiates the TCP handshake on the server side of the connection.

A Standard virtual server processes connections using the full proxy architecture. The following TCP flow diagram illustrates the TCP handshake for a Standard virtual server with TCP profile:

Standard virtual server with Layer 7 functionality

If a Standard virtual server is configured with Layer 7 functionality, such as an HTTP profile, the client must send at least one data packet before the server-side connection can be initiated by the BIG-IP LTM.

Note: The BIG-IP LTM may initiate the server-side connection prior to the first data packet for certain Layer 7 applications, such as FTP, in which the user waits for a greeting banner before sending any data.

The TCP connection set-up behavior for a Standard virtual server with Layer 7 functionality operates as follows: the three-way TCP handshake and initial data packet are processed on the client side of the connection before the BIG-IP LTM initiates the TCP handshake on the server side of the connection.

A Standard virtual server with Layer 7 functionality processes connections using the full proxy architecture. The following TCP flow diagram illustrates the TCP handshake for a Standard virtual server with Layer 7 functionality:

Performance Layer4 virtual server

The Performance Layer4 virtual server type uses the Fast L4 profile. Depending on the configuration, the virtual server utilizes the PVA ASIC chip with the PVA Acceleration mode defined as one of the following: full, assisted or none. Irrespective of the PVA acceleration mode used in the profile, the Performance Layer4 virtual server processes connections on a packet-by-packet basis.

The Performance Layer4 virtual server packet-by-packet TCP behavior operates as follows: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM makes the load balancing decision and passes the SYN request to the pool member.

The following TCP flow diagram illustrates the TCP handshake for a Performance Layer4 virtual server:

Performance HTTP virtual server

The Performance HTTP virtual server type uses the Fast HTTP profile. The Performance HTTP virtual server together with the Fast HTTP profile is designed to speed up certain types of HTTP connections and reduce the number of connections opened to the back-end HTTP servers. This is accomplished by combining features from the TCP, HTTP, and OneConnect profiles into a single profile that is optimized for network performance. The Performance HTTP virtual server processes connections on a packet-by-packet basis and buffers only enough data to parse packet headers.

The Performance HTTP virtual server TCP behavior operates as follows: The BIG-IP system establishes server-side flows by opening TCP connections to the pool members. When a client makes a connection to the Performance HTTP virtual server, if an existing server-side flow to the pool member is idle, the BIG-IP LTM system marks the connection as non-idle and sends client request over it.

Performance HTTP virtual server with idle server-side flow

The following TCP flow diagram illustrates the client connection to the Performance HTTP virtual server when an idle server-side flow is found (in this case the idle flow was created by the BIG-IP system):

Performance HTTP virtual server with no idle server-side flow

If an idle server-side flow is not found, the BIG-IP system creates a new server-side TCP connection and sends client request over it.

The following TCP flow diagram illustrates the client connection to the Performance HTTP virtual server when no idle server-side flow is found:

Forwarding Layer 2 virtual server

The Forwarding Layer 2 virtual server type uses the Fast L4 profile. The Forwarding Layer 2 virtual server forwards packets based on the destination L2 Media Access Control (MAC) address, and therefore does not have pool members to load balance. The virtual server shares the same IP address as a node in an associated VLAN. Before creating a Forwarding Layer 2 virtual server, you must define a VLAN group that includes the VLAN in which the node resides. The Forwarding Layer 2 virtual server processes connections on a packet-by-packet basis.

The Forwarding Layer 2 virtual server operates on a packet-by-packet basis with the following TCP behavior: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM passes the SYN request to the node in the associated VLAN based on the destination MAC address.

The following TCP flow diagram illustrates the TCP handshake for a Forwarding Layer 2 virtual server:

Forwarding IP virtual server

The Forwarding IP virtual server type uses the Fast L4 profile. An IP forwarding virtual server forwards the packet directly to the next hop IP address specified in the client request. Therefore, when the BIG-IP LTM system evaluates the packet for processing, the system looks only at the destination IP address. The Forwarding IP virtual server processes connections on a packet-by-packet basis.

The Forwarding IP virtual server operates on a packet-by-packet basis with the following TCP behavior: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM passes the SYN request to the next IP address in the associated VLAN based on the destination IP address.

The following TCP flow diagram illustrates the TCP handshake for a Forwarding IP virtual server:

Reject virtual server

The Reject virtual server type causes the BIG-IP system to immediately reject any traffic destined for the virtual server IP address.

The Reject virtual server operates using the following TCP behavior: the initial SYN request sent from the client to the BIG-IP LTM virtual server. The BIG-IP LTM immediately closes the connection by sending a TCP reset to the client.

The following TCP flow diagram illustrates the TCP behavior for a Reject virtual server: