BIG IP Traffic

BIG-IP® Local Traffic Manager:
Implementations
version 10.0.0
MAN-0293-00
Product Version
This manual applies to version 10.0.0 of the BIG-IP® product family.
Publication Date
This guide was published on March 11, 2009.
Legal Notices
Copyright
Copyright 2008-2009, F5 Networks, Inc. All rights reserved.
F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5
assumes no responsibility for the use of this information, nor any infringement of patents or other rights of
third parties which may result from its use. No license is granted by implication or otherwise under any
patent, copyright, or other intellectual property right of F5 except as specifically described by applicable
user licenses. F5 reserves the right to change specifications at any time without notice.
Trademarks
F5, F5 Networks, the F5 logo, BIG-IP, 3-DNS, Acopia, Acopia Networks, Application Accelerator, Ask
F5, Application Security Manager, ASM, ARX, Data Guard, Enterprise Manager, EM, FirePass,
FreedomFabric, Global Traffic Manager, GTM, iControl, Intelligent Browser Referencing, Internet
Control Architecture, IP Application Switch, iRules, Link Controller, LC, Local Traffic Manager, LTM,
Message Security Module, MSM, NetCelera, OneConnect, Packet Velocity, SSL Accelerator, SYN Check,
Traffic Management Operating System, TMOS, TrafficShield, Transparent Data Reduction, uRoam,
VIPRION, WANJet, WebAccelerator, and ZoneRunner are trademarks or service marks of F5 Networks,
Inc., in the U.S. and other countries, and may not be used without F5's express written consent.
Patents
This product protected by U.S. Patents 6,374,300; 6,473,802; 6,970,933; 7,051,126; 7,102,996; 7,146,354;
7,197,661; 7,206,282; 7,287,084. Other patents pending.
Export Regulation Notice

This product may include cryptographic software. Under the Export Administration Act, the United States
government may consider it a criminal offense to export this product from the United States.
RF Interference Warning
This is a Class A product. In a domestic environment this product may cause radio interference, in which
case the user may be required to take adequate measures.
FCC Compliance
This equipment has been tested and found to comply with the limits for a Class A digital device pursuant
to Part 15 of FCC rules. These limits are designed to provide reasonable protection against harmful
interference when the equipment is operated in a commercial environment. This unit generates, uses, and
can radiate radio frequency energy and, if not installed and used in accordance with the instruction manual,
may cause harmful interference to radio communications. Operation of this equipment in a residential area
is likely to cause harmful interference, in which case the user, at his own expense, will be required to take
whatever measures may be required to correct the interference.
Any modifications to this device, unless expressly approved by the manufacturer, can void the user's
authority to operate this equipment under part 15 of the FCC rules.
Canadian Regulatory Compliance

This class A digital apparatus complies with Canadian I CES-003.
BIG-IP® Local Traffic Manager: Implementations i

Standards Compliance
This product conforms to the IEC, European Union, ANSI/UL and Canadian CSA standards applicable to
Information Technology products at the time of manufacture.
Acknowledgments
This product includes software developed by Bill Paul.
This product includes software developed by Jonathan Stone.
This product includes software developed by Manuel Bouyer.
This product includes software developed by Paul Richards.
This product includes software developed by the NetBSD Foundation, Inc. and its contributors.
This product includes software developed by the Politecnico di Torino, and its contributors.
This product includes software developed by the Swedish Institute of Computer Science and its
contributors.
This product includes software developed by the University of California, Berkeley and its contributors.
This product includes software developed by the Computer Systems Engineering Group at the Lawrence
Berkeley Laboratory.
This product includes software developed by Christopher G. Demetriou for the NetBSD Project.
This product includes software developed by Adam Glass.
This product includes software developed by Christian E. Hopps.
This product includes software developed by Dean Huxley.
This product includes software developed by John Kohl.
This product includes software developed by Paul Kranenburg.
This product includes software developed by Terrence R. Lambert.
This product includes software developed by Philip A. Nelson.
This product includes software developed by Herb Peyerl.
This product includes software developed by Jochen Pohl for the NetBSD Project.
This product includes software developed by Chris Provenzano.
This product includes software developed by Theo de Raadt.
This product includes software developed by David Muir Sharnoff.
This product includes software developed by SigmaSoft, Th. Lockert.
This product includes software developed for the NetBSD Project by Jason R. Thorpe.
This product includes software developed by Jason R. Thorpe for And Communications,
http://www.and.com.
This product includes software developed for the NetBSD Project by Frank Van der Linden.
This product includes software developed for the NetBSD Project by John M. Vinopal.
This product includes software developed by Christos Zoulas.
This product includes software developed by the University of Vermont and State Agricultural College and
Garrett A. Wollman.
This product includes software developed by Balazs Scheidler <bazsi@balabit.hu>, which is protected
under the GNU Public License.
This product includes software developed by Niels Mueller <nisse@lysator.liu.se>, which is protected
under the GNU Public License.
In the following statement, "This software" refers to the Mitsumi CD-ROM driver: This software was
developed by Holger Veit and Brian Moore for use with "386BSD" and similar operating systems.
"Similar operating systems" includes mainly non-profit oriented systems for research and education,
including but not restricted to "NetBSD," "FreeBSD," "Mach" (by CMU).
This product includes software developed by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/).
This product includes software licensed from Richard H. Porter under the GNU Library General Public
License (© 1998, Red Hat Software), www.gnu.org/copyleft/lgpl.html.
This product includes the standard version of Perl software licensed under the Perl Artistic License (©
1997, 1998 Tom Christiansen and Nathan Torkington). All rights reserved. You may find the most current
standard version of Perl at http://www.perl.com.
This product includes software developed by Jared Minch.
ii
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit
(http://www.openssl.org/).
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com).
This product contains software based on oprofile, which is protected under the GNU Public License.
This product includes RRDtool software developed by Tobi Oetiker (http://www.rrdtool.com/index.html)
and licensed under the GNU General Public License.
This product contains software licensed from Dr. Brian Gladman under the GNU General Public License
(GPL).
This product includes software developed by the Apache Software Foundation <http://www.apache.org/>.
This product includes Hypersonic SQL.
This product contains software developed by the Regents of the University of California, Sun
Microsystems, Inc., Scriptics Corporation, and others.
This product includes software developed by the Internet Software Consortium.
This product includes software developed by Nominum, Inc. (http://www.nominum.com).
This product contains software developed by Broadcom Corporation, which is protected under the GNU
Public License.
BIG-IP® Local Traffic Manager: Implementations iii

iv
Table of Contents
Table of Contents
1
Introducing Implementations for BIG-IP Local Traffic Manager
Introducing BIG-IP system implementations ............................................................................1-1
Getting started .......................................................................................................................1-1
Using the Configuration utility ............................................................................................1-1
About this guide ..............................................................................................................................1-2
Additional information ..........................................................................................................1-2
Stylistic conventions ..............................................................................................................1-3
Finding help and technical support resources ..........................................................................1-5
2
Configuring nPath Routing
Introducing nPath routing .............................................................................................................2-1
Configuring nPath routing .............................................................................................................2-2
Creating a custom Fast L4 profile ......................................................................................2-3
Creating a server pool for nPath routing .........................................................................2-4
Creating a virtual server ......................................................................................................2-4
Configuring the virtual server on the content server loopback interface ................2-5
Setting the route for inbound traffic .................................................................................2-5
Enabling the connection.autolasthop bigdb key ..............................................................2-5
Setting timers for nPath configurations .....................................................................................2-6
Guidelines for configuring timeouts for UDP traffic .....................................................2-6
Guidelines for configuring timeouts for TCP traffic ......................................................2-6
3
Basic Web Site and E-Commerce Configuration
Working with a basic web site and e-commerce configuration ..........................................3-1
Configuring a basic e-commerce site .........................................................................................3-2
Creating load balancing pools .............................................................................................3-2
Creating virtual servers ........................................................................................................3-3
4
Installing a BIG-IP System without Changing the IP Network
Installing a BIG-IP system without changing IP networks ......................................................4-1
Configuring the BIG-IP system for the same IP network ......................................................4-3
Removing the self IP addresses from the individual VLANs ........................................4-3
Creating a VLAN group .......................................................................................................4-4
Creating a self IP address for the VLAN group ..............................................................4-5
Creating a pool of web servers ..........................................................................................4-5
5
Web Hosting for Multiple Customers
Introducing multiple customer hosting ......................................................................................5-1
Hosting multiple customers using an external switch ............................................................5-2
Creating VLANs with tagged interfaces ...........................................................................5-2
Creating load balancing pools .............................................................................................5-3
Directly hosting multiple customers ..........................................................................................5-5
Creating VLANs with untagged interfaces .......................................................................5-6
BIG-IP® Local Traffic Manger: Implementations vii

Table of Contents
6
A Simple Intranet Configuration
Working with a simple intranet configuration .........................................................................6-1
Creating the simple intranet configuration ...............................................................................6-2
Creating pools ........................................................................................................................6-2
7
Load Balancing ISPs
Introducing ISP load balancing ......................................................................................................7-1
Configuring ISP load balancing .....................................................................................................7-2
Creating pools for an additional Internet connection ...................................................7-2
Creating virtual servers for an additional Internet connection ..................................7-3
Configuring address translation for outbound traffic .............................................................7-5
8
Load Balancing HTTP Traffic with Source Address Affinity Persistence
Introducing basic HTTP load balancing ......................................................................................8-1
Configuring HTTP load balancing with source address affinity persistence ......................8-2
Creating a pool .......................................................................................................................8-2
9
Load Balancing HTTP Traffic with Cookie Persistence
Introducing basic HTTP load balancing ......................................................................................9-1
Configuring HTTP load balancing with cookie persistence ..................................................9-2
Creating a custom persistence profile ..............................................................................9-2
Creating a pool .......................................................................................................................9-3
10
Compressing HTTP Responses
Introducing HTTP data compression ...................................................................................... 10-1
Creating a custom HTTP profile .............................................................................................. 10-2
Creating a virtual server ............................................................................................................. 10-3
11
Configuring HTTPS Load Balancing
Introducing HTTPS load balancing ........................................................................................... 11-1
Creating an SSL key and certificate ......................................................................................... 11-2
Creating a custom SSL profile ................................................................................................... 11-3
Creating a pool ............................................................................................................................. 11-5
viii
Table of Contents
12
Configuring HTTPS Load Balancing with Data Compression
Introducing HTTPS load balancing with compression ......................................................... 12-1
Creating an SSL key and certificate ......................................................................................... 12-2
Creating a custom Client SSL profile ...................................................................................... 12-3
Creating a custom HTTP profile for compression .............................................................. 12-4
Creating a pool ............................................................................................................................. 12-6
13
Using RAM Cache for HTTP Traffic
Introducing HTTP RAM Cache ................................................................................................. 13-1
Creating a custom HTTP profile .............................................................................................. 13-2
14
Load Balancing Passive Mode FTP Traffic
Introducing FTP load balancing ................................................................................................. 14-1
Creating a custom FTP monitor ............................................................................................... 14-2
Creating a pool ............................................................................................................................. 14-3
15
Load Balancing Passive Mode FTP Traffic with Rate Shaping
Introducing FTP load balancing with rate shaping ................................................................ 15-1
Creating a custom FTP monitor ............................................................................................... 15-2
Creating a pool ............................................................................................................................. 15-3
Creating a rate class .................................................................................................................... 15-4
16
Setting up a One-IP Network Topology
Introducing the one-IP network topology ............................................................................. 16-1
Creating a pool for a one-IP network topology ................................................................... 16-2
Defining a default route .............................................................................................................. 16-4
Configuring a client SNAT ......................................................................................................... 16-5
17
Using Link Aggregation with Tagged VLANs
Introducing link aggregation with tagged VLAN interfaces ................................................ 17-1
Using the two-network aggregated tagged interface topology ......................................... 17-2
Aggregating the links .......................................................................................................... 17-3
Assigning a trunk to the VLANs ...................................................................................... 17-3
Creating a pool of web servers to load balance .......................................................... 17-4
Creating a virtual server to load balance the web servers ....................................... 17-5
Using the one-network aggregated tagged interface topology ......................................... 17-6
Removing the self IP addresses from the VLANs ....................................................... 17-7
Creating a VLAN group .................................................................................................... 17-7
Creating a self IP for the VLAN group .......................................................................... 17-8
BIG-IP® Local Traffic Manger: Implementations ix

Table of Contents
18
Setting Up Packet Filtering
Introducing packet filtering ........................................................................................................ 18-1
Configuring packet filtering ........................................................................................................ 18-2
Creating a SNAT ................................................................................................................. 18-2
Creating a gateway pool .................................................................................................... 18-2
Creating a forwarding virtual server .............................................................................. 18-3
Creating a packet filter rule ............................................................................................. 18-4
19
Implementing Health and Performance Monitors
Introducing health and performance monitors ..................................................................... 19-1
Creating a custom monitor ....................................................................................................... 19-3
Creating a pool ............................................................................................................................. 19-4
Assigning a monitor to a pool .......................................................................................... 19-4
Excluding a pool member from a monitor .................................................................... 19-5
20
Load Balancing Traffic to IPv6 Nodes
Configuring the radvd service ................................................................................................... 20-1
Configuring IPv4-to-IPv6 load balancing ................................................................................. 20-2
Creating a pool of IPv6 nodes ......................................................................................... 20-2
Creating a virtual server ................................................................................................... 20-3
21
Implementing Overlapping IP Addresses
Introducing overlapping IP addresses ...................................................................................... 21-1
What is a route domain? ................................................................................................... 21-1
Specifying route domain IDs ............................................................................................ 21-1
Configuring route domains ........................................................................................................ 21-2
Creating VLANs for route domains ............................................................................... 21-3
Creating self IP addresses for route domains .............................................................. 21-5
Creating route domain objects ........................................................................................ 21-6
Creating pool members for route domains ................................................................. 21-7
Creating static routes ........................................................................................................ 21-8
Creating virtual servers for route domains .................................................................. 21-9
22
Mitigating Denial of Service and Other Attacks
Basic denial of service security overview ............................................................................... 22-1
Configuring adaptive connection reaping ............................................................................... 22-2
Logging adaptive reaper activity ...................................................................................... 22-3
Simple DoS prevention configuration ..................................................................................... 22-4
Setting the TCP and UDP connection timers .............................................................. 22-4
Creating an IP rate class and applying it to a virtual server ...................................... 22-5
Setting connection limits on the main virtual server .................................................. 22-6
Filtering out attacks with iRules ............................................................................................... 22-7
Filtering out a Code Red attack ...................................................................................... 22-7
Filtering out a Nimda attack ............................................................................................. 22-7
x
Table of Contents
How the BIG-IP system handles several common attacks ................................................. 22-8
SYN flood ............................................................................................................................. 22-8
ICMP flood (Smurf) ............................................................................................................ 22-9
UDP flood ............................................................................................................................. 22-9
UDP fragment .................................................................................................................... 22-10
Ping of Death ..................................................................................................................... 22-10
Land attack ......................................................................................................................... 22-10
Teardrop ............................................................................................................................. 22-11
Data attacks ....................................................................................................................... 22-11
WinNuke ............................................................................................................................ 22-11
Sub 7 .................................................................................................................................... 22-11
Back Orifice ........................................................................................................................ 22-12
23
Configuring Administrative Domains
Introducing administrative domains ......................................................................................... 23-1
Creating a partition ..................................................................................................................... 23-2
Configuring user access to a partition .................................................................................... 23-3
Viewing, managing, and creating objects in a partition ........................................................ 23-4
Viewing and managing system objects ........................................................................... 23-4
Creating BIG-IP system objects ....................................................................................... 23-5
24
Configuring Remote Authentication and Authorization for Administrative Traffic
Introducing remote authentication and authorization for BIG-IP system user accounts ....
24-1
Configuring the BIG-IP system to use remote authentication of user accounts .......... 24-2
Configuring access control for BIG-IP system users ........................................................... 24-6
Understanding the remoterole command .................................................................... 24-7
Using the remote role command .................................................................................... 24-7
Using variable substitution ................................................................................................ 24-8
Propagating remote authentication and authorization data to multiple BIG-IP devices .....
24-11
25
Configuring Remote Authentication for Application Traffic
Introducing remote authentication for application traffic .................................................. 25-1
Configuring authentication that uses a remote LDAP or Active Directory server ..... 25-2
Creating an LDAP configuration object ........................................................................ 25-2
Creating an LDAP authentication profile ...................................................................... 25-5
Modifying a virtual server for LDAP authentication ................................................... 25-5
Configuring authentication that uses a remote RADIUS server ....................................... 25-7
Creating a RADIUS server object ................................................................................... 25-7
Creating a RADIUS configuration object ...................................................................... 25-8
Creating a RADIUS profile ............................................................................................... 25-9
Modifying a virtual server for RADIUS authentication .............................................. 25-9
Configuring authentication that uses a remote TACACS+ server ................................ 25-11
Creating a TACACS+ configuration object ................................................................ 25-11
Creating a TACACS+ profile ......................................................................................... 25-12
Modifying a virtual server for TACACS+ authentication ........................................ 25-13
BIG-IP® Local Traffic Manger: Implementations xi

Table of Contents
Configuring SSL-based authorization using a remote LDAP server ............................... 25-14

Creating an SSL CLient Certificate LDAP configuration object ............................ 25-14
Creating an SSL Client Certificate LDAP authentication profile ........................... 25-15
Modifying a virtual server for SSL Client Certificate LDAP authorization .......... 25-16
Configuring SSL certificate revocation using an OCSP responder ................................. 25-17
Creating an SSL OCSP responder object ................................................................... 25-17
Creating an SSL OCSP configuration object .............................................................. 25-18
Creating an SSL OCSP profile ....................................................................................... 25-18
Modifying a virtual server for SSL OCSP authentication ......................................... 25-19
Configuring a CRLDP authentication module ..................................................................... 25-20
Creating a CRLDP server object .................................................................................. 25-20
Creating a CRLDP configuration object ...................................................................... 25-21
Creating a CRLDP profile ............................................................................................... 25-22
Modifying a virtual server for CRLDP authentication .............................................. 25-23
26
Configuring Kerberos Delegation
Introducing Kerberos delegation infrastructure ................................................................... 26-1
Configuring the BIG-IP system for Kerberos delegation .................................................... 26-2
Adding a DNS server to the BIG-IP system ................................................................. 26-2
Joining the BIG-IP system to the trusted domain ........................................................ 26-3
Creating the Kerberos delegation configuration .................................................................. 26-5
Configuring Kerberos delegation using the Configuration utility ............................ 26-5
Configuring Kerberos delegation from the command line ....................................... 26-8
Authenticating Client Traffic ................................................................................................... 26-10
27
Configuring Multiple Authentication Servers
Introducing multiple authentication server configuration .................................................. 27-1
Meeting prerequisites .................................................................................................................. 27-2
Configuring BIG-IP system objects .......................................................................................... 27-2
28
Implementing Paired Tunneling
Introducing paired tunneling ...................................................................................................... 28-1
What is paired tunneling? .................................................................................................. 28-1
About data compression ................................................................................................... 28-2
Before you begin ................................................................................................................. 28-3
Configuring the client-side system ........................................................................................... 28-4
Creating a client-side endpoint pool .............................................................................. 28-4
Creating the client-side iSession profile ........................................................................ 28-5
Creating the client-side virtual server ........................................................................... 28-6
Configuring the server-side system ......................................................................................... 28-9
Creating the server-side virtual server ........................................................................ 28-10
Specifying service ports ................................................................................................... 28-11
Viewing data compression statistics ...................................................................................... 28-12
xii
Table of Contents
29
Securing and Accelerating HTTP Traffic with ASM and WA
Overview of the configuration tasks ....................................................................................... 29-1
Completing basic configuration tasks on the Local Traffic Manager ................................ 29-2
Performing initial configuration tasks on the Local Traffic Manager ................................ 29-3
Creating the HTTP class profile ...................................................................................... 29-3
Defining a virtual server and pool on the BIG-IP Local Traffic Manager ............... 29-4
Defining an NTP server ..................................................................................................... 29-6
Creating an application profile for the WebAccelerator system ..................................... 29-7
Selecting an acceleration policy ....................................................................................... 29-7
Planning your host map ..................................................................................................... 29-8
Assigning the WebAccelerator application profile to the security policy in Application
Security Manager ........................................................................................................................ 29-12
Running the Application Security Manager Deployment Wizard ................................... 29-13
30
Securing and Accelerating HTTP Traffic with PSM and WA
Overview of the configuration tasks ....................................................................................... 30-1
Completing basic configuration tasks on the Local Traffic Manager ................................ 30-2
Performing initial configuration tasks on the Local Traffic Manager ................................ 30-3
Creating the WebAccelerator HTTP class profile ..................................................... 30-4
Creating an HTTP service profile ................................................................................... 30-4
Creating a virtual server and pool on the BIG-IP Local Traffic Manager .............. 30-5
Creating an application profile for the WebAccelerator system ..................................... 30-7
Selecting an acceleration policy ....................................................................................... 30-7
Planning your host map ..................................................................................................... 30-8
Creating an HTTP security profile in the Protocol Security Module configuration ... 30-12
Glossary
Index
BIG-IP® Local Traffic Manger: Implementations xiii

Table of Contents
xiv
1
Introducing Implementations for BIG-IP
Local Traffic Manager
• Introducing BIG-IP system implementations
• About this guide
• Finding help and technical support resources

Introducing BIG-IP system implementations

In a typical configuration, the BIG-IP® system functions as a device on the
network, directing different types of protocol and application traffic to an
appropriate destination server. The system accomplishes this by forwarding
the traffic to a load balancing server pool, sending the traffic directly to a
specific server node, or sending it to a next-hop router or a pool of routers.
The most basic configuration of the BIG-IP system includes two virtual
local area networks (VLANs) with one or more BIG-IP interfaces (ports)
assigned to each VLAN. Using the BIG-IP system’s browser-based
Configuration utility, you can implement many configuration scenarios
simply by using the default VLAN configuration, and then creating BIG-IP
system objects such as a customized virtual server, traffic profile, and load
balancing pool.
Note
BIG-IP® Local Traffic Manager is one of several products that constitute

the BIG-IP product family. All products in the BIG-IP product family run on
the powerful Traffic Management Operating System, commonly referred to
as TMOSTM. For an overview of the complete BIG-IP product offering, see
the introductory chapter of the TMOSTM Management Guide for BIG-IP®
Systems.
Getting started
Before you begin implementing a solution in this guide, we recommend that
you familiarize yourself with additional resources such as other BIG-IP
system guides and online help, and review the stylistic conventions that
appear in this chapter. For more information, see About this guide, on page
1-2.
Then, we recommend that you run the Setup utility on the BIG-IP system to
configure basic network and network elements such as static and floating
self IP addresses, interfaces, and VLANs. After running the Setup utility,
you can use this guide to implement specific configuration scenarios. For
information on running the Setup utility, see BIG-IP® Systems: Getting
Started Guide.
Using the Configuration utility

After running the Setup utility, you use the Configuration utility to perform
additional configuration steps necessary for your configuration. For
information on using the Configuration utility, see BIG-IP® Systems:
Getting Started Guide.
For a list of browser versions that the Configuration utility supports, see the
release notes for this product on the Ask F5SM web site,
https://support.f5.com.
BIG-IP® Local Traffic Manager: Implementations 1-1

Chapter 1
About this guide

The chapters contained in this guide provide step-by-step procedures for
implementing complete traffic management solutions using the
Configuration utility. For example, Chapter 3, Basic Web Site and
E-Commerce Configuration, describes how to configure the BIG-IP system
objects that you need to set up an array of web servers that process
e-commerce traffic.
Additional information
In addition to this guide, there are other sources of the documentation you
can use in order to work with the BIG-IP system. The following guides are
available in PDF format from the Ask F5SM web site,
https://support.f5.com:
◆ BIG-IP® Systems: Getting Started Guide
This guide provides detailed information about licensing and
provisioning the BIG-IP system, as well as installing upgrades.
◆ TMOSTM Management Guide for BIG-IP® Systems
This guide contains any information you need to configure and maintain
the network and system-related components of the BIG-IP system, such
as routes, VLANs, and user accounts.
◆ Configuration Guide for BIG-IP® Local Traffic Management
This guide contains any information you need for configuring specific
features of the BIG-IP system to manage local network traffic.
◆ BIG-IP® Application Security Manager: Getting Started Guide
This guide describes how to set up BIG-IP Application Security Manager
to configure security policies.
◆ Configuration Guide for BIG-IP® Application Security Management
This guide provides configuration procedures to protect Web
applications from both generalized and targeted application layer attacks.
• Configuration Guide for BIG-IP® Protocol Security Module
This guide provides the procedures for configuring BIG-IP Protocol
Security Module.
• Configuration Guide for the BIG-IP® WebAcceleratorTM System
This guide describes the core BIG-IP WebAccelerator concepts and
provides the procedures for configuring and monitoring the
WebAccelerator system.
◆ Bigpipe Utility Reference Guide
This guide contains information about using the bigpipe utility
commands to manage the BIG-IP system.
◆ Traffic Management Shell (tmsh) Reference Guide
This guide contains information about using the Traffic Management
Shell (tmsh) commands to manage the BIG-IP system.
1-2
Stylistic conventions
To help you easily identify and understand important information, all of our
documentation uses the stylistic conventions described here.
Using the examples

All examples in this document use only private class IP addresses. When
you set up the implementations we describe, you must use valid IP addresses
suitable to your own network in place of our sample addresses.
Identifying new terms

To help you identify sections where a term is defined, the term itself is
shown in bold italic text. For example, a floating IP address is an IP address
assigned to a VLAN and shared between two computer systems.
Identifying references to products

We refer to all products in the BIG-IP product family as BIG-IP systems.
We refer to the software modules by their name; for example, we refer to the
Local Traffic Manager module as simply the Local Traffic Manager. If
configuration information relates to a specific hardware platform, we note
the platform.
Identifying references to objects, names, and commands

We apply bold text to a variety of items to help you easily pick them out of a
block of text. These items include web addresses, IP addresses, utility
names, and portions of commands, such as variables and keywords. For
example, with the bigpipe self <ip_address> show command, you can
specify a specific self IP address to show by specifying an IP address for the
<ip_address> variable.
Identifying references to other documents

We use italic text to denote a reference to another document or section of a
document. We use bold, italic text to denote a reference to a book title. For
example, for installation instructions, see the guide titled BIG-IP® Systems:
Getting Started Guide.
Identifying command syntax

We show complete commands in bold Courier text. Note that we do not
include the corresponding screen prompt, unless the command is shown in a
figure that depicts an entire command line screen.

Chapter 1
For example, the following command shows the configuration of the

specified pool name:
bigpipe self <ip_address> show
or
b self <ip_Address> show
Table 1.1 explains additional special conventions used in command line
syntax.
Item in text Description
\ Indicates that the command continues on the following line, and that users should type the entire
command without typing a line break.
< > Identifies a user-defined parameter. For example, if the command has <your name>, type in your
name, but do not include the brackets.
| Separates parts of a command.
[] Indicates that syntax inside the brackets is optional.
... Indicates that you can type a series of items.
Table 1.1 Command line syntax conventions
1-4
Finding help and technical support resources

You can find additional technical documentation and product information in
the following locations:
◆ Online help for local traffic management
The Configuration utility has online help for each screen. The online help
contains descriptions of each control and setting on the screen. Click the
Help tab in the left navigation pane to view the online help for a screen.
◆ Welcome screen in the Configuration utility
The Welcome screen in the Configuration utility contains links to many
useful web sites and resources, including:
• The F5 Networks Technical Support web site
• The F5 Solution Center
• The F5 DevCentral web site
• Plug-ins, SNMP MIBs, and SSH clients
◆ F5 Networks Technical Support web site

The F5 Networks Technical Support web site, https://support.f5.com,
provides the latest documentation for the product, including:
• Release notes for the BIG-IP system, current and past
• Updates for guides (in PDF form)
• Technical notes
• Answers to frequently asked questions
• The Ask F5SM Knowledge Base
To access this site, you need to register at https://support.f5.com.

Chapter 1
1-6
2
• Introducing nPath routing
• Configuring nPath routing
• Setting timers for nPath configurations

Introducing nPath routing

With the nPath routing configuration, you can route outgoing server traffic
around the BIG-IP® system directly to an outbound router. This method of
traffic management increases outbound throughput because packets do not
need to be transmitted to the BIG-IP system for translation and forwarding
to the next hop. Figure 2.1 shows an nPath configuration.
Figure 2.1 An example of nPath implementation
Note
The type of virtual server that processes the incoming traffic must be a
transparent, non-translating type of virtual server.
In bypassing the BIG-IP system on the return path, nPath routing departs
significantly from a typical load-balancing configuration. In a typical
load-balancing configuration, the destination address of the incoming packet
is translated from that of the virtual server to that of the server being load
balanced to, which then becomes the source address of the returning packet.
A default route set to the BIG-IP system then sees to it that packets returning

Chapter 2
to the originating client return through the BIG-IP system, which translates
the source address back to that of the virtual server. The nPath configuration
differs from the typical load-balancing configuration, as you can see in the
following section.
Note
Do not attempt to use nPath routing for Layer 7 traffic. Certain traffic
features do not work properly if Layer 7 traffic bypasses the BIG-IP system
on the return path. An example of such a feature is HTTP response
compression.
Configuring nPath routing

The nPath routing configuration differs from the typical BIG-IP load
balancing configuration in the following ways:
◆ The default route on the content servers must be set to the router’s
internal address (10.1.1.1 in Figure 2.1, on page 2-1) rather than to the
BIG-IP system’s floating self-IP address (10.1.1.10). This causes the
return packet to bypass the BIG-IP system.
◆ If you plan to use an nPath configuration for TCP traffic, you must create
a Fast L4 profile with the following custom settings:
• Enable the Loose Close setting. When you enable the Loose Close
setting, the TCP protocol flow expires more quickly, once a TCP FIN
packet is seen. (A FIN packet indicates the tearing down of a
previous connection.)
• Set the TCP Close Timeout setting to the same value as the profile
idle timeout if you expect half closes. If not, you can set this value to
5 seconds.
◆ Because address translation and port translation have been turned off,
when the incoming packet arrives at the pool member it is load balanced
to the virtual server address (176.16.1.1 in Figure 2.1, on page 2-1), not
to the address of the server. For the server to respond to that address, that
address must be configured on the loopback interface of the server and
configured for use with the server software.
You need to complete the following tasks to configure the BIG-IP system to
use nPath routing:
• Create a custom Fast L4 profile.
• Create a pool that contains the content servers.
• Define a virtual server with port and address translation disabled and
assign the custom Fast L4 profile to it.
• Configure the virtual server address on each server loopback interface.
• Set the default route on your servers to the router’s internal IP address.
2-2
• Ensure that the bigdb configuration key connection.autolasthop is

enabled. Alternatively, on each content server, you can add a return route
to the client.
For background information on profiles, pools, and virtual servers, see the
Configuration Guide for BIG-IP® Local Traffic Management.
Note
You perform the tasks contained in this guide using the Configuration
utility; however, the procedures do not include the step of logging on to the
Configuration utility. Before you begin the tasks, log on to the Configuration
utility.
Creating a custom Fast L4 profile

The first task you must complete to create an nPath routing configuration is
to create a custom Fast L4 profile.
To create a custom Fast L4 profile

1. On the Main tab of the navigation pane, expand Local Traffic, and
click Profiles.
The HTTP Profiles screen opens.
2. From the Protocol menu, choose Fast L4.
The Fast L4 Profiles screen opens.
3. To create a custom profile, click Create.
The New Fast L4 Profile screen opens.
Note: If the Create button is unavailable, this indicates that your
user role does not grant you permission to create a Fast L4 profile.
4. In the New Fast L4 Profile screen, set the following attributes:
a) In the Name box, type a name for the profile.
b) Check the Loose Close box.
c) Set the TCP Idle Timeout setting according to the type of traffic
the virtual server is going to handle. For additional information
about setting this timeout, see Setting timers for nPath
configurations, on page 2-6.
5. Click Finished.

Chapter 2
Creating a server pool for nPath routing

After you create a custom Fast L4 profile, you need to create a server pool.
To create a pool
click Pools.
The Pools screen opens.
2. To create a new pool, click Create.
The New Pool screen opens.
user role does not grant you permission to create a pool.
3. Type a pool name and add the member addresses for each of the
servers.
4. Click Finished.
Creating a virtual server

After you create a server pool, you need to create a virtual server that
references the custom Fast L4 profile and pool you created in the previous
two tasks.
To create a standard virtual server

click Virtual Servers.
The Virtual Servers screen opens.
2. To create a new virtual server, click Create.
The New Virtual Server screen opens.
user role does not grant you permission to create a virtual server.
3. Type the virtual server name, select a destination type, and type the
IP address.
4. For the Type setting, select Performance (Layer 4).
5. Set the following attributes:
a) For Protocol, select either UDP, TCP, or *All Protocols from
the list.
b) For Protocol Profile (Client), select the name of the custom Fast
L4 profile that you created.
c) Clear the Address Translation check box to disable address
translation.
2-4
d) Clear the Port Translation check box to disable port translation.

e) In the Resources section, choose the pool you created that
contains the content servers.
6. Click Finished.
Configuring the virtual server on the content server loopback

interface
You must place the IP address of the virtual server (176.16.1.1 in Figure 2.1
on page 2-1) on the loopback interface of each server. Most UNIX variants
have a loopback interface named lo0. Microsoft® Windows® has an MS
Loopback interface in its list of network adaptors. For some versions of
Windows, you must install the loopback interface using the installation CD.
Consult your server operating system documentation for information about
configuring an IP address on the loopback interface. The loopback interface
is ideal for the nPath configuration because it does not participate in the
ARP protocol.
Setting the route for inbound traffic

For inbound traffic, you must define a route through the BIG-IP system self
IP address to the virtual server. In the example, this route is 176.16.1.1, with
the external self IP address 10.1.1.10 as the gateway.
Note
You need to set this route only if the virtual server is on a different subnet
than the router.
For information about how to define this route, please refer to the
documentation provided with your router.
Enabling the connection.autolasthop bigdb key

To ensure that npath routing works correctly, you must ensure that the bigdb
configuration key connection.autolasthop is set to enable. This is relevant
for both IPv4 and IPv6 addressing formats.
To ensure that this bigdb key is enabled, type this command:
bigpipe db connection.autolasthop enable

Chapter 2
Setting timers for nPath configurations

When you create an nPath configuration, the BIG-IP® system sees only
client requests. Therefore, the timer for the connection timeout is only reset
when clients transmit. In general, this means the timeout for an nPath
connection should be at least twice as long as for a comparable connection
where BIG-IP system sees both client requests and node responses.
Following are descriptions of scenarios for setting the timers for UDP and
TCP traffic.
Guidelines for configuring timeouts for UDP traffic

When you configure nPath for UDP traffic, the BIG-IP system tracks
packets sent between the same source and destination address to the same
destination port as a connection. This is necessary to ensure that client
requests that are part of a session always go to the same server. Therefore, a
UDP connection is really a form of persistence, since UDP is a
connectionless protocol. To calculate the timeout for UDP, estimate the
maximum amount of time that a server transmits UDP packets before a
packet is sent by the client. In some cases, the server might transmit
hundreds of packets over several minutes before ending the session or
waiting for a client response.
Guidelines for configuring timeouts for TCP traffic

When you configure nPath for TCP traffic, the BIG-IP system sees only the
client side of the connection. For example, in the TCP three-way handshake,
the BIG-IP system sees the SYN from the client to the server, and does not
see the SYN acknowledgement from the server to the client, and does see
the acknowledgement of the acknowledgement from the client to the server.
The timeout for the connection should match the combined TCP
retransmission timeout (RTO) of the client and the node as closely as
possible to ensure that all connections are successful. The maximum initial
RTO observed on most UNIX and Windows systems is approximately 25
seconds. Therefore, a timeout of 51 seconds should adequately cover the
worst case. Once a TCP session is established, an adaptive timeout is used.
In most cases, this results in a faster timeout on the client and node. Only if
your clients are on slow, lossy networks should you ever need a higher TCP
timeout for established connections.
2-6
3
Basic Web Site and E-Commerce
Configuration
• Working with a basic web site and e-commerce

configuration
• Configuring a basic e-commerce site

Working with a basic web site and e-commerce

