BIG-IP Local Traffic Manager Implementations

BIG-IP Local Traffic ManagerTM: Implementations
Version 10.2
MAN-0293-02
Product Version
This manual applies to version 10.2 of the BIG-IP product family.
Publication Date
This guide was published on June 9, 2010.
Legal Notices
Copyright
Copyright 2010, 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, Access Policy Manager, APM, Acopia, Acopia Networks, Application Accelerator, Ask F5, Application Security Manager, ASM, ARX, Data Guard, Edge Client, Edge Gateway, 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, Protocol Security Module, PSM, Secure Access Manager, SAM, SSL Accelerator, SYN Check, Traffic Management Operating System, TMOS, TrafficShield, Transparent Data Reduction, uRoam, VIPRION, WANJet, WAN Optimization Module, WOM, WebAccelerator, WA, 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. All other product and company names herein may be trademarks of their respective owners.
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.
BIG-IP Local Traffic Manager: Implementations
Canadian Regulatory Compliance

This class A digital apparatus complies with Canadian I CES-003.
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.
ii
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. 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. This product contains software developed by MaxMind LLC, and is protected under the GNU Lesser General Public License, as published by the Free Software Foundation. This product includes the GeoPoint Database developed by Quova, Inc. and its contributors.
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 Creating a virtual server ......................................................................................................4-6
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 Creating virtual servers ........................................................................................................5-3 Directly hosting multiple customers ..........................................................................................5-5 Creating VLANs with untagged interfaces .......................................................................5-6
vii
Table of Contents
6
Web Hosting for Multiple Customers using Route Domains
Introduction .....................................................................................................................................6-1 Prerequisite information ...............................................................................................................6-1 Procedure .........................................................................................................................................6-2 Example .............................................................................................................................................6-6 For more information ....................................................................................................................6-8
7
A Simple Intranet Configuration
Working with a simple intranet configuration .........................................................................7-1 Creating the simple intranet configuration ...............................................................................7-2 Creating pools ........................................................................................................................7-2 Creating virtual servers ........................................................................................................7-3
8
Load Balancing ISPs
Introducing ISP load balancing ......................................................................................................8-1 Configuring ISP load balancing .....................................................................................................8-2 Creating pools for an additional Internet connection ...................................................8-2 Creating virtual servers for an additional Internet connection ..................................8-3 Configuring address translation for outbound traffic .............................................................8-5
9
Load Balancing HTTP Traffic with Source Address Affinity Persistence
Introducing basic HTTP load balancing ......................................................................................9-1 Configuring HTTP load balancing with source address affinity persistence ......................9-2 Creating a pool .......................................................................................................................9-2 Creating a virtual server ......................................................................................................9-3
10
Load Balancing HTTP Traffic with Cookie Persistence
Introducing basic HTTP load balancing ................................................................................... 10-1 Configuring HTTP load balancing with cookie persistence ............................................... 10-2 Creating a custom persistence profile ........................................................................... 10-2 Creating a pool .................................................................................................................... 10-3 Creating a virtual server ................................................................................................... 10-3
11
Compressing HTTP Responses
Introducing HTTP data compression ...................................................................................... 11-1 Creating a custom HTTP profile .............................................................................................. 11-2 Creating a virtual server ............................................................................................................. 11-3
viii
Table of Contents
12
Configuring HTTPS Load Balancing
Introducing HTTPS load balancing ........................................................................................... 12-1 Creating an SSL key and certificate ......................................................................................... 12-2 Creating a custom SSL profile ................................................................................................... 12-4 Creating a pool ............................................................................................................................. 12-6 Creating a virtual server ............................................................................................................. 12-7
13
Configuring HTTPS Load Balancing with Data Compression
Introducing HTTPS load balancing with compression ......................................................... 13-1 Creating an SSL key and certificate ......................................................................................... 13-2 Creating a custom Client SSL profile ...................................................................................... 13-4 Creating a custom HTTP profile for compression .............................................................. 13-5 Creating a pool ............................................................................................................................. 13-7 Creating a virtual server ............................................................................................................. 13-8
14
Using RAM Cache for HTTP Traffic
Introducing HTTP RAM Cache ................................................................................................. 14-1 Creating a custom HTTP profile .............................................................................................. 14-2 Creating a virtual server ............................................................................................................. 14-3
15
Load Balancing Passive Mode FTP Traffic
Introducing FTP load balancing ................................................................................................. 15-1 Creating a custom FTP monitor ............................................................................................... 15-2 Creating a pool ............................................................................................................................. 15-3 Creating a virtual server ............................................................................................................. 15-4
16
Load Balancing Passive Mode FTP Traffic with Rate Shaping
Introducing FTP load balancing with rate shaping ................................................................ 16-1 Creating a custom FTP monitor ............................................................................................... 16-2 Creating a pool ............................................................................................................................. 16-3 Creating a rate class .................................................................................................................... 16-4 Creating a virtual server ............................................................................................................. 16-5
17
Setting up a One-IP Network Topology
Introducing the one-IP network topology ............................................................................. 17-1 Creating a pool for a one-IP network topology ................................................................... 17-2 Creating a virtual server ............................................................................................................. 17-3 Defining a default route .............................................................................................................. 17-4 Configuring a client SNAT ......................................................................................................... 17-5
ix
Table of Contents
18
Using Link Aggregation with Tagged VLANs
Introducing link aggregation with tagged VLAN interfaces ................................................ 18-1 Using the two-network aggregated tagged interface topology ......................................... 18-2 Aggregating the links .......................................................................................................... 18-3 Assigning a trunk to the VLANs ...................................................................................... 18-3 Creating a pool of web servers to load balance .......................................................... 18-4 Creating a virtual server to load balance the web servers ....................................... 18-5 Using the one-network aggregated tagged interface topology ......................................... 18-6 Removing the self IP addresses from the VLANs ....................................................... 18-7 Creating a VLAN group .................................................................................................... 18-7 Creating a self IP for the VLAN group .......................................................................... 18-8
19
Setting Up Packet Filtering
Introducing packet filtering ........................................................................................................ 19-1 Configuring packet filtering ........................................................................................................ 19-2 Creating a SNAT ................................................................................................................. 19-2 Creating a gateway pool .................................................................................................... 19-2 Creating a forwarding virtual server .............................................................................. 19-3 Creating a packet filter rule ............................................................................................. 19-4
20
Implementing Health and Performance Monitors
Introducing health and performance monitors ..................................................................... 20-1 Creating a custom monitor ....................................................................................................... 20-3 Creating a pool ............................................................................................................................. 20-4 Assigning a monitor to a pool .......................................................................................... 20-4 Excluding a pool member from a monitor .................................................................... 20-5 Creating a virtual server ............................................................................................................. 20-6
21
Load Balancing Traffic to IPv6 Nodes
Configuring the radvd service ................................................................................................... 21-1 Configuring IPv4-to-IPv6 load balancing ................................................................................. 21-2 Creating a pool of IPv6 nodes ......................................................................................... 21-2 Creating a virtual server ................................................................................................... 21-3
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 How the BIG-IP system handles several common attacks ................................................. 22-8 SYN flood ............................................................................................................................. 22-8 x
Table of Contents
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 Partitions to Control User Access
Introducing administrative partitions ....................................................................................... 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-6 Modifying a virtual server for LDAP authentication ................................................... 25-6 Configuring authentication that uses a remote RADIUS server ....................................... 25-8 Creating a RADIUS server object ................................................................................... 25-8 Creating a RADIUS configuration object ...................................................................... 25-9 Creating a RADIUS profile ............................................................................................. 25-10 Modifying a virtual server for RADIUS authentication ............................................ 25-10 Configuring authentication that uses a remote TACACS+ server ................................ 25-12 Creating a TACACS+ configuration object ................................................................ 25-12 Creating a TACACS+ profile ......................................................................................... 25-13 Modifying a virtual server for TACACS+ authentication ........................................ 25-14 Configuring SSL-based authorization using a remote LDAP server ............................... 25-15 Creating an SSL CLient Certificate LDAP configuration object ............................ 25-15 Creating an SSL Client Certificate LDAP authentication profile ........................... 25-16 Modifying a virtual server for SSL Client Certificate LDAP authorization .......... 25-17
xi
Table of Contents
Configuring SSL certificate revocation using an OCSP responder ................................. 25-18 Creating an SSL OCSP responder object ................................................................... 25-18 Creating an SSL OCSP configuration object .............................................................. 25-19 Creating an SSL OCSP profile ....................................................................................... 25-19 Modifying a virtual server for SSL OCSP authentication ......................................... 25-20 Configuring a CRLDP authentication module ..................................................................... 25-21 Creating a CRLDP server object .................................................................................. 25-21 Creating a CRLDP configuration object ...................................................................... 25-22 Creating a CRLDP profile ............................................................................................... 25-23 Modifying a virtual server for CRLDP authentication .............................................. 25-24
26
Configuring Kerberos Delegation
Introducing Kerberos delegation infrastructure ................................................................... 26-1 Configuring the BIG-IP system for Kerberos delegation .................................................... 26-4 Adding a DNS server to the BIG-IP system ................................................................. 26-4 Joining the BIG-IP system to the trusted domain ........................................................ 26-6 Creating the Kerberos delegation configuration .................................................................. 26-7 Configuring Kerberos delegation using the Configuration utility ............................ 26-7 Configuring Kerberos delegation from the command line ..................................... 26-10 Configuring Kerberos delegation using tmsh ............................................................ 26-12 Authenticating Client Traffic ................................................................................................... 26-14 The BIG-IP system as a proxy server for Kerberos ................................................. 26-14 The BIG-IP system for client authentication with protocol transition ................. 26-15 Required Active Directory Settings .............................................................................. 26-16
27
Configuring Multiple Authentication Servers
Introducing multiple authentication server configuration .................................................. 27-1 Meeting prerequisites .................................................................................................................. 27-2 Configuring BIG-IP system objects .......................................................................................... 27-2
28
Load Balancing Diameter Application Requests
Introducing Diameter load balancing ....................................................................................... 28-1 Creating a custom Diameter profile ........................................................................................ 28-2 Creating a custom Diameter monitor .................................................................................... 28-2 Creating a Diameter load balancing pool ............................................................................... 28-3 Creating a virtual server for Diameter traffic ....................................................................... 28-3
29
Configuring XML Content-Based Routing
Introducing XML content-based routing ................................................................................ 29-1 Creating an XML profile ............................................................................................................. 29-2 Writing XPath queries ....................................................................................................... 29-3 Creating a pool ............................................................................................................................. 29-4 Creating an iRule .......................................................................................................................... 29-5 Creating a virtual server ............................................................................................................. 29-6 Viewing statistics about XML content-based routing .......................................................... 29-7
Glossary Index
xii
1
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 systems browser-based Configuration utility, you can implement many configuration scenarios simply by using the default VLAN configuration, and then creating Local Traffic ManagerTM 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 TMOS. For an overview of the complete BIG-IP product offering, see the introductory chapter of the TMOS 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, http://support.f5.com.
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, http://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. The guide also provides a brief introduction to the features of BIG-IP system and the tools for configuring the system. 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 ManagerTM 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 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.
1-3
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, http://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 http://support.f5.com.
1-5
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
BIG-IP Local Traffic Manager: Implementations 2-1
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 routers internal address (10.1.1.1 in Figure 2.1, on page 2-1) rather than to the BIG-IP systems 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 routers 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 more information about these tasks, click the Help tab in the Configuration utility, or see the Configuration Guide for BIG-IP Local Traffic Manager.
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.
2-3
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
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. To create a new pool, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. To create a new virtual server, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your 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
2-5
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
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.
3-1
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 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 ssl_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.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 click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_ssl. 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: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. 7. In the Resources area of the screen, locate the Default Pool setting and select ssl_pool. 8. Click Finished.
3-4
4
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.
4-1
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. This switch is eliminated in a configuration using a BIG-IP system.
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.
4-3
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

