F5

Question 1

What is a health monitor?

Answer 1

A health monitor is a test designed to report the status of a pool, pool member, or node on an ongoing basis, at a set interval. When a health monitor marks a pool, pool member, or node as down, the BIG-IP system stops sending traffic to the device.

Question 2

What are health monitor Interval and Timeout?

Answer 2

Interval - number of seconds between each test (default 5)
Timeout - if there is no successful test during this time, the device is marked unavailable (default 16)

Question 3

What’s the recommended Timeout for health monitors?

Answer 3

(3 x Interval + 1) seconds

Question 4

What other type of monitor is there other than health monitor?

Answer 4

Performance monitor

When a server that is being monitored by a performance monitor displays a degradation in performance, the BIG-IP system redirects traffic to other resources until the performance of the server returns to normal. The monitor checks the current CPU, memory, and disk usage of a server that is running and then dynamically load balances traffic based on its performance.

Question 5

What 4 types of health monitor are there?

Answer 5

Address Check

An address check monitor provides a simple verification of an address on a network. This type of monitor sends a request to a virtual server. When a response is received, the test is successful. If the monitor is unsuccessful in determining that a node is available, the monitor marks the node and all pool members at that IP address as Offline.

Service (Application) Check

An application check monitor interacts with servers by sending multiple commands and processing multiple responses.
An FTP monitor, for example, connects to a server, logs in by using a user ID and password, navigates to a specific directory, and then downloads a specific file to the /var/tmp directory. If the file is retrieved, the check is successful.

Content Check

A content check monitor determines whether a service is available and whether the server is serving the appropriate content. This type of monitor opens a connection to an IP address and port, and then issues a command to the server. The response is compared to the monitor’s receive rule. When a portion of the server’s response matches the receive rule, the test is successful.

Path Check

A path check monitor determines whether traffic can flow through a device to an endpoint. A path check monitor is successful when network paths through firewalls or routers are available.

Question 6

What ways of assigning a monitor are there?

Answer 6

Monitor-to-pool association

This type of association associates a monitor with an entire load balancing pool. In this case, the monitor checks all members of the pool.

Monitor-to-pool member association

This type of association associates a monitor with an individual pool member, that is, an IP address and service. In this case, the monitor checks only that pool member and not any other members of the pool. For example, we can create an instance of the monitor http for pool member 10.10.10.10:80 of my_pool.

Important: A monitor associated with an individual pool member supersedes a monitor associated with that pool member’s parent pool.

Monitor-to-node Specific association

This type of association associates a monitor with a specific node. In this case, the monitor checks only the node itself, and not any services running on that node. For example, we can create an instance of the monitor icmp for node 10.10.10.10. In this case, the monitor checks the specific node only, and not any services running on that node.

Monitor-to-node Default association

We can designate a monitor as the default monitor that we want the BIG-IP system to associate with one or more nodes. In this case, any node to which we have not specifically assigned a monitor inherits the default monitor.

Some monitor types are designed for association with nodes only, and not pools or pool members. Other monitor types are intended for association with pools and pool members only, and not nodes. Finally, in some instances, some monitor types associated with a node are not mutually exclusive of pools or pool members, and must function in combination in some scenarios.

Node-only monitors specify a destination address in the format of an IP address with no service port (for example, 10.10.10.2). Conversely, monitors that we can associate with nodes, pools, and pool members specify a destination address in the format of an IP address and service port (for example, 10.10.10.2:80). Therefore, when we use the BIG-IP Configuration utility to associate a monitor with a pool, pool member, or node, the utility displays only those pre-configured monitors that are designed for association with that server.

For example, we cannot associate the monitor icmp with a pool or its members, since the icmp monitor is designed to check the status of a node itself and not any service running on that node.

Question 7

What is a Profile?

Answer 7

A profile is an object or configuration tool that contains settings with values that we can use to affect the behavior of a particular type of network traffic, such as HTTP connections. Profiles also provide a way to enable connection and session persistence, and to manage client application authentication.

Question 8

How do we associate profiles?

Answer 8

After configuring a profile, we associate the profile with a virtual server. The virtual server then processes traffic according to the values specified in the profile. Using profiles enhances your control over managing network traffic, and makes traffic-management tasks easier and more efficient.

We can associate multiple profiles with a single virtual server. For example TCP profile, SSL profile, and HTTP profile with the same virtual server.

Question 9

What types of profiles are there?

Answer 9

Default, Custom and Parent profiles

By default, LTM provides you with a set of default profiles that contain various settings with default values that define the behavior of different types of traffic. For example the http default profile.

If we want to change those values to better suit the needs of your network environment, we can create a custom profile. A custom profile is a profile derived from a default profile and contains values that we specify.

A parent profile is a profile from which your custom profile inherits its settings and their default values.

Question 10

What is a profile dependency?

Answer 10

Some profiles are dependent on others. For example Cookie Persistence will not run without HTTP profile and http profile will not run without TCP profile.

Some profiles can’t be combined.

Question 11

What are SSL profiles nad what 2 types are there?

Answer 11