configuration
The most common use for the BIG-IP® system is distributing traffic across
an array of web servers that host standard web traffic, including e-commerce
traffic. Figure 3.1 shows a configuration where a BIG-IP system load
balances two sites: www.siterequest.com and store.siterequest.com. The
www.siterequest.com site provides standard web content, and the
store.siterequest.com site is the e-commerce site that sells items to
www.siterequest.com customers.
Figure 3.1 A basic load balancing configuration
To set up load balancing for these sites, you need to create two pools that are
referenced by two virtual servers, one for each site. Even though the sites
are related and they may even share the same IP address, each requires its
own virtual server because it uses a different port to support its particular
protocol: port 80 for the HTTP traffic going to www.siterequest.com, and
port 443 for the SSL traffic going to store.siterequest.com. Note that this is
true even when there is a port 80 and port 443 on the same physical server,
as in the case of Server2.
Note
All examples in this document use only private class IP addresses. When you
set up the configurations we describe, you must use valid IP addresses
suitable to your own network in place of our sample addresses.

Chapter 3
Configuring a basic e-commerce site

To configure the e-commerce site, you need to complete the following tasks
in order:
• Create the load balancing pools.
Create a pool to load balance HTTP connections, and a pool to load
balance SSL connections.
• Create virtual servers for the inbound traffic.
Create the virtual servers that reference the HTTP and SSL pools.
Creating load balancing pools

The first task in a basic configuration is to define the two load balancing
pools: a pool to load balance HTTP connections, and a pool to load balance
SSL connections. As shown in Figure 3.1, on page 3-1, the two servers for
the HTTP pool are 192.168.100.1:80 and 192.168.100.2:80 (Server1 and
Server 2). The two servers for the SSL pool are 192.168.100.2:443 and
192.168.100.3:443 (Server2 and Server 3).
Use the Configuration utility to create these two pools. For additional
information about configuring a pool, see the online help.
To create a pool for load balancing HTTP traffic

click Pools.
2. In the upper-right corner of the screen, click Create.
3. In the Name box, type a name for the pool.
In the example in Figure 3.1, on page 3-1, this pool name is
http_pool.
4. In the Resources area of the screen, use the New Members setting
to add the pool members.
In the example in Figure 3.1, on page 3-1, these pool members are
192.168.100.1:80 and 192.168.100.2:80.
5. Click Finished.
3-2
To create a pool for load balancing SSL traffic

click Pools.
In the example in Figure 3.1, on page 3-1, this pool name is
ssl_pool.
In the example in Figure 3.1, on page 3-1, these pool members are
192.168.100.2:443 and 192.168.100.3:443.
5. Click Finished.
Creating virtual servers

The next task in a basic configuration is to define the virtual servers that
reference the HTTP and SSL pools, respectively. You use the Configuration
utility to create these virtual servers. For additional information about
configuring a virtual server, click the Help button.
To define a virtual server for HTTP traffic

1. On the Main tab of the navigation pane expand Local Traffic, and
3. In the Name box, type a name for the virtual server, such as
vs_http.
4. In the Destination box, verify that the type of virtual server is Host,
and in the Address box, type an IP address for the virtual server,
such as 192.168.200.10:80.
5. In the Service Port box, type 80, or select HTTP from the list.
6. In the Configuration area of the screen, locate the HTTP Profile
setting and select http.
7. In the Resources area of the screen, locate the Default Pool setting
and select http_pool.
8. Click Finished.

Chapter 3
To define a virtual server for SSL traffic

3. In the Name box, type a name for the virtual server, such as vs_ssl.
such as 192.168.200.10:443.
5. In the Service Port box, type 443, or select HTTPS from the list.
6. In the Configuration area of the screen, locate the
SSL Profile (Client) setting and select clientssl.
and select ssl_pool.
8. Click Finished.
3-4
4
Installing a BIG-IP System without Changing
the IP Network
• Installing a BIG-IP system without changing IP

networks
• Configuring the BIG-IP system for the same IP

network
Installing a BIG-IP system without changing IP

networks
A combination of several features of the BIG-IP® system allows you to
place a BIG-IP system in a network without changing the existing IP
network.
Figure 4.1 shows the data center topology before you add the BIG-IP
system. The data center has one LAN, with one IP network, 10.0.0.0. The
data center has one router to the Internet, two web servers, and a back-end
mail server.
Figure 4.1 Existing data center network structure
The existing data center structure does not support load balancing or high
availability. Figure 4.2, on page 4-2 is an example of the data center
topology after you add the BIG-IP system.

Chapter 4
Figure 4.2 New structure after adding the BIG-IP system
Both the internal and external interfaces of the BIG-IP system are on the
same IP network, 10.0.0.0, but they are effectively on different LANs.
Figure 4.2 introduces a second switch.
4-2
Configuring the BIG-IP system for the same IP

network
To configure the BIG-IP system for this implementation, you must create a
VLAN group, a pool of web servers, and a virtual server. More specifically,
you must complete these tasks:
◆ Remove the self IP addresses from the individual VLANs
Routing is handled by the self IP address you create for the VLAN group.
◆ Create a VLAN group
Create a VLAN group that includes the internal and external VLANs.
This enables Layer 2 forwarding. (Layer 2 forwarding causes the two
VLANs to behave as a single network.)
◆ Create a self IP for the VLAN group
The self IP for the VLAN group provides a route for packets destined for
the network.
◆ Create a pool of web servers
Create a pool that contains the web servers that you want to load balance.
◆ Create a virtual server
Create a virtual server that load balances the web servers.
Note
This example assumes that you are using the default internal and external
VLAN configuration with self IP addresses on each of the VLANs that are on
the same IP network on which you are installing the BIG-IP system.
Important
The default route on each content server should be set to the IP address of
the router. In this example, you set the default route to 10.0.0.2.
Removing the self IP addresses from the individual VLANs

Remove the self IP addresses from the individual VLANs. After you create
the VLAN group, you will create another self IP address for the VLAN
group for routing purposes. The individual VLANs no longer need their own
self IP addresses.
WARNING
We recommend that you perform this step from the console or from a self IP
address you are not going to delete. If you are connected from a remote
workstation through a self IP address that you are going to delete, you will
be disconnected when you delete it.

Chapter 4
To remove the self IP addresses from the default VLANs

1. On the Main tab of the navigation pane, expand Network, and click
Self IPs.
The Self IPs screen opens.
2. Using the IP Address and VLANs columns, locate the self IP
addresses for the VLANs internal and external.
3. To the left of each self IP address you want to delete, check the
Select box.
Note: If the Delete button is unavailable, this indicates that your
user role does not grant you permission to delete a self IP address.
4. Click Delete.
A confirmation screen appears.
5. Click Delete again.
Creating a VLAN group

Packets received by a VLAN in the VLAN group are copied onto the other
VLAN in the group. This allows traffic to pass through the BIG-IP system
on the same IP network.
To create a VLAN group

VLANs.
The VLANs screen opens.
2. From the VLAN Groups menu, choose List.
This opens the VLAN Groups screen.
This opens the New VLAN Group screen.
user role does not grant you permission to create a VLAN group.
4. In the Name box, type the name myvlangroup.
5. For the VLANs setting, from the Available box select the internal
and external VLAN names, and click the Move button (<<) to
move the VLAN names to the Members box.
6. Click Finished.
4-4
Creating a self IP address for the VLAN group

The self IP address for the VLAN group provides a route for packets
destined for the network. With the BIG-IP system, the path to an IP network
is a VLAN. However, with the VLAN group feature used in this example,
the path to the IP network 10.0.0.0 is actually through more than one
VLAN. Since IP routers are designed to have only one physical route to a
network, a routing conflict can occur. The self IP address feature on the
BIG-IP system allows you to resolve the routing conflict by putting a self IP
address on the VLAN group.
To create a self IP address for a VLAN group

Self IPs.
user role does not grant you permission to create a self IP address.
3. In the IP Address box, type a self IP address for the VLAN group.
In the example shown in Figure 4.2, on page 4-2, this IP address is
10.0.0.6.
4. In the Netmask box, type a netmask for the self IP address.
5. For the VLAN setting, select the name myvlangroup from the list.
6. Click Finished.
Creating a pool of web servers

After you create the network environment for the BIG-IP system, you can
create the pool of web servers you want to load balance.
To create a pool
click Pools.
3. In the Name box, type a name for the pool, such as myweb_pool.
In our example, pool members are 10.0.0.3:80 and 10.0.0.4:80.
5. Click Finished.

Chapter 4

After you create the pool of web servers you want to load balance, you can
create the virtual server.
To create a virtual server

1. On the Main tab, of the navigation pane, expand Local Traffic, and
vs_myweb.
and in the Address box, type an IP address.
Continuing with our example, this address would be 10.0.0.5.
5. From the Service Port list, select *All Ports.
and select the name of the pool you created using the previous
procedure.
In our example, this pool name is myweb_pool.
7. Click Finished.
4-6
5
• Introducing multiple customer hosting
• Hosting multiple customers using an external switch
• Directly hosting multiple customers

Introducing multiple customer hosting

You can use the BIG-IP® system to load balance and provide hosting
services for multiple customers.
In the example shown in Figure 5.1, the BIG-IP system has an interface
(5.1) assigned to three VLANs on a network. The three VLANs are vlanA,
vlanB, and vlanC. Interface 5.1 processes traffic for all three VLANs. Note
that each VLAN contains two servers, and serves a specific customer.
Figure 5.1 An example of multiple site hosting

Chapter 5
Hosting multiple customers using an external switch

To configure the BIG-IP system for this implementation, you must complete
the following tasks:
• Create VLANs with tagged interfaces.
For more information on tagged interfaces, see the TMOSTM
Management Guide for BIG-IP® Systems.
• Create load balancing pools.
Create three pools of web servers, one pool for each VLAN, to which
you want to load balance traffic.
• Create virtual servers.
Create three virtual servers that load balance traffic to the pools of web
servers.
Creating VLANs with tagged interfaces

The first task in configuring the BIG-IP system for multiple-customer
hosting is creating VLANs with tagged interfaces. In this procedure, you
assign the same interface to each VLAN that you create, and you assign the
interface as a tagged interface. (For more information on tagged interfaces,
see the TMOSTM Management Guide for BIG-IP® Systems.)
For example, in Figure 5.1, on page 5-1, there are three VLANs, where each
VLAN processes traffic for a different subnet. Thus, vlanA processes traffic
for the 10.1.1 subnet, vlanB, processes traffic for the 10.1.2 subnet, and
vlanC processes traffic for the 10.1.3 subnet. The interface assigned to all
three VLANs is 5.1.
To create a VLAN with a tagged interface

VLANs.
The VLAN screen opens.
This displays the settings to configure for the VLAN.
user role does not grant you permission to create a VLAN.
3. Type the VLAN name and tag number.
If you do not provide a tag number, the BIG-IP system
automatically generates a number. In Figure 5.1, on page 5-1, an
example of a VLAN name and tag number is vlanA, with a tag
number of 0001.
5-2
4. For the Interfaces setting, from the Available box select the name
of an interface on your internal network, and click the Move button
(<<) to move the interface name to the Tagged box.
This assigns the selected interface to the VLAN, as a tagged
interface. In our example, the interface is 5.1.
5. Click Finished.
Creating load balancing pools

After you create the VLANs for the BIG-IP system, create three load
balancing pools, one for each VLAN. In Figure 5.1, on page 5-1, each pool
has two pool members.
To create a pool
click Pools.
3. In the Name box, type a name for the pool, such as
customerA_pool.
For example, in Figure 5.1, on page 5-1, the pool members for
vlanA are 10.1.1.1:80 and 10.1.1.2:80. The pool members for
vlanB are 10.1.2.1:80 and 10.1.2.2:80, and the pool members for
vlanC are 10.1.3.1:80 and 10.1.3.2:80.
5. Click Finished.

After you create the web server pools that you want to load balance, create a
virtual server for each pool.


Chapter 5
vs_customerA.
such as 10.1.10.10:80.
and select the pool corresponding to the virtual server you are
creating.
For example, for vs_customerA, you would select the pool
customerA_pool. For vs_customerB, you would select the pool
customerB_pool, and so on.
8. Click Finished.
5-4
Directly hosting multiple customers

The configuration shown in Figure 5.1, on page 5-1, uses an external switch
between the BIG-IP system and the server nodes. However, another way to
implement this solution is to remove the external switch, and instead use
multiple interfaces on the BIG-IP system to directly host traffic for multiple
customers. With this scenario, it is still necessary to configure the VLANs,
but you must configure them with untagged instead of tagged interfaces.
Figure 5.2 shows an example of this scenario.
Figure 5.2 Multiple customer hosting using VLAN switching
In Figure 5.2, two BIG-IP system interfaces are assigned to each VLAN. For
example, interfaces 1.1 and 1.2 are assigned to the vlanA VLAN. Each
interface is assigned to a VLAN as an untagged interface.
The first scenario, shown in Figure 5.1, on page 5-1, requires an additional
switch, but requires the use of only one interface on the internal network.
The second scenario, shown in Figure 5.2, removes the need for an
additional switch, but requires the use of multiple BIG-IP system interfaces.

Chapter 5
Creating VLANs with untagged interfaces

The first task in configuring the BIG-IP system for directly hosting multiple
customers is to create VLANs, adding untagged interfaces to them. (For
more information on tagged interfaces, see the TMOSTM Management
Guide for BIG-IP® Systems.)
To create VLANs with untagged interfaces

VLANs.
This displays the settings to configure for the VLAN.
user role does not grant you permission to create a VLAN.
3. Enter the VLAN name and tag number.
If you do not provide a tag number, the BIG-IP system
automatically generates a number. In Figure 5.2, on page 5-5, an
example of a VLAN name and tag number is vlanA, with a tag
number of 0001.
4. For the Interfaces setting, from the Available box select the name
of an interface on your internal network, and click the Move button
(>>) to move the interface name to the Untagged box.
This assigns the selected interface to the VLAN, as an untagged
interface. In Figure 5.2, on page 5-5, vlanA as interfaces 1.1 and 1.2
assigned to it. vlanB has interfaces 1.3 and 1.4 assigned to it, and
vlanC has interfaces 1.5 and 1.6 assigned to it.
5. Click Finished.
Once you have created your VLANs and assigned untagged interfaces to
them, you can create the pools and virtual servers, just as you did in the
section Hosting multiple customers using an external switch, on page 5-2.
5-6
6
• Working with a simple intranet configuration
• Creating the simple intranet configuration

Working with a simple intranet configuration

The simple intranet implementation described in this chapter is commonly
found in a corporate intranet (see Figure 6.1). In this implementation, the
BIG-IP® system performs load balancing for several different types of
connection requests:
◆ HTTP connections to the company’s intranet web site. The BIG-IP
system load balances the two web servers that host the corporate intranet
web site, Corporate.main.net.
◆ HTTP connections to Internet content. These are handled through a pair
of cache servers that are also load balanced by the BIG-IP system.
◆ Non-HTTP connections to the Internet.
Figure 6.1 A simple intranet configuration

Chapter 6
As Figure 6.1, on page 6-1 shows, the non-intranet connections are handled
by wildcard virtual servers, that is, servers with the IP address 0.0.0.0. The
wildcard virtual server that is handling traffic to the cache servers is port
specific, specifying port 80 for HTTP requests. This way all HTTP requests
not matching an IP address on the intranet are directed to the cache server.
The wildcard virtual server handling non-HTTP requests is a default
wildcard server. A default wildcard virtual server is one that uses only port
0. This makes it a catch-all match for outgoing traffic that does not match
any standard virtual server or any port-specific wildcard virtual server.
Creating the simple intranet configuration

To create this configuration, you need to complete the following tasks in
order:
• Create load balancing pools.
Create pools for the intranet servers you want to load balance, and one
for the cache server.
• Create virtual servers.
Create the virtual servers for each pool, and for the non-HTTP requests.
Creating pools
The first task in a basic configuration is to define the two load balancing
pools: a pool for the intranet content servers, and a pool for the Internet
cache servers.
To create pool
click Pools.
3. In the Name box, type a name for the pool, such as http_pool.
For example, in Figure 6.1, on page 6-1, the pool members for
http_pool are 192.168.100.10:80 and 192.168.100.11:80. The pool
members for specificport_pool are 192.168.100.20:80 and
192.168.100.21:80.
5. Click Finished.
6-2

The next task in a basic configuration is to create the virtual servers that
reference http_pool and specificport_pool, respectively. You must also
create a forwarding virtual server (with no pool) for remaining Internet
traffic.

vs_http, vs_specificport, or vs_non-http.
and in the Address box, type an IP address for the virtual server.
For example, you can assign the IP address 192.168.200.30:80 to
the virtual server that processes HTTP traffic. For load balancing
connections to cache servers, you can assign the address 0.0.0.0:80
to the virtual server, making it a wildcard virtual server. To create a
forwarding virtual server, you can assign the address 0.0.0.0:0.
6. In the Configuration area of the screen, locate the Type setting and
do the following:
a) Select Standard if the virtual server is to process HTTP traffic to
an intranet web site or to cache servers.
b) Select Forwarding (IP) if the virtual server is to forward
outgoing non-HTTP traffic.
7. If you are creating a virtual server to process HTTP connections to
an intranet web site, locate the HTTP Profile setting and select
http.
creating.
For example, for vs_http, you would select the pool http_pool.
Note: If you are creating a Forwarding (IP) virtual server, you do
not select a pool.
9. Click Finished.

Chapter 6
6-4
7
Load Balancing ISPs
• Introducing ISP load balancing
• Configuring ISP load balancing
• Configuring address translation for outbound traffic

Load Balancing ISPs
Introducing ISP load balancing

You may find that as your network grows, or network traffic increases, you
need to add an additional connection to the internet. You can use this
configuration to add an additional Internet connection to your existing
network. Figure 7.1 shows a network configured with two Internet
connections.
Figure 7.1 An example of an additional internet connection
This type of configuration requires you to configure network address

translation (NAT) on your routers. If your routers cannot perform NAT, you
can use the VLAN SNAT automap feature on the BIG-IP® system.

Chapter 7
Configuring ISP load balancing

When you set up ISP load balancing, you have several tasks to complete on
the BIG-IP system:
◆ Create two load balancing pools
Define one pool that load balances the content servers. Define another
pool that load balances the inside addresses of the routers.
◆ Configure virtual servers for inbound and outbound traffic
Configure virtual servers to load balance inbound connections across the
servers, and one to load balance outbound connections across the routers.
◆ Configure NATs or a SNAT automap for outbound traffic
Configure NATs or SNAT automap for outbound traffic so that replies
arrive though the same ISP the request went out on.
Creating pools for an additional Internet connection

First, create one pool that load balances the content servers, and one pool to
load balance the routers.
To create a pool
click Pools.
3. In the Name box, type a name for the pool, such as content_pool or
router_pool.
For example, in Figure 7.1, on page 7-1, the pool members for pool
content_pool are 10.1.1.1:80, 10.1.1.2:80, and 10.1.1.3:80. The
pool members for pool router_pool are 192.168.100.1:0 and
192.168.200.1:0.
5. Click Finished.
7-2
Load Balancing ISPs
Creating virtual servers for an additional Internet connection

After you create the pools, you can configure the two virtual servers, one to
load balance inbound connections to the servers, and one to load balance
outbound connections to the routers.
To create a virtual server for inbound content server traffic

vs_content.
For example, you could assign the IP address 172.100.12.20:80.
5. For the Service Port setting, type a port number, or select a service
from the list.
6. If the traffic to be load balanced is of a certain type, select the
profile type that matches the connection type.
For example, if the traffic to be load balanced is HTTP traffic,
locate the HTTP Profile setting and select http.
creating.
For example, for vs_content, you would select the pool
content_pool.
8. Click Finished.
To create a virtual server for outbound traffic for routers

vs_routers.

Chapter 7
For example, you can assign the IP address 0.0.0.0:0 to the virtual
server, making it a wildcard virtual server.
creating.
For example, for vs_routers, you would select the pool
router_pool.
6. Click Finished.
7-4
Load Balancing ISPs
Configuring address translation for outbound traffic

You must now set up address translation for outbound traffic so that replies
arrive through the same ISP that the request initially came through.
Specifically, you must either configure your routers so that they perform
network address translation (NAT), or you must configure SNAT
automapping on the BIG-IP system. You must also assign self IP addresses
to the external VLAN.
Note
For instructions on configuring routers to perform network address

translation, see the vendor documentation that pertains to your router.
To configure address translation for outbound traffic, you must:

• Assign IP-specific self IP addresses to the BIG-IP system external
VLAN, corresponding to the IP networks of the two routers.
• Enable SNAT automap for each of the external VLAN self IP addresses
and the internal VLAN.
To create self IP addresses for the external VLAN

Self IPs.
The Self IP screen opens.
This displays the settings that you can configure for a self IP
address.
3. In the IP Address box, type a self IP address that matches the
network of the router.
Note: Verify that the inside IP network address of the router is
enabled.
4. From the VLAN list, select external.
5. Click Repeat.
6. Create another self IP address for the external VLAN.
7. Click Finished.
To enable SNAT automap for internal and external VLANs

click SNATs.
The SNATs screen opens.
2. In the upper-right corner, click Create.
The New SNAT screen opens.

Chapter 7

user role does not grant you permission to create a SNAT.
3. In the Name box, type a unique name for the SNAT.
4. From the Translation list, select Automap.
5. From the VLAN Traffic list, select Enabled On.
This displays the VLAN List setting.
6. For the VLAN List setting, from the Available box select the
internal and external VLAN names, and click the Move button
(<<) to move the VLAN names to the Selected box.
7. Click Finished.
7-6
8
Load Balancing HTTP Traffic with Source
Address Affinity Persistence
• Introducing basic HTTP load balancing
• Configuring HTTP load balancing with source

address affinity persistence
Introducing basic HTTP load balancing

Many computing environments want to use a BIG-IP® system to
intelligently manage their HTTP traffic. You can easily control your HTTP
traffic by implementing a BIG-IP system feature known as an HTTP profile.
An HTTP profile is a group of settings that affect the behavior of HTTP
traffic. An HTTP profile defines the way that you want the BIG-IP system to
manage HTTP traffic.
You can use the default HTTP profile, with all of its default values, or you
can create a custom HTTP profile. When you create a custom HTTP profile,
you not only modify the setting values, but you can enable more advanced
features such as data compression of server responses.
When you configure the BIG-IP system to manage HTTP traffic, you can
also implement simple session persistence, also known as source address
affinity persistence. Source address affinity persistence directs session
requests to the same server based solely on the source IP address of a
packet. To implement source address affinity persistence, the BIG-IP system
offers a default persistence profile that you can implement. Just as for
HTTP, you can use the default profile, or you can create a custom simple
persistence profile.
The remainder of this chapter describes how to set up a basic HTTP load
balancing scenario and source address affinity persistence, using the default
HTTP and persistence profiles. For detailed information on managing HTTP
traffic and setting up source address affinity persistence, see the

Chapter 8
Configuring HTTP load balancing with source

address affinity persistence
To set up basic HTTP load balancing with persistence that is based on
source IP addresses, you need to complete the following tasks:
• Create a load balancing pool.
Create a pool to load balance HTTP connections.
• Create a virtual server.
Create a virtual server to process the HTTP traffic and send it to the pool.
Because this implementation configures HTTP load balancing and
session persistence using the default HTTP and source address affinity
profiles, you do not need to specifically configure these profiles. Instead,
you simply configure some settings on the virtual server when you create
it.
Creating a pool
The first task in a basic configuration is to create a load balancing pool to
load balance HTTP connections. Use the Configuration utility to create this
pool.

click Pools.
4. For the Health Monitors setting, from the Available box select
http, and click the Move button (<<) to move the monitor name to
the Active box.
5. For the New Members setting, add the pool members:
a) Click the New Address option.
b) In the Address box, type the IP address of a server in the pool.
c) In the Service Port box, type 80, or select HTTP.
d) Click Add.
e) Repeat steps b, c, and d for each server in the pool.
6. Click Finished.
8-2

The next task in a basic configuration is to define a virtual server that
references the HTTP pool. You use the Configuration utility to create the
virtual server.
To create a virtual server for HTTP traffic

vs_http.
This assigns the default HTTP profile to the virtual server.
and select the name of the HTTP pool you created in the previous
section (for example, http_pool).
8. From the Default Persistence Profile setting, select source_addr.
This implements simple persistence, using the default source
address affinity profile.
9. Click Finished.

Chapter 8
8-4
9
Load Balancing HTTP Traffic with Cookie
Persistence
• Introducing basic HTTP load balancing
• Configuring HTTP load balancing with cookie

persistence
Introducing basic HTTP load balancing

Many computing environments want to use a BIG-IP® system to
intelligently manage their HTTP traffic. You can easily control your HTTP
traffic by implementing a BIG-IP system feature known as an HTTP profile.
An HTTP profile is a group of settings that affects the behavior of HTTP
traffic. An HTTP profile defines the way that you want the system to
manage HTTP traffic.
You can use the default HTTP profile, with all of its default values, or you
can create a custom HTTP profile. When you create a custom HTTP profile,
you not only modify the setting values, but you can enable more advanced
features such as data compression of server responses.
When you configure the BIG-IP system to manage HTTP traffic, you can
also implement cookie-based session persistence. Cookie persistence directs
session requests to the same server based on HTTP cookies that the BIG-IP
system stores in the client’s browser. To implement cookie persistence, the
BIG-IP system offers a default persistence profile that you can implement,
or you can create a custom cookie persistence profile.
This chapter describes how to set up a basic HTTP load balancing scenario
and cookie persistence, using the default HTTP profile and a custom cookie
persistence profile. For detailed information on managing HTTP traffic and
setting up cookie persistence, see the Configuration Guide for BIG-IP®
Local Traffic Management.

Chapter 9
Configuring HTTP load balancing with cookie

persistence
To set up basic HTTP load balancing with persistence that is based on
cookies, you need to:
• Create a custom cookie persistence profile.
• Create a load balancing pool.
• Create a virtual server to process the HTTP traffic and send it to the pool.
Because this implementation configures HTTP load balancing using the

existing default HTTP profile, you do not need to specifically configure a
profile for managing HTTP traffic. The only profile you need to configure is
the custom cookie persistence profile.
Creating a custom persistence profile

A good way to implement cookie persistence is to create a custom cookie
To create a custom cookie persistence profile

click Profiles.
2. On the menu bar, click Persistence.
This displays the list of default persistence profiles.
The New Persistence Profile screen opens.
user role does not grant you permission to create a profile.
4. In the Name box, type a name for the profile, such as
mycookie_profile.
5. From the Persistence Type list, select Cookie.
6. From the Parent Profile list, select cookie.
7. To the far right of the Cookie Method setting, check the Custom
select box.
8. From the Cookie Method list, select HTTP Cookie Insert.
9. Leave the Cookie Name setting disabled.
10. In the Expiration setting, clear the Session Cookie check box.
Additional settings appear.
11. In the Minutes box, type 60.
12. Click Finished.
9-2
Creating a pool
The next task is to create a load balancing pool to which to load balance
HTTP connections.

click Pools.
4. From the Health Monitors list, from the Available box select http,
and click the Move button (<<) to move the monitor name to the
Active box.
d) Click Add.
6. Click Finished.

references the HTTP pool.
To create a virtual server for HTTP traffic

vs_http.

Chapter 9
4. In the Destination box:

a) Verify that the type of virtual server is Host
b) In the Address box, type an IP address for the virtual server.
6. In the Configuration area of the screen, retain the value of the
Protocol setting, TCP.
7. From the HTTP Profile list, select http.
and select the name of the HTTP pool you created in the previous
section (for example, http_pool).
9. From the Default Persistence Profile list, select the name of the
custom cookie profile you created earlier, such as
mycookie_profile.
This implements cookie persistence, using the custom cookie
profile.
10. Click Finished.
Note
You can also use HTTP Cookie Insert persistence wtih a Performance
(HTTP) type of virtual server.
9-4
10
• Introducing HTTP data compression
• Creating a custom HTTP profile
• Creating a virtual server

Introducing HTTP data compression

An optional feature of the BIG-IP® system is the system’s ability to off-load
HTTP compression tasks from the target server. All of the tasks that you
need to configure HTTP compression, as well as the compression software
itself, are centralized on the BIG-IP system.
The primary way to enable the HTTP compression option is by setting the
Compression setting of an HTTP profile to Enabled. This causes the
system to compress HTTP content for any responses matching the values
that you specify in the Request-URI or Content-Type settings of the HTTP
profile.
Tip
If you want to enable HTTP compression for specific connections, you can
write an iRule that specifies the HTTP:compress enable command.
Using the BIG-IP system HTTP compression feature, you can include or
exclude certain types of URIs or files that you specify. This is useful
because some URI or file types might already be compressed. F5 does not
recommend using CPU resources to compress already-compressed data
because the cost of compressing the data usually outweighs the benefits.
Examples of regular expressions that you might want to specify for
exclusion are .*\.pdf, .*\.gif, or .*\.html.
To configure HTTP data compression, you need to:
• Create a custom HTTP profile.
• Create a virtual server to process compressed HTTP responses.
For more detailed, background information on configuring compression and

virtual servers, see the Configuration Guide for BIG-IP® Local Traffic
Management.
BIG-IP® Local Traffic Manager: Implementations 10 - 1

Chapter 10
Creating a custom HTTP profile

The first task in configuring HTTP data compression on the BIG-IP system
is to create a custom HTTP profile. An HTTP profile defines the way that
you want the BIG-IP system to manage HTTP traffic.
After you create the custom HTTP profile, you create a virtual server and
assign the custom profile to that virtual server.
To create a custom HTTP profile

