BIG IP F5 Material

The BIG-IP system is a set of application delivery products that work together to ensure high availability, improved performance, application security, and access control.

One of the primary functions of the BIG-IP system is to direct different types of protocol and application traffic to an appropriate destination server. The system accomplishes this through its Local Traffic Manager module, which can forward traffic directly to a load balancing server pool, or send traffic to a next-hop router, a pool of routers, or directly to a selected node on the network.

Basic BIG-IP system configuration

TMOS - Traffic Management Operation System

TMOS is a real-time, event-driven operating system designed specifically for application delivery networking. Through TMOS, you can configure all of the basic BIG-IP system routing and switching functions, as well as enhancements such as clusters, user roles, and administrative partitions. On top of TMOS runs a set of independent modules that you can configure.

Examples of these modules are -
BIG-IP Local Traffic Manager
BIG-IP Global Traffic Manager
BIG-IP Access Policy Manager

BIG-IP Application Security Manager

BIG-IP Local Traffic Manager BIG-IP Local Traffic Manager is a required module that you use to customize the way that the BIG-IP system processes specific types of protocol and application traffic. By using local traffic management features such as virtual servers, pools, and profiles, you ensure that traffic passing through the BIG-IP system is processed quickly and efficiently, while still meeting certain security needs BIG-IP Global Traffic Manager BIG-IP Global Traffic Manager provides intelligent traffic management to your globally available network resources. Through Global Traffic Manager, you can select from an array of load balancing modes, ensuring that your clients access the most responsive and robust resources at any given time. In addition, Global Traffic Manager provides extensive monitoring capabilities, so information on the health of any given resource is always available BIG-IP Application Security Manager BIG-IP Application Security Manager provides web application protection from application-layer attacks. Application Security Manager protects Web applications from both generalized and targeted application layer attacks including buffer overflow, SQL injection, cross-site scripting, and parameter tampering BIG-IP Access Policy Manager BIG-IP Access Policy Manager is a flexible, high-performance access and security solution. With Access Policy Manager, you can manage access to networks and applications by implementing security policies in the network. Policies are set to allow access based on context, including user identity and group membership. Using SSL to secure traffic, Access Policy Manager provides policy-based access to enterprise applications for any client users, from employees, contractors, partners, and suppliers, to any corporate resource. What is F5 LTM ?

BIG-IP Local Traffic Manager(LTM) is an application delivery networking system that provides intelligent load balancing and traffic management as well as advanced application security, acceleration and optimization. LTM does many things but on high level It will distribute traffic across multiple servers monitor servers and not send traffic if they don't respond correctly. LTM Can run on F5 hardware as well as virtual appliances. 

Introduction to virtual servers

Virtual servers and virtual addresses are two of the most important components of any BIG-IP Local Traffic Manager configuration:

• A virtual server is a traffic-management object on the BIG-IP system that is represented by an IP address and a service. Clients on an external network can send application traffic to a virtual server, which then directs the traffic according to your configuration instructions. Virtual servers typically direct traffic to a pool of servers on an internal network, by translating the destination IP address in each packet to a pool member address. Overall, virtual servers increase the availability of resources for processing client requests.
• A virtual address is the IP address component of a virtual server. For example, if a virtual server’s destination IP address and service are 10.10.10.2:80, then the IP address 10.10.10.2 is a virtual address. You do not explicitly create virtual addresses; instead, the BIG-IP system creates a virtual address when you create a virtual server and specify the destination IP address.

You can create a many-to-one relationship between virtual servers and a virtual address. For example, you can create the three virtual servers 10.10.10.2:80,10.10.10.2:443, and 10.10.10.2:161 for the same virtual address, 10.10.10.2.

You can enable and disable a virtual address. When you disable a virtual address, none of the virtual servers associated with that address can receive incoming network traffic.

Virtual Servers bind all of the various objects needed to allow the LTM to make load balance decisions.

