1

LTM Tech Day

Presented by:
Eduardo Saito / Bruno Hatajima
Systems Engineer
Version 2.0
08/06/2011
 2

Agenda
Introduction
Basic Components
Networking and Network Translations
Load Balancing
Monitors
Profiles
Persistence
SSL Acceleration
iRules
 3

Introduction
 4

F5’s Application Delivery Network

International
Data Center
Cell

PC - Home Enterprise Manager /

ControlPoint
Applications &
BIG-IP BIG-IP Local
Storage
BIG-IP Link Traffic BIG-IP
ARX
Global Controller Manager Application
FirePass File/Data
Traffic Security
SSL VPN Virtualization
Manager BIG-IP Web Manager
Remote - WANJet
Accelerator
WAN

iControl

PC - LAN
TMOS

WLAN

Business Goal: Achieve these objectives in the most operationally

efficient manner
 5

The BigIP Local Traffic Manager (LTM)

The BigIP LTM more than a load balancer:
– High Availability
• Application load balancing
• Extensive monitoring of applications
• Stateful Failover
– Application Acceleration
• SSL Offload
• HTTP Compression
• Ram Cache
– Security
• Default deny device
• Packet Filters
• Application Security Module
 6

BIG-IP Hardware Line-up

Price
BIG-IP 8900

BIG-IP 6900
2 x Quad core CPU
16 10/100/1000 + 8x 1GB SFP
2x 320 GB HD (S/W RAID) + 8GB CF
16 GB memory
SSL @ 58K TPS / 9.6Gb bulk
6 Gbps max hardware compression
12 Gbps Traffic
BIG-IP 3600 2 x Dual core CPU
16 10/100/1000 + 8x 1GB SFP Multiple Product Modules
2x 320 GB HD (S/W RAID) + 8GB CF
8 GB memory
SSL @ 25K TPS / 4 Gb bulk
BIG-IP 1600 Dual core CPU
5 Gbps max hardware compression
6 Gbps Traffic
8 10/100/1000 + 2x 1GB SFP
Multiple Product Modules
1x 160 GB HD + 8GB CF
4 GB memory
SSL @ 10K TPS / 2 Gb bulk
1 Gbps max software compression
Dual core CPU
4 10/100/1000 + 2x 1GB SFP 2 Gbps Traffic
1x 160GB HD 1 Advanced Product
4 GB memory
SSL @ 5K TPS / 1 Gb Bulk
Module
1 Gbps max software compression
1 Gbps Traffic
1 Basic Product Module

Function / Performance
 7

On-Demand & Dynamic Application Security

c al Traffic
P Lo IP
BIG-I er + BIG- y
g it
Mana ion Secur
cat
Appli anager
M

Leading Value
• World’s first on-demand scaling Web Application Firewall
• Advanced security
• Integrated security performance
• Application insight/visibility

Better security  2x+ performance!

 8

On Demand – Zero Reconfiguration

Virtual
Machines

Servers

Physical Server

Virtual
Machines
Servers

• Automatic addition of power Physical Server

Servers
• No need to overprovision
• Fixed and predictable opex
 9

Basic Components
 10

LTM Components
Node
– IP address of physical server

10.20.3.110
Member
– A member is an IP Address:Service combination
– Members are those entities placed into pools
– A single physical server may host any number of pool members
• Therefore a single physical server can be a member of multiple pools 10.20.3.110:80 (http)
• Multiple virtual servers can use the same physical server 10.20.3.110:443 (https)

Pool
– A pool is a group of members supporting a particular application
– Each pool has its own characteristics and load balancing method
10.20.3.110:80 10.20.3.120:80

Virtual Server
– Is a combination of a virtual IP address and virtual service 64.128.16.100:80
– This IP address:service combination represents a pool to the
outside world
– The service of the virtual server does not have to match the
service of the pool
• So, virtual servers can perform port translation, as well as, address
translation 10.20.3.110:80 10.20.3.120:80
– Access is limited to the defined port only
 BigIP LTM Components
Intranet/Internet

Client 10.10.10.1
Virtual Server
HTTP_VS
172.16.1.230:80
Pool
HTTP_Pool

172.16.1.0/24 Production Network

Intf 1.1
VLAN External
IP 172.16.1.1

Intf 1.2
VLAN Internal
IP 192.168.114.1

192.168.114.0/24 Server Network

HTTP_Pool
Members
192.168.114.125:80
192.168.114.126:80
192.168.114.127:80

192.168.114.125 192.168.114.127
192.168.114.126
Node Information
Default Gateway: 192.168.114.1 (the BigIP)
Services: http (port 80) and ftp (port 21)
 12