Create a VLAN group that includes the internal and external VLANs. 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

1. On the Main tab of the navigation pane, expand Network, and click VLANs. The VLANs screen opens. 2. From the VLAN Groups menu, choose List. This opens the VLAN Groups screen. 3. In the upper-right corner of the screen, click Create. This opens the New VLAN Group screen. Note: If the Create button is unavailable, this indicates that your 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

1. On the Main tab of the navigation pane, expand Network, and click Self IPs. The Self IPs screen opens. 2. In the upper-right corner of the screen, click Create. Note: If the Create button is unavailable, this indicates that your 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
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as myweb_pool. 4. In the Resources area of the screen, use the New Members setting to add the pool members. In our example, pool members are 10.0.0.3:80 and 10.0.0.4:80. 5. Click Finished.
4-5
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 click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_myweb. 4. In the Destination box, verify that the type of virtual server is Host, 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. 6. In the Resources area of the screen, locate the Default Pool setting 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.
Note
An alternate way to implement web hosting for multiple customers is to use the route domains feature. For more information, see Chapter 6, Web Hosting for Multiple Customers using Route Domains. 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
5-1
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

1. On the Main tab of the navigation pane, expand Network, and click VLANs. The VLAN screen opens. 2. In the upper-right corner of the screen, click Create. This displays the settings to configure for the VLAN. Note: If the Create button is unavailable, this indicates that your 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
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as customerA_pool. 4. In the Resources area of the screen, use the New Members setting to add the pool members. 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.

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server.
Chapter 5
3. In the Name box, type a name for the virtual server, such as vs_customerA. 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 10.1.10.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 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.
5-5
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

1. On the Main tab of the navigation pane, expand Network, and click VLANs. The VLAN screen opens. 2. In the upper-right corner of the screen, click Create. This displays the settings to configure for the VLAN. Note: If the Create button is unavailable, this indicates that your 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
Introduction Prerequisite information Procedure Example For more information
Introduction
Using the route domains feature of the BIG-IP system, you can provide hosting service for multiple customers by isolating each type of application traffic within a defined address space on the network. This enhances security and dedicates BIG-IP resources to each application. Implementing route domains also allows you to use duplicate IP addresses on the network, as long as each of the duplicate addresses resides in a separate route domain and is isolated on the network through a separate VLAN. 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.0.10.1) can reside in each route domain, in the same pool or in different pools, and you can assign a different monitor to each of the two corresponding pool members.
Prerequisite information
Using the remainder of this chapter, you can set up a basic configuration with two route domains. Before you follow the step-by-step procedure, however, you must gather the following information, for each customer (that is, each type of application traffic): Two interface numbers Two self IP addresses, one per VLAN Pool member addresses and service A virtual server address and service
6-1
Chapter 6
Procedure
You must perform this procedure for each type of application traffic that you want to isolate within a route domain.
Note
To perform this procedure, you must have the Administrator or Resource Administrator user role assigned to your user account. In this procedure, you use the System, Network, and Local Traffic navigation menus of the Configuration utility.
Important
The tables in the procedure show only those settings that you need to explicitly configure. Settings for which you can use the default values are not shown. After you complete this procedure, each administrative partition contains one route domain, and the route domain in each partition is designated as the default route domain for the partition. With this configuration, you do not need to specify the %ID notation in any BIG-IP system addresses that you create.
To isolate traffic for an application on the network

1. Create an administrative partition: a) Expand System, click Users, and on the menu bar, click Partition List. b) Click the Create button, and specify values for these settings:
Setting Name Required Action Type a unique name for the partition. The name should indicate the application to which the partition pertains, for example, partition_App_A. Optionally, type a description of the partition, for example: This partition contains BIG-IP objects for managing Application_A.
Description
c) Click Finished.
2. Using the Partition list box on the upper-right portion of the Configuration utility screens, set the current partition to the partition that you created in step 1.
6-2
3. Create two VLANs, one for the external network and one for the internal network: a) Expand Network, and click VLANs. b) Click the Create button, and specify values for these settings:
Setting Name Required Action Type a unique name for the VLAN, for example external_AppA. In the Available box, click an interface number and use the Move button to move the number to the Tagged box. Note: You can use the same interface for other VLANs later, as long as you always assign the interface as a tagged interface.
Interfaces
c) Click Finished. d) Repeat steps 3b and 3c for the second VLAN. An example of a name for the second VLAN is internal_App_A.
4. Create a route domain object: a) On the navigation pane, click Route Domains. b) Click the Create button, and specify values for these settings:
Setting ID Required Action Type a unique number for the route domain, such as 1. Type a description of the route domain, for example: This route domain pertains to Application_A. Verify that the Strict Isolation box is checked. Using the Move button, assign the VLANs that you created in step 3. From the list, select Make this route domain the Partition Default Route Domain. Setting this value ensures that the %ID notation is not required in IP addresses for objects pertaining to this route domain.
Description
Strict Isolation VLANs
Partition Default Route Domain
c) Click Finished.
6-3
Chapter 6
5. Create two self IP addresses, one for each VLAN: a) Expand Network, and click Self IPs. b) Click the Create button, and specify values for these settings:
Setting IP Address Netmask VLAN Required Action Type a unique IP address. Type the netmask for the specified IP address. From the VLAN list, select the first of the VLANs that you created in step 3.
c) Click Finished. d) Repeat steps 5b and 5c. For the VLAN setting, select the second VLAN that you created in step 3.
6. Create a load balancing pool: a) Expand Local Traffic, and click Pools. b) Click the Create button, and specify values for these settings:
Setting Name New Members Required Action Type a unique name for the pool. Add new pool members as needed.
c) Click Finished.
7. Create a virtual server: a) On the navigation pane, click Virtual Servers.
6-4
b) Click the Create button, and specify values for these settings. For all other virtual server settings, you can use the default values.
Setting Name Destination Required Action Type a unique name for the pool. Type: Choose a virtual server type, either Host or Network. Address: Type an IP address for the virtual server. Netmask: Type a netmask for the virtual server address. Service Port: Select a service port from the list, or type a service port number. Specify the pool that you created in step 6.
Default Pool
c) Click Finished.
8. Add routes for the application traffic: a) Expand Network, and click Routes. b) Click the Add button, and specify values for the following settings.
Setting Type Destination Required Action Select Route. Type an IP address for a pool member that you created in step 6. Type a netmask for the destination IP address. From the list, select either Use Gateway or Use VLAN. Depending on your selection, specify either a next-hop address or the internal VLAN you selected in step 3, respectively.
Netmask Resource Type
c) Click Finished. d) Repeat steps 8b and 8c for each route that you add. Add one route for each pool member IP address. You can also add a default route for this route domain. (Each route domain on the BIG-IP system can contain a default route.)
6-5
Chapter 6
Example
A good example of the use of traffic isolation on a network is an ISP that services multiple customers, where each customer deploys a different application. Figure 6.1 shows two route domain objects on a BIG-IP system, where each route domain corresponds to a separate customer and therefore resides in its own partition. Within each partition, the ISP created the network objects and local traffic objects required for that customers application (AppA or AppB).
Figure 6.1 Configuring route domains in separate partitions

6-6
The configuration in Figure 6.1 results in the BIG-IP system segmenting traffic for two different applications into two separate route domains. The routes for each applications traffic cannot cross route domain boundaries because cross-routing restrictions are enabled on the BIG-IP system by default. Figure 6.2, on page 6-7 shows the resulting route isolation for AppA and AppB application traffic.
Figure 6.2 Application traffic for customers A and B, separated by route domains
6-7
Chapter 6
For more information

You can find background information in these product guides:
TMOS Management Guide for BIG-IP Systems Chapter 13, Configuring Administrative Partitions Chapter 14, Managing User Accounts Chapter 8, Configuring VLANs and VLAN Groups Chapter 12, Configuring Self IP Addresses Chapter 7, Working with Interfaces Chapter 11, Configuring Route Domains Chapter 10, Configuring Routes
Configuration Guide for BIG-IP Local Traffic ManagerTM Chapter 2, Configuring Virtual Servers Chapter 4, Configuring Load Balancing Pools
6-8
7
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 7.1). In this implementation, the BIG-IP system performs load balancing for several different types of connection requests:
HTTP connections to the companys 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 7.1 A simple intranet configuration
7-1
Chapter 7
As Figure 7.1, on page 7-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
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as http_pool. 4. In the Resources area of the screen, use the New Members setting to add the pool members. For example, in Figure 7.1, on page 7-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.
7-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.

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_http, vs_specificport, or vs_non-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. 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. 5. In the Service Port box, type 80, or select HTTP from the list. 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. 8. In the Resources area of the screen, locate the Default Pool setting and select the pool corresponding to the virtual server you are 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.
7-3
Chapter 7
7-4
8
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 8.1 shows a network configured with two Internet connections.
Figure 8.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.
8-1
Chapter 8
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
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as content_pool or router_pool. 4. In the Resources area of the screen, use the New Members setting to add the pool members. For example, in Figure 8.1, on page 8-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.
8-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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_content. 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. 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. 7. In the Resources area of the screen, locate the Default Pool setting and select the pool corresponding to the virtual server you are 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_routers.
8-3
Chapter 8
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. For example, you can assign the IP address 0.0.0.0:0 to the virtual server, making it a wildcard virtual server. 5. In the Resources area of the screen, locate the Default Pool setting and select the pool corresponding to the virtual server you are creating. For example, for vs_routers, you would select the pool router_pool. 6. Click Finished.
8-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