When we want the BIG-IP system to process application traffic over SSL, we can configure the system to perform the SSL handshake that destination servers normally perform. This ability for the BIG-IP system to offload SSL processing from a destination server is an important feature of the BIG-IP system.

The most common way to configure the BIG-IP system is to create a Client SSL profile, which makes it possible for the BIG-IP system to decrypt client requests before sending them on to a server, and encrypt server responses before sending them back to the client.

Within a Client SSL profile specifically, we can specify multiple certificate/key pairs, one per key type. This enables the system to accept all types of cipher suites that a client might support as part of creating a secure connection. The system then decrypts the client data, manipulates any headers or payload according to the way that you configured the Client SSL profile, and by default, sends the request in clear text to the target server for processing.

For those sites that require enhanced security on their internal network, you can configure a Server SSL profile. With a Server SSL profile, the BIG-IP system re-encrypts the request before sending it to the destination server. When the server returns an encrypted response, the BIG-IP system decrypts and then re-encrypts the response, before sending the response back to the client.

Question 12

What is SSL acceleration?

Answer 12

SSL acceleration refers to off-loading processor-intensive SSL encryption and decryption from a server to a device configured to accelerate the SSL encryption/decryption routine.

The F5 BIG-IP® product family uses specialized hardware built for SSL acceleration to remove processing bottlenecks and encrypt data without having to change application code. BIG-IP cuts costs and overhead by consolidating SSL certificates, eliminating the need to purchase SSL-capable software for each server within the network.

Question 13

What is SSL Termination and what are the advantages of using it?

Answer 13

SSL termination refers to the process of decrypting encrypted traffic before passing it along to a web server. Instead of relying upon the web server to do this computationally intensive work, we can use SSL termination to reduce the load on your servers, speed up the process, and allow the web server to focus on its core responsibility of delivering web content.

The advantages are:

BIG-IP performs SSL key exchange and bulk encryption.
It centralizes certificate management.
It offloads SSL traffic from the servers.
It allows iRules, cookie persistence, security policies and many other specific features.

Question 14

What is a Session Persistence?

Answer 14

When we configure session persistence, the BIG-IP system tracks and stores session data, such as the specific pool member that serviced a client request. The primary reason for tracking and storing session data is to ensure that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions.

In addition, session persistence can track and store other types of information, such as user preferences or a user name and password.

Question 15

Why are there different types of persistence?

Answer 15

The BIG-IP system offers several types of session persistence, each one designed to accommodate a specific type of storage requirement for session data. The type of persistence that we implement depends on where and how we want to store client-specific information, such as items in a shopping cart or airline ticket reservations.

For example, we might store airline ticket reservation information in a back-end database that all servers can access, or on the specific server to which the client originally connected, or in a cookie on the client’s machine. When we enable persistence, returning clients can bypass load balancing and instead connect to the server to which they last connected in order to access their saved information.

Question 16

How long are session persistence data kept?

Answer 16

The BIG-IP system keeps session data for a period of time that we specify.

Question 17

How do we configure Persistence?

Answer 17

The primary tool for configuring session persistence is to configure a persistence profile and assign it to a virtual server. If we want to enable persistence for specific types of traffic only, as opposed to all traffic passing through the virtual server, we can write an iRule.

A persistence profile is a pre-configured object that automatically enables persistence when we assign the profile to a virtual server.

Each type of persistence that the BIG-IP system offers includes a corresponding default persistence profile. These persistence profiles each contain settings and setting values that define the behavior of the BIG-IP system for that type of persistence. We can either use the default profile or create a custom profile based on the default.

Question 18

What types of Persistence are there?

Answer 18

Cookie persistence

Cookie persistence uses the HTTP cookie header to persist connections across a session. Most application servers insert a session ID into responses that is used by developers to access data stored in the server session (shopping carts and so on). Load balancing services use this value to enable persistence. This technique prevents the issues associated with simple persistence because the session ID is unique.

Destination address affinity persistence

Also known as sticky persistence, destination address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the destination IP address of a packet.

Hash persistence

Hash persistence allows you to create a persistence hash based on an existing iRule. Hash persistence allows the use of multiple values within a request to enable persistence. To avoid problems with simple persistence, for example, a hash value may be created based on Source IP, Destination IP, Destination Port. While not necessarily unique to every session, this technique results in a more even distribution of load across servers. We generally use this type of persistence technique with stateless applications or streaming content (video and audio).

Source address affinity persistence

Also known as simple persistence, source address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the source IP address of a packet. You generally use this type of persistence technique with stateless applications or streaming content (video and audio) as a means to more evenly distribute load.

SSL persistence

Because SSL sessions need to be established and are very much tied to a session between client and server, failing to persist SSL-secured sessions results in renegotiation of the session,. Regnegotiation requires a noticeable amount of time and can result in user dissatisfaction. To avoid unnecessary renegotiation, the BIG-IP system uses the SSL session ID to ensure that a session is properly routed to the application instance to which the session first connected. Even when the client’s IP address changes, the BIG-IP® system still recognizes the connection as being persistent based on the session ID. You generally use this persistence technique with stateful applications that depend on the client being connected to the same application instance throughout the life of the session.

Universal persistence