Setup Modes
and
Network Translations
 13

Overview
Traffic to and from pools must pass through the
BigIP LTM for normal load balancing and
application acceleration to work

– Ideally, real servers sit behind the BigIP with the BigIP
as their default gateway

– More often, BigIPs need to be inserted into existing

networks, without changing the existing IP address
structure
 14

Overview
There are two primary methods used to set up the
BigIP LTM to ensure the traffic flows properly
– Routed Mode (Recommended)
– Source NAT (SNAT)
• Also know as “One Armed”

There are three types of network translation performed

on the BigIP LTM

– Virtual Server (Network and Port Translation)

– Source (aka Secure) Network Address Translation (SNAT)
– Network Address Translation (NAT)
 15

Setup - Routed Mode

Routed Mode is the recommended mode and the most commonly used

In Routed Mode the real servers are on an internal network behind the LTM
and use the LTM as their default gateway. The virtual servers are on a
external network segment accessible by the clients. The LTMs essentially
“route” the traffic between the real servers and clients

Advantage:
– Simple networking topology
– Easy to debug
– Allows the BIG-IP to provide an additional layer of security
• The LTM essentially acts as a firewall, virtual servers can only be contacted on the
configured IP and port
• Additional packet filters (ACL) may be applied

Disadvantage:
– New networks and VLANs may need to be created
– Servers default gateways may need to be reconfigured to point to the LTM
– Additional LTM configuration may be need to access for direct access to real
servers
 Routed Mode Network Example
Client makes request

Source 10.10.10.1 Intranet/Internet

Destination 172.16.1.230
Client 10.10.10.1
The BigIP translates the source
Virtual Server IP address to the virtual server
HTTP_VS and sends the packet on.
172.16.1.230:80
Pool Destination 10.10.10.1
HTTP_Pool
Source 172.16.1.230

172.16.1.0/24 Production Network

Intf 1.1
VLAN External
IP 172.16.1.1

Intf 1.2 The server returns the packet to the

VLAN Internal source IP.
IP 192.168.114.1
Destination 10.10.10.1
Source 192.168.114.125

192.168.114.0/24 Server Network

F5 loadbalances the request and

changes the destination IP address

Source 10.10.10.1
Destination 192.168.114.125 HTTP_Pool
Members
192.168.114.125:80
192.168.114.126:80
192.168.114.127:80

192.168.114.125 192.168.114.127
192.168.114.126
Node Information
Default Gateway: 192.168.114.1 (the BigIP)
Services: http (port 80) and ftp (port 21)
 17

SNAT (“One Armed”) Setup

SNAT Mode allows the LTMs to be inserted into the network without impact.

SNATs are used to translate the client IP, to an IP owned by the LTM, forcing
real servers to respond through the LTM to client requests

Advantage:
– No changes to your servers or network.
– Easy option for quick proof of concept testing.
– OneConnect (connection aggregation / reduction feature) can operate in its most
aggressive mode, giving your servers the maximum performance by reducing TCP
and HTTP connections.
– No additional LTM configuration needed for direct access to real servers

Disadvantage:
– Servers see the BIG-IP as the client, which may require changes to your logging
mechanism, however, BIG-IP can insert the original source IP address into the
HTTP headers using
• an x-forward header (via http profile)
• a custom header (via iRules)
– Allows direct access to servers, reduced security
Why SNATs are required for seamless integration into the network
Intranet/Internet
Client makes request

Source 10.10.10.1 Client 10.10.10.1

Destination 192.168.114.230

Virtual Server
HTTP_VS
192.168.114.230:80
Pool
HTTP_Pool

Default Gateway
192.168.114.1

The server (using it’s default

gateway) returns the packet
Intf 1.2 directly to the source IP.
VLAN myvlan114
IP 192.168.114.240 Destination 10.10.10.1
Source 192.168.114.125

192.168.114.0/24 Server Network

F5 loadbalances the request and

changes the destination IP address

Source 10.10.10.1
Destination 192.168.114.125 HTTP_Pool
Members
192.168.114.125:80
192.168.114.126:80
192.168.114.127:80

192.168.114.125 192.168.114.127
192.168.114.126
Node Information
Default Gateway: 192.168.114.1
Services: http (port 80) and ftp (port 21)
 Source NAT (aka “One-Armed) Mode
Client makes request

Source 10.10.10.1 Intranet/Internet

Destination 192.168.114.230
Client 10.10.10.1

The BigIP translates the source