Types of virtual servers

There are several different types of virtual servers that you can create.

TYPE	DESCRIPTION
Standard	A Standard virtual server (also known as a load balancing virtual server) directs client traffic to a load balancing pool and is the most basic type of virtual server. When you first create the virtual server, you assign an existing default pool to it. From then on, the virtual server automatically directs traffic to that default pool.
Forwarding (Layer 2)	You can set up a Forwarding (Layer 2) virtual server to share the same IP address as a node in an associated VLAN. To do this, you must perform some additional configuration tasks. These tasks consist of: creating a VLAN group that includes the VLAN in which the node resides, assigning a self-IP address to the VLAN group, and disabling the virtual server on the relevant VLAN.
Forwarding (IP)	A Forwarding (IP) virtual server is just like other virtual servers, except that a forwarding virtual server has no pool members to load balance. The virtual server simply forwards the packet directly to the destination IP address specified in the client request. When you use a forwarding virtual server to direct a request to its originally-specified destination IP address, Local Traffic Manager adds, tracks, and reaps these connections just as with other virtual servers. You can also view statistics for a forwarding virtual servers.
Performance (HTTP)	A Performance (HTTP) virtual server is a virtual server with which you associate a Fast HTTP profile. Together, the virtual server and profile increase the speed at which the virtual server processes HTTP requests.
Performance (Layer 4)	A Performance (Layer 4) virtual server is a virtual server with which you associate a Fast L4 profile. Together, the virtual server and profile increase the speed at which the virtual server processes Layer 4 requests.
Stateless	A stateless virtual server prevents the BIG-IP system from putting connections into the connection table for wildcard and forwarding destination IP addresses. When creating a stateless virtual server, you cannot configure SNAT automap, iRules, or port translation, and you must configure a default load balancing pool. Note that this type of virtual server applies to UDP traffic only.
Reject	A Reject virtual server specifies that the BIG-IP system rejects any traffic destined for the virtual server IP address.
DHCP Relay	A DHCP Relay virtual server relays Dynamic Host Control Protocol (DHCP) messages between clients and servers residing on different IP networks. Known as a DHCP relay agent, a BIG-IP system with a DHCP Relay type of virtual server listens for DHCP client messages being broadcast on the subnet and then relays those messages to the DHCP server. The DHCP server then uses the BIG-IP system to send the responses back to the DHCP client. Configuring a DHCP Relay virtual server on the BIG-IP system relieves you of the tasks of installing and running a separate DHCP server on each subnet.
Internal	An internal virtual server is one that can send traffic to an intermediary server for specialized processing before the standard virtual server sends the traffic to its final destination. For example, if you want the BIG-IP system to perform content adaptation on HTTP requests or responses, you can create an internal virtual server that load balances those requests or responses to a pool of ICAP servers before sending the traffic back to the standard virtual server.

How does a virtual server work?

A good way to illustrate a virtual server is to examine the situation where a user on a client on an external network sends HTTP traffic through a Web browser. In this case, the BIG-IP system follows this process:

1.	The user initiates a connection by entering a URL into a Web browser. The browser resolves the URL to a virtual server address that you have previously created on the BIG-IP system. This virtual server address is the destination address in the request.

2.	The BIG-IP system examines the corresponding virtual server configuration and determines the pool of Web servers to which to send the incoming traffic.

3.	The BIG-IP system examines the pool configuration to determine the load balancing algorithm to use to select an internal server node.

4.	The BIG-IP system uses this algorithm to select the specific server node.

5.

In the Destination IP Address header of the request packets, the BIG-IP system changes the destination IP address (that is, the virtual server address) to the actual address of the selected node. In this case, the source address in the packets (that is, the address of the client that initiated the connection) remains unchanged.

6.	The BIG-IP system sends the incoming packets to the selected server node.

7.

