Profile concepts | F5 BIG-IP LTM Load Balancer Profile concepts

Profile concepts

Profile contains settings that instruct BIG-IP to process traffic through that virtual server.

Why would you want to change virtual server default traffic processing behavior ?

From the modules 2 and 3 we know that default behavior for a standard virtual server is to load balance traffic.

Ex: - We has an application that starts information about the client only on the server to which the client originally connected?  If the client returns on a subsequent connection and BIG-IP load balance to a different server, the application breaks.

To prevent this from happing, you can apply a persistence profile to the virtual server. A persistence profile tells BIG-IP how to identify a returning client connections to the same server rather than make new load balancing decision.

Persistence profile takes precedence over the virtual server default load balancing traffic behavior when working with returning clients.

Another variable reason for profiles is duplicating setting to multiple virtual servers.

We also knows that our application needing persistence receives its client traffic from many different networks.

So we has decided to use multiple virtual server to handle this traffic coming from different network. All of these virtual server points to the same pool and can use the same persistence profile.

Specific example where profiles are used are

1. Persistence
2. SSL Termination
3. PTP Protocol

Profile example : Persistence

A common misconception is that a persistence profile overrides the load balancing decision altogether.

Even if a persistence profile is configured, BIG-IP performs load balancing for a virtual server. A persistence record is created for a client group of clients for given time period or time out.

When the persistence record times out, or a new client initiates a connection from that client persist before reaching the time out.

Profile example : SSL Termination

A second example where a profile is used to change a virtual servers traffic behaviors is SSL termination.

Lets say you have an HTTPS virtual server. The client traffic to this server is encrypted from the client to the server. But what if needs to examine some of the encrypted content? And what if you want to offload the SSL encryption and decryption work from your servers? These are the two excellent reasons for using a clients profile and having BIG-IP terminate the SSL session rather then the servers.

Because it contains accelerator hardware, BIG-IP can speed up SSL processing. Terminating SSL session on BIG-IP also allows the servers to speed their CPU cycles on serving up the content rather than doing SSL encryption and decryption work. Certificate management also becomes easier because the administrator only need to install the SSL certificate at one device(BIG-IP) rather then one each pool member.

Profile example: FTP

The final profile example is FTP. If virtual servers were only configured to process client traffic. What would happen one of the pool members tried to initiate traffic outbound via BIG-IP LTM? The answer is that LTM would drop the packet. There is no listens (virtual server) configured to receive traffic from the pool member and direct that traffic out bound.

How does active FTP protocol work?

In active FTP, the clients initiates a connection typically to port 21 for “command control” but the server initiates the data transfer connection from typically port 20. How can this possibly work on BIG-IP LTM? The answers is an FTP profile is used. The FTP profile gives BIG-IP the smarts to accepts the server initiation packed back to the client for the data transfer connection.

One way to illustrate How  profile work is a scene from the movie “ The Matrix”. The character Neo needs to learn jujitsu. But rather then training for months, they sit him down and play in a martial arts program, voila, a master. A virtual server learns things the same way. An HTTP profile tells the virtual server what cookie is, what an HTTP method is, basically how to read HTTP.

           

Profile Dependencies

Some profile requires the presence of other profiles on the virtual server. The OSI model provides a help full context for explaining this requirement. The rule of thumb to remember is if you are using a higher level profile in terms of the OSI model, the lower level profiles are required for that virtual server.

For instance, if the BIG-IP administrator decides to use the cookie persistence profile, then that virtual server also needs an HTTP profile. The cookie is contained in HTTP header. BIG-IP cannot read the cookie without being able to read the HTTP part of the packet.

Because HTTP is a TCP protocol, the virtual server also needs a TCP Profile.

It is important to note that two profiles cannot coexist on the same layer. For example, you cannot configure both a TCP and UDP profile on one virtual server. To use both profiles, the BIG-IP administrator would need to configure one virtual server for TCP and another for UDP.

And the virtual server cannot be configured for both FTP and HTTP protocols. Again each protocol would needs its own virtual server.

Protocol-Layer4 Profiles

All virtual servers have at least one protocol (or layer 4) profiles configured.

The most commonly used protocol profiles are TCP, UDP and Fast L4. you do not have worry about which one the choose because BIG-IP automatically selects the appropriate one for your situation.

For example, if you configure an HTTP profile for a virtual server, BIG-IP automatically sets the layer4 profile to TCP.