1. On the Main tab of the navigation pane, expand Network, and click Self IPs. The Self IP screen opens. 2. In the upper-right corner of the screen, click Create. This displays the settings that you can configure for a self IP address. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click SNATs. The SNATs screen opens. 2. In the upper-right corner, click Create. The New SNAT screen opens.
8-5
Chapter 8
Note: If the Create button is unavailable, this indicates that your 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.
8-6
9
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 Configuration Guide for BIG-IP Local Traffic Manager.
9-1
Chapter 9
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.

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as http_pool. 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.
9-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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 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. 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. This assigns the default HTTP profile to the virtual server. 7. In the Resources area of the screen, locate the Default Pool setting 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.
9-3
Chapter 9
9-4
10
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 clients 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 Manager.
10 - 1
Chapter 10
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 persistence profile.
To create a custom cookie persistence profile

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. On the menu bar, click Persistence. This displays the list of default persistence profiles. 3. In the upper-right corner of the screen, click Create. The New Persistence Profile screen opens. Note: If the Create button is unavailable, this indicates that your 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.
10 - 2
Creating a pool
The next task is to create a load balancing pool to which to load balance HTTP connections.

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as http_pool. 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. 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.

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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_http.
10 - 3
Chapter 10
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. 5. In the Service Port box, type 80, or select HTTP from the list. 6. In the Configuration area of the screen, retain the value of the Protocol setting, TCP. 7. From the HTTP Profile list, select http. This assigns the default HTTP profile to the virtual server. 8. In the Resources area of the screen, locate the Default Pool setting 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 with a Performance (HTTP) type of virtual server.
10 - 4
11
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 systems 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 Manager.
11 - 1
Chapter 11
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. This displays a list of any existing HTTP profiles, including the default profile http. 2. In the upper-right corner of the screen, click Create. The New HTTP Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a profile. 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/**.
11 - 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_http_compress. 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. 5. In the Service Port box, type 80, or select HTTP from the list. 6. In the Configuration area of the screen, retain the value of the Protocol setting, TCP. 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. 8. In the Resources area of the screen, locate the Default Pool setting 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.
11 - 3
Chapter 11
11 - 4
12
Introducing HTTPS load balancing Creating an SSL key and certificate Creating a custom SSL profile Creating a pool Creating a virtual server
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, which 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, which enables the system to encrypt requests that the BIG-IP system sends to the target web server, decrypt the response. 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 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 Manager.
12 - 1
Chapter 12
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. You can configure the BIG-IP system to terminate SSL traffic either by creating a self-signed certificate or by generating a request for a certificate signed by a trusted certificate authority.
To create a self-signed key/certificate pair

1. On the Main tab of the navigation pane, expand Local Traffic, and 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. Note: If the Create button is unavailable, this indicates that your 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 servers 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
To request a certificate and key from a certificate authority

1. On the Main tab of the navigation pane, expand Local Traffic, and click SSL Certificates. This displays the SSL Certificates screen. 2. On the upper-right portion of the screen, click Create. 3. Type a unique name for the certificate. 4. In the Issuer box, select Certificate Authority. 5. Configure the Common Name setting (required). This value is embedded in a certificate for name-based authentication purposes. 6. Configure any other optional certificate settings. 7. Request the private key by: a) Specifying the key size (512, 1024, or 2048). b) Specifying the key type (FIPS or Normal). 8. Click Finished. This displays your certificate request. 9. To download the request into a file on your system, either: Copy the certificate from the Request Text box. Click the button in the Request File box. 10. In the Certificate Authorities box, click a certificate authority name. This displays the web site for the certificate authority. 11. Follow the instructions on the web site for either pasting the copied request or attaching the generated request file. 12. Click Finished.
12 - 3
Chapter 12
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. 2. From the SSL menu, choose Client. This displays a list of any existing Client SSL profiles, including the default profile clientssl. 3. In the upper-right corner of the screen, click Create. The New Client SSL Profile screen opens. 4. In the Name box, type a name for the custom profile, such as 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 far 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 far 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.
To create a custom Server SSL profile

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. 2. From the SSL menu, choose Server. This displays a list of any existing Server SSL profiles, including the default profile serverssl.
12 - 4
3. In the upper-right corner of the screen, click Create. The New Server SSL Profile screen opens. 4. In the Name box, type a name for the custom profile, such as 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 far 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_serverside_cert.crt. 8. For the Key setting, check the Custom box on the far 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_serverside_cert.key. 10. Click Finished.
12 - 5
Chapter 12
Creating a pool
The next task in this process is to create a load balancing pool to load balance connections. After you create the pool, you assign it to a virtual server that you create.
To create a pool for load balancing client-side terminated traffic

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as http_pool. 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.
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 HTTPS

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_clientssl. 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. 5. In the Service Port box, type 443, or select HTTPS from the list. 6. In the Configuration area of the screen, retain the value of the Protocol setting, TCP. 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. 9. In the Resources area of the screen, locate the Default Pool setting and select the pool name that you created in a previous section. Using our example, this would be http_pool. 10. From the Default Persistence Profile list, select source_addr. This implements the default profile for source address affinity 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 SSL traffic through the virtual server to the pool.
12 - 7
Chapter 12
12 - 8
13
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 Creating a virtual server
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 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 Guide for BIG-IP Local Traffic Manager.
Note
For information on configuring server-side SSL processing, see Chapter 12, Configuring HTTPS Load Balancing.
13 - 1
Chapter 13
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. You can configure the BIG-IP system to terminate SSL traffic either by creating a self-signed certificate or by generating a request for a certificate signed by a trusted certificate authority.
To create a self-signed key/certificate pair

1. On the Main tab of the navigation pane, expand Local Traffic, and 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. Note: If the Create button is unavailable, this indicates that your 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 servers 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.
To request a certificate and key from a certificate authority

1. On the Main tab of the navigation pane, expand Local Traffic, and click SSL Certificates. This displays the SSL Certificates screen.
13 - 2
2. On the upper-right portion of the screen, click Create. 3. Type a unique name for the certificate. 4. In the Issuer box, select Certificate Authority. 5. Configure the Common Name setting (required). This value is embedded in a certificate for name-based authentication purposes. 6. Configure any other optional certificate settings. 7. Request the private key by: a) Specifying the key size (512, 1024, or 2048). b) Specifying the key type (FIPS or Normal). 8. Click Finished. This displays your certificate request. 9. To download the request into a file on your system, either: Copy the certificate from the Request Text box. Click the button in the Request File box. 10. In the Certificate Authorities box, click a certificate authority name. This displays the web site for the certificate authority. 11. Follow the instructions on the web site for either pasting the copied request or attaching the generated request file. 12. Click Finished.
13 - 3
Chapter 13
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the SSL menu, choose Client SSL. This displays a list of any existing Client SSL profiles, including the default profile clientssl. 3. In the upper-right corner of the screen, click Create. The New Client SSL Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a profile. 4. In the Name box, type a name for the custom profile, such as 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. 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_cert.crt. 8. For the Key setting, check the Custom box on the far right side of the screen. 9. From the Key list, select the name of the key you created in the previous task. Using our example, this name would be my_cert.key. 10. Click Finished.
13 - 4
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. This displays a list of any existing HTTP profiles, including the default profile http. 2. In the upper-right corner of the screen, click Create. The New HTTP Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a profile. 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. 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.
13 - 5
Chapter 13
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.
13 - 6
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 client-side terminated traffic

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as http_pool. 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. In the Resource area, 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.
13 - 7
Chapter 13

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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_clientssl. 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. 5. In the Service Port box, type 443, or select HTTPS from the list. 6. In the Configuration area of the screen, retain the value of the Protocol setting, TCP. 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. 9. In the Resources area of the screen, locate the Default Pool setting and select the pool name that you created in a previous section. Using our example, this would be http_pool. 10. From the Default Persistence Profile list, select source_addr. This implements the default profile for source address affinity persistence. 11. Click Finished.
You can now test the configuration by attempting to pass SSL 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.
13 - 8
14
Introducing HTTP RAM Cache Creating a custom HTTP profile Creating a virtual server
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 systems 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 Manager.
14 - 1
Chapter 14
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. This displays a list of any existing HTTP profiles, including the default profile http. 2. In the upper-right corner of the screen, click Create. The New HTTP Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a profile. 3. In the Name box, type a name for the custom profile, such as http_ramcache. 4. Ensure that the Parent Profile setting is set to http. 5. In the Settings area of the screen, retain all default values. 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.
14 - 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_http_compress. 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. 5. In the Service Port box, type 80, or select HTTP from the list. 6. In the Configuration area of the screen, retain the value of the Protocol setting, TCP. 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. 8. In the Resources area of the screen, locate the Default Pool setting 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.
14 - 3
Chapter 14
14 - 4
15
Introducing FTP load balancing Creating a custom FTP monitor Creating a pool Creating a virtual server
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 Manager.
15 - 1
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Monitors. This displays a list of existing health and performance monitors. 2. On the upper-right corner of the screen, click Create. 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.
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 created in the previous task. After creating the pool, you assign it to the virtual server that you create.
To create a pool for load balancing FTP traffic

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 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. 6. 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) From the Service Port list, select FTP. d) Click Add. e) Repeat steps b, c, and d for each server in the pool. 7. Click Finished.
15 - 3
Chapter 15

The next task in a basic configuration is to define a virtual server that references the FTP profile and the FTP pool.
To create a virtual server for FTP traffic

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_ftp. 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. 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. In the Resources area of the screen, locate the Default Pool setting and select the name of the FTP pool you created in the previous task (for example, ftp_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.
15 - 4
16
Introducing FTP load balancing with rate shaping Creating a custom FTP monitor Creating a pool Creating a rate class Creating a virtual server
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 Manager. 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.
16 - 1
Chapter 16
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Monitors. This displays a list of existing health and performance monitors. 2. On the upper-right corner of the screen, click Create. This opens the New Monitor screen. Note: If the Create button is unavailable, this indicates that your 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. 9. For all other settings, retain the default values. 10. Click Finished. After you create the custom FTP monitor, you can create a load balancing pool for your FTP traffic.
16 - 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 created in the previous task.
To create a pool for load balancing FTP traffic with rate shaping
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 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 the Priority Group Activation setting is set to Disabled. 6. 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) From the Service Port list, select FTP. d) Click Add. e) Repeat steps b, c, and d for each server in the pool. 7. Click Finished.
After you create the pool, you assign it to the virtual server that you create in the next task.
16 - 3
Chapter 16
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

1. On the Main tab of the navigation pane, expand Network, and click Rate Shaping. The Rate Shaping screen opens. 2. In the upper-right corner of the screen, click Create. The New Rate Class screen opens. Note: If the Create button is unavailable, this indicates that your 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. 7. For all other settings, retain the default values. 8. Click Finished.
16 - 4

The next task in a basic configuration is to define a virtual server that references the FTP profile and the FTP pool.
To create a virtual server for FTP traffic with rate shaping

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_ftp. 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. 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). 8. In the Resources area of the screen, locate the Default Pool setting and select the name of the FTP pool you created in the previous section (for example, ftp_pool). 9. From the Default Persistence Profile setting, select source_addr. This implements simple persistence, using the default source address affinity profile. 10. Click Finished.
16 - 5
Chapter 16
16 - 6
17
Introducing the one-IP network topology Creating a pool for a one-IP network topology Creating a virtual server 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 17.1.
Figure 17.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.
17 - 1
Chapter 17
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
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. From the Configuration list, select Advanced. 4. In the Name box, type a name for the pool, such as server_pool. 5. 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. 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. 9. 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. 10. Click Finished.
17 - 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.

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as 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. 5. In the Service Port box, type 80, or select HTTP from the list. 6. In the Configuration area of the screen, retain the value of the Protocol setting, TCP. 7. From the HTTP Profile list, select http. This assigns the default HTTP profile to the virtual server. 8. In the Resources area of the screen, locate the Default Pool setting and select the name of the pool you created in the previous section (using our example, this would be server_pool). 9. Click Finished.
17 - 3
Chapter 17
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.
17 - 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click SNATs. The SNATs screen opens. 2. In the upper-right corner of the screen, click Create. The New SNAT screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a SNAT. 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.
17 - 5
Chapter 17
17 - 6
18
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.
18 - 1
Chapter 18
Using the two-network aggregated tagged interface topology

Figure 18.1 shows a two-IP network topology, with one network connected to VLAN external, and a separate network connected to VLAN internal.
Figure 18.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.
18 - 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
1. On the Main tab of the navigation pane, expand Network, and click Trunks. The Trunks screen opens. 2. On the upper-right corner of the screen, click Create. The New Trunk screen opens. Note: If the Create button is unavailable, this indicates that your 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

1. On the Main tab of the navigation pane, expand Network, and click VLANs. The VLAN screen opens. 2. In the Name column, click the VLAN name internal. This displays the properties of that VLAN.
18 - 3
Chapter 18
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
1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as myweb_pool. 4. 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 web server in the pool. c) From the Service Port list, select a service. d) Click Add. e) Repeat steps b, c, and d for each server in the pool. 5. Click Finished.
18 - 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 create the virtual server.

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_myweb. 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. Using the example in Figure 18.1, on page 18-2, this address could be 10.0.10.30. 5. In the Resources area of the screen, locate the Default Pool setting and select the name of the pool you created in the previous section (for example, myweb_pool). 6. From the Default Persistence Profile setting, select source_addr. This implements simple persistence, using the default source address affinity profile. 7. Click Finished.
18 - 5
Chapter 18
Using the one-network aggregated tagged interface topology

Figure 18.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 18.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 the following tasks: 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 18-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.
18 - 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

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 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

Create a VLAN group that includes the internal and external VLANs. 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

1. On the Main tab of the navigation pane, expand Network, and click VLANs. The VLANs screen opens. 2. From the VLAN Groups menu, choose List. This opens the VLAN Groups screen. 3. In the upper-right corner of the screen, click Create. This opens the New VLAN Group screen.
18 - 7
Chapter 18
Note: If the Create button is unavailable, this indicates that your 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

1. On the Main tab of the navigation pane, expand Network, and click Self IPs. The Self IPs screen opens. 2. In the upper-right corner of the screen, click Create. Note: If the Create button is unavailable, this indicates that your 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. 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.
18 - 8
19
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 VLANs 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.
19 - 1
Chapter 19
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
1. On the Main tab of the navigation pane, expand Local Traffic, and click SNATs. The SNATs screen opens. 2. In the upper-right corner, click Create. The New SNAT screen opens. Note: If the Create button is unavailable, this indicates that your 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 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as gateway_pool.
19 - 2
4. In the Resources area of the screen, use the New Members setting to add the pool members. 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_packetfilter. 4. For the Destination setting: 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. 5. From the Service Port list, select *All Ports. 6. In the Configuration area of the screen, locate the Type setting and select Forwarding (IP). 7. From the Protocol list, select *All Protocols. 8. From the VLAN Traffic list, select Enabled On. 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. 10. In the Resources area of the screen, locate the Default Pool setting and select the pool you created previously (gateway_pool). 11. Click Finished.
19 - 3
Chapter 19
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

1. On the Main tab of the navigation pane, expand Network, and click 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. Note: If the Create button is unavailable, this indicates that your 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 no 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.
19 - 4
20
Introducing health and performance monitors Creating a custom monitor Creating a pool Creating a virtual server
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 20.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 20.1 Example of a monitor with default values
20 - 1
Chapter 20
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 Manager.
20 - 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 20-4.
To create a custom monitor

1. On the Main tab of the navigation pane, expand Local Traffic, and click Monitors. This displays a list of existing health and performance monitors. 2. On the upper-right corner of the screen, click Create. This opens the New Monitor screen. Note: If the Create button is unavailable, this indicates that your 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 Configuration Guide for BIG-IP Local Traffic Manager. 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.
20 - 3
Chapter 20
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 20-5.
To create a pool and assign a monitor

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. In the Name box, type a name for the pool, such as http_pool. 4. For the Health Monitors setting, from the Available box select the 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. 7. 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) From the Service Port list, select FTP. d) Click Add. e) Repeat steps b, c, and d for each server in the pool. 8. Click Finished.
20 - 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 20-4. Then you can use one of the following procedures.
To remove a monitor from a pool member

1. On the Main tab of the navigation pane, expand Local Traffic, and 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 20-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. 5. From the Configuration list, select Advanced. 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

1. On the Main tab of the navigation pane, expand Local Traffic, and 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 20-4. 3. On the menu bar, click Members. The Current Members area of the screen lists the members of the pool.
20 - 5
Chapter 20
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. 5. From the Configuration list, select Advanced. 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 20-4. You use the Configuration utility to create the virtual server.

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_httppool. 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. 5. From the Service Port list, select a service. 6. In the Resources area of the screen, locate the Default Pool setting and select the name of the pool you created (such as http_pool). 7. Click Finished.
20 - 6
21
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 networks global address prefix on the internal VLAN. For more information on BIG-IP system services, see the TMOSTM Management Guide for BIG-IP Systems.
Note
All IPv6 addresses that you define on the BIG-IP system must reside in route domain 0.
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 networks 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.
21 - 1
Chapter 21
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 Manager.
Note
All IPv6 addresses that you define on the BIG-IP system must reside in route domain 0.
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 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: a) Click the New Address option. 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.
21 - 2

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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a virtual server. 3. In the Name box, type a name for the virtual server, such as vs_ipv6. 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. 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. 7. In the Resources area of the screen, locate the Default Pool setting and select the name of the pool you created in the previous section (for example, ipv6_pool). 8. Click Finished.
21 - 3
Chapter 21
21 - 4
22
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 Manager.
22 - 1
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>"
22 - 3
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

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 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

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 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

1. On the Main tab of the navigation pane, expand Local Traffic, and 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. Note: If the Create button is unavailable, this indicates that your 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. 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.
22 - 5
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. 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
22 - 7
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 systems 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. The General screen opens. 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 networks 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.
22 - 9
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. You do not need to make any changes to the BIG-IP system configuration for this type of attack.
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. You do not need to make any changes to the BIG-IP system configuration for this type of attack.
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. You do not need to make any changes to the BIG-IP system configuration for this type of attack.
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. You do not need to make any changes to the BIG-IP system configuration for this type of attack.
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.
22 - 11
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 partitions Creating a partition Configuring user access to a partition Viewing, managing, and creating objects in a partition
Introducing administrative partitions

The BIG-IP system includes a powerful authorization feature known as administrative partitions. Using the administrative partitions 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 partitions 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 users 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 users 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 Guide for BIG-IP Local Traffic Manager.
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 partitions feature on the BIG-IP system.
23 - 1
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 users 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. 3. On the upper-right corner of the screen, click Create. 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 Management Guide for BIG-IP Systems.
To configure user access to a partition

1. On the Main tab of the navigation pane, expand System, and click 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.
23 - 3
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. For example, 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.
23 - 5
Chapter 23
23 - 6
24
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.
Note
All remote authentication servers must reside in route domain 0. For information on route domains, see the TMOS Management Guide for BIG-IP Systems.
24 - 1
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 Management Guide for BIG-IP Systems. 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

1. On the Main tab of the navigation pane, expand System, and click Users. The Users screen opens. 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 should search for user authentication. 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.
24 - 3
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

1. On the Main tab of the navigation pane, expand System, and click Users. The Users screen opens. 2. On the menu bar, click Authentication. The Authentication screen opens. 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

1. On the Main tab of the navigation pane, expand System, and click Users. The Users screen opens. 2. On the menu bar, click Authentication. The Authentication screen opens.
24 - 4
3. Click Change. 4. From the User Directory list, select Remote - TACACS+. 5. From the Configuration list, select Advanced. 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.
24 - 5
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 this page. 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 utility, 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 }
24 - 7
Chapter 24
Table 24.1 shows the resulting configuration, where each group has a set of privileges assigned to it:
Group Name BigIPOperatorsGroup Assigned Privileges 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 login. 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
24 - 9
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.
24 - 11
Chapter 24
c) If necessary, change the passwords for the root and admin accounts using the user <name> password none newpassword <password> command. 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
Introducing remote authentication for application traffic Configuring authentication that uses a remote LDAP or Active Directory server Configuring authentication that uses a remote RADIUS server Configuring authentication that uses a remote 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 sites 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 Manager. 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
25 - 1
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.

Note
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.
25 - 2
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 - 3
Chapter 25
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.
25 - 4
To create a custom LDAP configuration object

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Configurations. The Authentication Configurations screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Configuration screen opens. Note: If the Create button is unavailable, this indicates that your 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 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 - 5
Chapter 25
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Profiles. The Authentication Profiles screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Profile screen opens. Note: If the Create button is unavailable, this indicates that your 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.
25 - 6
To modify a virtual server for LDAP authentication

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 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. 3. From the Configuration list, select Advanced. 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 - 7
Chapter 25
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. Note: If the Create button is unavailable, this indicates that your 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.
25 - 8
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. The Profiles screen opens. 2. From the Authentication menu, choose Configurations. This displays the Authentication Configurations screen. 3. In the upper right corner of the screen, click Create. This displays the New Authentication Configuration screen. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a RADIUS configuration object. 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. Selecting Advanced causes additional settings to appear on the 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). 9. If you selected a basic configuration in step 7, click Finished. If you selected an advanced configuration in step 7, configure the remaining settings and click Finished.
25 - 9
Chapter 25
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 iRule to an HTTP virtual server.
To create a custom RADUS profile

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Profiles. The Authentication Profiles screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a RADIUS profile. 4. From the Type list, select RADIUS. This displays the profile settings that you can configure. 5. In the Name box, type a unique name for the profile, such as 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 configuration object that you previously created. 8. For all remaining settings, retain the default values. 9. Click Finished.
Modifying a virtual server for RADIUS authentication

The final task in the process of implementing authentication using a remote 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 Standard type of virtual server.
25 - 10
To modify a virtual server for RADIUS authentication

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the Name column, click the name of a virtual server. This displays the properties of that virtual server. 3. From the Configuration list, select Advanced. This displays additional properties. 4. From the Authentication Profiles list, from the Available box select the name of the custom RADIUS 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 - 11
Chapter 25
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Configurations. The Authentication Configurations screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Configuration screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a TACACS+ configuration object. 4. From the Type list, select TACACS+. This displays the configuration object settings that you can configure. 5. In the Name box, type a unique name for the configuration object, such as my_tacacs_config. 6. For the Configuration area, select Basic or Advanced. Selecting Advanced causes additional settings to appear on the screen.
25 - 12
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. The IP address appears in the text window. 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. 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 click Finished.
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Profiles. The Authentication Profiles screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a TACACS+ profile. 4. From the Type list, select TACACS+. This displays the profile settings that you can configure. 5. In the Name box, type a unique name for the profile, such as my_tacacs_profile. 6. From the Parent Profile list, verify that tacacs is selected. This causes the new profile to inherit its default configuration values from the default profile, named tacacs.
25 - 13
Chapter 25
7. From the Configuration list, select the name of the TACACS+ configuration object that you previously created. 8. For all remaining settings, retain the default values. 9. Click Finished.
Modifying a virtual server for TACACS+ authentication

The final task in the process of implementing authentication using a remote 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the Name column, click the name of a virtual server. This displays the properties of that virtual server. 3. From the Configuration list, select Advanced. This displays additional properties. 4. From the Authentication Profiles list, from the Available box select the name of the custom TACACS+ 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 - 14
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Configurations. The Authentication Configurations screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Configuration screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create an SSL Client Certificate LDAP configuration object. 4. In the Name box, type a unique name for the configuration object, such as my_ssl_client_cert_ldap_config. 5. From the Type list, select SSL Client Certificate 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.
BIG-IP Local Traffic Manager: Implementations 25 - 15
Chapter 25
7. For the Hosts setting: a) Type the IP address of the remote LDAP. b) Click Add. The IP address appears in the text window. 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. 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 click Finished.
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Profiles. The Authentication Profiles screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create an SSL Client Certificate LDAP profile. 4. In the Name box, type a unique name for the profile, such as my_ssl_client_cert_ldap_profile. 5. From the Type list, select SSL Client Certificate LDAP. This displays the profile settings that you can configure. 6. From the Parent Profile list, verify that sol ldap is selected This causes the new profile to inherit its default configuration values from the default profile, named ldap.
25 - 16
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 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 Standard type of virtual server.
To modify a virtual server for SSL Client Certificate LDAP authorization

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the Name column, click the name of a Standard-type virtual server to which an HTTP server profile is assigned. This displays the properties of that virtual server. 3. From the Configuration list, select Advanced. This displays additional properties. 4. From the Authentication Profiles list, from the Available box select the name of the custom SSL CLient Certificate 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 - 17
Chapter 25
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The Profiles screen opens. 2. From the Authentication menu, choose OCSP Responders. This displays the OCSP Responders list screen. 3. In the upper right corner of the screen, click Create. This displays the New OCSP Responder screen. Note: If the Create button is unavailable, this indicates that your 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.
25 - 18
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 iRule to an HTTP virtual server.
To create an SSL OCSP configuration object

1. On the Main tab, expand Local Traffic, and click Profiles. The Profiles screen opens. 2. From the Authentication menu, choose Configurations. This displays the Authentication Configurations screen. 3. In the upper right corner of the screen, click Create. This displays the New Authentication Configuration screen. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create an SSL OCSP configuration object. 4. For the Name setting, specify a unique name for the configuration 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. After you create the profile, you assign the custom profile and a default iRule to an HTTP virtual server.
25 - 19
Chapter 25
To create a custom SSL OCSP profile

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Profiles. The Authentication Profiles screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create an SSL OCSP profile. 4. From the Type list, select SSL OCSP. This displays the profile settings that you can configure. 5. In the Name box, type a unique name for the profile, such as my_ssl_ocsp_profile. 6. From the Parent Profile list, verify that ssl_ocsp is selected. This causes the new profile to inherit configuration values from the default profile, named ssl_ocsp. 7. From the Configuration list, select the name of the SSL OCSP configuration object that you previously created. 8. For all remaining settings, retain the default values. 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the Name column, click the name of a virtual server. This displays the properties of that virtual server. 3. From the Configuration list, select Advanced. This displays additional properties.
25 - 20
4. From the Authentication Profiles list, from the Available box select the name of the custom SSL OCSP 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.
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. The Profiles screen opens. 3. From the Authentication menu, choose CRLDP Servers. This displays the CRLDP Servers list screen.
25 - 21
Chapter 25
4. In the upper right corner of the screen, click Create. This displays the New CRLDP Server screen. Note: If the Create button is unavailable, this indicates that your 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 iRule to an HTTP virtual server.
To create a CRLDP configuration object

1. On the Main tab, expand Local Traffic, and click Profiles. The Profiles screen opens. 2. From the Authentication menu, choose Configurations. This displays the Authentication Configurations screen. 3. In the upper right corner of the screen, click Create. This displays the New Authentication Configuration screen. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a CRLDP configuration object. 4. For the Name setting, specify a unique name for the configuration 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.
25 - 22
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. After you create the profile, you assign the custom profile and a default iRule to an HTTP virtual server.
To create a custom CRLDP profile

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The HTTP Profiles screen opens. 2. From the Authentication menu, choose Profiles. The Authentication Profiles screen opens. 3. On the upper-right corner of the screen, click Create. The New Authentication Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a CRLDP profile. 4. From the Type list, select CRLDP. This displays the profile settings that you can configure. 5. In the Name box, type a unique name for the profile, such as my_crldp_profile. 6. From the Parent Profile list, verify that ssl_crldp is selected. This causes the new profile to inherit configuration values from the default profile, named ssl_crldp. 7. From the Configuration list, select the name of the CRLDP configuration object that you previously created. 8. For all remaining settings, retain the default values. 9. Click Finished.
25 - 23
Chapter 25
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the Name column, click the name of a virtual server. This displays the properties of that virtual server. 3. From the Configuration list, select Advanced. This displays additional properties. 4. From the Authentication Profiles list, from the Available box select the name of the custom CRLDP 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 - 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 BIG-IP Kerberos delegation module essentially acts as a proxy for Kerberos credentials. The module obtains delegated Kerberos credentials for the client principal and a service ticket for the server-side principal. Doing so reduces network traffic between the client and the Kerberos server after the initial authentication is complete. For networks where all the client workstations are inside the domain, the module's default behavior is to use standard Kerberos delegation. In this configuration the browser supplies the module with a copy of the user's Ticket Granting Ticket (TGT). The module then uses this TGT to get service tickets to services on the other side of BIG-IP system. The protocol transition feature, which is turned on by enabling the protocol transition setting, is used for networks where clients are not in the domain (for example, laptops in hotel rooms). In this mode, the client's browser is authenticated by a client certificate, and the module makes Kerberos service ticket requests on the clients behalf. In this model, BIG-IP can only make service requests to specific services. This model is also called constrained delegation. Table 26.1 shows the infrastructure requirements for Kerberos delegation.
26 - 1
Chapter 26
Infrastructure Primary domain controller
Configuration Requirements This Kerberos delegation scenario uses a Microsoft primary domain controller (PDC) or Active Directory FSMO role named PDC emulator master. The time on the PDC must be synchronized with the time on the client and web servers. The DNS server must have knowledge of the domains web servers and virtual servers.
Key distribution center
The key distribution center (KDC) is installed as part of the domain controller and performs two service functions: the Authentication Service (AS) and the Ticket-Granting Service (TGS). The key distribution center usually is the PDC, but it can also be a standalone server in some networks.
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 6.x or later with support for SSL certificates. For user access, client machines can use either username and password or the Department of Defense (DoD) Common Access Card (CAC) and password.
Active Directory server
A Microsoft Windows Server 2003 (or later) Active Directory server (ADS) must be in the same domain of the BIG-IP, configured with the Kerberos protocol transition and protocol transition extensions initiated, and running in Windows Server 2003 mode to enable protocol transition. This is also known as the Key Distribution Center (KDC.) The time on the ADS must be synchronized with the time on the client and PDC.
Table 26.1 Infrastructure requirements for constrained delegation
26 - 2
Infrastructure Windows servers
Configuration Requirements All servers within the domain 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 Advanced Client Authentication Module should be installed on all BIG-IP systems that check for valid Online Certificate Status Protocol (OCSP) certificates. 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 constrained delegation
Note
26 - 3
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 command 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

1. On the Main tab of the navigation pane, expand System, and click Configuration. The General screen opens. 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 - 4
To configure DNS name resolution from the command line

1. Log in 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 nameserver 192.168.10.20 192.168.10.22
To configure DNS name resolution from with tmsh

1. At the tmsh prompt, define the DNS server(s) on the BIG-IP system by typing the following command:
modify sys dns name-servers add {<DNS_Server_IP_Address>}
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:
modify sys dns name-servers add {192.168.10.20 192.168.10.22}
2. You can view the added DNS server(s) by typing the following at the tmsh prompt:
list sys dns
Important
Before going any further, you should synchronize the BIG-IP clock with the PDC using NTP. For details on how to set NTP on BIG-IP, see the TMOS Management Guide for BIG-IP Systems.
26 - 5
Chapter 26
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. Run this command once for each domain the BIG-IP is joining. 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>
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. The KDC must be resolvable by both name and address (forward and reverse.) If domaintool does not allow your BIG-IP system to join the trusted domain, check the following: Make sure that the KDC has a reverse name lookup. Ensure that the PDC (primary domain controller) has a reverse name lookup. Make sure the BIG-IP clock is not off by more than five minutes from the PDC.
Important
For additional information about these commands, see the domaintool man page.
26 - 6
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), from the command line interface (see Configuring Kerberos delegation from the command line, on page 26-10), or using the TMOS shell (see Configuring Kerberos delegation using tmsh, on page 26-12.) 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, making the set cookie valuable if intercepted. To ensure that an attacker cannot intercept this set-cookie header, use a Client SSL profile in conjunction with the Kerberos delegation profile. The Client SSL profile is absolutely required for protocol transition to function correctly because a client certificate is mandatary.
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-10.
To create a Kerberos delegation configuration object

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The Profiles screen opens. 2. From the Authentication menu, choose Configurations. The Authentication Configurations screen opens. 3. In the upper-right corner of the screen, click Create. The New Authentication Configuration screen opens. 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. The screen expands to show several settings.
BIG-IP Local Traffic Manager: Implementations 26 - 7
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 <FQDN> is the virtual servers that you previously added to the domain:
HOST/<FQDN>
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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. The Profiles screen opens. 2. From the Authentication menu, choose Profiles. The Authentication Profiles screen opens. 3. In the upper right corner of the screen, click Create. The New Authentication Profile screen opens. 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. The screen expands to show several settings. 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

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. A list of profiles displays. 2. From the SSL menu, choose Client. The list of existing SSL profiles displays.
26 - 8
3. In the upper-right corner of the screen, click Create. The New Client SSL Profile screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 4. In the Name box, type a unique name for the profile. 5. To the far right side of Configuration, 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. To the far right side of Client Authentication, click the Custom box. 9. From the Client Certificate list, select Require. 10. From the Frequency list, select Once. 11. In the Certificate Chain Traversal Depth box, enter 9. 12. From the Advertised Certificate Authorities list, select your certificate name. 13. In the Certificate Revocation List (CRL) box, enter the location of the CRL file. 14. At the bottom of the screen, click Finished.
To create a load balancing pool

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. The Pools screen opens. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. Note: If the Create button is unavailable, this indicates that your user role does not grant you permission to create a pool. 3. From the Configuration list, select Advanced. 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.
26 - 9
Chapter 26
To create a virtual server and add the Kerberos delegation and Client SSL profiles to the virtual server
1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. The Virtual Servers screen opens. 2. In the upper-right corner of the screen, click Create. The New Virtual Server screen opens. 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 with HTTP profiles, type 80, or from the service list, select HTTP. If you are using a Client SSL profile type 443, or from the service list, select HTTPS. 6. From the Configuration list, select Advanced. 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-7.
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 "HOST/<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.
26 - 10
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 kerbpwd.
profile auth my_kerberos_profile { defaults from krbdelegate config my_kerberos_config type krbdelegate cookie name kerbc cookie key "kerpwd" }
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.
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 { key myvip.key cert myvip.crt ca file mypdc.crt mypdc.crt peer cert mode require } client cert ca
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
Use the following command to create the virtual server, where <ip addr>:https 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>:https ip protocol tcp profiles http tcp my_clientssl_profile auth my_kerberos_profile }
To enable the Kerberos delegation virtual server from the command line
To complete the configuration of the BIG-IP system for Kerberos delegation, enable the virtual server for the configuration. Type the following command to enable the virtual server, where <name> is the virtual server name:
b auth krbdelegate <name> { protocol transition enable }
26 - 11
Chapter 26
Configuring Kerberos delegation using tmsh

This section describes how to configure Kerberos delegation using tmsh. To configure Kerberos delegation using the Configuration utility, see Configuring Kerberos delegation using the Configuration utility, on page 26-7.
Note
All tmsh command examples in this section require you to be at the tmsh prompt: (tmos.ltm.auth)# in the ltm auth module unless otherwise noted. For more information on working with tmsh, see the Traffic Management Shell (tmsh) Reference Guide.
To create a Kerberos delegation configuration object using tmsh

Within the tmsh ltm auth module, type the following command to create the Kerberos delegation configuration object:
create kerberos-delegation my_kerberos_config client-principal "HOST/<fqdn>" server-principal "HTTP/<fqdn>" protocol-transition enabled debug-logging enabled
For the server principal, use the fully-qualified domain name (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.
Note
Refer to the Traffic Management Shell (tmsh) Reference Guide for kerberos-delegation component options.
To create the Kerberos delegation profile object using tmsh

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 kerbpwd.
create profile my_kerberos_profile configuration my_kerberos_config defaults-from krbdelegate cookie-name kerbc cookie-key kerbpwd
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 - 12
To create the Client SSL profile using tmsh

The next task in configuring Kerberos delegation is to create a Client SSL profile. Within the ltm profile module, type the create client-ssl command as follows:
create client-ssl my_client_ssl_profile key myvip.key cert myvip.crt ca-file mypdc.crt client-cert-ca mypdc.crt peer-cert-mode
Note
Refer to the Traffic Management Shell (tmsh) Reference Guide for client-ssl component options.
Important
You should require a client certificate only if using protocol transition.
To create the load balancing pool using tmsh

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

Type the following command to create the virtual server, where <ip addr>:https 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:
create virtual my_kerberos_virtual snat automap pool webserverpool destination <ip addr>:https ip-protocol tcp profiles add {my_clientssl_profile auth my_kerberos_profile }
To enable the Kerberos delegation virtual server using tmsh

To complete the configuration of the BIG-IP system for Kerberos delegation, enable the virtual server for the configuration. Type the following command to enable the virtual server, where <name> is the virtual server name:
modify kerberos-delegation <name> protocol-transition enabled
26 - 13
Chapter 26
Authenticating Client Traffic

After the network is configured, and the BIG-IP system is configured, Kerberos delegation authenticates clients as a proxy server for Kerberos credentials or with Kerberos protocol transition.
The BIG-IP system as a proxy server for Kerberos

Figure 26.1 shows how client authentication works using the BIG-IP system as a proxy server for Kerberos credentials.
Figure 26.1 How Kerberos delegation authenticates client traffic
The process for authenticating client traffic with Kerberos proxy delegation is as follows: 1. The user logs in 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 to the Kerberos server. 3. The Kerberos server authenticates the user and passes the session credentials to the BIG-IP system where they are stored in a credential cache as long as the client is logged into the BIG-IP system.
26 - 14
4. For the rest of the session, the BIG-IP system acts as a proxy server for credentials requested by other severs within the single domain.
The BIG-IP system for client authentication with protocol transition

Figure 26.2 shows how client authentication works with a constrained Kerberos delegation.
Figure 26.2 How Kerberos protocol transition authenticates client traffic
The process for authenticating client traffic with Kerberos protocol transition is as follows: 1. Client authenticates via certificate to the BIG-IP virtual server. 2. The BIG-IP system verifies the client certificate and extracts the username. 3. The BIG-IP system requests credentials to the pool based on the username. 4. The BIG-IP system passes the credentials obtained in step 3 to the application server. 5. The application server responds. 6. The BIG-IP system passes the response to the client.
26 - 15
Chapter 26
Required Active Directory Settings

The type of delegation your BIG-IP system supports will require specific property settings for the Active Directory server depending on the service your BIG-IP provides. Both settings are found under the Delegation tab of the Active Directory Properties window. If you are using the BIG-IP Kerberos delegation mode, select the Trust this computer for delegation to any service (Kerberos only) option. If you are using the protocol transition mode, select the Trust this computer for delegation to specified services only, option, and then you MUST select the Use any authentication protocol option as shown in Figure 26.3 Add the services that are on the back-end server. Your Active Directory server is now ready to be proxied by your BIG-IP system.
Figure 26.3 Active Directory setting for protocol transition mode.
26 - 16
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
27 - 1
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 Main tab, under Local Traffic. For additional information on using these screens, see the online help.
Configuration utility screen Monitors Profiles Profiles
Object RADIUS health monitor A RADIUS server object A Radius configuration object that references the RADIUS server object A load-balancing pool that references the RADIUS health monitor A virtual server that references the load-balancing pool
Pools
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.
27 - 3
Chapter 27
27 - 4
28
Introducing Diameter load balancing Creating a custom Diameter profile Creating a custom Diameter monitor Creating a Diameter load balancing pool Creating a virtual server for Diameter traffic
Introducing Diameter load balancing

An optional feature of the BIG-IP system is the systems ability to load balance and persist requests that applications send to servers running Diameter services. The BIG-IP system can also monitor each server to ensure that the Diameter service remains up and running. You implement Diameter load balancing by creating various local traffic objects in an administrative partition. The remainder of this chapter describes this process.
Important
To implement Diameter load balancing, you must have a user account with the Administrator, Resource Administrator, or Manager user role assigned to the account. You must also have access to the administrative partition in which the local traffic objects will reside when you create them. For information on creating partitions, as well as managing partitions and partition access, see Chapter 23, Configuring Administrative Partitions to Control User Access. For more detailed, background information on configuring Diameter-related local traffic objects, see the Configuration Guide for BIG-IP Local Traffic ManagerTM.
28 - 1
Chapter 28
Creating a custom Diameter profile

The first task in configuring Diameter load balancing on the BIG-IP system is to create a custom Diameter profile. A Diameter profile defines the way that you want the BIG-IP system to manage application traffic that is targeted to servers running the Diameter service. After you create the custom Diameter profile, you create a Diameter monitor and a load balancing pool. Then, you create a virtual server and assign the custom profile and the pool to that virtual server.
To create a custom Diameter profile

1. On the Main tab of the navigation pane, expand Local Traffic, and click Profiles. 2. From the Services menu, choose Diameter. 3. Click the Create button. 4. In the Name box, type a unique name for the profile, such as my_diameter_profile. 5. Retain the default values for all settings. 6. Click Finished.
Creating a custom Diameter monitor

Once you have created a Diameter profile, you can create a custom Diameter monitor. The purpose of the Diameter monitor is to monitor the health of all servers running the Diameter service.
To create a custom Diameter monitor

1. On the Main tab of the navigation pane, expand Local Traffic, and click Monitors. This displays a list of all pre-configured monitors. 2. Click the Create button. 3. In the Name box, type a unique name for the monitor, such as my_diameter_monitor. 4. From the Type list, select Diameter. 5. Retain the default values for all other settings. 6. Click Finished.
28 - 2
Creating a Diameter load balancing pool

The next step in a basic Diameter load balancing configuration is to define a load balancing pool that contains Diameter servers as its members.
To create a pool for load balancing Diameter traffic

1. On the Main tab of the navigation pane, expand Local Traffic, and click Pools. 2. In the upper-right corner of the screen, click Create. The New Pool screen opens. 3. In the Name box, type a name for the pool, such as my_diameter_pool. 4. For the Health Monitors setting, use the Move button to move the custom Diameter monitor you created in the previous section from the Available box to the Active box. 5. In the Resources area of the screen, use the New Members setting to add the pool members. 6. Click Finished.
Creating a virtual server for Diameter traffic

The final task in configuring Diameter load balancing is to define a virtual server that references the custom Diameter profile and Diameter pool that you created in previous tasks.
To create a virtual server to load balance Diameter traffic

1. On the Main tab of the navigation pane, expand Local Traffic, and click Virtual Servers. 2. Click the Create button. This displays the settings for a Standard type of virtual server. 3. Specify values for the following settings. For all other settings, use the default values:
Setting Name Required Value Type a unique name for the virtual server, such as vs_diameter. Type: Choose virtual server type Host. Address: Type an IP address for the virtual server. Service Port:: Type the number for the Diameter service port.
Destination
28 - 3
Chapter 28
Setting Diameter Profile
Required Value Select the custom Diameter profile that you created previously, such as my_diameter_profile. Specify the pool that you created previously, such as my_diameter_pool.
Default Pool
4. Click Finished.
After you have created the virtual server, you can test the configuration by attempting to pass Diameter traffic through the virtual server.
28 - 4
29
Introducing XML content-based routing Creating an XML profile Creating a pool Creating an iRule Creating a virtual server Viewing statistics about XML content-based routing
Introducing XML content-based routing

You can use the BIG-IP system to perform XML content-based routing whereby the system routes requests to an appropriate pool, pool member, or virtual server based on specific content in an XML document. For example, if your company transfers information in XML format, you could use this feature to examine the XML content with the intent to route the information to the appropriate department. You can configure content-based routing by creating an XML profile and associating it with a virtual server. In the XML profile, you define the matching content to look for in the XML document. You specify how to route the traffic by writing simple iRulesTM. When the system discovers a match, it triggers an iRule event, and you can configure the system to route traffic to a virtual server, a pool, or a node. The implementation described in this chapter routes traffic to a pool. Figure 29.1 shows a simple XML document that the system could use to perform content-based routing. It includes an element called FinanceObject used in the implementation described in this chapter.
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:eai="http://192.168.149.250/eai_enu/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> <soapenv:Header/> <soapenv:Body> <eai:SiebelEmployeeDelete soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <FinanceObject xsi:type="xsd:string">Route to Financing</FinanceObject> <SiebelMessage xsi:type="ns:ListOfEmployeeInterfaceTopElmt" xmlns:ns="http://www.siebel.com/xml"> <ListOfEmployeeInterface xsi:type="ns:ListOfEmployeeInterface"> <SecretKey>123456789</SecretKey> <Employee>John</Employee> <Title>CEO</Title> </ListOfEmployeeInterface> </SiebelMessage> </eai:SiebelEmployeeDelete> </soapenv:Body> </soapenv:Envelope>
Figure 29.1 Simple XML document including FinanceObject element
29 - 1
Chapter 29
Creating an XML profile

To implement content-based routing, you first need to create an XML profile. XML profiles specify the content to look for in XML documents. In the XML profile, you define XPath queries to locate items in an XML document.
To create an XML profile

1. On the Main tab of the navigation pane, expand Local Traffic and point to Profiles, Services, and click the create icon ( ) next to XML. The New XML Profile screen opens. 2. In the Name box, type a unique name for the XML profile, such as cbr_xml_profile. 3. Check the Custom box on the right. The Namespace Mappings and XPath Queries settings become available. 4. If you want to reference XML elements with namespaces in XPath queries, from Namespace Mappings, select Specify. The screen displays the Namespace Mappings List settings. 5. Add namespaces to the list: a) For Prefix, type the namespace prefix. b) For Namespace, type the URL that the prefix is mapped to. c) Click Add to add the namespace to the Namespace Mappings List. 6. To define the matching criteria in the XML document, from XPath Queries, select Specify. The screen displays the XPath Queries settings. 7. Add XPath queries to the list: a) For XPath, type an XPath expression. For example, to look for an element called FinanceObject, type //FinanceObject. For additional details, see Writing XPath queries, on page 29-3. b) Click Add. The expression is added to the list. You can define up to three XPath queries. 8. Click the Finished button. The system creates the XML profile.
Next, create a pool to specify where to send the traffic, as described in Creating a pool, on page 29-4.
29 - 2
Writing XPath queries

You can write up to three XPath queries to define the content that you are looking for in XML documents. When writing XPath queries, you use a subset of the XPath syntax described in the XML Path Language (XPath) standard at http://www.w3.org/TR/xpath. Here are the rules for writing XPath queries for XML content-based routing: Express the queries in abbreviated form. Map all prefixes to namespaces. Use only ASCII characters in queries. Write queries to match elements and attributes. Use wildcards as needed (use * for elements and namespaces); for example, //emp:employee/*. Do not use predicates in queries. Table 29.1 summarizes the syntax for XPath expressions.
Expression Nodename @Attname / // Description Selects all child nodes of the named node. Selects all attribute nodes of the named node. Indicates XPath step. Selects nodes that match the selection no matter where they are in the document.
Table 29.1 Syntax for XPath expressions
Table 29.2 shows examples of XPath queries.

Query /a //b Description Selects the root element a. Selects all b elements no matter where they are in the document. Selects any element in a namespace bound to prefix b, which is a child of the root element a. Selects elements in the namespace of element c, which is bound to prefix b, and is a child of element a.
/a/b:*
//a/b:c
Table 29.2 XPath query examples
29 - 3
Chapter 29
Creating a pool
For implementing content-based routing, you can create one or more pools that contain the servers where you want the system to send the traffic. You write an iRule to route the traffic to the pool.
To create a pool
1. On the Main tab of the navigation pane, expand Local Traffic, point to Pools, and click the create icon ( ) next to Pool List. The New Pool screen opens. Note: If the Create button is unavailable, your user role may not grant you permission to create a pool. 2. In the Name box, type a name for the pool, such as finance_pool. 3. 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 the 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. 4. Click Finished. The system creates the pool.
If you want to specify a default pool to which to send traffic when it does not match the content you are looking for, repeat the procedure to create a second pool. You specify the default pool in the virtual server. Instead of creating a pool, you can alternatively create a node or a virtual server to route traffic to. Refer to the Configuration Guide for BIG-IP Local Traffic ManagerTM for details on creating nodes and virtual servers.
29 - 4
Creating an iRule
You create iRules to automate traffic forwarding for XML content-based routing. When a match occurs, an iRule event is triggered, and the iRule directs the individual request to a pool, a node, or virtual server. This implementation targets a pool.
To create an iRule
1. On the Main tab of the navigation pane, expand Local Traffic, point to iRules, and click the create icon ( ) next to iRule List. The New iRule screen opens. 2. In the Name box, type a 1- to 31-character name, such as XML_CBR_iRule. 3. In the Definition box, type the syntax for the iRule using Tool Command Language (Tcl) syntax. For complete and detailed information on iRules syntax, see the F5 Networks DevCentral web site, http://devcentral.f5.com. 4. Click Finished.
Figure 29.2 shows an example iRule that queries for an element called FinanceObject in XML content and if a match is found, an iRule event is triggered. The system populates the values of the Tcl variables ($XML::count, $XML::queries, and $XML::values). Then the system routes traffic to a pool called finance_pool.
when XML_CONTENT_BASED_ROUTING { for {set i 0} { $i < $XML::count } {incr i} { log local0. $XML::queries($i) log local0. $XML::values($i) if {($XML::queries($i) contains "FinanceObject")} { pool finance_pool } } }
Figure 29.2 Example iRule for XML content-based routing Table 29.3 describes the Tcl variables in the example iRule.
Tcl variable $XML::count $XML::queries $XML::values Description Shows how many queries matched. Contains an array of the query names that matched. Holds the values of the elements that matched.
Table 29.3 Tcl variables in the iRule

29 - 5
Chapter 29

You next define a virtual server to receive the XML traffic.
To create a virtual server for XML content-based routing

1. On the Main tab of the navigation pane, expand Local Traffic, point to Virtual Servers, and click the create icon ( ) next to Virtual Server List. The New Virtual Server screen opens. 2. In the Name box, type a name for the virtual server, such as vs_cbr. 3. For the Destination setting, verify that the Type of virtual server is Host, and in the Address box, type an IP address for the virtual server. 4. From the Service Port list, select HTTP. 5. From the Configuration list, select Advanced. 6. From the HTTP Profile list, select http. This assigns the default HTTP profile to the virtual server. 7. From the XML profile list, select the XML profile you created, such as cbr_xml_profile. 8. For the SNAT Pool setting, select Auto Map. 9. In the Resources area, for iRules, in the Available list, select the name of the iRule that you previously created, such as XML_CBR_iRule, and move it to the Enabled list. 10. If you created a second pool, for Default Pool, select the pool to use as the default pool. 11. Click Finished. The system creates the virtual server.
When traffic that is routed to the virtual server includes the FinanceObject element and causes a match, the system sends it to the pool called finance_pool. If traffic does not include the element and does not cause a match, the system sends the request to the default pool, if one is specified, or drops the request, if no default pool is specified.
29 - 6
Viewing statistics about XML content-based routing

You can view statistics about content-based routing to make sure that it is working.
To view statistics about XML content-based routing

1. On the Main tab of the navigation pane, expand Overview and click Statistics. The Local Traffic Statistics screen opens. 2. For Statistics Type, select Profiles Summary. 3. In the Global Profile Statistics area, next to XML, click View. The system displays information about the number of XML documents that were inspected, the number of documents that had no matches, or that had one, two, or three matches, and the number of XML documents that were found to be malformed.
Note
The system first checks for a match, then checks for malformedness of XML content. So if the system detects a match, it stops checking, and may not detect any subsequent parts of the document that are malformed.
29 - 7
Chapter 29
29 - 8
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 hosts Media Access Control (MAC) address based on its IP address. authentication Authentication is the process of verifying a users 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.
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. Diameter protocol Diameter is an industry-standard protocol developed to strengthen security and augment functionality of the Remote Authentication Dial In User Service (RADIUS) protocol. 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.
Glossary - 3
Glossary
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. 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.
Glossary - 4
Glossary
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. 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).
Glossary - 5
Glossary
Link Aggregation Control Protocol (LACP) See LACP (Link Aggregation Control Protocol). load balancing method A particular method of determining how to distribute connections across a load balancing pool. 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.
Glossary - 6
Glossary
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. 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 implement on a BIG-IP system to authenticate client traffic using a remote 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.
Glossary - 7
Glossary
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. 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 persistence profile. 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.
Glossary - 8
Glossary
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. 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 implement on a BIG-IP system to authenticate client traffic using a remote RADIUS server. RAM cache A RAM cache is a cache of HTTP objects stored in the BIG-IP systems 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.
Glossary - 9
Glossary
responder object See OCSP responder object. route domain A route domain is a BIG-IP system object that allows you to isolate a type of application traffic to a defined address space on the network. 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). 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 walks 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 on a 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.
Glossary - 10
Glossary
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. 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 users 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 implement on a BIG-IP system to authenticate client traffic using a remote TACACS+ server.
Glossary - 11
Glossary
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. 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.
Glossary - 12
Glossary
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. 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 - 13
Glossary
Glossary - 14
Index
Index
/config/bigip.conf file 27-3 /etc/radvd.conf file 21-1 %ID notation 6-2
A
access to partitions 23-5 access control configuring 24-7 tailoring 23-1 access control combinations 24-8 access control groups See partitions. access control process See authorization steps. access levels for partition Common 23-2 See also user access. access-control properties configuring 24-6 Access-Request packets 25-9 ACK packets 2-2, 2-6 Active Directory remote authentication 24-2 adaptive connection reaping 22-2, 22-3 adaptive reaper 22-9 additional information for Bigpipe Utility Reference Guide 1-2 for Configuration Guide for BIG-IP Local Traffic Manager 1-2 for Configuration Worksheet 1-2 for Installation, Licensing, and Upgrades for BIG-IP Systems 1-2 for Platform Guide 1-2 for TMOS Management Guide for BIG-IP Systems 1-2 address translation 2-1, 2-2, 8-5 admin account 23-2 administrative partitions and route domains 6-6 defined 23-1 Administrator role and object management 23-4 Administrator role access 23-2 aggregation, of links 18-1 application traffic isolating 6-1 ARP protocol 2-5 authentication for remote user accounts 24-1 authentication attributes 24-9, 24-10 authentication module types 25-8 authentication server types 24-2 authentication servers as pool members 27-1
authorization data propagating 24-1 authorization failure 24-9 authorization levels determining 23-3 authorization properties configuring 24-6 authorization steps 23-2
B
Back Orifice attacks 22-12 BIG-IP system adding to network 4-1 configuring for same network 4-3 to replace switches 4-2 BIG-IP system bypass 2-1 BIG-IP system objects 23-1 bigpipe -? command 24-8 bigpipe shell and user roles 23-2 broadcast addresses 2-4 built-in switching for multiple customer hosting 5-5
C
cache servers 7-1 certificate installation 13-1 Certificate Revocation List Distribution Point protocol See CRLDP authentication module. certificates requesting from CAs 12-3, 13-2 client credentials 25-8 client requests and BIG-IP system 2-6 decrypting 12-7 Client SSL profiles assigning 12-7, 13-8 creating 12-4, 13-4 defined 12-1, 13-1 command line interface See bigpipe shell. common configuration 7-1 compression and iRules 11-1 and RAM Cache 14-1 configuring 13-5 compression tasks 11-1 configuration data importing and exporting 24-11 configuration examples, Internet 3-1 Configuration utility and online help 1-5 and Welcome screen 1-5 Configuration Worksheet 1-2 connection flooding 22-9 Index - 1
Index
connection request types 7-1 connection timeout 2-6, 22-8 connections adding 8-1 authenticating 25-8 reaping 22-2 See also Internet connections. content demand for 14-1 static 14-1 content compression and RAM Cache 14-1 content-based routing, XML 29-1 cookie persistence 10-1 cookie persistence profiles 10-2 cookies 22-8 corporate intranet 7-1 CRLDP authentication module defined 25-21 CRLDP configuration objects defined 25-22 CRLDP profile type defined 25-23 CRLDP responder objects defined 25-21 CRLDP server objects defined 25-21 custom HTTP profiles described 10-1 using 9-1 custom monitors 20-1 custom persistence profiles described 10-1 using 9-1 custom RADIUS profiles assigning 25-10 customers hosting for 5-1
Denial-of-Service attacks 22-1, 22-8 Denial-of-Service prevention 22-4 destination address translation 2-1 Diameter configuration process 28-2 Diameter health monitor 28-2 Diameter load balancing creating pools for 28-3 creating virtual servers for 28-3 overview of 28-1 Diameter services 28-1 and health monitoring 28-2
E
e-commerce traffic load balancing 3-1 expressions for packet filtering 19-1
F
Fast L4 profiles assigning 2-4 creating 2-2, 2-3 for nPath routing 2-2 files including and excluding 11-1 FIN packets 2-2 flooding 22-9 formatting conventions 1-3 FTP monitors 15-2, 16-2 FTP pools assigning 15-4 creating 15-3, 16-3 FTP profiles assigning 15-4 defined 15-1 FTP traffic 15-1 FTP virtual servers creating 15-4, 16-5
D
data attacks 22-11 data center topology 4-1 data compression and RAM Cache 14-1 data propagation 24-7, 24-11 default HTTP profiles described 10-1 using 9-1 default persistence profiles described 10-1 using 9-1 default routes for nPath routing 2-2 setting 2-2, 17-4 default wildcard servers 7-2
G
gateways and nPath routing 2-5 groups assigning privileges to 24-7 for user access control 24-1 Guest role tasks 23-3
H
health monitors for Diameter servers 28-2 for remote authentication servers 27-1 help, online 1-5 high demand objects 14-1
Index - 2
Index
high-water mark See adaptive connection reaping. hosting services using route domains 6-1 HTTP compression tasks 11-1 HTTP connections 10-3 HTTP headers 14-1 HTTP methods 14-1 HTTP pools assigning for compression 11-3, 28-4 assigning for RAM Cache 14-3 assigning for source address persistence 9-3 creating for cookie persistence 10-3 creating for source address persistence 9-2 HTTP profiles creating for compression 11-2, 13-5 creating for LDAP authentication 25-16 creating for RAM Cache 14-2 defined 10-1 described 9-1 HTTP RAM Cache See RAM Cache. HTTP traffic controlling for compression 11-1 controlling for cookie persistence 10-1 controlling for source address persistence 9-1 HTTP virtual servers creating for compression 11-3 creating for cookie persistence 10-3 creating for source address persistence 9-3 HTTPS pools assigning 12-7, 13-8 creating 12-6, 13-7 HTTPS traffic 12-7 HTTPS virtual servers creating 12-7, 13-8
IP addresses and loopback interfaces 2-5 and nPath routing 2-5 duplicating on network 6-1 removing from VLANs 18-7 IP aliases and nPath routing 2-5 IP network changing 4-1 IP network topology with single interface 4-1, 17-1 IP packets recognition by clients 17-5 routing incorrectly 2-5 IPV6 nodes 21-2 iRules for compression 11-1 for XML content-based routing 29-5
K
key installation 13-1
L
L2 forwarding 4-1 LACP protocol 18-3 Land attacks 22-10 LDAP configuration objects 25-2 LDAP profile type defined 25-6 LDAP remote authentication 24-2 link aggregation about 18-1 and network configurations 18-6 and VLAN groups 18-7 configuring 18-2 local traffic objects and route domains 6-6 loopback interfaces 2-2, 2-5 low-water mark See adaptive connection reaping.
I
ICMP floods 22-9 idle timeout values 2-2, 2-3 inbound traffic 8-3 inheritance prevention for monitors 20-5 interfaces and partitions 23-2 assigning as tagged 5-2 using link aggregation 18-1 Internet connections adding more 8-1 example 8-1 load balancing 8-1 intranet configuration creating 7-2 IP address translation 2-1
M
Manager role access 23-2 Manager role tasks 23-3 monitor inheritance 20-4 monitor settings 20-1 monitor types 20-1 monitors assigning to pools 20-4 creating 20-3 creating for FTP servers 16-2 defined 20-1 for Diameter load balancing 28-2 for FTP servers 15-2 removing 20-5
Index - 3
Index
MS Loopback interface 2-5 multiple customer hosting about 5-1, 6-1 configuring 5-2, 6-2 creating pools for 5-3 creating VLAN tags for 5-2 using built-in switching 5-5
P
packet filter rules creating 19-4 purpose of 19-1 packet filters 19-1, 19-4 packets forwarding and rejecting 19-1 receiving and copying 4-4 recognition by clients 17-5 partition access configuring 23-3 Partition Access list 23-4 partition Common described 23-2 partition contents 23-1 partition property 24-6 partitioned objects creating 23-5 described 23-2 partitions and user roles 23-2 benefits of 23-2 creating 23-2 defined 23-1 selecting 23-5 password credentials 25-8 performance monitors 20-2 permissions determining 23-1 See also user access. persistence 2-6 implementing 9-1 See also cookie persistence. persistence profiles assigning for compression 13-8 assigning for FTP 15-4 assigning for HTTP 10-4 assigning for HTTPS 12-7 assigning for RAM Cache 14-3 creating 10-2 Ping of Death attacks 22-10 Platform Guide 1-2 pool member exclusion 20-4, 20-5 pool members and Operator role 23-3 pools creating for a basic configuration 7-2 creating for Diameter load balancing 28-3 creating for e-commerce 3-1, 3-2 creating for FTP servers 15-3 creating for HTTP 9-2, 10-3 creating for HTTPS 12-6, 13-7 creating for intranet configuration 7-2 creating for ISP load balancing 8-2 creating for link aggregation 18-4 creating for monitors 20-4
N
NAS-Identifier string 25-9 netmask 2-4 network changing 4-1 network adapter list 2-5 network configurations and link aggregation 18-2, 18-6 for IP network topology 17-1 network objects and route domains 6-6 network prefixes 21-1 network traffic and additional connections 8-1 and packet filters 19-1 managing 2-1 network traffic authentication types 25-1 node configuration and radvd service 21-1 nodes and Operator role 23-3 nPath routing 2-1, 2-5 nPath routing tasks 2-2 numeric values for user privileges 24-9
O
object creation and partition location 23-5 object re-use 14-1 objects and Guest role 23-3 defined 23-1 demand for 14-1 viewing and managing 23-4 OCSP authentication module See SSL OCSP authentication module. OCSP responder objects creating 25-18 one-network topology 18-6 Online Certificate Status Protocol See SSL OCSP authentication module. online help 1-5 Operator role tasks 23-3 Other External Users account 24-6 outbound throughput increasing 2-1 Index - 4
Index
creating for multiple customer hosting 5-3 creating for nPath routing 2-4 creating for rate shaping 16-3 creating for routers 19-2 creating for single network 17-2 creating for XML content-based routing 29-4 of web servers 4-5 port translation 2-2 ports for e-commerce 3-1 pre-configured monitors 20-1 privileges assigning 24-7 configuring 24-6 for individual accounts 24-6 See also access control profiles creating for HTTP 11-2, 25-16 creating XML 29-2 protocols for remote authentication servers 25-1
R
RADIUS authentication module implementing 25-8 RADIUS authentication profiles assigning 25-10 RADIUS configuration objects creating 25-9 specifying in profile 25-10 RADIUS configuration overview 25-8 RADIUS profiles creating 25-10 RADIUS secret 25-8 RADIUS server configuration 27-2 RADIUS server objects creating 25-8 specifying in configuration object 25-9 RADIUS servers and authentication 25-8 and traffic authentication 25-8 RADIUS user authorization configuring 24-4 RADIUS-based authentication configuring 24-4 radvd service 21-1 RAM Cache defined 14-1 RAM Cache compliancy 14-1 RAM Cache virtual servers 14-3 rate classes and virtual servers 16-5 creating 16-4
rate shaping and FTP traffic 16-4 as optional feature 16-1 Read access 23-2 regular expressions 11-1 remote attribute mapping 24-7 remote authentication for system user accounts 24-2 remote authentication attributes 24-9, 24-10 remote authentication issues 27-1 remote authentication requirements 27-2 remote authentication server types 24-2, 25-1 remote user authentication configuring 24-1 remoterole command purpose of 24-1, 24-6, 24-7 remoterole command syntax 24-7 requests decrypting 12-1, 13-1 encrypting 12-1, 13-1 resource exhaustion 22-8 response types 14-1 responses compressing 11-1 encrypting 12-1, 13-1 retransmission timeout See RTO. role property 24-6 route configuration for nPath routing 2-2 route domain configuration and prerequisites 6-1 example of 6-6 route domains and administrative partitions 6-2, 6-6 and BIG-IP system objects 6-6 and duplicate IP addresses 6-1 defined 6-1 router pools 19-2 routers increasing throughput 2-1 routes for nPath routing 2-5 for packets 4-5 routing configuring XML content-based 29-1 routing conflicts 4-5 RTO 2-6
S
SCF purpose of 24-11 SCFs creating 24-11
Index - 5
Index
secondary RADIUS servers configuring 24-4 self IP addresses and partitions 23-2 creating 18-8 creating for VLAN groups 4-5 for external VLAN 8-5 removing 4-3, 18-7 self-signed certificates 12-2, 13-2 server hosting 3-1 server load 14-1 server pools for nPath routing 2-4 server responses encrypting 12-1, 12-7, 13-1 session persistence implementing 9-1 See also cookie persistence. See also source address affinity persistence. simple persistence See source address affinity persistence. Single Configuration File and access control 24-1 See SCF. Smurf attack 22-9 SNAT Automap about 8-1 for VLANs 8-5 SNAT source translations 17-1 SNATs creating 19-2 source address affinity persistence 9-1 source address translation 2-1 source IP addresses and session persistence 9-2 SSL certificates importing 24-2 SSL Client Certificate LDAP configuration objects creating 25-15 SSL Client Certificate LDAP profiles creating 25-16 SSL handshaking for compression 13-1, 13-2 for HTTPS 12-1, 12-2, 12-7 SSL keys and certificates creating 12-2, 13-2 installing 13-1 SSL OCSP authentication module defined 25-18 SSL OCSP configuration objects creating 25-19 SSL OCSP profile type defined 25-19 SSL OCSP responder objects creating 25-18
SSL profiles See Client SSL profiles. SSL traffic authentication 24-2 state keeping 22-8 static content 14-1 statistics, XML content-based routing 29-7 style conventions 1-3 Sub 7 attacks 22-11 SYN Check feature, activating 22-9 SYN cookies 22-8, 22-9 SYN floods 22-8 SYN packets 2-2, 2-6 system access controlling 23-1 system object creation and partition location 23-5 system objects viewing and managing 23-4 system resource exhaustion 22-8
T
TACACS+ configuration object defined 25-12 TACACS+ configuration overview 25-12 TACACS+ profiles creating 25-13 tagged interfaces 5-2, 18-1 Tcl variables for content-based routing 29-5 TCP connections 22-8 TCP timers 2-6 TCP traffic and nPath routing 2-2, 2-6 tcpdump utility 19-1 Teardrop attacks 22-11 terminal access property 24-6 throughput increasing 2-1 throughput optimization 17-5 timers 2-6 topology 4-1 traffic and same network 4-4 returning 2-1 traffic isolation example of 6-6 traffic load 14-1 trunk members 18-3 trunks 18-3
U
UDP floods 22-9 UDP fragment attacks 22-10 UDP timers 2-6 UDP traffic and nPath routing 2-6
Index - 6
Index
universal access 23-5 URIs including and excluding 11-1 user access configuring 23-3 denial of 24-8 tailoring 23-1 to partition Common 23-2 user account duplication 24-7 user account objects and manager role 23-3 user account properties modifying 23-3 user accounts defined 23-1 user authentication configuring 24-1 user name credentials 25-8 user partition property 24-6 user privileges assigning 24-7 user role property 24-6 user roles and Diameter load balancing 28-1 and partition access 23-2 and route domains 6-2 defined 23-1 for partition creation 23-2 U
for HTTP 9-3 for HTTPS 12-7, 13-8 for IPv6 nodes 21-3 for link aggregation 18-5 for multiple customer hosting 5-3 for nPath routing 2-4 for RAM Cache 14-3 mapping to IP addresses 2-4 modifying for CRLDP authentication 25-24 modifying for RADIUS authentication 25-11 modifying for SSL Client Certificate LDAP authentication 25-17 modifying for SSL OCSP authentication 25-20 modifying for TACACS+ authentication 25-14 VLAN groups creating 4-4, 18-7 VLAN tags creating 5-2, 18-3 VLANs and partitions 23-2 and tagged interfaces 5-2 removing self IP addresses from 4-3, 4-4 using link aggregation 18-1
W
web server arrays 3-1 web server pools creating 4-5 Welcome screen 1-5 wildcard virtual servers defined 7-2 WinNuke attacks 22-11
V
variable substitution for access control 24-8 vendor-specific attributes 24-7, 24-8 virtual authentication servers and VLANs 27-2 defined 27-1 virtual server addresses 2-2 virtual server modification 25-11 virtual servers and e-commerce 3-1 and SNATs 17-1 and web server pools 4-6 creating for e-commerce 3-3 creating for HTTP 10-3 creating for inbound and outbound traffic 8-3 creating for intranet configuration 7-3 creating for multiple customer hosting 5-3 creating for single network 17-3 creating for XML content-based routing 29-6 for a basic configuration 7-3, 19-3 for compression 11-3 for Diameter load balancing 28-3 for FTP 15-4 for FTP and rate shaping 16-5
X
XML content-based routing 29-1 XML document example 29-1 XML profiles, creating 29-2 XPath query syntax 29-3
Index - 7

BIG-IP Local Traffic Manager Implementations

Uploaded by

Document Information

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 Local Traffic Manager Implementations

Uploaded by

Copyright:

Available Formats

BIG-IP Local Traffic ManagerTM: Implementations

Export Regulation Notice

BIG-IP Local Traffic Manager: Implementations

Canadian Regulatory Compliance

BIG-IP Local Traffic Manager: Implementations

BIG-IP Local Traffic Manager: Implementations

BIG-IP Local Traffic Manager: Implementations

BIG-IP Local Traffic Manager: Implementations

Introducing Implementations for BIG-IP Local Traffic Manager

Introducing BIG-IP system implementations

Using the Configuration utility

BIG-IP Local Traffic Manager: Implementations

About this guide

Introducing Implementations for BIG-IP Local Traffic Manager

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

Table 1.1 Command line syntax conventions

Introducing Implementations for BIG-IP Local Traffic Manager

Finding help and technical support resources

BIG-IP Local Traffic Manager: Implementations

Configuring nPath Routing

Introducing nPath routing

Figure 2.1 An example of nPath implementation

Configuring nPath routing

Configuring nPath Routing

Creating a custom Fast L4 profile

To create a custom Fast L4 profile

BIG-IP Local Traffic Manager: Implementations

Creating a server pool for nPath routing

Creating a virtual server

To create a standard virtual server

Configuring nPath Routing

Configuring the virtual server on the content server loopback interface

Setting the route for inbound traffic

Enabling the connection.autolasthop bigdb key

BIG-IP Local Traffic Manager: Implementations

Setting timers for nPath configurations

Guidelines for configuring timeouts for UDP traffic

Guidelines for configuring timeouts for TCP traffic

Basic Web Site and E-Commerce Configuration

Working with a basic web site and e-commerce configuration

Figure 3.1 A basic load balancing configuration

BIG-IP Local Traffic Manager: Implementations

Configuring a basic e-commerce site

Creating load balancing pools

To create a pool for load balancing HTTP traffic

Basic Web Site and E-Commerce Configuration

To create a pool for load balancing SSL traffic

Creating virtual servers

To define a virtual server for HTTP traffic

To define a virtual server for SSL traffic

Installing a BIG-IP System without Changing the IP Network

Installing a BIG-IP system without changing IP networks

Figure 4.1 Existing data center network structure

BIG-IP Local Traffic Manager: Implementations

Figure 4.2 New structure after adding the BIG-IP system

Installing a BIG-IP System without Changing the IP Network

Configuring the BIG-IP system for the same IP network

Removing the self IP addresses from the individual VLANs