When the server node sends its response back to the client, the response returns through the BIG-IP system and a reverse translation occurs. In the Source IP Address header of the response packets, the BIG-IP system translates the actual source IP address of the response (the server node address) to the virtual server address. This causes the source address in the response to match the destination address in the request, a requirement necessary to ensure that the client accepts the response. In short, the BIG-IP system typically translates the destination address in a request to the actual address of a server node, and translates the actual source address in a response to the virtual server address. This means that a client on an external network never sees the private class IP address of an internal server node.

Property	Description	Default Value
Name	A unique name that you assign to the virtual server. This property is required.	No default value
Destination Type	The type of virtual server you want to create and its IP address. If the type you select is network, then this property also includes the mask for the IP address.	Host
Destination Address	The IP address of the virtual server.	No default value
Destination Mask	The netmask for a network virtual server. This property applies to a network virtual server only, and is required. The netmask clarifies whether the host bit is an actual zero or a wildcard representation.	No default value
Service Port	A service name or port number for which you want to direct traffic. This property is required.	No default value
State	The state of the virtual server, that is, Enabled orDisabled. As an option, you can enable or disable a virtual server for a specific VLAN. Note that when you disable a virtual server, the virtual server no longer accepts new connection requests. However, it allows current connections to finish processing before going to a down state. Note: If no VLAN is specified, then the Enabled orDisabled setting applies to all VLANs.	Enabled

Understanding virtual server and virtual address status

Status indicator	Explanation
	The virtual server or virtual address is enabled and able to receive traffic.
	The virtual server or virtual address is enabled but is currently unavailable. However, the virtual server or virtual address might become available later, with no user action required. An example of a virtual server or virtual address showing this status is when the objects connection limit has been exceeded. When the number of connections falls below the configured limit, the virtual server or virtual address becomes available again.
	The virtual server or virtual address is enabled but offline because an associated object has marked the virtual server or virtual address as unavailable. To change the status so that the virtual server or virtual address can receive traffic, you must actively enable the virtual server or virtual address.
	The virtual server or virtual address is operational but set to Disabled. To resume normal operation, you must manually enable the virtual server or virtual address.
	The status of the virtual server or virtual address is unknown.

Basic Virtual Construct

Requires a monitor, pool and virtual 

#Monitor

b monitor pavan_mn '{

  defaults from http

  recv "200 OK"

  send "GET /smoketest/test.htm HTTP/1.0\r\n\r\n"

}'

#Pool

b pool pavan_pl '{

  monitor all pavan_mn

  members 1.1.1.1:80

}'

#Virtual Server

b virtual pavan_vs '{

  destination 10.10.10.1:80

  pool pavan_pl

  ip protocol tcp

}'

Another example for Virtual Server Construct

virtual pavankumar_vs {
snatpool pavan_snatpool_sp
destination 1.1.1.1:80
pool pavan_pl
ip protocol tcp
rules pavan_test_rl
persist source_ip_persist_pr
profiles{ 
clientssl_pavan_pr{
client side
     }
     serverssl_default_tcs_pr{
     serverside
     }
     http_default_tcs_pr{}
     tcp_default_tcs_pr{}
     }
     vlans p_bspos_f_r_770 enable


}


Health Monitors

A monitor is a test that the LTM can perform on either a node of member. A monitor typically tests for a specific response within a specified time period. BigIP uses the results of this to decide on whether traffic should be sent to the node or pool member.

TYPES OF MONITORING

There 4 main types of monitoring:

      Address Check       - IP address (Node)

      Service Check        - IP : port

      Content Check        - IP : port & check data returned

      Interactive Check  - Interactive with servers. Multiple commands and multiple responses.

ADDRESS CHECK

This is the simplest type of check. An example of an address check is ICMP. This is used to ping an IP address and if there is no response within the specified time period the node is marked as down.

SERVICE CHECK