Universal persistence uses any piece of data (network, application protocol, payload) to persist a session. This technique requires the BIG-IP system to be able to inspect and ultimately extract any piece of data from a request or response. This technique is the basis for application-specific persistence solutions addressing popular applications like SIP, WTS, and more recently, VMware View. With universal persistence, you can write an expression that defines the data that the BIG-IP system will persist on in a packet. The expression, written using the same expression syntax that you use in iRules®, defines some sequence of bytes to use as a session ID. You generally use this persistence technique with stateful applications that depend on the client being connected to the same application instance throughout the life of the session.

Microsoft® Remote Desktop Protocol persistence

Microsoft® Remote Desktop Protocol (MSRDP) persistence tracks sessions between clients and servers running the Microsoft® Remote Desktop Protocol (RDP) service.

SIP persistence

SIP persistence is an application-specific type of persistence used for servers that receive Session Initiation Protocol (SIP) messages sent through UDP, SCTP, or TCP. You generally use this persistence technique with stateful applications that depend on the client being connected to the same application instance throughout the life of the session.

Question 19

What is a Prefix length option in creating persistence profile?

Answer 19

It’s specifying a group of source addresses for persistence profile by applying a mask on it. For example when we set Prefix length to 24, all the addresses with the same first three octets in IPv4 address will be directed to the same server.

Question 20

How does Cookie persistence work and what is its requirement?

Answer 20

Special cookie is inserted by BIG-IP into the reply sent to the Client. It contains selected pool member. HTTP profile is required.

Question 21

What types of Cookie persistence are there?

Answer 21

Cookie Hash

The Cookie Hash method consistently maps a cookie value to a specific node. When the client returns to the site, the BIG-IP system uses the cookie information to return the client to a given node. With this method, the web server must generate the cookie; the BIG-IP system does not create the cookie automatically as it does when we use the HTTP Cookie Insert method.

HTTP Cookie Insert

Using the HTTP Cookie Insert method, the information about the server to which the client connects is inserted in the HTTP header of the response from the server in the form of a cookie. By default, the cookie is named BIGipServer<pool_name> and includes the encoded address and port of the server handling the connection. The system sets the expiration date for the cookie based on the Expiration setting in the cookie persistence profile. HTTP Cookie Insert is the default value for the Cookie Method setting.</pool_name>

HTTP Cookie Passive

Using the HTTP Cookie Passive method is unlike the other cookie persistence methods. The BIG-IP system does not insert or search for blank Set-Cookie headers in the response from the server. This method does not try to set up the cookie. With this method, the server provides the cookie, formatted with the correct server information and timeout.

HTTP Cookie Rewrite

Using the HTTP Cookie Rewrite method, the BIG-IP system intercepts a Set-Cookie header, named BIGipCookie, sent from the server to the client, and overwrites the name and value of the cookie. The new cookie is named BIGipServer<pool_name> and it includes the address and port of the server handling the connection. The HTTP Cookie Rewrite method requires us to set up the cookie created by the server. For the HTTP Cookie Rewrite method to succeed, a blank cookie must come from the web server for the BIG-IP system to rewrite.</pool_name>

Question 22

What is an iRule?

Answer 22

An iRule is a script that we write if we want to make use of some of the extended capabilities of the BIG-IP that are unavailable via the CLI or GUI. iRules allow us to more directly interact with the traffic passing through the device. We can send traffic not only to pools, but also to individual pool members, ports, or URIs. And directing traffic to a desired pool is only the beginning. We can parse the entire header and payload of the data as it is being passed through the BIG-IP and, at wire speed, execute an entire script of commands on that traffic. The commands at our disposal range from logging to redirecting traffic, from modifying the URI or port to actually rewriting the payload itself.

Question 23

What are iRules commonly used for?

Answer 23

Custom Pool and Server selection
HTTP to HTTPS redirection
Universal Persistence
Intelligent SNAT
and more…

Question 24

What are the components of an iRule?

Answer 24

Event = defines the activity that triggers the iRule
Operator = used in a conditional expression top specify the event details
Command = indicates the action to perform

Question 25

What is High Availability and how is it deployed?

Answer 25

HIGH AVAILABILITY (HA) makes sure that the server pool is ready for user requests in situations when our primary load balancer is down. Traffic is then redirected to our backup/secondary load balancer with minimal downtime, which is unnoticeable to users.

HA DEPLOYMENT consists of two BIG-IP (like other load balancers) systems, synchronized with the same configuration:

1. An active system that processes traffic.
2. A standby system that remains in dormant mode until required.

This pairing’s goal is to provide users with seamless, uninterrupted service, in case one device fails.

If the active system is taken offline or fails to connect, the standby system immediately takes over, to avoid processing traffic. Typically, the newly active system remains active until an event requires the first BIG-IP system to become active again or until you manually force that system into standby.

Question 26

What is Failover and what is Failback?

Answer 26

FAILOVER is a procedure by which a system automatically transfers control to a duplicate system when it detects a fault or failure.

FAILBACK is the second stage of a two-part system. It follows an initial stage called failover, in which data recording is switched to a new venue that will be safe from corruption or failure. In failback, specific data is saved to the original system to make up for any lapse.