Virtual Server and destination IP addresses to
HTTP_VS
192.168.114.230:80
the virtual server and the original
Pool client and sends the packet on.
HTTP_Pool
Destination 10.10.10.1
Source 192.168.114.230

Default Gateway
192.168.114.1

Intf 1.2
The server returns the packet to the
VLAN myvlan114 source IP (which is now the BigIP).
IP 192.168.114.240
(SNAT Automap) Destination 192.168.114.240
Source 192.168.114.125

F5 loadbalances the request 192.168.114.0/24 Server Network

and using the SNAT changes
the source IP to the self IP of
myvlan114 and then changes
the destination IP address to the
chose server.

Source 192.168.114.240 HTTP_Pool

Destination 192.168.114.125
Members
192.168.114.125:80
192.168.114.126:80
192.168.114.127:80

192.168.114.125 192.168.114.127
192.168.114.126
Node Information
Default Gateway: 192.168.114.1
Services: http (port 80) and ftp (port 21)
 20

Labs 1A and 1B

Lab 1A – Networking the BigIP

Lab 1B – Building Pools and Virtual Servers

 21

Load Balancing
 22

Load Balancing Methods

Static Methods
– Round Robin
– Ratio (Weighted Round Robin)
• Distributes connections in a Round Robin faction for those members/nodes whose
ratio has not been met

Dynamic Methods
– Least Connections
– Fastest
• Next connection to member/node with fastest response time
• Based on monitor responses
– Observed
• Next connection to member with best response time but, if response times are equal,
the member/node with the fewest connections is chosen
– Predictive
• Same as observed except rated over time
– Dynamic Ratio
• Dynamically weights servers based on results SNMP queries
 23

Load Balancing
Two Primary Pool Failure Mechanisms
– Priority Group Activation
• Ability to dynamically pull in new members into the pool
• Lower priority groups are pull into higher priority groups
– Fallback hosts
• HTTP redirect (http 302) to node or virtual server

Load balancing member (service) versus node (IP address)

– Member load balancing looks only at the member’s pool statistics
– Node load balancing looks at all service pools a node participates in
• An example, is a server is in two pools one for HTTP and one for FTP using least
connection (node)

Default gateway pools

– SNATs can be used to load balance traffic across multiple ISPs or through
multiple gateways
 24

Load Balancing

LAB 2 – Load Balancing

 25

Monitors
 26

Monitors
A monitor is a test of a specific device, for an expected
response, within a given time.

The administrator can configure the interval between

checks and when the monitor times out.
– Interval is the time between each check
– Timeout is the length of time for a successful check to be
received before the node is marked down

The LTM can use composite monitors, so multiple checks

can be applied!

Monitors can also use reverse logic

 27

Monitors (cont.)
Node Checks
– Determine availability of all services for a particular node
• Example: ICMP check, is the node pingable
– When check fails, node is pull from all pools it has membership in

Service Checks
– Checks connectivity to services/ports
• Example: HTTP check, can port 80 be opened

Content Checks
– Queries the service and checks the contents of the query
• Example: HTTP GET /, is the page returning with correct content
– Content checks can involve username and passwords

Path Checks
– Are transparent monitors checking through devices to verify a path exists

Interactive Checks
– Custom scripts can be created to interact with application
– Examples are in /usr/bin/monitors
 28

Monitor Types
Simple monitors
– ICMP checks the status of a node, using Internet Control Message Protocol (ICMP).
– Gateway ICMP checks nodes in a pool that implements gateway failsafe for high availability.
– TCP Echo checks the status of a node, using Transmission Control Protocol (TCP).

Extended Content Verification (ECV) monitors

– TCP verifies the Transmission Control Protocol (TCP) service by attempting to receive specific
content from a node.
– HTTP verifies the Hypertext Transfer Protocol (HTTP) service by attempting to receive
specific content from a web page.
– HTTPS verifies the Hypertext Transfer Protocol Secure (HTTPS) service by attempting to
receive specific content from a web page protected by Secure Socket Layer (SSL) security.

Extended Application Verification (EAV) monitors

– External allows users to monitor services using their own programs.
– FTP verifies the File Transfer Protocol (FTP) service by attempting to download a specific file
to the /var/tmp directory on an LTM system. Once downloaded successfully, the file is
notsaved.
– IMAP Verifies the Internet Message Access Protocol (IMAP) by attempting to open a specified
mail folder on a server. This monitor is similar to the pop3 monitor.
– LDAP Verifies the Lightweight Directory Access Protocol (LDAP) service by attempting to
authenticate the specified user.
– MSSQL Verifies Microsoft® Windows SQL-based services.
– NNTP Verifies the Usenet News protocol (NNTP) service by attempting to retrieve a
newsgroup identification string from the server.
 29