Rather then just checking the IP Service Checks monitors the port. This is achieved by issuing a layer 4 connection to the node. The connection is opened and closed. If connection fails, the member is marked as as down and no traffic is distributed to the particular node.

CONTENT CHECK

Content Checks check whether the server is also serving the correct content. Once the TCP connection is opened, a command is sent (such as a HTTP GET) and the response is examined and the connection closed. If the connection fails or the received string is not obtained the member is marked as down and no further connections are sent to the member.

Note : It is important that the receive string is not configured using a string that may be also used with any error pages (such as a 404 page), as this would prevent the monitor from correctly marking the the member as offline.

INTERACTIVE CHECK

Protocols such as FTP require interactive checks as additional commands such as username, password and directory are typically required.
Typically Interactive Checks consist of a TCP connection that is opened, command(s) are then sent, the responses examined and the connection closed.
If any condition fails the member is marked as down and no further connections are sent to the member.

Note : Most interactive checks are external monitors. External monitors external scripts (perl, shell etc) that the LTM calls to perform the required tests (and to aggregate the results).

Below describes the various interactive checks available:

Scripted Monitors - Scripted Monitors use the Expect method/"model" (send/expect) to determine a nodes health. Expect is a UNIX binary that sends a command and then expects are specific response back.
External Monitors - External Monitors are custom shell scripts that can be created to determine the health of a node.
Performance Monitors - As the name suggests Performance monitors deem the nodes health by querying the nodes performance. There are a number of methods in which this can be achieved. These are :
   - Dynamic Ratio LoadBalancing - Dynamic Ratio Load-Balancing queries the given agent on either a RealNetwork RealServer, WMI or SNMP based platform to determine a ratio value. This ratio value is then dynamically assigned to the node.
   - SNMP DCA - SNMP DCA determines performance via the data collected from the nodes SNMP agent.
   - SNMP DCA Base - SNMP DCA determines performance via only the user-data collected from the nodes SNMP agent.
   - WMI - WMI determines performance via the data collected from the nodes WMI agent.

Normally Health Monitors are either Layer 7 or Layer 4

based.

Layer 7 load balancers health check the performance of the applications on the servers, these servers that come from the hardware and/or virtual load balancer manufacturers

Example : HTTP or HTTPS

Layer 4 load balancers are able to monitor the health of the server and decide whether to take it out of the network or to continue to use it, these load balancers cannot monitor the health of the applications

Example: TCP or UDP

Recommended Setting - Timeout = (3 x Interval) + 1 sec.

Interval - Interval between checks. 

Timeout - Defines how long F5 should wait before marking a                    node/member as down.

SCRIPTED MONITORS

You use the Scripted type of monitor to generate a simple script that reads a file that you create. The file contains send and expect strings to specify lines that you want to send or that you expect to receive. 

expect 220 send HELO bigip1.somecompany.net\r\n expect 250 send quit\r\n

Using a Scripted monitor, you can then generate a script that acts on the above file. When the Scripted monitor script reads this file, the script examines each line, and if the line has no quotation marks (" "), the line is sent or expected to be received as is. If the line is surrounded by quotation marks, the script strips off the quotation marks, and examines the line for escape characters, treating them accordingly.

Name "" Type Scripted Import Settings scripted Interval 10 Timeout 31 Manual Resume No Check Until Up No Filename <filename> Alias Address * All Addresses Alias Service Port * All Ports Debug No

Name

Specifies a unique name for the custom monitor, such as my_scripted_monitor.

Type

Specifies the type of monitor you are creating.

Interval

Specifies the frequency at which the system issues the monitor check. The default is 10 seconds.

Timeout

Specifies the number of seconds in which the node must respond to the monitor request. The default is 31 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.

Manual Resume

Using the Manual Resume setting, you can manually designate a resource as being available. 

Check Until Up

Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member. 

Filename

The Filename setting specifies the name of a file that you create. The file contains send and expect strings to specify lines that you want to send or that you expect to receive.