click Profiles.
This displays a list of any existing HTTP profiles, including the
default profile http.
The New HTTP Profile screen opens.
3. In the Name box, type a name for the custom profile, such as
http_compress.
4. Ensure that the Parent Profile setting is set to http.
5. In the Settings area of the screen, retain all default values.
6. In the Compression area, for the Compression setting, on the far
right side of the screen, check the Custom box and select Enabled
from the list.
7. If you want to base compression on URIs specified in the HTTP
request headers:
a) Locate the URI Compression setting, check the Select box on
the far right of the screen, and select URI List from the list.
This displays the URI List settings.
b) Specify any regular expressions that you want to include or
exclude from compression.
Examples of regular expressions are .*\.pdf, .*\.gif, or .*\.html.
8. If you want to base compression on the type of response content:
a) Locate the Content Compression setting, check the Select box
on the far right of the screen, and select Content List from the
list.
This displays the Content List settings.
b) Specify values for content you want to include or exclude from
compression.
Examples of content types that you can specify are
application/pdf and image/**.
10 - 2
9. For all other settings in the Compression area of the screen, retain
the default values, or configure them to suite your needs.
10. Click Finished.

The next task in configuring HTTP compression is to define a virtual server
that references the custom HTTP profile that you created in the previous
task.
To create a virtual server for HTTP compression

vs_http_compress.
7. From the HTTP Profile list, select the custom HTTP profile that
you created in the previous section. In our example, this value
would be http_compress.
This assigns the custom HTTP profile to the virtual server.
and select a pool name.
9. From the Default Persistence Profile list, select source_addr.
This implements the default profile for source address affinity
persistence.
10. Click Finished.
After you have created a custom HTTP profile and a virtual server, you can
test the configuration by attempting to pass HTTP traffic through the virtual
server. Check to see that the BIG-IP system includes and excludes the
responses that you specified in the custom profile, and that the system
compresses the data as specified.

Chapter 10
10 - 4
11
• Introducing HTTPS load balancing
• Creating an SSL key and certificate
• Creating a custom SSL profile
• Creating a pool

Introducing HTTPS load balancing

When you want to load balance HTTPS traffic, you can configure the
BIG-IP® system to perform the SSL handshake that target web servers
normally perform. There are two types of SSL processing that you can
configure. You can configure either type, or both. They are:
◆ Client-side SSL
A common way to configure the BIG-IP system is to enable client-side
SSL. This enables the system to decrypt client requests before sending
them on to a server, and encrypt server responses before sending them
back to the client. In this case, you need to install only one key/certificate
pair on the system.
◆ Server-side SSL
Another way to configure the BIG-IP system is to enable server-side
SSL. This enables the system to encrypt requests that the BIG-IP system
sends to the target web server, and decrypt server responses before
sending them back to the client. In this case, you need to install a second
key/certificate pair on the system (in addition to the key/certificate pair
that you install for client-side SSL).
The first step in the configuration is to install the required key/certificate
pairs.
Then you can create a custom Client SSL profile, and optionally, a custom
Server SSL profile. Client SSL and Server SSL profiles are traffic profiles
that determine the way that the BIG-IP system processes client requests or
server responses that are sent by way of a fully SSL-encapsulated protocol
(in this case, HTTPS).
Next, you create a pool of servers for load balancing the HTTPS requests.
Finally, you must create a virtual server to process the HTTPS traffic,
according to the settings you configured in the custom Client SSL and
Server profiles.
For more detailed, background information on SSL certificates, SSL
profiles, load balancing pools, and virtual servers, see the Configuration
Guide for BIG-IP® Local Traffic Management.

Chapter 11
Creating an SSL key and certificate

Before you can load balance HTTPS traffic, you must create one or more
SSL keys and certificates to install onto the BIG-IP system. With SSL keys
and certificates, and a custom Client SSL and optional Server SSL profile
that you create, the BIG-IP system can perform the SSL handshaking
normally performed by a target web server.
For purposes of testing that you can pass HTTPS traffic successfully, you
can use a self-signed certificate, rather than one signed by a trusted
certificate authority.
To create a self-signed key/certificate pair

click SSL Certificates.
This displays a list of existing SSL certificates.
2. On the upper-right corner of the screen, click Create.
This opens the New SSL Certificate screen.
user role does not grant you permission to create SSL certificates.
3. In the Name box, type a name for the certificate, such as
my_clientside_cert or my_serverside_cert.
4. From the Issuer list, select Self.
5. In the Common Name box, type either the IP address for the virtual
server you will create later on, or a DNS name that resolves to the
virtual server’s IP address.
6. In the Division box, type your company name.
7. In the Organization box, type your department name.
8. In the Locality box, type your city name.
9. In the State or Province box, type your state or province name.
10. From the Country list, select the name of your country.
11. In the E-mail Address box, type your email address.
12. In the Challenge Password box, type a password.
13. In the Confirm Password box, re-type the password you typed in
the Challenge Password box.
14. In the Key Properties area of the screen, from the Size list, select
1024.
15. Click Finished.
11 - 2
Creating a custom SSL profile

The second task in configuring HTTPS load balancing on the BIG-IP system
is to create a custom SSL profile. For client-side SSL processing, you create
a custom Client SSL profile. For server-side SSL processing, you create a
custom Server SSL profile.
An SSL profile is a group of settings that enable the BIG-IP system to
perform decryption and encryption of SSL traffic. Some of the data you
specify in a custom SSL profile are the names of any key and certificate you
created in the previous task.
After you create a custom SSL profile, you create a load balancing pool, and
then create a virtual server, assigning the custom profile to that virtual
server.
To create a custom Client SSL profile

click Profiles.
2. From the SSL menu, choose Client.
This displays a list of any existing Client SSL profiles, including the
default profile clientssl.
The New Client SSL Profile screen opens.
my_clientssl_profile.
5. Ensure that the Parent Profile setting is set to clientssl.
6. For the Certificate setting, check the Custom box on the right side
of the screen.
7. From the Certificate list, select the name of the certificate you
created in the previous section.
Using our example, this name would be my_clientside_cert.crt.
8. For the Key setting, check the Custom box on the right side of the
screen.
9. From the Key list, select the name of the key you created in the
previous section.
Using our example, this name would be my_clientside_cert.key.
10. Click Finished.

Chapter 11
To create a custom Server SSL profile

click Profiles.
2. From the SSL menu, choose Server.
This displays a list of any existing Server SSL profiles, including
the default profile serverssl.
The New Server SSL Profile screen opens.
my_serverssl_profile.
5. Ensure that the Parent Profile setting is set to serverssl.
6. For the Certificate setting, check the Custom box on the right side
of the screen.
Using our example, this name would be my_serverside_cert.crt.
8. For the Key setting, check the Custom box on the right side of the
screen.
previous section.
Using our example, this name would be my_serverside_cert.key.
10. Click Finished.
11 - 4
Creating a pool
The next task in this process is to create a load balancing pool to load
balance HTTPS connections. After you create the pool, you assign it to a
virtual server that you create.
To create a pool for load balancing HTTPS traffic

click Pools.
the Active box.
d) Click Add.
6. Click Finished.

Chapter 11

The final task in configuring HTTPS load balancing is to define a virtual
server that references the custom Client SSL profile and the load balancing
pool that you created in previous tasks.
To create a virtual server for HTTPS

vs_clientssl.
7. From the Client SSL Profile list, select the name of the custom
Client SSL profile that you created previously. In our example, this
name is my_clientssl_profile.
This assigns the custom Client SSL profile to the virtual server.
8. If you created a custom Server SSL profile, then from the Server
SSL Profile list, select the name of that profile. In our example, this
name is my_serverssl_profile.
This assigns the custom Server SSL profile to the virtual server.
and select the pool name that you created in a previous section.
Using our example, this would be http_pool.
persistence.
11. Click Finished.
After you have created the required SSL key/certificate pairs, one or two
custom SSL profiles, a load balancing pool, and a virtual server, you can test
the configuration by attempting to pass HTTPS traffic through the virtual
server to the pool.
11 - 6
12
Configuring HTTPS Load Balancing with
Data Compression
• Introducing HTTPS load balancing with compression
• Creating an SSL key and certificate
• Creating a custom Client SSL profile
• Creating a custom HTTP profile for compression
• Creating a pool

Introducing HTTPS load balancing with compression

When you want to enable data compression of HTTPS traffic, and load
balance the traffic, you can configure the BIG-IP® system to perform the
SSL handshake that target web servers normally perform. A common way to
configure the BIG-IP system is to enable it to decrypt client requests before
sending them on to a server, and encrypt server responses before sending
them back to the client.
In general, the way to configure the BIG-IP system to perform SSL
handshaking (and thus process HTTPS traffic), is to first request and install
an SSL key and certificate onto the BIG-IP system. Using the key/certificate
pair, the BIG-IP system can act as a server to decrypt the client request
before sending it on to the server, and it can encrypt the server response
before sending it back to the client.
After installing the key/certificate pair, you can create a custom Client SSL
profile. A Client SSL profile is a type of traffic profile that determines the
way that the BIG-IP system processes client requests that are sent by way of
a fully SSL-encapsulated protocol (in this case, HTTPS requests).
Next, you create a custom HTTP profile and enable data compression on the
BIG-IP system. Then, you must create a pool of servers for load balancing
the HTTPS requests.
Finally, you must create a virtual server to process the HTTPS traffic,
according to the settings you configured in the custom Client SSL profile.
For more detailed, background information on SSL certificates, SSL
profiles, load balancing pools, and virtual servers, see the Configuration
Note
For information on configuring server-side SSL processing, see Chapter 11,

Configuring HTTPS Load Balancing.

Chapter 12
Creating an SSL key and certificate

Before you can load balance HTTPS traffic and enable compression, you
must create an SSL key and certificate to install onto the BIG-IP system.
With an SSL key and certificate, and the custom Client SSL profile that you
create next, the BIG-IP system can perform the SSL handshaking normally
performed by a target web server.
For purposes of testing that you can pass HTTPS traffic successfully, you
can use a self-signed certificate, rather than one signed by a trusted
certificate authority.
To create a self-signed key/certificate pair

click SSL Certificates.
This displays a list of existing SSL certificates.
This opens the New SSL Certificate screen.
user role does not grant you permission to create SSL certificates.
3. In the Name box, type a name for the certificate, such as my_cert.
4. From the Issuer list, select Self.
5. In the Common Name box, type either the IP address for the virtual
server you will create later on in this chapter, or a DNS name that
resolves to the virtual server’s IP address.
6. In the Division box, type your company name.
7. In the Organization box, type your department name.
8. In the Locality box, type your city name.
9. In the State or Province box, type your state or province name.
10. From the Country list, select the name of your country.
11. In the E-mail Address box, type your email address.
12. In the Challenge Password box, type a password.
13. In the Confirm Password box, re-type the password you typed in
the Challenge Password box.
14. In the Key Properties area of the screen, from the Size list, select
1024.
15. Click Finished.
12 - 2
Creating a custom Client SSL profile

The next task in configuring HTTPS load balancing with compression is to
create a custom Client SSL profile. A Client SSL profile is a group of
settings that enable the BIG-IP system to perform decryption and encryption
for client-side SSL traffic. Some of data you specify in the Client SSL
profile are the names of the key and certificate you created in the previous
section.
After you create the custom Client SSL profile, you create a load balancing
pool, and then create a virtual server, assigning the custom profile to that
virtual server.
To create a custom Client SSL profile

click Profiles.
2. From the SSL menu, choose Client SSL.
This displays a list of any existing Client SSL profiles, including the
default profile clientssl.
clientssl_profile.
5. Ensure that the Parent Profile setting is set to clientssl.
6. For the Certificate setting, check the Custom box on the far right
side of the screen.
Using our example, this name would be my_cert.crt.
8. For the Key setting, check the Custom box on the far right side of
the screen.
previous task.
Using our example, this name would be my_cert.key.
10. Click Finished.

Chapter 12
Creating a custom HTTP profile for compression

To enable HTTP data compression on the BIG-IP system, you must create a
custom HTTP profile. An HTTP profile defines the way that you want the
BIG-IP system to manage HTTP traffic.
After you create the custom HTTP profile, you create a load balancing pool.
Then you create a virtual server, assigning the custom HTTP profile to that
virtual server.
To create a custom HTTP profile for compression

click Profiles.
http_compress.
6. For the Compression setting, on the far right side of the screen,
check the Select box and select Enabled from the list.
7. If you want to base compression on URIs specified in the HTTP
request headers:
a) Locate the URI Compression setting, check the Select box on
the far right of the screen, and select URI List from the list.
This displays the URI List settings.
b) Specify any regular expressions that you want to include or
exclude from compression.
Examples of regular expressions are .*\.pdf, .*\.gif, or .*\.html.
8. If you want to base compression on the type of response content:
a) Locate the Content Compression setting, check the Select box
on the far right of the screen, and select Content List from the
list.
This displays the Content List settings.
12 - 4
b) Specify values for content you want to include or exclude from

compression.
Examples of content types that you can specify are
application/pdf and image/**.
9. For all other settings in the Compression area of the screen, retain
the default values, or configure them to suite your needs.
10. Click Finished.

Chapter 12
Creating a pool
The next task in the process is to create a load balancing pool to load
balance HTTPS connections. After you create the pool, you assign it to a
virtual server that you create.
To create a pool for load balancing HTTPS traffic

click Pools.
the Active box.
5. In the Resource area, for the New Members setting, add the pool
members:
d) Click Add.
6. Click Finished.
12 - 6

The final task in configuring HTTPS load balancing is to define a virtual
server that references the custom Client SSL profile and the load balancing
pool that you created in previous tasks.
To create a virtual server for HTTP compression

vs_clientssl.
7. From the HTTP Profile list, select the name of the HTTP profile
that you created.
Using our example, this value would be http_compress.
8. From the Client SSL Profile list, select the custom Client SSL
profile that you created in a previous section. In our example, this
value would be clientssl_profile
This assigns the custom Client SSL profile to the virtual server.
and select the pool name that you created in a previous section.
Using our example, this would be http_pool.
persistence.
11. Click Finished.
You can now test the configuration by attempting to pass HTTPS traffic
through the virtual server. Check to see that the BIG-IP system includes and
excludes the responses that you specified in the custom HTTP profile, and
that the system compresses the data as specified.

Chapter 12
12 - 8
13
• Introducing HTTP RAM Cache
• Creating a custom HTTP profile

Introducing HTTP RAM Cache

The BIG-IP® system includes a feature known as HTTP RAM Cache. A
RAM cache is a cache of HTTP objects stored in the BIG-IP system’s
random-access memory (RAM) that subsequent connections can reuse to
reduce the amount of load on the back-end servers.
When to use the RAM Cache

The RAM Cache feature provides the ability to reduce the traffic load to
back-end servers. This ability is useful if an object on a site is under high
demand, if the site has a large quantity of static content, or if the objects on
the site are compressed.
◆ High demand objects
This feature is useful if a site has periods of high demand for specific
content. With RAM Cache configured, the content server only has to
serve the content to the BIG-IP system once per expiration period.
◆ Static content
This feature is also useful if a site consists of a large quantity of static
content such as CSS, javascript, or images and logos.
◆ Content compression
For compressible data, the RAM Cache can store data for clients that can
accept compressed data. When used in conjunction with the compression
feature on the BIG-IP system, the RAM Cache takes stress off of the
BIG-IP system and the content servers.
The items you can cache

The RAM Cache feature is fully compliant with the cache specifications
described in RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1. This
means that you can configure RAM Cache to cache the following content
types:
• 200, 203, 206, 300, 301, and 410 responses
• Responses to GET methods by default
• Other HTTP methods for URIs specified in the URI Include list or
specified in an iRule
• Content based on the User-Agent and Accept-Encoding values. The
RAM Cache holds different content for Vary headers
To use the RAM Cache feature, you need to:

• Create a custom HTTP profile.
• Create a virtual server.
For more detailed, background information on configuring the RAM Cache

feature, see the Configuration Guide for BIG-IP® Local Traffic
Management.

Chapter 13
Creating a custom HTTP profile

The first task in configuring the HTTP RAM Cache feature on the BIG-IP
system is to create a custom HTTP profile. An HTTP profile defines the
way that you want the BIG-IP system to manage HTTP traffic.
After you create the custom HTTP profile, you create a virtual server and
assign the custom profile to that virtual server.
To create a custom HTTP profile

click Profiles.
http_ramcache.
6. Scroll down to the RAM Cache area of the screen.
7. For the RAM Cache setting, on the far right side of the screen,
check the Select box, and select Enabled from the RAM Cache list.
8. For all other settings in the RAM Cache area of the screen, retain
the default values, or configure them to suit your needs.
9. Click Finished.
13 - 2

The next task in configuring the RAM Cache feature is to define a virtual
server that references the custom HTTP profile that you created in the
previous task.
To create a virtual server for HTTP RAM Cache

vs_http_compress.
7. From the HTTP Profile list, select the custom HTTP profile that
you created in the previous section. In our example, this value
would be http_ramcache.
This assigns the custom HTTP profile to the virtual server.
and select a pool name.
persistence.
10. Click Finished.

Chapter 13
13 - 4
14
• Introducing FTP load balancing
• Creating a custom FTP monitor
• Creating a pool

Introducing FTP load balancing

You can set up the BIG-IP® system to load balance passive mode FTP
traffic. To do this, you perform the following tasks:
• Create a custom FTP health monitor.
• Create a pool for load balancing FTP traffic.
• Create a virtual server for processing FTP traffic.
When you create the virtual server, you can configure it to use the default
FTP profile. An FTP profile determines the way that the BIG-IP system
processes FTP traffic.
This chapter describes how to create the objects listed above, using the
default FTP profile. For more detailed information on managing FTP traffic,
see the Configuration Guide for BIG-IP® Local Traffic Management.

Chapter 14
Creating a custom FTP monitor

You can create a custom FTP monitor to monitor files on your FTP server.
To create a custom FTP monitor

click Monitors.
This displays a list of existing health and performance monitors.
This opens the New Monitor screen.
3. In the Name box, type a name for the custom monitor, such as
my_ftp_monitor.
4. From the Type list, select FTP.
This displays additional FTP monitor settings.
5. In the User Name box, type the logon name for the FTP server.
6. In the Password box, type the password for the logon name.
7. In the Path/Filename box, type the path and name for the file you
want to monitor.
8. Verify that the Mode setting is set to Passive.
9. For all other settings, retain the default values.
10. Click Finished.
After you have created a custom FTP monitor, you can create a load
balancing pool for your FTP traffic.
14 - 2
Creating a pool
To load balance passive mode FTP traffic, you create a load balancing pool.
When you create the pool, you assign the custom FTP monitor that you
After creating the pool, you assign it to the virtual server that you create.
To create a pool for load balancing FTP traffic

click Pools.
3. In the Name box, type a name for the pool, such as ftp_pool.
4. For the Health Monitors setting, from the Available box select the
name of the custom FTP monitor, such as my_ftp_monitor, and
click the Move button (<<) to move the monitor name to the Active
box.
5. Ensure that Priority Group Activation is set to Disabled.
c) From the Service Port list, select FTP.
d) Click Add.
7. Click Finished.

Chapter 14

references the FTP profile and the FTP pool.
To create a virtual server for FTP traffic

3. In the Name box, type a name for the virtual server, such as vs_ftp.
5. From the Service Port list, select FTP.
6. From the FTP Profile list, select ftp.
This assigns the default FTP profile to the virtual server.
and select the name of the FTP pool you created in the previous task
(for example, ftp_pool).
9. Click Finished.
14 - 4
15
with Rate Shaping
• Introducing FTP load balancing with rate shaping
• Creating a custom FTP monitor
• Creating a pool
• Creating a rate class

Introducing FTP load balancing with rate shaping

You can set up the BIG-IP® system to load balance passive mode FTP
traffic with rate shaping. To do this, you perform the following tasks:
• Create a custom FTP health monitor.
• Create a pool for load balancing FTP traffic.
• Create a rate class.
• Create a virtual server for processing FTP traffic.
When you create the virtual server, you can configure it to use the default
FTP profile. An FTP profile determines the way that the BIG-IP system
processes FTP traffic.
This chapter describes how to create the objects listed above, using the
default FTP profile. For more detailed information on managing FTP traffic,
see the Configuration Guide for BIG-IP® Local Traffic Management.
Note that the rate shaping feature is optional on the BIG-IP system.
Therefore, you must have purchased a license for the rate shaping feature
before you can use rate shaping to control the load balancing of passive FTP
traffic.

Chapter 15
Creating a custom FTP monitor

You can create a custom FTP monitor to monitor files on your FTP server.
To create a custom FTP monitor

click Monitors.
user role does not grant you permission to create a custom monitor.
3. In the Name box, type a name for the custom monitor, such as
my_ftp_monitor.
4. From the Type list, select FTP.
This displays additional FTP monitor settings.
5. In the User Name box, type the logon name for the FTP server.
6. In the Password box, type the password for the logon name.
7. In the Path/Filename box, type the path and name for the file you
want to monitor.
8. Verify that the Mode setting is set to Passive.
10. Click Finished.
After you create the custom FTP monitor, you can create a load balancing
pool for your FTP traffic.
15 - 2
Creating a pool
To load balance passive mode FTP traffic, you create a load balancing pool.
When you create the pool, you assign the custom FTP monitor that you
To create a pool for load balancing FTP traffic with rate

shaping
click Pools.
3. In the Name box, type a name for the pool, such as ftp_pool.
name of the custom FTP monitor, such as my_ftp_monitor, and
click the Move button (<<) to move the monitor name to the Active
box.
5. Ensure that the Priority Group Activation setting is set to
Disabled.
d) Click Add.
7. Click Finished.
After you create the pool, you assign it to the virtual server that you create in
the next task.

Chapter 15
Creating a rate class

To implement rate shaping, you create a rate class. By creating a rate class,
you can load balance passive mode FTP traffic that is controlled by rate
shaping.
Note
Rate shaping is an optional feature of the BIG-IP system. Before attempting

to implement rate shaping, verify that you are licensed to use the feature.
To create a rate class

click Rate Shaping.
The Rate Shaping screen opens.
The New Rate Class screen opens.
user role does not grant you permission to create a rate class.
3. In the Name box, type a name for the rate class, such as
ftp_rateclass.
4. In the Base Rate box, type 1 and select Mbps from the list.
5. In the Ceiling Rate box, type 10 and select Mbps from the list.
6. In the Burst Rate box, type 10000.
8. Click Finished.
15 - 4

references the FTP profile and the FTP pool.
To create a virtual server for FTP traffic with rate shaping

3. In the Name box, type a name for the virtual server, such as vs_ftp.
5. From the Service Port list, select FTP.
6. From the FTP Profile list, select ftp.
This assigns the default FTP profile to the virtual server.
7. From the Rate Class list, select the name of the rate class you
created in the previous section (for example, ftp_rateclass).
and select the name of the FTP pool you created in the previous
section (for example, ftp_pool).
10. Click Finished.

Chapter 15
15 - 6
16
• Introducing the one-IP network topology
• Creating a pool for a one-IP network topology
• Defining a default route
• Configuring a client SNAT

Introducing the one-IP network topology

Another configuration option you can use with the BIG-IP® system is a
one-IP network topology. This differs from the typical two-network
configuration in two ways:
• Because there is only one physical network, this configuration does not
require more than one interface on the BIG-IP system.
• Clients need to be assigned SNATs to allow them to make connections to
servers on the network in a load balancing pool.
The single interface configuration is shown in Figure 16.1.
Figure 16.1 An example of a single interface topology
To set up this configuration, you need to complete the following tasks on the
BIG-IP system:
• Create a load balancing pool for the content servers.
• Create a virtual server to load balance traffic to the content server pool.
• Define a default route for the external VLAN.
• Configure a SNAT for the client.

Chapter 16
Creating a pool for a one-IP network topology

The first task required to set up this implementation is to create a pool that
contains the content servers that you want to load balance. Before creating
the pool, verify that all content servers for the pool are in the network of
VLAN external.
To create a pool
click Pools.
3. From the Configuration list, select Advanced.
4. In the Name box, type a name for the pool, such as server_pool.
the Active box.
6. For the Allow SNAT setting, verify that the value is Yes.
7. For the remaining settings in the Configuration area of the screen,
retain the default values.
8. In the Resources area of the screen, use the default values for the
Load Balancing Method and Priority Group Activation settings.
d) Click Add.
10. Click Finished.
16 - 2

The second task required to set up this implementation is to create a virtual
server that references the pool of servers that you want to load balance. The
pool that the virtual server references is the pool you created in the previous
task.

vs_one_ip.
4. For the Destination setting:
a) Verify that the type of virtual server is Host
b) In the Address box, type an IP address for the virtual server.
7. From the HTTP Profile list, select http.
and select the name of the pool you created in the previous section
(using our example, this would be server_pool).
9. Click Finished.

Chapter 16
Defining a default route

Another task that you must perform to implement one-IP network load
balancing is to define a default route for the VLAN external.
To define a default route

1. On the Main tab of the navigation pane, expand Network and click
Routes
The Routes screen opens.
2. In the upper-right corner of the screen, click Add.
The New Route screen opens.
Note: If the Add button is unavailable, this indicates that your user
role does not grant you permission to add a route.
3. For the Type setting, verify that it is set to Default Gateway.
This disables the Destination and Netmask settings.
4. For the Resource setting:
a) From the list on the left, select Use VLAN.
b) From the list on the right, select external.
5. Click Finished.
Note
If you are defining a default route for a route domain other than route
domain 0 (the default route domain), the procedure varies slightly. For
more information, see the TMOSTM Management Guide for BIG-IP®
Systems.
16 - 4
Configuring a client SNAT

Finally, configure the BIG-IP system to handle connections originating from
the client. You must define a SNAT in order to change the source address on
the packet to the SNAT external address, which is located on the BIG-IP
system. Otherwise, if the source address of the returning packet is the IP
address of the content server, the client does not recognize the packet
because the client sent its packets to the IP address of the virtual server, not
the content server.
If you do not define a SNAT, the server returns the packets directly to the
client without giving the BIG-IP system the opportunity to translate the
source address from the server address back to the virtual server. If this
happens, the client might reject the packet as unrecognizable.
To configure a client SNAT

click SNATs.
3. In the Name box, type a name for the SNAT, such as snat_one_ip.
4. In the Translation box, type an IP address that you want to use as a
translation IP address.
5. From the Origin list, select Address List.
This displays additional configuration settings.
6. For the Address List setting:
a) For the Type setting, verify that Host is enabled.
b) In the Address box, type a client IP address.
c) Click Add.
d) Repeat this process for each client to which you want to assign
the translation address.
7. From the VLAN Traffic list, select Enabled on.
8. For the VLAN List setting, from the Available box select external,
and click the Move button (<<) to move the VLAN name to the
Active box.
9. Click Finished.

Chapter 16
16 - 6
17
• Introducing link aggregation with tagged VLAN

interfaces
• Using the two-network aggregated tagged interface

topology
• Using the one-network aggregated tagged interface

topology
Introducing link aggregation with tagged VLAN

interfaces
You can use the BIG-IP® system in an aggregated two-interface load
balancing topology. Link aggregation is the process of combining multiple
links so that the links function as a single link with higher bandwidth. Link
aggregation occurs when you create a trunk. A trunk is a combination of
two or more interfaces and cables configured as one link.
The examples in this chapter show a trunk that includes two tagged
interfaces aggregated together. A tagged interface is an interface that is
configured to process traffic for multiple VLANs. A VLAN tag identifies
the specific VLAN and allows traffic to be passed through that specific
VLAN. In order to cause traffic for multiple VLANs to be passed through a
single trunk, you must assign the same trunk to each VLAN.
In the examples, we create a trunk (trunk1) that includes two interfaces, 1.1
and 1.2, and then assign trunk1 as a tagged interface to both VLAN external
and VLAN internal. Consequently, inbound and outbound traffic passing
between the BIG-IP system and the vendor switch can use either interface.
For example, traffic destined for VLAN external can pass through either
interface, 1.1 or 1.2.
Aggregating the two interfaces into a trunk to create a link has the following
advantages:
• It increases the bandwidth of the individual network interface cards
(NICs) in an additive manner.
• If one link goes down, the other link can handle the traffic by itself.
The examples in this chapter show you how to use link aggregation in two
configurations, a two-network configuration and a single-network
configuration.

Chapter 17
Using the two-network aggregated tagged interface

topology
Figure 17.1 shows a two-IP network topology, with one network connected
to VLAN external, and a separate network connected to VLAN internal.
Figure 17.1 An example of an aggregated two-interface load balancing configuration with two IP networks
To configure the BIG-IP system for the two-network implementation, you

must complete the following tasks:
• Create a trunk to aggregate the links.
• Add the trunk as a tagged interface to VLAN internal and VLAN
external.
• Create a pool of web servers that you want to load balance.
• Create a virtual server that load balances the web servers.
Note
This example assumes that you are using the default internal and external
VLAN configuration. It also assumes that the self IP addresses on each
VLAN are on the same IP networks as the BIG-IP system.
17 - 2
Aggregating the links

The first task for this implementation is to aggregate the links. To do this,
you must create a trunk, assign interfaces to the trunk as members, and then
enable Link Aggregation Control Protocol (LACP).
To aggregate links
Trunks.
The Trunks screen opens.
The New Trunk screen opens.
user role does not grant you permission to create a trunk.
3. In the Name box, type a name for the trunk, such as trunk1.
4. For the Interfaces setting, locate the Available box and select an
interface.
Note: The lowest-numbered interface is the controlling or reference
interface.
5. Using the Move button, move the interface number to the Members
box.
6. Repeat step 5 for all interfaces that you want to include as trunk
members.
7. For the LACP setting, check the box.
This enables dynamic link aggregation.
8. Click Finished.
Assigning a trunk to the VLANs

After you aggregate the links, you assign the trunk to the VLAN as a tagged
interface.
WARNING
You should perform this task from the management interface; otherwise you
will be disconnected from the BIG-IP system.
To add tagged interfaces to an existing VLAN

VLANs.
2. In the Name column, click the VLAN name internal.
This displays the properties of that VLAN.

Chapter 17
3. For the Interfaces setting, locate the Available box and select the
name of the trunk that you created in the previous procedure.
4. Click the Move button to move the trunk name to the Tagged box.
This assigns the trunk to the VLAN, as a tagged interface.
5. Click Update.
6. Return to the list of existing VLANs.
7. Repeat steps 2 - 5 for VLAN external.
8. Click Update.
Creating a pool of web servers to load balance

After you create the network environment for the BIG-IP system, you can
create the pool of web servers you want to load balance.
To create a pool
click Pools.
3. In the Name box, type a name for the pool, such as myweb_pool.
b) In the Address box, type the IP address of a web server in the
pool.
c) From the Service Port list, select a service.
d) Click Add.
5. Click Finished.
17 - 4
Creating a virtual server to load balance the web servers

After you create the pool of web servers you want to load balance, you can

vs_myweb.
Using the example in Figure 17.1, on page 17-2, this address could
be 10.0.10.30.
(for example, myweb_pool).
7. Click Finished.

Chapter 17
Using the one-network aggregated tagged interface

topology
Figure 17.2 shows a single IP network topology. The one-network topology
is identical to the two-network topology in all respects except that in the
one-network implementation, VLAN internal and VLAN external are on
the same internal network. This requires that the two VLANs be grouped in
order to be able to exchange packets directly.
Figure 17.2 An example of an aggregated two-interface load balancing configuration with one IP network
You configure the one-network topology in exactly the same way as the
two-network topology (allowing for the fact that the virtual server address
will now belong to the same network as the servers), with one additional
step: the internal and external VLANs need to be grouped. Therefore, to
configure the BIG-IP system for this implementation, you must complete
• Configure the tagged interfaces, load balancing pool, virtual server, and
trunk exactly as in the two-network configuration.
For more information, see Using the two-network aggregated tagged
interface topology, on page 17-2.
• Remove the self IP addresses from the internal and external VLANs.
• Combine the internal and external VLANs into a VLAN group.
• Assign a self IP address to the VLAN group.
17 - 6
Removing the self IP addresses from the VLANs

Before you can create a VLAN group, you must remove the self IP
addresses from the individual VLANs. After you create the VLAN group,
you create a self IP address for the VLAN group, for routing purposes. The
individual VLANs no longer need their own self IP addresses.
WARNING
You should perform this task from the management interface; otherwise you
will be disconnected from the BIG-IP system.
To remove the self IP addresses from the default VLANs

Self IPs.
2. Using the IP Address and VLANs columns, locate the self IP
addresses for the internal and external VLANs.
3. To the left of each self IP address you want to delete, check the
Select box.
4. Click Delete.
A confirmation screen appears.
Note: If the Delete button is unavailable, this indicates that your
user role does not grant you permission to delete a self IP address.
5. Click Delete again.
Creating a VLAN group

Packets received by a VLAN in the VLAN group are copied onto the other
VLAN. This allows traffic to pass through the BIG-IP system on the same
IP network.
Tip
A VLAN group name can be used anywhere that a VLAN name can be used.
To create a VLAN group

VLANs.
2. From the VLAN Groups menu, choose List.
This opens the VLAN Groups screen.
This opens the New VLAN Group screen.

Chapter 17

user role does not grant you permission to create a VLAN group.
4. In the Name box, type the name myvlangroup.
5. For the VLANs setting, use the Move button to move the internal
and external VLAN names from the Available box to the
Members box.
6. Click Finished.
Creating a self IP for the VLAN group

After you have created the VLAN group, create a self IP address for the
VLAN group. The self IP address for the VLAN group provides a route for
packets destined for the network. With the BIG-IP system, the path to an IP
network is a VLAN. However, with the VLAN group feature used in this
example, the path to the IP network 10.0.0.0 is actually through more than
one VLAN. Since IP routers are designed to have only one physical route to
a network, a routing conflict can occur. The self IP address feature on the
BIG-IP system allows you to resolve the routing conflict by putting a self IP
address on the VLAN group.
To create a self IP address for a VLAN group

Self IPs.
3. In the IP Address box, type a self IP address for the VLAN group.
4. In the Netmask box, type a netmask for the self IP address.
5. For the VLAN setting, select the name myvlangroup from the list.
6. Click Finished.
17 - 8
18
• Introducing packet filtering
• Configuring packet filtering

Introducing packet filtering

Packet filters enhance network security by specifying whether a BIG-IP®
system interface should accept or reject certain packets based on criteria that
you specify. Packet filters enforce an access policy on incoming traffic.
They apply to incoming traffic only.
You implement packet filtering by creating packet filter rules. The primary
purpose of a packet filter rule is to define the criteria that you want the
BIG-IP system to use when filtering packets. Examples of criteria that you
can specify in a packet filter rule are:
• The source IP address of a packet
• The destination IP address of a packet
• The destination port of a packet
You specify the criteria for applying packet filter rules within an expression.
When creating a packet filter rule, you can instruct the Configuration utility
to build an expression for you, in which case you need only choose the
criteria from predefined lists, or you can write your own expression text,
using the syntax of the tcpdump utility. For more information on the
tcpdump utility, see the online man page for the tcpdump command.
Note
Packet filter rules are unrelated to iRulesTM.
You can also configure global packet filtering that applies to all packet filter
rules that you create. The following sections describe how to set global
packet filtering options, and how to create and manage individual packet
filters rules.
By setting up some basic IP routing and configuring packet filtering,
specific hosts on the internal VLAN can connect to the internal VLAN’s self
IP address. These hosts can also use common Internet services such as
HTTP, HTTPS, DNS, FTP, and SSH. Traffic from all other hosts in the
internal VLAN is rejected.
To configure this implementation, you must:
• Create a SNAT.
• Create a pool of routers (also known as a gateway pool).
• Create a forwarding virtual server.
• Create a packet filter rule.

Chapter 18
Configuring packet filtering

This section describes each of the tasks that you need to perform to fully
configure packet filtering.
Creating a SNAT
The first task in implementing packet filtering is to create a SNAT.
To create a SNAT
click SNATs.
3. In the Name box, type a unique name for the SNAT.
4. From the Translation list, select Automap.
This displays the VLAN List setting.
6. For the VLAN List setting, from the Available box select internal
and external, and click the Move button (<<) to move the VLAN
names to the Selected box.
7. Click Finished.
Creating a gateway pool

The next task is to define a pool of routers, also known as a gateway pool.
To create a gateway pool

click Pools.
3. In the Name box, type a name for the pool, such as gateway_pool.
18 - 2
The members you add are router IP addresses.
5. Click Finished.
Creating a forwarding virtual server

The next task is to create a forwarding virtual server that references the pool
gateway_pool.
To create the virtual servers

vs_packetfilter.
a) For Type, select Network.
b) In the Address box, type the IP address 0.0.0.0.
c) In the Mask box, type the netmask 0.0.0.0.
6. In the Configuration area of the screen, locate the Type setting and
select Forwarding (IP).
7. From the Protocol list, select *All Protocols.
9. For the VLAN List setting, from the Available box select internal,
and click the Move button (<<) to move the VLAN name to the
Selected box.
and select the pool you created previously (gateway_pool).
11. Click Finished.

Chapter 18
Creating a packet filter rule

The final task in implementing packet filtering is to create a packet filter
rule. Note that a packet filter rule is different from an iRule.
To create a packet filter rule

Packet Filters.
This displays the setting to enable or disable packet filtering.
2. From the Packet Filtering list, select Enabled.
This displays additional settings.
3. From the Unhandled Packet Action list, select Accept.
4. Click Update.
5. On the menu bar, click Rules.
This displays a list of existing packet filter rules, if any.
6. On the upper right corner of the screen, click Create.
The New Packet Filter Rule screen opens.
user role does not grant you permission to create a packet filter
rule.
7. In the Name box, type a packet filter name, such as pf_internal.
8. From the Order list, select First.
9. From the Action list, select Reject.
10. From the Apply to VLAN list, select internal.
11. From the Logging list, select Enabled.
12. From the Filter Expression Method list, select Enter Expression
Text.
This displays the Filter Expression text box.
13. In the text box, type an expression. For example:
not dst port 80 and not dst port 443 and not dst port 53
and not dst port 22 and not dst port 20 and not dst port
21 and not dst host <internal self IP address>
Note: Replace <internal self IP address> with the actual self IP
address of VLAN internal. Also, see the tcpdump man page for
general information about building expresssions.
14. Click Finished.
18 - 4
19
Implementing Health and Performance
Monitors
• Introducing health and performance monitors
• Creating a custom monitor
• Creating a pool

Introducing health and performance monitors

You can set up the BIG-IP® system to monitor the health or performance of
certain nodes or servers that are members of a load balancing pool.
Monitors verify connections on pool members and nodes. A monitor can be
either a health monitor or a performance monitor, designed to check the
status of a pool, pool member, or node on an ongoing basis, at a set interval.
If a pool member or node being checked does not respond within a specified
timeout period, or the status of a pool member or node indicates that
performance is degraded, the BIG-IP system can redirect the traffic to
another pool member or node.
Some monitors are included as part of the BIG-IP system, while other
monitors are user-created. Monitors that the BIG-IP system provides are
called pre-configured monitors. User-created monitors are called custom
monitors.
Before configuring and using monitors, it is helpful to understand some
basic concepts regarding monitor types, monitor settings, and monitor
implementation.
◆ Monitor types
Every monitor, whether pre-configured or custom, is a certain type of
monitor. Each type of monitor checks the status of a particular protocol,
service, or application. For example, one type of monitor is HTTP. An
HTTP type of monitor allows you to monitor the availability of the
HTTP service on a pool, pool member, or node. A WMI type of monitor
allows you to monitor the performance of a pool, pool member, or node
that is running the Windows Management Instrumentation (WMI)
software. An ICMP type of monitor simply determines whether the status
of a node is up or down.
◆ Monitor settings
Every monitor consists of settings with values. The settings and their
values differ depending on the type of monitor. In some cases, the
BIG-IP system assigns default values. For example, Figure 19.1 shows
the settings and default values of an ICMP-type monitor.
Name my_icmp
Type ICMP
Interval 5
Timeout 16
Transparent No
Alias Address * All Addresses
Figure 19.1 Example of a monitor with default values

Chapter 19
To implement a health monitor, you complete these tasks:

• Create a custom monitor or decide to use a pre-configured monitor.
• Create a pool for load balancing traffic, and assign a monitor to the pool.
• Create a virtual server for processing traffic.
The remainder of this chapter describes how to create these objects.
Note
If you want to monitor the performance of a RealNetworks® RealServer

server or a Windows® server equipped with Windows Management
Instrumentation (WMI), you must first download a special plug-in file onto
the BIG-IP system. For more information, see the Configuration Guide for
BIG-IP® Local Traffic Management.
19 - 2
Creating a custom monitor

When you want to monitor a node, a server, or a pool of servers, you can use
a pre-configured monitor, or you create a custom monitor. The following
procedure describes how to create a custom monitor. If you want to use a
pre-configured monitor, you can skip this procedure and move on to the next
section, Creating a pool, on page 19-4.
To create a custom monitor

click Monitors.
user role does not grant you permission to create a monitor.
3. In the Name box, type a name for the custom monitor.
For example, if you are creating a custom HTTP monitor, you can
assign the name my_http_monitor.
4. From the Type list, select the type of monitor you want to create.
This displays additional monitor settings for you to configure.
Note: For a detailed description of each monitor type, see the
5. Change the values of any monitor settings to suit your needs.
6. Click Finished.
After you have created a custom monitor, you can create a load balancing
pool and assign the monitor name to the pool.

Chapter 19
Creating a pool
When you create the pool to load balance traffic, you assign the custom
monitor that you created in the previous section to a load balancing pool.
Then, after creating the pool, you assign it to the virtual server that you
create in the next section.
Assigning a monitor to a pool

One way to assign a monitor is to create the pool and assign the monitor to
the pool itself. When you assign a monitor to a pool, all members of the pool
inherit the monitor. If you want to exclude one or more pool members from
inheriting the monitor that you assign to a pool, see Excluding a pool
member from a monitor, on page 19-5.
To create a pool and assign a monitor

click Pools.
name of the custom monitor, such as my_http_monitor, and click
the Move button (<<) to move the monitor name to the Active box.
5. In the Resources section, ensure that the Load Balancing Method
setting is set to Round Robin.
6. Ensure that the Priority Group Activation setting is set to
Disabled.
d) Click Add.
8. Click Finished.
19 - 4
Excluding a pool member from a monitor

After you create the pool, you can exclude a pool member from inheriting a
monitor in one of two ways:
• Remove the monitor from the pool member.
• Assign a different monitor to the pool member.
Removing a monitor assignment from a pool member is useful if you want

to monitor some, but not all, of the servers in a load balancing pool. When
you exclude a pool member from inheriting the monitor that you assigned to
the pool, you have the option of assigning a different monitor to that pool
member. In this case, the other pool members are still monitored by the
monitor you assigned to the pool itself.
To exclude a pool member from monitor you assigned to the pool, you must
first follow the procedure described in To create a pool and assign a
monitor, on page 19-4. Then you can use one of the following procedures.
To remove a monitor from a pool member

click Pools.
This displays a list of existing pools.
2. In the Name column, click the name of the pool you created in
Assigning a monitor to a pool, on page 19-4.
3. On the menu bar, click Members.
The Current Members area of the screen lists the members of the
pool.
4. In the Members column, click the address of the pool member from
which you want to remove the monitor.
This displays the properties of that pool member.
This displays the Health Monitors setting.
6. From the Health Monitors list, select None.
7. Click Update.
To assign a unique monitor to a pool member

click Pools.
2. In the Name column, click the name of the pool you created in
Assigning a monitor to a pool, on page 19-4.
3. On the menu bar, click Members.
The Current Members area of the screen lists the members of the
pool.

Chapter 19
4. In the Members column, click the address of the pool member for
which you want to assign a unique monitor.
This displays the properties of that pool member.
This displays the Health Monitors setting.
6. From the Health Monitors list, select Member Specific.
7. Click Update.

The last task in a basic configuration is to define a virtual server that
references the pool that you created in Creating a pool, on page 19-4. You
use the Configuration utility to create the virtual server.

vs_httppool.
5. From the Service Port list, select a service.
and select the name of the pool you created (such as http_pool).
7. Click Finished.
19 - 6
20
• Configuring the radvd service
• Configuring IPv4-to-IPv6 load balancing

Configuring the radvd service

The first task to setting up the BIG-IP® system to function as an
IPv4-to-IPv6 gateway is an optional one: to configure the radvd service.
You configure the radvd service to send out ICMPv6 routing advisory
messages, and to respond to ICMPv6 route solicitation messages.
When you perform this task, the BIG-IP system begins to support
auto-configuration of downstream nodes. Also, the downstream nodes
automatically discover that the BIG-IP system is their router.
Configuring the radvd service to perform these functions ultimately
advertises the network’s global address prefix on the internal VLAN. For
more information on BIG-IP system services, see the TMOSTM
To configure the radvd service

1. Using a serial console or the IP address of the BIG-IP system
management interface, access an operating system prompt on the
BIG-IP system.
2. Copy the file /etc/radvd.conf.example to a new file named
/etc/radvd.conf.
3. Using the nano or vi text editor, open the file /etc/radvd.conf.
4. Using the example in the file, create an advertising configuration for
the network’s global address prefix.
Note: Replace the prefix option with an address appropriate for
your network.
5. Save the /etc/radvd.conf file and exit the editor.
6. Start the radvd service as follows:
bigstart startup radvd
7. Verify that the IPv6 nodes have auto-configured their addresses for
this prefix.
8. Take note of the addresses of the HTTP service IPv6 nodes.
These addresses are required for the next step in the process,
configuring IPv4-to-IPv6 load balancing.

Chapter 20
Configuring IPv4-to-IPv6 load balancing

When you configure IPv4-to-IPv6 load balancing, you must create a pool
for load balancing traffic to IPv6 nodes, and then create an IPv4 virtual
server that processes application traffic.
For more information about these tasks, click the Help tab in the
Configuration utility, or see the Configuration Guide for BIG-IP® Local
Traffic Management.
Creating a pool of IPv6 nodes

The first task in configuring IPv4-to-IPv6 load balancing is to create a pool
to load balance connections to IPv6 nodes. Use the Configuration utility to
create this pool.
To create a pool of IPv6 nodes

click Pools.
3. In the Name box, type a name for the pool, such as ipv6_pool.
4. For the Health Monitors setting, from the Available box select a
monitor for the type of traffic you want to load balance, and click
the Move button (<<) to move the monitor name to the Active box.
5. For the New Members setting, add the IPv6 pool members:
b) In the Address box, type the IPv6 address of a node in the pool.
c) In the Service Port box, type a service number, such as 80, or
select a service name, such as HTTP.
d) Click Add.
e) Repeat steps b, c, and d for each node in the pool.
6. Click Finished.
20 - 2

references the pool of IPv6 nodes. You use the Configuration utility to
To create a virtual server for IPv6 nodes

vs_ipv6.
5. In the Service Port box, type a service number, such as 80, or select
a service name, such as HTTP, from the list.
6. In the Configuration area of the screen, locate the profile setting for
the type of traffic you want to load balance, such as HTTP Profile,
and select a profile name, such as http.
This assigns the selected profile to the virtual server.
(for example, ipv6_pool).
8. Click Finished.

Chapter 20
20 - 4
21
• Introducing overlapping IP addresses
• Configuring route domains

Introducing overlapping IP addresses

The BIG-IP® system includes a feature that allows you to use overlapping
(duplicate) IP addresses on a network. This feature is known as route
domains.
What is a route domain?

A route domain is a BIG-IP object that you create, that represents a
particular address space on the network. Multiple nodes that each reside in a
separate route domain on the network can have the same IP address. This
allows a service provider, for example, to assign the same IP address to
multiple pool members in a pool, where each pool member represents a
different physical server. In this case, each pool member resides in a
separate route domain. One common reason to use route domains is when
you want each physical server to process traffic for a different customer.
For example, if you are processing traffic for two different customers, you
can create two separate route domains. The same node address (such as
10.10.10.1) can reside in both route domains, in the same pool or in different
pools, and you can assign a different monitor to each of the two
corresponding pool members.
In general, the route domains feature performs two main functions:
• The BIG-IP system acts as if two more octets were added to each IP
address. However, on the network, the system still shows the 4-octet IP
address.
• Each route domain has its own routing table, and traffic does not cross
route domains unless explicitly configured to do so (default deny).
You can configure route domains using the Configuration utility, the
bigpipe utility, or tmsh.
Specifying route domain IDs

Each route domain that you create has a unique integer ID. The address
format required for using overlapping IPv4 addresses is A.B.C.D%ID,
where ID is the ID of the route domain in which the IP address resides.
For example, three distinct pool members can have the IP address
10.10.10.1:80, where one member resides in route domain 1, another
member resides in route domain 2, and the third member resides in route
domain 3. In this case, the three pool members are identified as
10.10.10.1%1:80, 10.10.10.1%2:80, and 10.10.10.1%3:80, respectively.
If you do not create any route domains, then all BIG-IP objects that you
create reside in a single, default route domain. The default route domain has
an ID of 0. If you use the default route domain only, then you do not need to
specify ID 0 in any IP addresses, and this ID does not appear on the system.

Chapter 21
Configuring route domains

To create a typical route domain configuration, you create these BIG-IP
system objects for each route domain:
• VLANs
• Self IP addresses
• Route domain objects
• Pool members
• Static routes
• Virtual servers
For any of these BIG-IP objects that require an IP address, you must include
the relevant route domain ID in the address, using the %ID format. (For
information on route domain IDs, see Specifying route domain IDs, on page
21-1.)
Figure 21.1 shows an example of configuring two distinct route domains for
the purpose of using overlapping IP addresses on your network. Note in this
example that the same IP addresses for objects in route domain 1 are used
for objects in route domain 2. The only difference in the duplicate IP
addresses is the distinct route ID.
Figure 21.1 Sample route domain configuration
21 - 2
The sample configuration in Figure 21.1, on page 21-2 contains these

objects:
◆ Two route domains
The route domains are named 1 and 2.
◆ Two VLANs per route domain
For route domain 1, these VLANs are named vlan_clientside1 and
vlan_serverside1. For route domain 2, these VLANs are named
vlan_clientside2 and vlan_serverside2.
◆ Two self IP addresses per route domain
For route domain 1, the self IP addresses are 12.1.1.254%1 and
10.2.1.254%1). For route domain 2, the self IP addresses are
12.1.1.254%2 and 10.2.1.254%2.
◆ Two client nodes per route domain
For route domain 1, the client IP addresses are 12.1.1.101%1 and
12.1.1.102%1. For route domain 2, the client IP addresses are
12.1.1.101%2 and 12.1.1.102%2.
◆ Two server nodes per route domain
For route domain 1, the server node IP addresses are 10.2.1.101%1 and
10.2.1.102%1. For route domain 2, the server node IP addresses are
10.2.1.101%2 and 10.2.1.102%2.
◆ Two virtual addresses per route domain
For route domain 1, the virtual addresses are 12.1.1.253%1 and
10.2.1.253%1. For route domain 2, the virtual addresses are
12.1.1.253%2 and 10.2.1.253%2.
Note
For information on the syntax for bigpipe or tmsh commands, see the
Bigpipe Utility Reference Guide and the Traffic Management Shell (tmsh)
Reference Guide.
Creating VLANs for route domains

The first step to creating a route domain configuration is to create the
VLANs. In our example, we need to create a total of four VLANs:
• Two VLANs for application A (vlan_clientside1 and vlan_serverside1),
corresponding to route domain 1.
• Two VLANs for application B (vlan_clientside2 and vlan_serverside2),
corresponding to route domain 2.
Each VLAN is created with one tagged interface, such as 1.1.

Chapter 21
To create VLANs for route domain 1

1. On the Main tab of the navigation pane, expand Network and click
VLANs.
This displays a list of all existing VLANs.
Note: If the Create button is unavailable, you do not have
permission to create a VLAN. You must have the appropriate user
role assigned to your user account.
3. Locate the General Properties area, and in the Name box, type a
unique name for the VLAN.
In our example, this name is vlan_clientside1.
4. In the Tag box, type a tag for the VLAN, or leave the box blank.
If you do not specify a tag, the BIG-IP system assigns one
automatically.
5. In the Resources area, for the Interfaces setting, click an interface
number or trunk name in the Available box, and using a Move
button (<< or >>), move the interface number to the Tagged box.
Repeat this step as necessary.
For more information on tagged interfaces, see the TMOSTM
6. If you want to enable source checking, then in the Configuration
area, click the Source Check box.
7. For the MTU setting, use the default value or type a new value.
8. In the MAC Masquerade box, type a MAC address.
For more information, see the TMOSTM Management Guide for
BIG-IP® Systems.
9. For the Fail-safe setting, check the box if you want to base
redundant-system failover on VLAN-related events.
For more information, see the TMOSTM Management Guide for
BIG-IP® Systems.
10. Click Finished.
11. Repeat this procedure to create the second VLAN for route
domain 1, assigning the name vlan_serverside1 in step 3.
To create VLANs for route domain 2

To continue with our example, use the procedure in the preceding section to
create the VLANs for route domain 2. In this case, you assign the names
vlan_clientside2 and vlan_serverside2 to the VLANs.
21 - 4
Creating self IP addresses for route domains

The next step in the configuration process is to create a self IP address for
each VLAN. In our example, we are creating four self IP addresses: one for
each of two VLANs in route domain 1, and one for each of two VLANs in
route domain 2. Note that the two self IP addresses within a route domain
must be unique, but any two self IP addresses that fall within separate route
domains can have duplicate addresses, as long as the route domain ID in
each address is unique.
To create self IP addresses for VLANs in route domain 1

Self IPs.
This displays a list of existing self IP addresses.
2. In the upper-right corner of the screen, click the Create button.
permission to create a self IP address. You must have the
appropriate user role assigned to your user account.
3. In the IP Address box, type the self IP address that you want to
assign to VLAN vlan_clientside1, including the route domain ID
(1).
In our example, the self IP address for vlan_clientside1 is
12.1.1.254%1.
4. In the Netmask box, type a netmask.
In our example, the netmask is 255.255.255.0.
5. For the VLAN setting, select the name of the VLAN that you want
to assign to the self IP address.
In our example, this is vlan_clientside1.
6. For the Port Lockdown setting, select Allow Default.
7. If you want to configure the self IP address as a floating IP address,
check the Floating IP box.
8. To finish the configuration of this self IP address and create other
self IP addresses, click Repeat and perform all previous steps until
all self IP addresses have been created.
9. Click Finished.
10. Repeat this procedure to create a self IP address for the other VLAN
in route domain 1.
In our example, this self IP address is 10.2.1.254%1 and the
corresponding VLAN is vlan_serverside1.
To create self IP addresses for VLANs in route domain 2

create the self IP addresses for VLANs in route domain 2. The self IP
addresses for VLANs in route domain 2 are the same as the addresses in

Chapter 21
route domain 1, except for the route ID. In our example, the self IP
addresses for route domain 2 are 12.1.1.254%2 and 10.2.1.254%2, and you
assign the VLANs vlan_clientside2 and vlan_serverside2 to these
addresses.
Creating route domain objects

The next step to creating a route domain configuration is to create route
domain objects. In our example, we create two route domain objects, and
assign two existing VLANs to each route domain.
To create a route domain object for route domain 1

Route Domains.
This displays a list of existing route domains.
permission to create a self IP address. You must have the
appropriate user role assigned to your user account.
3. In the ID box, type an integer for the route domain ID.
For our example, this number is 1.
4. In the Description box, type a textual description of the route
domain.
5. From the Parent ID box, select None.
6. For the VLANs setting, click the VLAN name vlan_clientside1 in
the Available box, and using a Move button (<< or >>), move the
name to the Members box. Repeat the process for VLAN name
vlan_serverside1.
7. Click Finished.
To create a route domain object for route domain 2

create route domain 2. In this case, assign the VLANs vlan_clientside2 and
vlan_serverside2 to the route domain.
21 - 6
Creating pool members for route domains

Next, you must create pools with pool members for each route domain. To
continue with our example, create two pool members for each pool,
specifying the route domain IDs in the pool member addresses.
In our example, each route domain has the same set of pool members; only
the route domain ID differs within each route domain. Thus, route domains
1 and 2 each have the same pool members 10.2.1.101:80 and 10.2.1.102:80.
To create pool members for route domain 1

click Pools
permission to create a pool. You must have the appropriate user
3. In the Name box, type a name for the pool, such as pool_rd1.
4. For the Health Monitors setting, click a monitor name in the
Available box, and using a Move button (<< or >>), move the
interface number to the Active box.
5. For the New Members setting:
a) In the Address box, type a pool member address, including the
route domain ID. For our example, this address is 10.2.1.101%1.
b) In the Service Port box, type a service name, or select one from
the list.
c) Click Add.
d) Repeat steps a, b, and c for the second pool member. For our
example, this address is 10.2.1.102%1.
6. Click Finished.
To create pool members for route domain 2

create pool members for route domain 2. In our example, you create a pool
with a name such as pool_rd2, and assign IP addresses 10.2.1.101%2 and
10.2.1.102%2 to the pool members. Note that these are the same IP
addresses that you specified for the pool members in pool_rd1, except for
the route domain ID.

Chapter 21
Creating static routes

Next, you must create static routes that apply to each route domain. In the
example, for each route domain, the routes apply to both client-side and
server-side destinations.
To create static routes for route domain 1

Routes.
The Routes screen opens.
2. On the upper-right corner of the screen, click Add.
Note: If the Add button is unavailable, you do not have permission
to create a static route. You must have the appropriate user role
assigned to your user account.
3. From the Type list, select Route.
4. In the Destination box, type a destination IP address, including the
route domain ID.
For example, the destination can be the node address of a pool
member, such as 10.2.1.101%1 (in pool_rd1).
5. In the Netmask box, type the netmask for the IP address you typed
in the Destination box.
6. For the Resource property, select either of the following:
a) Use Gateway
In the box, type the self IP of a VLAN within route domain 1,
such as 10.2.1.254%1. (This is the self IP address for
vlan_serverside1.)
b) Use VLAN
In the box, type the name of a VLAN in route domain 1, such as
vlan_serverside1.
7. Click Finished.
8. Using our example, repeat this procedure to create these other static
routes for route domain 1:
a) A route to the other server-side node in pool_rd1
(10.2.1.102%1).
In this case, the gateway address and VLAN name are the same
as for the route you created in steps 1 through 7 (10.2.1.254%1
and vlan_serverside1, respectively).
b) A route to a client-side node in route domain 1.
In this case, using our example, the destination address is
12.1.1.101%1, the gateway address is 12.1.1.254%1, and the
VLAN name is vlan_clientside1.
21 - 8
c) A route to the other client-side node in route domain 1.

In this case, still using our example, the destination address is
12.1.1.102%1, and the gateway address and VLAN name are the
same as in the previous step (12.1.1.254%1 and
vlan_clientside1, respectively).
To create static routes for route domain 2

create static routes for route domain 2. In this case, you create these routes:
◆ Two routes corresponding to each of the two server-side nodes in
pool_rd2 (nodes 10.2.1.101%2 and 10.2.1.102%2), specifying either the
gateway address 10.2.1.254%2 or the VLAN name vlan_serverside2.
◆ Two routes corresponding to each of the two client-side nodes (nodes
12.1.1.101%2 and 12.1.1.102%2), where the gateway address and
VLAN name are 12.1.1.254%2 and vlan_clientside2, respectively).
Creating virtual servers for route domains

Finally, you must create virtual servers for each route domain, assigning a
pool to each virtual server. In our example, the two nodes in pool_rd1 use
the same two pool member addresses as the nodes in pool_rd2, although the
routing IDs specified in the pool member addresses differ by route domain.
To create virtual servers for route domain 1

1. On the Main tab, expand Local Traffic, and click Virtual Servers.
2. On the upper right portion of the screen, click the Create button.
You must have the appropriate user role assigned to your user
account.
3. In the Name box, type a name for a virtual server in route
domain 1, for example, vs_serverside_rd1.
4. In the Destination box:
a) Verify that the Host button is selected.
b) In the Address box, type an IP address for the virtual server, for
example, 10.2.1.253%1.
5. In the Service Port box, either type a service number (such as 80),
or from the list, select a service name (such as HTTP).
6. Verify that the State setting is set to Enabled.

Chapter 21
7. From the Configuration list, select Advanced and do the

following:
a) From the Type list, select Performance (Layer 4).
For information on this virtual server type, see the Configuration
Guide for BIG-IP Local Traffic Management.
b) Except for the Default Pool setting, retain all default values.
8. From the Default Pool list, select the name of the pool for route
domain 1.
In our example, this name is pool_rd1.
9. Click Finished.
10. Repeat this procedure to create a client-side virtual server for route
domain 1.
In our example, the virtual server name is vs_clientside_rd1 and the
virtual server address is 12.1.1.253%1. You can skip step 8,
selecting a default pool name.
To create virtual servers for route domain 2

create virtual servers for route domain 2:
◆ Create a virtual server with a name such as vs_serverside_rd2 with an IP
address of 10.2.1.253%2.
◆ Create a virtual server with a name such as vs_clientside_rd2 with an IP
address of 12.1.1.253%2. You can skip step 8, selecting a default pool
name.
21 - 10
22
Mitigating Denial of Service and Other
Attacks
• Basic denial of service security overview
• Configuring adaptive connection reaping
• Simple DoS prevention configuration
• Filtering out attacks with iRules
• How the BIG-IP system handles several common

attacks
Basic denial of service security overview

The BIG-IP® system contains several features and configurations that
provide you the ability to create a configuration that contributes to the
security of your network. In particular, the BIG-IP system is in a unique
position to mitigate some types of denial-of-service (DoS) attacks that try to
consume system resources in order to deny service to the intended
recipients.
The following features of the BIG-IP system help it resist many types of
DoS attacks:
◆ Hardened and dedicated kernel
The BIG-IP kernel has a mechanism built in to protect against SYN
Flood attacks by limiting simultaneous connections, and tearing down
connections that have unacknowledged SYN/ACK packets after some
time period as passed. (A SYN/ACK packet is a packet that is sent as part
of the TCP three-way handshake).
◆ High performance
BIG-IP system can handle tens of thousands of Layer 4 (L4) connections
per second. It would take a very determined attack to affect either the
BIG-IP system itself, or the site, if sufficient server resources and
bandwidth are available.
◆ Large amount of available memory
SYN floods, or denial-of-service (DoS) attacks, can consume all
available memory. The BIG-IP system supports a large amount of
memory to help it resist DoS attacks.
This chapter describes several configurations that help mitigate DoS attacks.
The configurations described include:
• How to configure the adaptive reapers to allow the BIG-IP system to
respond to attacks, following.
• A basic configuration to defend against denial of service attacks, on page
22-4.
• Several examples of iRulesTM syntax you can use to filter out specific
known attacks, on page 22-7.
For more information about these tasks, click the Help tab in the
Configuration utility, or see the Configuration Guide for BIG-IP® Local
Traffic Management.

Chapter 22
Configuring adaptive connection reaping

The BIG-IP system contains two global settings that provide the ability to
reap connections adaptively. Connection reaping is a condition where
connections are removed from the BIG-IP system when the connection load
uses enough memory to trigger the start of aggressive reaping. To prevent
denial-of-service attacks, you can specify a low-water mark threshold and a
high-water mark threshold:
• The low-water mark threshold determines at what point adaptive reaping
becomes more aggressive.
• The high-water mark threshold determines when unestablished
connections through the BIG-IP system will no longer be allowed. The
value of this variable represents a percentage of memory utilization.
Once memory utilization has reached the high-water mark, connections are
disallowed until the available memory has been reduced to the low-water
mark threshold.
WARNING
The adaptive reaper settings do not apply to SSL connections. However, you
can set TCP and UDP connection timeouts that reap idle SSL connections.
For more information see Setting the TCP and UDP connection timers, on
page 22-4.
To set the adaptive reapers using the Configuration utility

1. On the Main tab of the navigation pane, expand System, and click
Configuration.
The General screen opens.
2. From the Local Traffic menu, choose General.
The System screen opens.
3. In the Properties table, set the following values:
• Set the Reaper High-water Mark property to 95.
• Set the Reaper Low-water Mark property to 85.
4. Click Update.
Tip
There is generally no need to change these values as they represent an
optimal solution for most BIG-IP system deployments.
Important
Setting both of the adaptive reaper values to 100 disables this feature.
22 - 2
Logging adaptive reaper activity

You can log adaptive reaper activity by setting the logging levels on the
BIG-IP system to a more sensitive level.
When you set this logging level, the system logs a rate-limited message
(maximum once every 10 seconds), informing you that the adaptive reaping
mode has been entered or exited. This log message has a priority of
warning. For more information about the log level, refer to the db man
page.
Important
When the adaptive reaper high water limit is reached, the LCD displays the
message Blocking DoS Attack.
To set the adaptive reaper logging level from the command

line
1. Open a console on the BIG-IP system.
2. Type the following command to view the adaptive reaper logging
level:
bp db Log.DosProtect.Level list
The output looks as follows:

db Log.DosProtect.Level "Warning"
3. Choose the logging level for the adaptive reaper. The following
levels display the message Blocking DoS Attack on the LCD when
the Reaper High Water Mark is exceeded:
• Emergency
• Alert
• Critical
• Error
• Warning
The following levels do not display the Blocking DoS Attack
message on the LCD.
• Notice
• Informational
4. Type the following command to set the adaptive reaper logging
level, where <log level> is the logging level:
bp db Log.DosProtect.Level "<log level>"

Chapter 22
Simple DoS prevention configuration

DoS prevention is a simple configuration you can employ to mitigate the
impact of denial-of-service attacks.
The configuration consists of four tasks:
• Set the global TCP and UDP connection reap times to 60 seconds.
• Set an IP rate class of 20Mbps, outstanding queue maximum size of
2Mbps.
• Set the connection limit on the main virtual server to the approximate
amount of RAM in KB * 0.8.
Setting the TCP and UDP connection timers

You can set the TCP and UDP timers in the profile settings for the TCP
profile and the UDP profiles. You should set these timers for the services
that you use for your virtual servers. For example, 60 for HTTP connections,
60 for SSL connections.
To set the TCP connection reaper time

click Profiles.
2. From the Protocol menu, choose TCP.
The TCP profile list screen opens.
3. Click the name of the profile you want to configure.
The properties screen for the profile opens.
4. Set the Idle Timeout to 60.
5. Click Update.
To set the UDP connection reaper time

click Profiles.
2. From the Protocol menu, choose UDP.
The UDP profile list screen opens.
3. Click the name of the profile you want to configure.
The properties screen for the profile opens.
4. Set the Idle Timeout to 60.
5. Click Update.
22 - 4
Creating an IP rate class and applying it to a virtual server

The next task in setting up a simple configuration for DoS is to create a rate
class. You must first create a rate class, and then apply the rate class to a
virtual server.
Important
The rate class module requires a license key. If you do not have this
functionality and you would like to purchase a license key, contact F5
Networks.
To create a rate class

click Rate Shaping.
The Rate Shaping screen displays.
2. Click the Create button to create a new rate class.
The New Rate Class screen opens.
user role does not grant you permission to create a rate class.
3. Configure the following class properties:
• In the Class Name box, type the name you want to use for this
class.
• In the Base Rate box, type 2000000 (2 Mbps).
• In the Ceiling Rate box, type 20000000 (20 Mbps).
• In the Burst Size box, type 500, and select Megabytes from the
list.
• From the Direction list, select Any.
• From the Queue Discipline list, select Stochastic Fair Queue.
4. Click Finished.
After you create a rate class, you can apply it to the virtual servers in the
configuration.
To apply a rate class to a virtual server

The Virtual Servers List screen opens.
2. On the Virtual Servers List screen, click the virtual server you want
to modify.
3. From the Rate Class list, select the rate class you created.
4. Click Update.

Chapter 22
Setting connection limits on the main virtual server

This section describes how to set the connection limits on the main virtual
server. The connection limits determine the maximum number of concurrent
connections allowed on a virtual server. In this context, the main virtual
server is the virtual server that receives the most traffic to your site.
To calculate a connection limit for the main virtual server

Before you set a connection limit, use the following formula to figure out
what to set the connection limit value to on the main virtual server:
Connection Limit = Approximate Amount of RAM in KB * 0.8.
For example, if you have 256 MB of RAM, the calculation looks like this:
256,000 * 0.8 = 20480
In this case, you set the connection limit to 20480.
To set the connection limits on the main virtual server

The Virtual Servers List screen opens.
2. On the Virtual Servers List screen, click the virtual server you want
to modify.
3. In the Connection Limit box, type the number you calculated for
the connection limit.
4. Click the Update button.
22 - 6
Filtering out attacks with iRules

You can create BIG-IP rules to filter out malicious DoS attacks. Once you
identify a particular attack, you can write an iRule that discards packets that
contain the elements that identify the packet as malicious.
Filtering out a Code Red attack

The BIG-IP system is able to filter out the Code Red attack by using an
iRule to send the HTTP request to a dummy pool. For example, Figure 22.1
illustrates an iRule that discards Code Red attacks.
when HTTP_REQUEST {
if {string tolower [HTTP::uri] contains "default.ida" } {
discard
} else {
pool RealServerPool
}
}
Figure 22.1 A sample iRule for filtering out a Code Red attack
Filtering out a Nimda attack

The Nimda worm is designed to attack systems and applications based on
the Microsoft® Windows® operating system. For Nimda, an iRule can be
written as shown in Figure 22.2.
when HTTP_REQUEST {
set uri [string tolower [HTTP::uri]]
if { ($uri contains "cmd.exe") or ($uri contains
"root.exe") or ($uri contains "admin.dll") } {
discard
} else {
pool ServerPool
}
}
Figure 22.2 Sample iRule syntax to discard Nimda worm

Chapter 22
How the BIG-IP system handles several common

attacks
You might want to know how the BIG-IP system reacts to certain common
attacks that are designed to deny service by breaking the service or the
network devices.
The following pages list the most common attacks, along with how the
BIG-IP system functionality handles the attack.
WARNING
Take care any time you lower the idle session reaping time outs. It is
possible that valid connections will be reaped if the application cannot
respond in time.
SYN flood
A SYN flood is an attack against a system for the purpose of exhausting that
system’s resources. An attacker launching a SYN flood against a target
system attempts to occupy all available resources used to establish TCP
connections by sending multiple SYN segments containing incorrect IP
addresses. Note that the term SYN refers to a type of connection state that
occurs during establishment of a TCP/IP connection.
More specifically, a SYN flood is designed to fill up a SYN queue. A SYN
queue is a set of connections stored in the connection table in the
SYN-RECEIVED state, as part of the standard three-way TCP handshake. A
SYN queue can hold a specified maximum number of connections in the
SYN-RECEIVED state.
Connections in the SYN-RECEIVED state are considered to be half-open
and waiting for an acknowledgement from the client. When a SYN flood
causes the maximum number of allowed connections in the
SYN-RECEIVED state to be reached, the SYN queue is said to be full, thus
preventing the target system from establishing other legitimate connections.
A full SYN queue therefore results in partially-open TCP connections to IP
addresses that either do not exist or are unreachable. In these cases, the
connections must reach their timeout before the server can continue
fulfilling other requests.
Alleviating SYN flooding

The BIG-IP system includes a feature designed to alleviate SYN flooding.
Known as SYN Check™, this feature sends information about the flow, in
the form of cookies, to the requesting client, so that the system does not
need to keep the SYN-RECEIVED state that is normally stored in the
connection table for the initiated session. Because the SYN-RECEIVED
state is not kept for a connection, the SYN queue cannot be exhausted, and
normal TCP communication can continue.
22 - 8
The SYN Check feature complements the existing adaptive reaper feature in
the BIG-IP system. While the adaptive reaper handles established
connection flooding, SYN Check prevents connection flooding altogether.
That is, while the adaptive reaper must work overtime to flush connections,
the SYN Check feature prevents the SYN queue from becoming full, thus
allowing the target system to continue to establish TCP connections.
You can configure the BIG-IP system to activate the SYN Check feature
when some threshold of connections has been reached on the system.
To set the threshold on the BIG-IP system

1. On the Main menu of the navigation pane, expand System, and
click Configuration.
The General Properties screen opens.
2. From the Local Traffic menu, choose General.
3. In the SYN CheckTM Activation Threshold box, type the number
of connections that you want to define for the threshold.
4. Click Update.
ICMP flood (Smurf)

The ICMP flood, sometimes referred to as a Smurf attack, is an attack based
on a method of making a remote network send ICMP Echo replies to a
single host. In this attack, a single packet from the attacker goes to an
unprotected network’s broadcast address. Typically, this causes every
machine on that network to answer with a packet sent to the target.
The BIG-IP system is hardened against these attacks because it answers only
a limited number of ICMP requests per second, and then drops the rest.
On the network inside the BIG-IP system, the BIG-IP system ignores
directed subnet broadcasts, and does not respond to the broadcast ICMP
Echo that a Smurf attacker uses to initiate an attack.
You do not need to make any changes to the BIG-IP system configuration
for this type of attack.
UDP flood
The UDP flood attack is most commonly a distributed denial-of-service
attack (DDoS), where multiple remote systems are sending a large flood of
UDP packets to the target.
The BIG-IP system handles these attacks similarly to the way it handles a
SYN flood. If the port is not listening, the BIG-IP system drops the packets.
If the port is listening, the reaper removes the false connections.

Chapter 22
Setting the UDP idle session timeout to between 5 and 10 seconds reaps
these connections quickly without impacting users with slow connections.
However, with UDP this may still leave too many open connections, and
your situation may require a setting of between 2 and 5 seconds.
UDP fragment
The UDP fragment attack is based on forcing the system to reassemble
huge amounts of UDP data sent as fragmented packets. The goal of this
attack is to consume system resources to the point where the system fails.
The BIG-IP system does not reassemble these packets, it sends them on to
the server if they are for an open UDP service. If these packets are sent with
the initial packet opening the connection correctly, then the connection is
sent to the back-end server. If the initial packet is not the first packet of the
stream, the entire stream is dropped.
Ping of Death
The Ping of Death attack is an attack with ICMP echo packets that are
larger than 65535 bytes. Since this is the maximum allowed ICMP packet
size, this can crash systems that attempt to reassemble the packet.
The BIG-IP system is hardened against this type of attack. However, if the
attack is against a virtual server with the Any IP feature enabled, then these
packets are sent on to the server. It is important that you apply the latest
update patches to your servers.
Land attack
A Land attack is a SYN packet sent with the source address and port the
same as the destination address and port.
The BIG-IP system is hardened to resist this attack. The BIG-IP system
connection table matches existing connections so that a spoof of this sort is
not passed on to the servers. Connections to the BIG-IP system are checked
and dropped if spoofed in this manner.
22 - 10
Teardrop
A Teardrop attack is carried out by a program that sends IP fragments to a
machine connected to the Internet or a network. The Teardrop attack
exploits an overlapping IP fragment problem present in some common
operating systems. The problem causes the TCP/IP fragmentation
re-assembly code to improperly handle overlapping IP fragments.
The BIG-IP system handles these attacks by correctly checking frame
alignment and discarding improperly aligned fragments.
Data attacks
The BIG-IP system can also offer protection from data attacks to the servers
behind the BIG-IP system. The BIG-IP system acts as a port-deny device,
preventing many common exploits by simply not passing the attack through
to the server.
For information about iRule examples for thwarting two common data
attacks, see Filtering out attacks with iRules, on page 22-7.
WinNuke
The WinNuke attack exploits the way certain common operating systems
handle data sent to the NetBIOS ports. NetBIOS ports are 135, 136, 137 and
138, using TCP or UDP. The BIG-IP system denies these ports by default.
On the BIG-IP system, do not open these ports unless you are sure your
servers have been patched against this attack.
Sub 7
The Sub 7 attack is a Trojan horse that is designed to run on certain common
operating systems. This Trojan horse allows the system to be controlled
remotely.
This Trojan horse listens on port 27374 by default. The BIG-IP system does
not allow connections to this port from the outside, so a compromised server
cannot be controlled remotely.
Do not open high ports (ports above 1024) without explicit knowledge of
what applications will be running on these ports.

Chapter 22
Back Orifice
Back Orifice is a Trojan horse that is designed to run on certain common
operating systems. This Trojan horse allows the system to be controlled
remotely.
This Trojan horse listens on UDP port 31337 by default. The BIG-IP system
does not allow connections to this port from the outside, so a compromised
server cannot be controlled remotely. Do not open high ports (ports above
1024) without explicit knowledge of what will be running on these ports.
22 - 12
23
• Introducing administrative domains
• Creating a partition
• Configuring user access to a partition
• Viewing, managing, and creating objects in a

partition
Introducing administrative domains

The BIG-IP® system includes a powerful authorization feature known as
administrative domains. Using the administrative domains feature, you
ensure that BIG-IP system grants administrative users exactly the right type
and amount of access to BIG-IP system resources. As a result, you can tailor
user access to resources to exactly fit the needs of your organization.
The administrative domains feature consists of several important
components:
◆ Partitions
Partitions represent containers for BIG-IP system objects. You can use
partitions to limit user access to certain objects. For more information on
partitions, see the TMOSTM Management Guide for BIG-IP® Systems.
◆ User accounts
User accounts grant administrative access to the BIG-IP system. The
properties that you set on a user account determine that user’s
permissions for administering BIG-IP system resources. For more
information on user accounts, see the TMOSTM Management Guide for
BIG-IP® Systems.
◆ User roles
One of the properties that you set on a user account is the user role. A
user role determines that user’s permissions, that is, the specific objects
that the user can access and the tasks that the user can perform. The user
roles that you can assign to a user account are: Administrator, Resource
Administrator, User Manager, Manager, Application Editor,
Application Security Policy Editor, Operator, or Guest.You can also
specify that a user account has no access to system resources. For
descriptions of these user roles, see the TMOSTM Management Guide
for BIG-IP® Systems.
◆ BIG-IP system objects
BIG-IP system objects are the entities that you can manage on the
BIG-IP system. Examples of objects that you can place into partitions are
pools, virtual servers, and profiles. When objects reside in partitions, you
can control the type and amount of administrative user access to those
objects. Most local traffic objects, as well as user accounts, can reside in
partitions. For descriptions of local traffic objects, see the Configuration
By combining all of these components, you can finely-tune administrative

access to many of your BIG-IP system resources. This chapter describes the
procedure for configuring the administration domains feature on the BIG-IP
system.

Chapter 23
Creating a partition
When you first install the BIG-IP system, a default partition exists, known
as partition Common. Partition Common contains certain objects that the
system automatically creates during installation, such as the admin user
account, the default profiles, and the pre-configured health and performance
monitors.
Some types of BIG-IP system objects reside in partitions, while others do
not. In general, most local-traffic objects reside in partitions. Network
objects, such as self IP addresses, VLANs, interfaces, and so on, cannot
reside in partitions.
At a minimum, most BIG-IP system user accounts have Read access to
objects in partition Common, regardless of their user roles. User accounts
that have the Administrator and Resource Administrator roles assigned
to them not only can view the objects in Common, but also can create,
modify, and delete objects in that partition.
While managing partition Common is useful as a starting point for
controlling user access to BIG-IP system objects, creating other partitions
offers a much finer degree of access control for administrative users.
The first step in giving a user the authority to manage objects in a specific
partition is to create the partition. Once you have created the partition, you
choose the user that you want to manage the objects in the new partition.
Finally, you modify the properties of that user’s account, to assign both the
appropriate user role and the partition that you want to authorize the user to
manage. Once you have granted authority to the user to manage the
partition, the user can then manage those objects in certain ways, such as
creating HTTP virtual servers and profiles, within that partition.
Important
To create a partition, you must have the Administrator or Resource
Administrator user role assigned to your user account. For the admin
account, the BIG-IP system automatically assigns the Administrator role.
To create a partition
1. On the main tab of the navigation pane, expand System, and click
Users,
The Users screen opens.
2. On the menu bar, click Partitions List.
This displays the list of partitions that you are allowed to view.
4. In the Name box, type a unique name for the partition, such as
partition_App1.
23 - 2
5. In the Description box, type a description of the partition, for

example, This partition contains objects for managing traffic for
the App1 application.
6. Click Create.
Configuring user access to a partition

The next step, after you create the partition, is to assign a user role to a user
account and give that user authority to manage the new partition. The level
of authority that the user has is determined by the user role you assign to the
user account. For example:
• If you assign a user role of Manager to the user account, the user can
perform all tasks related to the objects (except user account objects) in
the relevant partition, such as creating, modifying, or deleting those
objects.
• If you assign a user role of Operator to the account, the user is restricted
to enabling and disabling the nodes and pool members that reside in the
assigned partition.
• If you assign a user role of Guest to the account, the user can only view
the objects in the partition. The user cannot create, modify, or delete any
objects in the assigned partition.
You can configure user access to a partition either when you first create the
user account or when you modify the user account properties. The following
procedure shows how to configure partition access to an existing user
account.
Note
This procedure pertains to local user accounts only. For information on

configuring partition access to remote user accounts, see the TMOSTM
To configure user access to a partition

Users.
The User List screen opens.
2. In the Name column, click the user account name.
The properties screen for that user account opens.
3. To grant an access level other than No Access, use the Role setting
and select a user role.

Chapter 23
4. From the Partition Access list, select a partition name.

You can select a single partition name, or All.
Note: For user accounts to which you assign the Administrator
role, this value is automatically set to All.
5. Click Finished.
Viewing, managing, and creating objects in a partition

It is important to understand what happens when an administrative user logs
into the BIG-IP system and attempts to view, manage, or create BIG-IP
system objects.
Viewing and managing system objects

Once you have assigned user roles and partitions to user accounts, the users
see only those objects on the BIG-IP system to which they have been
granted access. They can view only those objects, and no others.
For example, suppose user Jane Smith logs into the system with her user
account (jsmith), and she has the role of Manager and is authorized to
manage partition A. In this case, she sees and can manage all objects
contained in partition A (excluding user account objects), and she can see
objects in partition Common. She has no access to other objects on the
system. This means that if she uses the Configuration utility to view a list of
virtual servers on the system, she sees and can manage virtual servers
contained in partition A, and she can see any virtual servers in partition
Common (if any). Similarly, if she views the list of pools, she sees and can
manage those pools contained in partition A, and she can see any pools in
partition Common (if any), and so on. She has no access (either Read or
Write access) to objects in other partitions.
By contrast, a user with a role such as Administrator can see and manage
all objects on the system, regardless of the partition in which the objects
reside. Users with this type of role can also actively select a specific
partition to view and manage.
23 - 4
Creating BIG-IP system objects

When a BIG-IP system user has a user role that grants the authority to create
objects on the BIG-IP system in a specific partition, the object that the user
creates automatically resides in the partition that the user is authorized to
manage.
For example, suppose that Barry Jones has the user account bjones, and this
user account is authorized to manage partition B. When Barry logs into the
BIG-IP system using the bjones account, any object that he creates
automatically resides in partition B.
Conversely, if a user with a role that does not allow object creation (such as
the Operator role) is logged into the system, no Create buttons appear on
the Configuration utility screens.
If the logged-in user has universal access (such as a user with the
Administrator role), the user can actively select the partition in which to
view, manage, or create a BIG-IP system object.

Chapter 23
23 - 6
24
Configuring Remote Authentication and
Authorization for Administrative Traffic
• Introducing remote authentication and

authorization for BIG-IP system user accounts
• Configuring the BIG-IP system to use remote

authentication of user accounts
• Configuring access control for BIG-IP system users
• Propagating remote authentication and

authorization data to multiple BIG-IP devices
Introducing remote authentication and authorization

for BIG-IP system user accounts
The BIG-IP® system includes a comprehensive solution for managing
BIG-IP administrative accounts on your network. With this solution, you
can:
◆ Use a remote server for storing BIG-IP user accounts
The BIG-IP system includes support for using a remote authentication
server to store BIG-IP system user accounts. After creating BIG-IP
system accounts on the remote server, you configure the BIG-IP system
to use remote user authentication, using either the browser-based
Configuration utility or the command-line-based bigpipe utility. For
more information, see Configuring the BIG-IP system to use remote
authentication of user accounts, on page 24-2.
◆ Assign group-based access control
The BIG-IP system includes a remoterole command within the bigpipe
utility. You use the remoterole command to specify access control data
on a group-wide basis for remotely-stored BIG-IP system user accounts.
The remoterole command can use the existing group definitions
assigned to those remote accounts to define access control properties
(privileges) for those users. The remoterole command not only provides
more granularity and flexibility in assigning user privileges, but also
removes any need to duplicate remote user accounts on the BIG-IP
system for the purpose of assigning those privileges. For more
information, see Configuring access control for BIG-IP system users, on
page 24-6.
◆ Propagate a set of authorization data to multiple BIG-IP devices
The BIG-IP system includes a tool for propagating user access control
data easily to multiple BIG-IP devices on the network. This access
control data includes user role specifications, partition access, and
BIG-IP system console access. To propagate user authorization data to
multiple BIG-IP devices, you use the Single Configuration File feature
within the bigpipe utility. For more information, see Propagating remote
authentication and authorization data to multiple BIG-IP devices, on
page 24-11.
By using all of the above features together, you can define user privileges on
a group-wise basis, and you can centrally manage all BIG-IP user accounts,
thus negating any need to create and manage user accounts separately on
each individual BIG-IP device on the network.

Chapter 24
Configuring the BIG-IP system to use remote

authentication of user accounts
Once you have created the accounts on the remote server, you must
configure the BIG-IP system to specify the type of remote authentication
server. This allows the BIG-IP system to access that remote data when
authenticating BIG-IP system users.
The BIG-IP system supports several types of authentication servers for
storing BIG-IP system administrative user accounts. The actual procedure
you use to specify the type of remote server you are using to store user
accounts differs depending on the server type:
• Lightweight Directory Access Protocol (LDAP) servers
• Microsoft® Windows® Active Directory™ servers
• Remote Authentication Dial-in User Service (RADIUS) servers
• Terminal Access Controller Access-Control System Plus (TACACS+)
servers
Specifying a remote LDAP or Active Directory server

You can configure the BIG-IP system to use an LDAP or Microsoft
Windows Active Directory server for authenticating BIG-IP system user
accounts, that is, traffic that passes through the management interface
(MGMT).
If the remote authentication server is set up to authenticate SSL traffic, there
is an additional feature that you can enable. You can configure the BIG-IP
system to perform the server-side SSL handshake that the remote server
would normally perform when authenticating client traffic. In this case,
there are some preliminary steps you must perform to prepare for remote
authentication using SSL.
To prepare for SSL-based remote authentication

On the BIG-IP system, import the certificates, using the Configuration
utility. For information on importing certificates, see the TMOSTM
Once you have performed these preliminary SSL tasks, you can enable SSL
as part of the procedure described in To specify a remote LDAP or Active
Directory server, following.
To specify a remote LDAP or Active Directory server

Users.
2. On the menu bar, click Authentication.
The Authentication screen opens.
3. Click Change.
24 - 2
4. From the User Directory list, select Remote - Active Directory or

Remote - LDAP.
5. In the Host box, type the IP address of the remote server.
6. For the Port setting, retain the default port number (389) or type a
new port number in the box.
This setting represents the port number that the BIG-IP system uses
to access the remote server.
7. In the Remote Directory Tree box, type the file location (tree) of
the user authentication database on the LDAP or Active Directory
server. At minimum, you must specify a domain component (that is,
dc=<value>).
8. For the Scope setting, retain the default value (Sub) or select a new
value.
This setting specifies the level of the remote server database that the
BIG-IP system searches for to authenticate users. For more
information on this setting, see the online help.
9. For the Bind setting, specify a user ID login for the remote server:
a) In the DN box, type the Distinguished Name for the remote user
ID.
b) In the Password box, type the password for the remote user ID.
c) In the Confirm box, re-type the password that you typed in the
Password box.
10. If you want to enable SSL-based authentication, click the SSL box
and, if necessary, configure the following settings.
Important: Be sure to specify the full path name of the storage
location on the BIG-IP system. For example, if the certificate is
stored in the directory /config/ssl/ssl.crt, type the value
/config/ssl/ssl.crt.
a) In the SSL CA Certificate box, type the name of a chain
certificate, that is, the third-party CA or self-signed certificate
that normally resides on the remote authentication server.
b) In the SSL Client Key box, type the name of the client SSL key.
Use this setting only in the case where the remote server requires
that the client present a certificate. If a client certificate is not
required, you do not need to configure this setting.
c) In the SSL Client Certificate box, type the name of the client
SSL certificate.
Use this setting only in the case where the remote server requires
that the client present a certificate. If a client certificate is not
required, you do not need to configure this setting.
11. Click Finished.

Chapter 24
Specifying a remote RADIUS server

You can configure the BIG-IP system to use a RADIUS server for
authenticating BIG-IP system user accounts, that is, traffic that passes
through the management interface (MGMT).
To specify a remote RADIUS server

Users.
3. Click Change.
4. From the User Directory list, select Remote - RADIUS.
5. From the Server Configuration list, select either Primary Only or
Primary & Secondary.
6. For the Primary setting, configure these settings:
a) In the Host box, type the IP address of the remote server.
b) In the Port box, retain the default port number (1812) or type a
new port number in the box.
This setting represents the port number that the BIG-IP system
uses to access the remote server.
c) In the Secret box, type the RADIUS secret.
d) In the Confirm box, re-type the secret that you typed in the
Secret box.
Note that the values of the Secret and Confirm settings must
match.
7. If you selected Primary & Secondary in step 5, configure the
Secondary setting.
8. Click Finished.
Specifying a TACACS+ server

You can configure the BIG-IP system to use a TACACS+ server for
authenticating BIG-IP system user accounts, that is, traffic that passes
through the management interface (MGMT).
To configure remote TACACS+ authentication

Users.
24 - 4
3. Click Change.
4. From the User Directory list, select Remote - TACACS+.
Additional settings appear on the screen.
6. In the Servers box, type an IP address and click Add.
7. In the Secret box, type the TACACS+ secret.
8. In the Confirm Secret box, re-type the TACACS+ secret that you
specified in the Secret box.
9. From the Encryption list, retain the default value (Enabled) or
select Disabled. This setting is optional.
10. In the Service Name box, type the name of a service.
11. In the Protocol Name box, type the name of a protocol. This setting
is optional.
12. From the Authentication list, select either Authenticate to first
server or Authenticate to each server until success.
13. From the Accounting Information list, select either Send to first
available server or Send to all servers.
14. From the Debug Logging list, select either Disabled or Enabled.
15. Click Finished.

Chapter 24
Configuring access control for BIG-IP system users

After specifying the type of remote server you are using to store user
accounts, you can configure authorization properties (that is, a user role,
partition access, and terminal access) for those accounts.
When you configured the BIG-IP system to indicate the type of remote
server being used to store BIG-IP system user accounts, the BIG-IP system
automatically created a single user entity on the BIG-IP system that
represents all remotely-stored accounts. Named Other External Users, this
user entity includes a default set of access control values. These
access-control values are:
• Role = No Access
• Partition = All
• Terminal Access = Disabled
Note
You can use the Configuration utility to change the values that the BIG-IP
system uses as the default values when assigning privileges to remote user
accounts.
If you want to use non-default values for all of the user accounts represented
by Other External Users, you have two options:
◆ Use the remoterole command (recommended).
This allows you to assign privileges on a group basis. Using the
remoterole command gives you flexibility and granularity in controlling
access to BIG-IP system resources by remote user accounts. For more
information, see Understanding the remoterole command, on page 24-7.
◆ Use the Configuration utility to assign privileges on a per-user basis.
Using the Configuration utility, you can assign non-default privileges to
any individual user account that is stored remotely. If you do this, you
must first duplicate the user account on the BIG-IP system. For more
information, see the TMOSTM Management Guide for BIG-IP®
Systems.
Note
For detailed descriptions of the user roles that you can assign to accounts,
see the TMOSTM Management Guide for BIG-IP® Systems.
24 - 6
Understanding the remoterole command

The remoterole command assigns privileges to remote user accounts by
mapping a vendor-specific attribute (such as an LDAP attribute for defining
a user group) to a set of access-control properties that you define. These
access-control properties are:
• A user role
• Console access or restriction
• A user partition assignment
By mapping a remote authentication server attribute to a set of

access-control properties, you can easily define a different set of
access-control properties for each group of BIG-IP user accounts stored on a
remote authentication server.
Without the remoterole command, you must either assign the same
privileges to all remotely-stored user accounts, or you must individually
duplicate each remote user account on the BIG-IP system to assign unique
privileges to that account.
Once you have used the remoterole command, you can use the Single
Configuration File feature to propagate that access control data to other
BIG-IP devices on the network. For more information, see Propagating
remote authentication and authorization data to multiple BIG-IP devices, on
page 24-11.
Using the remote role command

You use the remoterole command to assign group-wide privileges to
remote user accounts. The command is available from within the bigpipe
utility. The following section shows the syntax for the remoterole
command, and shows an example of its use, with the resulting access control
data.
To assign privileges to remote user accounts

Type the bigpipe remoterole command, using the following syntax:
bigpipe remoterole role info <user group> attribute (<string> | none) console \
(enable | disable) line order <number> role <user role> user partition \
(<string> | none)
For example, suppose that your BIG-IP system user accounts are stored on
an LDAP remote authentication server and that those accounts are divided
between the groups BigIPOperatorsGroup and BigIPManagersGroup. In
this case, you can type the following remoterole command sequence to
define the privileges for those groups:
bigpipe remoterole role info BigIPOperatorsGroup { attribute
"memberOF=cn=BigIPOperatorsGroup,cn=users,dc=dev,dc=net" console disable line order 1
role operator user partition App_A } role info BigIPManagersGroup { attribute
"MemberOF=cn=BigIPManagersGroup,cn=users,dc=dev,dc=net" console enable line order 2
role manager user partition App_B }

Chapter 24
Table 24.1 shows the resulting configuration, where each group has a set of
privileges assigned to it:
Group Name Assigned Privileges
BigIPOperatorsGroup console disable

role operator
user partition App_A
BigIPManagersGroup console enable

role manager
user partition App_B
Table 24.1 Privilege assignments resulting from the remoterole command
Note
After you use the remoterole command to configure group-based privileges,

any user who logs on to the BIG-IP system and does not have a group
assignment on the remote server is denied access to the BIG-IP system.
Also, whenever you change the user role or partition assignment (or both)
for a remote account, all remote users are immediately logged off the
system, including those logged in as Other External Users.
Using variable substitution

Some BIG-IP environments might be using a large number of administrative
partitions and user roles, and therefore require several different
combinations of user roles and partitions. For example, if a BIG-IP system
is configured to use ten administrative partitions and five different user
roles, the system could require up to 50 combinations of partitions and user
roles, making use of the remoterole command unwieldy.
To mitigate this problem, the remoterole command supports the use of
variable substitution. That is, for the role, user partition, and console
arguments of the remoterole command, you can specify %<variable> for
the value.
Example
Suppose that you configure a remote RADIUS authentication server to
return a vendor-specific attribute and three variables, and their values.
• F5-LTM-User-Info-1 = DC1
• F5-LTM-User-Role = 400
Note: See Considerations for variable evaluation, on page 24-9 for more
information.
• F5-LTM-User-Partition = App_C
• F5-LTM-User-Console = 1
24 - 8
The remoterole command can use the first attribute (F5-LTM-User-Info-1)

on which to match. The command can then read the role, user partition,
and console values from the remaining three variables, rather than you
specifying them explicitly. The command does this when you specify each
of the three variables on the command line, preceded by the string %, as
arguments.
The following shows a sample use of the remoterole command. This
particular command matches on the vendor-specific attribute
F5-LTM-User-Info-1 and then assigns the access-control values listed
above (Operator, App_C, and 1) to any user accounts that are part of
Datacenter 1 (DC1):
b remoterole role info DC1 { attribute "F5-LTM-User-Info-1=DC1"
console "%F5-LTM-User-Console" role "%F5-LTM-User-Role" user partition
"%F5-LTM-User-Partition" line order 1 }
Considerations for variable evaluation

When using variable substitution with the remoterole command, you should
consider these rules that the system follows:
◆ Incorrect variable values
If the value of a variable is incorrect, the user is not authorized. For
example, if the %F5-LTM-User-Partition variable evaluates to p1, but
the p1 partition does not exist or the partition is named P1 instead of p1,
the user receives an error message when attempting to log on.
◆ The role variable
The variable that you specify on the command line with the role
argument (for example, %F5-LTM-User-Role) must evaluate to one of
these values:
• 0 (Administrator)
• 20 (Resource Administrator)
• 40 (User Manager)
• 100 (Manager)
• 300 (Application Editor)
• 400 (Operator)
• 700 (Guest)
• 800 (Application Security Policy Editor)
• 900 (None)
◆ Missing variables
When a variable does not exist in the authentication attributes, the system
assigns these privileges to the user account:
• Role = No Access
• Partition = None
• Terminal access = Disabled

Chapter 24
◆ No matching attributes
If the user is properly authenticated but there is no match on any of the
remoterole attributes, the system assigns the default privileges. For more
information on default privileges for remote user accounts, see
Configuring access control for BIG-IP system users, on page 24-6.
24 - 10
Propagating remote authentication and

authorization data to multiple BIG-IP devices
The final step in configuring remote authentication and authorization for
BIG-IP administrative users is to propagate the BIG-IP authentication and
authorization configuration data to the other BIG-IP devices on the network.
You perform this step using the bigpipe export and bigpipe import
commands, which are part of the Single Configuration File feature. The
bigpipe export command exports BIG-IP configuration data to a special
.scf file (SCF). The bigpipe import command uses the data in that SCF to
configure other BIG-IP devices.
If you performed the previous task (using the remoterole command to
define access control data for remote user accounts), any subsequent SCF
that you create using the bigpipe export command contains those access
control definitions. You can then use the bigpipe import command to
propagate that access control data to the other BIG-IP devices on the
network.
The following procedures describe how to create an SCF and import the
SCF onto another BIG-IP device. For a more detailed description of the SCF
feature and how to use it, see the TMOSTM Management Guide for BIG-IP®
Systems.
To create an SCF
1. Access the bigpipe shell.
2. Run the command export, and include a name for the SCF, for
example:
bp> export myConfiguration053107
The system creates the file, myConfiguration053107.scf, in the

/var/local/scf directory. To create the SCF in another location,
specify a full path for the file. For example, the command export
/config/myConfiguration creates the SCF in the /config directory.
To use an SCF to configure another BIG-IP system

1. Copy the SCF that you created in the previous section to a location
on your network that you can access from the system that you want
to configure.
2. Edit the SCF to reflect the management routing and special
passwords of the BIG-IP system that you want to configure:
a) Open the SCF in an editor.
b) Where necessary, change the values of the management IP
address, network mask, management default route, self IP
addresses, virtual server IP addresses, routes, default routes, and
host name fields to the values for the new system.

Chapter 24
c) If necessary, change the passwords for the root and admin

accounts using the command user <name> password none
newpassword <password>.
Important: When configuring a unit that is part of a redundant
system using the SCF from the other unit in the system, do not
modify the root and admin accounts. These accounts must be
identical on both units of a redundant system.
d) Save the edited SCF.
3. On the BIG-IP system that you want to configure, use the import
command to import the SCF:
bp> import myConfiguration
The system saves a backup of the running configuration in the

/var/local/scf directory, and then resets the running configuration
with the configuration contained in the SCF you are importing.
4. To save the new running configuration to the stored configuration,
use the save all command.
The system saves the running configuration to the stored
configuration.
24 - 12
25
Configuring Remote Authentication for
Application Traffic
• Introducing remote authentication for application

traffic
• Configuring authentication that uses a remote

LDAP or Active Directory server

RADIUS server

TACACS+ server
• Configuring SSL-based authorization using a remote

LDAP server
• Configuring SSL certificate revocation using an

OCSP responder
• Configuring a CRLDP authentication module

Introducing remote authentication for application

traffic
As an administrator in a large computing environment, you might prefer to
store your site’s user accounts remotely, on a dedicated authentication
server. Fortunately, you can set up the BIG-IP® system to use this server to
authenticate any network traffic passing through the BIG-IP system. Remote
authentication servers typically use these protocols:
• Lightweight Directory Access Protocol (LDAP)
• Remote Authentication Dial-in User Service (RADIUS)
• TACACS+ (derived from Terminal Access Controller Access Control
System [TACACS])
• Online Status Certificate Protocol (OCSP)
• Certificate Revocation List Distribution Point (CRLDP)
Using a remote authentication server, the BIG-IP system can authenticate

two types of network traffic:
• Application traffic that is slated for load balancing
This type of traffic passes through a virtual server and through Traffic
Management Microkernel (TMM) interfaces. To configure remote
authentication for this type of traffic, you must create a configuration
object and a profile that correspond to the type of authentication server
you are using to store your user accounts. For example, if your remote
authentication server is an LDAP server, you create an LDAP
configuration object and an LDAP profile. For more information, see the
remainder of this chapter, click the Help tab in the Configuration utility,
or see the Configuration Guide for BIG-IP® Local Traffic
Management.
• Management traffic for administering the BIG-IP system
This type of traffic does not pass through a virtual server, and instead
passes through the management interface (MGMT). You configure
remote authentication for this type of traffic when you create your
administrative user accounts. For more information, see Chapter 24,
Configuring Remote Authentication and Authorization for Administrative
Traffic in this guide, and the TMOSTM Management Guide for BIG-IP®
Systems.
When you want to use a remote server to authenticate application traffic
passing through the BIG-IP system, you can use one of these server types:
• An LDAP or Active Directory server
• A RADIUS server
• A TACACS+ server
• An SSL OCSP responder
• A CRLDP server
• A Kerberos server

Chapter 25
To configure remote user authentication for application traffic, you must

create both a configuration object and an authentication profile. Each
authentication server type requires a different configuration object and
profile. For example, to configure the BIG-IP system to use an LDAP
authentication server, you must create an LDAP configuration object and a
custom LDAP profile.
When implementing a RADIUS, SSL OCSP, or CRLDP authentication
module, you must also create a third type of object. For RADIUS and
CRLDP authentication, this object is referred to as a server object. For SSL
OCSP authentication, this object is referred to as an OCSP responder.
Note
To configure Kerberos authentication, see Chapter 26, Configuring

Kerberos Delegation.
Configuring authentication that uses a remote LDAP

or Active Directory server
You can configure the BIG-IP system to use an LDAP or Active Directory
server for authenticating traffic that passes through the TMM interfaces of
the BIG-IP system. By default, client credentials are based on basic HTTP
authentication (that is, user name and password). However, you can also
enable SSL authentication, which is based on SSL keys and certificates.
To configure LDAP or Active Directory authentication for application
traffic, you complete these tasks:
• Create an LDAP-type configuration object.
• Create an LDAP-type authentication profile.
• Modify a virtual server that is configured to manage HTTP traffic.
Creating an LDAP configuration object

The first task in configuring LDAP-based or Active Directory-based remote
authentication on the BIG-IP system is to create a custom LDAP
configuration object, using the Configuration utility. An LDAP
configuration object specifies information that the BIG-IP system needs to
perform the remote authentication. For example, the configuration object
specifies the remote LDAP tree that the system uses as the source location
for the authentication data.
If the remote authentication server uses LDAP or Active Directory and is set
up to authenticate SSL authentication traffic, there is an additional feature
that you can enable. You can configure the BIG-IP system to perform the
server-side SSL handshake that the remote server would normally perform
when authenticating client traffic. In this case, there are some preliminary
tasks you must perform to prepare for remote authentication using SSL.
25 - 2
To prepare for SSL-based remote authentication

1. Convert the Certificate Authority (CA) or self-signed certificates to
PEM format.
2. On the BIG-IP system, import the certificates, using the
Configuration utility.
You can store the certificates in any location on the BIG-IP system.
Once you have performed these preliminary SSL tasks, you can enable
SSL-based remote server authentication. You do this as part of creating the
LDAP configuration object, which includes these Advanced settings:
• SSL CA Certificate
This represents the name of the certificate that normally resides on the
remote authentication server.
• SSL Client Key
This represents the name of the SSL key that the client sends to the
BIG-IP system. This key specification is only necessary when the remote
server requires a client certificate.
• SSL Client Certificate
This represents the name of the SSL certificate that the client sends to the
BIG-IP system. This certificate specification is only necessary when the
remote server requires a client certificate.
Important
When specifying key and certificate files while creating an LDAP
configuration object, be sure to specify the full path name of the storage
location on the BIG-IP system. For example, if the certificate is stored in the
directory /config/ssl/ssl.crt, type the value /config/ssl/ssl.crt.
After you create the custom LDAP configuration object, you create a
custom LDAP profile, and then assign the custom profile to an HTTP virtual
server.

Chapter 25
To create a custom LDAP configuration object

click Profiles.
2. From the Authentication menu, choose Configurations.
The Authentication Configurations screen opens.
The New Authentication Configuration screen opens.
user role does not grant you permission to create an LDAP
configuration object.
4. In the Name box, type a unique name for the configuration object,
such as my_ldap_config.
5. From the Type list, select LDAP.
This displays the configuration object settings that you can
configure.
6. For the Configuration area, select Basic or Advanced.
Selecting Advanced causes additional settings to appear on the
screen.
7. In the Remote LDAP Tree box, type the file location (tree) of the
user authentication database on the LDAP or Active Directory
server.
At a minimum, you must specify a domain component (that is,
dc=<value>).
8. For the Hosts setting:
a) Type the IP address of the remote LDAP or Active Directory
server.
b) Click Add.
The IP address appears in the text window.
9. Retain or change the Service Port value.
10. Retain or change the LDAP Version value.
11. If you selected a basic configuration in step 6, click Finished. If you
selected an advanced configuration in step 6, configure the
remaining settings and then click Finished.
Note
For information about enabling SSL authentication, see the beginning of

this section, Creating an LDAP configuration object, on page 25-2.
25 - 4
Creating an LDAP authentication profile

The next task in configuring LDAP-based or Active Directory-based remote
authentication on the BIG-IP system is to create a custom LDAP profile. An
LDAP profile specifies information such as the LDAP authentication mode
(Enabled or Disabled), and the name of the LDAP configuration object you
previously created.
After you create the custom LDAP profile, you assign the custom profile
and a default iRule to a virtual server.
To create a custom LDAP profile

click Profiles.
2. From the Authentication menu, choose Profiles.
The Authentication Profiles screen opens.
The New Authentication Profile screen opens.
user role does not grant you permission to create an LDAP profile.
4. In the Name box, type a unique name for the profile, such as
my_ldap_profile.
5. From the Type list, select LDAP.
This displays the profile settings that you can configure.
6. From the Parent Profile list, verify that ldap is selected
This causes the new profile to inherit its default configuration values
from the default profile, named ldap.
7. From the Configuration list, select the name of the LDAP
configuration object that you previously created.
8. For all remaining settings, retain the default values.
9. Click Finished.
Modifying a virtual server for LDAP authentication

The final task in the process of implementing authentication using a remote
LDAP server is to assign the custom LDAP profile and a default LDAP
authentication iRule to a virtual server that is configured to process HTTP
traffic (that is, a virtual server to which an HTTP profile is assigned).
Note
The virtual server to which you assign the profiles and the iRule must be a
Standard type of virtual server.

Chapter 25
To modify a virtual server for LDAP authentication

2. In the Name column, click the name of a Standard-type virtual
server to which an HTTP profile is assigned.
This displays the properties of that virtual server.
This displays additional properties.
4. From the Authentication Profiles list, from the Available box
select the name of the custom LDAP profile that you previously
created, and click the Move button (<<).
This moves the profile name to the Enabled box.
Note: If the Authentication Profiles list is unavailable for
modification, this indicates that your user role does not grant you
permission to modify a virtual server.
5. Click Update.
25 - 6
Configuring authentication that uses a remote

RADIUS server
A RADIUS authentication module is a mechanism for authenticating client
connections passing through a BIG-IP system. You use this module when
your authentication data is stored on a remote RADIUS server. In this case,
client credentials are based on basic HTTP authentication (that is, user name
and password).
To implement a RADIUS authentication module, you must configure the
BIG-IP system to access data on a remote RADIUS server. To do this, you
must:
• Create one or more high-level RADIUS server objects.
• Create a RADIUS configuration object.
• Create a RADIUS profile.
• Modify a virtual server to assign the RADIUS profile to it.
Creating a RADIUS server object

The first task in configuring RADIUS-based remote authentication on the
BIG-IP system is to create a custom RADIUS server object. After you create
the custom RADIUS server object, you create a custom RADIUS
configuration object and a custom RADIUS profile, and then assign the
custom profile and a default iRule to an HTTP virtual server.
To create a RADIUS server object

1. On the Main tab in the navigation page, expand Local Traffic, and
click Profiles.
The Profiles screen opens.
2. From the Authentication menu, choose RADIUS Servers.
This displays the RADIUS Server List screen.
3. In the upper right corner of the screen, click Create.
This displays the RADIUS Server screen.
user role does not grant you permission to create a RADIUS server
object.
4. For the Name setting, type a unique name for the RADIUS server
object, such as my_radius_server.
5. For the Server setting, type a host name or IP address for the remote
RADIUS server.
6. For the Secret and Confirm Secret settings, type the RADIUS
secret.

Chapter 25
7. Retain the default Timeout value.

8. Click Finished.
Creating a RADIUS configuration object

The next task in configuring RADIUS-based remote authentication on the
BIG-IP system is to create a custom RADIUS configuration object. A
RADIUS configuration object specifies information that the BIG-IP system
needs to perform the remote authentication.
After you create the custom RADIUS configuration object, you create a
custom RADIUS profile, and then assign the custom profile and a default
iRule to an HTTP virtual server.
To create a RADIUS configuration object

1. On the Main tab, expand Local Traffic, and click Profiles.
This displays the Authentication Configurations screen.
This displays the New Authentication Configuration screen.
user role does not grant you permission to create a RADIUS
4. For the Name setting, specify a unique name for the configuration
object, such as my_radius_config.
5. For the Type setting, select RADIUS.
The screen expands to show several settings.
6. From the Configuration list, select Basic or Advanced.
screen.
7. For the RADIUS Servers setting, from the Available box select the
IP address of the RADIUS server and click the Move button (<<).
This moves the server name to the Selected box.
8. In the Client ID box, type a NAS-Identifier string.
Required for RADIUS authentication, the NAS-Identifier string
appears in Access-Request packets and identifies the NAS that
originates the packet. An example of a NAS-Identifier string is a
fully-qualified domain name (FQDN).
25 - 8
Creating a RADIUS profile

The next task in configuring RADIUS-based remote authentication on the
BIG-IP system is to create a custom RADIUS profile. A RADIUS profile
specifies information such as the RADIUS authentication mode (Enabled or
Disabled), and the name of the RADIUS configuration object you
previously created.
After you create the profile, you assign the custom profile and a default
To create a custom RADIUS profile

click Profiles.
user role does not grant you permission to create a RADIUS profile.
4. From the Type list, select RADIUS.
my_radius_profile.
6. From the Parent Profile list, verify that radius is selected.
This causes the new profile to inherit configuration values from the
default profile, named radius.
7. From the Configuration list, select the name of the RADIUS
9. Click Finished.
Modifying a virtual server for RADIUS authentication

RADIUS server is to assign the custom RADIUS profile to a virtual server
that is configured to process HTTP traffic (that is, a virtual server to which
an HTTP profile is assigned).
Note
The virtual server to which you assign an authentication profile must be a


Chapter 25
To modify a virtual server for RADIUS authentication

2. In the Name column, click the name of a virtual server.
select the name of the custom RADIUS profile that you previously
5. Click Update.
25 - 10
Configuring authentication that uses a remote

TACACS+ server
You can configure the BIG-IP system to use a TACACS+ server for
authenticating traffic that passes through the TMM interfaces of the BIG-IP
system. In this case, client credentials are based on basic HTTP
authentication (that is, user name and password).
To configure TACACS+ authentication for application traffic, you complete
these tasks:
• Create a TACACS+-type configuration object.
• Create a TACACS+-type authentication profile.
• Modify a virtual server configured to manage HTTP traffic.
Creating a TACACS+ configuration object

The first task in configuring TACACS+ remote authentication on the
BIG-IP system is to create a custom TACACS+ configuration object. A
TACACS+ configuration object specifies information that the BIG-IP
system needs to perform the remote authentication. For example, the
configuration object specifies the IP address of the remote TACACS+
server.
To create a custom TACACS+ configuration object

click Profiles.
user role does not grant you permission to create a TACACS+
4. From the Type list, select TACACS+.
configure.
such as my_tacacs_config.
screen.

Chapter 25
7. In the Servers box, type the IP address of the remote TACACS+

server and click Add.
The IP address appears in the text box.
8. For the Hosts setting, type the IP address of the remote LDAP or
Active Directory server and click Add.
9. In the Secret box, type a TACACS+ secret. key to be used for
encrypting or decrypting packets sent to or from the server.
10. In the Confirm Secret box, re-type the secret key you typed in the
Secret box.
Once you have created the TACACS+ configuration object, you must create
a custom TACACS+ profile and modify an HTTP virtual server.
Creating a TACACS+ profile

The next task in configuring TACACS+-based remote authentication on the
BIG-IP system is to create a custom TACACS+ profile. After you create the
profile, you assign the custom profile, the default http profile, and a default
iRule to a virtual server.
To create a custom TACACS+ profile

click Profiles.
user role does not grant you permission to create a TACACS+
profile.
4. From the Type list, select TACACS+.
my_tacacs_profile.
6. From the Parent Profile list, verify that tacacs is selected.
from the default profile, named tacacs.
25 - 12
7. From the Configuration list, select the name of the TACACS+

9. Click Finished.
Modifying a virtual server for TACACS+ authentication

TACACS+ server is to assign the custom TACACS+ profile and an existing
default authentication iRule to a virtual server that is configured to process
HTTP traffic (that is, a virtual server to which an HTTP profile is assigned).
Note
The virtual server to which you assign an authentication profile and iRule
must be a Standard type of virtual server.
To modify a virtual server for TACACS+ authentication

select the name of the custom TACACS+ profile that you
previously created, and click the Move button (<<).
5. Click Update.

Chapter 25
Configuring SSL-based authorization using a remote

LDAP server
With the SSL Client Certificate LDAP authentication module, you can use a
remote LDAP server to impose access control on application traffic. The
module bases this access control on SSL certificates and roles that you
specify.
To configure SSL Client Certificate LDAP-based authentication for
application traffic, you complete these tasks:
• Create an SSL Client Certificate LDAP-type configuration object.
• Create an SSL Client Certificate LDAP-type authentication profile.
• Modify a virtual server that is configured to manage HTTP traffic.
Creating an SSL CLient Certificate LDAP configuration object

The first task in configuring SSL Client Certificate LDAP-based remote
authentication on the BIG-IP system is to create a custom SSL Client
Certificate LDAP configuration object, using the Configuration utility. An
SSL Client Certificate LDAP configuration object specifies information
that the BIG-IP system needs to perform the remote authentication.
After you create the custom SSL Client Certificate LDAP configuration
object, you create a custom SSL Client Certificate LDAP profile, and then
assign the custom profile to an SSL virtual server.
To create a custom SSL Client Certificate LDAP

configuration object
click Profiles.
user role does not grant you permission to create an SSL Client
Certificate LDAP configuration object.
such as my_ssl_client_cert_ldap_config.
5. From the Type list, select SSL Client Certificate LDAP.
configure.
screen.
25 - 14
7. For the Hosts setting:

a) Type the IP address of the remote LDAP.
b) Click Add.
8. From the Search Type list, select User, Certificate Map, or
Certificate.
9. In the User Base DN box, type the search base for the sub tree that
the LDAP server uses to perform a User or Certificate search type.
10. In the User Key box, type the attribute that the LDAP server uses to
designate a user ID.
Creating an SSL Client Certificate LDAP authentication profile

The next task in configuring LDAP-based remote authentication on the
BIG-IP system is to create a custom SSL Client Certificate LDAP profile.
An SSL Client Certificate LDAP profile specifies information such as the
the name of the LDAP configuration object you previously created.
After you create the custom SSL Client Certificate LDAP profile, you
assign the custom profile and a default iRule to a virtual server.
To create a custom SSL Client Certificate LDAP profile

click Profiles.
user role does not grant you permission to create an SSL Client
Certificate LDAP profile.
my_ssl_client_cert_ldap_profile.
5. From the Type list, select SSL Client Certificate LDAP.
6. From the Parent Profile list, verify that sol ldap is selected
from the default profile, named ldap.

Chapter 25
7. From the Configuration list, select the name of the LDAP

9. Click Finished.
Modifying a virtual server for SSL Client Certificate LDAP

authorization
The final task in the process of implementing authorization using a remote
LDAP server is to assign the custom SSL Client Certificate LDAP profile
and a default LDAP authentication iRule to a virtual server that is
configured to process HTTP traffic (that is, a virtual server to which an
HTTP profile is assigned).
Note
The virtual server to which you assign the profiles and the iRule must be a
To modify a virtual server for SSL Client Certificate LDAP

authorization
2. In the Name column, click the name of a Standard-type virtual
server to which an HTTP server profile is assigned.
select the name of the custom SSL CLient Certificate LDAP profile
that you previously created, and click the Move button (<<).
5. Click Update.
25 - 16
Configuring SSL certificate revocation using an OCSP

responder
An SSL OCSP authentication module is a mechanism for authenticating
client connections passing through a local traffic management system. More
specifically, an SSL OCSP authentication module checks the revocation
status of an SSL certificate, as part of authenticating that certificate.
To implement an OCSP authentication module, you must:
• Create one or more high-level OCSP responder objects.
• Create an SSL OCSP configuration object.
• Create an SSL OCSP profile.
• Modify a virtual server to assign the SSL OCSP profile to it.
Creating an SSL OCSP responder object

The first task in configuring SSL OCSP-based remote authentication on the
BIG-IP system is to create a custom SSL OCSP responder object. An SSL
OCSP responder object is an object that you create that includes a URL for
an external SSL OCSP responder. You must create a separate SSL OCSP
responder object for each external SSL OCSP responder.
After you create the custom SSL OCSP responder object, you create a
custom SSL OCSP configuration object and a custom SSL OCSP profile,
and then assign the custom profile and a default iRule to an HTTP virtual
server.
To create an SSL OCSP responder object

click Profiles.
2. From the Authentication menu, choose OCSP Responders.
This displays the OCSP Responders list screen.
This displays the New OCSP Responder screen.
user role does not grant you permission to create an SSL OCSP
responder object.
4. For the Name setting, type a unique name for the OCSP responder
object, such as my_ocsp_responder.
5. Type or retain all configuration values.
6. Click Finished.

Chapter 25
Creating an SSL OCSP configuration object

The next task in configuring SSL OCSP-based remote authentication on the
BIG-IP system is to create a custom SSL OCSP configuration object. An
SSL OCSP configuration object specifies information that the BIG-IP
system needs to perform the remote authentication.
After you create the custom SSL OCSP configuration object, you create a
custom SSL OCSP profile, and then assign the custom profile and a default
To create an SSL OCSP configuration object

object, such as my_ocsp_config.
5. For the Type setting, select SSL OCSP.
6. For the Responders setting, from the Available box select the name
of an OCSP responder object and click the Move button (<<).
This moves the name to the Selected box.
7. Repeat the previous step for each responder object.
8. Click Finished.
Creating an SSL OCSP profile

The next task in configuring SSL OCSP-based remote authentication on the
BIG-IP system is to create a custom SSL OCSP profile. An SSL OCSP
profile specifies information such as the name of the SSL OCSP
configuration object you previously created.
25 - 18
To create a custom SSL OCSP profile

click Profiles.
profile.
4. From the Type list, select SSL OCSP.
my_ssl_ocsp_profile.
6. From the Parent Profile list, verify that ssl_ocsp is selected.
default profile, named ssl_ocsp.
7. From the Configuration list, select the name of the SSL OCSP
9. Click Finished.
Modifying a virtual server for SSL OCSP authentication

The final task in the process of implementing SSL OCSP authentication is to
assign the custom SSL OCSP profile to a virtual server that is configured to
process HTTP traffic (that is, a virtual server to which an HTTP profile is
assigned).
Note

To modify a virtual server for SSL OCSP authentication


Chapter 25

select the name of the custom SSL OCSP profile that you previously
5. Click Update.
Configuring a CRLDP authentication module

A Certificate Revocation List Distribution Point (CRLDP) authentication
module is a mechanism for authenticating client connections passing
through a local traffic management system. More specifically, a CRLDP
authentication module checks the revocation status of an SSL certificate, as
part of authenticating that certificate.
To implement a CRLDP authentication module, you must:
• Create one or more high-level CRLDP server objects.
• Create a CRLDP configuration object.
• Create a CRLDP profile.
• Modify a virtual server to assign the CRLDP profile to it.
Creating a CRLDP server object

The first task in configuring CRLDP-based remote authentication on the
BIG-IP system is to create a custom CRLDP server object. A CRLDP server
object is an object that you create that includes a URL for an external
CRLDP server. You must create a separate CRLDP server object for each
external CRLDP responder.
After you create the custom CRLDP object, you create a custom CRLDP
configuration object and a custom CRLDP profile, and then assign the
custom profile and a default iRule to an HTTP virtual server.
To create a CRLDP responder object

1. On the Main tab, expand Local Traffic.
2. Click Profiles.
3. From the Authentication menu, choose CRLDP Servers.
This displays the CRLDP Servers list screen.
25 - 20

This displays the New CRLDP Server screen.
user role does not grant you permission to create a CRLDP
responder object.
5. For the Name setting, type a unique name for the CRLDP server
object, such as my_crldp_server.
6. Type or retain all configuration values.
7. Click Finished.
Creating a CRLDP configuration object

The next task in configuring CRLDP-based remote authentication on the
BIG-IP system is to create a custom CRLDP configuration object. A
CRLDP configuration object specifies information that the BIG-IP system
needs to perform the remote authentication.
After you create the custom CRLDP configuration object, you create a
custom CRLDP profile, and then assign the custom profile and a default
To create a CRLDP configuration object

user role does not grant you permission to create a CRLDP
object, such as my_crldp_config.
5. For the Type setting, select CRLDP.
6. For the Servers setting, from the Available box select the name of a
CRLDP server object and click the Move button (<<).
This moves the name to the Selected box.
7. Repeat the previous step for each server object.
8. Click Finished.

Chapter 25
Creating a CRLDP profile

The next task in configuring CRLDP-based remote authentication on the
BIG-IP system is to create a custom CRLDP profile. A CRLDP profile
specifies information such as the name of the CRLDP configuration object
you previously created.
To create a custom CRLDP profile

click Profiles.
user role does not grant you permission to create a CRLDP profile.
4. From the Type list, select CRLDP.
my_crldp_profile.
6. From the Parent Profile list, verify that ssl_crldp is selected.
default profile, named ssl_crldp.
7. From the Configuration list, select the name of the CRLDP
9. Click Finished.
25 - 22
Modifying a virtual server for CRLDP authentication

The final task in the process of implementing CRLDP authentication is to
assign the custom CRLDP profile to a virtual server that is configured to
process HTTP traffic (that is, a virtual server to which an HTTP profile is
assigned).
Note

To modify a virtual server for CRLDP authentication

select the name of the custom CRLDP profile that you previously
5. Click Update.

Chapter 25
25 - 24
26
• Introducing Kerberos delegation infrastructure
• Configuring the BIG-IP system for Kerberos

delegation
• Creating the Kerberos delegation configuration
• Authenticating Client Traffic

Introducing Kerberos delegation infrastructure

The Kerberos delegation feature provides the ability to authenticate client
traffic with Microsoft® Windows® Integrated Authentication. You can also
set cross-realm authentication if the two realms have a trust relationship.
Table 26.1 shows the infrastructure requirements for Kerberos delegation.
Infrastructure Configuration Requirements
Primary domain controller This Kerberos delegation scenario uses a Microsoft

primary domain controller (PDC)
The time on the PDC must be synchronized with the
time on the client and web servers.
The primary domain controller must be a DNS server
and have knowledge of the web servers.
Client Client machines must be in the domain.

The time on the client must be synchronized with the
time on the web servers and PDC.
The client must be using Windows Internet Explorer
version 3.x or later.
Web server The Web servers must be set up to use Windows

Integrated Authentication with anonymous access
disabled. Please refer to the Microsoft
documentation for more information about load
balancing Kerberos web servers if you plan to set up
more than one server in your server pool.
The time on the web server must be synchronized
with the time on the client and PDC.
BIG-IP system The BIG-IP system must be in a domain with the

PDC.
The BIG-IP system must be able to process secure
traffic between the client and its web server.
The BIG-IP system must use a DNS server that
knows about the PDC.
The BIG-IP system must have its time synchronized
with the PDC.
Table 26.1 Infrastructure requirements for Kerberos delegation

Chapter 26
Configuring the BIG-IP system for Kerberos

delegation
Configuring the BIG-IP® system for Kerberos delegation requires you to
complete these tasks:
• Add the DNS server to the BIG-IP system.
• Join the BIG-IP system to the trusted domain.
• Set up the Kerberos delegation configuration.
Adding a DNS server to the BIG-IP system

The first step for configuring the BIG-IP system for Kerberos delegation is
to add the DNS server to the BIG-IP system. This section describes how to
test the DNS server from the BIG-IP system, and how to add the DNS server
to the BIG-IP system from either the Configuration utility or the command
line interface.
To test the DNS server before you define it on the BIG-IP

system
Before you configure the DNS server on the BIG-IP system, you can test the
DNS server(s) that you want to define on the BIG-IP system by typing the
following command at the Linux prompt:
dig @<DNS_Server_IP_Address>
If the test is successful, the system displays a list of the root name servers.
To configure DNS name resolution using the Configuration

utility
Configuration.
2. From the Device menu, choose DNS.
The DNS screen opens.
3. Locate the DNS Lookup Server List setting.
4. In the Address box, type the DNS server IP address.
5. Click Add.
6. Click Update.
26 - 2
To configure DNS name resolution from the command line

1. Log on to the command line.
2. Define the DNS server(s) on the BIG-IP system by typing the
following command:
bigpipe dns nameservers <DNS_Server_IP_Address> add
For example, if you want to add the DNS name server IP addresses
192.168.10.20 and 192.168.10.22 to the BIG-IP system, type the
following command:
bigpipe dns nameservers 192.168.10.20 192.168.10.22 add
3. Save the changes by typing the following command:

bigpipe save
The local /etc/resolv.conf file is now configured with the following

entries:
nameserver 192.168.10.20
nameserver 192.168.10.22
Joining the BIG-IP system to the trusted domain

After you have added the DNS server to the BIG-IP system, you can add the
BIG-IP system to the trusted domain. Use the domaintool command to add
the BIG-IP system to the trusted domain.
You use the domaintool command to add the system to the domain, where
<domainname> is the name of the domain in all uppercase letters, and
<name> is the fully-qualified domain name (FQDN) of the Kerberos Key
Distribution Center (KDC). Optionally, you can use the IP address of the
KDC. The command syntax is:
domaintool --add <domainname> --kdc <name|IP address>
If you are setting up cross-domain authentication, use the --dnsdomain

option to this command. All hosts found in a certain DNS domain are
automatically in the correct Kerberos realm. Use the domaintool --add
command for each realm that the BIG-IP system may contact.
Now that the BIG-IP system is configured with the domains it may contact,
you must use the domaintool command to create service principals within
the domain. These service principals are named after the FQDN of the
virtual servers you create:
domaintool --join <domainname> --admin_principal <admin principal> --host <hostname>

Chapter 26
This command prompts you for a password. Typically, the value of the
admin_principal argument is administrator; however, you can use any
administrator name. The host argument specifies the FQDN of the virtual
server you configure for traffic. Run this command for each virtual server
you plan to configure.
Important
For additional information about these commands, see the domaintool man
page.
26 - 4
Creating the Kerberos delegation configuration

Now that you have added the DNS server to the BIG-IP system, and the
BIG-IP system to the domain, you need to create a Kerberos delegation
configuration. This section describes how to create a Kerberos delegation
configuration from the Configuration utility (following) or from the
command line interface (see Configuring Kerberos delegation from the
command line, on page 26-8).
For this configuration, you need to create the following objects:
• Kerberos delegation configuration
• Kerberos delegation profile
• Kerberos delegation Client SSL profile
• Kerberos delegation pool for load balancing
• Kerberos delegation virtual server
Important
The Kerberos delegation profile includes a set-cookie operation. To ensure
that an attacker cannot intercept this set-cookie header, always use the
Kerberos Delegation profile in conjunction with a Client SSL profile.
Configuring Kerberos delegation using the Configuration utility

This section provides all procedures for configuring Kerberos delegation,
using the Configuration utility. For the procedures on configuring Kerberos
delegation using the command line interface, see Configuring Kerberos
delegation from the command line, on page 26-8.
To create a Kerberos delegation configuration object

click Profiles.
4. For the Name setting, type a unique name for the configuration
object, such as my_kerberos_config.
Note: Any alphabetic characters in the name must be lowercase.
5. For the Type setting, select Kerberos Delegation.

Chapter 26
6. In the Client Principal Name box, type the client principal name.
The client principal name is the name of the virtual server on the
BIG-IP system. Use the following format, where <name> is the
admin_principal name that you previously added to the domain:
HTTP/<name>
7. In the Server Principal Name box, type the server principal name.
The server principal name is the name of the web server. Use the
following format, where <FQDN> is the fully-qualified domain
name of the web server in the pool:
HTTP/<FQDN>
8. Click Finished.
To create a Kerberos delegation profile object

click Profiles.
4. For the Name setting, type a unique name for the configuration
object, such as my_kerberos_profile.
Note: Any alphabetic characters in the name must be lowercase.
5. For the Type setting, select Kerberos Delegation.
6. For the Cookie Name setting, type a unique name.
7. For the Cookie Key setting, type a strong password.
Note: The Cookie Key value is an encryption key that encrypts
cookie data. A default value is supplied; however, you should
change the default value so that attackers who know this value
cannot decrypt cookie data and impersonate trusted users.
8. Click Finished.
To create a Client SSL profile

click Profiles.
A list of profiles displays.
2. From the SSL menu, choose Client.
The list of existing SSL profiles displays.
26 - 6

4. In the Name box, type a unique name for the profile.
5. On the far right side of the screen, click the Custom box.
6. From the Certificate list, select the name of an existing certificate.
7. From the Key list, select the name of an existing key.
8. At the bottom of the screen, click Finished.
To create a load balancing pool

click Pools.
4. For the Name setting, type a name for the pool, such as
webserverpool.
5. Specify, retain, or change the remaining settings.
Note: For the New Members setting, add the IP address and port
for each of the web servers in the Kerberos delegation
infrastructure.
6. Click Finished.
To create a virtual server and add the Kerberos delegation

and Client SSL profiles to the virtual server
3. For the Name setting, type a unique name for the virtual server,
such as my_kerberos_virtual.
4. For the Destination setting, click Host and type an IP address.
5. For the Service Port setting, type 80, or from the service list, select
HTTP.

Chapter 26
7. For the Type setting, select Standard.

8. For the Protocol setting, select TCP.
9. For the HTTP Profile setting, select http.
10. From the SSL Profile (Client) list, select the name of the Client
SSL profile you created previously.
11. For Authentication Profiles setting, use the Move button (<< or
>>) to enable the profile you created for Kerberos delegation.
12. In the Resources area of the screen, from the Default Pool list,
select the pool you created that contains the web servers.
13. Click Finished.
Configuring Kerberos delegation from the command line

This section describes how to configure Kerberos delegation from the
command line, using the bigpipe utility. To configure Kerberos delegation
using the Configuration utility, see Configuring Kerberos delegation using
the Configuration utility, on page 26-5.
To create a Kerberos delegation configuration object from

the command line
Type the following command to create the Kerberos delegation
configuration object:
auth krbdelegate my_kerberos_config { server principal "HTTP/<FQDN>" client principal
"HTTP/<FQDN>" }
For the server principal, use the FQDN of the web server.
For each client principal, use the FQDN of the virtual server you plan to
create on the BIG-IP system.
To create the Kerberos delegation profile object from the

command line
After you create the Kerberos delegation configuration object, you can
create the profile for the configuration.
Be sure to set a cookie name and strong password for the cookie encryption
key on the profile. In this example, the cookie name is kerbc and the key is
kerbc.
profile auth my_kerberos_profile { defaults from krbdelegate config my_kerberos_config
type krbdelegate cookie name kerbc cookie key "kerbc" }
Note
The Cookie Key value is an encryption key that encrypts cookie data. A
default value is supplied; however, you should change the default value so
that attackers who know this value cannot decrypt cookie data and
impersonate trusted users.
26 - 8
To create the Client SSL profile from the command line

The next task in configuring Kerberos delegation is to create a Client SSL
profile. Type the profile clientssl command as follows:
profile clientssl my_client_ssl_profile ( defaults from clientssl key my_key_name cert
my_cert_name )
To create the load balancing pool from the command line

After you create the configuration object and the profile for the Kerberos
delegation configuration, create a pool of web servers using the following
command, where <ip addr> is the IP address of the web server:
pool webserverpool { monitor all http members <ip addr>:http }
To create the Kerberos delegation virtual server from the

command line
To complete the configuration of the BIG-IP system for Kerberos
delegation, create the virtual server for the configuration.
Type the following command to create the virtual server, where <ip
addr>:http is the virtual server address, webserverpool is the pool of
webservers, my_client_profile is the Client SSL profile you created, and
my_kerberos_profile is the profile you created for Kerberos delegation:
virtual my_kerberos_virtual { snat automap pool webserverpool destination <ip addr>:http
ip protocol tcp profiles http tcp my_clientssl_profile auth my_kerberos_profile }

Chapter 26
Authenticating Client Traffic

After the network is configured, and the BIG-IP system is configured,
Kerberos delegation authenticates clients. Figure 26.1 shows how client
authentication works with Kerberos delegation.
Figure 26.1 How Kerberos delegation authenticates client traffic
The process for authenticating client traffic with Kerberos delegation is as

follows:
1. The user logs on to the domain.
2. The client browser connects to the BIG-IP virtual server and passes
Windows Integrated Authentication credentials, as well as SSL
credentials.
3. The BIG-IP system verifies the credentials and uses those
credentials to fetch credentials from domain 2 on behalf of the user
from domain 1.
4. The BIG-IP system passes the credentials obtained in step 3 to the
application server in domain 2.
5. The application server responds.
6. The BIG-IP system passes the response to the client.
26 - 10
27
• Introducing multiple authentication server

configuration
• Meeting prerequisites
• Configuring BIG-IP system objects

Introducing multiple authentication server

configuration
One of the features of the BIG-IP® system is its ability to authenticate local
administrative traffic when user accounts are stored on a remote LDAP,
RADIUS, or TACACS+ server. In fact, the BIG-IP system allows you to
configure the use of not just one, but two remote servers for authenticating
local administrative traffic. For most customers, this ability to configure one
or two remote authentication servers is more than sufficient. However, there
are two potential issues:
• Some customers need more than two remote servers for local
authentication.
• During authentication, the BIG-IP system queries the servers in a certain
order (server 1, then server 2) even when one or more servers are
unavailable. This can lead to a TCP timeout occurring on every incoming
connection, resulting in performance degradation.
To solve these problems, you can create virtual authentication servers. A

virtual authentication server is a virtual server that you configure to act as
an additional remote LDAP, RADIUS, or TACACS+ server. You can
configure as many virtual authentication servers as you need.
In general, to implement a multiple authentication server configuration, you
must complete several tasks:
• First, you create a health monitor to monitor the server nodes and mark
them as up or down.
• You then create a server object (for RADIUS servers only) and an
authentication configuration object.
• Next, you create a load-balancing pool, where multiple authentication
servers are members of that pool and are monitored with the monitor you
previously created. For those server nodes marked as down, the BIG-IP
system refrains from querying them during authentication.
• Finally, you create a virtual authentication server, associate it with the
pool of servers, and configure your applications to target that virtual
server.
Note
As an alternative to associating the pool with the virtual server, you can
associate the pool with each proxy or authentication source directly.
The remainder of this chapter describes how to successfully create a

multiple authentication server configuration. For example purposes only, the
information is written for RADIUS servers, but it applies to LDAP or
TACACS+ servers also, except for some minor differences: If your servers
are LDAP or TACACS+ servers, any information about RADIUS secrets
does not apply. Also, you should replace any mention of a RADIUS

Chapter 27
configuration object with an LDAP or TACACS+ configuration object.

Finally, you can ignore any information that pertains to a RADIUS server
object.
Meeting prerequisites
Before continuing, you must ensure that the following requirements are met:
• The RADIUS secret must be the same for all RADIUS servers.
• The address of the virtual server that you create to reference the RADIUS
pool cannot be a loopback address.
• The virtual server that references the RADIUS pool must be in the same
VLAN as the RADIUS servers.
For example, if the RADIUS server addresses are 10.1.1.10 and
10.1.1.11 and reside in the VLAN internal, then you must associate the
RADIUS pool with a virtual server that is routable to those addresses
(such as 10.1.1.99). This causes the source address of the RADIUS
traffic to be the self IP address of VLAN internal, rather than the virtual
server address.
Configuring BIG-IP system objects

To create a multiple RADIUS server configuration, you need to configure a
few local-traffic objects. Table 27.1 shows these objects, as well as the
Configuration utility screens you use to create these objects. Note that the
screens are all available in the Configuration utility from the Main tab,
under Local Traffic. For additional information on using these screens, see
the online help.
Configuration
Object utility screen
RADIUS health monitor Monitors
A RADIUS server object Profiles
A Radius configuration object that references the RADIUS Profiles

server object
A load-balancing pool that references the RADIUS health Pools

monitor
A virtual server that references the load-balancing pool Virtual Servers
Table 27.1 Required Configuration utility screens
27 - 2
Figure 27.1 shows relevant sample entries in the bigip.conf file.
monitor my_radius_monitor {
defaults from radius
password "jdoe"
secret "testing123"
username "jdoe"
}
radius server system_auth_name1 {
host "10.1.1.99"
service 1645
secret "testing123"
}
auth radius system-auth {
server system_auth_name1
}
pool radius_pool {
monitor all my_radius_monitor
member 10.1.1.10:1812
member 10.1.1.12:1645
}
virtual radius_virtual_server {
destination 10.1.1.99:1645
ip protocol udp
pool radius_pool
Figure 27.1 Example of relevant entries in the bigip.conf file
As seen in Figure 27.1, you configure these BIG-IP system objects:

• A RADIUS monitor named my_radius_monitor.
• A RADIUS server object named system_auth_name1 with IP address
and port 10.1.1.99:1645.
• A RADIUS configuration object named system-auto that references the
RADIUS server object.
• A pool named radius_pool that references the RADIUS monitor and
contains two pool members (10.1.1.10:1812 and 10.1.1.12:1645).
Note that port 1812 is the registered port number for the RADIUS
service.
• A virtual authentication server named radius_virtual_server that
references the pool radius_pool and uses the same IP address and port as
the RADIUS server object.
Note that this virtual server is defined on the same VLAN as the
RADIUS servers in the pool.
Once you have added entries to the bigip.conf file that are similar to those
in the above example, you can use the virtual server as a virtual remote
authentication server.

Chapter 27
27 - 4
28
• Introducing paired tunneling
• Configuring the client-side system
• Configuring the server-side system
• Viewing data compression statistics

Introducing paired tunneling

When you have two BIG-IP® systems that are separated by a wide area
network (WAN), you can optimize the data transfer between the two
systems. You accomplish this by creating a special optimization pathway, or
tunnel, between the two systems. When either system sends data to the
other using this tunnel, the data is compressed in a way that optimizes
compression quality and speed.
You can also configure the two systems to encrypt and decrypt the traffic
that passes through the tunnel, to ensure a secure connection for the traffic
when it crosses the WAN.
To implement these optimizations, you can set up a BIG-IP system
configuration known as paired tunneling.
What is paired tunneling?

In a paired tunneling configuration, two BIG-IP systems running Local
Traffic Manager are located on either side of a wide area network (WAN)
and have established a tunnel between them, for the purpose of optimizing
data transfer across the WAN. Figure 28.1 shows this configuration.
Figure 28.1 Sample paired tunneling configuration
The client-side system is the system closest to the client node that initiates a
request over the WAN for data that resides on a server node. The server-side
system is the system closest to the server node that services the request.
You can configure paired tunneling using either the Configuration utility or
the bigpipe utility.

Chapter 28
About data compression

In a paired tunneling configuration, the BIG-IP systems compress data and
headers pertaining to any TCP-related protocol, such as FTP, Telnet, HTTP,
and so on. A paired tunneling configuration can also compress
dynamically-generated data.
The method of compression that the BIG-IP systems actually use depends
on some combination of user configuration and performance optimization.
The compression methods available for the BIG-IP systems in a paired
tunneling configuration are:
◆ deflate
This is a higher-quality compression algorithm that is typically slower
than the lzo algorithm, unless the system is also using hardware
acceleration. The deflate algorithm is ideal for achieving better
compression through slower links (for example, a T1 or DS3 link).
◆ lzo
This is a fast, medium-quality compression algorithm with low latency.
The Lempel-Ziv-Oberhumer (lzo) algorithm is ideal for interactive
protocols (such as Telnet) or high-bandwidth protocols that compress
easily (such as data replication).
◆ adaptive
This is a compression method that chooses the best algorithm (deflate,
lzo, or off) as traffic conditions change. The adaptive method is both the
recommended and the default compression method.
◆ off
When the compression method is set to off, no compression occurs for
traffic passing between the two BIG-IP systems. This option is ideal for
protocols that cannot be compressed, such as streaming media (already
compressed), or encrypted protocols.
The compression methods that you configure on the two BIG-IP systems
must match, unless one of them is set to adaptive compression. For
example:
• If you configure one system to use the deflate method and the other to
use the lzo method, any connections currently passing through the tunnel
are reset, and no further traffic is allowed.
• If you configure one system to use deflate and the other to use adaptive
compression, the data is compressed using the deflate method.
• If you configure both systems to use the adaptive method (the default
setting), the systems uses either deflate, lzo, or off, depending on traffic
conditions. This is the recommended configuration.
WARNING
You should ensure that the data that a BIG-IP system sends through the
iSession tunnel is not already compressed or encrypted through some other
mechanism. Data targeted for the tunnel that has been already optimized
cannot be optimized any further and could produce adverse effects.
28 - 2
Before you begin

Before creating a paired tunneling configuration, you should consider the
following details:
• All local traffic management objects that you create, such as pools,
profiles, and virtual servers, are created in the current administrative
partition. Therefore, you should ensure that the current administrative
partition on each system is set appropriately.
• You must have a user role assigned to your user account that allows you
to create pools, profiles, and virtual servers.
• Paired tunneling configurations fully support route domains. That is, any
virtual servers and pool members that you create as part of a paired
tunneling configuration can reside in a non-default route domain.
For more information on these topics, see the TMOSTM Management Guide
for BIG-IP® Systems.

Chapter 28
Configuring the client-side system

The configuration procedure for the client-side BIG-IP system requires you
to perform the following tasks, in the order shown:
• Create an endpoint pool with one member, whose IP address is the same
address that you intend to assign to the virtual server on the server-side
BIG-IP system. (For information on creating the virtual server on the
server-side system, see Configuring the server-side system, on page
28-9.)
• Create a custom iSession profile that references the endpoint pool.
• Create a virtual server to process traffic, and assign the iSession profile
and an SSL profile to it.
The following subsections describe in detail how to perform these tasks

using the Configuration utility.
Creating a client-side endpoint pool

The first task in configuring the client-side system is to create an endpoint
pool on the client-side system (for example, clientside_endpoint_pool).
This pool acts as an endpoint of the tunnel between the two systems. The
pool has one pool member, which is the server-side virtual server (IP
address and service).
To create the endpoint pool on the client-side system

1. On the Main tab of the navigation menu, expand Local Traffic, and
click Pools.
This displays the list of pools on the system.
The New Pool screen displays.
permission to create a pool. You must have the appropriate user
3. In the Name box, type a name for the pool, such as
clientside_endpoint_pool.
4. For the New Members setting:
a) Click New Address.
b) In the Address box, type the virtual address assigned to the
virtual server on the server-side BIG-IP system.
c) In the Service Port box, specify a service.
28 - 4
d) Click Add.
This adds the specified IP address and service to the pool as a
pool member.
5. Click Finished.
Creating the client-side iSession profile

The next task is to create a custom iSession profile on the client-side system.
The iSession profile specifies the type of compression that you want the
BIG-IP system to use, and specifies the endpoint pool that you created in the
previous section.
To create a custom client-side iSession profile

click Profiles.
This displays the list of HTTP profiles on the system.
2. From the Services menu, choose iSession.
The New iSession Profile screen displays.
permission to create a profile. You must have the appropriate user
4. In the Name box, type a name for the profile, such as
clientside_isession_profile.
5. Verify that the Mode setting is set to Enabled.
6. From the Compression list, select the compression algorithm that
you want the system to use.
Note: The compression algorithm you select must match the type
you select on the server-side system, unless one of the systems is set
to adaptive. The default value is adaptive.
7. Verify that the Port Transparency and Reuse Connection settings
are set to Enabled.
8. Verify that the Target Virtual setting is set to None.
9. From the Endpoint Pool list, select the endpoint pool that you
created earlier on the server-side system. In our example, this pool
name is clientside_endpoint_pool.
10. Click Finished.

Chapter 28
Creating the client-side virtual server

The final task in setting up the client-side BIG-IP system is to create a
virtual server. The purpose of this virtual server is to capture client traffic
that is destined for a specific server node or subnet that resides on the other
side of the wide-area network (WAN). The virtual server then forwards that
traffic through the iSession tunnel for optimization.
Figure 28.2 shows a sample client-side virtual address configuration, based
on the destination IP address of the packet.
Figure 28.2 Sample client-side virtual address configuration
If the virtual address you specify is an address representing a subnet, the

BIG-IP systems in the paired tunneling configuration optimize traffic for the
entire subnet on which the destination server resides.
When you create the virtual server, you configure it to reference these
profiles:
◆ The default TCP optimization profiles
By configuring the virtual server to reference two default TCP
optimization profiles, you ensure optimal system performance when
processing both local and wide-area TCP traffic.
◆ The default Server SSL profile
The BIG-IP system provides a default profile named serverssl, which
enables server-side SSL processing. The serverssl profile ensures that
traffic sent from the client-side BIG-IP system to the server-side BIG-IP
system is encrypted.
◆ The custom iSession profile
This profile, which you created in the previous step, specifies the
endpoint pool that you previously created, which in turn references the
server-side virtual server address.
28 - 6
Note
As an option, you can use the RAM Cache feature. The result is that the
client-side BIG-IP system can process some client requests without needing
to connect to a backend server on the other side of the WAN.
To create a client-side virtual server

This displays the list of virtual servers on the system.
The New Virtual Server screen displays.
permission to create a virtual server. You must have the appropriate
user role assigned to your user account.
clientside_virtual_server.
a) Click Host or Network, depending on whether the address you
specify represents a specific server node or a subnet,
respectively.
b) In the Address box, type a destination IP address
This address should be either the destination IP address of the
specific server node to which the client node is sending the
request, or an address that matches the subnet on which the
server node resides.
c) If you clicked Network in step 4.a., then in the Mask box, type
the subnet mask.
5. From the Service Port list, select a service, such as HTTP or *All
Ports.
This causes the virtual server to listen for traffic on the specified
port or ports. If you select a specific service port (such as HTTP),
the virtual server ignores all other traffic types.
7. Verify that the Type value is Standard.
8. From the Protocol Profile (Client) list, select tcp-lan-optimized.
9. From the Protocol Profile (Server) list, select tcp-wan-optimized.
10. From the SSL Profile (Client) list, retain the default value of None.
11. From the SSL Profile (Server) list, select serverssl.
This causes the BIG-IP system to initiate an SSL connection to send
the traffic through the tunnel.
12. From the VLAN Traffic list, select All VLANS.

Chapter 28
13. For the iSession Profile setting:

a) From the list on the left, select the name of the custom iSession
profile you created previously on this system. In our example,
this is clientside_isession_profile.
b) From the Context list, select Server.
Selecting Server specifies that the local endpoint of the tunnel is
located on the server-side of the virtual server you are creating.
14. Click Finished.
28 - 8
Configuring the server-side system

To configure the server-side BIG-IP system for paired tunneling, you simply
need to create a virtual server. The purpose of this virtual server is strictly to
forward traffic to the local-area network (LAN) behind the server-side
BIG-IP system, rather than to load balance connections to a pool of servers.
The IP address that you assign to the virtual server can be any address to
which the client-side virtual server can route. In a typical configuration, this
address resides on the same subnet as the actual destination server node.
Note that the address you assign to this server-side virtual server is also
specified as the single member of the endpoint pool that you configured on
the client-side BIG-IP system.
Figure 28.3 shows a sample server-side virtual address configuration, based
on the client-side virtual address configuration.
Figure 28.3 Sample server-side virtual server configuration
The virtual server on the server-side system references these profiles:

◆ The default TCP optimization profiles
By configuring the virtual server to reference two default TCP
optimization profiles, you ensure optimal system performance when
processing both local and wide-area TCP traffic.
◆ The default Client SSL profile
The BIG-IP system provides a default profile named clientssl, which
enables client-side SSL processing. The clientssl profile ensures that
traffic sent from the client-side BIG-IP system to the server-side BIG-IP
system is authenticated and decrypted.
◆ The default iSession profile
Assigning this profile to the virtual server implements the server-side
endpoint for the paired tunneling configuration.

Chapter 28
Note
For the server-side BIG-IP system, you do not need to create an endpoint
pool or a custom iSession profile.
Creating the server-side virtual server

You can use the following procedure to create the server-side virtual server.
To create a server-side virtual server

This displays the list of virtual servers on the system.
permission to create a virtual server. You must have the appropriate
user role assigned to your user account.
serverside_forwarding_virtual_server.
a) Click Host.
b) In the Address box, type an IP address.
Important: This IP address should match the pool member
address you specified when creating the endpoint pool on the
client-side BIG-IP system.
For more information, see Specifying service ports, on page 28-11.
7. Verify that the Type value is Standard.
8. From the Protocol Profile (Client) list, select tcp-wan-optimized.
This setting is optional.
9. From the Protocol Profile (Server) list, select tcp-lan-optimized.
10. From the SSL Profile (Client) list, select clientssl.
This causes the BIG-IP system to terminate the SSL connection for
traffic coming from the tunnel.
11. Verify that the SSL Profile (Server) setting is set to None.
12. From the VLAN Traffic list, select All VLANS.
28 - 10
13. For the iSession Profile setting:

a) From the list on the left, select isession.
b) From the Context list, select Client.
Selecting Client specifies that the local endpoint of the tunnel is
located on the client-side of the virtual server you are creating.
14. Click Finished.
Specifying service ports

When you configure the server-side virtual server, F5 recommends that you
set the Service Port setting to *All Ports. In this case, the actual service
ports on which the server-side virtual server listens vary, depending on how
you have configured port transparency on the client-side BIG-IP system.
Port transparency is a feature that you configure within the client-side
iSession profile.
Table 28.1 shows how the Port Transparency setting on the client-side
system affects server-side virtual server behavior.
If client-side port Then the server-side virtual server For example...

transparency is set to... listens on...
Enabled The same service port that is configured If the client-side service port is set to HTTP,
(the default setting) on the client-side virtual server. then the server-side virtual server listens on
port 80.
Disabled iSession port 3701. If the client-side service port is set to HTTP,
then the server-side virtual server listens on
port 3701.
Table 28.1 Effect of the client-side Port Transparency setting on server-side virtual server

Chapter 28
Viewing data compression statistics

Once you have created a paired tunneling configuration, and the two BIG-IP
systems are processing traffic across the WAN, you can view data
compression statistics on the client-side system.
To view data compression statistics

To view these statistics, you can use the bigpipe utility on the client-side
system, as follows:
bp> profile isession isession show
The statistics show both raw and optimized statistics.
28 - 12
29
Securing and Accelerating HTTP Traffic with
ASM and WA
• Overview of the configuration tasks
• Completing basic configuration tasks on the Local

Traffic Manager
• Performing initial configuration tasks on the Local

Traffic Manager
• Creating an application profile for the

WebAccelerator system
• Assigning the WebAccelerator application profile to

the security policy in Application Security Manager
• Running the Application Security Manager

Deployment Wizard
Overview of the configuration tasks

This implementation describes the tasks that configure the BIG-IP®
Application Security Manager and the BIG-IP® WebAccelerator™ system
to run on the same virtual server.
For this implementation, you must perform the following tasks before the
system can secure connectivity and accelerate HTTP traffic to your
applications.
◆ Complete basic configuration on the BIG-IP Local Traffic Manager
Before you can begin this implementation, you must complete the basic
configuration requirements on the BIG-IP Local Traffic Manager. See
Completing basic configuration tasks on the Local Traffic Manager, on
page 29-2, for more information.
◆ Perform initial configuration tasks on the BIG-IP Local Traffic
Manager
To prepare the BIG-IP Local Traffic Manager to run the Application
Security Manager and the WebAccelerator system on the same virtual
server, there are initial configuration tasks you must complete. See
Performing initial configuration tasks on the Local Traffic Manager, on
◆ Create an application profile for the WebAccelerator system
An application profile provides all of the basic information required for
the WebAccelerator system to begin expediting traffic to your
applications. See Creating an application profile for the WebAccelerator
system, on page 29-7, for more information.
◆ Run the Application Security Manager Deployment Wizard
The Deployment Wizard automates the fundamental tasks required to
initially build and deploy a security policy for your applications. See
Running the Application Security Manager Deployment Wizard, on page
29-13, for more information.

Chapter 29
Completing basic configuration tasks on the Local

Traffic Manager
Before you can begin the processes required to run the Application Security
Manager and the WebAccelerator system on the same virtual server, you
must have already completed some basic configuration tasks on the BIG-IP
Local Traffic Manager. The following tasks must be completed:
◆ Licensing and provisioning for the Application Security Manager
and the WebAccelerator system
For more information, see the BIG-IP® Systems: Getting Started Guide.
◆ Configuring virtual server settings
For more information, see the Configuration Guide for BIG-IP® Local
Traffic Management.
◆ Configuring name resolution (DNS or entries to the host file)
For more information, see the TMOS™ Management Guide for BIG-IP®
Systems.
29 - 2
Performing initial configuration tasks on the Local

Traffic Manager
Once you have performed the basic configuration tasks on the BIG-IP®
Local Traffic Manager™, you can complete the initial configuration tasks
required to prepare the BIG-IP Local Traffic Manager to run both the
Application Security Manager and the WebAccelerator system on the same
virtual server.
The following list describes the initial configuration for the Local Traffic
Manager:
◆ Creating an HTTP class profile for the Application Security
Manager and the WebAccelerator system
The HTTP class profile uses the HTTP header, cookie, host, and path,
and other HTTP properties, to specify the HTTP traffic to which the
system applies security and acceleration. See Creating the HTTP class
profile, following, for more information.
◆ Defining a virtual server and pool
The virtual server load balances traffic to one or more pools that are
hosting the web application. A pool is made up of members, which are
the servers that host the web application resources that you want to
protect with the Application Security Manager, and whose traffic you
want to expedite with the WebAccelerator system. See Defining a virtual
server and pool on the BIG-IP Local Traffic Manager, on page 29-4, for
more information.
◆ Configuring a Network Time Protocol (NTP) server
To properly maintain its cache and synchronize configurations, the
system requires that the time on the application servers and the time on
the BIG-IP system be the same. See Defining an NTP server, on page
29-6, for more information.
Creating the HTTP class profile

The first task required to prepare the BIG-IP Local Traffic Manager to run
the Application Security Manager and the WebAccelerator system, is to
create an HTTP class profile. An HTTP class profile uses the HTTP header,
cookie, host, and path, and other HTTP properties, to specify the HTTP
traffic to which the system applies security and acceleration. For this
implementation, you create one HTTP class profile that enables both the
Application Security Manager and the WebAccelerator system.
Important
When you enable application security for an HTTP class profile, the system
automatically creates a web application configuration and default security
policy for Application Security Manager.

Chapter 29
To create an HTTP class profile

1. On the Main tab of the navigation pane, expand Application
Security, and click Classes.
The HTTP Class screen opens.
2. Click the Create button.
The New HTTP Class Profile screen opens.
3. In the Name box, type a unique name for the HTTP class profile.
4. From the Parent Profile list, select httpclass.
5. In the Configuration area, check the Custom box (on the right) to
activate the WebAccelerator setting, and then select Enabled from
the list.
6. Verify that the Application Security setting is also enabled.
7. Click the Finished button.
The system adds the new HTTP class profile, and displays the
HTTP Class Profiles screen.
An important consideration when configuring HTTP class profiles

In the Configuration utility, you can create HTTP class profiles from more
than one section of the navigation pane. When you create an HTTP class
profile from the Local Traffic section, by default both the WebAccelerator
setting and the Application Security setting are disabled. In this case, you
must explicitly enable both of these settings if you want the HTTP class to
accelerate and secure your traffic. When you create an HTTP class profile
from either the Application Security section or the WebAccelerator
section of the Configuration utility, then in the HTTP class profile
configuration, the respective setting is enabled by default. In this case, you
must explicitly enable only one of the corresponding settings.
Defining a virtual server and pool on the BIG-IP Local Traffic

Manager
The second task you need to perform is to define a virtual server and pool.
As part of the definition, you associate the HTTP class profile that you
created in the previous procedure with the virtual server. The virtual server
then processes and routes incoming traffic according to the settings that you
configure in the associated HTTP class profile. The pool hosts the web
application content that clients are accessing.
Note
The following procedure outlines only the basic virtual server and pool
configuration. For detailed information about virtual servers, pools, and the
other local traffic components, see the Configuration Guide for BIG-IP®
Local Traffic Management.
29 - 4
To configure a virtual server and pool

The Virtual Servers list screen displays.
3. In the General Properties area, for the Name setting, type a unique
name for the virtual server.
4. For the Destination setting, click the Host button, and type an IP
address in the Address box.
5. For the Service Port setting, type the appropriate service port for
your application. For example, for HTTP, the port is 80.
Alternatively, you can select a service type from the list.
6. From the State list, select Enabled.
7. Above the Configuration area, select Advanced.
The screen refreshes to display the additional configuration options.
8. In the Configuration area, from the HTTP Profile list, select
http-acceleration.
Important: We strongly recommend that you leave RAM Cache
enabled for the http-acceleration service profile, and that you do
not make any modifications to the RAM Cache default settings for
Minimum Object Size, Maximum Object Size, URI Caching, and
Ignore Headers. Doing so will adversely affect the way the BIG-IP
WebAccelerator system manages HTTP traffic for your site.
9. For the Port Translation setting, ensure that the setting is enabled
(checked).
Important: If the Port Translation setting is disabled for the virtual
server, the WebAccelerator system cannot properly accelerate
traffic.
10. For the SNAT Pool setting, select Auto Map.
11. In the Resources area, for the HTTP Class Profiles setting, in the
Available list, select the Application Security
Manager/WebAccelerator-enabled HTTP class profile that you
created, and click the Move button (<<) to add the profile to the
Enabled list.
12. Next to the Default Pool setting, click the Add (+) button.
13. In the Configuration area, for the Name setting, type a unique name
for the pool.
14. For the Health Monitors setting, from the Available list, select a
health monitor or monitors, and click the Move button (<<) to add
the monitor to the Active list.

Chapter 29
15. In the Resources area, from the Load Balancing Method list, select
a load balancing option.
16. Leave the Priority Group Activation setting at the default,
Disabled.
17. For the New Members setting, select New Address, and in the
Address and Service Port boxes, type the address and port for the
pool members. Alternately, you can select Node List, and select
nodes to add to the New Members list.
18. Click the Add button.
19. Click Finished.
The screen refreshes, and returns to the New Virtual Server screen,
where you see the new pool in the Default Pool list.
20. Click Finished again.
The system updates the configuration, and displays the Virtual
Server list screen, where you can see the virtual server that you
created.
Defining an NTP server

Next, you need to define a Network Time Protocol (NTP) server. NTP is a
protocol that synchronizes the clocks on your network with a defined NTP
server. This synchronization ensures that the Local Traffic Manager
properly maintains its cache, and synchronizes configuration changes for
optional symmetric deployments in the WebAccelerator system.
To define an NTP server

1. On the Main tab of the navigation pane, expand System, and then
click Configuration.
The General screen displays.
2. From the Device menu, choose NTP.
The NTP screen displays.
3. For the Time Server List setting, in the Address box, type either the
IP address or the fully-qualified domain name for an NTP server.
4. Click the Add button to add the server to the list.
5. Click Update to save the changes.
29 - 6
Creating an application profile for the

Once you have completed the first series of tasks that set up the local area
network, you create an application profile for the WebAccelerator system.
The application profile provides the key information that the
WebAccelerator system needs to appropriately handle requests to your site’s
web applications. Creating an application profile consists of the following
tasks:
• Selecting an acceleration policy to manage traffic to your application
• Planning and defining your host map
• Verifying your application profile
Selecting an acceleration policy

To begin the process of creating an application profile, you must first decide
which acceleration policy you want to associate with your application. One
option is to select a pre-defined acceleration policy that is associated with
your specific application publisher.
If you do not want to use an acceleration policy that is specific to a certain
application publisher, you may use one of the two pre-defined general
delivery acceleration policies. Both work well for most sites that use Java 2
Platform Enterprise Edition (J2EE™) applications.
• Level 1 Delivery
This pre-defined acceleration policy is compliant with HTML version
2.0. For this acceleration policy, the WebAccelerator system:
• Sends all requests for HTML pages to the origin web server for
content.
• Ignores any no-cache directives included in HTTP Cache-Control
request header, and uses the cache response directives that it receives
from the origin web server.
This pre-defined acceleration policy is compliant with HTML version 3.0
and later. For this acceleration policy, the WebAccelerator system:
• Caches HTML pages and assigns a lifetime setting of 0, which
prompts the WebAccelerator system to provide fresh content by
making subsequent requests for that content, using a conditional GET.
• Uses the Intelligent Browser Referencing feature only for documents
and includes.

Chapter 29
In addition to these application-specific and general delivery acceleration

policies, the WebAccelerator system also provides a deployment-specific
acceleration policy, called Symmetric Deployment. You can select this
option if you are configuring an optional symmetric deployment. For more
information about this option, see the Configuration Guide for the BIG-IP®
WebAccelerator™ System.
If, however, you have a unique application for which you cannot use a
pre-defined acceleration policy, you can customize the WebAccelerator
system’s behavior by creating a user-defined acceleration policy. In most
cases, you do this by copying a pre-defined acceleration and modifying it as
required. You also have the option of importing a signed acceleration policy
that is created, certified, and encrypted by its author, such as a consultant or
vendor.
For information about acceleration policy features, and instructions about
how to create user-defined acceleration policies or import signed
acceleration policies, see the Policy Management Guide for the BIG-IP®
Tip
You can change the selected acceleration policy at any time after you create
the application profile.
Planning your host map

When the WebAccelerator system receives an HTTP request, it compares
the host on the request to those in its host map to determine which
application profile to apply. Once it matches to an application profile, it can
use the associated acceleration policy to handle the request.
When you create a host map, you identify the domain as it appears on the
HTTP Host request header. These domains are called requested hosts.
When you specify the host name for the requested host in a host map, you
can use a wildcard, an asterisk (*) followed by a period, for the first
character in the domain. This wildcard can represent one or more
subdomains, enabling you to map several subdomains to one origin web
server in one step. Using a wildcard saves time if your site has several
subdomains.
Note
The WebAccelerator system is also capable of managing requests for

unmapped domains, which are called unmapped requests. For more
information, see the Configuration Guide for the BIG-IP®
29 - 8
Following are examples of valid requested host names that use wildcards.
◆ *.sales.siterequest.com maps to the following (all to the same
destination host):
• direct.sales.siterequest.com
• marketing.sales.siterequest.com
• marcom.marketing.sales.siterequest.com
◆ *siterequest.com maps to the following (all to the same destination

host):
• www.siterequest.com
• engineering.siterequest.com
◆ *.com maps all incoming requests that end in .com to one destination
host.
◆ * maps all incoming requests to one destination host.
If the WebAccelerator system can map multiple requested host names to a

request, it chooses the host name that most closely matches the request.
Consider the following defined host names:
• a.com
• www.a.com
• *.b.a.com
• *.a.com
If the WebAccelerator system receives requests that contain these URLs, it

maps to the requested hosts as follows:
• A request to www.a.com maps to www.a.com, and does not map to
*.a.com.
• A request to a.com maps to a.com.
• Requests to c.a.com and b.a.com both map to *.a.com.
• A request to c.b.a.com maps to *.b.a.com.
To create an application profile

1. On the Main tab of the navigation pane, expand WebAccelerator
and click Applications.
The Applications screen displays in a new window.
The New Application screen opens.
3. In the Application Name box, type a name for the application.

Chapter 29
4. In the Description box, type an optional description.

5. From the Central Policy list, select the acceleration policy that you
want the WebAccelerator system to use when requesting
information from the associated application. If you have configured
an optional symmetric deployment, we recommend that you select
the Symmetric Deployment pre-defined acceleration policy,
because it is specifically designed to manage content assembly in a
symmetric deployment. For more information, see the
Configuration Guide for the BIG-IP® WebAccelerator™ System.
6. If you have a symmetric deployment, from the Remote Policy list,
select an acceleration policy for the remote WebAccelerator system.
We recommend that you select Symmetric Deployment. If you do
not have a symmetric deployment, do not select a remote policy.
7. In the Hosts section at the bottom of the screen, click the Add Host
button.
8. In the Requested Host box, type a valid host name for each client
host that you want to allow access to the application.
9. Click the Save button.
Verifying the application profile

After you create an application profile, you must verify that the
WebAccelerator system is able to properly send data to and receive data
from the origin web servers.
To verify the application profile

1. On a machine separate from the WebAccelerator system, and from
which you can run a web browser, open the hosts file and add the
host name that you used to access the web site application. The host
name must point to the IP address for the virtual server that you
configured.
Note: On Microsoft® Windows® 2000 and Windows® XP machines,
the hosts file is located at
C:\WINDOWS\system32\drivers\etc\hosts
For example, if you can access the web site at the
www.siterequest.com domain, and the virtual server is at IP
address 11.1.11.3, add the following line to the hosts file on the
machine running the browser:
11.1.11.3 www.siterequest.com
All network traffic from the web browser machine for

www.siterequest.com subsequently goes to the virtual server.
2. From the web browser machine, request a page from
www.siterequest.com.
29 - 10
You should see the page that you would have received if your
browser had accessed the origin web servers directly. If the browser
times out the request, it means that either the WebAccelerator
system is not running, or the firewall is blocking access to port 80
on the WebAccelerator system.
3. If you receive an Access denied by intermediary. Domain not
recognized. error, perform the following tasks:
• Verify that the hosts file is correct.
• Verify that the host map for the application profile is correct.
• Verify that you used a domain in the request that matches a
requested host in the host map, and that it maps to the destination
host.
4. After you confirm the host mapping, remove any entries that you
changed or added.

Chapter 29
Assigning the WebAccelerator application profile to

the security policy in Application Security Manager
Before you run the Deployment Wizard for the Application Security
Manager, you must assign the WebAccelerator application profile to the
security policy. If you have more than one application profile configured,
you can change the assignment on the Policy Properties screen in the
Application Security Manager.
To assign the WebAccelerator application profile to the

security policy
1. On the Main tab of the Application Security navigation pane, click
Policies List.
The Security Policies screen opens.
2. In the editing context area, ensure that the edited web application
and security policy are those that you want to update.
3. In the Security Policies area, in the Security Policy Name column,
click the name of the security policy that you want to edit.
The Security Policy Properties screen opens.
4. Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
5. For the WebAccelerator Cache Clear Settings option, from the
Available WA Applications list, select the WebAccelerator
application profile that you created, and click the Move button (<<)
to add the profile to the Assigned WA Applications list.
6. Click the Save button.
29 - 12
Running the Application Security Manager

Deployment Wizard
Once you have configured the WebAccelerator system’s application profile,
you can create the Application Security Manager’s security policy.
The most efficient way to build a security policy for a new web application
is to use the Deployment Wizard. The Deployment Wizard automates the
fundamental tasks required to initially build and deploy a security policy.
The Deployment Wizard uses several deployment scenarios, which
represent several typical environments that use application security, to guide
you through the configuration process. The deployment scenarios include:
• A web application in a production environment
• A web application in a test environment
• A web services application
• A system-supplied application-ready security policy.
To start the Deployment Wizard

1. On the Main tab of the navigation pane, expand Application
Security and click Web Applications.
The Web Applications screen opens.
2. Click the Set Language link for the new web application.
The Select Deployment Scenario screen opens.
3. In the Select Deployment Scenario area, select a deployment
scenario.
For more information about deployment scenarios, see the BIG-IP®
Application Security Manager: Getting Started Guide guide, which
is available on the Ask F5SM web site, https://support.f5.com.
4. Click the Run Deployment Wizard button.
The Application Security Manager Deployment Wizard starts.

Chapter 29
29 - 14
30
Securing and Accelerating HTTP Traffic with
PSM and WA
• Overview of the configuration tasks
• Completing basic configuration tasks on the Local

Traffic Manager
• Performing initial configuration tasks on the Local

Traffic Manager
• Creating an application profile for the

• Creating an HTTP security profile in the Protocol

Security Module configuration
Overview of the configuration tasks

This implementation describes the tasks that configure the BIG-IP® Protocol
Security Module and the BIG-IP WebAccelerator™ system to run on the
same virtual server.
For this implementation, you must perform the following tasks before the
system can secure connectivity and accelerate HTTP traffic to your
applications.
◆ Complete basic configuration on the BIG-IP Local Traffic Manager.
Before you can begin this implementation, you must complete the basic
configuration requirements on the BIG-IP Local Traffic Manager. See
Completing basic configuration tasks on the Local Traffic Manager, on
◆ Perform initial configuration tasks on the BIG-IP Local Traffic
Manager.
To prepare the BIG-IP Local Traffic Manager to run the Protocol
Security Module and the WebAccelerator system on the same virtual
server, there are initial configuration tasks you must complete. See
Performing initial configuration tasks on the Local Traffic Manager, on
◆ Create an application profile for the WebAccelerator system.
An application profile provides all of the basic information required for
the WebAccelerator system to begin expediting traffic to your
applications. See Creating an application profile for the WebAccelerator
system, on page 30-7, for more information.
◆ Create an HTTP security profile in the Protocol Security Module
configuration.
The final task is to create a custom HTTP security profile in the Protocol
Security Module configuration, and associate the WebAccelerator
application profile with it. See Creating an HTTP security profile in the
Protocol Security Module configuration, on page 30-12, for more
information.

Chapter 30
Completing basic configuration tasks on the Local

Traffic Manager
Before you can begin the configuration tasks to set up and run the Protocol
Security Module and the WebAccelerator system on the same virtual server,
you must perform basic configuration tasks on the BIG-IP® Local Traffic
Manager. Ensure that the following tasks have been completed:
◆ License and provision the Protocol Security Module and the
WebAccelerator system.
When you add new modules to a BIG-IP system, you activate add-on
license keys, and also provision the system for the new software.
Provisioning reallocates system resources, such as disk storage and
memory. For more information, see the BIG-IP® Systems: Getting
Started Guide.
◆ Configure at least one DNS server.
You configure a DNS server to enable name resolution for your virtual
servers and applications. For more information, see the TMOS™
◆ Configure at least one NTP server.
The WebAccelerator system relies on the NTP protocol to keep system
clocks synchronized. This synchronization ensures that the system
properly maintains its cache, and synchronizes configuration changes for
optional symmetric deployments. For more information, see the
TMOS™ Management Guide for BIG-IP® Systems.
30 - 2
Performing initial configuration tasks on the Local

Traffic Manager
Once you have performed the basic configuration tasks on the BIG-IP Local
Traffic Manager, you complete the initial configuration tasks required to
prepare the BIG-IP Local Traffic Manager to run both the Protocol Security
Module and the WebAccelerator system on the same virtual server. The
virtual server load balances pools that host the web application for which the
Protocol Security Module is checking security and the WebAccelerator
system is expediting traffic. The virtual server is also the bridge that
connects the Protocol Security Module and WebAccelerator, by using their
respective profiles.
For this implementation, perform the following tasks to configure the Local
Traffic Manager:
◆ Create a WebAccelerator HTTP class profile.
The first step in configuring the Protocol Security Module and
WebAccelerator is to create the WebAccelerator class profile. See
Creating the WebAccelerator HTTP class profile, on page 30-4, for more
information.
◆ Create an HTTP service profile
After you create the WebAccelerator profile, you create a custom HTTP
service profile. This profile enables the protocol security checking that is
performed on incoming HTTP traffic. See Creating an HTTP service
profile, on page 30-4, for more information.
◆ Create a virtual server and pool.
In this step, you configure the virtual server, including assigning the
HTTP class profile and the HTTP service profile to the virtual server,
and define one or more pools. See Creating a virtual server and pool on
the BIG-IP Local Traffic Manager, on page 30-5, for more information.

Chapter 30
Creating the WebAccelerator HTTP class profile

The first task required to prepare the BIG-IP Local Traffic Manager to run
the Protocol Security Module and the WebAccelerator system together is to
create the WebAccelerator HTTP class profile.
To create the WebAccelerator HTTP class profile

1. On the Main tab of the navigation pane, expand WebAccelerator,
and then click Class Profiles.
The HTTP Class screen opens.
The New HTTP Class Profile screen opens.
name for the HTTP class profile.
4. From the Parent Profile list, select httpclass.
5. In the Configuration area, verify that the WebAccelerator setting is
enabled.
6. Click the Finished button.
The system adds the new HTTP class profile, and displays the
HTTP Class Profiles screen.
Creating an HTTP service profile

The second task that you perform is to create an HTTP service profile. The
HTTP service profile (in the Local Traffic configuration) uses the HTTP
security profile (in the Protocol Security Module configuration) to scan for
vulnerabilities specific to the protocol. For more information about security
profiles, see Creating an HTTP security profile in the Protocol Security
Module configuration, on page 30-12.
To create an HTTP service profile

click Profiles.
The Profiles:Services:HTTP screen opens.
name for the profile.
4. For the Parent Profile setting, select the existing HTTP protocol
from which you want the new profile to inherit settings. The default
setting is http.
5. Above the Settings area, check the Custom check box.
The system activates the editing mode for the individual settings.
30 - 4
6. Check the Protocol Security check box to enable HTTP security

checks.
7. Modify any other settings on the screen as required by your
configuration.
8. Click Finished.
The screen refreshes and displays the new HTTP service profile in
the list.
Note
For more information about HTTP service profiles in general, see the
Creating a virtual server and pool on the BIG-IP Local Traffic

Manager
The next configuration task is to create a virtual server and pool on the local
area network. The virtual server processes the incoming traffic, which
includes applying the protocol security checks and the acceleration policy.
The pool hosts the web application content that clients are accessing.
Note
The following procedure outlines only the basic virtual server configuration.
For detailed information on virtual servers, including SSL virtual servers,
and other local traffic components, see the Configuration Guide for
BIG-IP® Local Traffic Management.
To create a virtual server and pool

The Virtual Server List screen opens.
3. In the Name box, type a name for the virtual server.
4. For the Destination Type setting, click the Host button and type an
IP address in the Address box.
5. In the Service Port box, type 80 or select HTTP from the list.
The screen refreshes to display the advanced configuration options.
7. In the Configuration area, from the HTTP Profile list, select the
HTTP service profile that you created.
8. For the SNAT Pool setting, select Auto Map.

Chapter 30
9. In the Resources area, for the HTTP Class Profiles setting, from
the Available list, select the HTTP class profile that you created,
and click the Move button (<<) to add the class to the Enabled list.
10. Next to the Default Pool list, click the Add (+) button.
12. For Health Monitors, from the Available list, select a health
monitor or monitors and click the Move button (<<) to add the
monitor to the Active list.
13. In the Resources area, from the Load Balancing Method list, select
a load balancing option.
14. Leave the Priority Group Activation setting at the default,
Disabled.
15. For the New Members setting, select New Address, and in the
Address and Service Port boxes, type the address and port for the
pool members. Alternately, you can select Node List, and select
nodes to add to the New Members list.
16. Click the Add button.
17. Click Finished.
The screen refreshes and opens the New Virtual Server screen,
where you see the new pool in the Default Pool list.
18. Click Finished again.
The system updates the configuration, displays the Virtual Server
list screen, where you can see the virtual server that you created.
30 - 6
Creating an application profile for the

The application profile provides the key information that the
WebAccelerator system needs to appropriately handle requests to your site’s
web applications. Creating an application profile consists of the following
tasks:
• Selecting an acceleration policy to manage traffic to your application
• Planning and defining your host map
• Verifying your application profile
Selecting an acceleration policy

To begin the process of creating an application profile, you must first decide
which acceleration policy you want to associate with your application. One
option is to select a pre-defined acceleration policy that is associated with
your specific application publisher.
If you do not want to use an acceleration policy that is specific to a certain
application publisher, you may use one of the two pre-defined general
delivery acceleration policies. Both work well for most sites that use Java 2
Platform Enterprise Edition (J2EE) applications.
This pre-defined acceleration policy is compliant with HTML version
2.0. For this acceleration policy, the WebAccelerator system:
• Sends all requests for HTML pages to the origin web server for
content.
request headers, and uses the cache response directives that it receives
This pre-defined acceleration policy is compliant with HTML version 3.0
and later. For this acceleration policy, the WebAccelerator system:
• Caches HTML pages and assigns a lifetime setting of 0, which
prompts the WebAccelerator system to provide fresh content by
making subsequent requests for that content, using a conditional GET.
• Uses the Intelligent Browser Referencing feature only for documents
and includes.
In addition to these application-specific and general delivery acceleration

policies, the WebAccelerator system also provides a deployment-specific
acceleration policy, called Symmetric Deployment. You can select this

Chapter 30
option if you are configuring an optional symmetric deployment. For more

information about this option, see the Configuration Guide for the BIG-IP®
If, however, you have a unique application for which you cannot use a
pre-defined acceleration policy, you can customize the WebAccelerator
system’s behavior by creating a user-defined acceleration policy. In most
cases, you do this by copying a pre-defined acceleration policy and
modifying it as required. You also have the option of importing a signed
acceleration policy that is created, certified, and encrypted by its author,
such as a consultant or vendor.
For information about acceleration policy features, and instructions about
how to create user-defined acceleration policies or import signed
acceleration policies, see the Policy Management Guide for the BIG-IP®
Tip
You can change the selected acceleration policy at any time after you create
the application profile.
Planning your host map

When the WebAccelerator system receives an HTTP request, it compares
the host on the request to those in its host map to determine which
application profile to apply. Once it matches to an application profile, it can
use the associated acceleration policy to handle the request.
When you create a host map, you identify the domain as it appears on the
HTTP Host request header. These domains are called requested hosts.
When you specify the host name for the requested host in a host map, you
can use a wildcard, an asterisk (*) followed by a period, for the first
character in the domain. This wildcard can represent one or more
subdomains, enabling you to map several subdomains to one origin web
server in one step. Using a wildcard saves time if your site has several
subdomains.
Note
The WebAccelerator system is also capable of managing requests for

unmapped domains, which are called unmapped requests. For more
information, see the Configuration Guide for the BIG-IP®
30 - 8
Following are examples of valid requested host names that use wildcards.
◆ *.sales.siterequest.com maps to the following (all to the same
destination host):
◆ *siterequest.com maps to the following (all to the same destination

host):
• www.siterequest.com
• engineering.siterequest.com
◆ *.com maps all incoming requests that end in .com to one destination
host.
◆ * maps all incoming requests to one destination host.
If the WebAccelerator system can map multiple requested host names to a

request, it chooses the host name that most closely matches the request.
Consider the following defined host names:
• a.com
• www.a.com
• *.b.a.com
• *.a.com
If the WebAccelerator system receives requests that contain these URLs, it

maps to the requested hosts as follows:
• A request to www.a.com maps to www.a.com, and does not map to
*.a.com.
• A request to a.com maps to a.com.
• Requests to c.a.com and b.a.com both map to *.a.com.
• A request to c.b.a.com maps to *.b.a.com.
To create an application profile

1. On the Main tab of the navigation pane, expand WebAccelerator
and click Applications.
The Applications screen displays in a new window.
The New Application screen opens.
3. In the Application Name box, type a name for the application.

Chapter 30
4. In the Description box, type an optional description.

5. From the Central Policy list, select the acceleration policy that you
want the WebAccelerator system to use when requesting
information from the associated application. If you have configured
an optional symmetric deployment, we recommend that you select
the Symmetric Deployment pre-defined acceleration policy,
because it is specifically designed to manage content assembly in a
symmetric deployment. For more information, see the
Configuration Guide for the BIG-IP® WebAccelerator™ System.
6. If you have a symmetric deployment, from the Remote Policy list,
select an acceleration policy for the remote WebAccelerator system.
We recommend that you select the Symmetric Deployment
pre-defined acceleration policy. If you do not have a symmetric
deployment, do not select a remote policy.
7. In the Hosts section at the bottom of the screen, in the Requested
Host box, type a valid host name
8. To add additional client hosts that you want to allow access to the
application, in the Hosts section at the bottom of the screen, click
the Add Host button.
The screen refreshes and displays another Requested Host box,
where you can type the name of an additional client host.
9. When you finish adding client hosts, click the Save button.
Verifying the application profile

After you create an application profile, you must verify that the
WebAccelerator system is able to properly send data to and receive data
from the origin web servers.
To verify the application profile

1. On a machine separate from the WebAccelerator system, and from
which you can run a web browser, open the hosts file and add the
host name that you used to access the web site application. The host
name must point to the IP address for the virtual server that you
configured.
Note: On Microsoft® Windows® 2000 and Windows® XP machines,
the path name for the hosts file is:
C:\WINDOWS\system32\drivers\etc\hosts.
For example, if you can access the web site at the
www.siterequest.com domain and the virtual server is at IP address
11.1.11.3, add the following line to the hosts file on the machine
running the browser:
11.1.11.3 www.siterequest.com
All network traffic from the web browser machine for

www.siterequest.com subsequently goes to the virtual server.
30 - 10
2. From the web browser machine, request a page from

www.siterequest.com.
You should see the page that you would have received if your
browser had accessed the origin web servers directly. If the browser
times out the request, it means that either the WebAccelerator
system is not running, or the firewall is blocking access to port 80
on the WebAccelerator system.
3. If you receive an Access denied by intermediary error, perform
• Verify that the hosts file is correct.
• Verify that the host map for the application profile is correct.
• Verify that you used a domain in the request that matches a
requested host in the host map.
4. After you confirm the host mapping, remove any entries that you
changed or added.

Chapter 30
Creating an HTTP security profile in the Protocol

Security Module configuration
In the Protocol Security Module, the HTTP security profile specifies the
HTTP security checks that are enforced by the Security Enforcer. You also
associate the WebAccelerator application profile with the security profile.
For detailed information about configuring protocol security profiles, refer
to the Configuration Guide for BIG-IP® Protocol Security Module, which
is available at https://support.f5.com.
Important
The following task assumes that you have already set up a remote logging
configuration for security profile log files. For more information on remote
logging and Protocol Security Module, refer to the Configuration Guide for
BIG-IP® Protocol Security Module.
To create a security profile for HTTP traffic

1. On the Main tab of the navigation pane, expand the Protocol
Security section and click Security Profiles.
The HTTP Security Profiles screen opens in a new browser session.
2. Above the HTTP Security Profiles area, click the Create button.
The New Security Profile screen opens.
3. In the Profile Properties area, in the Profile Name box, type a
unique name for the profile.
4. For the Remote Logging setting, check the box to enable remote
logging for this security profile.
5. In the Defense Configuration area, you can update the blocking
policy settings for the security profile by clicking a tab and
modifying the settings as needed. If you do not check either Alarm
or Block for a violation, the system does not perform the
corresponding security check.
• Check Alarm if you want the system to log any requests that
trigger the security profile violation.
• Check Block if you want the system to block requests that trigger
the security profile violation.
• Check both Alarm and Block if you want the system to perform
both actions.
6. Click the Blocking Page tab to configure the blocking response
page. If you have enabled the Block flag for any violations, the
system sends the blocking response page to the offending client,
instead of connecting them to the application.
7. Click theWebAccelerator tab. On this tab, you associate the
WebAccelerator application profile with the HTTP security profile.
30 - 12
8. For WebAccelerator Cache Clear Settings option, from the

Available WA Applications list, select the WebAccelerator profile
and click the Move button (<<) to add it to the Assigned WA
Applications list.
9. Click Create.
The screen refreshes, and you see the new security profile in the list.

Chapter 30
30 - 14
Glossary
Glossary
active unit
In a redundant system, the active unit is the system that currently load
balances connections. If the active unit in the redundant system fails, the
standby unit assumes control and begins to load balance connections. See
also redundant system.
ARP (Address Resolution Protocol)

ARP is an industry-standard protocol that determines a host’s Media Access
Control (MAC) address based on its IP address.
authentication
Authentication is the process of verifying a user’s identity when the user is
attempting to log on to a system.
authentication iRule
An authentication iRule is a system-supplied or user-created iRule that is
necessary for implementing a PAM authentication module on the BIG-IP
system. See also iRule, PAM (Pluggable Authentication Module).
authentication module
An authentication module is a PAM module that you create to perform
authentication or authorization of client traffic. See also PAM (Pluggable
Authentication Module).
authentication profile
An authentication profile is a configuration tool that you use to implement a
PAM authentication module. Types of authentication modules that you can
implement with an authentication profile are: LDAP, RADIUS, TACACS+,
SSL Client Certificate LDAP, and OCSP. See also PAM (Pluggable
Authentication Module).
authorization
Authorization is the process of identifying the level of access that a
logged-on user has been granted to system resources.
BIND (Berkeley Internet Name Domain)

BIND is the most common implementation of the Domain Name System
(DNS). BIND provides a system for matching domain names to IP
addresses. For more information, refer to
http://www.isc.org/products/BIND.
certificate
A certificate is an online credential signed by a trusted certificate authority
and used for SSL network traffic as a method of authentication.
BIG-IP® Local Traffic Manager: Implementations Glossary - 1

Glossary
certificate authority (CA)

A certificate authority is an external, trusted organization that issues a
signed digital certificate to a requesting computer system for use as a
credential to obtain authentication for SSL network traffic.
certificate revocation list (CRL)

See CRL (certificate revocation list).
Certificate Revocation List Distribution Point (CRLDP)

See CRLDP (Certificate Revocation List Distribution Point).
chain
A chain is a series of filtering criteria used to restrict access to an IP address.
The order of the criteria in the chain determines how the filter is applied,
from the general criteria first, to the more detailed criteria at the end of the
chain.
configuration object
A configuration object is a user-created object that the BIG-IP system uses
to implement a PAM authentication module. There is one type of
configuration object for each type of authentication module that you create.
See also PAM (Pluggable Authentication Module).
Configuration utility
The Configuration utility is the browser-based application that you use to
configure the BIG-IP system.
connection persistence
Connection persistence is an optimizing technique whereby a network
connection is intentionally kept open for the purpose of reducing
handshaking.
cookie persistence
Cookie persistence is a mode of persistence where the BIG-IP system stores
persistent connection information in a cookie.
CRL (certificate revocation list)

A CRL is a list that an authenticating system checks to see if the SSL
certificate that the requesting system presents for authentication has been
revoked.
CRLDP (Certificate Revocation List Distribution Point)

CRLDP is an industry-standard protocol that manages SSL certificate
revocation for devices on a network.
Glossary - 2
Glossary
CRLDP authentication module

A CRLDP authentication module is a user-created module that you
implement on a BIG-IP system to authenticate client traffic using the
CRLDP protocol. The purpose of a CRLDP authentication module is to
manage the revocation of client SSL certificates on a network.
custom profile
A custom profile is a profile that you create. A custom profile can inherit its
default settings from a parent profile that you specify. See also parent
profile and profile.
default profile
A default profile is a profile that the BIG-IP system supplies with default
setting values. You can use a default profile as is, or you can modify it. You
can also specify it as a parent profile when you create a custom profile. You
cannot create or delete a default profile. See also profile, custom profile.
default route
A default route is the route that the system uses when no other route
specified in the routing table matches the destination address or network of
the packet to be routed.
default VLAN
The BIG-IP system is configured with two default VLANs, one for each
interface. One default VLAN is named internal and one is named external.
See also VLAN (Virtual Local Area Network).
default wildcard virtual server

A default wildcard virtual server has an IP address and port number of
0.0.0.0:0. or *:* or "any":"any". This virtual server accepts all traffic that
does not match any other virtual server defined in the configuration.
domain name
A domain name is a unique name that is associated with one or more IP
addresses. Domain names are used in URLs to identify particular Web
pages. For example, in the URL http://www.siterequest.com/index.html,
the domain name is siterequest.com.
external VLAN
The external VLAN is a default VLAN on the BIG-IP system. In a basic
configuration, this VLAN has the administration ports locked down. In a
normal configuration, this is typically a VLAN on which external clients
request connections to internal servers.

Glossary
failover
Failover is the process whereby a standby unit in a redundant system takes
over when a software failure or a hardware failure is detected on the active
unit.
floating self IP address

A floating self IP address is an additional self IP address for a VLAN that
serves as a shared address by both units of a BIG-IP redundant system.
forwarding virtual server

A forwarding virtual server is a virtual server that 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. See also virtual server.
gateway pool
A gateway pool is a pool of routers that you can create to forward traffic.
After creating a gateway pool, you can specify the pool as a gateway, within
a TMM routing table entry.
health monitor
A health monitor checks a node to see if it is up and functioning for a given
service. If the node fails the check, it is marked down. Different monitors
exist for checking different services.
ICMP (Internet Control Message Protocol)

ICMP is an Internet communications protocol used to determine information
about routes to destination addresses.
interface
The physical port on a BIG-IP system is called an interface.
internal VLAN
The internal VLAN is a default VLAN on the BIG-IP system. In a basic
configuration, this VLAN has the administration ports open. In a normal
configuration, this is a network interface that handles connections from
internal servers.
iRule
An iRule is a user-written script that controls the behavior of a connection
passing through the BIG-IP system. iRules™ are an F5 Networks feature
and are frequently used to direct certain connections to a non-default load
balancing pool. However, iRules can perform other tasks, such as
implementing secure network address translation and enabling session
persistence.
Glossary - 4
Glossary
Kerberos protocol
The Kerberos protocol is a network authentication protocol that allows
individuals communicating over a non-secure network to prove their
identity to one another in a secure manner. Kerberos is aimed primarily at a
client-server model, providing mutual authentication; both the user and the
server verify each other's identity.
LACP (Link Aggregation Control Protocol)

LACP is an industry-standard protocol that aggregates links in a trunk, to
increase bandwidth and provide for link failover.
Layer 1 through Layer 7

Layers 1 through 7 refer to the seven layers of the Open System
Interconnection (OSI) model. Thus, Layer 2 represents the data-link layer,
Layer 3 represents the IP layer, and Layer 4 represents the transport layer
(TCP and UDP). Layer 7 represents the application layer, handling traffic
such as HTTP and SSL.
LDAP (Lightweight Directory Access Protocol)

LDAP is an Internet protocol that email programs use to look up contact
information from a server.
LDAP authentication module

An LDAP authentication module is a user-created module that you
implement on a BIG-IP system to authenticate client traffic using a remote
LDAP server.
LDAP client certificate SSL authentication module

An LDAP client certificate SSL authentication module is a user-created
module that you implement on a BIG-IP system to authorize client traffic
using SSL client credentials and a remote LDAP server.
link aggregation
Link aggregation is the process of combining multiple links in order to
function as though it were a single link with higher bandwidth. Link
aggregation occurs when you create a trunk. See also trunk and LACP (Link
Aggregation Control Protocol).
Link Aggregation Control Protocol (LACP)

See LACP (Link Aggregation Control Protocol).
load balancing method

A load balancing method is an algorithm that determines how to distribute
connections across a load balancing pool.

Glossary
load balancing pool

See pool.
load balancing virtual server

A load balancing virtual server is a virtual server that directs client traffic to
a load balancing pool. This is the most basic type of virtual server. See also
virtual server.
local traffic management

Local traffic management is the process of managing network traffic that
comes into or goes out of a local area network (LAN), including an intranet.
You can manage local traffic using BIG-IP® Local Traffic Manager.
MAC (Media Access Control)

MAC is a protocol that defines the way workstations gain access to
transmission media, and is most widely used in reference to LANs. For
IEEE LANs, the MAC layer is the lower sublayer of the data link layer
protocol.
management interface
The management interface is a special port on the BIG-IP system, used for
managing administrative traffic. Named MGMT, the management interface
does not forward user application traffic, such as traffic slated for load
balancing.
monitor
The BIG-IP system uses monitors to determine whether nodes are up or
down. There are several different types of monitors and they use various
methods to determine the status of a server or service. You can associate
monitors with nodes, pools, and individual pool members. See also node,
pool, and pool member.
monitor instance
You create a monitor instance when a health monitor is associated with a
pool member or node. It is the monitor instance that actually performs the
health check, not the monitor.
NAT (Network Address Translation)

A NAT is an alias IP address that identifies a specific node managed by the
BIG-IP system to the external network.
node
A node is a logical object on the BIG-IP system that identifies the IP address
of a physical resource on the network. Nodes are directly associated with
pool members and monitors. See also pool member and monitor.
Glossary - 6
Glossary
OCSP (Online Certificate Status Protocol)

OCSP is a protocol that authenticating systems can use to check on the
revocation status of digitally-signed SSL certificates. The use of OCSP is an
alternative to the use of a certificate revocation list (CRL).
See also CRL (certificate revocation list).
OCSP authentication module

An OCSP authentication module is a user-created module that you
OCSP responder. The purpose of an OCSP authentication module is to
check on the revocation status of a client SSL certificate.
OCSP responder
An OCSP responder is an external server used for communicating SSL
certificate revocation status to an authentication server such as the BIG-IP
system.
OCSP responder object

A responder object is a software application on the BIG-IP system that
communicates with an OCSP responder, for the purpose of checking
revocation status of a client or server SSL certificate.
PAM (Pluggable Authentication Module)

A PAM module is a software module that a server application uses to
authenticate client traffic. The modular design of a PAM module allows an
organization to add, replace, or remove that authentication mechanism from
a server application with minimal impact to that application. An example of
a PAM module is an application that uses a remote Lightweight Directory
Access Protocol (LDAP) server to authenticate client traffic. See also LDAP
(Lightweight Directory Access Protocol).
parent profile
A parent profile is a profile that can propagate its values to another profile.
A parent profile can be either a default profile or a custom profile. See also
profile.
partition
A partition is a logical container that you create, containing a defined set of
BIG-IP system objects. You use partitions to control user access to the
BIG-IP system. See also user role.
performance monitor
A performance monitor gathers statistics and checks the state of a target
device.

Glossary
persistence profile
A persistence profile is a configuration tool for implementing a specific type
of session persistence. An example of a persistence profile type is a cookie
pool
A pool is a logical group of pool members. The BIG-IP system load
balances requests to the pool members within a pool, based on the load
balancing method and persistence method you choose when you configure
the pool. See also node and pool member.
pool member
A pool member is one of the members of a load balancing pool. A pool
member name indicates a node IP address and a service number. See also
node.
port
A port can be represented by a number that is associated with a specific
service supported by a host. Refer to the Services and Port Index for a list of
port numbers and corresponding services.
port-specific wildcard virtual server

A port-specific wildcard virtual server is a wildcard virtual server that uses a
port number other than 0. See also wildcard virtual server.
pre-configured monitor
A pre-configured monitor is a system-supplied health or performance
monitor. You can use a pre-configured monitor as is, but you cannot modify
or delete one. See also monitor.
profile
A profile is a configuration tool containing settings for defining the behavior
of network traffic. The BIG-IP system contains profiles for managing
FastL4, HTTP, TCP, FTP, SSL traffic, as well as for implementing
persistence and application authentication.
profile setting
A profile setting is a configuration attribute within a profile that has a value
associated with it. You can configure a profile setting to customize the way
that the BIG-IP system manages a type of traffic.
profile type
A profile type is a category of profile that you use for a specific purpose. An
example of a profile type is an HTTP profile, which you configure to
manage HTTP network traffic.
Glossary - 8
Glossary
protocol profile
A protocol profile is a profile that you create for controlling the behavior of
FastL4, TCP, UDP traffic.
RADIUS (Remote Authentication Dial-in User Service)

RADIUS is a service that performs remote user authentication and
accounting. Its primary use is for Internet Service Providers, though it can
also be used on any network that needs a centralized authentication and/or
accounting service for its workstations.
RADIUS authentication module

A RADIUS authentication module is a user-created module that you
RADIUS server.
RAM cache
A RAM cache is a cache of HTTP objects stored in the BIG-IP system’s
RAM that subsequent connections reuse to reduce the amount of load on the
back-end servers.
rate class
You create a rate filter from the Configuration utility or command line
utility. When you assign a rate class to a rate filter, a rate class determines
the volume of traffic allowed through a rate filter. See also rate shaping.
rate shaping
Rate shaping is a type of extended IP filter. Rate shaping uses the same IP
filter method but applies a rate class, which determines the volume of
network traffic allowed. See also rate class.
redundant system
Redundant system refers to a pair of units that are configured for fail-over.
In a redundant system, there are two units, one running as the active unit and
one running as the standby unit. If the active unit fails, the standby unit takes
over and manages connection requests.
responder object
See OCSP responder object.
router
A router is a Layer 3 networking device. If no VLANs are defined on the
network, a router defines a broadcast domain.
secure network address translation (SNAT)

See SNAT (secure network address translation).

Glossary
self IP address
Self IP addresses are the IP addresses owned by the BIG-IP system that you
use to access the internal and external VLANs.
service
Service refers to services such as TCP, UDP, HTTP, and FTP.
session persistence
A series of related connections received from the same client, having the
same session ID. When persistence is enabled, a BIG-IP system sends all
connections having the same session ID to the same node, instead of load
balancing the connections. Session persistence is not to be confused with
connection persistence.
Setup utility
The Setup utility guides you through the initial system configuration
process. You can run the Setup utility from the Configuration utility start
page.
simple persistence
See source address affinity persistence.
SNAT (Secure Network Address Translation)

A SNAT is a feature you can configure on the BIG-IP system. A SNAT
defines a routable alias IP address that one or more nodes can use as a
source IP address when making connections to hosts ona network.
SNMP (Simple Network Management Protocol)

SNMP is the Internet standard protocol, defined in STD 15, RFC 1157,
developed to manage nodes on an IP network.
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.
spanning tree
A spanning tree is a logical tree structure of Layer 2 devices on a network,
created by a spanning tree protocol algorithm and used for resolving
network loops.
SSH
SSH is a protocol for secure remote login and other secure network services
over a non-secure network.
Glossary - 10
Glossary
SSL (Secure Sockets Layer)

SSL is a network communications protocol that uses public-key technology
as a way to transmit data in a secure manner.
SSL profile
An SSL profile is a configuration tool that you use to terminate and initiate
SSL connections from clients and servers.
standby unit
A standby unit in a redundant system is a unit that is always prepared to
become the active unit if the active unit fails.
TACACS (Terminal Access Controller Access Control System)

TACACS is an older authentication protocol common to UNIX systems.
TACACS allows a remote access server to forward a user’s login password
to an authentication server.
TACACS+
TACACS+ is an authentication mechanism designed as a replacement for
the older TACACS protocol. There is little similarity between the two
protocols, however, and they are therefore not compatible.
TACACS+ authentication module

A TACACS+ authentication module is a user-created module that you
TACACS+ server.
tagged interface
A tagged interface is an interface that you assign to a VLAN in a way that
causes the system to add a VLAN tag into the header of any frame passing
through that interface. Tagged interfaces are used when you want to assign a
single interface to multiple VLANs. See also VLAN (virtual local area
network).
TMM (Traffic Management Microkernel) service

The TMM service is the process running on the BIG-IP system that
performs most traffic management for the product.
transparent node
A transparent node appears as a router to other network devices, including
the BIG-IP system.
trunk
A trunk is a combination of two or more interfaces and cables configured as
one link.

Glossary
tunnel
A tunnel is a network configuration in which two local traffic management
systems can pass optimized traffic over a wide-area network.
user role
A user role is a type and level of access that you assign to a BIG-IP system
user account. By assigning user roles, you can control the extent to which
BIG-IP system administrators can view or modify the BIG-IP system
configuration.
virtual address
A virtual address is an IP address associated with one or more virtual servers
managed by the BIG-IP system. See also virtual server.
virtual port
A virtual port is the port number or service name associated with one or
more virtual servers managed by the BIG-IP system. A virtual port number
should be the same TCP or UDP port number to which client programs
expect to connect.
virtual server
Virtual servers are a specific combination of virtual address and virtual port,
associated with a content site that is managed by a BIG-IP system or other
type of host server.
VLAN (virtual local area network)

A VLAN is a logical grouping of interfaces connected to network devices.
You can use a VLAN to logically group devices that are on different
network segments. Devices within a VLAN use Layer 2 networking to
communicate and define a broadcast domain.
VLAN group
A VLAN group is two or more VLANs that you put together into a VLAN
group. A primary use of a VLAN group is to successfully route traffic when
both the source and the destination hosts reside on the same network.
VLAN name
A VLAN name is the symbolic name used to identify a VLAN. For
example, you might configure a VLAN named marketing, or a VLAN
named development. See also VLAN (virtual local area network).
VLAN tag
An IEEE standard, a VLAN tag is an identification number inserted into the
header of a frame that indicates the VLAN to which the destination device
belongs. VLAN tags are used when a single interface forwards traffic for
multiple VLANs.
Glossary - 12
Glossary
wildcard virtual server

A wildcard virtual server is a virtual server that uses an IP address of
0.0.0.0, * or "any". A wildcard virtual server accepts connection requests
for destinations outside of the local network. Wildcard virtual servers are
included only in Transparent Node Mode configurations.

Glossary
Glossary - 14
Index
Index
Administrator role
/config/bigip.conf file 27-3 and object management 23-4
/etc/radvd.conf file 20-1 Administrator role access 23-2
aggregation, of links 17-1
application profile verification 30-10
A application profiles
acceleration and host maps 29-8, 30-8
and application to traffic 29-3 assigning to security policies 29-12
enabling 29-4 configuring 29-9, 30-9
acceleration policies creating 30-1
and Level 1 Delivery 29-7, 30-7 defined 29-7, 30-7
and Level 2 Delivery 29-7, 30-7 for WebAccelerator 29-7
and signed acceleration policies 29-8, 30-8 application security
and Symmetric Deployment 29-8, 30-7 enabling 29-4
and user-defined acceleration policies 29-8, 30-8 Application Security Manager
customizing 29-8 and HTTP class profiles 29-3
for WebAccelerator 30-10 applications
access and acceleration policies 29-7
for client hosts 29-10 ARP protocol 2-5
to partitions 23-5 authentication
access control for remote user accounts 24-1
configuring 24-7 authentication attributes 24-9, 24-10
tailoring 23-1 authentication module types 25-7
access control combinations 24-8 authentication server types 24-2
access control groups authentication servers
See partitions. as pool members 27-1
access control process authorization data
See authorization steps. propagating 24-1
access levels authorization failure 24-9
for partition Common 23-2 authorization levels
See also user access. determining 23-3
access-control properties authorization properties
configuring 24-6 configuring 24-6
Access-Request packets 25-8 authorization steps 23-2
ACK packets 2-2, 2-6
Active Directory remote authentication 24-2
adaptive connection reaping 22-2, 22-3 B
adaptive method 28-2 Back Orifice attacks 22-12
adaptive reaper 22-9 BIG-IP system
additional information adding to network 4-1
for Bigpipe Utility Reference Guide 1-2 configuring for same network 4-3
for Configuration Guide for BIG-IP Local Traffic to replace switches 4-2
Management 1-2 BIG-IP system bypass 2-1
for Configuration Worksheet 1-2 BIG-IP system objects 23-1
for Installation, Licensing, and Upgrades for BIG-IP bigpipe -? command 24-8
Systems 1-2 bigpipe shell
for Platform Guide 1-2 and user roles 23-2
for TMOS Management Guide for BIG-IP Systems broadcast addresses 2-4
1-2 built-in switching
address translation 2-1, 2-2, 7-5 for multiple customer hosting 5-5
admin account 23-2
administrative domains
defined 23-1
administrative partitions
and tunneling 28-3
BIG-IP® Local Traffic Manager: Implementations Index - 1

Index
C content compression
cache directives 29-7 and RAM Cache 13-1
cache servers 6-1 content requests 29-7
certificate installation 12-1 cookie encryption and decryption 26-6
Certificate Revocation List Distribution Point protocol cookie persistence 9-1
See CRLDP authentication module. cookie persistence profiles 9-2
client authentication cookies 22-8
and Kerberos delegation 26-10 corporate intranet 6-1
client credentials 25-7 credential fetching 26-10
client hosts credential passing 26-10
and application access 30-10 credential verification 26-10
client principal names 26-6 CRLDP authentication module
client requests defined 25-20
and BIG-IP system 2-6 CRLDP configuration objects
decrypting 11-6 defined 25-21
Client SSL profiles CRLDP profile type
and Kerberos delegation 26-5 defined 25-22
assigning 11-6, 12-7 CRLDP responder objects
creating 11-3, 12-3 defined 25-20
defined 11-1, 12-1 CRLDP server objects
for tunneling 28-9 defined 25-20
clock synchronization 29-6 cross-domain authentication 26-3
command line interface cross-realm authentication
See bigpipe shell. setting 26-1
common configuration 6-1 custom HTTP profiles
compression described 9-1
and iRules 10-1 using 8-1
and RAM Cache 13-1 custom monitors 19-1
configuring 12-4 custom persistence profiles
for dynamically-generated data 28-2 described 9-1
over a WAN 28-1 using 8-1
turning off 28-2 custom RADIUS profiles
compression methods assigning 25-9
defined 28-2 customers
compression statistics hosting for 5-1
for tunneling 28-12
compression tasks 10-1 D
configuration data
data attacks 22-11
importing and exporting 24-11
data center topology 4-1
configuration examples, Internet 3-1
data compression
Configuration utility
and RAM Cache 13-1
and online help 1-5
over a WAN 28-1
and Welcome screen 1-5
data compression statistics
Configuration Worksheet 1-2
for tunneling 28-12
connection flooding 22-9
data encryption
connection request types 6-1
and tunneling 28-1
connection timeout 2-6, 22-8
data optimization
connections
through tunneling 28-1
adding 7-1
data propagation 24-7, 24-11
authenticating 25-7
data types
reaping 22-2
and tunneling 28-2
See also Internet connections.
data verification
content
and WebAccelerator 29-10, 30-10
demand for 13-1
static 13-1
Index - 2
Index
default HTTP profiles F

described 9-1 Fast L4 profiles
using 8-1 assigning 2-4
default persistence profiles creating 2-2, 2-3
described 9-1 for nPath routing 2-2
using 8-1 files
default routes including and excluding 10-1
for nPath routing 2-2 FIN packets 2-2
setting 2-2, 16-4 flooding 22-9
default wildcard servers 6-2 formatting conventions 1-3
deflate method 28-2 forwarding virtual server
Denial-of-Service attacks 22-1, 22-8 for tunneling 28-9
Denial-of-Service prevention 22-4 FTP monitors 14-2, 15-2
deployment scenarios FTP pools
defined 29-13 assigning 14-4
Deployment Wizard creating 14-3, 15-3
about 29-13 FTP profiles
and deployment scenarios 29-13 assigning 14-4
starting 29-13 defined 14-1
destination address translation 2-1 FTP traffic 14-1
DNS name resolution FTP virtual servers
configuring 26-3 creating 14-4, 15-5
DNS servers
adding and testing 26-2
as primary domain controllers 26-1 G
configuring 30-2 gateways
domain authentication 26-3 and nPath routing 2-5
domain controllers 26-1 groups
domain verification and mapping 29-11 assigning privileges to 24-7
domains for user access control 24-1
adding BIG-IP systems to 26-3 Guest role tasks 23-3
creating service principals in 26-3
identifying 29-8
domaintool command 26-3 H
duplicate IP addresses health monitors
assigning 21-1 for remote authentication servers 27-1
help, online 1-5
high demand objects 13-1
E high-water mark
e-commerce traffic See adaptive connection reaping.
load balancing 3-1 host map
encryption and requested hosts 29-8, 30-8
and tunneling 28-1 host map verification 29-11
encryption keys 26-6 host names
endpoint pools specifying 29-8
creating 28-4 hosts file verification 29-11
on server-side systems 28-10 HTML pages
expressions caching 29-7
for packet filtering 18-1 HTTP class profile
creating for other modules 29-3
HTTP class profiles
and configuration options 29-4
and important considerations 29-4
creating 29-4, 30-4
for Application Security Manager 29-3
for WebAccelerator system 29-3

Index
HTTP compression tasks 10-1 IP address translation 2-1

HTTP connections 9-3 IP addresses
HTTP headers 13-1 and loopback interfaces 2-5
HTTP methods 13-1 and nPath routing 2-5
HTTP pools assigning 21-1
assigning for compression 10-3 removing from VLANs 17-7
assigning for RAM Cache 13-3 IP aliases and nPath routing 2-5
assigning for source address persistence 8-3 IP network
creating for cookie persistence 9-3 changing 4-1
creating for source address persistence 8-2 IP network topology
HTTP profiles with single interface 4-1, 16-1
creating for compression 10-2, 12-4 IP packets
creating for LDAP authentication 25-15 recognition by clients 16-5
creating for RAM Cache 13-2 routing incorrectly 2-5
defined 9-1 IPV6 nodes 20-2
described 8-1 iRules
HTTP RAM Cache for compression 10-1
See RAM Cache. iSession context 28-8, 28-11
HTTP security profile iSession port 3701 28-11
described 30-12 iSession profiles
HTTP service profiles and port transparency 28-11
creating 30-4 creating 28-5
HTTP traffic for tunneling 28-6, 28-9
controlling for compression 10-1
controlling for cookie persistence 9-1
controlling for source address persistence 8-1 J
HTTP virtual servers J2EE
creating for compression 10-3 and delivery acceleration policies 29-7, 30-7
creating for cookie persistence 9-3 Java 2 Platform Enterprise Edition
creating for source address persistence 8-3 See J2EE.
HTTPS pools
assigning 11-6, 12-7 K
creating 11-5, 12-6
KDCs 26-3
HTTPS traffic 11-6
Kerberos delegation
HTTPS virtual servers
and Client SSL profiles 26-5
creating 11-6, 12-7
and virtual servers 26-9
defined 26-1
I Kerberos Key Distribution Centers (KDCs) 26-3
ICMP floods 22-9 Kerberos realms
idle timeout values 2-2, 2-3 and DNS domains 26-3
inbound traffic 7-3 Kerberos web servers
inheritance prevention load balancing 26-1
for monitors 19-5 key installation 12-1
Intelligent Browser Referencing feature 29-7
interfaces L
and partitions 23-2
L2 forwarding 4-1
assigning as tagged 5-2
LACP protocol 17-3
using link aggregation 17-1
Land attacks 22-10
Internet connections
LDAP configuration objects
adding more 7-1
defined 25-2
example 7-1
LDAP profile type
load balancing 7-1
defined 25-5
intranet configuration
LDAP remote authentication 24-2
creating 6-2
Lempel-Ziv-Oberhumer method 28-2
for corporate intranets 6-1
Level 1 Delivery acceleration policy 29-7, 30-7
Index - 4
Index
Level 2 Delivery acceleration policy 29-7, 30-7 nodes

link aggregation and Operator role 23-3
about 17-1 in route domains 21-1
and network configurations 17-6 nPath routing 2-1, 2-5
and VLAN groups 17-7 nPath routing tasks 2-2
configuring 17-2 NTP
local endpoints 28-8, 28-11 configuring 29-6
loopback interfaces 2-2, 2-5 defined 29-6
low-water mark NTP protocol
See adaptive connection reaping. synchronizing system clocks 30-2
lzo method 28-2 numeric values
for user privileges 24-9
M
Manager role access 23-2 O
Manager role tasks 23-3 object creation
monitor inheritance 19-4 and partition location 23-5
monitor settings 19-1 object re-use 13-1
monitor types 19-1 objects
monitors and Guest role 23-3
assigning to pools 19-4 defined 23-1
creating 19-3 demand for 13-1
creating for FTP servers 14-2, 15-2 viewing and managing 23-4
defined 19-1 OCSP authentication module
removing 19-5 See SSL OCSP authentication module.
MS Loopback interface 2-5 OCSP responder objects
multiple customer hosting creating 25-17
about 5-1 one-network topology 17-6
configuring 5-2 Online Certificate Status Protocol
creating pools for 5-3 See SSL OCSP authentication module.
creating VLAN tags for 5-2 online help 1-5
using built-in switching 5-5 Operator role tasks 23-3
Other External Users account 24-6
outbound throughput
N increasing 2-1
name resolution overlapping IP addresses 21-1
configuring 26-3, 30-2
name servers
listing 26-2 P
NAS-Identifier string 25-8 packet filter rules
netmask 2-4 creating 18-4
network purpose of 18-1
changing 4-1 packet filters 18-1, 18-4
network adapter list 2-5 packets
network configurations forwarding and rejecting 18-1
and link aggregation 17-2, 17-6 receiving and copying 4-4
for IP network topology 16-1 recognition by clients 16-5
network prefixes 20-1 paired tunneling
Network Time Protocol (NTP) protocol described 28-1
See NTP. partition access
network traffic configuring 23-3
and additional connections 7-1 Partition Access list 23-4
and packet filters 18-1 partition Common
managing 2-1 described 23-2
network traffic authentication types 25-1 partition contents 23-1
node configuration partition property 24-6
and radvd service 20-1

Index
partitioned objects ports

creating 23-5 for e-commerce 3-1
described 23-2 pre-configured monitors 19-1
partitions pre-defined acceleration policies
and tunneling 28-3 and Level 1 Delivery 29-7, 30-7
and user roles 23-2 and Level 2 delivery 29-7, 30-7
benefits of 23-2 selecting 29-7, 30-7
creating 23-2 primary domain controllers (PDCs) 26-1
defined 23-1 privileges
selecting 23-5 assigning 24-7
password credentials 25-7 configuring 24-6
PDCs 26-1 for individual accounts 24-6
performance monitors 19-2 See also access control.
permissions profile verification 30-10
determining 23-1 profiles
See also user access. creating for HTTP 10-2, 25-15
persistence protocol security
and nPath routing 2-6 and WebAccelerator application profile 30-12
implementing 8-1 protocol security checks 30-5
See also cookie persistence. Protocol Security Module
persistence profiles and application profiles 30-1
assigning for compression 12-7 and security profiles 30-1
assigning for FTP 14-4 running with WebAccelerator system 30-3
assigning for HTTP 9-4 protocol vulnerabilities
assigning for HTTPS 11-6 scanning for 30-4
assigning for RAM Cache 13-3 protocols
creating 9-2 for remote authentication servers 25-1
Ping of Death attacks 22-10 provisioning
Platform Guide 1-2 for modules 30-2
pool member exclusion 19-4, 19-5
pool members
and Operator role 23-3 R
and route domains 21-1 RADIUS authentication module
as tunnel endpoints 28-10 implementing 25-7
pools RADIUS authentication profiles
and HTTP class profiles 29-4 assigning 25-9
configuring 29-5 RADIUS configuration objects
creating for a basic configuration 6-2 creating 25-8
creating for e-commerce 3-1, 3-2 specifying in profile 25-9
creating for FTP servers 14-3 RADIUS configuration overview 25-7
creating for HTTP 8-2, 9-3 RADIUS profiles
creating for HTTPS 11-5, 12-6 creating 25-9
creating for intranet configuration 6-2 RADIUS secret 25-7
creating for ISP load balancing 7-2 RADIUS server configuration 27-2
creating for link aggregation 17-4 RADIUS server objects
creating for monitors 19-4 creating 25-7
creating for multiple customer hosting 5-3 specifying in configuration object 25-8
creating for nPath routing 2-4 RADIUS servers
creating for rate shaping 15-3 and authentication 25-7
creating for routers 18-2 and traffic authentication 25-7
creating for single network 16-2 RADIUS user authorization
of web servers 4-5 configuring 24-4
port translation 2-2 RADIUS-based authentication
port transparency configuring 24-4
defined 28-11 radvd service 20-1
Index - 6
Index
RAM Cache route domains

and http-acceleration profile 29-5 and tunneling 28-3
and WebAccelerator 29-5 defined 21-1
defined 13-1 router pools 18-2
RAM Cache compliancy 13-1 routers
RAM Cache feature increasing throughput 2-1
for tunneling 28-7 routes
RAM Cache virtual servers 13-3 for nPath routing 2-5
rate classes for packets 4-5
and virtual servers 15-5 routing conflicts 4-5
creating 15-4 routing tables
rate shaping and route domains 21-1
and FTP traffic 15-4 RTO 2-6
as optional feature 15-1
Read access 23-2
realms S
and DNS domains 26-3 SCF
and trust relationships 26-1 and access control 24-1
regular expressions 10-1 purpose of 24-11
remote attribute mapping 24-7 SCFs
remote authentication creating 24-11
for system user accounts 24-2 secondary RADIUS servers
remote authentication attributes 24-9, 24-10 configuring 24-4
remote authentication issues 27-1 security
remote authentication requirements 27-2 and application to traffic 29-3
remote authentication server types 24-2, 25-1 security checks
remote policies 29-10 and HTTP security profile 30-12
remote user authentication to HTTP traffic 30-5
configuring 24-1 security policies
remoterole command and application profiles 29-12
purpose of 24-1, 24-6, 24-7 See also tunneling.
remoterole command syntax 24-7 self IP addresses
request timeout 29-11 and partitions 23-2
Requested Hosts creating 17-8
and domains 29-8, 30-8 creating for VLAN groups 4-5
defined 29-8, 30-8 for external VLAN 7-5
requests removing 4-3, 17-7
encrypting and decrypting 11-1, 12-1 self-signed certificates 11-2, 12-2
resource exhaustion 22-8 server hosting 3-1
response types 13-1 server load 13-1
responses server pools
compressing 10-1 for nPath routing 2-4
encrypting and decrypting 11-1, 12-1 server principal names 26-6
retransmission timeout server responses
See RTO. encrypting 11-6
role property 24-6 encrypting and decrypting 11-1, 12-1
roles Server SSL profiles
and tunneling 28-3 for tunneling 28-6
root name servers service port 3701 28-11
listing 26-2 service ports
route configuration for tunneling 28-11
for nPath routing 2-2 service principals
route domain IDs creating 26-3
format of 21-1

Index
session persistence SYN cookies 22-8, 22-9

implementing 8-1 SYN floods 22-8
See also cookie persistence. SYN packets 2-2, 2-6
See also source address affinity persistence. system access
signed acceleration policies controlling 23-1
defined 29-8, 30-8 system object creation
simple persistence and partition location 23-5
See source address affinity persistence. system objects
Single Configuration File (SCF) viewing and managing 23-4
See SCF. system resource exhaustion 22-8
Smurf attack 22-9
SNAT Automap
about 7-1 T
for VLANs 7-5 TACACS+ configuration object
SNAT source translations 16-1 defined 25-11
SNATs TACACS+ configuration overview 25-11
creating 18-2 TACACS+ profiles
source address affinity persistence 8-1 creating 25-12
source address translation 2-1 tagged interfaces 5-2, 17-1
source IP addresses TCP connections 22-8
and session persistence 8-2 TCP optimization profiles
SSL certificates for tunneling 28-6, 28-9
importing 24-2 TCP timers 2-6
SSL Client Certificate LDAP configuration objects TCP traffic
creating 25-14 and nPath routing 2-2, 2-6
SSL Client Certificate LDAP profiles tcpdump utility 18-1
creating 25-15 Teardrop attacks 22-11
SSL handshaking terminal access property 24-6
for compression 12-1, 12-2 throughput
for HTTPS 11-1, 11-2, 11-6 increasing 2-1
SSL keys and certificates throughput optimization 16-5
creating 11-2, 12-2 time synchronization
installing 12-1 and PDCs 26-1
SSL OCSP authentication module timers 2-6
defined 25-17 topology 4-1
SSL OCSP configuration objects traffic
creating 25-18 and same network 4-4
SSL OCSP profile type returning 2-1
defined 25-18 traffic load 13-1
SSL OCSP responder objects trunk members 17-3
creating 25-17 trunks 17-3
SSL profiles trust relationships 26-1
See Client SSL profiles. trusted domains
SSL traffic authentication 24-2 adding BIG-IP systems to 26-3
standard pre-defined acceleration policies 29-7, 30-7 trusted user impersonation 26-6
state keeping 22-8 tunneling
static content 13-1 for data optimization 28-1
style conventions 1-3 See also endpoint pools. 28-4
Sub 7 attacks 22-11
subdomains
mapping 29-8
symmetric deployment
and content assembly 29-10
defined 29-8
Symmetric Deployment acceleration policy 30-7
SYN Check feature, activating 22-9
Index - 8
Index
U and SNATs 16-1

UDP floods 22-9 and web server pools 4-6
UDP fragment attacks 22-10 as client principal names 26-6
UDP timers 2-6 creating for e-commerce 3-1, 3-3
UDP traffic creating for HTTP 9-3
and nPath routing 2-6 creating for inbound and outbound traffic 7-3
universal access 23-5 creating for intranet configuration 6-3
unmapped domains 30-8 creating for multiple customer hosting 5-3
See unmapped requests. creating for single network 16-3
unmapped requests 30-8 for a basic configuration 6-3, 18-3
URIs for compression 10-3
including and excluding 10-1 for FTP 14-4
user access for FTP and rate shaping 15-5
configuring 23-3 for HTTP 8-3, 29-5
denial of 24-8 for HTTPS 11-6, 12-7
tailoring 23-1 for IPv6 nodes 20-3
to partition Common 23-2 for link aggregation 17-5
user account duplication 24-7 for multiple customer hosting 5-3
user account objects for nPath routing 2-4
and manager role 23-3 for RAM Cache 13-3
user account properties for tunneling 28-6, 28-10
modifying 23-3 mapping to IP addresses 2-4
user accounts modifying for CRLDP authentication 25-23
defined 23-1 modifying for RADIUS authentication 25-10
user authentication modifying for SSL Client Certificate LDAP
configuring 24-1 authentication 25-16
user impersonation 26-6 modifying for SSL OCSP authentication 25-19
user name credentials 25-7 modifying for TACACS+ authentication 25-13
user partition property 24-6 VLAN groups
user privileges creating 4-4, 17-7
assigning 24-7 VLAN tags
user role property 24-6 creating 5-2, 17-3
user roles VLANs
and partition access 23-2 and partitions 23-2
and tunneling 28-3 and tagged interfaces 5-2
defined 23-1 removing self IP addresses from 4-3, 4-4
for partition creation 23-2 using link aggregation 17-1
user-defined acceleration policies vulnerabilities
described 29-8, 30-8 scanning for 30-4
V W
variable substitution web application content
for access control 24-8 hosting 29-4, 30-5
vendor-specific attributes 24-7, 24-8 web applications
virtual authentication servers and hosted content 29-4, 30-5
and VLANs 27-2 web server arrays 3-1
defined 27-1 web server pools
virtual server creating 4-5
defining 30-5 web servers
virtual server addresses 2-2 and Kerberos authentication 26-1
virtual server modification 25-10 and server principal names 26-6
virtual servers WebAccelerator
and FQDNs 26-3 and HTTP class profiles 29-3
and HTTP class profiles 29-4 WebAccelerator application profiles
and Kerberos delegation 26-9 and protocol security 30-12

Index
and application profiles 30-1
and NTP protocol 30-2
and security profiles 30-1
running with Protocol Security Manager 30-3
Welcome screen 1-5
wide area networks
optimizing traffic for 28-1
wildcard virtual servers
defined 6-2
WIndows Integrated Authentication 26-1
WinNuke attacks 22-11
Index - 10

BIG IP Traffic

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BIG IP Traffic

Uploaded by

Copyright:

Available Formats

BIG-IP® Local Traffic Manager:

Export Regulation Notice

Canadian Regulatory Compliance

BIG-IP® Local Traffic Manager: Implementations i

BIG-IP® Local Traffic Manager: Implementations iii

BIG-IP® Local Traffic Manger: Implementations vii

BIG-IP® Local Traffic Manger: Implementations ix

BIG-IP® Local Traffic Manger: Implementations xi

Configuring SSL-based authorization using a remote LDAP server ............................... 25-14

BIG-IP® Local Traffic Manger: Implementations xiii

• Introducing BIG-IP system implementations

• About this guide

• Finding help and technical support resources

Introducing BIG-IP system implementations

BIG-IP® Local Traffic Manager is one of several products that constitute

Using the Configuration utility

BIG-IP® Local Traffic Manager: Implementations 1-1

About this guide

Using the examples

Identifying new terms

Identifying references to products

Identifying references to objects, names, and commands

Identifying references to other documents

Identifying command syntax

BIG-IP® Local Traffic Manager: Implementations 1-3

For example, the following command shows the configuration of the

Item in text Description

| Separates parts of a command.

[] Indicates that syntax inside the brackets is optional.

... Indicates that you can type a series of items.

Table 1.1 Command line syntax conventions

Finding help and technical support resources

◆ F5 Networks Technical Support web site

BIG-IP® Local Traffic Manager: Implementations 1-5

• Introducing nPath routing

• Configuring nPath routing

• Setting timers for nPath configurations

Introducing nPath routing

Figure 2.1 An example of nPath implementation

BIG-IP® Local Traffic Manager: Implementations 2-1

Configuring nPath routing

• Ensure that the bigdb configuration key connection.autolasthop is

Creating a custom Fast L4 profile

To create a custom Fast L4 profile

BIG-IP® Local Traffic Manager: Implementations 2-3

Creating a server pool for nPath routing

Creating a virtual server

To create a standard virtual server

d) Clear the Port Translation check box to disable port translation.

Configuring the virtual server on the content server loopback

Setting the route for inbound traffic

Enabling the connection.autolasthop bigdb key

BIG-IP® Local Traffic Manager: Implementations 2-5

Setting timers for nPath configurations

Guidelines for configuring timeouts for UDP traffic

Guidelines for configuring timeouts for TCP traffic

• Working with a basic web site and e-commerce

• Configuring a basic e-commerce site

Working with a basic web site and e-commerce

Figure 3.1 A basic load balancing configuration

BIG-IP® Local Traffic Manager: Implementations 3-1

Configuring a basic e-commerce site

Creating load balancing pools