Monitor Types
EAV monitors (continued)

– Oracle Verifies services based on Oracle® by attempting to perform an Oracle login to a

service.
– POP3 Verifies the Post Office Protocol (pop3) service by attempting to connect to a pool, pool
member, or node, log on as the specified user, and log off.
– RADIUS verifies the Remote Access Dial-in User Service (RADIUS) service by attempting to
authenticate the specified user.
– Real Server checks the performance of a pool, pool member, or node that is running the
RealServer data collection agent, and then dynamically load balances traffic accordingly.
– SIP checks the status of Session Initiation Protocol (SIP) Call-ID services on a device. The
SIP protocol enables real-time messaging, voice, data, and video.
– SMTP checks the status of a pool, pool member, or node by issuing standard Simple Mail
Transport Protocol (SMTP) commands.
– SNMP DCA Checks the current CPU, memory, and disk usage of a pool, pool member, or
node that is running an SNMP data collection agent, and then dynamically load balances
traffic accordingly.
– SNMP DCA Base Checks the current user usage of a pool, pool member, or node that is
running an SNMP data collection agent, and then dynamically load balances traffic
accordingly. The way that you configure the monitor settings determines the data that the LTM
system collects.
– SOAP Tests a Web service based on the Simple Object Access Protocol (SOAP).
– UDP Verifies the User Datagram Protocol (UDP) service by attempting to send UDP packets
to a pool, pool member, or node and receiving a reply.
– WMI Checks the performance of a pool, pool member, or node that is running the Windows
Management Infrastructure (WMI) data collection agent and then dynamically load balances
traffic accordingly.
 30

Monitor Status Reporting

Status (Color) Status Definition

General: Child – monitor successful, Parent – at least one Child is Green

Available (Green)
Node: Most recent monitor successful
Pool Member: Most recent monitor successful
Pool: At least one Pool Member is available
Virtual Server: At least one Pool is available

General: Child – no associated monitor (or timeout of first check not reached),
Unknown (Blue)
Parent – all child objects are unknown (blue)
Node: No associated monitor (or timeout of first check not reached and not
successful)
Pool Member: No associated monitor (or timeout of first check not reached and not
successful)
Pool: All Pool Members are unknown (blue)
Virtual Server: All Pools are unknown (blue)
General: Child – monitor failed, Parent – at least one Child red AND no green or
Offline (Red) yellow children available
Node: Most recent monitor failed (no successful checks within timeout period)
Pool Member: Most recent monitor failed (no successful checks within timeout
period)
Pool: One or more members are offline and no members are available
Virtual Server: One or more pools offline and no members available
 31

Monitors

Lab 3 - Monitors
 32

Profiles
 33

Profile Facts
A default profile is a predefined profile on the BigIP LTM
– A default profile can be used as is
– Can be used a templates to create custom profiles.
– Can be modified (not recommended).
– Can not be deleted (except via the CLI, also not recommended)

A custom profile is any profile derived from another

profile
– A parent profile is any profile used as a template to create custom
profile
– A child profile is any profile derived from another profile
• All custom profiles are child profiles
– A profile can be both a parent profile and a child profile

A child profile inherits changes to the parent profile

 34

More Profile Facts

Some profiles conflict with each other.
– The LTM will let you know

Multiple profiles can be (and often are) assigned to a

single virtual server.
– For example a secure (HTTPS) server may have a TCP, HTTP,
SSL and Persistence profile assigned to it.

Each profile must have a unique name.

Default profiles are stored in /config/profile_base.conf

Custom profiles are stored in /config/bigip.conf

 35

Profiles Types
Protocol (connection oriented)

Service (data type oriented)

Persistence (session oriented)

SSL (encryption oriented)

Authentication (security oriented)

 36

Profiles Types
Protocol Profiles
– Support parameters concerning timeouts and connection
management
– All Virtual Servers must have at least one protocol profile

Profile Type Prerequisite Profile Incompatible Profiles

fastL4 None ALL
tcp None udp, fastL4
udp None tcp, fastL4
connpool None N/A
 37

Profiles Types
Service Profiles
– Support special features for selected applications
– Require TCP profiles (since they are connection-oriented)

Profile Type Prerequisite Profile Incompatible Profiles

http tcp ftp
ftp tcp http, clientssl, serverssl
 38

Profiles Types
SSL Profiles
– Support encryption/decryption of traffic on the client side or server
side or both
– Require TCP profiles (since they are connection-oriented)