Alias Address and Alias Service Port

The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses. 

The Debug setting specifies whether the monitor sends error messages and additional information to a log file created and labeled specifically for the monitor. Possible values for the Debug setting are No and Yes. The default setting is No, which specifies that the system does not redirect error messages and additional information related to this monitor. The Yes setting specifies that the system redirects error messages and additional information to the/var/log/<monitor_type>_<ip_address>.<port>.log file. You can use the log information to help diagnose and troubleshoot unsuccessful health checks.

External Monitors

Using an External type of monitor, you can create your own monitor type. To do this, you create a custom External-type monitor and within it, specify a user-supplied monitor to run.

Name "" Type External Interval 5 Timeout 16 Manual Resume No Check Until Up No External Program "" Arguments "" Variables "" Alias Address * All Addresses Alias Service Port * All Ports

Name

Specifies a unique name for the custom monitor, such as my_external_monitor.

Type

Specifies the type of monitor you are creating.

Interval

Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.

Timeout

Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.

Manual Resume

Using the Manual Resume setting, you can manually designate a resource as being available. 

Check Until Up

Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member. 

External Program

It is the External Program setting that you use to specify the executable name of your user-supplied monitor program. An External-type monitor searches the directory /usr/bin/monitors for that monitor name.

Arguments

The Arguments setting allows you to specify any command-line arguments that are required.

Variables

This setting specifies the variables that an External monitor requires, namely a Name/Value pair.

Alias Address and Alias Service Port

The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses

HTTP Monitors

You can use an HTTP type of monitor to check the status of Hypertext Transfer Protocol (HTTP) traffic. Like a TCP monitor, an HTTP monitor attempts to receive specific content from a web page, and unlike a TCP monitor, may send a user name and password. 

Name "" Type HTTP Interval 5 Timeout 16 Manual Resume No Check Until Up No Send String GET / Receive String "" User Name "" Password "" Reverse No Transparent No Alias Address * All Addresses Alias Service Port * All Ports

Name

Specifies a unique name for the custom monitor, such as my_http_monitor.

Type

Specifies the type of monitor you are creating.

Interval

Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.

Timeout

Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.

Manual Resume

Using the Manual Resume setting, you can manually designate a resource as being available. 

Check Until Up

Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member. 

Send String and Receive String

This type of monitor takes a Send String value and a Receive String value. If the Send String value is blank and a connection can be made, the service is considered up. A blank Receive String value matches any response. The check is successful when the content matches the Receive String value. Note that you can specify the value of a response header as the Receive String value. For example, the value of the Receive String attribute can be 404 Object Not Found.

User Name and Password

If there is no password security, you must use blank strings [""] for the Username and Password settings.)

Transparent and Reverse

Both Transparent and Reverse modes are options. 

HTTPS MONITORS

You use an HTTPS type of monitor to check the status of Hypertext Transfer Protocol Secure (HTTPS) traffic. An HTTPS type of monitor attempts to receive specific content from a web page protected by SSL security. The check is successful when the content matches the Receive String value.

The BIG-IP system provides two pre-configured HTTPS monitors, https and https_443. Figure A.6 shows the settings of the pre-configured monitor https, and Figure A.7 shows the settings of the pre-configured https_443.

Name "" Type HTTPS Interval 5 Timeout 16 Manual Resume No Check Until Up No Send String GET / Receive String "" Cipher List "" User Name "" Password "" Compatibility Enabled Client Certificate "" Reverse No Transparent No Alias Address * All Addresses Alias Service Port * All Ports

Name

Specifies a unique name for the custom monitor, such as my_https_monitor or my_https_443_monitor.

Type

Specifies the type of monitor you are creating.

Interval

Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.

Timeout

Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.

Manual Resume

Using the Manual Resume setting, you can manually designate a resource as being available. 

Check Until Up

Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member. 

Send String and Receive String

This type of monitor takes a Send String value and a Receive String value. If the Send String value is blank and a connection can be made, the service is considered up. A blank Receive String value matches any response. The check is successful when the content matches the Receive String value. Note that you can specify the value of a response header as the Receive String value. For example, the value of the Receive String attribute can be 404 Object Not Found.

Cipher List

If you do not specify a cipher list, the monitor uses the default cipher list DEFAULT:+SHA:+3DES:+kEDH.

User Name and Password

If there is no password security, you must use blank strings [""] for the Username and Password settings.)

Compatibility

When you set the Compatibility setting to Enabled, this sets the SSL options to ALL.

Client Certificate

You use the Client Certificate setting to specify a certificate file that the monitor then presents to the server.

Transparent and Reverse

Both Transparent and Reverse modes are options. 

Alias Address and Alias Service Port

The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses. 

PERFORMANCE MONITORS

Real Server

A Real Server type of monitor checks the performance of a pool, pool member, or node that is running the RealSystem Server data collection agent. The monitor then dynamically load balances traffic accordingly. Performance monitors are generally used with dynamic ratio load balancing.

Note: Unlike health monitors, performance monitors do not report on the status of a pool, pool member, or node.

The BIG-IP system provides a pre-configured Real Server monitor named real_server. 

Name "" Type Real Server Interval 5 Timeout 16 Manual Resume No Method GET Command GetServerStats Metrics ServerBandwidth:1.5, CPUPercentUsage, MemoryUsage, TotalClientCount Agent Mozilla/4.0 (compatible: MSIE 5.0; Windows NT)

Like all pre-configured monitors, the real_server monitor cannot be modified by users. However, if you want to modify the Metrics setting, you can create a custom Real Server monitor, to which you can add metrics and modify metric values.

Name

Specifies a unique name for the custom monitor, such as my_real_server_monitor.

Type

Specifies the type of monitor you are creating.

Interval

Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.

Timeout

Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.

Manual Resume

Using the Manual Resume setting, you can manually designate a resource as being available

Gateway ICMP Monitor

A Gateway ICMP type of monitor has a special purpose. You use this monitor for a pool that implements gateway failsafe for high availability.

A Gateway ICMP monitor functions the same way as an ICMP monitor, except that you can apply a Gateway ICMP monitor to a pool member. (Remember that you can apply an ICMP monitor to a node only and not a pool member.) 

Name "" Type Gateway ICMP Interval 5 Timeout 16 Manual Resume No Check Until Up No Transparent No Alias Address * All Addresses Alias Service Port * All Ports

Name
Specifies a unique name for the custom monitor, such as my_gw_icmp_monitor.

Type
Specifies the type of monitor you are creating.

Interval
Specifies the frequency at which the system issues the monitor check. The default is 5 seconds.

Timeout
Specifies the number of seconds in which the node must respond to the monitor request. The default is 16 seconds. If the node responds within the set time period, the node is considered to be up. If the node does not respond within the set time period, the node is considered to be down. The Timeout value should be three times the Interval value, plus one second.

Manual Resume
Using the Manual Resume setting, you can manually designate a resource as being available. 

Check Until Up
Enabling the Check Until Up feature causes the monitor to check the health of the pool member as usual, until the pool member is determined to be up. When the pool member is determined to be up, the BIG-IP system disables health checks for the pool member. 

Transparent
The Transparent mode is an option for this type of monitor. When you set this mode to Yes, the monitor pings the node with which the monitor is associated. 

Alias Address and Alias Service Port

The Alias Address setting specifies the destination IP address that the monitor checks, with the default value * All Addresses. 

LTM Comes with a set of monitors known as "monitorroot"

Monitor Examples

monitorroot type http {
defaults from none
interval 5
up interval 0 
timeout 16 
time until up immediate 
dest *:*
ignore down response disable 
enable 
is read only 
partition Common 
}