Profile Type Prerequisite Profile Incompatible Profiles

clientssl tcp ftp
serverssl tcp ftp
 39

Profiles Types
Persistence Profiles
– Define methods the LTM uses to treat multiple TCP
connections as a single session
– Used to make persistence decisions

Profile Type Prerequisite Profile Incompatible Profiles

universal None N/A
source_addr (simple) Any None
udp Any None
cookie http N/A
ssl tcp ftp
sip tcp or udp ftp
msrdp tcp N/A
 40

BigIP v10 Practical

Persistence
 41

Persistence
Persistence
– is the ability to continue to direct a client to a server once the initial load
balancing decision has been made
– Required for stateful applications (i.e. eCommerce shopping carts)

Persistence Methods
– Simple Persistence
– SSL Session ID
– Session Initiated Protocol (SIP)
– Cookie Persistence
• can persist to server based on information found in cookie
• BigIP can create (insert), rewrite or just watch (passive) cookies
– Each of these persistence methods have weaknesses

– Universal Persistence/Persistence by Expression

• using iRules you can create an expression that defines what you are to persist on
based on packet information
 42

Persistence
Some additional Persistence settings worth noting

– Match Across Services

• Specifies, when checked (enabled), that all persistent connections from
a client IP address which go to the same virtual IP address also go to
the same node. The default is disabled.
– Match Across Virtual Servers
• Specifies, when checked (enabled), that all persistent connections from
the same client IP address go to the same node. The default is
disabled.
– Match Across Pools
• Specifies, when checked (enabled), that the system can use any pool
that contains this persistence record. The default is disabled.
– Timeout
• Specifies the duration of the persistence entries.
• Resets on a new connection
 43

Persistence

Lab 4 - Persistence
 44

BigIP v9 Practical

SSL Acceleration
 45

SSL Traffic Processing

Advantages
– SSL key exchange is done via hardware
– SSL bulk encryption is done via hardware
– Centralized certificate traffic
– Offloading of SSL process frees up valuable server
resources
– Allows rules process and cookie persistence with
encrypted traffic
 46

SSL Traffic Processing

Configuring Client-side SSL

– Create or import a certificate, configure an SSL client profile

using the certificate and attach the SSL client profile to a virtual
server

Client-side Processing

– External traffic is received by the virtual server with a client SSL

profile and is decrypted
– Traffic is process normally, cookie persistence and iRules can
be used
– Traffic is sent unencrypted to the chosen member
 47

SSL Traffic Processing

Lab 5 – SSL Acceleration

 48

BigIP v9 Practical

iRules
 49

iRules
iRules are a powerful yet simple tool for defining the application
traffic that administrators wish to direct, redirect, filter, or persist on

Is a scripting tool which allows you to manage traffic base on an

individual connections or a particular event

Based on the Tools Command Language (TCL)

Using a feature call the Universal Inspection Engine (UIE), an iRule

can inspect the header of a packet or actual content of the packet
moving in either direction
 50

Solution: Server Resource Cloaking

Description
To protect from web server signatures exposing from potential security holes to hackers,
iRules are used to remove or “cloak” visible web server signatures

HOW IT WORKS
1. Client requests information
from an application and is
5
iRule! Remove Apache v 2.0.49 Reference
routed through BIG-IP
rule when HTTP_RESPONSE {
#
2. BIG-IP directs request to # Remove all but the given headers.
best performing web server #
HTTP::header sanitize “ETag” “Connection” “Content-
TYPE”
3. Web server provides }

application response BUT all

responses – by default –
include information that
2 3
Response from
indicates the type of server 4 Apache Web Server
responding 1 includes server
HTTP Request signatures

4. BIG-IP looks at traffic and HTTP Response

determines it must call the
6
iRule for “Resource Cloaking”

5. iRule runs, removing

Apache references, and send
request on to client

6. Client only sees “sanitized”

response.
 51

http://DevCentral.f5.com
DevCentral is a F5 monitored user forum. Here users share iRules and iControl code.
iRules documentation, examples and the iRule editor can be found at DevCentral.

There are currently over 13,000 registered users.

 52

The F5 iRule Editor is the industry's first

iRule Editor integrated code editor for network devices.

What does that mean for you?

Well, it means that you are no longer constrained

to a simple edit window (or vi for you hard core
geeks out there).

You can now develop iRules with full syntax

highlighting, colorization, textual auto-complete,
integrated help, etc. You get the point...

Developed using iControl!

 53

iRules

Lab 6 – iRules
54