monitor gateway_icmp_default_mn{
defaults from gateway_icmp 
interval 30 
timeout  91

}

Example HTTP Monitor

monitorroot type http {
defaults from none 
interval 5 
up interval 0 
timeout 16 
time until up immediate 
dest *:* 
ignore down response disable 
enable 
is read only 
partition Common 
password none 
recv disable none 
 recv none
send "GET /\r\n"
username none 
}

monitor http_default_mn{
defaults from http 
recv "200 OK"
send "GET /health/health.htm
HTTP/1.0\r\n\r\n"

}

Example TCP Monitor

monitorroot type tcp {
defaults from none 
interval 5 
up interval 0 
timeout 16 
time until up immediate 
dest *:* 
ignore down response disable 
enable 
is read only 
partition Common 
recv disable none
recv none
send none
}

monitor tcp_80_crml_mn{
defaults from tcp 
dest *:http
}

pool ams_r7pd002srs_crml_80_pl{
lb method member predictive 
monitor all tcp_80_crml_mn
members {
10.174.72.14:http{}
10.174.72.15:http{}
}

}

Multiple Monitor Example

pool mail_alo_mns_135_7575_7576_pl{
lb method least conn 
action on svcdown reselect 
slow ramp time 600 
monitor all tcp_7575_mms_mn and tcp_7576_mms_mn and 
https_443_mms_mn 
members{ 
10.228.4.10:any{} 
10.228.4.11:any{} 

}

STATUS DUE TO MONITORS

TYPES

There are 4 main status types (with regards to monitors). These are :

• Up / Available - Means the most recent monitor check was successful.
• Down / Offline - Means no response equal to the configured timeout period.
• Unknown - Typically means no monitor is assigned nor the monitor has yet to return a result.
• Connection Limit / Unavailable - Previously defined connection limit has been reached. In turn no traffic is sent.

POOLS

Pools are group of servers that will be used as resources for the VIP

They are consist of 

• Load Balancing Method
• Pool Members
• Protocol port
• monitor

Pool features

You can configure Local Traffic Manager to perform a number of different operations for a pool. For example, you can:

• Associate health monitors with pools and pool members
• Enable or disable SNAT connections
• Rebind a connection to a different pool member if the originally-targeted pool member becomes unavailable
• Specify a load balancing algorithm for a pool
• Set the Quality of Service or Type of Service level within a packet
• Assign pool members to priority groups within a pool

Load Balancing Pool

A load balancing pool is a logical set of devices, such as web servers, that you group together to receive and process traffic. Instead of sending client traffic to the destination IP address specified in the client request, Local Traffic Manager sends the request to any of the servers that are members of that pool. This helps to efficiently distribute the load on your server resources.

When you create a pool, you assign pool members to the pool. A pool member is a logical object that represents a physical node (server), on the network. You then associate the pool with a virtual server on the BIG-IP system. Once you have assigned a pool to a virtual server, Local Traffic Manager directs traffic coming into the virtual server to a member of that pool. An individual pool member can belong to one or multiple pools, depending on how you want to manage your network traffic.

The specific pool member to which Local Traffic Manager chooses to send the request is determined by the load balancing method that you have assigned to that pool. A load balancing method is an algorithm that Local Traffic Manager uses to select a pool member for processing a request. For example, the default load balancing method is Round Robin, which causes Local Traffic Manager to send each incoming request to the next available member of the pool, thereby distributing requests evenly across the servers in the pool.

Load Balance Methods

Methods fall into two groups

• Static
• Dynamic

Round Robin(static)

• BigIP gets a new request and sends to the first server in the pool
• The next request is sent to the next server in the pool
• This process repeats
• Round Robin mode works well in most configurations, especially if the equipment that you are load balancing is roughly equal in processing speed and memory.

Ratio(static)

• Ratio values are placed on the pool members
• Used to send a percentage of traffic to a certain pool member based upon the weight

Priority(Static)

• Set a priority to members of the pool
• Often used to send all traffic to one server and if the server fails, then send traffic to the other pool member

Least Connection(Dynamic)

• Makes a LB decision based upon which server has the least amount of connections

Nodes

• Pool members are a combination of IP address and a port
• Nodes are objects that consist of only the pool member's IP Address
• Nodes can be used in many pools
• You don't need to create a node before creating a pool member
• Nodes are created as soon as pool member is created

PROFILES

• Provides information for how the VIP should behave
• Controls how connections are managed
• Can provide more details packet inspection based upon the profile
• You must have a profile assigned to a vitual server. If the profile is not specified, will use a TCP or UDP by default depending upon the protocol

b virtual pavan_vs{
destination 1.1.1.1:80 
pool pavan_pl 
ip protocol tcp 
profile tcp_default_pr 
}

Profile Categories

Protocol

• TCP
• UDP

FastL4
Services

• HTTP
• FTP

Persistence
SSL

• Client - Decrypting Traffic between Client and LTM
• Server - Encrypting Traffic between LTM and Server

Viewing Profile Configuration

b profile <profile_name> list

• Will show common parameters of the profile

b profile <profile_name> list all 

• Will show all parameters of the profile

Profile types

The LTM system provides several types of profiles. While some profile types correspond to specific protocols, such as HTTP, SSL, and FTP, other profiles pertain to traffic behaviors applicable to multiple protocols. Examples of these are connection persistence profiles and authentication profiles. 

PROFILE TYPE	DESCRIPTION
Protocol profiles
Fast L4	Defines the behavior of Layer 4 IP traffic.
Fast HTTP	Improves the speed at which a virtual server processes traffic.
TCP	Defines the behavior of TCP traffic.
UDP	Defines the behavior of UDP traffic.
Services profiles
HTTP	Defines the behavior of HTTP traffic.
FTP	Defines the behavior of FTP traffic.
SSL profiles
Client SSL	Defines the behavior of client-side SSL traffic. See also Persistence Profiles.
Server SSL	Defines the behavior of server-side SSL traffic. See also Persistence Profiles.
Persistence profiles
Cookie	Implements session persistence using HTTP cookies.
Destination Address	Implements session persistence based on the destination IP address specified in the header of a client request. Also known as sticky persistence.
Hash	Implements session persistence in a way similar to universal persistence, except that the LTM system uses a hash for finding a persistence entry.
MSRDP	Implements session persistence for Microsoft Remote Desktop Protocol sessions.
SIP	Implements session persistence for connections using Session Initiation Protocol Call-ID.
Source Address	Implements session persistence based on the source IP address specified in the header of a client request. Also known as simple persistence.
SSL	Implements session persistence for non-terminated SSL sessions, using the session ID.
Universal	Implements session persistence using the LTM system's Universal Inspection Engine (UIE).
Authentication profiles
LDAP	Allows the LTM system to authenticate traffic based on authentication data stored on a remote Lightweight Directory Access Protocol (LDAP) server.
RADIUS	Allows the LTM system to authenticate traffic based on authentication data stored on a remote RADIUS server.
TACACS+	Allows the LTM system to authenticate traffic based on authentication data stored on a remote TACACS+ server.
SSL Client Certificate LDAP	Allows the LTM system to control a client's access to server resources based on data stored on a remote LDAP server. Client authorization credentials are based on SSL certificates, as well as defined user groups and roles.
SSL OCSP	Allows the LTM system to check on the revocation status of a client certificate using data stored on a remote Online Certificate Status Protocol (OCSP) server. Client credentials are based on SSL certificates.
Other profiles
OneConnect	Enables client requests to reuse server-side connections. The ability for the LTM system to reuse server-side connections is known as Connection PoolingTM.
Stream	Defines the behavior of Real-Time Streaming Protocol (RTSP) traffic.

..... ............................. wait for updates !!!!