F5 Administering BIP-IP V11

-
'V '
t;/' \(1(;!vJ
F5 Networks Training
Administering BIG-Ip® V11

Student Guide
v11.4.0 - December, 2013
Administering BIG-IP v1.1

Administering BIG-Ip® V11
Student Guide
Sixth Printing; December, 2013
This manual was written for BIG-Ip® products version 11 A. Some of Ihe features discussed in this course were added with
version 11.4, but most of the concepts apply to previous versions of BIG-Ip®.
© 2013, F5 Networks, Inc. All rights reserved.
Support and Contact Information

Obtaining Technical Support
Web tech.f5.com (Ask FS)
Phone (206) 272-6888
Email (supportissues)support@fS.com
Email (suggestions)fecdback@fS.com
Contacting F5 Networks
Web www.fS.com
Email sales@fS.com & info@fS.com
FS Networks, Inc. F5 Networks, Ltd. FS Networks, Inc. FS Networks, lne.

Corporate Office United Kingdom Asia Pacific Japan
401 Elliott Avenue West Chertsey Gate West 5 Temasek Boulevard Akasaka Garden City 19F
Seattle, Washington 98119 Chertsey Surrey KT 16 8AP #08-01102 Suntec Tower 5 4-15-1 Akasaka, Minato-ku
T (888) 88BIG-I P United Kingdom Singapore, 038985 Tokyo 107-0052 Japan
T (206) 272-5555 T (44) 0 1932582-000 T (65) 6533-6103 T(81)35114-3200
F (206) 272-5557 F (44) 01932582-001 F (65) 6533-6106 F (81) 3 51 14-3201
Training@ f5.com EMEATraining@f5.com APACTraining@f5.com JapanTraining@fS.com
Administering BIG-IP v11

Legal Notices
Copyright
Copyright 2013, F5 Networks, lnc. All rights reserved.
F5 Networks, lnc. (F5) believes the infonnation it furnishes to be accurate and reliable. However, F5
assumes no responsibility for the use of this infonnation, 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
3DNS, Access Policy Manager, Acopia, Acopia Networks, Advanced Client Authentication, Advanced
Routing, APM, Application Security Manager, ARX, AskF5, ASM, B1G-1P, Cloud Extender,
CloudFucious, CMP, Data Manager, DevCentral, DevCentral [DESIGN], DS1, DNS Express, DSC, Edge
Client, Edge Gateway, Edge Portal, EM, Enterprise Manager, F5, F5 [DES[GN], F5 Management Pack,
F5 Networks, F5 World, Fast Application Proxy, Fast Cache, FirePass, Global Traffic Manager, GTM,
lBR, lntelligent Browser Referencing, Intelligent Compression, lPv6 Gateway, iApps, iControl, iHeaJth,
iQuery, iRules, iRules OnDemand, iSession, IT agility. Your way., L7 Rate Shaping, LC, Link
Controller, Local Traffic Manager, LTM, Message Security Module, MSM, Netcelera, OneConnect,
Packet Velocity, Protocol Security Module, PSM, Real Traffic Policy Builder, ScaleN, SSL Acceleration,
StrongBox, SuperVlP, SYN Check, TCP Express, TOR, TMOS, Traffic Management Operating System,
TrafficShieJd, Transparent Data Reduction, UNlTY, VlPRlON, vCMP, WA, WAN Optimization
Manager, WANJet, WebAccelerator, WOM, and ZoneRwmer, are trademarks or service marks ofF5
Networks, lnc., 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.
Materials
The material reproduced on this manual, including but not limited to graphics, text, pictures, photographs,
layout and the like ("Content"), are protected by United States Copyright law. Absolutely no Content
from this manual may be copied, reproduced, exchanged, published, sold or distributed without the prior
written consent of F5 Networks, Inc
Patents
This product may be protected by U.S. Patents 6,31 1,278,6,327,242,6,374,300,6,405,2 I 9,6,473,802,
6,505,230,6,640,240,6,772,203,6,970,933, 6,889,249, 7,047,301, 7,051,126, 7,102,996, 7,1 13,962,
7,114,180,7,126,955,7,146,354,7,197,661, 7,206,282, 7,286,476, 7,287,084, 7,296,145, 7,296,263,
7,308,475,7,343,413,7,346,695,7,349,391, 7,355,977, 7,376,967, 7,383,288, 7,395,349, 7,409,440,
7,409,460,7,430,755,7,441,045,7,461,290, 7,472,413,7,487,253,7,490,162,7,493,383,7,505,455,
7,509,322,7,512,673,7,552,191,7,558,848, 7,562,1l0, 7,567,573, 7,580,353, 7,590,625, 7,606,9[2,
7,639,700,7,640,347,7,640,580,7,650,392, 7,657,618, 7,676,828, 7,697,427, 7,702,809, 7,705,829,
7,707,182,7,707,287,7,707,289,7,710,867, 7,752,400, 7,768,823, 7,774,484, 7,774,835, 7,783,781,
7,788,335,7,822,839,7,826,487,7,831,712, 7,882,084, 7,916,728, 7,916,730, 7,921,282, 7,945,678,
7,953,838,7,958,222,7,958,347,7,975,025 7,996,886, 8,004,971, 8,005,953, 8,010,668, 8,015,314,
8,024,443,8,024,483,8,103,746,8,103,770,8,103,809, 8,108,554,8,112,491,8,116,222,8,117,244,
8,121,117,8,145,768,8,150,957,8,159,940, 8,176,164, 8,180,747, 8,185,617, 8,189,476, 8,195,760,
8,195,769, 8,200,957, 8,203,949, 8,204,860, 8,204,930, 8.209,403, 8,239,354, 8,260,958, 8,261,351,
8,275,909,8,284,657,8,301,837,8,306,036, 8,306,038, 8,326,923, 8,326,984, 8,341,296, 8,345,701,

8,346,993,8,347,100,8,352,597,8,352,785, 8,375,421, 8,379,515, 8,380,854, 8,392,372, 8,392,563,
8,396,836,8,396,895,8,397,059,8,400,919, 8,407,771, 8,412,582, 8,417,681, 8,417,746, 8,417,833,
8,418,233,8,429,783,8,432,791,8,432,799, 8,433,735, 8,438,253, 8,447,871, 8,447,883, 8,447,884,
8,453,120,8,463,850,8,463,909,8,477,609, 8,477,798, 8,484,361. Other patents may be pending. This
patent list is complete as of July 2013.
Disclaimer
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.
Administering BlG-IP v11

Administering BIG-IP v11: Table of Contents
Table of Contents
Chapter 1: Selling Up the BIG-IP System ............................................................................ 1-1
Introducing the BIG-IP System .... .............. ...1-1
Initially Setting Up the BIG-IP System ........................................................................................................... 1-10
Configuring the Management Interface ......................................... I-II
Activating the Software License ............................................................................................................... 1-13
Provisioning Modules and Resources ...................................................................................................... 1-15
Importing a Device Certificate ......... ................. ........... ...... ........ . .......................... 1-17
Specifying BIG-IP Platform Properties .................................................................................................... 1-18
Configuring the Network .............. . .......................................................................................... 1-22
Creating an Archive of the BIG-IP System ...................................................................................................... 1-26
F5 Support Resources and Too]s.. ......................... . ..................... 1-28
Chapter Resources .................. . ... ]-32
BIG-IP System Setup Labs .. 1-33
Lab I.I - Configure the Management Port ............................................................................................... ] -34
Option A: Configure the management port via the management port ....................................... 1-36
Option B: Contigure the management port via a serial console... .................................. 1-39
Option C: Configure the management port via the LCD panel ................................................. 1-42
Lab 1.2 - Activate the BlG-IP System..... ...................... . .......................................... 1-43
Option A: Activate a licensed BIG-IP system ............. . . ........................................ 1-44
Option B: Activate an unlicensed BIG-1P system ................................. 1-46
Lab 1.3 - Classroom Network Configuration ........................................................................................... I-50
Lab 1.4 - Test Access and Archive the Configuration....... . ................................................................ I-55
Lab 1.5 - AskF5 Research Lab (Optional) ............................ . ................................................................. 1-61

II Administering BIG-IP v11: Table of Contents
Chapter 2: Traffic Processing with LTM .............................................................................. 2-1
Overview ofLTM Traffic Processing ........... . .. ........ 2·1
Configuring Virtual Servers and Pools ................... . .......... 2·8
Load Balancing Concepts .......................................... . ................................................................. 2-11
Traffic Statistics and Logs ............................................... . ............................ 2-14

Chapter Resources ............................................................................... . ... 2-21
Traffic Processing Labs .................................................................. ................. . .... 2-22
Lab 2.1 - Virtual Servers and Pools Lab ................................................................ . ......... 2·22
Lab 2.2 - Packet Discards Lab (Optional) .................... . .................................... 2·28
Chapter 3: Using NATs and SNATs ..................................................................................... 3-1
NAT Concepts ..................................................................................... . .............................. 3-2
SNAT Concepts .............................................................................. . ............................ 3·6
........................ 3·15
SNAT Pools ....... . ...................................................................................... 3·17
Chapter Resources ........................................................................................................................................... 3-20
Address Translation Labs ............................................................................ . .. 1·33
Lab 3.1 - NAT Lab ................................ . .. 3·21
Lab 3.2 - SNAT Lab ................................................................................ . ... 3·23
Chapter 4: Using the Traffic Management Shell (tmsh) ..................................................... 4-1
Traffic Management Shell (trush) .................................. . .................................... ~I
Accessing the Traffic Management Shell (trush). ....................................................................... ~2
Understanding and Navigating the tmsh Hierarchical Structure .4·3
Command Completion Feature ................................................................................. . .... 4-6
tmsh Help Functions ............................................. . ........................................................ ~7
tmsh Command History Feature ........................... .. ........................ 4-8
tmsh on DevCentral .............................................................................................. . ........................... 4-9
BIG·IP Configuration State and Files .............................................................................................................. 4-10
BIG-IP Configuration Files ................................................... . ......................................................... 4-12
Loading and Saving the System Configuration ......................... . ............................................................. 4-13
Shutting Down and Restarting the BTG-IP System .................................................................................. 4·14
Saving and Replicating Configuration Data CUCS and SCF) .......................................................................... 4-15
Chapter Resources ......................... ................................................................................... 4·21
Lab 4.1 - tmsh Configuration Labs ... ......................... ........................ .. ............. .... 4-22
It Administering BIG-IP v11

Administering BIG-IP v11: Table of Contents III
Chapter 5: Monitoring ........................................................................................................... 5-1
Monitor Concepts .............................................................................................................................................. 5-1
Configuring Monitors.. . . .. .... ....... . ................. 5-9
Assigning Monitors to Resources. .. 5-12
Managing Pool, Pool Member, and Node Status ............................................................................................. 5-17
Using the Network Map ....... ............. .................. . ... 5-23
Chapter Resources. ............. ........................... . ... 5-25
Lab 5.1 - Configure Monitors Lab .................................................................................................................. 5-18
Chapter 6: Modifying Traffic Behavior with Profiles..........,.......,.............,.......,.......,.......... 6-1
Introducing Profiles ................................................................................................................. 6-1
Introducing SSL Termination.. . ... 6-3
Understanding Profile Types and Dependencies .... 6-7
Configuring and Assigning Profiles. .............. ..6-10
Chapter Resources.. . ................................................................................................................. 6-13
Lab 6.1 - Client SSL Profile Lab .............. 6-14
Chapter 7: Modifying Traffic Behavior with Persistence., .................................................. 7-1
Understanding Persistence .. . ............................ 7-1
Introducing Source Address Affinity Persistence ............................................................................................. 7-5
Introducing Cookie Persistence ... ...................................................................................... 7~
Lab 7.1 - Source Address Affinity Persistence .... . ...... 7-12
Lab 7.2 - Cookie Persistence ............................................................................................................... 7-18
Managing Object State .... . ........ 7-23
Lab 7.3 - Managing Object State Lab ..... 7-30
Chapter 8: Deploying Application Services with iApps...................................................... 8-1
Introducing iApps ....... ...... ....... ...... ...... ......... ........ .......... ........ .......... ..... ... ............. .. 8-1
Using iApps Templates ...... . .... ........................... ..8-4
Deploying an Application Service ............................................................................................... 8-8
Leveraging the iApps Ecosystem on DevCentral ..................... . ..... 8-14
Lab 8.1 - Deploy a Simple Website Application ............................................................................................ 8-15
Lab 8.2 - Deploy a Custom Application Service ...... .................. ................... ... 8-25
Administering BIG-IP v11 iii

iv Administering BIG-IP v11: Table of Contents
Chapter 9: Troubleshooting the BIG-IP System .................................................................. 9-1
Configuring Logging ........................................................................................................................................ 9-1
Monitoring the BIG-IP System Remotely with SNMP . .............................. 9-11
Using tcpdump on the BIG-IP System .......................................................................................................... 9-16
Lab 9.1 - Remote Syslog Lab ......................................................................................................................... 9-24
Lab 9.2 - SNMP Trap Lab...... .................................................................... ... 9-27
Lab 9.3 - High-Speed Logging Lab ............................................................................................................... 9-30
Leveraging the BlG-IP iHealth System.. .............................................................. 9-35
Analyzing Application Perfonnance with Analytics.. ............................................. ..................... ..... 9-42
Working with F5 Tcchnical Support ............................................................................................................... 9-46
Chapter Resources.. ... ... .......... ............ ...... 9-51
Lab 9.4 - Troubleshooting Lab .................................................................................................................... 9-52
Lab 9.5 - iHealth Lab (Optional) ................ ............................................ ............ 9-53
Chapter 10: The BIG-IP Product Suite ............................................................................... 10-1
BIG-IP Product Family Overview .............. ... ............. ................... 10-1
DNS and GTM System Options ...................................................................................................................... 10-2
ASM as a Wcb Application Fircwall.. ................... .................. 10-8
APM and Secure Access ........................ .. . ...... 10-16
BlG-IP Product Traffic Proccssing ......... 10-19
Introduction to Enterprise Manager ............................................................................................................... 10-22
Chapter 11: Administering the BIG-IP System .................................................................. 11-1
High Availability Concepts ...... . .................... J I-I
Always On Management (AOM) .. ... 11-4
Expanding Network Configuration Options (Interfaces, Trunks, VLANs, SelfIPs) 11-5
Restricting Traffic on the BlG-IP System . . . . . . . . . . . . . . 11-14
Lab 11.1- Packet Filters Lab ................... . .... 11-23
Lab 11.2 - AOM IP Address Lab (BIG-IP Hardware Only) .................................................................... I J-27
License Dates and Upgrade Considerations ..... ........................ ......................................................... ...11-28
BlG-IP Disk and Software Management ....................................................................................................... 11-31
User Roles and Administrative Partitions. . . . ......•................................................................ J 1-42
CMP and vCMP ..... . ........................................... 11-49
Chapter Resources .. . ... II-57
Lab 11.3 - Admin Partitions and Users Lab .......... . ..... II-59
iv Administering BIG-IP v11

Administering BIG-IP v11: Table of Contents v
Chapter 12: Customizing Application Delivery with iRules ............................................. 12-1
iRules Concepts .......... 12-1
iRules Events .. ...................... 12-4
iRulcs Resources .. ............................................. 12-5
Lab 12.1 - iRules Lab .................................................................................................................................. 12-6
Administering BIG-IP v11 v

vi Administering BIG-IP v11 : Table of Contents
vi Administering BIG-IP v11

Chapter 1 - Setting Up the BIG-IP System 1-1
Chapter 1: Setting Up the BIG-IP System

Chapter Objectives
A fier completi ng thi s chapter, you will be able to :

• Access the BIG-LP system to configure the management interface
• Activate the BIG-IP system for operation, including licensing and provisioning
• Use the Setup utility to create the classroom lab environment network configuration
• Back up the BIG-IP system configuration for safe-keeping
Introducing the BIG-IP System
Lesson Objectives
At the end of this lesson, you should be able to:

• Articulate the difference between a packet-based design and lilli-proxy architecture
• Identify the major elements that comprise the BIG-LP system
• Articulate the difference between application traffic and administrative traffic
• Identify the tools that are used to administer the BlG-IP system and describe how to access them
Packet-based vs. Full Proxy Architecture
Packet-based design
A network device with a packet-based (or packet-by-packet) design is located in the middle of
communication streams, but is not an endpoint for those communications; it just passes traffic through, as
shown in Figure I.
Between client... ... and server
D +-------
Connection
D
o
-o
Figuro 1: Packet-based design
Administering BIG-IP v11 1-1

1-2 Chapter 1 - Setting Up the BIG-IP System
A packed-based device does often have some knowledge of the protocols that flow through it, but it is far
from being a real protocol endpoint. The speed of these devices is primarily based on not having to
understand the entire protocol stack, hence reducing the amount of work needed to handle traffic.
The full proxy platform
A full proxy is the opposite of a packet-by-packet design. Instead of having a minimal understanding of
the communications streaming through the device, a full proxy completely understands the protocols, and
is itself and endpoint and an originator for the protocols.
A full proxy maintains two separate connections - one on the client-side, one on the server-side, as shown
in Figure 2. A full proxy device such as the BIG-IP effectively creates a gap between the two
connections, allowing the contents of traffic exchanged over the connections to be viewed and modified
to address a wide range of security, performance, and availability issues that are unique to each "side" of
the proxy. For example, clients often experience higher latency because of lower bandwidth connections,
while servers are generally low latency because they're connected via a high-speed LAN. The
optimization and acceleration techniques used on the client side are often very different from those used
on the server side because the issues that give rise to performance and availability challenges are vastly
different. Or perhaps we'd like to use the BIG-IP system to offload some of resource intensive functions
that are normally handled by the application servers such as SSL encryption or data compression. Or
suppose we just want to be able to connect a legacy lPv4 network to an lPv6 network.
llH Ittfl :
TCP View and modify TCP

C'ient.j~~~i.~. traffic behavior •
D.· · ...... A ....... JJ.;::==~....
Server
'-' Modified
Application data application data
-D ••
O •
Encrypted
I" .. "."' ....".'" .'" III"' • • --------tI
Unencrypted
-0 ......--------......·..............
---~••·.
Compressed ncompressed
-D ......--------•• ... ·
IPv6 IPv4
- ~··,~· II,~
Figure 2: TIre BIG-IP system is based on a full p roxy architecture

••••• , ..-------~
Because the BIG-IP full proxy is an actual protocol endpoint, it fully implements the protocols as both a
client and a server. (A packet-based design does not.) This also means the BIG-lP system can have its
1-2 Administering BIG-IP v11

Chapter 1 - Setting Up the BIG-I P System 1-3
own TCP connection behavior, such as buffering, retransmits, and TCP options. A client connecting to
the BIG-IP system would likely have different connection behavior than the BIG-IP system might use for
communicating with the back end servers. Therefore, the BIG-IP system allows for the optimization of
every connection uniquely, regardless of the original source or the final destination.
Deny-by-Default
Some network devices pennit all traffic to pass through by default, and then are configured to restrict
undesirable traffic. In contrast, remember that the BIG-IP system is a "default deny" system. In other
words, when you insert a new BIG-IP system into your network, all traffic is denied to start with. This
method provides much tighter security because you must then specifically configure the objects that will
open up the system to traffic processing.
Throughout the remainder of this class, we'll examine what these objects are and how they can be
configured to exploit BIG-iP's lull proxy capabilities.
What's Inside the BIG-IP System?
The internal architecture of the BIG-lP system is separated into two major lunctional areas - one that is
responsible for traffic management and the other that is responsible for operational management, as
illustrated in Figure 3.
BIG-IP' :
TMOS'!i); Traffic Management Administration
GUI
iRules TMSH
Ful Proxy
SSL Compression
eLI
........
-.
Figure 3: What's inside th e BIG-IP system?

1-4 Chapter 1 - Setting Up the BIG-I P System
Traffic Management
At run-time, when traffic flows through BIG-lP, it all goes through TMOS, a purpose-built operating
system designed and built by F5 specifically to support intelligent application delivery services. This
"side" ofBIG-IP handles traffic management functions, including but not limited to:
Access control (APM) Carrier-grade NAT (CGNAT)
Application security (ASM) Encrypt and decrypt (SSL)
Network firewall (AFM) Compression
Application acceleration (AAM) Caching
Load balancing (LTM) iRules
DNS services (GTM) iControl
ISP connection management (Link Controller)
Operational Management
Operational management resides on its own "side" of BIG-IP using off-the-shelf components and
software that start with a Linux core. In essence, it's a box within a box. This "side" ofBIG-lP has
nothing to do with the actual flow of traffic through BIG-IP aside from configuration. Instead, it provides
administrative functionality through the Linux shell (bash), TMOS Shell (TMSH) and the graphical
user interface (GUI).
What's on the Outside of a BIG-IP?
Figure 4: BIG-IP platform fronl panel
Although the physical layout of each BIG-IP platfonn is a bit different, they all typically share some
common features, as shown in Figure 4. These features include:
1 Management interface 5 Indicator LEDs
2 USB ports 6 LCD panel
3 Console port 7 LCD control buttons
4 Failover port (~/r r'N!'11 rill I 8 TMM switch interfaces
LCD panel and LED indicators ~()rf," ;I,;s,{ q'),vrt/ft( hr{ '
Using the LCD panel and its associated control buttons, you can manage the BIG-IP hardware unit
without attaching a console or network cable. For example, you can use the LCD to configure the
management port, reboot the BIG-IP system, power the unit on or off, or clear alarms.

Figure 5 LCD panel on a BIG-IP 7000 series application delivery controller
The status LED indicates the operating state of the system:

Orono light indicates the system is halted and powered down.
Green solid indicates the system is running in normal mode. It also indicates that the system is
Active for at least one traffic group in a high availability configuration.
Yellow light indicates the system is running impaired. It can also indicate that the system not
active for any traffic group in a high availabil ity configuration.
Yellow blinking indicates the system is not under host computer control (softwarelhardware
problem, EUD, etc.).
The alarm LED indicates system alarm conditions and the severity of the alarm:
Orono light indicates no alarm conditions are present, and the system is operating properly.
Rcd solid indicates an emergency. The system is not operating, and the condition is potentially
damaging.
Yellow solid indicates an error. The system is not operating properly, but the condition is not
severe or potentially damaging.
The power supply LEOs indicate the operating state of the power supplies:
Green solid indicates the referenced power supply is present and operating properly. It also
indicates when tbe system is in power standby mode.
Yellow solid indicates the referenced power supply is present but not operating properly
Offlno light indicates no power supply present
The LED indicators can also be set as tbe result of user-defined alerts, as contained in the user_alert.coof
file on the B1G-IP system. SNMP alerts and traps are discussed later in this course.
Administering BIG-I P v11 1-5

1-6 Chapter 1 - Setting Up the BIG-I P System
Network connection entry points and traffic types
The BIG-IF system uses two network connection entry points: the TMM switch interfaces and the
management interface (MGMT).
The Traffic Management Microkemel (TMM) controls all of the TMM switch interfaces, and the
underlying Linux operating system controls the BIG-IP management interface.
The BIG-IP system processes two types of traffic: Application traffic and administrative traffic. The
management interface processes administrative traffic only. The TMM interfaces can process both
application traffic and administrative traffic. These topics are discussed in more detail throughout the
course, as are some of the other aspects of the BIG-IP platform hardware previously shown.
Establishing a connection to BIG-IP
Before you can activate, configure, or manage a BIG-IP system, you typically connect BIG-IP to a
management workstation or management network so as to easily perform administrative functions. There
are several ways to gain initial access to the BIG-IP system and configure the management interface
including but not limited to:
• Using the serial console
• Using the LCD panel and control buttons
• Using the management interface at its default IP address
Note: The BIG-IP setup process is covered in detail in the next lesson.
Configuring and Administering BIG-IP
The BIG-IP system offers both graphical user interface (GUI) and command line interface (CLI) tools to
configure and administer BIG-IP, so that you can work in the environment where you are most
comfortable given the tasks at hand. Once you have completed the initial configuration ofBIG-IP, you
can continue with more detailed configuration and administration tasks using either CLI tools such as the
Traffic Management Shell or tmsh (see Figure 6), or GUI tools such as the Configuration utility, or a
combination of the two.
Note: Some functions can only be performed with the CLI; others can only be performed (or are
more easily performed) with the GUI. Most functions can be performed using either tool.
Using command line utilities
You can use the command line interface (a.k.a. CLI) to manage the BIG-IP system and its configuration
objects. You can also use the CLI to monitor network traffic, current connections, and the operating
system itself, to completely shut down the BIG-IP system, or to manage some BIG-IP settings that are not
available through the GUI.
Depending on your terminal access and user role settings, you can manage the BIG-IP system using
command line functions such as the Linux shell (bash), the config utility, and/or the Traffic Management
Shell (tmsh). You can use command line tools directly on the BIG-IP system console, or, given
appropriate configuration settings, you can connect to the management interface using an SSH client such
PuTTY, Tera Term, or SecureCRT, and run commands.

Accessing the command line through the serial console
All BIG-IP platforms have serial console access through the port labeled CONSOLE on BIG-IP . The
default setting is N-8- 1 at 19,200bps. Prior to initial setup, only the root user has access. After initial
setup, the root user still has access and the default administrator user account (admin) has no command
li ne access by dcfault. Tbis can be chan ged using the CLI or the GUt
Accessing the command line through SSH
BIG-LP ships with an SSH server that provides authorized users with secure login connections and file
transfer over the network. The server uses cryptographic authentication, automatic session encryption,
and integrity protection for all transferred data.
To access the CLI, open an SSH sess ion to the BlG-lP system using PuTTY Or other SSH-enabled utility.
On initial serup, this address is the management IP address; after setup, you may also be able to SSH to
one of the BIG-IP system's selflP addresses, assuming you bave permitted such access via the Port
Lockdown setting. (We' ll discuss Port Lockdown in more detail later in this course.)
As part of initia l setup, a BIG-IP administrator can choose wbether or not to enable SSH access for one or
more lP add resses. By default, the root user has access to the CLI (via console or SSH) and tbe admin
user only has access to tbe GUl (but can be given access to the CLI, if you wish). Other user roles,
besides administrators, can also be given access to the CLI. As mentioned before, the root user bas no
access to the GUl and this cannot be changed.
Accessing the Configuration utility (GUI)
You can use the Configuration utility (a.k.a. GUl) to manage the BIG-IP system and its configu ration
objects. You can also use tbe Configuration utility to monitor network traffic, ClUTent connections, and the
operating system itself.
To access the Configuration utility:
l. Open a web browser session to https, / / . On initial setup this
add ress is the managementlP address configured during setup, or after setup, a self IP add ress
that pennits port 443 access via its Port Lockdown setting.
2. When you connect to the Configuration utility, you r browser may alert you that the SSL
connection is using a secure certificate that is not recognized by a certi fi cate signing authority.
This is normal behavior as B1G-IP creates a self-signed certificate during installation. Accept the
cert ifi cate .
3. Enter an appropriate usemame and password such as the default administrative user (admiD).
Tbis will open the Configuration utility's Welcome page. (This page is also accessible at any time
by cl icking the F5 logo in the upper left comer of any Configuration utility page.)
The modules that appear in the Navigation pane vary depending on your license.
Note : The root user has no access 10 the GUI, and this cannot be changed.

Configuration utility advantages
There are distinct advantages to using the Configuration utility (GUI) versus TMOS shell (trnsh) to
perfonu configuration tasks:
• The learning curve is smaller because it is easier to use and more intuitive.
• It minimizes the chances of configuration errors. Input is checked and errors are reported
immediately.
• Changes are recorded immediately in BlG-lP's configuration files and effective immediately on
the system. No restarting of BIG-IP processes or manual reloading of configuration files is
required, except in the case of provisioning.
• It is easier to access. More people have browsers installed on their workstations than SSH clients.
For products such as Access Policy Manager (APM), Application Security Manager (ASM), and
Enterprise Manager (EM), almost all tasks are perfonued using the GUI over the CLl.

Always-On Management (AOM)
The Always-On Management (AOM) is a separate subsystem on some BIG-IP platforms (not YEs) that
provides lights-out management for the BIG-IP system using the lOll DOll 000 Ethernet management port
over SSH, or using the serial console. Since it operates independently from the BIG-IP host subsystem,
AOM allows you to manage aspects of the BIG-IP platform, even if the host subsystem is locked up or
turned off. If the AOM is reset or fails, the BlG-IP host subsystem continues operation, and there is no
interruption to application traffic.
The AOM provides the ability to power onloffand restart the BIG-IP host subsystem. The AOM is
powered on when power is supplied to the BIG-IP platform; it cannot be turned off.
Access the AOM Command Menu using the serial console
To access the AOM Command Menu using the serial console, connect the serial console to the BIG-1P's
CONSOLE port (as described earlier), tbcn type the following key sequence: <Esc> then ( within 3
seconds. (On US keyboards, ( is the same as <Shift+9>.)
The AOM Command Menu opens as displayed below:
AOM Command Menu
1 Connect to Host subsystem console

2 Reboot Host subsystem (sends reboot command)
3 Reset Host subsystem (issues hardware reset--USE WITH CARE!)
4 Reset AOM subsystem (issues hardware reset--D8E WITH CARE!)
5 Power off Host subsystem (issues hardware shutdown--USE WITH CARE!)
B AOM baud rate configura tor
L AOM subsystem login
N AOM network configurator
P AOM platform information
Note: If the BIG-IP Host subsystem is powered off, option 5 changes to Power on Host
subsystem.
AcceSSing the AOM Command Menu using SSH
Before you can directly access the AOM over the network using an SSH client such as PuTTY or
TeraTerm, you must configure an IP address for AOM by running the N -- AOM network configurator
command from the command menu, as sbown above. The AOM IP address must be different than the
BIG-IP management address, but must be on the same IP subnet.
Once the AOM has been configured with an IP address, you can open an SSH client on a workstation
connected to the management port on the BIG-IP system and type the following commands:
ash root@<AOM_ip_address>
hostconsh
Esc then (
(On US keyboards, ( is the same as <Shift+9>.)
Note: For complete steps to configure the AOM, please see SOL9608: Configuring the AOM so
it can be accessed over the network.

Initially Setting Up the BIG-IP System
Lesson Objectives
After completing this lesson, you will be able to:

• Access the BIG-LP system and configure the management interface using the command line
• Use the Setup utility to activate the BIG-iP system for operation including licensing,
provisioning, installing a device certificate, and configuring platform general properties and user
admi ni stration
• Use the Setup utility to configure the network objects used in support of tbe classroom lab
environment
• Access the Welcome page and the Setup utility from anywhere within the Configura tion utility
• Create a UCS backup of the BIG-LP configuration and download it for safekeeping
Initial BIG-IP Setup
There arc several steps that are performed to initially set up a BIG-IP device, and get it ready to configure
for processing application traffic. These steps are summarized in Figure 7.
Access Activate Configure
Figure 6: Summary of the BtG-IP setup process
J. Configure the management interface for administrative access

2. License tlle BIG-IP system
3. Provision the desired BIG-IP product modules (e.g. LTM, APM, ASM, etc.)
4. Install an appropriate device certificate
5. Configure platform general properties and user administration
6. Con.figure network elements including VLANs, self iPs, and, optionally, high avaitability

1. C onfiguring the Management Interface
Accessing the BIG-IP system
One of the first steps in setting up a BIG- IP system is to configure the management interface (MGMT).
The management interface is used by the BIG-IP system to perfonn system management function s, and is
intended for administrative traffie only. It cannot be used for load-balanced traffic. As there are no access
controls available on the management interface (except for limiting SSH access), F5 recommends that
you limit network access throug h this interface to trus ted traffic. For security reasons, the management
internce s hould on ly be connected to a secure, management-only network, suc h as one that uses an
RFCI918 private IP address space. If you do not ha ve a trusted and secure management network, F5
recommends that you do not use the management internee, and that you grant administrative access
through the TMM s witch interfaces or the local seria l console.
There are several ways you can initially access the BIG-IP system to configure the management interface:
• Using a serial console - If you're installing a BIG-IP appliance, you can use a null modem cable
or RJ45 console cable (depending on platfonn model) to connect a management sys tem that is
running a terminal emulator program to the BIG-JP console port. If you're installing a BIG-JP VE
sys tem, you can use the Console display on your VE management software (such as VMware
VSphere).
• Use the LCD panel and associated control buttons - This method applies only if you have
physical access to a BIG-IP appliance or VJPRlON device. There is no equivalent on BIG-IP VE.
• Using tbe default management interface - You can reconfigure the management interface by
connecting to the Ethemet interface labeled Management (MGMT) to remotely access the
command line or the GUI.
F5 ships BIG-IP, VIPRlON, and Enterprise Manager systems with default values pre-configured for
several platfonn properties, including default management port JP address and netmask, and default
credentials for accessing the system. These settings are summarized in the tables that follow.
Default IP Addresses
Product Management Port IP Add ress I Netma::.s::.k~_..;D;,;e;;,::.u

fa ::.::.
lt .:.;,;;,:;;,::...>,=
Route ( Gatew ay"..)_ _ _~
:..:;;,:..:::.
BIG-IP 192.168.1.245/24 None
VIPRION 192.168.1.246/24 None
Default Administrative Accounts
Login Type Username Password

BIG-IP Configuration utility admin admin
BIG-IP command line root default
If these settings are not appropriate for your network or security needs, they can and s hould be changed .
We will explo re how to change these values in the remainder of thi s c hapter.

Setting the Management IP Address
There are several tools you can use to sct the management lP address to something other than the F5
default:
• From the command line via the conlig command
• From the command line via tmsh commands or a tmsh script
• From the BlG-lP hardware device front panel LCD controls
• From the GUl via the Configuration utility or the Setup utility (after initial deployment)
Configuring the Management IP address via the config command
Establish a connection to BlG-lP using the serial console or an SSH session to the default management lP
address (192.168.1.245 for BlG-lP; 192.168.1.246 for VlPRlON), and log in as the root user with the
password of default. Enter config at the Linux bash prompt (e.g. config # config). You will be asked to
enter a management lP address, netmask, optional default route, and then confirm your choices. (See the
Configure Management IP Address lab later in this chapter for step-by-step instructions.)
Note: If you are connected to the B IG-IP system via the management IP address and you
change this address, you will lose your connection. You must then establish a new connection
to the changed management IP address to continue with any other configuration activities.
Configuring the Management IP address via tmsh
Establish a connection to BlG-lP using the serial console (not the management lP address), and log in as
the root user with the password of default. Enter tmsh at the Linux bash prompt. To change the
management lP address, enter:
tmsh create Isys management-ip <address/netmask>
... replacing <address/netmask> with the appropriate management lP address and network mask
combination.
Note: A BIG-IP system can only have one management IP address assigned to it. The create
command changes the existing management-ip address to the new address/netmask specified.
We recommend that you do not delete the management IP address using tmsh.
Configuring the Management IP address via the LCD panel
You can also configure the management lP address via the LCD panel on BlG-lP. Access the system
menu by pressing the red X button, then set the IP address, netmask, and, optionally, the default route.
Click Commit to save your settings. (See the Configure Management IP Address lab later in this chapter
for step-by-step instructions.)

2. Activating the Software License
After configuring the management interface, you can access thc GUI through the management interface,
and use the Setup utility to begin activating your BIG-lP system for operation. (Note: You could use the
command line instead to perform these tasks but it is generally considered more complicated than using
the GUl.) This next phase begins with a step to activate the license for your BlG-IP system software. The
licensing process consists of five basic steps, as illustrated in Figure 8.
F5 License Server
~:::--- ___-:I~. . ._.. . . . .__!a~ct=ivate . F5. com
Admin
o
(pre-populated on the BIG·IP s}lslem)
o
Figure 7. Overview of tho BIG·IP licensing procoss
I. Find the Base Registration Key (Note: A registration key is already pre-populated on F5-shipped
BIG-lP hardware devices.)
2. Generate the dossier on the BIG-lP system. The dossier includes the registration key.
3. Send the dossier to the F5 license server at activate.fS.com
4. Generate the license and send back to the BIG-IP system
5. Install the license on the BIG-JP system, finishing the licensing process
License activation methods
Two activation methods are available:

• Automatic licensing can be used when the BIG-lP system has Internet access, and can
communicate directly with the F5 License Server. (You can temporarily configure such access for
automatic activation; it is not necessary for the BIG-IP system to have permanent Internet
access.) BIG-IP au tomatically generates a dossier, transmits it to the F5 License Server at
bttps:llactivate.fS.com , downloads the generated license from tbe license server its configuration
folder (config/bigip.license), and activates it.
• Manualliccnsing is requi red if the BIG-IP system does not have Internet access, or if you ' d like
to download either the registration key, dossier, and/or license for external storage and
safekeeping.

What's needed to license?
To activate a license for BIG-lP, you will need the folJowing:

• Base registration key
The base registration key is a 27-<:haracter string that lets tbe F5 License Server know which F5
products you are entitled to license. The base registration key is premstalled on all F5 factory
purchased BIG-lP systems and will automatically populate into the Configuration/Setup utility
wben you carry out the licensing steps. (In this class, you may need to locate and manually enter a
Base Registration Key.) The base registration key is in the format:
AAAAA-BBBBB-CCCCC-OOOOO-EEEEEEE
• Dossier
A dossie r is au tomati ca lly generated by BIG-lP during the licensing process. It contains
encrypted information that identifIes your platform to the F5 License Server. Multiple system
settings are stored in the dossier, including the base registration key.
• Access to the Internet to connect to the FS License Server
As mentioned previously, if the BIG-IP system is on a network with Internet access, you can have
the BIG-IP system carry out the licensing steps automatically. If the BIG-IP system is not
connected to tbe Internet, you must manually carry out the licens ing steps.
Note: For complete, up-to-date licensing instructions and troubleshooting tips, please refer to
S0L7752: OveNiew of licensing the BIG-IP system available at AskF5.com. You will be
manually licensing your BIG-IP system during class, and will have an opportunity to walk
through the licensing steps in detail there.

3. Provisioning Modules and Resources

..... . :::::
:::::
:::::
:::::

The license you receive from F5 Networks detennines what software modules the BIG-IP system will
support. The process of allocating CPU, memory, and disk space to licensed software modules is called
provisioning and gives the application administrator some control over the way BIG-lP apportions these
resonrces to each module. For example, if you're deploying LTM and ASM to serve mostly as your
application firewall (as opposed to load balancing traffic), you may want to allocate more resources to
ASM than to LTM.
Note: Provisioning is not performed on Enterprise Manager as it runs in a standalone

environment, either on its own hardware appliance or as aVE.
Provisioning is an operational management feature that is integral to the initial installation and setup of
BIG-IP. Provisioning gives the nctwork administrator limited control over the resources - CPU and RAM
- that are allocated to each licensed module. For example, on a BIG-IP that is licensed for both LTM and
GTM, you might want to minimize the resources allocated to GTM to give more resources to LTM as it's
usually the bigger work borse.
With the exception of Enterprise Manager, all modules have some reliance on management (Linux),
Traffic Manager Microkemel (TMM), and the user interface (UI), so these elements are always
provisioned. Other modules must be manually provisioned.
Provisioning the Management (MGMT) module
Options for provisioning the Management special module include Small, Medium, and Large. Use
Large for configurations containing more than 2,000 objects, or more specifically, for any configuration
that exceeds 1,000 objects per 2GB of installed memory.
License status
The resource provisioning screen on the GUI shows all modules available on the BIG-lP system and an
indication of whether the module is licensed or unlicensed in the License Status column. Although you
can provision and configure some unlicensed modules, the unlicensed module functionality is not
generally active or is active only on a limited basis.

Provisioning levels
To provision a licensed module, click the checkbox next to the None option in the Provisioning column,
then select one of the available pre-defined resource levels, as shown in Figure 9:
• The Dedicated setting specifies that this is the only active module. If you select Dedicated for
one module, the system resets other modules to the None setting. The Dedicated provisioning
setting is primarily applicable for Application Security Manager (ASM) and other such modules
installed in standalone configurations (when no other modules are installed, including Local
Traffic Manager).
• Nominal gives the module its minimum functional resources and distributes additional resources
to the module only if they are available after all other provisioned modules are enabled. It
allocates CPU, memory, and disk space in a way that is applicable for most typical
configurations.
• The Minimum setting allocates the least amount of resources required for the module to be
enabled. No additional resources are ever allocated to the module during operation.
Note: For more information on how TMM uses CPU and RAM during processing, refer to
S0L3242: Overview of BIG-IP Traffic Management Microkemel (TMM) CPU and RAM usage.
t WA ,
,""
Ism-all
• M~ (MGMTl
CBmI!r Grad~ NAT (CG.'i.liT) • ,
I _ ~~t'l r:III'W./'JII(AFM) [J Nao p
" ".
.. .
X150
• "'fIpkatl~,i.etl:lI:, ut!n rl M a~ (MM)
"'
" ~'" 12
"""'" " 448
• I:ltJbaI TtgTjc (GTM)

o None . l.X1 hem~ , ".
• UIt CarIToller lLC )
• ~ l lr.en:;!(1 0
".
"""' 0
Ij:J lftn9!(j
• PoNe)' ErlfDfCillmenl (PEM ) "
• P'l'DloooI S!1:urty ( <4 ) "'""'"" 12
Figure 8. Sample Resource Provisioning pa ge In the Configuration utility showing L TM and ASM provisioned

Once you have made and saved your provisioning selections, traffic processing may be briefly interrupted
while BIG -IP reloads the configuration.
Note: The BIG-IP Product Matrix is a PDF file that lists the various product modules/features
and the platforms that support those modules/features. It can be found in SOL 10288: BIG-IP
software and platform support matrix.
SOL9476: The F5 hardware/software compatibility matrix lists the product software versions
supported by F5 hardware platforms.
4. Importing a Device Certificate
In some cases, BIG-IP systems need 10 exchange SSL certificates and keys in order to verify each othe r's
c redentials before exchanging data . For example, multiple BIG-tP systems might need 10 verify
credentials before commun icating with each other over a wide area network to collect performance data
for globa l traffic management.
To perform mutual authen tication, BtG-IP systems can use either self-signed certificates or CA-signed
certificates.
• Self-signed certificates - When you install BIG-JP software, the ap pli cation in cludes a self
signed SS L certi fi ca te (i.e. created and authenticated by the system on which it resides).
• CA-signed certificates - If your network includes one or more certificate authority (CA) servers,
you can replace the self-signed certificate on each BIG-IP system with a CA-signed certificate
(i.e. a certificate that is signed by a third party). Authenticating BIG-JP systems using CA-signed
certificates is mo re secure than using self-signed certificates.
After licensing and provisioning is complete, the Setup utility includes an optio nal step to allow the
administrator to import a CA-signed certi fi cate onto the BIG-IP system, replac ing the se lf-signed
certificate that was included by default. Import types include certificatelkey source pairs or PKCSl2 files.
Note: In this course, you will be using the self-signed certificate unless otherwise instructed. For
more information on managing SSL certificates for BIG-IP devices, please refer to the chapter
entitled SSL Certificates for BIG-IP Devices in the BIG-IP TMOS: Concepts manual available at
AskF5.com.
Activation Complete
Once you have completed licensing, provisioning, and installing a device certi fic ate, your BIG-IP system
is almost ready to operate . Of course, as a default deny device, the BIG-JP sys tem won't do much of
anything until you specifically tell it who it is, where to listen for traffic, and what to do with that traffic
when it hears it. This is the time to begin configuring your BIG-IP platform to operate in your application
delivery network environment. What this configuration looks like will certainly vary from one shop to
another, and frequ ently from one BIG-IP system to another, depending on the applications that are
delivered.

5. Specifying BIG-IP Platform Properties

After licensing and provisioning, tbe Setup utility provides options for quickly defining (or changing)
certain BIG-IP platform properties, including General Properties and User Administration Properties.
• Management lP address, netmask, and/or IP address of the default route
• Host name, bost IP address, and time zone
• Passwords for both the default command line interface user (root), also known as the system
maintenance account, and the default Configuration utility administrative user (admin).
• lP address (or range of addresses) allowed for SSH access to BIG-IP
You can also configure platform properties in the Configuration utility by navigating to System »
Platform.
Management port configuration
You have already learned how to configure the management port on the BIG-IP device using the conf ig
command from the command line. The management port can also be configured from within the Setup
utility, or from the System » Platform area of the Configuration utility, as shown in Figure 1O.
The management port can be configured manually or automatically (via DHCP).
Note: Effective in version 11.3, configuration of the management port is set to Manual by default
on BIG-IP hardware devices, and to Automatic by default on virtual editions.
General Properties
Managem ent Port Configuration o Automatic (DHCP) ® Manual
IP Address[lprefixj 1 192.168 4 ,31
Management Port
Network Mask I 255.255.0.0
Management Route I
Host Name I bigip4.f5trn.com

Host IP Address IUse Management Port IP Address I'"
Time Zone
I
IAmericaILos Angeles "
Figure 9: Con(;guring the BIG-IP system's platform general properties
When Manual configuration is enabled, you manually configure the management port by assigning an LP
address and netmask to the port, as shown in Figure 10. The IP address that you assign to the
management port must be on a different network than the selflP addresses that you assign to VLANs ,
(VLANs are discussed in more detail in the next lesson.) You can also specify an IP address for the BIG
IP system to use as a default route to tbe management port.
Nole: BIG-IP supports either an IPv4 or an IPv6 address for Ihe management port,

When Automatic (DHCP) configuration is enabled, DHCP uses UDP ports 67 and 68. On first boot, the
BIG-lP system contacts your DHCP server and obtains a lease for an IP address and default route for the
management port, and DNS and NTP servers.
The DHCP leasc renews automatically at the configured interval.
Note: If you do not have a DHCP server on your network, and DHCP configuration is enabled,
the BIG-IP system assigns a default IP address of 192.168.1.245 to the management port of
BIG-IP hardware devices and virtual editions, and 192.186.1.246 to the management port of
VIPRION systems.
Host name
Every BIG-IP system must have a host name that is a fully qualified domain name. In your classroom
BIG-IP lab environment, your B1G-IP will have the host name bigipX.fStrn.com (where "X" is your
workstation number).
Host name is used to identify BIG-lP systems during device group configuration and administration. and
also to match UCS files with the B1G-IP system on which they were originally created . (UCS files are
covered in detail later in this course.)
Host IP address
Every BIG-IP system has a host IP address. The default is to use the same address as the manage ment
port (Use Management Port IP Address) .
Time zone
Use the Time Zone pull-down to specify the time zone region that most closety represents the location of
the BIG-IP system you are configuring. Atthough it is important to configure this setting, it is marc
important to ensure that the system time is correctly set to start with.
The BIG -lP system uses two clocks to track time:
• The hardware clock tracks time even when thc system is unplugged, and is used to initialize the
operating system clock when the system is booted .
• The operating system clock is a software clock that is available when the system is running. This
clock stores time according to the local time zone that yo u configured when you initially set up
tbe system .
Once the date and time bave been set to a rougbly accurate va lue, F5 recommends that you set up the
BIG-lP sys tem to keep its clock synchronized with an NTP server. NTP servers can be added to the BIG
IP system later using either the Configuration utility or the command line. Tbe hardware clock can be
initially set using the command line.
Note: For more information on configuring the BIG-IP system to use an NTP server, see
SOL 13380: Configuring the BIG-IP system to use an NTP server from the command line or
SOL3122: Using the BIG-IP Configuration utility to add an NTP server

User administration properties
BIG-IP platfonn properties also include the credentials for the default administrative accounts, and the lP
addresses that will be allowed to access the BIG-IP management through SSH, as shown in Figure J 1.
User Administration
Password: ! ••••••••••
Root Account I
;i
Confirm:
I •••••••••• I
Password: ! ••••••••••
Admin Account I
Confirm: ••••••••••
I !
SSH Access o Enabled
ISSH IP Allow I* All Addresses "
Figure 10: Configuring root and admin user credentia's, and enabling SSH access to the management interface for afl
IP addresses
Administrative account passwords
The BIG-lP system ships with two default administrative accounts, root and admiD. The root account
has full command line access but no GUI access to the BIG-IP system. By default, the admiD account has
GUI access to all functions on the BIG-lP system, but no command line access. (This can be changed
later 00.)
Duriog initial BIG-IP deployment using the Setup utility, you are prompted to enter and continn new
passwords for both the root and admiD accounts. In doing so, you will be logged out and then asked to
log back iota the BIG-IP system. Upon logging back in, you should be returned to the next Setup utility
page.
You can also use System » Platform (io the GUI) to cbange tbe default passwords for tbe root and
ad miD accounts after initial deployment, and are encouraged to do so on a regular basis to comply with
password policies, standards such as PCI compliance, or otber security policies appropriate to your
organization.
Note: You are not required to have any user accounts other than the root and admin accounts,
and the root account is not present if the BIG-IP device is running in appliance mode. F5
recommends that you create other user accounts as a way to intelligently control administrative
access to system resources . (User administration is covered later in this course.) F5 also
recommends that you change all user passwords on a regular basis for security purposes.

If you lose or forget the root account password, you can reset it without reinstalling the system
software. See S0L13121: Changing system maintenance account passwords (11.x)
Controlling SSH access
Administrative access to the BIG-lP system through the management port using an SSH client cao be
controlled through the SSH Access and SSH IP Allow.
When disabled, no SSH access to the BIG-lP system 's management interface is pennitted.
When eoabled, SSH access can be granted to all IP addresses (* All Addresses in the SSH IP Allow pull
down) or limited to selected IP addresses (Specify Range in the SSH lP Allow pull-down).
Note: You can also restrict access to the Configuration utility (GUll by source IP address. See
SOL 13309.· Restricting access to the Configuration utility by source IP address for more
information.

6. Configuring the Network

After configuring your BIG-lP platform's General and User Administration Properties, you will almost
certainly go on to define the network configuration objects that allow the BlG-lP system to integrate into
your application delivery network, including defining virtual LANs (VLANs) and self IP addresses.
Optionally, you may also want to set up the BIG-IP system to participate in a high availabi lity
configuration, called a device service cluster in F5 terminology. This includes defining settings for
ConfigSync operations, failover, and mirroring, and perhaps even configuring a redundant pair ofBIG-lP
devices.
The BIG-lP system offers several options for configuring these settings:
• Using the Standard Network Configuration wizard (part of the Setup utility)
• "Do-it-yourself' using normal Configuration utility functions (referred to as Advanced Network
Configuration in the Setup utility)
• Using an iApp that automatically deploys the desired network configuration objects and perhaps
even application s pecific configuration objects sucb as virtual servers, peols, a nd profiles
• Running a tmsh script that creates the desired configuration objects
• Using your own iControl user interface
• Using a combi nation of the above
Note: In this class, we will be using the Setup utility to create the BIG-IP configuration objects
that support the classroom network environment.
Standard Network Configuration
The Standard Network Configuration screens in the Setup utility can be used to:
• Configure basic network components including the TMM switch interfaces, VLANs and self
IPs .
• Configure a standard Active/Standby pair including senings for ConfigSync, failover, and
mirroring, as well as peer discovery.
The TMM switch interfaces on the BIG-IP system are the physical ports that con.nect the BIG-lP system
to other devices on the network, such as routers, bubs, switches, destination servers, etc, and process
application traffic. Through its interfaces, the BIG-IP system can forward traffic to or from other
networks . The exact number of interfaces depends on thc platform type.
A virtual LAN or VLAN is a way of logically partitioning a physical network so that distinct broadcast
domains are created. Hosts can be grouped by a common set of requirements regardless of their physical
location.
A self lP address is an IP address/netmask combination on the BIG-I? system that you associate with a
VLAN to allow the BIG-IP system to access hosts in that V LAN. By virtue of its netmask, a self lP
address represents an address space - that is a range of IP addresses spanning the hosts in a VLAN, rather
than a single host address. You associate one or more self LP addresses with a VLAN to create a distinct
broadcast domain - a logical su bset ofa physical network that is independent of the physical network
topology.
Note: We will cover VLANs and self IPs in more detail throughout the remainder of this course.
1-22 Adminislering BIG-IP v11

Ready for Application Traffic Configuration
Once you have completed configuring your BIG-IP system for administrative access, and to participate in
your network environment, you're ready to configure it to listen for and process application traffic. The
Welcome page is the default landing page when signing into a licensed and provisioned BIG-IP system.
This can be changed by modifying the Start Screen setup under System» Preferences.
The Welcome page
The Configuration utility's Welcome page contains a variety of useful infonnation, as shown in Figure
12. Use the objects in the Navigation pane to navigate to pages where configuration and administration
tasks can be perfonned. Use the links on the Welcome page to perfonn additional setup tasks, change
your system preferences for the Configuration utility, or link to F5's online support sites such as AskF5
and DevCentral.
You can usually access the Welcome page by clicking on the F5 logo in the upper left comer of each
Configuration utility page. (This can change depending on where you are in the GU! and what your BIG
IP's preferences are set to.) The contents of the Welcome page are also shown in the About tab.
Ullr Documentation Ask Fe:

Tl'Cml ca; dC l'1llMenlllllDll b (hiS plodu cl, mtl.llil'U U!IeI glJJlieol. ~rl<.! Ask F'!iIi:!IiIUfIIl ~ ~tlu I IDn~ 10 Irchnu ~S:IIII"~. pmduc l
r$a-;g n~ II~' ,I ..,jalHlloalhl oI!..;k f60 Toc hnoul~_ b m . n ~ • • Ggl nDt u . . . nnllPl. t..pP O,l IL1:l;Q IJe l1 gt~!O'. a " d
", g en l ril lfrlclrrl~ ..... F'!j Ne tvtM'r1 ~ ~ 15 Ask F5

~d,~ "''''rriI!td
;s(:Ctlls 10 all tvIII.'IoIIo',,,
~, . ,! c',;de , an F!5
'lfi'lllClltgnllfTMtr ~
Pr.fulncu
o,.tl.Sytle nl
~~g
~II
fl)llhll C~,.. Ut ,h'y
AdditionAl Situp Option.

Kleen , you can C<jslo"",,~e
-UN till! i;it~ ~ , "(olig ""~ liQn op ll (lf'oll lQ rtfl'lt I tl~

t}o.l!l s@ n~ l ll
_....
sorl.ltlon C. m.r
Th . StlYlJIIII'I Cuht " ~ I Y''''s ~1.1Ip"'b:r-.lftt DIplD~ GU ' d8~ ,
WhIt.., PIIIH', Appil:'.uD n B!lef~, SLiOCti~ 'SlU'R1, Tut o~ 31~ 3nd
~ , I:~ ~t'lUIi, DfItt' ,.w1'l... lnIIjlil~ t ()()~ gu r~d Ih4I! I~Bl! .....ng
C. vC . ntraJ
1h11 Salu p UII I~T
D ~nlrtl' liIJIIO''1du n«work ii d ,nil'llll~iltO' i a"d . '(, ":'00
~~.'" : ...,.\,~, ~~'fIIIItJ all'lBn_ l ools, t'P! , _ _ If.llll, an.:l(.;)mmun,ly
: C'f'llll:1
nlSOlK'H ~gned 10 ,,-pe ed IC II'lD1II ~I =
~ ~I i . a
·
• rdF>
"....
• lh ~I~ !r<oI' .....,
IQ rU Il'II Q'~ ~,~
• V~ iJeoC.rt.'1Il
pr. Cl;( Qii
Si tup Utility Modul• •

?~ 111, S.'u p U11~r:r JIIAIll IIlIlllir.. ~. 10 bsu:: '!II'IICI F51!HG-lP~" g , ~ . 1II(""dg, ~ ~~m tII)'Ol.H OO ad~ n_
1«1"'-'" r-:l sl::or"1o1fC ""iH~ e«t!IlIU' il lmn "'l!Ght'll'lt "l'ItUI*Iiy 10 qu.;clt idll¢C ttl «fttflVP.l: ~~!it~ t t lM l
r..1 bUl inau ~~L MDdLiln incbroJ optiunJ b: K eele r, I'on,
S ~CIln1, <J:l\1 a:i1a -.ppicll1 lOn d R:. - , glJlllblnl
• ,,",101 &!:·IP MDdo.U~
Figure 11.- BIG-IP Welcome page

Accessing the Setup utility after the system is licensed
You can access the Setup utility even after the system is licensed and configured. Navigate to the
Welcome SCreen by clicking on the FS logo from most anywhere within the Configuration utility (or click
the About tab). Scroll down and click on the Run the Setup Utility link.
Note: The ability to rerun the Setup utility in its entirety depends heavily on the other
configuration objects that exist on the system. If those objects deviate from what the Setup utility
would normally generate, the utility will typically stop and/or issue an error message.
Context Sensitive Help
The Configuration utility provides context sensitive help on each

screen, with dcscriptions of each control and setting shown in the
body. Depending on the hardware you have and the settings you
configure, you may see only some of the body area's elements
described in the Help panel. To access a screen's Help content, click General Properties
the Help tab at the top of the navigation pane, as shown in Figure 13. a , - - -- - , - ----,
Activate
Launch button License
CUd< Actlv a" LlCen.. to open
The Launch button launches the Help display in a separate browser
lIIe Uten... gener.. p r ope~ ..
pop-up window which can then be moved around on your monitor lCI'~ en . where you can Su.bmlt
display. Your browser settings must permit pop-up windows in order Uconslns key. 10 edlvalo the
for this function to work properly. s-'PtGim and softwarQ .
Print button
a UCon• • Ty po
a UConoO<J Dot.
Use the Print button to obtain a printable copy of the contextual help 5peclfles the date on whleh the
for the screen. Ileensc was actlva1ed.
Figure 12: Context senSlhve help carr

Expand and Collapse buttons be obta ined by clicking the Help tab
Click the Expand button to expand all the help major topics. After clicking Expand, the Collapse button
will appear. Clicking Collapse collapses all the help major topics. You can also click a specific help topic
heading (e.g. "+ License Type" or "- Licensed Date", as shown in the figure to the right) to expand or
co llapse that particular topic.

Setting Menu Options
You can customize your Configuration utility experience using the options
available [rom the cog pull-down that appears at the left of the menu bar
area on each page. (See Figure 14.)
Show compact menus

Auto- rlose menus
The Show compact menus option controls the way the objects will appear
in the na vigation pane. When turned off, a gray bar will appear at the le ft Delay hiding menu Items
of the Show compac t menus selection in the pull-down, and the objects in
the navigatio n pane will be lo nge r and include both a title and a Add to Favorites
description of the functionality provided (e.g. Local Traffic - Control the
Direct link to page
deli very of application traffic fo r a local area network). When turned on, a
green bar will appea r at the left of the selection in the pull-<iown, and the Print content are a
navigation objects on the far left will contain a title only (e.g. Local
Traffic) .
Figure 13: Click Ihe widget
icon to open selections for
Auto-close menus setting menu options
When Auto-close menus is turned on, any open major configuration object in the navigation pane will
automatically collapse before another object is opened. When Auto-close menu s is turned of[, any major
configuration object you open in the navigation pane will stay open, even when you click ano ther object.
You must manually close an obj ect by clicking on its title.

Creating an Archive of the BIG-IP System
Lesson Objectives

• Use the Configuration utility to create an archive of BIG-lP system configuration data
Note: BIG-IP configuration backup files are covered in more detail later in this course.
Understanding Archives
As you administer the BIG-IP system using any of the available tools, you create configuration data that
consists of system and network definitions, such as VLANs, self IPs, and administrative user accounts, as
well as application traffic elements, such as virtual servers, pools, and profiles. Once you have created
this configuration data, you may wish to save it to use for backing out a change, disaster recovery, or even
as a way to propagate data to other systems.
We will cover B1G-IP arcbives in more detail in the chapter entitled Traffic Management Shell (tmsh) and
Managing the BIG-IP Configuration. In the meantime, it's important that you at least understand how to
create an archive so that you can regularly back up your BIG-IP systems before and after each lab, should
you so desire.
Using the archives feature
BIG-lP configuration data can be backed up to a User Configuration Set (UCS) archive file. By default,
the UCS archive contains all files required to restore your current configuration including system specific
configuration files, product licenses, user accounts and password information, DNS zone files, and
installed SSL keys and certificates.
Creating a new archive using the Configuration utility
To create a new UCS archive, navigate to System » Archives and click on the Create button. Give the
archive a name and click the Finished button to save the archive, as shown in Figure 15. By default, BIG
IP saves the UCS archive file with a .ucs extension and places the file in an archive directory whose path
is Ivarllocal/ucs.
1-26 Administering BIG-I P v11

System» Archives » New A,el1l\1e .
General Properties
File Name train4 _base .ucs!
Encryption iDisabled ¥ .
Private Keys /Include vi

Version IBIG-IP 11.4.0 Build 2384.0
1 Cancel I I Finished I
Figure 14: Creating a UCS arch ive using the Configuration utilIty
For more information on backing up and restoring BIG-IP configuration files and transferring
archives to a secure location, see SOL 13132: Backing up and restoring BIG-IP configuration
files (11 .x) and SOL 175: Transferring files to or from an F5 system

F5 Support Resources and Tools - -- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Lesson Objective:
At the end of this lesson, you will be able to:

• Describe online F5 resources tbat provide help and support services for BIG-IP products
AskF5.com
, ~'I~II' '., ~I ,,1_, It,·." '" ' " \I •
r' II
AskF5 Knowledge Base
Product Manuals and

• Sa;!l rch AskF5
Search the AskF5 Knowledge Base Release Notes
supponed ProdUcts
r ~( iI s.,-.e( II'II:~
End-.of-l.Jf lt PrOClU¢IS
R ~ "1 Addition tQ Search

BIG-IP Edge App. New Releases
About AlkF!
BIG~IP 11.4.0
Additional Search Criteria (optional)
BG-IP L fM VE. ANA ~M, ~II CG
OownlOld l Produd "ALL AI"", ~. E..~ mwl.ft
Oor ~r . PHI oInl FlSU
BIG-IP ,Hulth
Version' I\I.L --;!

WebSupport
Licltn5Jng
Doc: Type; ALL El ARX 8.-4.0
• Fit-e db;!lck
Diagnostics and Firmware
~ ....ung llsts Upgrades
Recent Add itions and Updates I View All
tOO UIi8"~llti ~iI96'flrtN
0612812.013 sot.'.lolIIl Iblr lo IJIIlti@fctf~1UaI{Ilrot-M" 5tJI~~ ~ ft
.tRX ~ .111 8 1IIlIt'laQt!{I n...r AMt.&r-i-On iI1 ~ H) 1 13
061281201:1 tADM.IAI. [I'Ik:f IJMeWil~ "'1I!dJI(llI1lrlT~lIiIdcn~

SCCP.....,......., 1?1I 1!
8K}. I P~1
06127/201::: ;;()L 14.t!t I I hi!, WS~ II:fIQfllI' ~ ~ ttl ~~ ~r,p1.~1
r~n 'IJII..n'" 1CfVef (ef1nrUIt,~ ~ ~~.., lrw IO.Il. ~
Hotfix Infonnalion
0&/271201:1 3.Ol. 1:!6.76 1l1e lil!flf1lC1» I"\a Ilftl8l~enr~~ ((]fJIrotI menJr1o'

aiLLlll/M IQr DIr 8IG-fJ' AAM C&niP [t 1 I
Figure 15." AskF5.com provides a centralized starling point for locating information that relates to BIG-iP system
adminislration Emd supporls
Need access to the latest product updates? Looking for product guides, release notes, solutions to known
issues, and how-to infonnation? AskF5 is a complete, easy-to-use storehouse for thousands of solutions to
help you manage your F5 products mOfe effectively.

Whether you want to search the knowledge base periodically to research an issue, Or you need the most
recent news on you r F5 products, AskF5 is your source for:
• Product manuals and release notes • Hotfix infonnation

• F5 Announcements • Product lifecycle infonnation
• General sol uti ons • BIG -IP Edge Apps for iPhone, iPad, iPod Touch
• Known issues • Procedures for contacting F5 Sup port
• Security advisories • Links to software, hotfix, patch, and other file downloads
• Best practices • Links to licensing tools
• Diagnostic and finnware upgrades • Initiate a customer support case
You can also sign up for regular AskF5 updates, including:
• Weekly Technews e-mail that outlines product and hotfix reicases, updated and new solutions,
and new feature notices
• E-mail alerts fo r security notices
• AskF5's RSS feed that keeps you informed of new product developments for your BIG-IP
versions
BIG-IP Version Support
The F5 hardware/software compatibility matrix is your best source for information abo ut product ve rsions
and the latest scep, AOM, and EUD ve rsions supported by F5 hard ware platforms. This table shows
each F5 platform and chassis marketing name (e.g. BIG-IP 4200s, BIG-IP 10200v, VIPRJON
4800/S 100), the platform type, the BIG-LP software versions supported by the platform, the latest version
of seep/AOM firmware supported by the platfoml, and the latest ve rsion of EUD supported by the
platform. We' ll cover seep/AOM and EUD later in this class.
See SOL9476: The F5 hardware/software compatibility matrix for more details .
Use the AskF5 Knowledge Base as your first resource when you need help. AskF5 solutions are avai lable
whenever you need them and include the most up-to-date information available from F5.
Preventive and Corrective Issues Management
Step-by-step instructions, downloads, and links to additional resources give you the means to so lve issues
quickly and without delay. Because you can search by product, version, and document type, in addition to
key words, it is easy to find the answers you need. For more complex queries, you can narrow your search
using Boolean operators (AND and OR) and Lucene search mode (to modify the way the search engine
interprets special characters for wildcard, fuzzy, and proximity searches).
AskF5 provides resources fo r you to add ress potential issues before they become reality. In addi tion to
standard searches to find information, you can select a specific product to see all documents related to that
product, read release notes, access product manuals, and view the most requested so lutions for the
product.

Documented known issues are posted to Askf5 between release dates so you can implement solutions
right away. If vulnerabilities are discovered in a BIG-IP component, F5 will send a security email alert
The email alert wilt point you to the security advisory, which will specify wbich products are affected,
describe the vulnerability, explain risks associated with running an affected version, and provide available
hotfix information.
Askf5 RSS feeds are an excellent way to stay informed about new documents specific to your F5
products and versions. The AskFS Recent Additions page, which is published over RSS, provides an
overview of recently added or updated documents. You can configure feeds tbat pertain to specific
products, product versions, and document sets. You can also aggregate multiple feeds in your RSS reader
to display One unified list of all selected documents.
Document categories
The Askf5 Knowledge Base is divided into several document types:
V ReJease Note ~ OI/ervieW
~ Manual ~TroobleShooting
~8eSI practice ~ HOW-TO
;2)Security AdVIsory ~ Error Message
~ Known Issue ~ Documenlabon Erratum
InfOO11atiooal ~ Change In Behavior
Figure 16: A.$kF5 Knowledge Base document categories
Searching for information
Askf5 's Advanced Search functionality provides additional granularity when specifyi ng search criteria .
For example, a series of selections can be used to filter the results produced by a keyword search. These
include:
• Product - Limits the search to a specific F5 product
• Version - When Product filter is specified, further limits the search to a particular version of the
selected Product
• Document type - Limits the search to a particular document type (e.g. Release Notes, Manuals,
Best Practice, Known Issue, Security Advisory, General Solution)
• Publication date - Limits the search to documents published within a particular time frame (e.g.
week, month, three months, year, two years)
• Updated date - Limits the search to documents last updated within a particular time frame (e.g.
week, month, three months, year, two years)

Sign Up for AskF5 Mailing Lists
Security Updates
Receive timely security updates and ASM attack signature updates from F5. When remote vulnerabilities
are discovered, F5 implements, tests, and releases security hotfixes for any vulnerable supported version,
and sends an cmail alert to the F5 Security mailing list. F5 encourages customers with an active support
account to scribe to tbis list. For more information, see SOL4602: Overview ofthe F5 security
vulnerability response policy. To sign up for the Security mailing lists, click Mailing Lists in the left
navigational panel of the AskF5 Knowledge Base.
TechNews
AskF5 provides two formats for their TechNews email publications:

• Weekly HTML TechNews - The weekly TechNews HTML email includes timely information
about known issues, product releases, hotfix releases, updated and new solutions, and new feature
notices.
• Periodic plain text TecbNews - F5 five sends a timely TechNews email any time a product or
hotfix is released. This information is always included in the next weekly HTML TechNews
email.
To sign up for the TechNews mailing lists, click Mailing Lists in the left navigational panel of the AskF5
Knowledge Base.
RSS Feed
Use F5 RSS feeds to stay infonned about new documents pertaining to your installed products, or
products of interest. AskF5's Recent Additions page provides an overview of all the documents recently
added to the knowledge base. Recent Additions is also published over RSS to provide additional
configurability. You can configure feeds that pertain to specific products, product versions, andlor
document sets. You can also aggregate multiple feeds in your RSS Reader to display one unified list of all
selected documents.
To sign up for RSS feeds, click the Recent Additions tab at AskF5.com. After you plug the feeds into the
RSS Reader of your choice, you are automatically informed whenever relevant documents are published
including known issues, security advisories, hest practices, general solutions, manuals, and release notes.

Chapter Resources
Solution Number Solution Title

SOL7683 Connecting a serial terminal to a BIG-IP system
SOL2595 Activating and installing a license file from Ihe Command line
SOL 13132 Backing up and! restoring BIG-IP
SOL 10288 BIG-IP software and platform support matrix
SOL3782 Finding the serial number or registration key of your BIG-IP system
SOL 12815 Overview of Appliance mode
SOL3242 Overview of BIG-IP Traffic Management Microkernel (f MM) CPU and RAM usage
SOL7312 Overview of the management port
SOL 13284 Overview of management interface routing
SOL 13148 Overview of default management access settings for F5 products
SOL7752 Overview of licensing the BIG-IP system
SOL 13369 Performing a first-time configuralion from the command tine (11.x)
SOL 13127 Restoring the BIG-IP configuration to factory default settings (11.x)
SOL9476 The F5 hardware/software compatibility matrix
SOL175 Transferring files to or from an F5 system
SOL9245 Verifying that a BIG-IP license is valid
SOL 13250 Overview of port lockdown behavior (10.x-11.x)
SOL 12352 Datasheets for F5 hardware platforms
SOL31122 Using the BIG-IP Configuration utility to add an NTP server
SOL3381 Setting the time and date on the BIG-IP system
SOL 13380 Configuring the BIG-tP system to use an NTP server from the command line (11.x)
SOL 13092 Overview of securing access to the BIG-IP system
SOL5380 Specifying allowable ranges for SSH access
SOL13418 Archiving UCS files using the log rotate and crontab utilities (11.x)
SOL9403 Overview of Ihe Always-On Management (AOM) subsystem
SOL9608 Configuring the AOM so it can be accessed over the network
SOL2200 Most recent versions of F5 software
SOL8986 F5 software life cycle policy
SOL9957 Creating a custom RSS feed to view new and updated documents

BIG-IP System Setup Labs
The BIG-IP System Setup Labs are di vided into several sections, as follows:
• Lab I, I - Confi gure the Management Port
• Lab 1,2 - Activate the BIG-IP System (License, Provision , Device Certificate)
• Lab 1,3 - Classroo m Network Configuration
• Lab 1.4 - Test Access and Archive the Configuration
• Lab 1.5 - AskF5 Research (if Internet access)
Estimated Time for Comp letion: 45 minutes
Note: For all labs, when an "X" is listed in lab instruction steps, please substitute your lab station
number instead, For example, for lab station 1, the IP address shown as 192,168,X.3 1 in the lab
instructions would be entered as 192.168.1.31 when carrying out the instruction . A password
specified as "root)(" in the instructions would be entered as root1 .
Important: If using Firefox as your browser throughout these labs, please do NOT permanently
accept any certificate exceptions when accessing the BIG-IP system ,
Lab Preparation Tasks
Verify workstation IP addresses are properly configured
Ifpossible, yo ur workstation should be configured with two IP addresses in order to access the BIG-IP
system simultaneously through the management IP address ( 192. 168.X.3 I) and external self IP address
( 10. 10.X.3 1). The steps below are genera lly applicable for a Windows 7 environment. If you are using a
different operating system andlor are unfamiliar with how to configure multiple lP addrcsses, please
consult with the in structor.
1. Open the Windows Control Panel function
2. Select Network and Internet (may also be Network Connections)
3. Click View network status and tasks
4. C li ck Local Area Connection
5. Cli ck the Properties button
6. Double click Internet Protocol Version 4 (TCP/JPv4)
7. Se leclthe radio button next to Use the following LP address and configure the fo llowing
settings:
a. IP address: 192.168.X.30
h, Subnet mas k: 255.255.0.0
c. Default gateway: Leave blank OJ as provided by your instructor
8, Click the Advanced button to add a second IP address.

9. In the Advanced TCP/IP Settings window, click the Add button under the IP addresses area
and configure the following:
a. IP address: 1O.IO.X.30
b. Subnet mask: 255.255.0.0
c. Default gateway: 10.1 0.17.33 (or as provided by your instructor)
10. Select the radio button next to Use the following DNS server addresses and set Preferred DNS
serve to 10.10.17.53 (or as provided by your instructor).
II. As necessary, click OK to close all network configuration windows and save your changes.
Note: If you cannot configure your PC to have more than one IP address, start with the
192.168.X.30/16 address and then switch to the 1O.10.X.30/16 address after the BIG-IP system
has been licensed, initially set up, and a standard network configured.
Continue with Lab 1.1: Configure the Management Port

Lab 1.1 - Configure the Management Port
Lab Objectives .....,IP

~J 1I;fIj l ~
• Configure the IP address and network mask for the BIG-IP

management port
Lab Requirements
• For classrooms with BIG-IP hardware devices, serial console access to the BlG-IP system or
physical access to the BlG-IP device if using the LCD option
• For classrooms with BIG-IP YEs, access to the preconfigured management port (l92.l68.x.31)
to rerun the conjig command, if desired.
Configure the Management Port
Note: Your instructor will tell you which method you will be using to configure your BIG-IP
system's management port.
Run only one of the following, as indicated by your instructor.
A: Configure the management port via the MGMT port (pages 1-36 through 1-38), or
B: Configure the management port via a serial console (pages 1-39 through 1-41), or
C'. Configure the management port via the LCD panel (page 1-42)

A: Configure the Management Port via the MGMT Port
1. Gain access to the BIG-IP system's management port. Open an SSH session using PuTTY (or
other SSH client) to the preconfigured management port IP address 192.16S.X.31 where "X" is
your station number.
2. When prompted to log into the BIG-IP system, enter root for the usemame and default for the
pass word.
3. At the config # prompt, enter the command: config
Note: Use the <Tab> key to tab between fields and options in the config tool. Use the
<Backspace> andlor <Delete> keys to remove field content. Use the <Enter> key to select an
option (such as "OK" or "Next"). You can also select an option by moving the mouse cursor over
a particular option (such as "OK" or "Next") and clicking.
Start the configuration process
4. Start the process of configuring the management port. On the Configuration Utility panel, as
shown below, press the <Enter> key to select the OK option.
· ..·nfl'I'J! ,tl·;;1 "tITlt'
Use t his utility to add an IP address, netmask and default route
for the management port on t his system.
You must add an IP address and netmask for the management port
before you can use the web- based Setup utililty.
--
1-36 Administenng BIG-IP v11

Select manual configuration of the IP address
5. On the Configure IP Address panel, as shown in the example below, ensure the No option is
highlighted (to bypass automatic configuration of the IP address) and press the <Enter> key. (If
the No option is not already highlighted, use the <Tab> key to tab to it before pressing the
<Enter> key.)
IMPORTANT: Do NOT select the <Yes> option shown in the panel below or you may
inadvertently reset your BIG-IP device to its default IP address and netmask, rendering it
inaccessible. Alert your instructor immediately if you inadvertently do so.
I Use automatic configuration of IP address ?
Current IP Address : 192 . 1 68.X . 31
Cur rent Ne trnask : 255 .255 . 0 . 0
De fault Route :
< Ye~ > ..

Set the IP address to 192.168.X.31
6. On the Configure IP Address panel, as shown in the example below, use the <Backspace>,
<Delete>, andlor arrow keys to change the IP address to 192.168.X.3I, where "X" is your station
number. After changing the IP address, press the <Tab> key to highlight the OK option, then
press the <Enter> key to continue.
F~~~~~~~~~=~·'·'II.f.lY Il.L 1 Ad<lL~'''S:l==~~~~~~~~~='i1
IP Address
[ 1 92 . 168.X_31 P
I
-- <Ca ('.;1>

Set the netmask to 255_255_0_0
7. On the Configure Ne/mask panel, as shown in the example below. After changing tbe netmask,
press the <Tab> key to highlight the OK option, then press the <Enter> key to continue.
Netmask
[255.255.0.0
Set no default route

- <("ilrc~l >
8. When prompted to create a default route for the management port, select the No option and press
the <Enter> key to continue, as sbown in the example below. In our classroom environment, no
default route is required.
anaGeme'lt hl)ut
Do you want t o create a default route for the management port ?
This i s requi red I f you want to connect to the management port
from another subnet •
< tee
Confirm the management port configuration

:> ..
9. On the Confirm Configura/ion panel, ensure that your settings are correct, as shown in the table
below, then select the Yes option and press the <Enter> key to complete the configuration. [I' the
options are not correct, select the No option and rerun the config corrunand. (See earlier steps.)
I liP Address I 192.168.X.31
Skip forward to Lab 1.2: Activate the BIG-IP System
1-38 Admlnlsterrng BIG-IP v11

B: Configure the Management Port via a Serial Console
Note: Do not do these steps if you already completed A: Configure the Management Port via
the MGMT Port. Skip forward instead to Lab 1.2 Activate the BIG-IP System.
I. Gain access to the BIG-IP system's serial port

a. For classes using se.n.al cables, connect a null-modem cab le between the BIG-lP device
and a VT-IOO emulator. Tbe serial settings should N-8-1 at 19,200bps.
b. For classes using seria l terminal emulators, open an SSH session using PuTTY (or other
SSH client) to the sen.al console lP address provided by your instructor. Tbis should
connect you to the serial port of your BIG-lP system. You may need to log into the
console server before logging into the BIG-IP system in the next step.
2. When prompted to log into the BIG-IP system, enter root for the usemame and default for the
password .
3. At the config # prompt, enter tbe command: config
Note : Use the <Tab> key to tab between fields and options in the config tool. Use the
<Backspace> andlor <Delete> keys to remove field content. Use the <Enter> key to select an
option (such as "OK" or "Next"). You can also select an option by moving the mouse cursor over
a particular option (such as "OK" or "Next") and clicking.
Start the configuration process
4. Start the process of configuring tbe management port. On the Configuration Utility panel, as
shown below, press the <Enter> key to select the OK option.
~======~~~~~~ · C.[';".T7
~··~Wt
!U ~~t~~,
I 7~'-~~~~
. 'l l l l~,~~~~~~~~~~~~
Use th~ s utility to add an IP address, netmask and default route
for the management port on this system.
You must add an IP address and netmask for the management port
before you can use the web-based Setup utililty.
--
Administering BIG -IP v11 1-39
Select manual configuration of the IP address
5. On the Configure IP Address panel, as shown in the example below, ensure the No option is
highlighted (to bypass automatic configuration of the [p address) and press the <Enter> key. (If
the No option is not already highlighted, use the <Tab> key to tab to it before pressing the
<Enter> key.)
IMPORTANT: Do NOT select the <Yes> option shown in the panel below or you may
inadvertently reset your BIG-IP device to its default IP address and netmask, rendering it
inaccessible. Alert your instructor immediately if you inadvertently do so.
, "I \';'1: 1f ~.j'j[ "h
Use automatic configuration of IP address?
Current IP Address : 192 .168.1. 245

Current Ne tmask: 255. 255.0.0
Default Route:
< It-S > ..

Set the IP address to 192.168.X.31
6. On the Configure lP Address panel, as shown in the example below, use the <Back.space>,
<Delete>, andlor arrow keys to change the [p address to 192.168.X.3I, where "X" is your station
number. Af\er changing the [p address, press the <Tab> key to highlight the OK option , then
press the <En ter> key to continue.
1
IP Address
1192 .168.X.31
< d >

Chapter 1 - Settmg Up the BIG-IP System 1-41
Set the netmask to 255_255_0.0
7. On the Configure NemlGsk panel, as shown in the example below. After changing the nctmask,
press the <Tab> key to highlight the OK option, then press the <Enter> key to continue.
',' I I l' ': :j'.')', _.
Ne lmask
[255.255.0.0
Set no default route

- <CiHIC" >
8. When prompted to create a default route for the management port, select the No option and press
the <Enter> key to continue, as shown in the example below. In our classroom envirorunent, no
default route is required.
~======================~~"~~;~~~~~~
C'~ "'~ lr'-'~ lr i~(7t~3i==~
nu~ __________________====~
Do you want to create a default route for t he management por t ?
This is required if you want t o connect to the management port
from another subne t •
<
Confirm the management port configuration

y<,~ > ..
9. On the Confirm Configuration panel, ensure that your settings are correct, as shown in the table
below, then select the Yes option and press the <Enter> key to complete the configuration. (ft he
options are nol correct, sclect the No option and rerun the conjig conunand . (See earlier steps.)
liP Address I 192.16S.X.3 1
Skip forward to Lab 1.2: Activate the BIG-IP System
Admm1stenng BIG-IP v11 1-41

C: Configure the Management Port via the LCD Panel
Note: Do ill!! do these steps if you already completed A: Configure the Management Port via
the MGMT Port or B: Configure the Management Port via the Serial Console. Skip forward to
Lab 1.2: Activate the BIG-IP System instead.
This lab can only be carried out if your classroom environment includes BIG-LP
hardware devices. All steps are done using the buttons to the right of the LCD
display on tbe front of the BIG-IP device itself The arrow buttons are used for
navigation. The checkmark button is used to make a selection or to save a setting.
I. Press the red X button to start the configuration process.
2. Using the up/down arrows, navigate to System menu and press the
green check mark button to select it
3. Navigate to the Management meou and press the green check mark button to select it
4. Navigate to the lP Address menu and select it
5. Navigate to the IP Address field and select it
. 6. Using the up and down arrow keys to increment/decrement the values in each octet, enter the IP
address as 192.168.X.31 where "X" is your station numbeL Press the green check mark button
to save your setting.
7. Navigate to the Netmask field and select it
8. Enter the netmask as 255.255.0.0 and save your setting.
9. Use the down arrow to navigate to the Commit menu and select it When you see the OK menu
blinking, click the green checkmark button.
Continue with Lab 1.2: Activate the BIG-IP System

Chapter 1 - Settmg Up the BIG-IP System 1-43
Lab 1.2 - Activate the BIG-IP System
Lab Objectives
Ensure the BlG-IP system:

• Is properly licensed and provisioned for configuration and operation
• Has a self-signed SSL certificate insta lled for operatio»
• Has a valid host name, and updated root and admin user credentials
Lab Requirements
• Access to the BIG-IP system's base registration key

• Access to the Internet or to the BIG-IP system's license tile
• Network access to the BIG -IP system's management port
Activate the BIG-IP System
Note: Your instructor will tell you which method you will be using to activate your BIG-IP system,
including licensing , provisioning, and device certificate setup. Two methods are available and
instructions for each have been provided in the lab steps that follow. You should run only one
set of steps, as outlined below and as indicated by your instructor.
Run either:
A: Activate a Licensed BIG-IP System (pages 1-44 through 1-45), or
B: Activate an Unlicensed BIG-IP System (pages 1-46 through 1-48)
Adm inistering BIG- IP v11 1-43

A. Activate a Licensed BIG-IP System
Provision your BIG-IP system
l. Open a browser session to https:11192.168.X.31 where "X" is yOUJ station num ber. BIG-IP ships
with a self-signed SSL certificate. If your browser asks you to, accept the certificale (not
permanentl y, ifusing Firefox) and log in with usemame adruin and password admin .
2. On the resulting Welcome page, click the Run the Setup Utility li.1lk thai appears in the Setup
area of the page. You may need to scroll down to find il.
3. On the subsequenl Setup Utility » License page ofthe Setup utility, click the Next button 10
continue.
4. On Ihe subsequent Setup Utility » Resource Provisioning page oflhe Setup utility, provision
your BIG-IP system, as shown below .
Current Resource Allocation section
Note: Your BIG-IP may produce a warning message that certain system daemons may restart ,
causing your session to wait for a minute or so. This is normal behavior when changing
provisioning settings.
Accept the BIG-IP Self-Signed Device Certificate
5. After provisioning is complete, you should be taken to the Device Certificates page in the Setup
ulility. We will be using the BIG-JP system's self-signed certificate in class. Note Ihe expiration
date for the certificate for possible later discussion, and click the Next button to conlinue the
Setup utility.

Configure User Administration
6. Configure host name, time zone, and administrative access usernames/passwords. Remember to
substitute your station number for "X." Some fields may already contain the correct values.
General Properties section
Management Port
User Administration section

Password: raalX
Root Account
Confirm: raalX
Password: adminX
Admin Account
Confirm: adminX
Nexl, then OK
Note: You are changing the passwords for the root and admin accounts, not creating new
accounts. Since you are currently logged in using the admin account, you may need to log back
in again with your new password.
7. Log back in to BIG-IP as user adruiD with password ofadruinX. You should be taken directly to
the Setup Utility » Network page. If the page does not load entirely (parts of it are blank), try
clicking on any visible tab (such as Main or About), hard-refresh your browser page (Ctrl-F5) or,
worst case scenario, restart your browser and connect to the BIG-1P management port again.
Skip forward to Lab 1.3: Classroom Network Configuration

B. Activate an Unlicensed BIG-IP System
Note: Do not do these steps if you already completed A: Activate a Licensed BIG-IP System.
Skip forward instead to Lab 1.3 Classroom Network Configuration.
Locate the Base Registration Key and License File
Note: Your instructor will let you know where to find the base reg istration key and license
information that you will use during this lab. Please ask your instructor for assistance if you
cannot quickly locate this information.
t. Locate the base registration key and license file that you will use in subsequent steps. Your
instructor will let you know where to find them.
License your BIG-IP system
2. Open a browser session to https:11192.168.X.31 where "X" is your station number. BlG-IP ships
with a self-signed SSL certificate. Accept tbe certificate (not pennanently, if using Firefox) and
log in with usemame admin and password admin.
Note: Upon connecting to your BIG-IP system, you should be directed to the Setup utility.
Please let your instructor know if you are not placed directly into the Setup utility.
3. Click the Next button to start the Setup utility.

4. On the subsequent Setup Utility» License page, click the Activate button to begin tbe licensing
process.

5. Use the Base Registration Key you located earlier to generate a dossier us ing either step <a) or
(b) below, depending on whether or not the Base Registration Key field already has a value in it.
a. If your Base Registration Key field does not already have a value prepopulated in it:
When complete, click ...
b. If your Base Registration Key field already has a value prepopulated in it :
GentKal Properties section
When complete, clicll ...
6. Generate the dossier and install your license. In Step!: Dossier below, a fil e called dossier.do
will be downloaded to your workstation. If prompted for where to save the file, choose the
desktop. In Step 3: License below, select the bigip.license file you found in a previous lab step.
o-at Properties lHICt/on
Click Choose File and navigate back to the license file

Step 3: license
found earlier.
When complete, ctIck...
processes are now restarted, and BIG-IP will inaccessible for about a minute.
instructor if the continues for than that.
When configuration
changes have been Continue
click...

7. Upon returning to the BIG-IP system from the previous step, you should be taken directly to the
Resource Provisioning page of the Setup utility. Provision your BIG-JP system, as shown below.
Current Resource Allocallon section
Note: Your BIG-IP may produce a warning message that certain system daemons may restart,
causing your session to wait for a minute or so. This is normal behavior when changing
provisioning settings.
Accept the BIG-IP Self-Signed Device Certificate
8. After provisioning is complete, you should be taken to the Device Certificates page in the Setup
utility. We will be using the BlG-JP system's self-signed certificate in class. Note the expiration
date for the certificate, and click the Next button to continue the Setup utility.

Configure User Administration
9. Configu re host name, time zone, a nd administrative access usernames/passwords. Remember to

substitute your sta tion number for "X." Some fields may already contain tbe correct values.
IP Add ress[/prefix]: 192.168.X.31

Management Port
Network Mask : 255.255.0.0
User Administration section

Password: rootX
Root Account
Confirm: roolX
Password: adminX
Admin Accou nt
Confirm : adminX
Next. then OK
Note: You are changing the passwords for the root and admin accounts, not creating new
accounts. Since you are currently logged in using the admin account, you may need to log back
in again with your new password.
10. Log back in to BIG-IP as user admin with password of ad minX. You should be taken directly to
the Setup Utility » Network page. If the page does not load entirely (parts of it are blank), try
clicking on any visible tab (such as Main or About), hard-refresh you r browser page (Ctrl-FS) or,
worst case scenario, restart your browser and connect to the BIG-IP management port again.
Continue with Lab 1.3: Classroom Network Configuration and Backup

Lab 1.3 - Classroom Network Configuration
Lab Objectives
• Continue using Ihe Setup ulility 10 creale Ihe VLANs and Self IPs that are used in support of the
classroom lab environment, and to prepare the BIG-JP system for high availability.
Lab Requirements
• Access to a li censed and provisioned BIG-IP system via the management port
• Students already have an open browser window to the BIG-IP system, and are in the Setup utility,
havi ng completed licensing, provisioning, and device certificale steps.
Configure the Classroom Network
I. Continue the Setup utility by performing a Standard Network Configuration. Click tbe Next
button under the Standard Network Configuration heading, as shown in Figure J8:
Standard Network Configuration

Create a standard nerv"orl(~c::Co:-:flg
nz:-:l"'~t:-:n
Jra',o-'-"'-
b), C:-"""'"'
config l:-:"
lrIn::C
g =lh:-:se
eC:-:Cr"'ature-s
·e.cc"'=
• Redundancy
• VLANs
• Config Sync
Fallover
• MirrOring
• Peer Device OiscO\'-ery (for Redur l d~'irlt CUIlfigufations )
Advanced Network Configuration

CreateaciVanced deVIce configurations by clicking Finished and navigating to the Mam tab of the Configuration Utilrty
I FiniShed I
Figure 17: Click the Next button to use the Setup utility wizard for standard networl< configuration

Configure Redundant Device Wizard options
2. Set Redundant Device Wizard Options to prompt for CODfigSync settings and High
Availability options.
Redundant Device W izard Options section

Check the box for Display configuration
ConfigSync
Check the box for Display failover and mirroring

High Availability options
Select Network
Wilen complete, cliCk ... Next
Configure Self IPs and VLANs
3. Configure VLAN internal and its self IPs, interface, and port lockdowo settings.
Setup utility
Setup Utility » VLANs
Intemal Network Configuration section

Address: 172.16.X.31
Self IP
Netmask: 255.255.0.0
Port Lockdown: Allow Default
Floating IP
Port Lockdown : Allow Default
Internal VLAN Configuration section
VLAN Name internal
VLANTag 10
auto
Move 1.2 from the Available column to the
VLAN Interfaces
Untagged column
When complete, cliCk... I Next

4. COnfigure VLAN external and its self LPs, interface, and port lockdown settings.
External Network Configuration sactlon
Address: 10.10.X.31
Setf tP Netmask: 255.255.0.0
Port Lockdown : Allow 443
Address: 10.1 0.X.33
Floating IP
Port Lockdown: Allow 443
External VLAN Configuration section
Move 1.1 from the Available column to the

VLAN Interfaces
cotumn
Whan complete, click ... Next
5. Configure the high availability network to use the existing VLAN internal.
High Availability Network ConflgUl'allon sactlon
Netmask: 255.255.0.0
High Ava~abillty VLAN Configuratlon section
I
When complete, click . ..

Configure ConfigSync
6. Configure ConfigSync on the non-floating self IP for VLAN internal.
ConfigSync Configuration section
When complete, dick...
Configure Unicast and Multicast Failover settings
7. Use the default settings for Failover Unicast Configuration and Failover Multicast
Configuration.
Faltover Unicast ConfIguration sec\lor)
Local Address I Port I VLAN

Address
Failover MuHicast Configuration section
Mirroring configuration
8. Use the default primary and secondary local mirror address settings for Mirroring
Configuration .
Mirroring Configuration section
Next

1-54 Chapter 1 - Settmg Up the BIG-IP System
Finish the Setup Utility
You have now completed configuring the network interfaces that are used in support of the classroom
envirorunenl. We will not be configuring a standard Active/Standby pair in this class so you can exi t the
Setup utility at this point.
9. Click the Finished button under tbe Advanced Device Management Configuration heading.
You should be taken to the Welcome page, and there should be a message at the top of the page
indicating the Setup Utility has completed, similar to what is shown in Figure 19.
Figure 18: Setup Utility Completion is indicated in the message area after exiting
Continue with Lab 1.4: Test Access and Archive the Configuration

Lab 1.4 - Test Access and Archive the

Configuration
Lab Objectives
• Test ad mini strative access to tbe BIG-IP system

• Create a UCS arc hi ve of the 81G-1P system configuration.
Lab Requirements
• Access to a 8 IG-IP system that has completed the initial setup process, including management
port configuratio n, licensing, provisioning, device certificate setup, and standard network
configuratio n.
Test Administrative Access to the BIG-IP System
Test SSH (port 22) access to the management port
I. Using PuTTY, open an SSH session to 192.168.X.31. Make sure the protocol is set to SSH (port
22) before connecting. Log in as root with password rootX. Were you able to connect? What
BIG-IP configuration setting(s) permits this access? When you are done, you may close the
PuTTY window or leave it open for later lab steps.
Test HTTPS (port 443) access to VLAN external's self IPs
Open a browser window to https:III0.1O.X.31 and log in as user admin with password admin)'
What are you connecting to at this address? What 8IG-1P configuration setting(s) permit this
access?
Open a browser window to bttps:III0.I0.X.33 and log in as user admin with password adminX.
What are you connecti ng to at this address? What BIG-IP configuration setting(s) permit thi s
~I.!' 8"* access?
~ote: Although you can connect to the GUI or command line using the BIG-IP system's self IP
addresses, such access is typically restricted to avoid security risks . On a customer- or Internet
facing VLAN , there is often no access via the self IPs, or access is restricted to port 443
(HTTPS) only.
Admlnlstenng BIG-IP v11 1-55

Test SSH (port 22) access to VLAN external's non-floating self IP
4. Using PuTTY, try to open an SSH session to IO.IO.X.3I. Make sure the protocol is set to SSH
(port 22) before connecting. Were you able to connect? Why or why not? • .
-1/"..
Note: Your network connection in the previous step should be refused, as this self IP is currently
protected via Port Lockdown. By default, when using the Setup utility to create VLAN external,
the BIG-IP system only permits access to this VLAN's self IPs via port 443 (https). SSH uses
port 22. Port Lockdown is covered in more detail later in this course.
s. Reconfigure the self IP address IO.IO.X.3I to also allow access via port 22.
Configuration section
Select the TCP and Port radio buttons

Custom List Enter 22 in the field that appears to the right of Port
Click Add
When finished ... Click Update
6. Using PuTTY, try to open an SSH session to IO.IO.X.3I again. You should have success this
time. If not, review the Port Lockdown settings for this self IP and make sure port 22 was
successfully added in the previous step.

Note: In the next section, you'll start using some Traffic Management Shell (tmsh) commands to
become familiar with the command line interface. tmsh commands will be discussed in more
detail in a later chapter.
The lIess parameter used in the instructions below allows scrolling when tmsh command output
is more than the console can display. Use the arrow keys and the space bar to scroll through
the output. Type q to quit scrolling mode and return to the Linux bash prompt.
7. Use the Traffic Management Shell (tmsh) command to view various conliguration settings. Using
PuTTY, open (or reuse) an SSH session to to.to.X.3I or to I92.I68.X.31:
a. Log in to the SSH session as the root user with password rootX.
b. At the Linux bash prompt, enter the following command and compare the results with what
you see in the Configuration utility (GUI) at Network» VLANs.
tmsh list /net vlan Iless
c. At the Linux bash prompt, enter the following command and compare the results with what
you sec in the Conliguration utility (GUI) at Network » Self IPs.
tmsh li st /net s el f I less
d. At the Linux bash prompt, enter the following command and compare the results with what
you see in the Configuration utility (G UI) at Network » Interfaces.
tmsh list /net inte r face Iless
e. At the Linux bash prompt, enter the following command and compare the results with what
you see in the Configuration utility (GUI) at System » License.
tmsh show jsys license
f. What is the registration key for your BIG-lP system?

g. What is the software version Dumber this license was first activated for?
h. What is the service check date for your BIG-IP system?

Configure command line access for the admin user
8. Open another SSH session window to W.W.X.31 or to 192.l68.X.3l and attempt to log in as the
admin user with password ad minX. Were you successful?
Note: Your attempt to log in to the command line interface as the admin user in the previous
step should fail. By default, the admin user does not have access to the command line.
9. Update the admin user settings to permit access to the command line interface, but only to the
Traffic Management Shell (tmsh).
Account Propertles sectfon
When finished, cflCl<.. .
Note: When changing terminal access for the admin user - the user you are currently logged in
as - you may have to log back onto the GUI again.
10. Open an SSH session to W.lO.X.31 or to 192.168.X.31 and test logging in with the admin user
credentials again. Were you able to connect this time?
11. How is your access different from the root user? (Hint: Check the prompt after you log in as
each user.) What do you have access to as the root user that you do not have access to as the
admin user?
Check root user access to the GUI
12. Open a browser window to IO.10.X.31 or 192.l68.X.31 and attempt to log in as the root user.
Were you successful?
Note: Your attempt to log into the GUI as user "root" should fail. User "root" does not have
access to the BIG-IP systems administrative GUI, only to the command line.

Create a UCS Archive of Your Configuration
13. Open a browser window to 10.10.X.31 or 192.168.X.31 and create a backup of your current
configuration
Finished, then click OK when the archive is complete
14. Download your new UCS backup to your workstation hard drive for possible use in a later lab.
TralnlLbase.uca section
Click Download: IrainX_base.ucs, then save to
Archive File
des ent PC.
View the backup UCS file using the command line interface
15. Open an SSH session to BIG-lP system.

16. At the config# prompt, make a new directory:
mkdir /var/tmp/test
(Note: This directory may already exist from a previous class. If so, continue with the next step.)
17. Change to the new directory:
cd /var/tmp/test
18. Copy the backup previously downloaded to the new directory (and replace, ifnecessary).
Remember to replace the "X" with your station number in the file names:
cp Ivar/local/ucs/trainX_base.ucs trainX base.ues
19. Decompress and extract the file contents:

tar -xvzf trainX base.lies
The resulting files show the directory structure and all files stored within the UCS backup.
individual files can be viewed with cat, tail, more, less, and other command line tools.

Expected Results
At the end of the previous labs, you should have configured the BIG-lP system up to the point where it is
connected to the network and able to process administrative traffic. For the remainder of the class, you'll
learn how to configure the BIG-IP system for application delivery. Whether you're working on BIG-lP
virtual edition or on actual BIG-IP devices, Figure 20 provides a conceptual representation of the work
you've done to date. You can use this as a reference throughout the remainder of the class.
192.168.X.30 0 10.10.X.30
MGMT IP
192.168.X.31/16
VLAN: exte rn al
Inte rface: 1.1
Non·floating Self IP: 10.10.X.31/ 16
Floating Self IP: 10.10.X.33
Port Lockdown: Allow Custom (22 & 443)
VLAN: internal
Interface: 1.2
Non-floating Self IP: 172.16.X.31 / 16
Floating Self IP: 172.16.X.33
Port Lockdown: Allow Def ault
Figure 19: Conceptual rep resenta tion of your ctassroom environment aner setop lob completion
If you have Internet access in your classroom environment, continue

with Lab 1.5: AskF5 Resources Lab.

Lab 1.5 - AskF5 Research Lab (if Internet)
Lab Requirements:
• Access to the Internet
Research Solutions
I. Open a browser session to http://askf5.com

2. Find the release notes for the 11.4.0 version of one of the BIG-IP products (e.g. LTM, GTM,
ASM, etc.) and read the section entitled New in 11.4.0.
3. Search for other solutions that relate to the topics presented in this chapter. You can use the list of
Chapter Resources on page 1-32, or here are some suggestions:
a. SOL13132: Backing up and restoring BIG-LP configuration files (ll.x)
b. SOL2200: Most recent versions of F5 software
e. SOL13250: Overview of port loekdown behavior (lO.x-ll.x)
d. SOL5903: BIG-IP software support policy
e. SOL917: Finding the serial number or registration key of your F5 device.
f. SOL9957: Creating a custom RSS feed to view new and updated documents
4. Search for other AskF5 documents relating to topics in the upcoming modules and explore them.
For example:
a. Manual Chapter: BIG-lP Local Traffic Manager: Concepts > Nodes
b. Manual Chapter: BIG-lP Local Traffic Manager: Concepts > Pools
c. Manual Chapter: BIG-IP Local Traffic Manager: Concepts > Virtual Servers
d. Manual Chapter: BIG-lP Local Traffic Manager: Concepts > SNATs
STOP

1-62 Administering BIG-IP v 11

Chapter 2 - Traffic Processing with LTM 2-1
Chapter 2: Traffic Processing with LTM

Chapter Objectives
After completing this chapter, you will be able to:
• Articulate how virtual servers, pools, pool members, and nodes work together to process traffic
• Describe how round robin and ration load balancing methods work
• Configure virtual servers, pools, pool members and nodes to access an application and test
Overview of LTM Traffic Processing
Lesson Objectives
• Define the terms vutual server, pool, and pool member, as they relate to BIG-IP Local Traffic
Manager (LTM)
Understanding Traffic Processing with LTM

BIG-IP Local Traffic Manager (LTM) is one of several products that constitute the BIG-IP product
fantily. LTM controls traffic that comes into or goes out of or within a local area network, including an
intranet.
In a typical client-server scenario, a client request goes to the destination server specified in the request,
as illustrated in the top part of Figure 1. For sites with large volumes of inconting traffic, a destination
server can quickly become overloaded. Also, such servers are frequently located within networks that use
private (RFCI918) addresses and are physically isolated from public networks.
To solve overloading problems, the BIG-IP system sits between clients and internal servers, as shown in
the bottom part of Figure 1. Clients don't send traffic directly to the internal servers. Instead, client traffic
is directed to virtual servers on the BIG-IP system. BIG-IP LTM essentially intercepts and intelligently
processes this incoming network traffic to the internal servers, often load balancing the traffic based on a
variety of criteria specified in the LTM configuration.
Although load balancing is one of the most common uses for LTM, it is not the only use. LTM can also
solve challenges in WAN optimization and infrastructure offload. For example:
• TCP optintization, adaptive compression, and data de-duplication features relieve network
congestion and reduce bandwidth utilization;
• LTM can be used to offload CPU-intensive processes such as compression and SSL processing
from your servers to accommodate more growth within existing infrastructure; and,
• LTM can simplify server and SSL certificate management and consolidate application
optimization and DNS processing into a single, centralized application delivery solution.

2-2 Chapter 2 - Traffic Processing with LTM
Application
Server
Application Servers
Figure 1: Client-server behavior (top) contrasted with client-server behavior when BIG-IP Local Traffic Manager sits
as a fuff-proxy in-between clients and servers (bottom)
Local Traffic Objects

Once you have set up your base network and have administrative access to BIG-IP (as you did in the
previous chapter), you can begin the process of configuring a network that proccsses traffic to your
internal servers. LTM sits between clients and your internal servers, and processes typical application
traffic using a combination of virtual servers and load balancing pools. In the simplest of terms, LTM
virtual servers recei ve incoming traffic, make decisions as to how to process that traffic, and direct traffic
to associated application servers that are grouped together in load balancing pools.
Now let's break these traffic processing elements down into their specific configuration objects
(definitions) on the BIG-IP system.
Nodes
A 00 de is a logical configuration object on BIG-IP that identifies the LP address of a physical device on
the network. A single node may logically represent multiple pool members, as shown in Figure 2. Nodes
are typically not defined directly. Rather, as a pool member is defined, its associated node object is
automatically created, if necessary.

172.16.20.1 172.16.20.2 172.16.20.3
Node
l= IP Address (rOI..- :z p)
Figure 2. A node definition on the BIG-IP system consists of an IP address only
Pool Member
Pool members are tbe actual application servers used to process client traffic, and are defined as
configuration objects on the BIG-IP system. The difference between a node and a pool member is that a
node is designated solely by the device's lP address (e.g. 172.16.20.1), while a pool member includes
both an lP address and a service port (e.g. 172.16.20.1 :80), as shown in Figure 3.
172.16.20.1 :80 172. , 6.20.2:80 172.16.20.3;80
Pool Member =Node IP + Service Port
Figure 3. Pool members are defined by an IP address and a service p ort

Pool members can also be defined with a host name instead of an IP:port combination, assuming BIG-IP
can resolve that name. Similarly, a service name can be used instead of the port value if a standard port is
being used (e.g. "http" instead of"80").
Pool members are grouped together into load balancing pools. When you create a pool, you also define
the pool members that it contains.
Note: The same IP:port combination can be defined in multiple load balancing pools, but each is
treated as a separate and distinct pool member within the BIG-IP system.

Pool
A pool is a logical set of pool members that are grouped together to receive and process a certain ty pe of
traflic. Instead of sending client traffic to the destination LP address specified in the client request, LTM
sends the request to any of the servers that are members of that pool. This helps to efficiently distribute
the traffic load on your server resources.
When you create a pool, you assign pool members to it. You then assign tbe poot to a virhlal server. LTM
directs traffic coming into the virhlal server to a member of its assigned pool .
With few exceptions, all the members of a given pool typicall y host the same content, as shown in Figure
4. A pool is assigned a load balancing method (or algorithm) at the time it is created. LTM uses the load
balanci ng method, along with other criteria, to detennine which pool member to direct network traffic to.
(See Distributing Traffic across Application Servers later in this chapter.)
Nn.1p I172.16.20.2
Pools Pool Members Pool Members Pool Members

http_pool 172.1620.1.80 172.1620.2.80 172.1620.380
https _pool 1721620.1443 17216202 '443 17216203443
ssh .Dool 172. 16.20.1'22 172.16202'22 172,16203'22
Figure 4: A pool is a group of relatad pool members
Virtual Servers hUp :/fwrNw.f5 .com
As a default deny device, the BIG-IP system will not

process application traffic unless it is told to specifically
liste n for traflic. A virtual server is One such listener.
The BIG-LP system supports many different types of
virtual servers. In this class, we'll focus on a standard
host virtual server that is often used to serve application
content, sucb as a web site or a wcb-based application.
Client traflic is directed to the virtual server on the BIG
lP system; BIG-IP then directs tra ffi c to the pool member,
as shown in Figure 5. Like pool members, a standard host
vi rhlal server's defi nition includes an lP address and a
service port. Often, a virhlal server' s LP address is
registered to a site's host name, and clients di scover the
address via DNS. Alternatively, DNS requests may
resolve to an LP address hosted by a firewall or other edge
device that will perform network address translation
(NAT) on the request, and then forwa rd it to a virhlal Figure 5 ' Client tramc IS directed to 8 viltual
server on the BIG-IP system . The service port on the server 0 11 BIG-IP
2-4 Adm inistering BIG-IP v11

virtual server should be the same TCP or UDP port known to client programs. For example, traffic to F5
Network' s website is processed by a virtual server on a BIG-IP system. The host name
http://www.fS.com - resolves to an IP address (suppose it's 216.34.94.17) . The virtual server is
con fi gured wi th this IP address and port 80, the standard port for HTTP traffic.
Virtual servers also include many other properties that give it the intelligence it needs to process the
traffic that it receives. For example, the properties can tell the BIG-IP system which poo l to use, by
defau lt, to load balance requests to, as shown in Figure 5, or on which VLAN(s) to listen for traffic,
limiting or opening up access to the vi rtual server and its associated back end resources. Other properties
can tell the BIG-IP system to use different methods when process ing traffic on the client side connection
vs. on the server side connection. For example, a virtual server can be configured to use SSL when
communicating with the client but not when communicating with pool members, reducing the workload
for the servers.
Virtual Server Address Translation

When you create a standard host virtual server, you can specify the de fault poo l that you want to serve as
the destination for traffic received by that virtual server. (There are other wa ys to make this association ,
as you'll see in the iRules chapter later on in this course .) This association maps the virtual server's
address to the pool members ' addresses. When client traffic is received on a virtual server, the BIG -JP
system typicall y perfonns the following funct ions :
• Checks availability of the pool members associated with the virtual server
• Selects the poo l member to load balanc e the request to
• In the request packet, "translates" the virtual server's IP address to the pool member'S IP address
• "Un tra nslates" the response packets as they are returned from the pool member
As shown in Figure 6, the translation process actually changes the destination lP:port for tbe incoming
traffic, and is usually enabled (by default) for all virtual servers. The source lP:port address is changed on
outbound traffic. In advanced configurations, address and port translation may be disabled.
Virtual servers can be configured to perfonn additional traffic management functions including:
• Compress ing or decompressing HTTP data as it passes through BIG-IP
• Decrypting and encrypting SSL connections and verifying SSL certificates
• Inspecting and directing traffic based on traffic contcnt
• Persisting client connections to the same pool member

2-6 Chapter 2 - Traffic Processing with L TM
Network Packet Flow

When a client connection arrives on the BIG-IP system, its destination is a virtual server address and port
(e.g. 2 16.34.94.17:80). The BIG-IP system further processes the request based on the virtual server's
configuration, and then sends it to a different final destination - a pool member (e.g. 172 .16.20 .1:80).
This translation process is transparent to the client. Although there are many exceptions, the most
common tra ffi c fl ow through BIG-IP includes the following steps, as illustrated in Figure 6:
I. Client sends a packet. The source address is the client's address; the des tination address is a
virtual server on the BIG-IP system. Using the virtual server's pool assign ment and the load
balancing method for that pool, LTM selects a pool member to process the request.
2. LTM translates the destination IP address:port from the virtual server's IP address:port to the pool
member's IP address:port, and sends the packet to the pool member. Source IP add ress and port
remain unchanged.
The pool member processes the packet and, on response, the translation process is reversed:
3. Pool member sends the response packet back to the BIG-l.P system. Source IP address:port is the
pool member; destination IP address:port is the client.
4 . LTM translates the source IP address:port from the pool member' s IP address:port back to the
virtual server's lP address:port, and sends the response packet on to the client.
Destination Destination
Client Virtual Server Client Pool Member
Pool Members
Client
Client Virtual Server Client Pool Member
A gure 6- Tra ffic flow through thf1 B/G-IP system showing the address translation proce ss used on both reque st and
response packets
Two TCP connections - a full proxy architecture

As mentioned earlier in this course, the BIG-IP LTM TMOS operating system implements a full proxy
architecture for virtual servers configured with a TCP profile. For such sessions, there are actually two
separate TCP connections:
I. A client-side connecti on between the client and the BIG-IP system
2. A server-side connection between BIG-IP and the pool member

The separate connections allow many changes to be made to traffic as it flows through BIG-IP including
but not limited to unencrypting requests and even changing request content. It also allows you to maintain
compatibility to disparate server operating systems in the data center.
In full-proxy architecture, the BIG-lP system appears as a Tep peer to both the client and the server by
associating two independent Tep connections with the end-to-end session. Although certain client
information such as the source IP address or source Tep port may be re-used on the server-side of the
connection, the BIG-l? system manages two sessions independently, making itselftransparent to the
client and server, as show in Figure 7. The three-way Tep handshake occurs on the client side of the
connection before the BIG-1P LTM initiates the Tep handshake on the server side of the connection.
Depending on the connection type, BIG-IP may also wait for the client to send its first packet of
information before initiating the server-side connection.
For more information on how BIG-IP processes TCP connections between client and server,
please see SOLBOB2: Overview of TCP connection set-up for BIG-IP L TM virtual server types.
Client
o TCP
Handshake
(client/BIG-I P)
Request
(client to BIG-IP)
Response
(BIG-IPto client)
Separate client and server connections
TCP
Handshake Request Response
(BIG-IP/server) (BIG-IPto server) (server to BIG-IP)
Servers
Figure 7: Not lust NA T, BIG- IP deploys a {ull-proxy architecture

Con'figuring Virtual Servers and Pools
Lesson Objective
• Use the Configuration utility to create a new virtual server, pool, and pool members, and
associate them with one another so as to process traffic.
Pool Configuration
You can use the Configuration utility or TMOS Shell (tmsh) to create a load balancing pool, or to modify
a pool and its members. When you create a pool, LTM automatically assigns a group of default settings to
that pool and its pool members. You can retain these settings or modify them (either during pool creation
or at a later time), as shown in Figure 8.
For a complete description of LTM pool configuration settings, please refer to the manual
entitled BIG-IP Local Traffic Manager: Concepts, available at AskF5.
C onfiguration: iBas\r: ..
-.. :
~Ul~s Rillourc ••
l
i L..CI~d E].~r~nong I\r'.eU'oai •
~ Pnl;Jnly GrtI!lp A::toration IO$8bile:o J::.
• o Nfffl ~dtJ 0 NodI! lJsl

TfEfflC Class
.-.. "'" 1===--------1
' " 1B~O.J
(00""011
l
...."'... .1
_. PO". II Il f<m'
Ne.... Member:>
[MlJ
ON!-! Cache's R.l POC O !n1G20 1 IT:! ii2!) 1 1ft!
R 1 P DC(J 17 J 162Q..1 I1J 18 :1 0 280
•••
rn!J~
~-----------------1
Figure 8: COOfiguring a pool calJed http.J"JOJ using Jhe GUJ
After configuring a pool, you can assign it to one or more virtual servers.
2-8 Administering BlG-IP v11

Virtual Server Configuration

You can use the Configuration utility or TMOS Shell (tmsh) to create a virtual server, or to modif'y a
virtual server and its assigned pools. When you create a virtual server, you specif'y the default pool that
you want to serve as the destination for traffic received at that virtual server. You can also configure its
general properties, some configuration options, and other resources you want to assign to it, such as
iRules. (For example, an iRule might be used to select a different pool than the default pool based on
other criteria such as where the tramc originated or what the traffic contains.)
Although LTM supports a wide range of virtual server configurations, in this class we will focus
exclusively on a very simple and common configuration - a host virtual server that represents a single lP
address, such as an internet web site or an FTP site. The site's content will be on the pool members in the
default pool we assign to the virtual server.
To configure and manage virtual servers, log in to the Configuration utility and, on the Main tab, expand
Local Traffic and click Virtual Servers.
For a complete description of both Basic and Advanced virtual server configuration settings,
please refer to the manual entitled BIG-IP Local Traffic Manager: Concepts available at AskF5.
- L.ooC<Jl Tumc )I
Genen.1 Properties
VlrtlJ'al S.rvllrt ' Vlru!... 1So rvlI! r lIu th·, In'Ii .. ' ,;;"'1 ... ·
Virtual server name

lApp
<# ... •
JName
local TraWl!;: D escnpLJon
Type Standard
VirttJ~l SeNers Source

L
"Type: e Host 0 t-.letv'lork
Adtl,ess: l lo 10 4 100
Pmlifes
!Rules.
Service PO ll LOI _ -,I I,,-HTTF'
S:::..
O vl
;.:...:.;._ _....
Pools State 1Enabled ,ow
I h~ pool
~
Default Pool .j ...1
Default Persistence Profile :None ~

Fallback Persisten~ Profile rNooo a
Figure 9: Configuring a standard host virtual Server at IP address:port 10.10.4.100:80 that is associated with default
poolllffpyool

Distributing Traffic across Application Servers

The BIG-lP system is often used to distribute traffic across an array of web servers that host standard web
traffic, including e-commerce traffic. Figure 10 shows a configuration where a BIG-lP system load
balances two sites: www.mysite.comandstore.mysite.com. The fanner provides standard web content,
and the latter is the e-commerce site that sells items to customers.
http://www.mysite.com https:l/store.mysite.com
D~
Virtual SeIVer1 Virtual Server2
www.MySite.com store.MySite.com
216.34.94.17:80 216.34.94 17:443
htlp pool sst pool
http pool s51 pool

172.16.20.1:80 17216.20.2443 ....-
172.16.20.2:80 172:16.20.3:443
172.16.20.1 172.16.20.2 172.16.20.3
Figure 10: Illustration of a basic web site and eCommerce configuralion with lraffic distributed by BIG·'P across
application servers
In this example, the two pools are sharing a node between them at 172.168.20.2. Requests for content
from www.mysite.comare load balanced between two pool members, 172.16.20.1:80 and 172.16.20.2:80.
E-commerce traffic is also load balanced between two pool members, 172.16.20.2:443 and
172.16.20.3:443.
This scenario eliminates a single point of failure for both sites without needing to add a fourth node. The
server at 172.16.20.2 may bave more capacity and better perfonmance compared to the other two servers
so that it can handle the apparent additional workload. However a lot depends on the load balancing
method used in each pool, as you'll see in the next section.
2-10 Administering B!G-!P v11

Load Balancing Concepts
Lesson Objective
• Compare and contrast two of the BIG-IP system's load balancing - Round Robin and Ratio
• Configure a load balancing method for a pool
Overview of Load Balancing

The BlG-lP system is designed to distribute client connections to load balancing pools that are typically
comprised of multiple pool members (servers). The load balancing method (or algorithm) is the primary
mechanism that the BIG-lP system uses to detennine how those connections are distributed across pool
members, and fall into one of two categories: static or dynamic. Certain load balancing methods are
designed to simply distribute connections evenly across pool members, regardless of what the pool
member's or nodes' current workload is. Therefore, they tend to work better with homogenous server
pools (e.g. servers that all have similar processing perfonnance and capacity) and/or homogenous
workloads (e.g. all connections are short-lived; all requestslresponses are similar in size). Other load
balancing methods are designed to favor higher perfonuing servers, possibly resulting in deliberately
uneven traffic distribution across pool members. Some load balancing methods take into account one or
more factors that change at run time, such as current connection count or capacity; others do not.
Load Balancing Methods

Static vs. Dynamic
A static load balancing method is one in which the algorithm's settings are pre-defined. For example, the
Round Robin method causes the BIG-IP system to send each incoming connection to the next available
pool member, thereby distributing connections evenly across the pool over time. This even distribution
may vary though if the static method is used in conjunction with certain other traffic behavior modifiers
that work at run time (e.g. certain profiles such as OneConnect or Persistence, and iRules).
A Dynamic load balancing method derives and adjusts its settings "on-the-fly" - while the BIG-lP
system is processing traffic. For example, the Observed load balancing method causes higher perfonning
servers to process more connections over time than lower perfonning servers.
Because each deployment of the BIG-IP system is unique, and server perfonnance depends on a number
of different factors, not the least of which is the type of applications it delivers, we recommend that you
test with different load balancing methods, and select the one that offers the best perfonnance in your
particular environment.
Adminislering BIG-IP v11 2-11

The table below summarizes just a handful of the different load balancing methods available on the BIG
IP system.
Method Description When to Use

Round Robin (Default) Each new connection request is With servers that are relatively
passed to the next server in line, evenly equal with respect to processing
distributing connections across servers. speed and memory, and
applications that have even loads
per request
Ratio A static rotation according to defined ratio With servers that are
weights for each pool member or node. disproportionate with respect to
processing speed and memory.
Specify ratio weights that are
proportional to server capacity.
Least Connections A new connection is passed to the pool Best in environments where servers
member or node that has the least number have similar capabilities. Otherwise,
of active conneQtions. some latency can occur.
Note: In this class, we will focus on the Round Robin and Ratio methods. For a complete list of
BIG-IP load balancing methods, please see the Pools section of the manual entitled BIG-IP
Local Traffic Manager: Concepts and the chapter entitled Pools.
Round Robin
Round Robin is the default load balancing method on the BIG-IP system. In Round Robin mode, each
new connection is passed to the next available
o o
pool member in succession, eventually
distributing connections evenly across the
array of pool members being load balanced, as
shown in Figure 11.
Round Robin is a static load balancing
method. In other words, no dynamic run-time
information - except pool member status - is
used in the Round Robin algorithm to select
the next pool member to load balance to.
The Round Robin load balancing method r
works well in most configurations, especially
if the servers that you are load balancing
traffic to are roughly equal in processing speed
and memory, and the applications being served
have even loads per request.
pOOl
Figure 11 ." Round Robm load balances each naw connection 10

tile nexi availabJe pool member

Chapler 2 - Traffic Processing wilh LTM 2-13
Ratio (member) and Ratio (node)

With tbe Ratio load balancing method, LTM distributes connections among pool members or nodes in a
stat ic rotation according to ratio weights that are defined for each pool member or node, as shown in
Figure 12. The number of connections that each pool member/node receives over a brief period is
proportional to the ratio weight defined for that pool member/node.
Nole: Over lime, oUlages can disrupllhe ralio dislribulion pattern.
J----D
Ratio 3 Ratio 2 Ratio 1 Ratio 1
Figure 12: Ratio load balancing method
As with round robin, ratio is a static load balancing method, and distribution is based on user-specified
ratio weights tbat are typically proportional to the capacity of the servers. No dynarrUc run-time
infonnation factors into tbe load balancing decisions BIG-lP makes with the exception of pool member
status.
Later in tills course, we'll explore the effect of node and pool member status on how the BIG-lP system
makes load balancing decisions.

Traf'fic Statistics and Logs
Lesson Objective
• Use BIG-JP's traffic statistics functionality to monitor and assess application traffic flow
• Use the BIG-IP system log as part of assessing overall application delivery and operational health
Overview of S
tatistics
An important part of successfully managing a network is having access to up-to-date information about
network performance. The BIG-IP system offers many different options for collecting, analyzing, and
viewing all sorts of network-related statistics, application statistics, performance statistics, transaction
statistics, connections statistics, throughput statistics, client-side and server-side latency, memory usage,
CPU usage, packet filter statistics, SNAT statistics, and much, much more.
In this course, we'll focus in on Module Statistics and, more specifically, Local Traffic statistics, a tool
that helps the BIG-IP administrator get a simple yet clear picture of traffic flow into and out oflocal
traffic objects such as virtual servers, pools, and nodes. Later on in this course, you'll use this same tool
to view SNAT statistics and persistence records.
Module Statistics
Module Statistics provide a tabular view of many different statistics. From the Main tab of the
Navigation pane, select Statistics» Module Statistics.
The following table summarizes the statistics available in each tab on an LTM provisioned BIG-lP:
2~affi~!>IJ_~a_ry ___~()~I!!2~~~_c
_ _______N__etw rk________ ~~!1l0ry
__ o__
(Shows by default) Availability and utilization of.. Availability and utilization of. .. "Current allocations ..
General Virtual servers Interfaces System memory
• Bits, packets, Virtual addresses Packet filters Memory pools
connections I sec Profiles summary Rate classes
• Requests Profiles - statistics Trunks

• Packet discards Pools
• Packet statistics iRules
• Traffic management Nodes
CPU usage SNATs
ICMP SNAT pools
• Packets SNAT translations

• Errors NATs
tP Persistence records
• Packets DNS Express zones
• Errors DNS cache
• Fragments

Auto Refresh
On each statistics display, you can also tum Display Options
on the Auto Refresh function to ,
automatically refresh the data on the page at Statistics Type [ Status Summ ary .3
the specified interval rate, as shown in Figure
13. Statistics can also be refreshed manually
Data Format [ Nor~l lzed 21
by clicking the Refresh button.
Auto Refresh IIDisabled vi Eefres~
Note: Short refresh intervals may impact 1'0 seconds
system performance. Local Traffic Summary 20 seconds
) 30 seconds
ObJe~[ T'lPe li'rOt31 60 seconds
Search Virtual Servers 1 i '80 seconds
, 300 seconds
A search option is also available on some of
Pools 1
the statistics pages, and allows you to fdter
the results for specific objects, as shown in Nodes 3
Figure 14. You can search either on object
name or a partition/path name. The * can be Figore 13: Statistics can be manually or automa tically refreshed
used to create a wildcard search.
Detailed Statistics Display Options
Some statistics entries include links. For StatistiCs T ypt" IV1~ual Servers vJ
example, in Figure 14, the vs_https link will
take you directly to the configuration for this
Data Format I NormalIzed .::II
virtual server. The View ... link in the Details
column expands the level of detail, providing
II Auto Refres~ Disabled -:J Reiresij
additional and more granular statistical data ~s_hlIps I~ Beset s earcij
for that object including profile statistics, and
" ~ii Status It· VoI1lJ.aI SeM'r Partrban ' Path Detalts
connection details.
I r0 CJ v< _ 1111PS Common VII"W
Clearing Statistics [ Reset )

You can clear the statistics for one or more
Figure 14: Use the searcll field to filter the search results by
local traffic objects by clicking the checkbox. object name or partition/path
to tbe left of each object ' s entry, then
clicking the Reset button. To clear statistics for all objects in tbe display, click the checkbox at the top of
the checkbox column, then click the Reset button.
On other screens, a Clear Statistics button accomplishes the same thing, as sbown in Figure 15.
Data Format
Statistical data can be viewed unrormatted or normalized . Unformatted presents the actual data value,
including all decimal places. Normalized rounds data values to the nearest whole number. An unformatted
"Bits In" value might display as 3120936; normalized, the same data value will display as 3.1 M .

Traffic summary statistics
Ok"" Options
Reset displayed
statistics to zero
lin . Paden, Conn. I s .. ~ ..,..s....
... ...... .... .......
,- ' ..........
,-
~~~ I".ur.liooq
. '" ,
• te::1JID A ~
.....
.,~
""' ,..
. 'II<
• ....
lftJiC
''''
..
lO...
""" ""' j
",,
11· ~ .
" .,"
""'" "
•.
O/\O:Ii!t- C \ll~ , !_fit
' 'lMI " ,

' ~ :.o("",,,, , ~
•
•
•
• ,•
10
0
1
....
c.cJO..c
'IV
.,... '
",
... Ss....... SU •
" ".,
1"-.. I)~ '11< u.
..
.-.:,w '- .!rI"JIf<laotJ"
~ C !)T'l' C'1ID.
Figure 15: Sample traffic summary statistics

.
•
"
The Traffic Summary page shows overall traffic rates in terms of bits, packets, and connections per
second and in total for both client side and server side traffic. It also shows packet discard stati stics which
can be useful to help identify packet drops, as shown in Figure 16. When administering the BIG-lP
system, it is important to understand the causes of packet drops. Not all packet drops are for the same
reason, and drops are not always indicative of an issue with the device; in some cases, packet drops may
be expected behavior. For example, the BIG-IP system may
intentionally drop packels in certain situations, such as when a Packet Discards
-
BIG-IP interface receives a frame containing an invalid VLAN Maint mode virtual server or
!D. However, in other instances, packet drops may indicate an controller
o
issue with the configuration or the BIG-IP system itself. For
Connection limit rea ched (virtual
example:
address)
o
• A BIG-IP interface will drop packets containing frame
Connection limit reached (\I1rtual
check sequence (FCS) errors. A high ratio of FCS errors 46
server)
may be a sign of a configuration issue. such as a duplex
mismatch. No clientside connection o
• When a packet arrives at the BIG-IP system with tbe No virtual server, NAT or SNAT
for request
38
destination IP address matching a virtual server, but
containing a non-matching service port, the packet is No available memory for
discarded. connection
o
• Packets may also be dropped if there is insuffocient
memory in which to process them or a connection limit Figure 16.· Sample packet discard
has been reached. statistics

Local traffic statistics
Oispl<ty Option5
Sl:;!tistics Type
Data Format
Auto Refresh
loc .. 1 Trilfl'ic Summilry

ObJECt TYJlE Tatal
Virtual Servers ~ SNAT Translations a D

NATs
Pools 2 I
,PerSisten ce Records o D
, DNS Express Zones
Nodes :.=I
-----J.DN5 qche
D o o
Figure 17: Sample local traffic statistics status summary page
The local traffic statistics pages contain a wealth of infonnation on local traffic objects such as virtual
servers, pools, nodes, and others, as shown in Figure 17. The Status Summary page provides a quick
view of all local traffic object types and their current status - available, unavailable, offline, or unknown.
Click on a number in the Total column to be taken directly to the list of those objects. For example, in
Figure 17, clicking on the number "2" in the Virtual Servers column takes you directly to the virtual
servers list at Local Traffic » Virtual Servers: Virtual Server List. Likewise, clicking on anyone of
the numbers in the Available, Unavailable, Offline, or Unknown columns will take you directly to a list of
those particular objects. For example, clicking on the "I" in the Available column for Pools takes you
directly to the one pool that is currently marked with a status of available.
You can filter the displayed statistics to a particular local traffic object type using the Statistics Type
pull-down. As shown in Figure 17, many different local traffic object statistics can be accessed this way.
mFigure 18, we've limited the statistics display to virtual servers only, and the resulting list can be
further filtered using the Search field, as described earlier in this chapter.
DisplOlY Options
5t:tJ~ Type IVltUal S~M!r s

-::J
Data Forrnat !.bmihzed .
~ RelrE'sh lOrs 1Jbled ,;. RIlfr8:!iiri 1
I' ~
Il::. S-, .. Vn:t.aI 'S-~ flfJni\Jllh ' P~lt,
., . hs Paclkillbi
1,0..
Co~.ctlon.
.,t.....:IrTlum
~-
R....Hb CPU UtiUndon AVII.
1~ 5'"
0
"""""
".... "" ~ Ctm:flt TtA'1l 5Sec, 1.
,...
(I 0 B3S 0 0%
0
-,os_hllp Cornman 3 !M 34 0M 411\ 5 7K
, " ir21
0%
""
~
IJ Wf_ttli:pt C"","""
""'" 11 4M 1 6K 33K
" 0 0"
'" 0%
Figure 18: Sample statistics data for virtual server local traffic objects

These traffic statistics provide useful information during problem diagnosis and can also shed light on
how the BIG-IP system is processing (and in many cases, modi tying) traffic behavior and how your
application systems are working. For additional details, click on the View ... link in the Details column to
expand statistics data for a specific object, as illustrated in Figure 19.
Di5pl ~ Options
•
IINmm""'" :;J
_ 1 ~b1!!d ... ~
Trame: Oetl.lIs e~ Plldim

T_ In Qu, In Qu, "-tun T""
1: 3 1M 3< OM , IK 5JK 39 831l
0 0 0 0 a o
~ 3 1M 3<HIM 411\ 5Th. 39 638
Syncookllt Dfiails
""'"'
""
Profil . s
S el~ct Proltie
~11!
0
SVN CooIae
Inltanc..
Si:Jft"n'aT"! SYtI CooIuE'
0 0
SYN Clc:h.
"'",," ~
• o
Software SVN Cooki.
o a -
Harctwv. SYN Cookl.
• _ _--J
Connections
o
"'o"
Es tab~ s he d
"'o "
&po.d o
,Q/:jandoned o
Miscellaneous
Rec e-i"\fed Re set
Gad C hec\...~ um D
S ~OlJ.Df Qm!.or rI
Re c eived SYN Coo ki e 0
Recerved Bad SYN Cookie 0
SYN C3Che OVerflow 0
Re LranSll1ltt1!d-Seg~ 0
Figure 19: Sample detailed vIrtual server stalist/cs

Accessing statistics from an object's configuration page

Statistics can also be accessed from within some configuration object pages. For example, if you view the
current settings for a pool, a Statistics tab appears in the menu bar area, as shown in Figure 20. Clicking
the Statistics link from within the configuration object's page will take you to the appropriate Statistics»
Module Statistics» Local Traffic page, with the Statistics Type and Search fields preset for that specitic
object.
General Propeltlel
","'"
~IUiOI'I/ Pa(t,
Conflluradon! B~
Oi.p1rt Option.
...J
l
SI35lICS-lype
();lUI FormM
Cl "1~"'pDUI Comr....D"'I 32M :n~ -4 1K 5.4K 0 o ,

Cl
•
Common 1 1M 115M l !1t( 1 r:,( 0 , ,
o ,
• - I'n lfl20 1eG
o 17?HI':'tJ~RrI a
Common
,
11M 15 4M 1 7 t~ :PlK
• -
Cl • - 112 H:J 2flJ 00 212 0 o
IEii!U
Figure 20: Accessing statistics from an object's configuration page

The BIG-IP System Log

Viewing and managing log messages are important parts of maintaining a BIG-lP system. Log messages
inform you on a regular basis of the events that are happening on the system. Some messages pertain to
general events that happen while BIG-lP is operating. Other messages pertain to events that are specific to
the BIG-IP system, such as the starting and stopping of BlG-IP system services.
The BlG-lP system automatically logs four main event types, as shown in the table below. Each type of
event is stored in a separate log file, and the information stored in each Jog file varies depending on the
event type and other configuration settings. All log files for these event types are stored in the directory
Ivar/log.
--- - -- - - - - - - _._ --- _ .._- -
. Event Type Description Examples ____;;.-
LO9 File Name
System Based on Linux events, and • BIG-IP startup Ivar/log/messages
are not specific to the BlG-tP • BIG-IP shutdown
system and software.
Packet fitter Result from implementation of Ivar/log/pktfilter
packet filters and packet filter
rules
Local traffic Pertain specifically to the local • Traffic object is enabled or Ivar/log/ltm
traffic manager (LTM) disabled
• Connection limit is reached
Audit Result from authorization or • Failed login attempt Ivar/log/audit
c~ rt"in ~ecu ~ity_~v_ent~
The Configuration utility is often used to set up and view logging data, as it provides column-level sorting
functions and search fiJtering capabilities. From the Navigation pane, select System» Logs, then choose
one of the options shown above, or select Configuration:Options to configure Jogging options.
Note: Logs are covered in more detail in the Troubleshooting section of this class.

Chapter Resources

SOL8082 Overview of TCP connection setup for BIG-IP LTM virtual server types
SOL7595 Overview of IP forwarding virtual servers
SOL 13452 Configuring a virtual' server to ser:ve multiple HTTPS sites using TLS Server Name
Indication feature
SOL 14687 Configuring virtual servers to share the same virtual address across multiple
partitions
SOL 13575 Configuring a BIG-IP virtual server with message-based load balancing profile
SOL 10516 Overview of BIG-IP pool status
SOL 10430 Causes of uneven traffic distribution across BIG-IP pool members
SOL7065 Configuring the BIG-IP system to use an alternate server if pool members are
unavailable
SOL 1331 0 ~bling nodes or pool members fo ~ ainte n a nce

Lab 2.1 - Virtual Servers and Pools Lab
Objectives:
• Configure pools for virtual servers
• Configure virtual servers and associate them with a pool
• VerifY functionality
Estimated time for completion: 20 minutes
Lab Requirements:
• Administrative access to a BIG-IP LTM system
• IP and port addresses available for use on BIG-IP LTM that can be reached by the client systems
• Actual servers with appropriate routes to return traffic through each BlG-IP LTM system
Note: When asked to "refresh" a browser window throughout the labs in this course, we
recommend a hard refresh (a.k.a. hard reload). On most PC browsers, hold down Ctrl and
press F5. You can also change your browser preferences to avoid caching altogether, or refer to
the Wikipedia article, Bypass your cache, for instructions for various browsers.
Create a Pool
1. Create a Pool using the information in the following table.
Resources section :
Address:Port 172,16,20,1 :80 Ratio: 1 Click Add

New Members Address:Port 172,16,20,2:80 Ratio: 2 Click Add
Address:Port 172.16.20.3:80 Ratio: 3 Click Add
When complete, click ... Finished
2. Navigate to Local Traffic »Nodes and notice that tbe BIG-IP system automatically created three
new node entries as the result of you creating the three pool members in the previous step.

Create a Virtual Server

3. Create a Virtual Server that uses the pool created in the previous step.
Resources section:
When complete. click...
Test Your Configuration Changes

Connect to virtual server vs_hHp (10.1 0.X.1 00:80)
4. Verify that your virtual server is configured correctly by accessing it as an application user. Open
anotber web browser window and establish a connection to your virtual server at
http://IO.IO.X.IOO. Note the results of the page that is displayed, then "hard-refresh" the page
five to ten times. (In most browsers Ctrl+FS hard-refreshes the page.)
5. Verify that !raJlic was sent througb your virtual server and pool members by examining statistics
on Local TraJlic and answering the questions below in the space provided. Hint: Use the Refresh
and Reset buttons in the Display Options area to manage the statistics display.
DiSplay Options section
connections between the pool members

1."2:3?

Expected results and troubleshooting

Depending on what browser you're using, you should see five or six connections per refresh, distributed
among the pool members in approximately a 1:2:3 ratio over time. For example:
172.16.20.1:80 has 3 connections
172.1 6.20.2:80 has 6 connections
172.16.20.3 :80 has 9 connections
If not, verify the following:
• Is traffic getting to the virtual server?
Does the Configuration utility Statistics page show traffic received by vs_http? Verify that
the address and port are configured correctly for this virtual server. It should be 10.1 O.x.l 00,
port 80 (or HTTP).
Does 10.1 0.x.1 00 appear in your workstation's ARP table? Open the Windows Run dialog
box. (Press the keyboard shortcut combination .. W" ~ - Windows icon key plus the letter
R.) Type cmd. exe to open the Windows command line interface. Type arp -a and examine
the results to see if you connected with the virtual server on Local Traffic Manager.
• Is traffic getting to the pool members?
lfno traffic is going TO the pool members, verify httpyool has been assigned to vs_http.
Verify that pool members have the correct IP address and port assigned.
If traffic goes TO a pool member but does not return, verify self IP and VLAN
configurations. (See the instructor, if necessary.)
Create a Second Pool and Virtual Server

Next, you will create a second virtual server with same IP address (10.1 0.x.1 00) as the virtual server you
created previously. The port and the load balancing method, however, will be different (443 instead of80,
and round robin instead of ratio).
Additionally, this time you will create the pool for your virtual server "on the fly." That is, when you
click the "+" button next to Default Pool on the New Virtual Server page, you'll be directed temporarily
to the New Pool page. When you add the members to the pool, you'll click the Node List radio button to
bring up a list of the nodes already defined on the BIG-IP system and select from the resulting list to add
members to this new pool.
After you create the new pool, you will be returned to the New Virtual Server page where you can
complete your virtual server configuration.

6. Create another virtual server and pool.
Type: Host
Address: 10.1 0.X.1 00
Resources seclJon :
New POIlI screen Configuration section
Resources section (on "New Pool"screen)
Click Node List and use the resulting pull-down to

select the nodes to add to the member list:
New Members Address: 172.16.20.1 Service Port : 443 Click Add
Address: 172.16.20.2 Service Port: 443 Click Add
Address: 172.16.20.3 Service Port: 443 Click Add
Finished (This will return you to the New Virtual Server
When complete. click ...
Resources section (back on the "New Virtual Server'" screen)
Adm inistering BIG-IP v11 2-25

Test Your Configuration Changes

Note: When driving traffic to your virtual servers during testing, make sure that you are
connected to the correct one: http://10.10X100 for virtual 10.1 OX1 00:80
and https:1!10.10X100 for virtual 10.1 OX1 00:443.
Connect to virtual server vs_https (10.10.X.100:443)

If you cannot connect to your virtual server in the next step, con finn that it was actuaJ1y created. (Go to
Local Traffic » Virtual Servers in the Configuration utility.) Students frequently fail to click the Finish
button on the New Virtual Server screen after clicking the Finish button on the New Pool screen.
7. Open a new web browser window and establish a connection to your new virtual server at
https:1I10.10.X.I00. Ifprompted, accept the self-signed SSL certificate. Note the results oflhe
page that is displayed. Refresh the screen several times using Ctrl+FS.
Verify traffic flow via Configuration utility statistics

8. View statistics and confIguration information to confirm traffic and answer the questions in the
table below:
Display Options section
How many TCP connections are each time you

hard-refresh the browser 0.10.1.100?
Verify traffic flow via tmsh statistics

9. Using PuTTY, open an SSH session to your BIG-lP at either the management IP address
(l92.168X31) or at the external non-floating self-IP (10.1 OX31).
10. At the login prompt, enter the root user credentials you set up in the first lab.
I I. Back on your browser window connected to https:IIIO.IO.X.IOO, hard-refresh the page once
using CtrI+FS.
12. On your SSH window, view pool and virtual server statistics by entering the following commands
at the config# prompt:
tmsh show /ltm pool https-pool Imore
tmsh show /ltm virtual vs_https Imore

13. Compare the statistics shown via tmsh to those currently shown on the Configuration utility. The
tmsh statistics should show additional traffic statistics.

Depending on the browser you are using, you should see about six connections for each connection
refresh to vs_https. Also, each pool member in httpsyool should be getting approximately the same
number of connections each time. The total number of connections should also be approximately the same
for each pool member due to the Round Robin setting.
If you are not seeing the results expected via statistics:
• Is traffic getting to the virtual server?
Do statistics show traffic received by vs_https? Verify that the address and port are
confIgured correctly for this virtual server. It should be 10.1 O.X.I 00, port 443 (or HTTPS).
Docs 10. 1O.X.J 00 appear in your workstation' s ARP table? Open the Windows Run dialog
-
box. (Press the keyboard shortcut combination I", Win h~ Windows icon key plus the letter
R.) Enter cmd. exe to open the Windows command line interface. Enter arp -a and
examine the results to see if you connected with the virtual server on BIG-lP. You may need
to clear your ARP cache before testing to remove the entry from the vs_http virtual server.
Enter netsh interface ip delete arpcache on the Windows command line interface
screen (not the PuTTY command line screen).
• Is traffic getting to the pool members?
lfno traffic is going TO the pool members, verify httpsyool has been assigned to vs_https.
Verify the pool members have the correct lP address and port assigned.
If traffic goes TO a pool member but does not return, verify selflP and VLAN
configurations. (See the instructor, if necessary.)
You may stop here or continue with optional Lab 2.2: Packet Discard Lab

Lab 2.2 - Packet Discards Lab (Optional)
Objectives:
• Generate situations that can cause the BIG-IP system to drop packets and view the results in
Module Statistics
Estimated time for completion: 5 minutes
Even though this lab introduces specific configuration settings that have not been discussed yet, they
allow you to further explore general traffic statistics and to see how the BIG-JP system functions as a
default deny device.
Lab Requirements:
• Existing virtual server vs_http at IO.1O.X.lOO:80
Generate Packet Discard Statistics

I. Open a browser session to your BIG-IP system, and clear the Traflic Summary statistics by
navigating to Statistics» Module Statistics» Traflic Summary » General, and clicking the
Clear Statistics button.
2. Manually disable virtual server vs_http.
3. Open a new browser window and try to connect to virtual server vs_http at http://IO.IO.X.IOO.
Your request should fail as the virtual server is no longer able to receive traffic. What are the
symptoms, as seen from the application user's perspective?
4. Back on your BIG-IP system, navigate to Statistics» Module Statistics» Traflic Summary»
General, and refresh Traflic Summary statistics by clicking the Refresh button.
S. Scroll down to the Packet Discards section and view the statistics shown there. Were packets
discarded? What reason does the BIG-IP system indicate for the discards?
6. Clear the Traflic Summary: General statistics again by clicking the Clear Statistics button.
7. Try connecting to your other virtual server, vs_https, at https:IIIO.IO.X.IOO. Are you successful?
2-28 Admlntstering BIG-IP v11

8. Enable virtual server vs_http again but set its connection limit to a maximum of 1. This will
require you to change the Configuration section view from Basic to Advanced.
Configuration section (Change Configuration: Basic to Configuration: Advanced)
9. On your browser session to http://IO.IO.X.IOO, hard refresh the page five to ten times (Ctrl+FS).
Did you connect to the virtual server? Were there any problems?
10. Back on your BIG-IP system, navigate to Statistics» Module Statistics» Traffic Summary»
General, and refresh Traffic Summary statistics by clicking the Refresh button.
11. Scroll down to the Packet Discards section and view the statistics shown there. Were packets
discarded? What reason(s) does the BIG-IP system indicate for these discards?

When you disabled vs_http, client packets destined for 10. IO.X. 100 are still directed to tbe BIG-IP system
by virtue of the lP address. (BIG-IP responds to ARPs for tbese addresses as tbey are contained in its
virtual address list.) However, once the packet reachcs the BIG-IP system, there is no listener available
at the IP address and port combination (10.1 O.X.l 00:80) as the virtual server has been disabled. The result
is the packets are discarded. Once you re-enable the virtual server, it is capable of listening for and
processing traffic again.
When you set the connection limit on vs_http to one (I) though, another problem was created. This
setting causes the BIG-lP system to limit the number of concurrent connections to the virtual server to tbe
value specified. Because our request to access http://lO.IO.X.IOO results in several HTTP GET requests
for the parts of the web application that comprise the page - HTML, GIFs, lPGs, etc. - some of those
requests can cause the need for more tban one connection to the virtual server at a time. Since the limit is
set to 1, only 1 connection at a time is permitted. Tberefore, some of the requests will be discarded
resulting in a web page that is only partially delivered, ifat all.
Clean-up after lab

12. Set tbe connection limit for vs_http back to 0 (zero), indicating no limit on connections, tben set
the Configuration view from Advanced back to Basic before saving your cbanges. Conftrrn that
the application is functioning properly again.
STOP

" (I P'" Sfr--rCC lP !.9~ h..Ctjfl- '>r

tM1f ~f) f-I,JI ",t'c('t-!(h',L- '!"r-I.;J
2-30 Ad mlntstertng
' BIG-IP vll
Chapter 3 - Using NATs and SNATs 3-1
Chapter 3: Using NATs and SNATs

Chapter Objectives
At the end of this chapter, you should be able to compare and contrast NATs and SNATs, describe how
they listen for traffic, how they perform address translation, and how they are typically used in the BIG-IP
environment.
Address Translation on the BIG-IP System

Earlier in this course, we introduced you to the concept of a standard host virtual server on the B1G-1P
system, how a virtual server listens for certain types of traffic, and how it translates the destination LP
address on request packets and the source LP address on response packets.
Therc are two other configuration objects on the B1G-1P system that can also be used to listen for and
process traffic: NATs and SNATs. Each of these three objects - virtual servers, NATs, and SNATs
perform address translation as part of processing traffic, as shown in Figure 1. However, the address
translation is different with each and, more importantly, each object provides unique functionality that can
help address specific or wide-ranging issues, as we'll explore in this chapter.
172.16.20.1
O ?O (11) 1 100 80
Vinua l Server
(one-to-ma ny)
!~====~
..... -t;'Or. Destination: ~~ilic.1
172.16 .20180
172 16 20 2.S0 or
172 1520 .3'80
Source: BI-DIREC110NAl Source:
O
207.10.1.103 172.16.20.3 172.16.20.3
-.'
~ ....-.-......
Destination:
NAT (one-to-o ne)
Destination:
207.10.1.103 172.16.20.3
.... , _fO;;
Source:
__~~~__~~~1~7~2~.1:6~.2~0:/2:4~~17121·1C6J.21°11
·1
o
Source:
207.10.1.101:pOl1 1 SNAT
172.16.20.2
172.16.20.3
..... - t 5
Figure 1: Examples of address franslation objects on the BIG-IP system: virtual server, NA T, and SNA T

3-2 Chapter 3 - Using NATs and SNATs
NAT Concepts
Lesson Objectives
• Describe what a NAT is and how it is sometimes used in the BlG-lP environment
Introduction to NATs
In some cases, you might want to allow a client on an external network to send a request directly to a
specific internal node, bypassing the normal B1G-1P LTM load balancing methods upon which server
selection is typically made. To connect directly to an internal node, a client would need to know that
node's lP address. However, since such addresses are typically private (i.e. non-publicly routable RFC
1918), some sort of translation mechanism is needed.
A NAT is a feature of BlG-IP Local Traffic Manager that provides a one-to-one mapping between two lP
addresses, such as between an internal, non-publicly roulable lP address and an external, publicly roulable
address, as shown in Figure 2, so that:
• When an external node sends traffic to the public lP address defined in the NA T, the BIG-IP
system automatically translates that destination address to the associated private lP address that
represents a specific node on the internal network.
• When an internal node initiates traffic to an external network, its private IP address is hidden
from the external network.
In other words, a NAT provides a routable address for sending packets directly to or from a node that has
a private class lP address. NA Ts can also be used to hide publicly roulable lP addresses for security
reasons.
When you create a NAT, you can map only lP address to another lP address (for example, private lP to
public lP), hence the term one-to-one mapping (see Figure 2.) l[you want to map more than one lP
address (e.g. multiple internal nodes) to a single lP address (e.g. a publicly routable IP), you would create
a SNA T instead, as we'll discuss later in this chapter.
Source: BI-DIREC110NAL Source:
O
207101 103 172.16.20.3 172.16.20.3
---· -· --.
Destinat·ion: liNiAiTi(oiniei-tioi-Oiniei)r~~~~;;
Destination:
207.10 .1.103 172.16.20.3
.•... - fS
Figure 2: A NA T can be used to provide a one-to-one, bi-direclionaf mapping between a private class IP address and
a pubt/cfy routable IP address
The BIG-IP system can apply a NAT to either an inbound or an outbound connection.

Note: NATs do not support port translation, and are not appropriate for protocols that embed IP
addresses in the packet, such as FTP, NT Domain, or CORBA IIOP.
Tip: When you use a NAT to provide access to an internal node, all ports on that internal node
are open. This can present a security risk that can be mitigated by using a SNAT instead.
NAT Traffic Flow on an Inbound Connection

Witb respect to NATs, an inbound connection is one tbat is initiated by a node on an external network,
and comes into tbe BIG-lP system to tbe lP addrcss specified by tbe NAT. The final destination is
actually a node on tbe internal network.
Review of traffic flow without a NAT

As you learned earlier in tbis course, load balanced traffic typically flows tbrough the BIG-lP system in
the following way:
I. A client on an external network sends traffic to a virtual server on tbe BIG-IP system. The
destination lP address is the virtual server address, and the virtual server is typically listening on a
particular port.
2. Upon receiving a packet, the virtual server makes a load balancing decision, and then translates
the destination lP addrcss to thc lP address of a pool member it selected.
3. Tbe pool member sends its response back tbrough tbe BIG-IP system. While processing the
response, the BIG-IP system performs the reverse translation, changing the source address in thc
packet from the pool member's lP address to the virtual server's lP address, which is the source
address the client expects to see.
This typical load balancing scenario ensures that, for load balanced traffic, the client never sees the
internal private class IP address of an internal node.
Traffic flow with a NAT

If you want an external client to be able to send packets directly to a specific node on an internal network,
the client needs a routable lP address for that node. A NAT on tbe BIG-IP system provides a solution to
this problem by mapping a publicly routable address to a private (non-publicly-routable) address. Traffic
flow is described below:
l. A client on an external network sends traffic to a NAT on the BIG-lP system. The destination lP
address on the packet is the NAT address. Unlike a virtual server though, a NAT is listening for
any and all ports on a given lP address.
2. Upon receiving a packet, the NAT translates the destination lP address to the private class lP
address of the node it is mapped to (i.e. the origin address). No load balancing or port translation
occurs, unlike a virtual server.
3. The node sends its response back tbrough the BIG-IP system where the reverse translation is
performed. Tbe source address in the packet is changed from the node's lP address to the NAT lP
address, wbich is tbe source address the client expects to see in tbe response. Tbis is similar to tbe
reverse translation behavior of tbe virtual server, except that no port translation occurs.

EXTERNAL INTERNAL
NElW ORK NETWORK
Client
Node
NAT Origin
172.16.20.3
D -~ Address
207.10.1 .103
Ad dress
172.16.20.3
Destination: NAT
Destination:
207.10 .1.103 172.1 6.20 .3
tlH ffHl :- <. f.'i
FlgUlli 3: Inbound conn ection traffic flaw from an extarn al client 10 a publicfy-routabJe NA T on the BIG, IP system, .and
addrass lransla tion to the p nvafo class IP add(1jss of an in ternal node
As shown in Figure 3, a client on the external network needs to directly access a node on the internal
network (without load balancing involved). The node has a private class JP address of 172.16.20.3. You
can create a NAT with a public destination address of your choice (the NAT address; here we've used
207.10.1.103) and map it to the private class address 172.16.20.3 (the origin address). Whenever a client
on the external network initiates a connection to the NAT address - 207.10. I. I03 and any port - the BIG
IP system translates that NAT address to the origin address - 172.16.20.3 - and passes the packet along to
the internal node at that address for processing.
NAT Traffic Flow on an Outbound Connection

Sometimes, an internal network node might need to initiate an outbound connection to an external
network node, rather than simply respond to a client request. If the path of that connection takes it through
a BIG-JP system - for example, if the BIG-JP system was configured as the node's default gateway - there
has to be some sort of listener object on the BIG-JP system that can pick up and process the traffic.
Remember, the BIG-IP system operates as a default deny device and, without a listener, the traffic will
simply be dropped. Also, if the internal node has a private class IP address, tbat address will need to be
translated before sending out on a publicly routable network so that the response can find its way back.
As with the inbound NAT example, some sort of listening and translating mechanism is in order, and a
NAT provides a potential solution.
As shown in Figure 4, suppose an internal node (such as a mail server) has a private class IP address of
172. I 6.20.1. You can create a NAT designed to translate the origin address 172. I 6.20. I to a public source
address of your choice (such as 207.1O.l.lOl). Whenever the internal node 172.16.20.1 initiates a
connection destined for a node on the external network, the NAT translates the source JP address in the
packet from the origin address of 172.16.20.1 to the publicly routable NAT address of207.1O. 1.1 01. The
response from the external node will be destined for the NAT address 207. lO. l.J 01. The NAT then
translates the response packet destination IP address to the internal node address 172. 16.20. I.

EXTERNAL INTERNAL
NE1WO RK NETW ORK
r
NAT
Address
207 .10.1.101
"Origin
Add ress
172.16.20.1
Node
172.16.20.1
Source: NAT
Source :
207.10. 1.10 1
tlH fHtI _ =- ,> f5
172. 16 .20.1
Figure 4: Ou~bou nd connection lrafflc now fro m ,m ;nternaf node to en axtema{ nOde through a NA T on the BIG-IP
system, and address trans/ation of the ongin address to the publicly routable NA T addross.
NAT Drawbacks
When you use a NAT to provide access to an internal node, all ports on that internal node are open. In
other words, the NAT will accept traffic for any service port so long as tbe destination lP address on the
packet matches the NAT address. To mitigate this security risk, many administrators opt to use a SNAT
instead, as you'll see later in this chapter.
Also, since it is a one-to-one mapping of lP addresses, in the case where many internal nodes with private
IP addresses need publicly routable addresses in order to connect to external networks, a separate NAT
would have to be configured for each internal node. This can create significant administrative overhead as
well as quickly use up already depleted publicly routable IPv4 addresses. Also, since NATs are bi
directional listeners, there is a potential security risk. In the outbound NAT example above, the desired
result was to provide internal nodes with tbe ability to initiate traffic to external nodes. However, an
external clients could also initiate traffic to the same NAT (via the NAT address), thereby giving them a
direct connection to an internal node on 0/1 service ports. Again, SNATs provide a far less risky option
with significantly less overhead.
Lastly, the BIG-IP system does not track NAT connections. Therefore, the public IP address that you
define in a NAT cannot be the same address as a virtual server address or a SNAT address.
As a result, NAT use in the BIG-IP environment is relatively uncommon.

SNAT Concepts
------------------------------------
Lesson Objectives
• Describe what a SNAT is and how it is commonly used in the BIG-lP environment
• Compare and contrast SNAT Auto Map and SNAT Pool, and identify use cases for each
Understanding SNATs
SNAT - source network address translation or secure network address translation (both are correct)
- is roughly equivalent to a form of NAT known as network address and port translation (NAPT) or Port
Address Translation (PAT). While a basic NAT is a one-to-one translation mapping - one source lP
address translated to a different source lP address - a SNAT typically provides a many-to-one address
translation mapping, as illustrated in Figure 5.
Source:
172. 16.20/:2!4_ t 1. 7.2.:S
.1:::l.•20• .•1
o
Source: 172.1S.20.2
207.10.1.101:port
SNAT
(many-to-ona)
172.16.20.3
Figure 5: SNAT can be used to translate multiple source IP addresses - such as Intemal private IP addresses - to a
different source address - such as to a pubficly routable address
There are many uses for SNAT in a BIG-lP network configuration. For example, SNAT can provide a
secure mechanism for translating internal, non-publicly-routable addresses into publicly routable
addresses. Unlike NAT, which requires a separate publicly-routable address for each internal host, SNAT
allows a single publicly-routable IP address to be used by many hosts on an internal, private network.
This translation method allows you to conserve addresses in the publicly-routable address space, with port
translation providing the necessary uniqueness. Also, unlike NAT, SNATs are secure in tbat tbey arc
unidirectional: they only listen for traffic sourced/rom a specified origin address, not destined to the
SNA T address.
SNAT's are commonly used in the BIG-lP environment to belp deal with routing complexities, and it is
this aspect of SNAT tbat we will explore throughout tbe remainder of this chapter.
Virtual server address translation and routing considerations

The typical client-initiated request scenario we've seen in class to date involves two connections - one
from the client to a virtual server on the BIG-IP system; the other from the BIG-IP system to a pool
member in a load balanced pool. On the inbound client-side connection, the destination lP address is the
virtual server's lP address; on the inbound server-side connection, the destination IP address is that of the
pool member. The pool members response returns to the client through the BIG-IP system, thereby

reversing the original destination IP address translation, as shown in Figure 6. In fact, the success of this
whole transaction relies integrally on the translation reversal occWTing.
Client Vlrrual Se<Ver Client Pool Member
10.10.1.30:2181 10.10.1 .100.80 10.10.1.30:2181 172 16.20 180
Client
10.10.1.30 Pool Member
o ..... - I~
172.16.20,1:80
DeSlination Destination
Clienl Virtuai Servor Client Pool Member
10.10.1.30:2181 10 10 1 100:80 10.10.1.30:2181 172.16,20 1:80
Figure 6: Destination JP addross translation on a standard host virtual Stuver
The server respoose to a client-initiated connection will be returned to the client through the BIG-IP
system in the following typical network configuration:
• The server nodes are on the same subnet as the BIG-IP system.
• The client nodes are on a different suboet from the server nodes.
• The BIG-IP system is the default gateway for the server subnet.
But what if the network configuration is atypical, such that the required return path through the BIG-IP
system is not used? What if the clients aod servers are on the same network? What if the default gateway
of the server node is not the BIG-IP system? Let 's take a look at these situations to see how a SNA T
might help. But first, a brief look at how a SNA T works.
How Does SNAT Work?

A SNAT consists of three basic elements:
• What source address will be translated? (a.k.a. origin addresses)
• What will these addresses be translated to? (a.k.a. translation address)
• Where is the SNA T li stening?
At a high level, a SNAT works in the following manner:
I. The BIG-IP system receives a request from a client and verifies whether the source IP address is
defmed in the origin address list for a SNAT. As with virtual servers, an order of specificity
applies.
Administering BIG-IP vII 3-7

2. [fthe client's IP address is defined in the origin address list, the BlG-lP system translates the
source IP address to a translation address defined in the SNAT. The translation address is an lP
addressed defmed on the BIG-lP device. The source port may also be translated.
3. The BIG-IP system then sends the client request to the pool member or other destination.
4. The response is returned to the BIG-IP system by virtue of the updated source IP address on the
request.
5. The BIG-lP system reverses the source address translation, restoring the original source IP
address, and sends the response to the client.
Common Reasons for Using SNAT

Default gateway is not the BIG-IP system
A common use for SNAT is when the default gateway of a node (server) is not the BIG-lP system.
Sometimes a node's default route cannot be the BIG-IP system. This can prevent the client from getting a
response if the request flows through a virtual server on the BIG-IP system to start with, as illustrated in
Figure 7.
Without a SNAT, the response to the client-initiated request will come directly from the pool member.
The message may never route properly under these circumstances but, even if it did, the client would
reject the response as the client has no connection with the pool member, only with the virtual server.
10.10.1.30 10.10.1.100 10.10 .1 .30 172.16.20.1
10.10.1.30
D ~-
Nodes' default gateway
10.1 0.1.30 172.16.20.1
Figure 7: Without SNAT, routing issues can occur, for exampJe, If a node 's default gateway is not the 8IG-JP system

With a SNA T, both the destination lP address and the source LP address are changed : the destination by
the virtual server and tbe source by the SNA T, as illustrated in Figure 8. From tbe pool member' s
perspective, the request originated on the BIG-IP system and so the response will be returned there. Tben
the BlG-LP system can reverse the original inbound translation, cbanging both the source and destination
IP addresses using the virtual server and SNAT respectively.
10.10.1.30 10.10.1.100 SNAT 172.16.20.1
SNAT
10.10.1.30
0 .... '-'" - fS 172.16.20.1
Nodes' default galeway
10.10.1 .30 10.10.1.100 SNAT 172.16.20.1

Figure B: SNAT ensures a node's response is sent back through the BtG-/P system

Clients and servers are on the same network

If you want to process traffic destined to server nodes that are on the same subnet as the client nodes, you
can use a SNA T so that server responses are sent back via the 8IG-JP system. As with the previous
example, without a SNA T everything looks good until the internal server sends its response . Since both
client and server are on tbe same suboet, there is no need to send the response back via the BIG-IP
system; it can be sent directl y to the client. The client is not expecting tbe response to come directl y from
the server, so it will reject it, as illustrated in Figure 9.
172.16.1.30
D ...-=-----'---~
Figure 9: If client and server oro on the same subnet, the response from the pool member does not route back
through the BIG·IP system and failures occur
SNAT causes the BIG-JP system to change the source IP in the message, and the server' s response will be
sent back via the 8IG·JP system, as shown in Figure 10.
SNAT
172.16.20.1
Figure 10: SNAT ensures the response is routed back through the BIG· IP system

Chapler 3 - Using NATs and SNATs 3-11
Internal clients with private IPs need to share one outbound Internet connection
Here's another example of how a SNAT might be used in the BIG-I P e nvironment. Internal clients often
have private IP addresses that cannot be routed on the Internet (i.e. publicly-routable). Nor do companies
have limitless resources for connecting devices directly to the Internet. When an internal c lient initiates a
connection to an externa l host, a SNAT ensures that tbe LP add ress of the internal client remains hidden to
the externa l bost, and that the request is ro uted through a single, publicly-routable address, as illustrated
in Figure J1. The externa l bast can then use th is public address when sending the response.
A SNAT for an outgoi ng connection works in the following way:
1. BIG-LP receives a packet from an interna l server
2. B1G-IP checks to see if that source LP address is defined in a SNAT.lfit is, BIG-IP cbanges the
source LP address in the packet to the !Tanslation address in the SNAT.
3. BIG-IP sends the packet with the SNAT translated address to the destination external server node.
What are we
What
translating
addresses are
them to?
we translating?
172.16.20 .1
Translation Origin
Address Addresses
207.10.1.102 172.16.20.0/24
SNAT
o Source:
207.10.1.102:3155
Source:
172.16.20.3:3155
Figure 1,. SNAT can be used to affow mulliple internaf, pnvate clients to share a single publicly routable IP address

SNAT and Port Exhaustion

Up until now, we've focused mostly on tbe IP address translation that occurs with SNAT. But remember
that SNAT is a form of address translation that includes both the network address and the port (same as
NAPT and PAT). When a SNAT is configured on a BIG-IP virtual server, the source address of each
connection is translated to a configured SNAT address (such as a selfIP in the case of Auto Map or a
SNA T pool address in the case of SNAT pool), and the source port is mapped to a port currently available
for that address. By default, the BIG-IP system attempts to preserve the source port, but, under certain
conditions, if the port is already in use on the selected translation address, thc system also translates the
source port.
Note: Starting in BIG-IP 9.6.1 and 10.0.0, it is possible to control, on a per-virtual-server basis,
whether the system should preserve the client's source port. For more information, refer to
SOL 11003: Configuring source port preservation for virtual servers.
Socket pairs
Each SNAT address, like any IP address, has only 65,536 ports available. This is a limit ofthe TCP and
UDP protocols (not a limit ofSNAT), since each uses a 16-bit unsigned integer (2 16 = 65,536) to specify
the source and destination ports in their respective headers. However, each SNAT address can potentially
process more than 65,536 concurrent connections so long as each socket pair is unique. A socket pair
consists of the following elements:
• Source IP address
• Source port
• Destination IP address
• Destination port
A given SNA T address can keep using the same source port as long as tbe remote socket (destination
address:port) is unique, thus allowing the SNAT address to process more than 65,536 concurrent
connections. The table below shows how the same SNAT IP translation address and port combination
could be used by the BIG-IP system to connect with different remote socket combinations:
SNAT Translation Address:Port Destination Address:Port
172.16.1.33: 1234 172.16.20.1 :80
172.16.1.33: 1234 172.16.20.2:80
172.16.1.33:1234 172.16.20.1 :443
172.16.1.33:1234 172.16.20.2:443
SNAT on a virtual server with load balancing

When SNAT is used in conjunction with a virtual server that load balances connections to a pool, the
destination is changed from the virtual server IP address and port to that of the chosen pool member.
Therefore, assuming a specific SNAT address is configured on only one virtual server, the SNAT address
is able to process approximately 65,536 connections for each pool member in the pool.
While tbe uniqueness of remote sockets depends entirely on your specific configuration and trartlc, for
simplicity you can think of65,536 concurrent connections as the maximum capacity for any given SNAT
address. If you think you will need to support more than 65 ,536 concurrent connections, you should
configure more SNA T addresses either in tbe SNAT pool or as self IPs on the appropriate egress VLANs.

Monitoring SNAT Pools

You may be able to detennine wi,en SNAT port exhaustion is occurring by reviewing tbe system log
files. When port exbaustion occurs, error messages that appear similar to the following examples are
logged to the Ivar/log/ltm file:
01010201:2: I net port exhaustion on 10.1.21.26 to 172.28.21.71:53 (proto 17)
01010201:2: Inet port exhaustion on 10.10.10.211 co 172.28 .21. 123:80 (proto 6)
Nole: The previous error messages are not specific to SNAT port exhaustion, and may be
logged whenever TMM detects port exhauslion for a traffic management object.
If you believe SNAT port exhaustion may be occurring, you can monitor the number of concurrent
connections going through the SNAT, as shown in Figure 12. In the Configuration utility, navigate
to Overview » Statistics » Local Traffic and for Statistics Type, select SNATs, SNAT Pools, or SNAT
Translations in the drop-down menu.
Display OpUons
stallstlcs Type ISNAT Translalions ~
Data Fonnat [Ncl~~tlZed y
Auto Rertesh I Disabled .:: IRerteshl
Ils.orchl Bits 'Ickets

A SNAT Trll1. llItlons PortItlon I PlIth stot. In 00A In OIA Curronl Total
10.1 04.150 Common Enabled a a a 0 0 0 0

172.16.4 150 Common Enabled 3.1M 7 .0M 4 .4K 3.5K 0 13 573
Figure 12: Sample SNA T pool statistics

Configuring SNATs
SNA Ts can be configured in many ways to address a variety of network configurations and routing issues
- more than just the three examples presented earlier. When you create a SNAT, you map an original LP
address to a translation address in one of several ways, depending on your needs.
SNAT on a virtual server

When a virtual server is configured with a Source Address Translation (SNAT) option, the source
address of incoming traffic to that virtual server will be translated to a translation address on the egress
VLAN, as specified in the SNAT configuration. The translation address selected depends on whether or
not you are using Auto Map or SNAT Pool, and what the egress VLAN is.
Note: In this course, we will be limiting our discussion to the use of the SNAT Auto Map and
SNAT Pools on a virtual server. For more information on other types and uses of SNATs, please
take the Configuring BIG-IP Local Traffic Manager (L TM) course or see BIG-IP Local Traffic
Manager: Concepts (manual) or S0L7820: Overview of SNA T features .
10.10.1 .30
o Origin addresses?
Clients that connect
to the virtual server
Translated address?
IP address :port
on egress VLAN
Derault Listening where?

gateway On the virtual server
172.16.20. 1 172.16.20.2 172.16.20.3
SNAT Impact on Server Applications

When SNAT is used to translate the source LP address (and potentially port) of the incoming packet to the
SNAT address, the application servers that eventually receive that packet for processing will see the
request as originating from the SNAT address, not the original client lP add ress. If an application server is
required to log the Original client IP address for requests, this translation behavior can prove problematic.
Note: For techniques you can use to address this issue, see SOL4816: Using the X-Forwarded
For HTTP header to preserve the original client IP address for traffic translated by a SNA T.

SNAT Auto Map
Lesson Objectives
At the end of this lesson, you sho uld be able to:
• IdentifY which IP addresses will be used for SNAT Auto Map
• Configure a virtual server on the BIG-IP system to use SNA T Auto Map
• Describe the source address translation process used by the BIG-IP system when SNAT Auto
Map is configured
Understanding SNAT Auto Map

Of the available SNAT types, Auto Map is frequently used as it is simple to configure and maintain , and
helps conserve IP addresses by using BIG-LP's existing self LP addresses. Auto Map Source Address
Translation can be used in a variety of different ways but it is often configured directly on a virtual server.
During traffic processing, BIG-IP prefers using the floating self LP address On the egress VLAN as the LP
address for SNAT Auto Map. Back to our asymmetrical routing example, on the inbound server side
connection, tbe BIG-IP system will translate the source address from the client's LP address to the floating
self LP address on the server side's VLAN (the egress VLAN). In our classroom lab environment, that
VLAN's name is internal and its floating self LP address is in the format I 72.16.x.33, as illustrated in the
example in Figure 13. Floating self LP addresses on an egress VLAN are preferred over non-floating LP
addresses to prevent interruptions in service in the event of a failover .
D 10 rD
r~6 twork I> ~lItr tPi
.0.. s.lt IP 1.rs1

---- VLAN external
10.10116
Ih,s direction: lU.1U.4.JI~
[] ' 0 ' 04 .31
[] 10104.33 Traffic exibng Ihis direclion: 172.16.4.33
[] 172.16.4.31 VlAN internal
[] 172.16.4.33 172.16/16
172.16.20 I 1n.1620 2 172.16.20.3

Figure 13.· When Auto Map is conffgured. BIG·IP generally seleels Ihe floating self IP address on the egress VLAN

Configuring a virtual server with SNAT Auto Map
Ceneral Properties
Name
Partition I Path Common
Oescriptlon [
Type Standard
Source I 0.0.0.010
Type: • Host Networ1c.

DesllnaUon
Address: ] 10.10.4.100
J
ServIce PO(! Ieo ]I HTTP
AvailabllHy Available (Enabled) - The virtual server Is available
8yncoolde Status 0"

stale Enabled ...
iBaslc
VL.AN end Tunnel Trame [All VLANs and Tunnels ...
Source Address Translation
Figure 14: Assigning Auto Map as the Source Address Translation method for a vlrtua! server
Self IP address selection

The SNAT Auto Map feature selects a translation address from the avai lable self IP addresses in the
following order of preference:
• Floating self LP addresses on the egress VLAN
• Floating selfLP addresses on different VLANs
• Non-floating self LP addresses on the egress VLAN
• Non-floating selfLP addresses on different VLANs
The selection of a floating self IP as translation address on a VLAN other than the egress VLAN is
intended to avoid disruption in an HA failover scenario. However, depending on the network routing
configuration, selection ofa selfLP other than the egress VLAN may cause traffic disruption. F5
recommends ensuring that you have configured floating self 1P addresses on all VLANs from which you
expect SNA T traffic to egress. Alteroative ly, you can use a SNAT pool with one or more lP addresses on
the egress subnet VLAN as members of the SNAT pool.

SNAT Pools
Lesson Objectives
• Configure a SNA T pool
• Describe the source address translation process used by the BIG-IP system when a SNAT pool is
configured
Understanding SNAT Pools

Similarly to Auto Map, a SNAT pool represents a pool of translation addresses that you can configure on
the BIG-IP system. Whereas the Auto Map "pool" of addresses is comprised of the self lP addresses
dcfmed on the BIG-IP system as a whole, the translation addresses in a SNA T pool are configured by a
BIG-IP ad ministrator, and can include lP addresses other than self IPs. When traffic is processed by a
virtual server configured with a SNA T pool, the origin source lP address is translated to one of the
addresses in the SNAT pool, preferably one that is on the VLAN where the traffic is exiting.
Note: If a translation address on the egress VLAN is not available, the BIG-IP system will select
another IP address from the list. This may result in traffic disruption. You should ensure that you
have sufficient IP addresses to handle the maximum number of concurrent connections
expected.
SNAT pool advantages over SNAT Auto Map

The SNA T pool type has some distinct advantages over SNA T Auto Map . Here are some examples:
• All Auto Map SNATs share the same translation addresses - the BIG-lP self lPs. With SNAT
pools, many separate and distinct translation addresses can be used, and that can help mitigate
port exhaustion.
• Virtual server IP addresses (i.e. virtual IP addresses) can be added as trans lation addresses in a
SNAT pool definition. This helps from a securi ty standpoint in that the BIG-IP self lPs are not
exposed externally as they ma y be with Auto Map.
• SNA T pools can be referenced in iRules.

TraHie flow with SNAT pools

As with SNAT Auto Map, BIG-lP prefers choosing a SNAT pool trans lation address that is on the egress
VLAN, as shown in Figure J5.
SNAT Pool List

MySnatPool
VLAN external Common
10.10/16
Traffic exiling !his direction: 10.10.4.150

tlH IHtl :- <. fS IPAddress:
l...----l
Traffic exiting this direction: 172.16.4.150 10.10.4.150
VLAN internal 172.16.4.150
172.16/16
172.16.20.1 172.16.20.2 172.16.20.3

Figure 15: Source address selection wilh a SNA T pool
SNAT Pool Configuration

Local Traffic •• Addre55 Tramstation : SNAT Pool list r4ew !Ofl"T !"oat
To configure a SNAT pool on a virtual
server, tir>t start by creating the SNAT
pool, as shown in Figure J 6: aener..' PrDparties
I. Navigate to Local Traflic » I Nam. MySna'Pool
Address Translation» SNAT

Configuration
Pool List and cli ck the C reate
button (or use the plus-sign (+) IP Address: 10 .10.4.150 j
on the SNA T Pool List flyout). I~ .
~72 . 16.4 . 150 - - -
2. In the General Properties Member List :10.10.4.150
section, give your SNAT pool a
name. J
3. In the Configuration section,
add the desired IP addresses to
I Cancel II Repeat II Finished I
the Member List.
4. Click the Finished bulton. Figure 16: Conflgurmg a SNAT Pool

Create a new virtual server (or edit an existing virtual server) and, in the Configuration section, set
Source Address Translation to SNA T , and set SNAT Pool to the desired SNAT pool, as illustrated in
Figure 17.
100'no,at Properties
Name
Descripllon
Type standard _ _ _~•...,

"'il
Source O.O.O.OJ!)
Type : • Host V Network

DestinaUon
Address: 10.10.4.100
S8Mce Port
Avallablilly • Available (Enabled) - The virtual server Is &vellable
Syncookle status 011
Slat. iEnabled ...
Configuration: leaslc
Source Address Translation iSNAT

SNAT Pool IMySnatPool ..•
Figure 17: Configuring a SNAT Pool on a virtuaf server
Administering BlG-IP v11 3-19

Chapter Resources

SOL6459 Order of precedence for virtual server matching
SOL9038 The order of precedence for local traffic ob)ectlisteners
SOL6459 Order of precedence for virtual server matching
SOL7820 Overview of SNAT fealures
SOL7336 The SNAT Automap and self I P address selection
SOL 11003 Configuring source port preservation for virtual servers
SOL 13433 Configuring source Iport preservation for SNATs
SOL4816 Using the X-Forwarded-For HTTP header to preserve the original client IP address
for traffic translated by a SNAT
SOL9039 A virtual server with a SNAT pool takes precedence over matching the NAT

Chapter 3 - USing NATs and SNATs 3-21
Lab 3.1 - NAT Lab
Objectives:
• Demonstrate the functionality ofa NAT on the BlG-IP system
• Estimated time for completion: 10 minutes
Lab Requirements:
• Administrative access to a BlG-1P LTM system
• At least one server on the VLAN iDternal (172 .16/16 network)
Configure the NAT

I. Add a NAT to connect the external-facing IP address 10.1 OX.200 directly to the internal node at
address 172. 16.20.2 . Configure the General Properties section, as shown below. Accept all the
defaults in the Configuration section.
General Properties sactlon
When complete, click . ..
2. View the local traffic statistics for Nat_200_to_2.
Display Options section
3. There should be no statistics yet for Nat_200_to_2 as you haven't initiated any traffic to the NAT
address or from the Origin Address yet. (All the values for Bits, Packets, and Connections should
be 0.)
4. Open a new browser window to http://10.10_X.200. Note the server you are connected to.
5. Back on the BIG-IP browser WiDdow where you are viewing NAT local traffic statistics, click the
Refresh button to refresh the information on the screen . Note the bits, packets, and connections
values for NAT_200_lo_2.
6. Open a browser window to https:/1l0. 1O.X-200. What server are you connected to?

3-22 Chapter 3 - USing NATs and SNATs
7. Back on the BIG-IP system, refresh the NAT local traffic statistics by clicking the Refresh button
once. Did the statistics change and why?
8. Open a PuTTY session to lO.1 0.X.200. Log in with usemame student and password student.
9. Back on the BIG-LP system, refresh the NAT local traffic statistics by clicking the Refresh
button . Did the statistics change and why?
Expected results
You should be able to connect to multiple services (e.g. http, https, and ssh) through the one NAT, and
you should always connect to 172.16.20.2. Unlike a virtual server, a NAT li stens on all ports. Therefore,
statistics increase every time there is traffic through the NAT, no matter what port is requested.
While NAT_200_to_2 would also allow outbound connections from 172.16.20.2, our classroom
environment is not set up to be able to test this.
If you are unable to connect, as expected, check your NAT defmition to make certain your NAT Address
and Origin Address are specified correctly.
Clean-up
10. Delete NAT_200_to_2 and conftrrn that you are no longer able to directly access 172.16.20.2
through lO. lO.X .200.
Continue with Lab 3.2: SNA T Lab

Lab 3.2 - SNAT Lab
Objectives:
• Demonstrate the functionality ofSNAT Auto Map and SNAT pool on a virtual server
Lab Requirements:
• Two available floating se lf IP addresses - one for each VLAN (internal and external)
• Two available IP addresses for the SNAT pool - one 00 each VLAN (internal and external)
Test Behavior without the SNAT

I. Open two hrowser sessions: one to .!!!!I!:1I10.10.X.100 and the other to bttps:1Il0.10.X.100
2. On each of the resulting web pages, click the link that says Source IP Address, as shown in
Figure 18, and note the source IP addresses as passed from BIG-IP to the internal application
Server. You can use the table that follows Figure 18.
The page is from Server 1 Address: 172.16,20.1: 80
Your Source Address is: 18.11.1.3.
Connected to Virtual Address: 18.11.1.168
AAd connected to Node Address{ 112.16.28.2
FIgure 18: Click the link Source IP Address to view the source IP as lransfated and passed to the node

http://l0.l0.X.l00 https:lll0.l0.X.l00
Source IP Address 111 II? t ,. IP . .'3
Connected to Virtual Address Ar fr • ¥ . 4.t'" t? ,.• .(~~
Connected to Node Address _ _ _~H: . 'iz . .:z... .~
3. Have another student attempt to open a browser session to your virtual servers
(bttp:1I10.10.X.IOO and https:1I10.10.X.100), and you to theirs. Both attempts should fail due to
the route settings on the back end application servers (shown below):
Destination Gateway
10.10.1/24 172.16.1.33
10.10.2/24 172.16.2 .33
10.10.3/24 172.16.3.33
• •
• •
• •
Configure SNAT Auto Map and Test
Add SNAT Auto Map to the virtual server
4. Follow the instructions in the table below to add SNAT Auto Map to vs_ http
Test connectivity with SNAT Auto Map

5. Refresh (Ctrl+F5) the browser window where you are connected to http://10.10.x.100 and view
yo ur source IP address there. It should have changed to 172. 16.X.33, which is the floating self IP
address ofVLAN internal, the egress VLAN for traffic flowing from the BIG-/P system to the
pool members.
6. Have another student try to access both your virtual servers (http://I0.10.X.100 and
bttps:1I10.10.X.IOO), and you to theirs. You should both have success
accessing !!.!!J!:1110.1 O.X.l 00, but not bttps:1I10.10.X.IOO.

The SNAT on vs_http will always cause the back end servers to send their response back to the BIG-IP
system that processed the original client request - no matter where that client request originated. This
ensures the address translation performed by the virtual server on the inbound connection can be
" undone," and the response sent correctly bac k to the original client.
3-24 Administering BIG-IP vll

Configure SNAT Pool

Configure a SNAT pool
7. Follow the instructions in the table below to create a new SNAT pool called MySnatPool.
MySnalPool
IP Address: 10.10.X.150, then click Add
Member List
IP Address: 172.1B.X.150, then click Add
When oomplete. click . .. Finished
Change the virtual server to use a SNAT pool instead of SNAT Auto Map
8. Change the Source Address Translation method on vs_http from Auto Map to SNAT pool.
Configuration sectJon
When oomplete. click .. .
Test connectivity with the SNAT Pool

9. Refresh (Ctr1+F5) the browser window where you are connected to https:IIlO.10.X.lOO.
10. View your source [P address again by clicking on the Source IP Address link on the page, as
shown in Figure 18. Your source lP address should still be 10.1 OX.30.
11. Refresh (Ctrl+F5) the browser window where you are cormected to http://10.10.X.100 and view
your source lP address there. It should have changed to 172. I 6X. I 50, which is the translation [P
address in the SNAT pool that is on VLAN internal, the egress VLAN for traffic flowing from
the BIG-[P system to the pool members.
[2. Have another student try to access both your virtual servers (http://1O.10.X.100 and
https:1110.10.X.100), and you to theirs. You should both have success
accessing .!illJ!:111O.10.X.lOO but not https:lllO.10.X.100.

3-26 Chapter 3 - USing NATs and SNATs
Eliminate SNAT pool address on VLAN internal

13. Delete 172.16.X.lSO from the Member List on MySnatPool. This leaves just one translation
address in the SNAT pool and, more importantly, removes the one translation address that was on
the egress VLAN for traffic from BIG-IP to the pool members.
Select 172.16.X.1S0 from the list, and then click the
Member List
Delete button that is to the i of the Edit button.
When complete. cllck... Update
14. Retest access to http://IO.IO.X.IOO. What does tbe application show your source IP address as
now? How is this possible') Can your partner still access http://JO.IO.x.IOO') Why or why not?

In the last step above, your source address should now show as 10.1 O.x.ISO. At this point, the only
reason the load balanced pool member's response is still returning through the BIG-IP system is by virtue
of the application server's routing table. It indicates that any message originating from a 1O.10.Xl24 client
should be directed to 172.16.X.33 as its gateway. Had the routing been different, your web application
would almost certainly be broken.
It is recommended that a SNAT pool contain at least one member per applicable egress VLAN.
Clean up
15. Reset the Source Address Translation method on vs_http to Auto Map, and then delete
MySnatPool.
STOP

Chapter 4 - Using the Traffic Management Shell (tmsh) 4-1
Chapter 4: Using the Traffic Management Shell

(tmsh)
Chapter Objectives
• Use the Traffic Management Shell (tmsh) to view and configure objects on the BIG-LP system
• Discuss how the BIG-IP system stores its configuration data
• Backup and restore BlG-LP configuration data
Traffic Management Shell (tmsh)
Lesson Objectives
At the end of this Jesson, you should be able to:
• Di scuss how to restrict access to the Traffic Management Shell (tmsh) and the Linux bash shell
(Advanced shell)
• Discuss tmsh hierarchy and how it applies when navigating within the shell
• Use command completion features and help functions to construct a tmsh command
• Create, modify and delete common BlG-lP configuration obj ects using trnsh
Introduction to Traffic Management Shell (tmsh)

In addition to the Configuration utility, the Traffic Management Shell (tmsh) provides an on-<levice shell
for administratin g co nfiguration objects and managing BIG-IP operation. Using tmsh, yo u can configure
system features and set up network elements. You can configure BIG-IP to manage local and global
traffic passing through the system, and view statistics and performance data.
Although there may be some distinct advantages to using the Configuration utility over trnsh, many
network and system administrators are much more comfortable working in a command line envi ronment.
There are a few BIG-IP syste m functions that can only be carried out using trnsh - there is no
Configuration utility counterpart. And there are some BIG-IP configuration tasks that are far easier to
perform using tbe Configuration utility . But from a network administrator perspective. the two tools
togetber provide all the functions you need to carry out your job functions . Therefore, it comes down to a
matter of personal preference and, more importantly, the terminal access level you ha ve been assigned in
you r user account.
Note: Traffic Management Shell replaces bigpipe shell as the primary command-line interface
starting in version 11.0.0.

4-2 Chapter 4 - Using the Traffic Management Shell (tmsh)
Accessing the Traffic Management Shell (tmsh)

The BIG-IP system provides a number of access control mechanisms to maintain secure access to the
system, including but not limited to a hierarchy of user accounts and access privileges. One of these
privileges is access to the BIG-IP command line interface (a.k.a. terminal access).
There are three options available for tenninal access to the BIG-IP system.
• Disabled - no shell access
• Advanced sheU - Unrestricted tenninal
access to the Linux bash shell and Traffic
Management Shell (tmsh)
• tmsh - Access to the Traffic Management
Shell (tmsh) only
These options are configured for each user account, Account Properties
and the available options will vary depending on a User Nama admln
specific user's role. For example, the
New: ~ ••••••••••
Administrator and Resource Administrator roles Password
can be configured with any of the three options, as Confirm: ..........
shown in the top of Figure 1. Other roles, such as

Role IAdmlnlslrdlof
Operator or Manager, can only be configured with
access to tmsh or no access at aU (disabled), as Terminal Access
shown in the bottom of Figure 1.

User roles are covered in detaillatcr in this course. Account Security
Locked Oul
If you configure Advanced sheU access for a user
account, the user will land in the bash shell at the failed Logins o
config directory upon logging in (i.e. the command
line prompt will show config #). The Traffic Syst~m " Usors: Usor Ust 'i,'.J 11 ,,'I
Management Shell can then be accessed by typing
tmsh from within the bash shell, as shown in Figure
2. A£counlProperdes
I
If you configure tmsh tenninal access for a user User Name operal or1
account, the user will go directly into tmsh when

logging in to the BIG-JP tenninal (e.g. with
New" I••••••
PuTTY), as shown in Figure 3.
Pass'WOl'd
C on(lfm I••••••
Role IOperator
PilrtiUon AeC88S
IAll
Terminal Ac.ceu
I Disabled !:.ii
I Cancel II Rep'" I[ Finished 1 l.!I!!m",S~,,-_ _
Figure 1: Terminal access is configured at the user account
Jevel, and options vary depending on the user's role

login as: root

Using keyboard-interactive authentication.
Password:
Last login: Thu Sep 12 13:05:58 2013 from 192.168.4.30
[root@bigip4:Active:Standalone] config # tmsh
root@(bigip4) (cfg-sync Standalone) (Active) (/Common) (tmos) # •
Figura 2: User accounts with Advanced shell terminal access (such as root) are placed at lhe Unux bash shell in Ihe
config dlmelory upon logging InlO Ihe B IG-IP syslem's command Ime inlerface
login as: admin

Using keyboard-interactive authentication.
Password:
Last login: Thu Sep 12 13:23:43 2013 from 192.168.4.30
admin@(bigip4) (cfg-sync Standalone) (Active) (/Common) (tmos)#1
Fig(1ff) J: User accounts with Imsh terminal access (such as admln after Lab 1 In this course) are placed dJrflctly in
Ihe Tmfl'ic Managemenl Shell(lmsh) upon Ioggmg inlo Ih e BIG-IP system's command Ime inlerface
Understanding the tmsh Hierarchical Structure

The structure oftmsh is hierarchical and modular, as shown in Figure 4:
• tmos - At the highest level is tmos (sometimes referred to th e root but nol to be confused with
Lima root).
• modules - Beneath lbe tmos root are subordinate modules that vary depending on the BIG-IP
version, and access to which depend on licensing and provisioning settings. Examples include
Itm, gtm, net, sys, ap m, a5m, auth, eli, em, utll, vcmp, warn, and worn.
• sub-modules - Some modules al so contain sub-modules, as illustrated in Figure 4. For example,
Itm has sub-modules for monitors and profiles, called monitor and profile respectively .
• components - Components are at the bottom of the bierarcby and represent tbe actual objects
tbat you can configure on the BIG-IP system. Examples include node, pool, virtual (server), self
(IP), and vlan.
Note: You must provision a BIG-IP product before you can use tmsh to fully configure it. For
example, you must provision the Global Traffic Manager (GTM) before you can execute tmsh
commands against that reference the gtm module (e.g . tmsh create gtm ... J

root -7 modules -7 sub -modules -7 cOlmc,on9n~ts
••••
monitor profile ••••

self
vlan
• •• •
• •
• snat • •
•
•
•
Figure 4" The tmsh hierarchy is comprised of modules, sub-modulus, and compon ents
Using tmsh
If your user account has Advanced shell access defined, you can run tmsh commands in the following
ways:
• Issue a single tmsh command at the Linux bash shell prompt (e.g. config #). For example, to
display all the modules provisioned on the BIG-lP system:
Cun fl # tmsh list aye provision
• Open the Traffic Management Sbell first, by typing tmsh at the Lioux basb shell prompt (e.g.
config #). This starts tmsh in interactive shell mode and displays tbe shell's root prompt, similar
to this:
user@(bigipl) (cfg-sync Standalone) ((Common) (tmos)#
If your user account has tmsh terminal access defined, you will be automatically placed in tbe Traffic
Management Shell upon logging in to the BIG-lP terminal (e.g. with PuTTY).

The tmsh prompt

As with the Configuration utility, the tmsh command line prompt provides infonnation about the BlG-iP
system's settings and current state. Let's look at an example:
root@ (bigipl) (cfg-sync Standalone) (/Common) (tmos) #
In the example above, the root user is logged on in this session; the host name (or at least the first level
qualifier of a fully-qualified host name) of this BIG-IP is bigipl; the device is not configured as part of a
device group therefore there is no need for configuration synchronization (crg-sync Standalone); and,
tmsh is currently pointing to the /Common partition.
The prompt can also convey status infonnation, as in the example below:
root@(bigipl) (cfg-sync Changes Pending) (REBOOT REQUIRED) (/Common) (tmos)#
Here, the prompt infonns you that the device is part of a device group and that there are configuration
changes waiting to be synchronized between the devices in that group (crg-sync Changes Pending); and,
a reboot of the BIG-IP system is required in order for certain configuration changes that have been made
to take effect.
Tip: You can change the information that displays in the tmsh prompt, but the prompt always
includes your location in the hierarchy and ends with a pound sign (#).
Navigating the tmsh Hierarchy

As mentioned previously, the structure of tmsh is hierarchical and modular. It is important to understand
how to navigate into, within, and out of this hierarchy. Figure 5 illustrates some basic navigational
techniques, each of which are described in more detail below:
: tJ l gl~" ,._ i:'"g-I')(

- - - -
[root@bigip4:Active:Standalonej config # tmsh (-- Enter
root@(bigip4) (tmos)# ltm pool (-- Dive
root@(bigip4) (tmos_ltm.pool)# exit (-- Up 1 level
root@(bigip4) (tmos.ltm)# /net vlan (-- Traverse
root@ (bigip4) (tmos.net.vlan)# / (-- To tmos root
root@(bigip4) (tmos)# quit (-- Exit
[root@bigip4:Active:Standalone] config #
Figure 5: General techniques for navigating mto, within, and out of the Traffic Management Shell (tmsh)

4-6 Chapter 4 - Using the Traffic Managem ent Shel l (tmsh)
Once in the Traffic Management Shell, you can navigate to modules, sub-modu les, general components,
or to a specific component. The following table provides exa mples of how the tmsh prompt changes as
you navigate through the hierarchy executing a series of tmsh commands.
Current prompt tmsh command Resulti~g .~rom!lt

(tmosl# Itm (tmos .!tml ff
(tmos .ltml # jsys soft ware (tmos.sys.software)#
(tmos.sys.software)U modi f y /l tm pool P I (tmos.ltm . pool.Pll#
Note: You can only navigate directly to a specific configuration object (e.g . pool, virtual server) if
that object already exists, and you must use the modify command with no options to get there
(e .g . modify 111m pool P1).
Navigating out of a lower level or out of tmsh

The table below describes the commands you can use to navigate out of a particular mode or module, and
eventually quit tmsh and return to the Linux bash shell (if you have Advanced shell access) or out of your
command line intenace session altogether (if you have tmsb terminal access):
,?urrenl pr~!!, pt tmsh command R~s~!!i.n!!pro~p..t.

(tmos.ltm.virtual. VSll# / (tmos.ltm.vlrtuall#
( t mos.l t m.vir t ua ll ff exiL (tmosl#
(tmosl# q u it config #
--- 'It
* ... only if user's Tenninal Access setting is Advanced shell, otherwise the session is terminated. Also, if
you entered the Traffic Management Shell from a Linux directory other than "con fig" (e .g. " var") you
will return to that same directory upon quitting tmsh.
Command Completion Feature

Understanding the command completion feature
At any point while typing or editing a command in tmsh, you can press tbe <Tab> key and tmsh wi ll
either complete the current word or the next word, or display a li st of possible options for completion, if
the letters entered are not unique. Ca lled command completion, this feature reduces the amount of typing
that is requi red to enter and run tmsh commands.
If the command only has one option, tmsh fill s in the remainder of the word with that option, and also
includes a trai ling space so that any additional parameters can be specified. For example, typing sho then
pressing <Tab> results in the show command being filled in.
If tbe command has more than one option, tmsh completes tbe current word with the longest possible
match , while also displaying the other possible matches . lftmsh dis plays nothing after you press the
<Tab> key, 00 options exist to complete the word.
If you move the cursor anywhe re on tbe command line and press (he <Tab> key, (msh completes wbat is
to the left of the cursor. For example, tmsh completes sho <Tab> pool as show pool .
Command completion also works at the object level. For example, the following command will sbow all
nodes whose lP address begins with the string "172.16." and that can be used to complete the command
before actually running the command.
(tmosl# show I t m node I72.I6.<Tab>

Note: Your user role may impact the options that tmsh presents when using the command
completion feature. For more information, please consult the Traffic Management Shell (tmsh)
Reference Guide, available at AskF5.
Using wildcards searches in tmsh commands

tmsh supports regular expression (RE) and gtob-based wildcard search methods. In the previous example,
we used conunand complete to bave tmsh complete - but not run - a show command and let us know
what lP addresses matching 172.16. that could be used to complete the command. If you want to actually
show the confIguration settings for all LTM nodes whose lP address begins witb 172.16., you could type
the following at the (tmos)# prompt and hit the enter key:
(tmo s )U show Itm node 172.16.*
For more infonnation about using wildcards, access the man page for eacb program using tbe following
tmsh commands:
(tmos)U help regex
(tmos)U help glob
tmsh Help Functions

Context-sensitive help
tmsh includes a context-sensitive help feature that provides belp as you type commands. At any time, you
can type a question mark on the command line, and tmsb will return infonnation to assist you in
completing the command. The results vary depending on where the question mark is entered.
If the question mark is typed inunediately following any portion ofa command (with no intervening
space), tmsh returns possible completions for the command but does not actually complete the command,
as the command completion feature does. For example:
(tmos)# show Itm v?
... retums :
Components:
virtual virtual address
When you type a question mark in tbe middle of a command, tmsh returns belp on the portion of the
command to the left of tbe cursor. For example:
( tmos)# sho w Itm virtual?
... returns something like tbis (some output under "Options" bas been omitted):
Options:
all Apply the command to all c onfiguration objec t s
all-properties Display a l l properties for the spe cifi e d it e ms
default Units are determined base d on c urrent v a lues
Identifier:
[o bje c t identifierl Name of the virtual server
Properties:
"( n Optional delimiter
Pro files Specifies a list of profiles for the virtua l
server to use to direct and manage traffi c .

Here's another example:

(tmos)# show ltm virtual v?
... might retum something like this (depending on what virtual server objects you actually had configured
on your system with a name beginning with the letter "v"):
Configuration Items:
Man pages
tmsh includes man pages for each of its commands, modules, sub-modules, and components. You can
access the man pages using the following command syntax:
(tmos)# help [command] I [full path to compoI?ent]
For example, to access the man page for configuring a pool: (tmos) # help /ltm pool
You can also search the man pages for infonnation on a specific tenn or topic. To do this, use the
following command syntax:
(tmos)# help search [term or topic]
For more information on tmsh man pages, please see the Traffic Management Shell (tmsh)
Reference Guide, available at AskF5.
tmsh Command History Feature

tmsh maintains a history of the commands that have been run on BIG-IP. Command history is displayed
in the order in which the commands were entered, and each command is history is identified by an entry
10. The larger the entry 10, the more recently the command was entered.
Command history is part of the command line interface (CLI) module. You can access history by entering
the show /cli history command from anywhere within tmsh. To rerun a command from the history
list, type "q" to close the list and return to the (tmos)# prompt, then type an exclamation point (')
followed by the entry ill of the command you want to run.
The table below summarizes the CLI history commands:
Module Command Use
eli show h is tory

Display a numbered list of tmsh commands in the
order that they were previously run
After a show history command, re-runs the command
specified by [entry_id]
! ! Re-runs the previously issued command.
! [string] Runs the last command that began with the specified
[string].

Using the tmsh keyboard map feature

You can use the default keyboard map to search the command history li st for a speci fi ed command . For
examp le, to search for the previous corrunand that contains a specified string, type Istringl Alt-P . You
must press Enter to run tbe command. Tbe following table describes the defautt keyboard map for tmsh .
The key sequences are not case-sensiti ve.
Key Sequence Action

Ctrl ... A Moves the cursor to the beginning of the line.
c t rl ... B Moves the cursor 10 the left one character.
Ctrl ... C Cancels Ihe current command.
Ctrl .. 0 Deletes the character under Ihe cursor, or when the command line is empty. exits tmsh .
Ct r ... E Moves the cursor to the end of the line.
Ct r l .. F Moves the cursor to the right one character.
Ctr l ... G Clears all characters from the command line.
Ct rl ... H Deletes the previous character.
Ctd ... J Enters a new line and runs the current command.
Ctrl + K Deletes all characters tram the cursor to the end at the line.
Ctr l + L Clears the screen, repositions the prompt at the upper left, and leaves the current command intact.
Ctr l + M Enters a new line and runs the current command.
Ctrl + N Displays the next item in the command history.
Ct r l + p Displays the previous item in the command history.
Ct r l + Q Resumes input.
Ct r l • R Clears the screen, repositions the prompt at upper left, and leaves the current command intact.
Ct rl + S Suspends input.
Ctrl ... T Transposes the character under the cursor with the character to the left of the cursor.
Ct r l ... U Deletes all characters before the cursor.
Ct r l + W Deletes the word before the cursor.
Esc ... B Moves the cursor one word to the left.
Esc + 0 Deletes all characters from the cursor to the end of the current or next word .
Es c + F Moves the cursor one word to the right.
Es c + L Changes the word to the right and the word under the cursor to lowercase .
Es c + N Searches command history search for the next item.
Esc + P Searches command history search for the previous item .
Esc ... U Changes the word 10 the right and the word under the cursor 10 uppercase.
Esc ... Backspace Deletes the word to the left of the cursor.
Bac kspa c e Deletes the character to the left of the cursor.
Dele te Deletes the character to the left of the cursor.
i (UpArrow) Scrolls back through the command history.
(Down Arrow) Scrolls forward through the command history.
tmsh on DevCentral
DevCentral has an entire Hot Topics section devoted to tmsh, including:
• tmsb Wiki - Learn new ways to create corrunands and automate tasks via the CLI on your BIG
!P.
• tmsb Samples - Find sample tmsh scripts that perform various functions such as creating a test
report detailing all invalid or soon-to-expire certificates or displaying a list ofvirrual servers that
are currently marked as down.

BIG-IP Configuration State and Files
Lesson Objectives
Atthe end of this lesson, you should be able to:
• Articulate the difference between the BIP-lP system's running configuration and stored
configuration
• Compare and contrast how using the Traffic Management Shell and the Configuration utility
impact the running and stored configurations
• Describe what happens when an administrator saves or loads configuration data using tmsh
Introduction to the BIG-IP system configuration state

When you perform configuration tasks on the BIG-lP system, underlying configuration data is generated.
This configuration data exists in two different states.
• The stored configuration comprises all ofthe configuration data that has been explicitly or
implicitly saved to the BlG-LP system configuration files.
• The running configuration comprises the stored configuration and all of the configuration
changes that have been made to the system since the last save operation. The BIG-IP system
operates based on the running configuration.
Storage of BIG-IP configuration data

The way that the BlG-IP system saves configuration data depends on which tool you are using to perform
configuration tasks.
• Configuration utility - Configuration changes are automatically saved to both the running and
stored configuration as you finish each task. For example, if creating a new virtual server, the
underlying conf'guration data is created in the running configuration (implying that the virtual
server can probably now process traffic) and also added to the stored configuration files (in other
words, can be fo und in the bigip.confftle), as shown in Figure 6.
• tmsh - Configuration changes that you make within tmsh are applied only to the running
configuration. For tmsh to write the changes to the stored configuration fil es, you must save the
changes using the tmsh save sys conf i9 command, as shown in Figure 7.

LOGal Traffic ,. Virtu.1 Servers: Virtual Server List .. New VIrtual Server.
General Properties
I Name
Desclipllon [
Type [ Standard
Source
1
Type: Ii) Hos! ~ NelWork
Desllnation
.
Address: 10.10.1.100 J
Service Port L~~_ 1H..:...;TT":,,,;"------lo.Ofl
,",-,I PS
State I [Enabled .::..
I~:::=~~
Cancel [[ Repeat II
Finished [I
ltm virtual v s_https {

vs_https
- ........
...., destinati on lO .lO. l .lOO:https
10.10.1.100
,
' .... ........ - """---'
Config
fi les
Running Stored
Configuration Configuration
Figure 6: BIG-IP system configuration changes made using the GUf affect both the running configuration and the
stored configuration
Administering BIG-IP '111 4-11

(tmo s )~
create Iltm virtual vs_https destination 10.10.1.100:443 ...
(tmos)1 save Isys config
vs_https 1 tm vir t u a l vs_ https (

10.10.1.100:443 destination lO .lO. l . lOO : https
-~-~, ...-----
Entire configuration """--'"""
Config
flies
Running
Stored
Configuration
Configuration
(jH ~ :- <. f5
FigtJre 7: BJG-fP systartJ config uration changes made using tmsh affect just th f) ru nning c onfiguration A lmsh save
sys config command must be iss ued to update the stored configuration. All changes made via tmsh since tile last
save sy s config are saved to the stored configuration.
BIG-IP Configuration Files

The stored configuration is contained in many files and directories on the BIG-I? system, including:
File Description
bigip.conf Stores configuration objects for managing local application traffic such as traffic
group object associations, virtual servers, load balancing pools, profiles, and SNATs.
bigip_base.conf Stores the BIG-IP system network components such as self-IP addresses, traffic
group definitions, VLANs, interfaces, device trust certificates, etc.
bigip_gtm.conf Stores all uniquely GTM configuration elements such as data centers, servers and
their virtual servers, and wide IPs
.--- _ __ __ _-
bigip_user.conf
_.. .... .. .._... __
Stores
_..--. all.. __user roles
._----_ . ---
Note: In versions prior to BIG-IP 11.0.0, the BIG-IP configuration files, such as
the bigip.conf file and the bigip_base.conffile, reside only in the /config directory.
Beginning in BIG-IP 11.0.0, the BIG-IP configuration files may reside in multiple locations.
Configuration data for objects in the Common partition continue to exist in the BIG-IP
configuration files residing in the /config directory. Configuration data for objects in a partition
other than the Common partition exist in configuration files located in
the /config/partitions/<partition name>/ directory.
For example, if there is a self IP configured for the ExampleA partition, the self IP will be in
the/config/partitionslExampleAlbigip base.conf file.

Chapter 4 • Using the Traffic Management Shell (tmsh) 4·13
Loading and Saving the System Configuration

The system applies all configuration changes that you make from within tmsh to the running
configuration of the system. You can save or load the entire configuration. You can also reset your BIG·
IP system to factory defaults by loading the running configuration from tbe defau lt configu ration files tbat
come witb tbe BIG·IP system (defaults/defaults.seC)
During a save sys conf i g operation, the contents of the running configuration - including any and all
changes made since the last save sys conf ig command - are saved to various stored configuration
files.
During a l oad sys config operation, the contents oftbe running configuration are removed, and a
new configuration is loaded into memory from the contents of various stored configuration files,
depending on the parameters that were included on the load command. Depending on tbe new
configuration, you may need to reboot the BIG·IP system.
Tbe table below summari zes so me of these save and load commands, and the impact on the running
configuration in an LTM environment.
tmsh Command Impact on Runni~I!. Config

save sys contig None
load sys c;onfig • Rebuilds all local traffic objects using bigip .conf
o Rebuilds all network objects using bigip_base .conf
• Rebuilds all system user accounts using bigip_user.conf
• Updates system maintenance account settings using bigip_user.conf
• Retains the managementlP address
• Retains the BIG·IP license file
• Retains files in the /shared folder
• Retains manually modified bigdb variables
load sya config default • Removes all local traffic objects
• Removes all network objects
• Removes all system user accounts
• Resets passwords for system maintenance account to defaults
(rooVdefault and admin/admin)
• Retains the management IP address
• Retains the BIG·IP license file
• Retains files in the /shared folder
• Retains manually modified bigdb variables
Note: Only users with the Administrator or Resource Administrator role are authorized to
load configuration data with tmsh. Users assigned other roles receive an error message if they
attempt to run this tmsh command.
Warning : If multiple users are making changes to BIG·IP via tmsh, and one user runs the tmsh
save /sys config command, BIG·I P saves the changes made by al/ the users, not just the one
issuing the save command.
Administering BIG·IP v11 4·13

Effect of load/save on administrative partitions
Note: Although we have not yet discussed the BIG-IP system's administrative partitions feature ,
there is significance with respect to the scope and impact of tmsh load/save sys config
commands . The significance is presented in this section for reference purposes, and becomes
relevant after you have completed reviewing administrative partitions later in this course.
In versions prior to BIG-LP 11.3.0, the tmsh save Isys config command saves the configuration in
the current ad ministrative partition only. Similarly, the tms h l oad Isys config command loads the
configuration in the current admini strative partition only. To save configuration data for all administrative
partitions, you used the tms h save Isys config partitions all command . Simi larl y, you used
the tmsh l oad Isys config part iti ons all command to load con fi guration in all administrative
partitions.
Beginning in BIG-IP 11.3.0, the tmsh save Isy s conf i g command now saves the configuration in all
administrative partitions. Similarly, the tmsh l oad I sys conf ig command now loads the
configuration in all administrative partitions.
The tmsh lsave/loa dl Isys config partitions all command remains unchanged and
continues to save/load the configuration in all administrative partitions.
Wh en using tmsh to perform a configuration save/load in a specific administrative partition, you can use
either the new current - part i tion optjon or the parti tions option.
Shutting Down and Restarting the BIG-IP System

There are several methods that can be employed to shut down and restart a BIG-LP system . All of these
methods will cause a failover on a BIG-LP system that is configured for HA (i.e . in a Sync-Failover device
group), or traffic disruption on a BIG-JP system that is not configured for HA :
• tmsh hal t - Shuts down the BIG-IP system. When the message indicating the system is halted
appears, it is safe to tum off the power.
• tmsh reboo t - Restarts the BIG-IP system.
• bigs tart restart - This command is essentially a soft reboo t of the BIG-IP system. (It
restarts all the BIG-IP system services.) You must have Advanced Shell access in order to use it.
• To restart the BIG-IP system from GUI, navigate to System » Configuration» Device, and, in
the Properties and Operation section, click the Reboot button. There is no G UI option to shut
down the BIG-JP system, only restart it.
• LC D panel - If operating a BIG-LP platfoml, you can use the LCD control panel on the front of
the device to shut down the BIG-LP system. First halt tbe system, then wait 30 seconds before
turning off or restarting the unit.
• AOM - If operating a BIG-LP platform equipped with AOM, you can shut down and/or restart
your BIG-IP system from the AOM menu.
For mo re speciflc information on sbutling down and restarti ng the BIG-IP system, please see:
• SOL7369: Shulling down and restarling the BIG-IP system
• SOLI I 333: Shutting down and rebooting VIPRJON systems

Saving and Repli~a!ing Configuration Data

When you initially set up your BIG-IP system at the start of this course, you learned how to create a UCS
archive using the Configuration utility. In this lesson, you will learn more about archives and other
methods for saving and replicating BIG-IP system configuration data.
Overview
Once you have created configuration data for the BlG-IP system, you can replicate almost all of this data
in a separate file to use:
• As an archive for disaster recovery - Using the archives feature, you can back up the current
configuration data, and if necessary, restore the data at a later time. We recommend that you use
this feature to mitigate the potential loss of BlG-LP system configuration data. An archive is also
referred to as a user configuration set (or UCS).
• As a way to propagate data to other systems - Using the single configuration file (or SCF)
feature, you can easily and quickly propagate the exact configuration of the BIG-IP system to
otner BIG-IP systems.
Differences between UCS and SCF

UCS and SCF are not configuration files in and of themselves, as bigip.conf and bigip_base.conf are, for
example. Rather, an SCF is useful when you want to transfer configuration data from one BIG-lP system
to another. Typically, this involves using tmsh to save an SCF of one BIG-lP system's configuration, and
then using tmsh to load that SCF onto another BIG-IP system. Ln this way, you can "clone" the
configuration of one system to another.
Note: SCF is just one of the tools that can be used to transfer a configuration from one BIG-IP
system to another. Enterprise Manager (EM) and/or ConfigSync (if the BIG-IP system is in a
high availability configuration) are olher options that will be discussed later in this class.
UCS configuration archives are primarily intended for complete configuration backup and restoration
only, as part of an overall strategy for securing your BIG-lP configuration data offsite in tbe event ofa
disaster, or to back out changes in the event of a failure. Unlike SCF archives, UCS archives contain
licensing information and device certificates and keys. Using a UCS archive to restore confIguration data
onto a BIG-lP system other than the device on which the UCS was created requires additional
considerations, as we'll see shortly.

Data contained in the SCF file

Here's a small sample of the contents of an SCF file. The lab in this chapter also provides an opportunity
to create and examine the contents of an SCF:
auth user admin {
description "Admin User II
encrypted-password
"$6$YNneFFwV$KOYH3hZtPHpvC2NGiI'lTCIMCIXI'I5rSJ.51oLbgztj//Sp
CsxAE3EPY/iYNf2.akvGQk4SLAEDOySzmZnHjI'lAol."
partition-access all
role admin
shell tmsh
Itm default-nade-monitor
rule none
ltm node /Common/172.16.20.1

address 172.16.20.1

address 172.16.20.2

address 172.16.20.3
ltm pool /Common/http~ool

members {
/Common/172.16.20.1,SO
address 172.16.20.1
}
/Common/172.16.20.2,SO {
address 172.16.20.2
/Common/172.16.20.3,SO {
address 172.16.20.3
Itm virtual-address /Common/10.l0.4.100

address 10.10.4.100
mask 255.255.255.255
traffic-group /Common/traffic-group-l
Contents of the UCS archive file

A UCS archive contains:
• All BIG-IP specific configuration flies
• BIG-IP product license
• User accounts and password infonnation
• DNS zone files and ZoneRunner configuration
• SSL certificates and keys

UCS Archives
Before you replace a version of the BIG-JP system with a newer version, apply a hot-fi x, or make
significant configuration changes, you should create an archive (backup copy) of c urrent configuration
data in the form of a user configuration set or UCS. Theu, if yo u need to recover that data later, you can
res to re the data from the archive.
UCS archives can be created and managed using either the Configuration utility or tmsh.
Note: Only users with either the Administrator or Resource Administrator user role can
manage archives (e.g. create, delete, upload, or download).
Saving archives
By default, the BIG-IP system stores all archives in the directory I var I l oea 1 lues . If using Lbe GUI
(System » Archives), this is the only location in which you can create a new archive. You can save a
UCS archive directl y to a different directory on the BIG-IP system using the command line (tmsh) but, if
you do, you will not be able to see the file in the list of archives on the G UI.
After you create an arc hive on the BIG-[P system, you can download a copy of it to the system from
which you are running the Configuration utility - preferably a secure remote system. Th is provides an
extra level of protection by p reserving the configuration data on a remote system. In the unlikely event
that you need to restore the data, and a BIG-IP system event prevents you from accessing the archive in
the BIG-IP system directory in which you saved the archive, you st.i ll have a backup copy of the data.
Important: If your configuration data includes SSL keys and certificates, be sure to store the
UCS archive file in a secure environment.
Restoring archives
If using tbe GUI to restore a UCS archive, the archive must be in the Ivar/loe al / ues directory
otberwise it will not appear in the archive list. If yo u previously downloaded an archive to a remote
system, you can upload it to the Iva r / l oea l / ues directory at System » Archives.

Single Configuration Files (SCF)

Working with single configuration files
When you save a singte configuration file, BIG-IP first gathers all of the configuration data on the
running system in the fom! oftmsh commands (and their attributes and values) th at can be used to
recreate the configuration at a later date. Once gathered, BIG-LP saves the configuration commands to a
flat text file in the Ivarlloeallsefl directory with the name you specify and an ex te nsion of ,sef. For
example:
tmsh save /sys conf ig file bigipl_2012112B
... saves the currently running configuration as Ivarlloeallseffbigipl_20121128,sef.
When you install an SCF on a target BIG-I.P system, the target system first saves the currently running
configuration to Ivarlloeallseflbaekup,sef, and then loads the specified SCF into running memory. For
example:
tmsh load /sys cenfig file bigipl_2012112B.scf
... saves the currently running configuration to IvarlloeaIlscflbaekup.scf before loading the SCF file at
IvarllocaIlscffbigipl_20121128.scf onto the system .
tmsh commands for managing single configuration files

Module Command Usage
- ------ -- --
sys save config file [filename ] Saves a copy of the currently running configuration
to an SCF with the name provided by [filename].
Does not affect the running or stored configuration
of the BIG-IP system on which you run the
command.
load config file [filename] Saves the running configuration in Ivar/local/scfl and
then resets the running configuration to the values
contained in the SCF file specified by [filename].
load config default Saves the running configuration in Ivar/local/scfl and
then resets the running configuration to the factory
default settings contained in Idefaults/defaults .scf
Guidelines for using SCF files

• Build a BIG-IP template configuration usi ng the Configuration utility or tmsh.
• Save an SCF fil e from the fully-eonfigured system using the tmsh save /sys command, and
store the SCf file in a safe place for future use. This SCF file can be used as a template to
configure future BIG -IP systems.
• When you are ready to use the SCF file to configure a new BIG-LP system, copy the SCF file to
the new BIG-IP system, and edit the SCF prior to importing it to change LP addresses, routing
information, and other common settings, as needed.
• Install the modified SCF file into the new BIG-LP system using the tmsh l oad /sys command.

User Configuration Set (UCS) Archive

A user configuration set (UCS) is a backup file containing BIG-IP configuration data that can be used to
restore a BIG-IP system in the event of a failure or RMA replacement, or to roll forw.rd a configuration
during software installation or upgrade .
Filenames and location

By default, BIG-IP saves a UCS archive fiJe with a .ues extension, if you do not include it in the filename
at the time the file is created . Also by default, BIG-IP saves UCS archive liles to the default archive
directory, Iv.r/loe.Uues/. Archives located in this list will automatically appear in the list of available
archives when using the Configuration utility or the tmsh list jsys ucs command.
Best Practice: F5 recommends that you include the BIG-IP hos tname as part of the filename to
easily identify the file .
Data contained in the UCS archive

The files that are includes in a UCS are described in the file lusr/ libdatalconfigsyndcs.dat. This file
contains:
• Keys that specify what files to include

• Keys that specify wbat directories to include
• Keys that specify what files to exclude
For more information on the data contained in the UCS archive , see SOL4422: Viewing and
modifying the files that are configured for inclusion in a UCS archive
Secure storage --
Ensure that you have access to System n Archrves tlf J. 1111 11 ,
a secure location for storage

of your UCS archive fil es. The
default UCS archive contains General Properties
SSL private keys, user
File r~ame
accounts, passwords and
critical system fil es. It is
important that you store the
Encryption Enabl ed 1.1
backup UCS archives
Passphrase
containing sensitive
information in a secure
Venfy Pas sphrase
location.
At the time you create a UCS

Private Keys Exclude 1.1
archive, you can request the
conteots of the archive be Vers ion SrG-IP 11 .2.1 Sund 797.0
encrypted with a passpbrase
andlor private keys excluded, I Cancel " Finished I
as shown in Figure 9.
-
Figure 8: Encrypting a UCS at the time it is created; P rivate keys are also
excluded in this example

For more information on securing and managing UCS archives, see SOL 175: Transferring files
to or from an F5 system.
, Changes in BIG-IP 11 .x
Prior to BIG-IP version II , when a UCS file was installed on B1G-IP, the BIG -IP system restored the
configuration either partially or in full depending on the hOSlname of the unit that th e install wa s
occurnog 00.
If the hostname of the unit matched the hostname stored in the UCS archive, BIG -IP restored the full
configuration, including sel f-IP addresses and VLANs. If the hOSlname of the unit did not match the
hostname stored in the archive, BiG-lP restored only the shared confi guration (e.g. virtual servers, pools,
profiles).
Note: Beginning in BIG-IP version 11.0.0, BIG-IP always restores the full configuration when
installing a UCS configuration archive. This has certain impacts on the BIG-IP license. See
SOL4423: Overview of UCS archives for more details.
tmsh commands for managing UCS archives

Module Command
U~ge
sys s ave ucs <pa th / to ! UCS >

Creates the UCS archive file at the location
specified by <path/tolUCS>. If just a filename is
specified, the UCS file is saved by default in the
Ivarllocallucsl directory.
loa d ucs <path / t o / UCs> Restores the UCS archive file from the location
specified by <path/to/UCS >. If just a filename is
provided, BIG-IP looks for the file in the
Ivarllocallucsl directory. Note : You may have to
reboot the BIG-IP system for the restored UCS
archive to take effect.
----'-

Chapter Resources

SOL13132 Backing up and reslorinQl BIG-IP configuration files (11 .x)
S0L13551 Configuring a replacemenl BIG-IP device after an RMA when no UCS archive is
available
SOL4423 Overview of UCS archives
SOL10245 BIG-IP UCS installation and licensing behavior
SOL8465 Viewing and extracting the contents of an encrypted UCS file
SOL4422 Viewing and modifying the files that are configured for inclusion in a UCS archive
SOL5437 Encryption used for UCS and configsync creation
SOL7369 Shutting down and restarting the BIG-IP system
SOL 13408 Overview of single configuration files (11 .x)
SOL 14564 The tmsh save/load /sys config command now saves/loads configuration in all
administrative partitions
Manuat Chapter
BIG-IP TMOS: Concepts Archives
BIG-IP TMOS : Implementations WorkinQ with Sin~le Conf~g_uration Files

4-22 Chapter 4 - USing the Traffic Management Shell (tmsh)
Lab 4.1 - tmsh Configuration Labs
Objectives:
• Configure pools and virtual servers using tmsh and observe the changes that occur in the stored
configuration files as the result of these changes.
• Estimated time for completion : 30 minutes
Lab Requirements:
• Command-line access to BIG-lP
• Services to load balance, including SSH
Configure a Pool using tmsh

In thi s lab, wherever you see notation such as <Key>, please interpret that as meaning you should press
the keyboard key specified rather than type the letters. For example, <Tab> means "press the Tab key."
When an instruction indicates that you should "run" a particular command, press <Ent er> after typing
in the command.
Access the Traffic Management Shell (tmsh)

I. Access the command-line interface to BIG-IP and log in as the root user.
2. At the bash prompt, enter the Traffic Management Shell by typing: tmsh
3. Navigate to the 11m module using command completion by typing: It<Tab><Enter>
Your command promp t should now read something like this:
root@(bigipX) (cfg - sync Standal o ne) (Active) (/Common) (tmos. ltm)#_
Create a pool using tmsh

In the nex t group of lab steps, you wi IJ create a new pool - sshyool - using the information in the table
below. During the creation process, you should practice using tmsh's auto-<:ompletion function s whe n
you can.
9bject Name ___ ~'.'a~~a!.8nc~nl!...ftII~~_,,_ Node IPs Port
sshJlool Round Robin 172.16.20.1 22
172.16.20.2 22
172.16.20 .3 22
4. Type cr<Tab> and the word create should auto-<:omplete.

5. Type p<Tab> and options for modules and components that begin with the letter "p" should be
displayed - for example, persistence, prolile, and pool. Since there is more than One option ,
tmsh cannot auto comp lete the command and awaits additional input.

Chapter 4 - USing the Traffic Management Shel l (tmsh) 4-23
6. Type oo<Tab, and the word pool should auto-complete.

7. Type ? to show a li st of ava ilable options for completing the command .
8. Type sshyool for the pool name, followed by a space.
9. Type {l o <Tab, and the load-balancing-mode option should auto-complete.
10. Type ro<Tab, and the round-robin option should auto-complete.
II. Conti nue using auto-complete until you have created the full tmsb command below, then press
<Enter> to run the command:
(tmoe.lom)# create pool Bsh-poo1 { load-balancing-mode round-robin

members add { 172.16.20.1,22 172.16.20.2,22 172.16.20.3,22 } }
12. Veri fy the pool was successfully created by viewing its configuration. You should see three
members:
ttnlos . Jtm) ti list pool sshyool
Save the running configuration to the stored configuration

13. Save the current running configuration to the stored configuration by running:
(tmos_ltml# save /sys config
Note the "j" is required in front of the "sys" as you are currently in the "Itm" module and the
"save config" command is part of the "sys" module. Notice also that your prompt still reads:
(tmos .ltml # indicating you are in the LTM module within the TM shell.
View pools in the running configuration

14. View all pools in the running configuration by running: list pool
15. Arc all of the pools displayed, including sshyool?
View the stored configuration in bigip.conf

16. Exit tmsh by running: quit
17. View the stored configuration in bigip.conf by running: more /conf ig/bigip. conf
Use the space bar to page down or the <Enter, key to scroll down through the display.
18. Is pool ssbyool in the stored configuration? Why or why not?
19. End the "more" display by typing: q
Admin istering BIG-IP v11 4-23

Create a virtual server using tmsh

20. Create the virtual server defined in the table below using the tmsh command shown immediately
below the table as the basis. (Hint: Navigate to the correct shell and module first before running
the command exactly as shown, or add the appropriate syntax to the command to run it from
wherever you are currently located.)
Object Name lP Address Port Profile Resource

vs ssh 10.10.X.100 22 tcp ssh pool
(t;mos.1 bnll create virtual vs ssh destination lO.lO.X.IOO:22 profiles
add { tcp } pool sshyool
21. Navigate to the bash shell (if not already there) and view the stored configuration again: more
/config/bigip.conf
22. Is vs_ssh listed? Why or why not?
Test your configuration changes

23. Open a new SSH session to virtual server vs_ssh (at the appropriate lP address:port). Were you
able to connect?
24. Log in with userid student and password student, and view the files in the main directory by
running the list command: Is -1
a. Could you see a list of files?
b. Which pool member did you connect to? Hint: Check node statistics by running the
command tmsh show Iltm node 172.16.20.*. The asterisk is a wildcard that indicates any
value in the last octet. You can reset each node's statistics by running the command
tmsh reset-stats /itm node 172.16.20.*)
c. Do you have an open (current) connection to one of the pool members?
25. Close the SSH session window to vs_ssh. Back on the SSH session to BIG-IP, save the running
configuration to the stored configuration.
26. View the stored BIG-IP configuration bigip.conf again to verify that vs_ssh is now part of the
stored configuration.
27. You've looked at bigip.conf. Now go look at Iconfiglbigip_base.conf. What types of
configuration objects are stored there?
Create UCS and SCF backups of your configuration using tmsh

28. Make a UCS archive of your current configuration by running the following:
(Omcs)# save /sys ues trainX_ffiod4.ucs
29. Make an SCF archive of your current configuration by running the following:
(~S)# save /sys config file trainX_ffiod4.scf
30. View your current local traffic objects: (tmos) # list /ltm
Note that you can see all the virtual servers, pools, pool members, and nodes you've created so
far in class.

Chapter 4 - USing the Traffic Management Shell (tmsh) 4-25
31. Restore your UCS archive from the very first lab in this course by running:
(tmos)# load /sys lies tralnX base ues
32. All of the localrraffic objects created after Lab 1 should now be gone (virtual servers, pools,
etc.). Look at the stored configuration in bigip.conf, and then the running configuration via the
Configuration utility (GUI) or via:
(tmoa )# list /ltm
33. Restore the configuration as it existed before the UCS restore, and view local traffic objects
again. Everything should be back to normal.
(tmos )# l o ad / sys ucs trainX mod4.ucs
(tmos)8 list Iltm
34. Compare the two archives that yo u created -/varllocaUucs/lrainX_mOd4.ucs and

Ivar/local!scf/trainX_mod4.scf - from a file type perspective. (You'll have to ex it from the TM
sheU in order to do this.) What's different about their file formats?
35. View the single configuration file (SCF) you created earlier with cat , tail, more, less, and
otber Linu x bash tools. For example:
cat Iless /var/local/scf/trainX mod4.scf
View the automatic rotating BIG-IP system archives

36. Change to the default UCS arcbive directory and list its directory:
cd /var/local/ucs
ls - 1
37. Notice that there are additional UCS archives in tbis directory, above and beyond those that you
have explicitly created to date. You should see train4_base.ucs (which you created in the first
lab) and train4_D1od4.ucs (whicb you created just a few moments ago). Notice also that there are
severa l UCS files called cs_backup.ucs, cs_backup.ucs.I, etc . When you issued the l oad / sys
uc s command in step 31 to restore tbe configuration from traioX_base.ucs, the BIG-LP system
first archived tbe ex isting running configuration as one of the cs_backup.ucs archives you see in
tbe Ivar/local/ucs directory. The date and time 00 the actual cs_ backup archive will be slightly
after you created the train4_mod4.ucs file in step 3D, just before you did the restore.
38. View the rotating archive configuration file: more cs_bac kup_ro t at e. c onf
STOP

4-26 Chapter 4 - USing the Traffic Management Shell (tmsh)
(J
I . 9~/
?' «_ I'(,/W;)-{
r"i~ V"~) ~
r'F;:-A I)C- r
, I '
~:I ,( , ~ n (o.
j) ~/.:.... ~ chcct{
r4~/(
;(1),. ,--, ' -J

, 1.
1_
'"l"'l- - r. J ,I
1
4) rl..!h~ (~k (~t I) 'If,
\
() /'1 ~ - ~yt.rl.- f - I," t s

Chapter 5 - Monitoring 5-1
Chapter 5: Monitoring ( (l-I/:;J.I /oJ t,J)')
Chapter Objectives
After completing this chapter, you will be able to use healtb monitors and tbe network map to dete rmine
the avai lability of network resou rces.
Monitor Concepts
Lesson Objectives
At the end o f this lesson, yo u will be able to:
• Compare and cont rast health monitors and performance monito rs
• Descri be the types o f configuration objects a health monitor ca n be assigned to
• Describe how a mo nitor inherits configuration settings from its parent
Overview of Monitors
Monitors determi ne the availability and performance of network resources such as nodes (devices) and
poo l me mbers (services). If a monitored resource repeatedly fails or does not respond to a health monitor
tcst, or shows that its performance is degraded or its load is excessive, the BIG-lP syste m can mark that
resource as temporarily unavailabl e and redirect traffic to another resource.
Health monitors check the functional Performance monitors check the

availabi li ty o ft be reso urce performance of and load on the reSource
Monitors gather information about your network and that information is ava ilab le fo r you to view and use
duri ng troubleshooting activities, or as input to system maintenance, performance management or
capacity planning processes.

5-2 Chapter 5 - Monitoring
About health monitors

In a nutshell, health monitors generally cbeck
1. ... a specific resource ..
2. . .. for an expected response ..
3. . .. within a defined time interval.
If the specified resource does not provide the expccted response within the specified time interval, BIG-lP
marks the resource as unavailable. In addition, BIG-IP system no longer directs traffic to that resource
until it detects (via the health monitor) that the resource is once again available. In other words, the health
monitor cbeck is ongoing regardless of whether the monitored resource is currently available (up) or
unavailable (down).
About performance monitors

A performance monitor gathers information about the resources it is assigned to, and uses th.is information
to dynamically load balance traffic. If the performance of a monitored resource is degraded or the load is
excessive, BIG-IP can temporarily redirect traftic to another resource until the performance bottleneck is
relieved or the load returns to normal.
Types of resources that can be monitored

local Traffic Manager (lTM) Global Traffic Mana_!ler (GTM)_ _link Controller
nodes links links
pools servers pools
pool members virtual servers pool members
pools
pool members
Monitors are BIG-lP configuration objects that are created and then assigned to one or more resources.
BIG-1P includes many pre-configured monitor templates tbat can be used as-is or as the basis for a
customized monitor to meet a specific need.
Monitoring methods
BIG-lP ptovides three methods of monitoring:
~onilo~ng ~!!~~d _Si",ple Monit~ri"'!1_ ~Clive Monil~':in_g _~"~~i.".e Monil"ri_~ __

Use Determines whether Directs traffic (load Assumes health of
resource status is up or balances) based on resource based on
down ongoing checks of connection attempts
resource status or
performance
Examples • Gateway ICMP • HTIP • Inband
• ICMP • WMI
• TCP_ ECHO
Note: In this course, we will focus on some typical health monitors for nodes and pool members .
For information on other BIG-I P health and performance monitoring features, please see BIG-IP
Local Traffic manager: Monitors Reference or take our Configuring L TM course.

Resource status hierarchy

Depending on the type of resource a health monitor is assigned to, a failed health statu s ch eck may carry
impli cations for mOre than just the resource itself. Consider this: A local traffic node is identified by its IP
address alone, and typically represents an application server de vice; a pool member is identified by its
node lP address and a service port, and represents a particular service provided by an application server
device. As presented earlier in this course, a node can contain more than one pool me mber. The pool
members are, in fact, children of the parent node.
With respect to health monitors then:
• If a health check fails on a monitor assigned to a
specific pool member, only that pool member is
( Virtual
Server
)-
marked offline.
• If a bealth cbeck fails on a monitor assigned to a
node, the node may be marked unavailable, and
( Pool
)
all the pool members it contains may also be
Pool
marked offline.
Member
• When certain bealth monitors assigned to a node

detect that tbe node is available once again, the
node will be marked availabte. Depending on
( Node
)
other monilOrs, the child pool members may
continue to be marked ojjline.
We will discuss resource status and status inheritance in more detail later in this chapter. For now, keep
this hierarchy in mind as you learn more about some commonly used BIG-lP monitors.
Types of Monitors
Pre-configured monitors are included as part of the BIG-lP system - - while other mon itors called
custom monitors are created by network administrators. Every monitor, whether pre-configured or
custom, is a certain type (or category) of monitor:
• Add ress check monitor
• Service check monitor
• Conte nt c heck monitor
• Application c heck monitor
• Perfo mlance check monitor
• Path check monitor
Some monitors types are more robust than others; some more granular in their ability to measure the
health andlor performance of the network. Each is designed to perform a very specific type of monitoring
function .
Note: In this class , we will focus on address check, service check, and content check health
monitor types .

Address check monitors

An address check monitor provides a simple verification that an IP address on the network is reachable.
This type of monitor sends a request to the address specified and, if a response is received, the test is
successful, as illustrated in Figure J.
172.16.20.2:80 172.16.20.1
. 172.16.20.2:443
172.16.20.2:22
. 172.16.20.2:21 172.16.20 .2
172.16.20.3
Figure 1: An address check monitor such as ICMP assigned to a node simply pings that node's IP address and. if a
response is received, marks the node as available.
When an address check moni tor is associated with a node, the availability of th e node can also affect the
availa bility of pool members that share that node's IP address. In other words, if an add ress check
monitor assigned to a node detec ts that the node is not responding properly, the node is marked offline. In
addition, all pool members attba t node will be marked ofOine (regardless of the success or fa ilure of any
monitors assigned directly to those pool members). To compound matters, when the node's address check
monitor detects that the node is back up again, it will mark the node as availabte - bu t the pool members
may still show as orOine. This is due to the fact that an address check monitor tests at the IP address level,
not at the port level.
+ 172.16.20.2 :80 172.16.20.1

. 172.16.20.2:443
+ 172.16.20.2:22
+ 172.16.20.2:21 • 172.16.20.2
..... - .
F,gure 2: Pool members can inhent status from {he parent nodes . If a node is marked offline by a
172.16.20.3
monitor, pool
members that share the same IP address will also be marked offline.
Note: An address check monitor on a node as a means to determine the status of an application
is ineffective, at best, providing a false sense of security unless accompanied by other monitor
tests. A node test may show the node is available, but all its pool members may be down ,
rendering the applications the node serves as unreachable.
5-4 Administe ri ng BIG-IP v11

Only the Gateway ICMP address check monitor can be assigned to a specific pool member or as the
default monitor for all pool members in a given pool. The other address check monitors can only be
assigned at the node level. Even though Gateway ICMP may be assigned to a pool member (IP address
and service port) it still only checks the IP address (essentially the node). However, in this case, if the
address check fails, only the one pool member is marked offline; the node's status does not change.
Likewise, when the IP address is finally reachable, the Gateway ICMP morutor marks the pool member as
available, even though the pool member's port was not actually tested.
Service check monitors

A service cbeck monitor determines whether a service is available by opening a connection to an IP
address and port combination (service). The pre-configured TCP Half Open monitor is an example of a
service check morutor. This monitor works by sending a TCP SYN packet to the assigned service. The
test is successful if the monitor receives a SYN-ACK packet back, as illustrated in Figure 3. The
connection is then reset (RST) by the BIG-IP system .
• 172.16.20.3:80
. 172.16.20.3:443
• 172.16.20.3:22
172.16.20.3:21
..... . RST
172.16.20.3:443
Figure 3: Example of the rep Half Open service check monitor assigned to pool member 172.16.20.3:443
When associated with a pool member, the TCP Half Open monitor determines the availability of that
service. If the connection fails, the pool member is marked offline, and no additional requests are load
balanced to that pool member until the monitor detects that the pool member is once again available.
Service check monitors can be associated with a specific pool member or assigned as the default monitor
for a pool. If assigned at the pool level, the monitor normally applies to all the pool members in that pool.
(This behavior can be overridden by selecting Member Specific as opposed to Inberit from Pool as the
Health Monitors setting for a specific pool member in the pooL) If a service check monitor is assigned to
a specific pool member, only that member is monitored.
While a service check monitor may determine that a particular service is available, it does not determine
whether or not the service is working properly. For that, a more robust monitor such as a Content Check
Monitor is required.

Content check monitors

More robust monitors such as content check monitors do more than just verify that a service is available;
they also test whether or not appropriate content is being served. A typical content check monitor will
open a connection and issue one or more commands to the server, as illustrated in Figure 4. The response
received is then compared to an expected response. The commands sent to the server (the Send String)
and the expected response (the Receive String) are customized to meet the needs of the application
service being monitored .
• 172.16.20.3:80
. 172.16.20.3443
172.16.20.3:22
. 172.16.20.3:21
..... . HTTP GET...

172.16.20.3:80
[r esponse]
Figure 4: A content check momtor, such as the HTTP monitor "'ustraled here, determines availabffily of a service and
that appropriate content is being served
BIG-lP includes several pre-configured monitors that can be used as templates for creating a custom
content check monitor. For example, the HTTP monitor can be used as the basis for creating a custom
monitor to check the status of a web application service. You might configure the custom monitor's send
string to send GET / index. html \r\n, and configure the receive string to look for a response that
definitively confirms that the index. html page was successfully served. When assigned to a pool
member, the monitor periodically establishes a connection with the pool member, sends the send string,
then compares the response to the receive string, closes the connection, and marks the pool member as
either available or offline, depending on the whether or not the test was successful.

Monitor Interval and Timeout Settings

When configuring a health check monitor, you set values for the interval and timeout settings in seconds.
• Interval controls how often the monitor's test will run.
• Timeout controls how long the monitor will wait for a successful test result before marking the
resource offline.
Interval typicaUy defaults to five (5) seconds, and timeout typically defaults to sixteen (16) seconds, in
line with F5's recommendation to set timeout to three times the interval setting plus one (i.e. 5 x 3 + 1 ~
16). The monitor's health check (test) will run every 5 seconds and, ifno successful test result is returned
within 16 seconds, the resource will be marked offline. This interval-to-timeout recommendation keeps
the BlG-lP system from potentially marking a resource omine just before it makes a fourth check, as
Configuration: IBasic •
Interval 5 seconds
Timeout seconds
test test test test test test
Figure 5" A monitor instance will ke ~p its associated resource marked available untfl the timeout value is reached.
Here, timeout is 16 seconds. Each successful monitor test result resets the timeout counter to O. Each upright tick
mark represents a 5 second interval. During the first interval, a successful response is received and the timeout
counter IS reset. During the next three intervals, no successful response ;s received. The resource is marked offline 1
second after the last test if no successful response has been receIVed.
On a simple address check monitor (such as icmp), having the B1G-1P system ping every lP address to
which the monitor is assigned every five seconds mayor may not represent a significant increase in traffic
within your network. However, setting up and tearing down a complete HTTP connection - including
sending a request and receiving a response - to every pool member an http-type monitor is assigned to
every five seconds is potentially significant.
There are no steadfast recommendations for setting interval (or timeout, for that matter), as applications
and networks vary greatly from one installation to the next. Instead, you should simply understand that
any B1G-1P health monitor instance creates additional network traffic. Care must be taken to balance the
need for monitors - and the important feedback they provide with respect to application health - with the
inevitable increase in traffic. A best practice when implementing monitors is to stress and volume test the
impact of various interval and timeout values on traffic, and choose the settings (and monitors) that
provide the most effective overall balance.

For example, you might set interval for a content check monitor, such as http, to 30 seconds, knowing that
the infonnation it provides is critical to assessing the availability ofa web application, but also knowing
that it creates significantly more network traffic than an address check monitor. If timeout is then set
accordingly to 91 seconds (3 x 30 + I), the potential exists for a "broken" web application on a pool
member to go undetected for 91 seconds before the BIG-JP system finally marks that pool member
oilline. If this is a business-critical web application, perhaps that's too long to wait, given that any
application users (clients) who are being load balanced to this pool member are no doubt seeing
unpredictable results (at best) on their end.
In the end, if you did decide to run this http monitor more frequently, you could take steps to ensure that
the monitor's Send String request produced as little response data as possible for the BIG-IP system to
detennine that appropriate content is being served. For example, you could have the monitor request a
page that was specifically designed for the monitor test, rather than a page that an application user might
request. While this does not preclude the possibility that an important user page is not bcing served
properly, it does provide an alternative, especially if that important user page has lots of content (e.g. jpgs,
gifs, html, etc.)

Con'figuring Monitors
Lesson Objective:
At the end of this lesson, you will be able to configure a custom monitor using the Configuration utility.
Monitor Templates
The BIG-lP system includes a set of pre-configured monitors for address, service, and content checks.
Some of these monitors can be used with no changes; all can be used as templates to create monitors with
settings that are customized for particular network or application needs. Once a custom monitor is
created, it can also be used as a template to create other custom monitors.
The tables below summarize some of the more commonly used monitors.
Address check monitor templates

Monitor Function
ICMP The check is successful if the monitor receives a response to an ICMP_ECHO
datagram. Can be assigned to a node only.
TCP Echo Verifies TCP connections. The check is successful if the monitor receives a
response to a TCP echo request. Uses port 7 and can be assigned to a node
only.
Gateway ICMP Uses ICMP to make a simple resource check. The check is successful if the
monitor receives a response to an ICMP_ECHO datagram. Unlike ICMP though,
the Gateway ICMP monitor can be assigned to a node, pool member, or poot.
If assigned to a pool member, gateway_icmp still will not check the port service.
If the test is successful, the pool member is marked available, even though the
port associated with the pool member was not tested. If the test to the pool
member is unsuccessful, only the pool member is marked offline; the node
~~ does not chang~
Service check monitor templates

Monitor Function
TCP Hatf Open Monitors the associated service by sending a TCP SYN packet to the service.
The test is successful if the monitor receives a SYN-ACK packet back, at which
point the monitor sends the service a RESET, and the service is marked as
available. If the test fails, the service is marked offline.
TCP Same as TCP Half Open except that the monitor tries establishing a complete
TCP connection by following the SYN-ACK with an ACK. This monitor is
frequently used as a template for a content check monitor rather in its barest
form as a service check monitor.

Content check monitor templates

Monito r Function
TCP Verifies TCP service by attempting to receive specific content from a resource.
The check is successful when the content matches the Receive String value.
HTTP Checks the status of HTTP traffic. Like the TCP monilor, an HTTP monilor
attempts to receive specific content from a web page. Unlike a TCP monitor, Ihe
HTTP monitor may also send a user name and password.
HTTPS Checks the status of HTTPS traffic by attempting to receive specific contenl from
a web page protected by SSL security. The check includes SSL negotiation, and
is successful when the content matches the Receive String.
LDAP Checks the status of LDAP servers. A check is successful if entries are returned
for the base and filler specified. Monilor settings musl include a user name,
password, and base and filter strings.
Note: The default Receive String is null.
Creating Monitors
A few pre-configured monitors can be assigned to resources without modification, and can occasionally
be useful in their default form. For example, there is little to change in the ICMP or TCP Half Open
monitors except perhaps to their interval or timeout settings. If the default settings are satisfactory for
your monitoring requirements, they can be used as-is.
However, most pre-configured monitors are of little value without customization. The HTTP monitor's
default receive string is null ~ not very useful from a content check perspective as any response string
would be considered acceptable. As a result, most production environment BIG-IP monitors are
customized to meet your application services and network needs.
Some pre-configured monitors, such as the FTP monitor, cannot be assigned directly to a resource; they
can only be used as a template to create a custom monitor - log on credentials may be required; paths and
file names may need be specified, send and receive strings should be set to something other than a null
value; and timer intervals should be configured to work within the characteristics and constraints of your
network and application services, so that monitors don't become a burden on BIG-IP performance.
Creating a custom monitor using the Configuration utility

While morutor settings vary from one monitor to the next, the general steps involved in creating a custom
monitor do not, and are surrunarized below:
1. Navigate to Local Traflic» Monitors and click the Create button
2. Name the monitor
3. Select the type of monitor
4. Select the parent monitor ~ can be either an F5-supplied default monitor or another custom
monitor. Only applicable parents (based on the morutor type) will be shown.
5. Customize the settings, as needed

Creating a custom http monitor

In Figure 6, we're creating a new moni tor called my_http . It ' s an HTTP type monitor and its parent is an
FS-supplied monitor called http. This new monitor can be assigned to any pool member that can process
http traffic.
localTramt' )) Monnors . NE."N Monnof
General Properties
I Name I my-http
..>
Loo-al nome Description
Network Map I Type I HTTP

Virt ual Serve rs Parent Monitor 1http
Policies
Profiles
I
Configuration: Basic
JRules
Interval I5 seconds
POOlS Timeout 116 seconds
Nodes GET / i ndex. ht ml \ r \n
MonHors • Send string
Traffic Class
Address Translation
r<~"'
11 J I I
ONS Expre ss Zones
Receive string
ONS Caches
Figure 6: Creating a cuslom monitor, in this case a new HTTP monitor type based on the FS-provided default monitor
called "hffp" (Parent Monilor)
Every five seconds, it will establish a connection to an assigned poo l member, send an HTTP GET
request for index. hIm! (the Send String), and upon receiving a response, will examine the response
contents to see if it includes the character string Server 11-31 (the Receive String). In this case, the
Receive String setting includes a regular expression -the " [1-3)" part - that permits a value of I , 2, or 3
at this location in tbe string.
The net effect is that if any pool member this monitor is checking has an index.html page that contains the
character string "Server I" or "Server 2" Or "Server 3" the pool member will be marked as available. If
the pool member'S index. html page does not contain one of these character strings, the monitor will mark
the pool member as offline.
For more information on using regular expressions in monitor receive strings, please see
SOLS917: Using regular expressions in a health monitor Receive String

Assigning Monitors to Resources
Lesson Objective:
• Assign a node default or node specific monitor
• Assign a monitor to all members in a pool or to a specific pool member
Monitor Associations
Creating a custom monitor is an important process, but unless the monitor is assigned to a resource - a
node, a pool, or a pool member, for example - the monitor will not perform any tests. Monitor assigrunent
can be assigned at a group level (a pool, for example) or individually (node specific, for example).
Note: By default, the BIG-IP system makes no monitor assignments.
Assigning monitors to nodes

One option in your BIG-IP monitoring strategy may be to monitor some or all of your LTM nodes. There
are three different ways this can be done :
• Node Default - Default monitor(s) can be assigned to all nodes
• Node Specific - Monitor(s) can be assigned to a specific node
• None - A node can be configured to have no monitoring whatsoever
When a new node is created and con.figured, its default monitor setting is Node Default indicating that
the monitor assignment comes from the Default Monitor setting for alllocallTaffic nodes (i.e. at the
global level) . As noted above and shown in Figure 7, BIG-JP makes no monitor assignments by default.
Configuration: IBasic
Active Available
Common
Health Monitors gateway_icmp
https_443
icmp
real _server •
[QPdateJ
Figure 7: By default, there is no Default Monitor setting for nodes on the BIG-IP system

To activate a node Default Monitor:

1. Navigate to Local Traffic »Nodes.
2. In thc Menu bar, click the Default Monitor tab.
3. In the Configuration section, selcct the monitor(s) you want to use and activate them by clicking
the « button to move them from the Available column to the Active column. In Figure 8, we've
selected icmp as the node Default Monitor.
4. Click Update to save your changes.
Configuration: IBasic
Active Available
Common
Hea~h Monitors gateway _icmp
https_443
real_server
snmp_dca
I Update I
Figure 8: Setting a Node Default Monitor, in this case, icmp
For cach node the default monitor(s) should apply to, select the node's configuration and ensure that
Health Monitors is set to Node Default, as shown at the top left of Figure 9. When a health monitor is
made active at the global level in this way, all local traffic nodes on LTM with their Health Monitor
setting configured to Node Default will be checked.
A node can be assigned monitors individually with the Node Specific setting, as shown at the top right of
Figure 9. Node specific monitors are used instead afthe Default Monitor, not in addition to the Default
Monitor.
Ifa node is configured with the Health Monitors setting of None, as shown at the bottom of Figure 9, no
monitor checking is performed for that node regardless of any node Default Monitor settings.
Administering BIG-IP vii 5-13

General Propertie.
Neme
_.
General Properties
Name
Partition I Path
172.16.20.1
172.16.20.1
Common
Addre SS'
Plllrtition I Path
Health Monitors
172.16.20.2
Common
II
Available (Enabled) - Notte address is evaHable
Description Curr.TII Conntdions o

Availabilily t:) AvaJiabie (Enabled)· I) Enabled (AJllr!l\'Tlc allowed)
51ale Ci Disabled tOnly perslslenl or adlve connections al\O\
Health Monitors j Omp o Forced Omlne (Only active connections ;1Iliowed)
Gurrert Connedions o Connguratlon
e Enabled (All traffic al Hell"" Monitors INode Sped 'll: ..
Siale o Disabled (Only persi
Active Available
o Forced Offline (Only
CDmMDn CDmmDn
Co "figl..ll'il1fon
Selecl MOIlnor'S
gtltew8y-icmp
B httpl_443
icmp
INode Default R reel_server

HeaMh Monitors snmp_dca
•
I)enaral' Properties
N. "", 112.16.20.3
Address 112.16.20.1
Partition ' Path Common
CnertpUon
Unknown (Enabled) - Node addrlSs does not fll!lV e service cflecklng enabled
CUrr.nC Connections o
II) Enabled tAil tramc allowed)
.tao. I) Dlsabted (Only persistent or ac1i've connec1tons aHowed)
o Forced omlne (Only actiVe connections allowed)
------~
Configuration
IINone
Figure 9 ' Specifying different Health Monttors settings on nodas. Node 112.16.20.1 will be assigned th e Node Default
monitor. in this case, icmp (lop-left); Node 172. 16.20.2 has a Node Specific monitor, gateway-icmp (Iop~righl). This
overrides any node Defaull MQnitor setting; Node 172.16.20.3. has no Health Momtors (bottom). This also overndes
any node Default Monitor setting.

Assigning monitors to pool members

Like nodes, there is another group monilor assignment at the pool level. A pool member can have a
monitor assigned specifically to it, Or its monitor assignments can be derived from the monitors assigned
at the pool level, as shown in Figllre 10. A pool member can also be configured to have no monitors
associated with it. Unlike nodes though, a pool member's default monitor assignment is nol set at a global
level (for all pool members on the system) bul is inherited instead from tbe member' s pool.
• Inherit From Pool - Monitor assignments for tbe specified pool member are derived from the
pool's configuration settings.
• Member Specific - Monitor(s) can be assigned to a specific pool member
• None - A pool member can be configured to have no monitoring
General Properties
Name
Application CDurse_Administering
Partition I Palh Common
DescripUon
Avalleblltly II Available (Enabled) - The pool Is available

Configuration: BasicI
Active Available
'CDtnnlOn
Heanh Monitors El gatew8Y_icmp

http
El http_heod_1S
http"
I Update 11 Oelele I
Figure 10: All members in pool http""pool wilfbemonitored using the my_ http monifor, unless certain pool members
have Member Specific or None for their Health Monitors setting
To activate a default monilor for all pool members in a pool :

l. Navigate to Local Traffic »Pools.
2. Select the pool you wish to configure monitors for by clicking on ils name.
3. In Ihe Configuration seclion, selecl the monitor(s) you want to use and activate tbem by clicking
Ihe « button 10 move Ihem from the Available column 10 Ihe Active column .
4. When all desired monilors have been aclivaled, click Update to save your changes.
5. For each pool member the default monilor(s) sbould apply to, selecllhe member's configuration
and ensure Ihal Health Monitors is sella Inherit From Pool.

When a defaul t heal th monito r is made ac tive at the pool level, all pool mem bers in the pool w ith their
Health Monitor setti ng con fi gured to Inherit From Pool will be checked by those moni tors.
A pool member can be assigned monitors individually with the Member Specific setting. Member
specific monitors are used inslead of the pool's default monitor, not in addi tion to the default monitor.
If a pool member is con fi gured with the Health Monitors setting of None, no moniior checking is
performed for thai p ool member regardless ofthe pool's default monitor settings .
Monitor Instances
When you associate a mo nitor wi th a reso urce such as a node, the BIG-JP system auto matically creates
an instance of that monitor for tbat node. A mo nitor associati o n thus creates an instance of a mo nitor fo r
each resource that you ass ign it to. Thi s means tbat you can bave multiple instances of tbe same monitor
running on your nodes and poo l members,
You can view the instances of a particular monitor by naviga tin g to the mon itor definitio n and then
c licking on the Instances tab, as shown in Figure JJ.
Monitor Instances: lemp
Node Name Service Partitlon I Path
172. 16.20.1 172.16.20 1 Common
172- 16.20.2 172.16.20.2 Common
172 1620 3 172.16 .20 .3 Common
Figure 11: A monitor's Instan ces tab shows which resource s the monNor is currently associated with (checkingJ- In
this example, the icmp monitor is checking the health of three nodes via ping
5-16 Adm inistering BIG-IP v11

Managing Pool, Pool Member, and Node Status

Lesson Objectives:
At the end of this lesson, you will be able to describe how the states of virtual servers, pools, pool
members and nodes change as the result of monitoring.
Understanding Object Status

In LTM, monitors are assigned to nodes, pool members, and
pools, but the resu lts of monitor checks have an effect on
the status of virtual servers, as well. This is due to the
( Vlnual
Server
)-.
parent-child hierarchy tbat exists between these objects, as
In large part, a child object inherits its status from its
( Pool
I
Pool
parents. For example, ifat least one pool member is
Member
avai lable, the pool's status will show as available. On the
other hand, ifall pool members in a pool are marked
amine, tben the pool is also marked oilline. And if that
same pool is the only pool associated witb a virtual server,
( Node
)
the virtual server will also be marked as offline.
Figure 12: Object status rolls up from th e parent
node level to th e virluaJ seNer level
Object status and object state
An object's status is detennined by its bealth check results,
and by the slate the object is set to. A BIG-lP Administrator can change an object's state using the
Configuration utility or tmsh:
• Enabled - The object is eligible to receive traffic.

• Disabled - The object continues to process persistent and active connections. It can accept new
connections only if the connections belong to an existing persistence session .
• Forced offline - The object is eligible to continue serving existing connections only (and only if
tbey don't time out); no new connections are allowed.
Object state is frequently changed by a BIG-IP Administrator, when getting ready to perform
maintenance on a server or when recovering from an error situation. When an object's state is changed by
an Administrator rather than a health monitor, or if the health monitor is configured with tbe Manual
Resume option, the status indicators displayed in the Configuration utility are black althougb the shapes
remain the same.
The Configuration utility indicates status by displaying one of several icons distinguished by shape and
color:
• The shape of the icon generally indicates the status that a monitor has reported for that object
• The color of the icon indicates the actual status of the object

The table below shows the icons and their general meaning.
Indicator Meaning Indicator Meaning
(Green
Object is enabled and available (able A
(Yellow
Object is enabled but currently
unavailable (e.g. connection limit
to receive traffic)
has been reached)
• •
circle) triangle)
Object is enabled but offline because The status of the object is unknown;
(Red a health monitor has marked the (Blue
it may not be monitored or the
diamond) object as unavailable (down). square) monitor has not timed out yet
Object is operational but its state has Object has been manually forced
(Black been manually set to disabled (Black offline
circle) diamond)
Interpreting Node Status

Indicator Color/Shape Explanation
-----
Green circle Node is enabled and able to receive traffic
Node is enabled but currently unavailable. It may become available
A Yellow triangle
later with no user action required. Example: Connection limit reached
• Red diamond
Node is enabled but offline because an associated monitor has marked
the node down. User intervention is required.
•
Node status is unknown. Possible reasons include :
Blue square • No monitor associated with the node
• Monitor results not available yet
•
• Node is set to disabled although monitor has marked node as up.
Black circle Enable the node to resume normal operation.
• Node is set to disabled and is down.
•
Node is set to disabled and is offline either because a user disabled it or
a monitor has marked the node down . If a user disabled the node , you
Black diamond
may be able to enable it again to resume normal operation (depending
on why it was disabled to start with).
Interpreting Pool and Pool Member Status

BIG-lP determines the statu s of a pool based on the availability of the members of that pool. The
availability ofa pool member is determined by its health check results, and by the state the pool member
is set to.
The availability of a pool member may be overridden by the availability of its parent node. For example,
if you assign the [CMP monitor to node [72.[6.20.1 and the HTTP monitor to pool member
172.16.20 .1:80, even if the HTTP monitor reports the pool member is up, if the parent node fail s the
health check, the pool member will inherit the down status of the parent node.

Pool status indicators

Indicator Color/Shape ~xpl;;;
a-.;
n_ti;:..n
a;:..o...;_ _ __
Green circle At least one pool member is available to process Iraffic
•• Yellow Iriangle
Red diamond'
No pool members are currently available but may become available
later with no user aclion required . Example : Con~ection limit reached
All pool members are unavailable and cannot accept Iraffic. User
intervention may be required.
Slatus of at least one pool member is unknown and no other pool
• Blue square
Pool member status indicators

members are available. Possible reasons include:
• One or more pool members has no associated monilor
• Monitor results nol available yet

Pool member is enabled, parenl node is up and monitor has marked the
Green circle
pool member as up.
Pool member is currently unavailable but may become available later with
.. Yellow triangle
no user aclion required. Example: Connection limit reached
•
Pool member is unavailable. Possible reasons :
Red diamond • Parent node is down
• Monitor has marked pool member down
• Blue square
Pool member has no monitor associated wilh it, or no monitor resulls are
available yet.
• Pool member is set to disabled although a monitor has marked the
•
pool member as up. Enable the pool member to resume normal
Slack circle operation.
• Pool member is set to disabled and is offline because parent node is
down.
•
• Pool member is sella disabled and is offline because a user disabled
it.
Black diamond
• Pool member is set to disabled and is offline because either the parent
node is down or a moni!or h~~~~~,:?_th ~!'?'?L~em~er ~_~~~.: __
Virtual server status indicators

Green circle Virtual server is enabled and able to receive traffic.
•• Yellow triangle
Red diamond
Virtual server is enabled but currently unavailable . It may become
available later with no user action required . Example: Connection limit
reached
Virtual server is enabled but offline because an associated object has
••
marked the node down. User intervention is required .
Blue square Virtual server status is unknown but is still able to receive traffic.
Virtual server is operational but set to disabled . Enable the virtual server
Black circle
to resume normal operation.

Checking Object Status

Checking object status using the Configuration utility
The following table lists Configuration utility pages where you can check the statlJ s of vari ous objects:
Configuration utility page Description Location

Network map Summary of virtual servers and Local TraffIC » Network Map
objects associated with them (e.g.
pools, pool members , and nodes)
Virtual servers Currenl stalus of virtual servers Local Traffic » Virtual Servers
Pools and pool members Current status of pools and pool Local Traffic » Pools
members
Nodes Current status of nodes Local Traffic » Nodes
Checking object status using the command line
The foll owing table shows the tmsh commands you can use to check the statlJs of vari ous obj ects:
Description tmsh command
Summary statistics t ms h show /l t m vir t ual <v irt ual server n a me>
Virtual server status t ms h show /ltm virtua l <vi rtual serv e r na me >
tms h show /l t m pool <poo l ~n a me >

Pool/pool member status
tmsh list /ltm pool <pool _ n a me> all - p roper ties
Node status tmsh show /ltm no de <nod e I P >
---

Determining which Monitor Triggered a Change in Status

In configurations where multiple health monitors are assigned to a single resource, you might want to
know which health monitor caused a change in the availability (status) of a resource. You can make this
detennination by drilling down to the resource's definition (e.g. node or pool member).
Member Properties
Node Name 172.16.20.2
Address 172.16.20.2
Servl,. Port 80
Per1itlon I Path Common
Otscrtp110n
Pllf8nt Node '72,16.20.2

Avaftablllty • O~Une (Enabled) - Pool member has been marked do'Ml by ill monitor
Health Monitors
Member Properties
Node Name 172.16.20.2
Address 172.16.20.2
SIN\c:e Port 80
Oesct1pllon
Par.m Node • ,n ,. "".2

Availability . Avallable (Eni!lbled) - Pool member Is available
Heanh MonIors • m'I_bO:CU 1t1p

. my_n"p
Figure 13: BIG-IP correlates the avera/} status of a resource with the status produced by each health monitor
assigned to the resource, as shown in the se two examples.
At the top of Figure 13, pool member 172.16.20.2:80 is being checked by two http-type health monitors:
mLhttp and mLbad_http. More importantly, mLbad_http's health check has failed, as indicated by
the red diamond to the left of its entry in the Health Monitors area. In this particular case, the monitors are
configured such that all checks need to be successful if the pool member is to be marked as available.
Since one has failed, the pool member has been marked amine, as indicated by the red diamond in the
Availability area.

At the bottom of Figure 13, we've changed the way the monitors are configured such that just one
successful monitor check is required for pool member 172.16.20.2 in order for it to be marked as
available. In this case, even though my-bad_http has failed, my-http is returning a successful result.
Therefore, the pool member has been marked as available for traffic processing, as indicated by the green
circle in the Availability area.
Note: Monitor availability requirements are configured under the Configuration:Advanced view,
and these settings are discussed in more detail in the Configuring L TM course.
Monitor status changes in the BIG-IP local traffic log

In v 11.4, the BIG-IP system now also logs by default specific dewils regarding which health monitor
caused a change in availability of an object. You can find this infonnation in the /varlloglltm file, or by
viewing the log using the GUI at System » Logs » Local Traffic.
For example, the following sample output shows that the my_http monitor is identified as the health
monitor that caused a change in the availability of pool member 172.16.20.1:80 in pool http-"ool. The
parts of interest have been underlined:
Pool/Common/http pool member /Common/172.16.20.2:80 monitor status
down. [ /Common/my http: down, /Common/tcp: up 1 [was up for
Ohr:2mins:37sec 1

Using the Network Map
Lesson Objectives:
At the end of this Jesson, you will be able to use the Network Map feature to assess the status of virtual
servers, pools, pool members, and nodes.
Using the Network Map

The Configuration utility's network map feature provides a centralized view of local traffic objects from
a virtual server perspective. For each virtual server configured on the BlG-lP system, the network map
shows its status and the status of its associated pools, pool members, nodes, and even iRules - in two
different displays that are filterable and searchable.
Local traffic summary

For each object type, the local traffic summary displays the total number of each object in the current
running configuration (only as it relates to virtual servers and their associated objects) and the number of
objects in each type with a given status.
l ocal TflllIIC !al.m m3ry

..... _. . . . . .
• """" ~ Unkn_1
.-
~.
otItKI TJtlI T~ ~
, • ,0
Vh111~ Servers (I
0
• ,
Pool Members 9
, • 0
0 3
""'""
iRul 8:fi 0
0
"
Figure 14: Example of a local traffic summary dispJay on the ne/work map page
Local traffic network map

The local traffic network map presents a visual hierarchy of the names and status of virtual servers and
their associated pools, pool members, and iRules on the running configuration. The map shows all objects
in context, starting with the virtual servers at the top.
LOGII TllImc NetwOf1l. UiJp
• ""-"110.... ""_1'1.....
• mr_'1IJUOOI
• 117.11.2C.1!80
• H:!,HUO.l::flO
•
...
",_ftGQ
•
•
....."...
H2..tft.20.1;SO
1'11..1!UO.2;aO
-
.'
CI .........nttPI
.
.
............
1n.1G.2(].1:U3
112.tI.2fI.2=44.]
.--
• 1n.li!UO.l~IfIC • 1n.16.2'0..3:10 • U2.1e.2Q,~
a ft _llIltp7
•
. '"1.. .. . ,. .
l11J _otfte.r.wel'-'l!tp_~.t
• 112. HI,21], UU
~ IIIlfD...JJDOl2
g H.2.10'2'0 1.aO
• "-sst.
• t7l.1f.2ll.1:21
Q 112.HI.2tI.HO • 1T2.1I.2(1.2:22
• ,n.1UD.:lID . ,n.11!.2IU92
Figure 15: Example of a local traffic network disp lay an the nelwork map page

When you position the cursor over an object on the map, the system presents hover text containing
additional information about the object, such as the parent node on a pool member, and destination
address on a virtual server.
When you position the cursor over the status icon that accompanies an object, the system presents hover
text containing additional information about the object's status.
Filtering the display results

You can filter the results of either display using the Type and Status lists in the filter bar that appears
immediately above each display, as shown in Figure 16. With the Search box you can optionally a
character string in the search operation. For example, if you constrain the search to include only available
pool members whose IP address includes 172.16.20.3, the operation returns those nodes, along with the
child pool members, the pool itself, and the associated virtual service, and any iRules that are explicitly
applied to that virtual server. The system sorts the results alphabetically, by virtual server name, and the
objects that match the filtering criteria are highlighted.
Soard> 117:!-1' 20.3 '1

1- """""""11_... .... :
Loc.III f.nfk. Hll!'twor"k Ma9
• rllJ'_.DP.....bBp_W1U81
• ""...Jorro.J>O(ll
• 'fi!.'&.20.I;!O
0;-:--,
1 .
•
,71.1 4.20,'::10
t n .UL20.2:lC
...-
·"tU/;S;tI
1
•
•
I n .1 Q..'-O . 1 ~.2'
In.'ft.~.2:22
.
• 172.1B-2Q,2:8Q
•
. l n l fa.20 .J:80
..,..............
""_Qtt.r.w!tII_lIIltp_.... rtullll
.
•
,n. 1ft....1O .1::11O
1T2.16-20.:2:8Q
. o 172.1..,'"",'
,_,,_,Up>
"...........
•
•
, n.l6.:ztLl~44'J
172..16..2C1..2:44:l
1 0 11>.11,20.':2'
• 17MS.~. 3;80 • 112.UL2(I.,]]"J
Figure 16: Using the filtering mechanisms - s ra/us, Type, and Search - to limit the displayed results
Search strings can refer to object names, IP address, and IP address:port combinations (in both IPv4 and
IPv6 formats). The string is processed with implied wildcard characters (asterisks - *) surrounding the
string. For example, a search on the string 10 is the same as entering the search string as *10*. You can
specifically include wildcards in the search string. For example, a search string 10.* will only highlight
objects whose IP address first octet is 10.
Tip: Browsers have limits as to how much data they can render before they become sluggish
and halt processing. Mapping large configurations might approach these limits, or memory
constraints might prevent the system from producing a network map of the whole configuration.
If this occurs, the system posts an alert indicating that you can use the Network Map to
determine the complexity of the configuration which, in turn, can give you an indication of the
size of the resulting map. You can then modify the search criteria to return fewer results,
producing a map that does not encounter those limits.

Chapter Resources

SOL 13898 Determining wh ch monitor triggered a change in the availability of a node or pool
member (11.x)
SOL 12531 Troubleshooting health monitors
SOL 13310 Disabling nodes or pool members for maintena~ce (11.x)
SOL5917 Using. regular expressions in a health monitor Receive String
SOL6143 UDP health monitor operation
SOL 1033 Configuring an HTTP application health monitor to send a POST request
SOL2167 Constructing HTTP requests for use with the HTTP or HTTPS application health
monitor
S0L11681 Overview of the Diameler monitor
SOL6914 Overview of the WMI performance monitor
S0L14407 Change in Behavior: The BIG-IP system now displays which monilor Iriggered a
change in the availability of a node or pool member
SOL7440 Overvie.w,o!,passive healt~ m_onitoring

,
5.1 Configure Monitors Lab
Objectives:
• A ssign health monitors to nodes and pool members
• Create a custom monitor
Lab Requirements:
• Access to a BIG-LP provisioned with LTM with at least one pool with two working members
• Some knowledge of the tratlic sent by the members
Configure Monitors for Nodes

Check current nodes' status
I. Examine the current status indicators for all nodes and answer the questions in the space
provided.
Node Ust section
What are the nodes' statuses? !J; f:';v... ~1t

Will BIG-IP load balance traffic
to nodes with status V :0
Unknown?
When complete, click.. . Default Monitor tab in menu bar
Assign a default monitor to all nodes

2. Add icmp as the default monitor for all nodes (continues from the previous step)
Select icmp
Health Monitors
Press « button
When complete, click... I Update then click the Node List tab in menu bar
Note: Each time the Node List tab is clicked, the screen will refresh.

Chapter 5 - Monrtoring 5-27
£
(-Iv <"I.~ 'J V
3. Recheck node status indicators. What are the nodes' statuses? Was the change imroediate'V , /~
At this point, each node is being tested with the default icmp "ping" monitor. Remember this monitor
only checks the status of the parent node, not the various child pool members that you now have
configured at ports 80, 443 and 22.
Configure Monitors for Pool Members

Check current pool members' status
4. Examine the current status indicators for the pool members in httpyool
Node list section
What are the pool members'

statuses?
Will BIG-IP load balance traffic
to pool members with this
status?
Assign a custom monitor to a pool

5. Create a new HTTP monitor called my_http but with no customizations - yel!
6. Add my-http as the default monitor for all pool members in httpyool
Select my_http
Health Monitors
Press « button
When complete, cUck... Update then click the Members tab in menu bar

7. Recheck pool member status indicators. (Each time you click the Members tab, the status will be
updated.) What are the pool member~' statuses? Was the change immediate?
' / I 2 ~ Lt I";
Customize the monitor and check status again
8. Customize the my_http monitor by adding a specific Send String and Receive String relevant to
our application .
Update
9. Check the pool members' statuses again. (Each time you click the Members tab, the status will be
updated.) What are they now? Why? Was the change immediate?
[0. What is the status ofpoo] httpyool? [s this what you expected? Why or why not?
[1. What is the status of virtual server vs_http? [s this what you expected? Why or why not?
Modify the custom monitor

12. Update my_http monitor's Receive String setting to use a regular expression, changing the
scope of the receive string.
Note: The string "[1-3]" in the Receive String below is a regular expression that implies "match
any single character in the range 1 to 3"
13. What are the pool members' statuses now? Why? Was the change immediate?

Chapter 5 - MOnitoring 5-29
Expected Results and Troubleshooting

When the Receive String was set to Server 2, only pool member 172.16.20.2:80 returned a value that
matched. The other two pool members, 172.16.20.1:80 and 172.16.20.3:80 returned Server I and Server
3 respectively, and were therefore marked by the monitor as unavailable (red diamond) to process traffic
after the timeout value expired.
When you changed the Receive String to Server [1-31. each pool member in pool httpJlool was now
checked for content matching the character string "Server" followed by a space, followed by either a " I"
or "2" Or "3". All pool members returned content that matched the expression, so the monitor marked
their status as available (green circle) to process traffic immediately upon receiving a successful test
response.
The changes in pool member status mayor may not appear immediately. It depends on the monitor's
Interval and Timeout settings, and the time it takes for a monitor test to complete successfu lly. If you
look at these settings for my_http monitor, they are 5 second interval and 16 seconds timeout. Ifa
monitor tes t is successfu l, the monitored resource is marked as available (green circle) immediately. If a
monitor test fail s or there is no response within the specified interval, another test is issued. If there is no
response or all responses are failures within the specified timeout, the mon;tored resource is marked as
unavailable (red dia mond). Monitoring tests continue at each specified interval. If and when a successful
test response is received, the monitored resource will be marked as available again .
STOP

5-30 Chapter 5 - MOnitoring

Chapter 6 - Modifying Traffic Behavior with Profiles 6-1
Chapter 6: Modifying Traffic Behavior with

Profiles
Chapter Objectives
• Describe what profiles are and how they are used on the BIG-IP system
• Descri be the parent-child profile relationsbip and tbe effect on the ch ild pro fi le's settings
• Describe proftJe dependencies and exclusions and cite at least one example of each
• Descri be the benefits of using SSL tennination on the BIG-IP system
• Configure a virtual server to use client SSL tennination
Introducing Profiles
Lesson Objectives
At the end of this lesson, yo u will be ab le to describe what profi les are and how they are used on tbe BIG
IP system to affect traffic behavior.
Why Use Profiles?

Wben dealing with large confIgurations, two key problems ex ist:
• Traffic management attributes need to be repeatedl y configured across all objects
• Changing settings across these objects can be tedious and complicated
Profi les are powerful configurat ion objects that provide an easy way for you to define traffic behavior and
then appl y tbat beha vior across many vi rtual servers, effecting changes more e ffici ently. More
importantly profi les give you the power to:
• Modify the behavior of certain types of network traffic;
• Reduce the need for costly infrastructure upgrades in response to changes and developments in
external technologies;
• Help increase perfonnance and throughput on the network; and
• Omoad work fro m internal application servers
More specifica lly, a profile is a configuration object that contains settings that control the behavior ofa
particular type of network traffic, such as HTTP connections. Profiles also provide a way for you to
enable connection and sess ion persistence, and to manage client application authentication .

6-2 Chapter 6 - Modifying Traffic Behavior with Profiles
Client Server
virtual server
-
Tra ffic behavior
cookie persistence
-
one connect
En Unencrypted
optimilsd caching
wan optimized
Uncompressed
-
Com com ression
http
WAN 0 m ized
-
tcp-lan LA N
Figure 1.- Profiles affect the behavior of traffic as if flows through the BIG-IP system, and are used for many reasons
includmg offloa.(ling work from back-end servers, connect;ng disparate networks, and allowing for optimum tuning of
traffic flow over different types of connectiotis.
For example, if you want to encrypt traffic on the client-side connection but have the server-side
connection's traffic unencrypted, you can assign a Client SSL profile to the virtual servers that process
that traffic. [fyou want to compress data between the client and BIG-IP but not between BIG-IP and the
back end servers, as illustrated in Figure I, assign an HTTP compression profile to the virtual servers
where that behavior is desired.
Reduce the complexities associated with rapidly evolving network technology

In short, profiles on the BIG-lP system provide a means for a company to adapt to new network protocols
and technologies without the need to introduce new devices or modify back end application systems.
Since the BIG-lP system acts as a full proxy between the internal and external networks, a profile allows
the BIG-IP system to intercept and change traffic behavior before handing that traffic off to your
applications to process.

Introducing SSL Termination
Lesson Objectives:
Upon completion of this lesson, you will be able to:
• Articulate some of the benefits ofusing client SSL termination
• Configure a client SSL profile and assign it to a virtual server
Client-side SSL Termination

Normally, a packet is encrypted from end-to-end in a typical
SSL client-server connection, as shown in Figure 2. This
means that the server is responsible for negotiating certificates
and keys. If hardware acceleration is desired to help take the
load off the operating system, then each server must have an
SSL accelerator card. That can be an expensive proposition
Packet
when hundreds or thousands of servers are involved. encrypted
A BIG-IP virtual server can act as the end-point for encrypted end-to-end
SSL-encapsulated sessions such as HTTPS, as shown in
Figure 3. Once the traffic is decrypted by the BIG-IP system,
Layer 7 features, such as cookie persistence and iRules can be
applied before the traffic is sent to a pool member.
There are numerous advantages to this arrangement:
• Pool members avoid tbe overhead associated witb
processing encrypted traffic, resulting in better server
performance and reduced cost si nee each server does
not need an SSL accelerator card.
• A single SSL certificate installed on the BIG-IP Local
Traffic Manager system can take the place of
certificates installed on each pool member, resulting
in additional offloading of certificate verification
tasks. Figure 2: In (J normal SSL connection. traffic is
GncryplQd from end-la -end.

6-4 Chapter 6 - Modifying Traffie Behavior with Profiles
DOD
Virtual Server Profile

~
Encrypted
tlH I-Hfi :- -:. L" .
Unencrypted
Figure 3: Glient SSL terminatJon on the big-tP system
Traffic flow through BIG-IP with client SSL termination

Figure 3 illustrates the now of traffic wben a client SSL termination profile, such as client-ssl , is assigned
to a vi rtual server on BIG-lP.
I. Client traffic is directed to the virtual server. It arrives encrypted and BIG-IP acts as the server
during SSL negotiations for the client-side connection.
2. When BIG -IP receives the traffic, the c1ient-ss! profile settings instruct the virtual server to
establish an SSL session with the client and decrypt the traffic. BIG-IP Loca l Traffic Manager
then typically load balances the traffic to one of the pool mem bers associated with the virtual
server. Other ac ti ons from other profiles, such as persistence, or from iRules could also be applied
to the traffic .
3. BIG-IP establisbes a connection to the selected pool member, delivers the clear text
(unencrypted) traffic, which is th en processed by the pool member. The pool member returns the
response in clear-text to BIG-lP.
4. BIG-IP encrypts the response using the client-ss! profile settings assigned to th e virtual server,
and sends the encrypted response back to the client.

SSL Acceleration
Server performance can be severely affected by the process of encrypting and decrypting SSL traffic.
Tests show packet processing times increase by a factor of 20-30 when SSL encryption is used. Installing
an SSL accelerator card can help servers that are processing SSL traffic. Such cards use hardware instead
of software to encrypt and decrypt traffic, resulting in throughput times that are comparable to non
encrypted traffic. However, SSL accelerator cards are expensive, especially when they must be replicated
through dozens, hundreds, or cven thousands of servers.
Each BIG-IP system is built with one or more SSL accelerator cards or chips, and is licensed to provide a
maximum number of client-side SSL transactions per second (TPS). Specific Iirnits are determined by the
license on the BIG-IP system. These independent processors allow the BIG-IP system to perform both the
SSL key exchange and bulk crypto work via hardware components rather than software components.
F5 recommends that you monitor traffic volumes in order to allow the license lirnit to be proactively
managed. You can configure BIG-IP to send an email message to a specified address or to send SNMP
traps whenever a message is logged as a result ofthe SSL TPS limit being reached.
For information about SSL TPS log messages and notification options, refer to S0L7747: Error
message: 'SSL transaction (TPS) rate limit reached' or 'no SSL TPS or run out'
Enabling Client SSL Profiles

When you want to manage HTTP traffic over SSL you can configure the BIG-IP system to perform the
SSL handshake that target web servers typically perform, making BIG-IP responsible for decrypting
client requests before forwarding them to a server, and encrypting server responses before returning them
to the client. In order to facilitate this, you will need an SSL certificate/key pair on the BIG-IP system in
order to authenticate the SSL traffic.
The following general steps are carried out in order to enable a Client SSL profile on a new virtual server:
• Generate a certificate request and send to a public Certificate Authority (CA)
• Install the certificate and private key received from the CA on the BIG-IP system
• Create a client SSL profile
• Create a virtual server and assign the SSL profile to it
Install an SSL certificate on BIG-IP

When BIG-IP software is installed, the system generates a default SSL certificate and key pair named
default.crt and default.key, and associates them with the default SSL profiles. (The default
certificatelkey is required for system operation and should not be deleted.) If your network includes one
or more CA servers, you can replace the self-signed certificate on each BIG-IP system with a trusted CA
certificate (a certificate signed by a third party). Authenticating BIG-IP systems using trusted CA
certificates is more secure than using self-signed certifLcates.
You can install and manage SSL certificates on BIG-IP using the Configuration utility. To configure and
manage SSL certificates, from the Navigation pane, go to System » File Management » SSL Certificate
List. From here, you can create a new certificate, or import a trusted CA certificate/key generated by a
third party
You can install multiple certificates and keys on BIG-IP, allowing each SSL profile that you create to
reference a different certificate and key, if necessary.

For more information on installing SSL certificates for local traffic, please see BIG-IP Local
Traffic Manager: Concepts and BIG-IP Local Traffic Manager: Implementations
Create a custom Client SSL profile

A client profile enables BIG-lP L TM to accept and tenninate any client requests that are sent by way of a
fully SSL-encrypted protocol. LTM supports SSL for both TCP and UDP profiles. To configure and
manage SSL profiles, from the Navigation pane, go to Local Traffic» Profiles» SSL. The table below
shows just some of the configuration settings of a custom Client SSL profi Ie:
Setting Default Value

Name Specifies the user-supplied name of the profile No default value
Parent Profile Specifies the default profile (or existing custom clientssl
profile) from which this custom SSL profile will
be derived
Certificate Specifies the name of the certificate installed default
on BIG-IP that should be used for the purpose
of tenminating or initiating an SSL connection
Key Specifies the name of the private key installed default
on BIG-IP that should be used for the purpose
of terminating or initiating an SSL connection
Pass Phrase Specifies the name of the pass phrase used to No default value
encrypt the key
T rusted Certificate Allows authentication by specifying a list of None
Authorities certificates that the BIG-IP system trusts
Secure Specifies the method of secure renegotiation Require (for Client SSL)
Renegotiation for SSL connections
For more information on configuring a Client SSL profile, please see BIG-IP Local Traffic
Manager: Concepts

Understanding Profile Types and Dependencies
Lesson Objectives:
During this lesson, you will learn how individual profiles deal with specific traffic types, and must
sometimes be assigned along with other profiles in order to affect traffic behavior.
Default and Custom Profiles

Default Profiles
As with monitors, the BIG-LP system comes with a
set of profiles that you can use as is. These are
(F5-supplied) i Parent
referred to as default profiles. If you want to change
the values specified in tbe default profiles, you can
create a custom profile and model it after the default,
as shown in Figure 4. A custom profile is a profile
,J
derived from a default profile or another custom
profile .
Custom
Assigning a Profile to a Profiles
~ Pa rent
Virtual Server
I
Once you've configured a profile, you can associate it
and other profiles with one or more virtual servers.
For example, you can associate a TCP profile, a
cookie persistence profile, and an HTTP profile with
the same virtual server. The virtual server tben Custom
processes traffic according to the behaviors specified Profiles
in the assigned profiles' settings.
A profile can be assigned to a virtual server at the
time tbe virtual server is created, or can be added to a
virtual server later on. It is not unusual for multiple Figure 4: Illustration of profile parent-<:hild relationship
profiles to be assigned to a single virtual server,
especially in light of profile dependencies, as presented in tbe next lesson.

Profile Types
Profiles are grouped to make configuration clearer. Typically, a virtual server will have only one profile
of any given type assigned to it. Some profile groupings are shown in the next tabl e.
Profile Types
Protocol Profiles
Usage Profiles Types
Control timeouts and connection management. All Fast L4 TCP
virtual servers must have at least one protocol Fast HTTP UDP
profile assigned to them . LTM assigns a default HTTPClass SCTP
depending on the virtual server's protocol setting .
Application-Layer Profiles
Intelligently control application layer traffic HTIP RTSP
including inserting headers into HTTP requests HTIP Compression Diameter
and compressing HTTP server responses. FTP RADIUS
DNS XMP
SIP
Session Persistence Profiles
Ensures client connections are directed to the Cookie SIP
same pool member throughout the life of a Destination address affinity Source address
session or during subsequent connections. Hash SSL
RDP Universal
SSL Profiles
Intelligently control SSL traffic: authenticate clients SSL connection termination and initiation
and servers; offload SSL cert verification tasks Client and server authentica tion
Remote Server Authentication Profiles
Authenlicate client traffic separately from LDAP SSLOCSP
underlying authentication technology (PAM RADIUS CRLDP
support) TACACS+ Kerberos
SSULDAP XMP
Analytlcs Profiles
Application statistics data collection Analytics
Other Pro Illes
Specific traffic behavior management. OneConnect Stream
NTLM Request Logging
Statistics

Profile Dependencies
Profiles can both complement and contradict each other. More
specifically, some profiles are dependent upon others, and some .. Coo1<1e Persistence I
combinations of profiles are not allowed. As a general rule: ~
,
..
J
• Profiles of a given layer of the OSI model are often '"
1:
dependent upon profiles that work at lower layers. (/) IHTlP FTP
fti
• Profiles at the same OS! layer are mutually exclusive on a :::J
~
u_ ,
L ~. J<lI
single virtual server, meaning they cannot co-exist. :>
• All virtual servers have a Layer 4 profile assigned (for "TCP X.UDP I
TrOinsport
example TCP) J
Some of these dependencies and exclusions are illustrated in

Figure 5. Note that although there are no profiles at Layers 1-3,
some of the information from those layers is available to profiles
at Layer 4 (e.g. IP address). Here are some examples of profile
dependencies and exclusions:
L~' LI '''~
Some profiles depend on other profiles

Figure 5: Some profiles are dependent on
As shown in Figure 5, if a certain web application's traffic others, and some are mutually exclusive
behavior requires persistence, and you want that persistence
to be based on a cookie that is passed between the client and the BIG-lP system, then a cookie persistence
profile can be assigned to the virtual server. But, since cookies are part of the HTTP protocol, the virtual
server could not know what a cookie is unless it also has an HTTP profile assigned. Finally, since HTTP
uses TCP, the virtual server must also be assigned a TCP profile.
Some profiles are mutually exclusive with other profiles

Profiles that are mutually exclusive often support the same layer in the OSI Reference Model. For
example, a typical standard host virtual server cannot have both TCP and UDP profiles assigned, nor can
it have both FTP and HTTP profiles assigned, as shown in Figure 4. Although it would be rare to try to
combine FTP and HTTP, it is not uncommon to have an application that uses both TCP and UDP in its
operation. The latter case is often addressed through the use of two virtual servers, one with a TCP profile
and the other with a UDP profile.
System profile defaults

For each profile type, the BIG-IP system includes a default profile. Default profiles are stored in
/conligiprofiJes_base.conf and should not be deleted. F5 recommends that you use these default profiles
to create custom profiles that meet your specific network needs. You should not modify a default profile!

6-10 Chapter 6 - Modifying Traffie Behavior with Profiles
Configuring and Assigning Profiles
Lesson Objectives:
• Create a custom profile and assign it to a vi rtual server
• Articulate how a custom profile inherits changes from its parent profile
Custom Profile Configuration

When you create a custom profile, you give tbe profile a name and then almost immediately refer to an
existing profile to act as its parent, as shown in Figure 6. The parent profile can be anyone of the BIG-IP
system's default profiles or another existing custom profile of the same type. The new profile becomes a
cbild of the parent profile. This parent-cbild relationship remains for the life of both profiles, and can
carry implications when the parent is modified.
Local Traffic u Profltes' Services: HTT1

-
,,~~(..'. HrrP 0((·1 I"
o
General Properties
Name
Parent Proftle I ~ttp H

•
Figura 6: Custom profile my_ httpyroftle becomes the child of parent profile hNp
Parent-child relationship when the parent is modified

Whe n a child profi le is created, its initial setlings (before customization) are inherited in their entirety
from the parent profile. Generally, one or more (or all) of those inherited setlings will be customized in
thc child.

The profile creation screen contains a check box to the right of each customizable profile setting, as
shown 00 the right in Figure 7. When you check a custom box for a setting in tbe child profile, that
setting is now considered customized. More importantly, the setting's value in the cbild is retained even if
the corresponding setting value in the parent is subsequently changed. Thus, checking tbe custom box for
a setting io the child ensures that the parent profile never overwrites that setting's value in the child
through inheritance.
For example, in Figure 7, client SSL profile Pr_Client_SSL is a child of parent profile clientssl, one of
the default profiles on the BIG-IP system. The only custom setting in Pr_Client_SSL is its Certificate
value. If the Certificate value in clientssl (the parent) ever changes (not that it is likely to), the Certificate
value in Pr_Client_SSL (the child) remains unchanged. However, if the Proxy SSL value in clientssl ever
changed to a defaul t of enabled (checked), the Proxy SSL value in Pr_Client_SSL will also change to
enabled (checked) as the result of inheritance .
.....
"..-on I,. ...
-
- _--",,I
I...'m...._ _...
--
~
-,
-
FIgure 7: A ch,1d With a custom configuroflon serting will not inherit any upda fes to that setting from its paron!
Note: If you check the Custom box at the top of the Settings area when creating a new profile,
all profile settings within the child become customized, even if no values are actually changed
from their initial inherited settings. Any changes made subsequently in the parent profile will not
be inherited by the child.
Deleting profiles
A custom profile that is parent to one or more child profiles may not be deleted unless the child profiles
are deleted first.
Note: Default profiles may never be deleted , even if they have no children.

Assigning profiles to a virtual server

Once you have created a profile for a spec ific type of traffic, you can assign it to one or more virtual
servers. Whenever the virtual server receives that type of traffic, the BIG-IP system applies tbe profile
setTings to tbat traffic, thereby controlling its behavior.
Because certain kinds of traffic use multiple protocols and servers, it is often necessary to associate
multiple profiles with a single virtual server. For example, a client appLication tbat uses the TCP, SSL,
and HITP protocols and services to send a request, at leasttbree profiles are required - one for TCP, one
for SSL (at least), and one for HTTP. Also, as discussed earlier in this chapter, there are certai n profile
dependencies and exclusions that can afTeet how profiles are assigned to a virtual server.
You can use either the Con.figuration utility or tmsh to associate one or more profiles witb a virtual server.
When using the Configuration utility, profile settings are contained in many page sections that lie beneath
the virtual server's General Properties section, as shown in Figure 8.
Configuration: Basic
Protocol
HTTPPro1lle None ..
FTP Profile
RTSP Profile
Selected Available
JCommon
El clientss\
SSl Profile (CHent)
[ El
clientssl-insecure-c(
wom-default-clients!
Selected Available
/Common
SSL Profile (Server)
[ El
EI
apm-default-servers!
serversst
serverss~insecure-c
wom-default-servers
J
...J - ~ - -
VlAN and TUM_I Traftic
Source Address Transtation ~ Auto Map ..
Figure 8. Profile settings are generally found in the Configuration section of a virtual server's defmition on the GUt
You may need to scroll down or expand the Configuration setTing from Basic to Advanced in order to
find tbe appropriate profile setting option.
Content Rewrite (new in vi 1.4) and Acceleration profiles have their own sections towards the bottom of
the virtual server's page. Persistence profiles are applied on the Resources tab of the virtual server's
page.

ChapterReso~r___
ces _________________________
Solution Solution Title
Number
SOL 14488
Working with profiles
SOL4707
Choosing appropriate profiles for HTTP traffic
SOL7559
Overview of the TCP profile
SOL 14783
Overview of the Client SSL profile (11.x)
SOL 14806
Overview of the Server SSl profile (11.x)
SOL 13171
Conf.iguring the cipher strength for SSL profiles (11.x)
SOL 13136
SSL ciphers used in the default SSL profiles (11.x)
SOL 13163
SSL ciphers supported on BIG-IP platforms (11.x)
SOL 13213
SSL ciphers that are fully hardware accelerated on BIG-IP platforms (11.x)
SOL 13349
Verifying SSL certificate and key pairs from the command line (11.x)
SOL 13579
Generating new default certificate and_.key pairs for BIG-IP SSL ~o!!les

6-14 Chapter 6 - ModifYing Traffic Behavior with Profiles
Lab 6.1 - Client SSL Termination Lab
Objectives:
• Create a Client SSL profile, assign the profile to a virtual server, and observe the change in traffic
behavior between the BlG-LP system and the pool member.
Lab Requirements:
• Existi ng pool bttpjlool (pool mem bers port 80) and pool httpsjlool (pool mem bers port 443)
Create a New Virtual Server and Assign a Client SSL Profile

Create a Client SSL Profile
l. Create a Client SSL profile called Pr_Client_SSL with clientssl as its parent.
General Properties sectlon
Finished
Add a new virtual server

2. Create a new vi rtual server called vs_ssl at IO.IO.X.I0l:443 and assign pool bttpsjlool as its
default pool.
Resources section:

Test and confirm behavior before Client SSL implementation

3. Open a web browser session to https:1I10.10.X.IOl and accept the SSL certificate.
4. Depending on the browser, you mayor may not see a lock icon somewhere in the window
indicating the session is encrypted and secure. [I' you do not see or cannot find the lock icon,
locate the certif,cate that is being used for the session.
5. Note the pool member address and port displayed in the body of the web page (e.g.
172. 16.20.1:443, 172.16.20.2:443, or 172. 16.20.3:443)
6. Change the default pool for vs_ssl from httpsyoot to bttpyool.
Load Balancing section
7. Test the results of this change by refreshing (Ctrl+FS) the page at https:1Il0.10.x.lOl. Your
connection should fail with an SSL connection error or similar. (If a failure does not occur, you
may need to restart your browser, or test from a different browser.) The connection from your
client to the BIG-[P is encrypted, and the connection from BlG-LP to the back end server is also
encrypted. But because of the default pool change, we're load balancing to a pool member at port.
80 (http) instead of port 443 (https). You'll "fix" this in the next steps.
Add a Client SSL profile to a virtual server

8. Assign the Pr_CUent_SSL profile to virtual server vs_ssi.
Test behavior after Client SSL implementation

9. Refresh your web browser session to https:IIIO.tO.X.IOI. Confirm that the browser session is
still encrypted and secure from the client perspective by examining the certificate again. Also
oote the pool member pon in the body of the web page has changed from 443 to 80. This
indicates the back end connection is not encrypted, as the request from BlG-lP to tbe load
balanced server is now success fully being processed on pon 80 rather than port 443 .
STOP

6-16 Chapter 6 - ModifYing Traffic Behavior with Profiles

Chapter 7 - Modifying Traffic Behavior with Persistence 7-1
Chapter 7: Modifying Traffic Behavior with

Persistence
Understanding Persistence
Lesson Objectives
During this lesson, you will learn how the BIG-IP system uses persistence to direct client connections to
the same server multiple times, rather than being load balanced.
Understanding Stateful and Stateless Applications

In information technology, stateCut and stateless are sometimes used to describe the interactions between
two entities (e.g. end user and web application). Stateless means there is no record of previous
interactions between the entities - and no need for such a record, as illustrated in Figure J. Each
interaction is discrete, unrelated to those that precede or follow, and handled using only the information
that comes with it. Stateful means the entities interact with each other in a manner that keeps track of one
or more preceding interactions (states), as illustrated in the e-commerce-type web application in Figure 2.
Web Application Web Application
User (mysite.com) User (shop.mysite.com)
~Q mysite com ~Q
= (cart 12 3)
shop.mYSlte.com
(cart:o 123)
(home page)
shop.mysite.com
mysile.com/aboul.html cart = 123
• =
add2cart camera
• (about page)
shop.mysile.com
mysile.com/brochure.pd(
• cart = 123
add2cart=CO!Tlluler
(brochure document)
Figure 1: Example of a stateless interaction between a Figure 2: Example of a slatefu/ interaction between a user
user and a web application and an e-commerce web application
Stateless, stateful, and the application delivery network

Today, billions of people worldwide access web applications over various networks including the
Internet. Based primarily on the HTIP protocol, web applications are an economical way for businesses
to interact with their customers and employees through the ubiquitous browser. The ability to update and
maintain web applications without distributing and installing software on potentially thousands of client
computers is a key reason for the proliferation of web applications. But it wasn't always this way.

7-2 Chapter 7 - Modifying Traffic Behavior with Persistence
In its original design, HTTP supported a stateless request-response model for transferring a document
(think web page) from a server to a client. In HTTP 1.0, the request-to-connection ratio was I: I (one
request-response pair per connection). In HTTP vl.l, the ratio was expanded to N: 1 (think keep-alives) to
address the growing complexity of web pages that now required many objects and elements be transferred
from server to client for each request (think html,jpgs, gifs, video, audio, css, scripts). Still, the
underlying HTTP protocol was stateless.
Maintaining State in a Stateless Environment

Unlike documents though, most applications are based on logical flows and processes that are predicated
on the ability to maintain state aCrOSS multiple user interactions. For example, a customer using an e
commerce application might interact with many product pages, adding items to a shopping cart and then
paying for those purcbases during a checkout process. Such interactions are statefut. At the very least, the
application must keep track of who the customer is so as to be able to associate them with their
appropriate shopping cart. But since HTTP is stateless, it seems unlikely that HTTP would be appropriate
for delivering stateful applications. Yet it is, due to two state management mecbanisms: sessions and
cookies.
Sessions
Although not used exclusively by the HTTP protocol, sessions provide a way for a web application to
maintain state across multiple user interactions. When a user connects to a server for the first time, a
corresponding session is created in the server's memory and associated with the connection. Application
developers can use tbat session area as a place to store application-state data such as a customer !D,
shopping cart number, or even page display options.
There are some inherent prOblems with using session data alone to manage application state information.
The session can become disassociated from the connection, if the connection times out (i.e. is idle for too
long). And, the timeout for a connection is typically much shorter than the timeout for a session (often
seconds for a connection vs. minutes for a session). This can result in the session remaining in memory on
the server even after its associated connection has been tenninated due to inactivity. In can also waste
server resources and, more importantly, break the application if not combined with some other state
management mechanism, such as cookies.
Cookies
Cookies are bits of data stored on the client by the browser, and shared between the client's browser and
the web application server via two cookie-related HTTP headers: Set-Cookie and Cookie. Defined in
RFC2965: HTTPSlale Management Mechanism (and by its very name), cookies provide a mechanism for
maintaining and managing state in an HTTP application. The application typically sets the cookie value
using Set-Cookie; the browser shares unexpired cookies back with the application using Cookie; and the
cookies are passed back and forth between browser and application using HTTP.
The browser automatically knows to store a cookie shared by a web application in a file on the client, and
keeps track of these cookies on a per domain basis. Of course, this assumes the user has configured
hislber browser settings to accept cookies.
Many browsers allow you to view cookies stored by your browser, as shown in Figure 3.

N.Ilme ... Valli e ()o ln aln p, Expires I Ma.· Age

c.sm-hU 1137.481 1.382729051083 ~vww. a m .. I f n, 01 No v 201.3 19:2 ...
I ,.,;< i on- I ~ 191· 6517971-1561350 l,amazon.. I Tue, OUa n 2.036 08:0...
session-id rime 2082787<011 amazon.. I rue, 01 Jan 2036 08:0...
se sion token GgBJyCU,OUYlxmio<OYR,OcpoYK2113xOPp H2YG... ,amazo n.. I Ihu. 20 Oct 203 3 Ht.2...
ubid - ma.ln 116-1120115- 11 28102 ,amal on.. I r u ~, 01 Jan 2036 08:0...
x ~ w l..ujd 1d K55yw Q+dW +qyljArAL4 V,JHIVaj IlRVW2W... .amazon.... I I ue, 01 Jan 2036 08:0 ...
Figure 3: Sample cookie data from tin Amazon session, as shown via the Chrome browser's Inspect Element option
Unexpired cookies for a given domain are always passed to the server by the browser in the Cookie HTTP
header. The application on the server can then retrieve the cookies' values simply by asking for them.
Many modem web applications use a session's identifier and pass it along as a cookie, enabling the
application to find the session data on the server, even after the connection from which the session was
created is closed or times out. Through this exchange of session ill between browser and application,
state is maintained.
Stateful applications in a load balancing environment

But what happens if a load balancer such as BIG-IP LTM is introduced into the equation? The first time a
client connects to an application via the appropriate virtual server, the BIG-LP system load balances the
connection to one ofthe virtual server's pool members (server). The server creates a session in memory,
the applicalion obtains the session ill, and passes it back to the client's browser via a cookie in the HTTP
response header. But the next time the same customer connects to the application (assuming the original
connection has now expired), the virtual server's default behavior is to load balance this new connection.
Depending on the load balancing method, the new connection may be directed to a completely different
pool member as the previous connection. A new session is then established on that server, the application
looks for and cannol locate the old session data - even if it has a session ID, as the session is on a different
server - and the applicalion is broken.
Clearly, for this type of scenario, the desired behavior is for all connections - from a given client to this
specific application - to be directed to the same pool
member.
Persistence Concepts
BIG-IP's persistence fealure tracks and slores
persistence data, such as the specific pool member that
previously serviced a client connection, ensuring that
multiple client connections are directed to the same
pool member throughout the life of the persistence
record.
If an application is stateless, there is no need for
persistence. Client connections can be load balanced to
any pool member at any time. And not all stateful web
applications require persistence. There are other state
management mechanisms an application can use Figure 4,· Persistence can be used to direct
besides session data, including cookies, passed multiple clien t connections to the same pool
parameters (GETfPOST data), and databases. member, in support of a stateful web application

But if persistence is needed to support state management for an application, then the virtual server for that
application can be configured with a persistence proHle. The persistence profile instructs the BlG-IP
system to treat client connections differently. Persistence can ensure that a series of stateful interactions
between client and application are directed to the same pool member, as illustrated in Figure 4.
Persistence types
Persistence is a property of a virtual server, and is configured by assigning a persistence proHle to the
virtual server, thus modifying the normal behavior of traffic through that virtual server. Many persistence
types are available on the BIG-IP system, and are distinguished by the way they identify a returning client
connection. In this course, we'll examine two commonly used persistence types:
Persistence Type Description
Source address Directs connections to the same pool member based solely on the source IP
affinity persistence address of a connection.
Cookie perSistence Uses a special BIG-IP cookie shared with the client's browser to allow the client
to reconnect to the same pool member used previously.
You can configure certain types of virtual servers to have a persistence profile. (The default is no
persistence.) When a persistence profile is assigned to a virtual server, the BIG-JP system examines each
connection to that virtual server to determine whether or not persistence should apply. In the case of
source address affinity persistence, the BIG-JP system maintains internal persistence records that
indicate the source IP address - or range of addresses - for which persistence applies, as well as
information about the pool member to persist to. In the case of cookie persistence, if a persistence cookie
is passed in the HTTP request, then persistence applies.
In general, if persistence is found to apply, the connection is directed to the specified pool member. If
persistence does not apply (i.e. the persistence record or persistence cookie has expired), the connection is
load balanced according to the associated pool's load balancing method, and new persistence criteria is
established (e.g. a new persistence record or a persistence cookie on the outbound response).

Introducing Source Address Affinity

Persistence
Lesson Objective:
• Describe how source address affinity persistence works
• Configure a source address affinity persistence profile and assign it to a virtual server
• View persistence records using tbe Configuration utility
Source Address Affinity Persistence

Source address affinity persistence allows connections from a specific source lP address - or range of
addresses - to be directed to the same pool member. When a client connects to a virtual server that has a
source address affinity profile assigned, the BIG-IP system checks to see iftbat client's lP address
matches an IP address or range of addresses (by virtue of a mask) in an existing persistence record . If the
address matcbes , the BJG-JP system directs the connection to the pool member spec ified, as illustrated in
Figure 5.
Persistence Persistence Virtual Pool Pool Member Age

Value Mode Server
10.10.0.0 Source Address vs_https httpsJlOOI 172.16.20.1:443 120 seconds
https_pool
172.16.20.1 :443
Source Address Affinity
Mask 255.255.0.0
Timeout 180 seconds
172.16.20.2:443
~
172.16.20.3:443
.:.
172.16.20.4:443
.:.
Figure 5: Persistence records cause client connections to be directed to the same pool member, in essence,
changing the normal behavior of the load balancing method.

Ifno persistence record matches, the connection is load balanced to ao ava il able pool member, and the
BIG-IP system creates a new persistence record.
A persistence record includes:
• Persistence value - IP address or range of addresses to which persistence applies;
• Persistence mode - Indicates the type of persistence (in this case, source address affinity)
• Virtual server - which virtual server the persistence record applies to (by name); click on the
entry to view the virtual server's configuration;
• Pool - the name of the pool containing the pool member connections will persist to; click on the
entry to view the pool's configuration;
• Pool Member - the IP address and port of the specific pool member connections that match this
record will be directed to; click on the pool member to view its configuration; and,
• Age - How long Ihe persistence record has existed. Age increases from 0 up to the timeout va lue
specified in the persistence profile, and is reset back to zero each lime a connection that matches
the persistence record is directed to the pool member indicated.
Unless Ihe entry times out, Or the named pool member fails a monitor health check, subsequent
coo.nections from the specified client(s) to the named virtual server will be directed to the same pool
member.
Source address affinity persistence is a good choice for basic persistence because of its robustness and
simplicity. It also does not require the client to have cookies enabled, as you'll see in the Cookie
Persistence section. As long as a client's IP address does not change during the persistence period, and the
pool member remains available to process traffic, all coo.nections from th at cli ent to the associated virtual
server will be directed to the same pool member.
Persistence entry timeout

The persistence record 's timeout value detennines how long subsequent connections are directed to the
same pool member. For example, suppose a source address persistence profile has a timeout value of
3600 seconds (60 minutes) and that the rust coo.nection to the virtual server with this profile occurs at
9:00am. If the next connection that matches tbe persistence record occurs any time before I 0:00am, the
connection will be directed to the same pool member. Each connection that matehes a persistence record
resets the record's age value to zero (0), in effect restarting the timeout counter.
Applying source address affinity persistence to a range of IP addresses

You can apply source address affinity to a range of client IP addresses by using the Mask setting in the
source address amnity profile. The mask setting detennines tbe portion ofa client's lP address that will
be used to match against existing persistence records. The default mask is 255.255.255.255, indicating
that each IP address is to be treated uniquely. A mask of255.255.255 .0 indicates that only the first three
octets of a client's lP address are used by BIG-IP when looking for matching persistence entries. Such a
mask is frequently used to group clients whose lP addresses may vary due to DHCP but generally remain
within the same range.
7-6 Administering BIG-IP vii

Persistence mirroring
Persistence mirroring can be used to duplicate persistence records to other BIG-IP systems in a hi gh
availability configuration. This setting provides higher reliability in the event ofa failure, and can only be
configured if the BIG-I? device is part of a SyncFailover device group.
Limitations of source address affinity perSistence

Source address affinity persistence is easy to implement but has limitations. The most common limitation
is when a single customer returns to the same application (virtual server) using a client device with a
different LP address. In such a case, the customer may not be returned to the same pool member as their
prior connection. If the customer is returning from the same network, specifying an appropriate mas.k in
the persistence profile can minimize this problem, but may result in uneven traffic distribution.
If the customer is connecting to the same virtual server but from a different network (e.g. home versus
work), the customer is unlikely to be directed to the same pool member.
Las tly, if many clients connect to the virtual server via the same proxy server, all of their connections will
be seen as co ming from the same LP address. This can also result in uneven traffic distribution across all
pool members.
Configuring source address affinity perSistence
General Properti ••
Name Pr_Src_PerSl:>l
AppIiCaiion Cousc_Adn'lInl:ill!rI1Q

Persistence T>ype Source Address Affinity
Parent Profile l$Duree addr ... 1
Conftguratlon
Custom 0
M3I.Cn Across. Sfl:r\nc~ 0

Match Across VIrtual Ser..-ers 0
Match Across Pools 0
Hash A1gonthm 0
Tm l!Dut ISo"aly ,vJl30 ,.con<!< 13
Mask Ill"". • I 0
Map Proxles Enabled 0

L CNerride Connection Wmit 0
~ IDeleu~ . I
Figure 6: Source Address Affinity Profile creation screen

The table below summarizes a few of the commonly specified settings when creating a custom source
address affinity profile:
Setting Description Default Value

Name Specifies a unique name for the profile. This No default value
setting is required.
Persistence Type Specifies the type of persistence profile. This Source Address Affinity
setting is required.
Timeout Specifies the duration in seconds of a 180 seconds
persistence entry. To specify a custom timeout
value, select Specify. Indefinite means the
persistence entry never expires.
Mask Specifies the mask BIG-IP should when None
matching a client IP address with an existing
pElr~i~te~c_~_~_nt~:
7-8 Administering BIG-IP vII

Introducing Cookie Persistence
Lesson Objective:
During this lesson, you will learn bow cookie persistence works, and how to configure a cookie
persistence profile and assign it to a virtual server.
Introduction to Cookie Persistence

A client can be made to persist to a particular pool member using a more granular form of persistence
(than source address affinity) called cookie persistence. Cookie persistence uses an HTTP cookie stored
on a specific client's computer to allow the client to reconnect to the same pool member previously used.
There are four types of cookie persistence available:
• HTTP Cookie losert method (default)
• HTTP Cookie Rewrite method
• HTTP Cookie Passive method
• Cookie Hash method
Note: In this course , we will focus on insert, rewrite , and passive methods only.
The only significant difference between the cookie insert, rewrite, and passive methods is how aod when
the BlG-LP system becomes involved in setting cookie persistence values. The method you choose will
depend a lot on how your application works.
Cookie Insert Method

HTTP Cookie Insert is the default value for the Cookie Method setting. With cookie insert,
information about the server to which the client connects is inserted by the BIG-lP system as a cookie into
the header of the HTTP response from the server. By default, the inserted cookie is named
BIGipServer<pool_oame> by defau lt, and its value is the encoded LP address and port of the pool
member subsequent connections shou ld pers ist to, as shown in Figure 7.
Cookie Insert and Always Send Cookie

By default, the BIG-IP system only sends the cookie on a client's ini tia l connection to a virtual server
witb cookie insert pers istence. This behavior is controlled by the Always Send Cookie setting in the
cookie persistence profile, and its default setting is disabled . Once the browser has accepted lbe cookie,
there is no real need for the BIG-LP system to rese nd it on subsequent persisted connections - except
perhaps if there is an actua l expiration time specified. Again, by default, the persistence cookie's
Expiration setting is Session Cookie, indicati ng the cookie will expire ouly when the client 's browser is
closed. Since the cookie's expiration time never needs to be updated , and the persisted pool member
information always stays the same, there is no need to resend the cookie on eacb response as that would
simply create additional and Wlflecessary traffic.

However, iftbe cookie's expiration is set to a particular time value, for example 2 hours, and the desired
bebavior is for tills expiration time to be reset on eacb subsequent client connection, tben Always Send
Cookies should be enabled. in doing so, tbe cookie will be resent with a new expiration time on each
subsequence connection. If Always Send Cookies is disabled undcr these circumstances, the client gets
one 2-hour window in which persistence will apply. At the end of that 2-hour window, the BIG-IP system
will load balance the client's next connection to the virtual server first, before a new persistence cookie
with a new 2-hour expiration time is sent back to the client.
Cookie Rewrite Method

With the cookie rewrite method, the BIG-lP system intercepts a Set-Cookie header,
named BIGipCookie, sent from the server to the client, and overwrites the name and value of tbe cookie.
The cookie is renamed BIGipServer<pool_name> and the va lue includes the address and port of the
server handling the connection.
For the cookie rewrite method to succeed, there needs to be a blank cookie coming from tbe web server
for tbe BIG-lP system to rewri te. If the server is an Apache variant, the cookie can be added to every web
page header by adding an entry to the httpd.conffile. The application that requires persistence could also
be written to insert the Set-Cookie header with the appropriate cookie name and value.
Cookie Passive Method

With the cookie passive method, the BIG-IP system does not insert or search for Set-Cookie headers in
the response for the server. instead, any cookie settings are allowed to pass through the B1G-lP system
unchanged. This method relies on the server (or the application) to provide a preformatted cookie with the
name of the pool and the encoded server address and port. The B1G-lP system then passes the cookie
unchanged - to the client.
Note: F5 recommends using Cookie Rewrite over Cookie Passive whenever possible.

" ,~
1
pis play Cogkl,
S.PLJlitJP ~9d'rll!
_
• NetwOl1t. t Source",
"CJFr~
- 0110104 tOOl nll9nll4 10!1HfI 1Il{ll1 10 10" InO
- ~'Web SaL
• {J1-.d01l
... loc al Stor aye
.. $ FlS:S!on Storage
... CoI*e':i
.. t; 10 10" 100
Figure 7: Example of a BIG-IP persistence cookie as shown in the Chrome browser
Note: For more information on decoding the value in a BIG-IP persistence cookie, see
SOL6917: Overview of BIG-IP persistence cookie encoding.
Important: In some environments, it may be unacceptable to disclose the IP and port numbers
of origin web servers behind the BIG-IP system in an HTTP cookie. Of your security policy
requires this information to be obscured, refer to the processes described in SOL 14784:
Configuring BIG-IP cookie encryption (10.x through 11.x)

7-12 Chapter 7 - ModifYing TraffiC Behavior with Persistence
Lab 7.1 - Source Address Affinity Persistence

Objectives:
• Configure a source address affinity persistence profile, assign it to a virtual server, verify
functionality, and observe changes in traffic behavior.
Lab Requirements:
• Two or more working pool members in httpsyool
• A virtual server at https:lIlO , I OX . I 00 associated with httpsyool
Configure Source Address Affinity

Confirm traffic behavior before persistence
I, Ensure that the Load Balancing method for httpsyool is Round Robin and that Priority Group
Activation is disabled, Although this step is not required to enable persistence, it will ensure that
the recurring direction of a connection to a pool member is due to persistence and not potentially
due to a load balancing choice,
2, Access and reset the stati stics for pool httpsyool.
3. Open a new browser session and connect to https:!!10.10.X.lOO.
4. Refresb the screen 5-10 times by clicking CtrJ+F5
5. View pool statistics,
What are the results?

You should see BIG-LP load balance each refresh request across all pool members, with each pool
member receive approximately tbe same amount of traffic. If you do not see tbese results, make sure you
reset the statistics properly and waLk through the steps again.

Chapter 7 - ModifYing Traffic Behavior with Persistence 7-13
Create a source address affinity persistence profile

6. Create a source address affmity persistence profile called Pr_Src_Persist
General ProperUes section
Check the Custom box, then specify timeout setting
Timeout
as 30 seconds
When complete. click ... ..
..
Configuration utility
Local Traffic » Virtual Ser~ers » ~s_hllps " Resources
Load Balancing section
Confirm traffic behavior after persistence

8. Access and reset the statistics for bttpsyool.
9. On your browser session to https:/IlO.IO.X.IOO,refreshthescreen 5-10 times using Ctrl-F5.
What pool member did you load balance to? Are you persisting?
10. View the pool statistics.
II. Wait 30 seconds, and tben refresb tbe screen at bttps:IIIO.IO.X.IOO again. At this point, you
should be load balanced to another pool member. Confirm by looking at pool member statistics.

12. View persistence records statistics.
Refresh
13. Ifno Persistence Records display, switch back to your browser window where you are connected
to https:IIIO.IO.X.lOO and refresh the screen several times. Check for Persistence Records
statistics again.
,
Q. What is the Persistence Value? ,J' A I. f} 1'7
tP
·'1 v, , -y ) , ;;.
Q. Does the Persistence Value represent a single IP address or a range of

IP addresses? - l i I /' 1
Q. Based on the Persistence Value, will this Persistence Record apply to a

client connection with a different IP address? f t"

While the persistence entry is active for your client IP address, all traffic generated every time you refresh
will be directed to the same pool member. Since the persistence profile is configured with a timeout value
of30 seconds, your persistence entry may have timed out before you were able to navigate to the
persistence statistics on the Configuration utility.
Persistence profile Pr_Src_Persist currently has a Mask specification of None, indicating each unique LP
address will be load balanced to an appropriate pool member before persistence applies.

Expand Source IP Range Using a Mask

In this next series of steps, you will specify a mask in the source address affinity persistence profile
Pr_Src_Persist, expanding the range of client IP addresses that wiU persist to the same pool member. To
test the new behavior, you w ill enlist the help of ano ther student in the class but before that student can
access yo ur virtual server, vs_https, you'll need to add SNAT Auto Map to its configuration.
Add SNAT Auto Map to vs_https

14. Modify vs_https to specify Auto Map as the Source Address Translation setting. T his will
facilitate other students in tbe class accessing your virtual server witbout experiencing routing
issues.
Before you start this next series of steps, ensure you have two browser windowsltabs open : one
to your BIG-IP system at Statistics" Module Statistics" Local Traffic, and viewing
Persistence Records ; and the other to https:II10_10_X.100. You will be switching back and
forth between these two windows frequently as you go along.
15. Have a student at another workstation accessyollr virtual server at https:lllO.IO.X.IOO. What
pool member are they persisting to?
16. On your browser session to https:IIIO.10.X.100, refresh yo ur screen several times. What pool
member are you persisting to?
17. On your BIG-IP system wb ere you are viewing Persistence Records, refresh the statistics by
clicking the Refresh button on the Auto Refresh line:
Q. How many Persistence Records are there now?
Q. What client IP address does each apply to?
Q. Based on your answers above, what Mask applies to profile

Pr- Src- Persist?

7-16 Chapter 7 - ModifYing Traffic Behavior with Persistence
Expand the range of IP addresses Pr_Src_Persist applies for

18. Modify the mask on Pr_Src_Persist to specify a range oflP addresses using mask 255.255.0.0.
Configuration utitity
Local Traffic» Profiles» Persistence then chck Pr_Src _Persis!
Check the Custom box
Mask Select Specify from the pull-down menu
Enter 255.255.0.0 in the space to the right
When complete, click... I Update
19. Navigate to Statistics» Module Statistics» Local Traffic and view Persistence Records
statistics . If any persistence records still exist, wait until they have all expired before continuing.
20. Have a student at another workstation access YOllr virtual server at https:II IO.IO.X.IOO. What
pool member are Ihey persisting to?
21. On your browser session to https: IIIO.IO.x.IOO,refresh your screen several times. What pool
member are YOll persisting to?
22. On your BIG-IP system where you are viewing Persistence Records, refresh the statistics by
clicking the Refresh button on the Auto Refresh line:
Q . How many Persistence Records are there now, and for what range of IP
addresses?
23. Wait until all Persistence Records have expired again, and then refresh your browser session to
https:lllO.10.X.100. Have the other student do the same. Did you both persist to the same pool
member again? Examine the Pers istence Records statistics again to confinn the results.
7-16 Admlnlstenng BIG-IP v11


When you expanded the mask on Pr_Src_Persist from the (default) 255.255.255.255 to 255.255.0.0,
persistence was expanded to apply to all client connections with LP addresses in the 10.10/16 network.
Instead of two persistence records, each with a unique IP address as the Persistence Value, you should
have seen only one Persistence Record with a Persistence Value 10.10.0.0. When the other student
connected from a client with an IP address in that network, their connection persisted to the same pool
member as your connection, and vice versa.
Clean up after lab

24. Reset Source Address Translation on vs_https to None, effectively removing the ability for
other students in class to connect to your virtual server.
Continue with Lab 7.2 Cookie Persistence.

7-18 Chapter 7 - ModifYing Traffic Behavior with Persistence
Lab 7.2 - Cookie Persistence
Objectives:
• Configure a cookie persistence profile, assign it to a virtual se!>'er, verify functionality and
obse!>'e changes in traffic behavior.
Lab Requirements:
• Two or more working pool members in httpyool
• A virtual se!>'er at http://lO.IO.X . IOO associated with httpyool
• System time on student's workstation and the BlG-IP system must be synchronized.
Configure Cookie Persistence

Note: Ensure that the system time on your workstation (PC) and the time on the BIG-IP system
are synchronized before beginning this lab. The easiest way to do this is to change the time on
the PC to match the time on the BIG-IP system.
Synchronize system time on the BIG-IP system and the lab workstation
I. Ensure tbe system time on your Jab workstation is synchronized with the time on tbe BIG-IP
system. Iftbere is a discrepancy, correct it. For example, if running Windows on your
workstation (PC), you should be able to right click the click display and select Adjust
DatefTime. Adjust the date/time on tbe PC to match what is currently di splayed on your BIG-IP
system.
Confirm traffic behavior before persistence

2. Cbange the load balancing method for bttpyool from Ratio (member) to Round Robin, and
make sure Priority Group Activation is disabled. Although this step is not required to enable
cookie persistence, it will enSUJe tbat tbe recurring direction of a connection to a pool member is
due to persistence and not potentially due to a load balancing choice.
3. Access and reset the statistics for pool httpyoo\.
4. Open a new browser session and connect to http://10.IO.X.I00.
5. Refresh the screen 5-10 times by clicking Ctrl+F5.
6. View pool statistics to ensure you are not persisting.

Chapter 7 - Modifying TraffiC Behavior with Persistence 7-19

You should see BIG-LP load balance each refresh request across all pool members, with each pool
member receive approximately the same number of connections. No persistence is in effect. If you do not
see these results, make sure you changed the load balancing method to Round Robin and reset the
statistics properly, and repeat the above lab steps again.
Create a cookie persistence profile and assign it to a virtual server

7. Create a custom cookie persistence profile called Pr_Cook.ie_Persist . When you select Cookie
as the Persistence Type, the Configuration Section will appear. Leave all defaults in the
Configuration Section for now.
Finished
load Balancing section
Hint: If you received an error message after clicking Update, think "profile dependencies,"
and make the necessary corrections to success fully add Pr_Cookie_Persist to vs_btlp.
Confirm traffic behavior after persistence

9. Access and reset the statistics for http-"ool.
Jo. Back on http://I0.10.X.IOO, refresh the screen 5-10 times.
II. View the pool statistics.
Q. What are the results? Are you persisting?

12. View persistence records.
IQ. Wh",~ th"""'''' Why?
13. Back On http://IO.IO.X.l00, view tbe BIG-IP persistence cookie by clicking on the Display
Cookie link in the middle of the page.
Q. What is the name and value of the cookie?
Note: In the next lab steps, we'd like you to view and periodically delete the BIG-IP persistence
cookie stored by your browser. The steps to do this vary from browser to browser, and are
summarized here. Actual steps may differ depending on the version of browser you are using.
Chrome (v24) Users - Right click anywhere on the page and select Inspect Element from the
resulting pull-down, then click on the Resources tab, then expand Cookies. You can view and
delete cookies in the Inspect Element window.
Safari (v5) Users - Ensure Show Development menu in menu bar is checked in your
Preferences -7 Advanced settings. Then follow the same directions as for Chrome.
Firefox (v18) Users - In the pull-down menus at the top of your browser window, select Tools
-7 Options -7 Privacy -7 Remove individual cookies. You can view and dele Ie cookies in Ihe
resulting pop-up window.
IE (v8) Users - To view cookies, press F12, then select Cache -7 View Cookie Information
from the pull-down menus at the top of the resulting Oeveloper Tools window. This opens a
new browser tab with cookies listed as a scrollable page. To delete cookies , select Clear
Session Cookies and Clear Cookies for Domain from the Cache pull-down .
In all cases, you 're looking for a cookie called BIGipServerhttp_pool that is associated with the
"domain name" lO.lO.X.100.
Test cookie expiration behavior

14. Find the BlG-lP persistence cookie value as your browser is storing it. (See instructions above for
each browser type.)
When does the cookie expire?

IS. Delete the cookie and close the browser window to http://)O.lO.X.IOO in anticipation of the next
lab step. (If you cannot delete individual cookies in the browser you're using, delete all cookies
and close the browser window to http://l0.10.X.IOO.)
16. Reconfigure Pr_Cookie_Persist with an expiration time of30 seconds.
ConflQuration section
Check the Custom box on the far right, and then set
Expiration
Seconds to 30.
When complete, click .. .
17. Open a new browser window to http://10.10.X.IOO, and hard-refresh the browser session several
times. View the cookie and its expiration time again. Did you load balance to a different pool
member than the last time you connected? Why or why nofl
18. Refresh the screen several times to ensure that you are persisting, and then wait at least 40
seconds before refreshing again. Did you load balance to a different pool member than the last
time you connected? Why or why not?
19. Reconfigure Pr_Cookie_Persist with an expiration time of 2 hours.
When complete, cliCk ...
20. Hard-refresh the browser session with bttp:IIIO.IO.X.IOO. Did you load balance to a different
pool member?
21. View the cookie and note its expiration time. Did it change to 2 hours or does it still show 30
seconds?
22. Wait a few seconds and refresh your browser session with http://IO.I0.X.IOO. View the cookie
expiration time again. Did it change? Why or why not?

7-22 Chapter 7 - ModifYing TraffiC Behavior with Persistence
Test the effects of Always Send Cookie

23. Reconfigure Pr_Cookie_Persist to enable (check) Always Send Cookie.
Click the Custom box on the far right, then click the
Always Send Cookie
Enabled box.
24. Refresh your browser session with http://IO.IO.X.IOO, and view the cookie expiration time again.
Now did it change?
Note: If using a specific cookie expiration time on Cookie Insert mode, and you want the timer to
reset to 0 on each client connection, you should enable Always Send Cookie. Otherwise, the
default action is for the BIG-IP system to set the cookie expiration time on the initial client
connection, and to not update the expiration time on any subsequent client connections for
which the persistence cookie applies.
Test cookie persistence effects on other clients

25. Have another student access your vs_http virtual server at http://IO.IO.X.lOO. Did they persist?
Did they persist to the same pool member that you are persisting to? Why or why not?

If the persistence cookie is not behaving as you expect, check to ensure that the lime on your Windows
workstation corresponds to the time on the BIG-lP system. If these are out of synch even by a minute, it
may cause unpredictable results, especially when using Firefox. Check with your instructor if you cannot
get the lab off the ground.
Clean up after lab

26. Reset Pr_Cookie_Persist to inherit its Expiration setting from its parent. (This should set it to
an Expiration value of Session Cookie.)
STOP

Managing Object State
Lesson Objectives
During thi s lesson, you will learn how to change the availability of pool members and nodes through
management action. You will be able to prevent the BIG-lP system from sending client traffic to pool
members that you wish to remove from service so as to perform problem diagnosis, upgrade, or
maintenance activi ties.
Virtual Server, Pool Member, and Node State

You have already seen how monitors can affect the status of virtual servers, nodes, and pool members.
These changes are dynamic in that if the monitor's test results change, the monitored object's status will
change, without human intervention. These status changes may also be short-lived as the monitored object
may fail monitor checks for a few seconds/minutes, and then start passing them again when some error
situation has cleared, again without human intervention.
There may be times however when it is desirable to stop the flow of traffic to a specific node for a period
of time, especially during server maintenance windows or certain troubleshooting situations. To support
this need, BIG-lP allows the certain object state's to be manually changed, either through the
Configuration utility or using tmsh.
At any point during BlG-lP operation, pools, pool members, and nodes will be in one of three
management states - enabled, disabled, or forced amine. An object's state determines what sort of traffic,
ifany, the object will be allowed to process, and plays a significant role when the BIG-lP system is
handling persistent traffic to that object.
In the enabled state, the object supports all connection types - those from new users and those from
returning users. Returning users are those who have connected previously and established a persistent
session, as defined by a persistence record. In the disabled state, the object supports new connections but
only [rom returning users (i.e. those with a persistence entry). In the forced offline state, the object
supports no new connections, even from clients with a matching persistence entry. Only existing
connections are aHawed to complete.
Disabled and forced amine states can differ when persistence is specified, depending on the Action On
Service Down setti ng for the pool. With no persistence, BIG-lP does not recognize any client as a
returning user. Also note that the state impacts how new connections are handled, as illustrated for pool
members in the table below:
Pool Active New Persistence Entry New Connection New Connection

Member (Existing) (Session) (Persistent) (non-persistent)
Status Connections
Enabled Maintained Yes Yes Yes
Disabled Maintained No. but timers for existing Yes No
entries are allowed to reset
Forced Maintained No No No
Offline (default)

Disabling nodes or pool members for maintenance

When you interrupt access to a network device for maintenance, you shou ld cbange the state of tbe node
to Disabled or Forced Offline. If a node is disabled or forced offline, any pool member in the BIG-IP
configura tion that uses tha t same IP add ress is also disabled or forced offline. Alternative ly, when you
want to stop a service associated with a particular application - perhaps to do ma intenance on the
applicatio n itself - yo u should change the state ofthe affected pool membcr(s) to Disabled or Forced
Offl ine.
Changing node state

One or more nodes can be enabled or disabled usi ng the Node List in tbe ConfIguration utility. An
individual node can be enabled, disabled, or forced offline using its confIguration screen. (See Figure 8.)
Node state can also be changed usi ng the command line. To disable a node using tmsh:
tmsh modify f Itm node <node name> session u se r-di sabl ed luser - enabled
For example, to set the slale of node 172.16.20.1 to disabled, you would type the following command at
the TMOS prompt:
t msh modify / I t m node 1 72.16.20.1 session user - disabled
To force a node offline using tmsh :

tmsh modify /Itm node <node name> state user-down luser-up
For example, to sel the state of node 172.16.20.1 to forced offline, you would type th e followin g
command al the TMOS prompt:
t msh modify fI t m node 172. 16.20.1 state user-down
Remember that when using the command line to make changes, if you want those changes
saved, you must follow the modify command with a save /sys config command.

I ISearchl
... Name Application Address
172.16.20 .1
------------------~-- 172.16.20.1
172.1 6.20 .2 172.16.20.2
172.16. 20 .3 172.16. 20 .3
172.16.20.4 172.16.20.4
I Enable " Disable II Delete.. . I
General Properties
Name 172.16.20.1
Address 172.16.20.1
Description
Availability Available (Enabled) - Node address is available
Heakh Monitors icmp
Current Connections
• Enabled (All traffic allowed)

state Disabled (Only persistent or active connections allowed)
Forced Offiine (Only active connections allowed)
Figure 8. Changing node slale using the Configuration uliflly (Top: Change node 10 disabled or enabled at tM Nodes
List page; Bottom: Change node to enabled, disabled, or forced offline at the specific node's configuration page .

Changing pool member state

One or more nodes can be enabled or disabled using the Members tab on the Pool List in the
Configuration utility. An individual pool member can be enabled, disabled, or forced offline using its
con figuration screen. Both screens are shown in Figure 9.
Pool member state can also be changed using the command line. To disable or enable a pool member
using tlUSh:
tmsh modify /Itm pool <pool name> members modify { <pool.member:port>
session user-disab ledluser -enabled } }
For example, to set the state of pool member 172.16.20.1:80 in pool htlpJlool to disabled, you would
type the following command at the TMOS prompt:
tmsh modify /ltm pool http-pool members modify { 172.16.20.1,80 {
session user-disabled } }
To force a pool member offline or bring it back online using hnsh :
tmsh mod if y f Itm pool <pool name> members modify { <pool.member:port>
state user-downluser - up } }
For example, to set the state of pool member 172.16.20.1:80 to forced ofmne, you would type the
following command at the TMOS prompt:
tmsh modify /ltm pool http-pool members modify { 17 2. 16.20.1,80 { state
user - down } }
saved, you must follow the modi fy command with a save / sys conf ig command.

Current Members
Member • Address Priority Group
172.16.20. 1 80 172.16.20.1 1 o (Active)

172.16. 20 .280 172.16.20.2 2 o (Active)
172. 16.20.3:80 172.16.20.3 3 o (Active)
[ Enable [ [ Disable [ ' Remove I
Node Name 1172.16.20.1

Address 172.16.20.1
Service Port 80
Description
Parent Node 172.16 20.1

Availability Available (Enabled) - Pool member is available
HeaRh Monitors
Current Connections
• Enabled (All traffic allowed)

State Disabled (Only persistent or active connections allowed)
Forced Offline (Only active connections allowed)
Figure 9: Changing pool member state using the Configuration utility (Top: Change member Slate to disabled or
enabled at the Members tab of a particular pool; Bottom: Change member state to enabled, disabled, Or forCed offline
at the member's configuration page,

Changing virtual server state

As wilh nodes and pool members, virtual server slate can also be changed man ually using either the
Configuration ulility or Imsh. Unlike nodes and pool members though, a virtual server cannot be forced
omine - ils state is only ever enabled or disabled.
You mighl wanllo disable a virtual server in troubleshooting situalions, such as if Lhe virtual server was
being bombarded wilh traffic. Disabling a virtual server prevents any new connections to that server. You
could also disable a virtual server as part of staging a new applicalion service for production rollout. You
might lest the new service during a maintenance window, and Iben disable Ihe virtual server until the
scheduled rolloul dale.
One or more LTM virtual servers can be enabled or disabled using Ihe Virtual Server List in the
Configuration ulility. An individual virtual server can be enabled or disabled using ils configuration
screen. Bolh screens are shown in Figure 10.
Virtual server slate can also be changed using the command line. To disable or enable a virtual server
using tmsh:
tmsh mOdify fitm vi rtua l <virtual server name> disabl e d l e nabled
For example, to set the stale of virtual server vs_http 10 disabled, you would type the following
command at the TMOS prompt:
tmsh mod ify / ltm virtual vs_http disabled
saved, you must follow the modify command with a save s y s config command .

IISearcN
-- . - 'IF:
.. Name Appi cation Destination Service Port Type
10.10.4.100 80 (HTIP) Siandard
10.10.4.100 443 (HTIPS) Standard
10.10.4.100 22 (SSH) Standard
10.10.4.101 443 (HTIPS) Standard
I Enable I @"Sabie] 1Delete ... I
General Properties
Name
Partition 1 Path Common
Description
Type Siandard
Source 0 .0 .0 .010
Type: ,. Host ,", Network

Destination
Address:! 10.10.4.100 ,
Service Port 80 - - l [8Trp
Availability Available (Enabled) - The virtual server is available
Syncookie Status Off
State ,Enabled ....

y
Figure 10: Changing virtual server slate using [he ConfIguration utilily (Top: Change virtual server state to disabled or
enabled at the Virtual Servers list page; Bottom. Change virtual server state to enabled or disabled at the virtual
servers configuration page. Forced offline is not available for a virtual server.

7-30 Chapter 7 - ModifYing Traffic Behavior with PerSistence
Lab 7.3 - Managing Object State Lab
Objectives:
• See the effect of object state on persistence
• Estimated time for completion : 15 minutes
Lab Requirements:
• vs_https with resources httpsyool and Pr_Src_Persist profile
Persistence and Disabled Pool Members

Pre-configuration steps
I. Update the timeout value in the Pr_ Src_Persist profile
When complete, click .. .
Establish a persistent session and disable a member

2. Open a browser window to https:1I10.10.X.I00. Refresh the page several times to confinn that
you are persisting to the same pool member.
Q . What is the IP address of the pool member you are persisting to?

3. Use either tbe Configuration utility OR tmsb 10 di sable the pool member you are persisting to
(as noted in Ihe previous step). instructions for bOlh methods are shown below: (a) for the
Conliguralion uliJity; (b) for Imsh.
a. To disable Ihe pool member using the Configuration ulility:
Current Members section
b. To disable the pool member using tmsh, substitute the IP address:port combination for
the server you are persisting to for <pool.member:port>:
tmsh modify Itm pool https-pool members modify {
<pool.member,port> { session user-disab led) )
4. Go back 10 Ihe browser window connected to https:II IO.IO.X.IOO and refresh the page several
times.
Q. Are you still persisting to the same pool member? Why or why not?

s. Use either tbe Coofiguratioo utility OR tmsb to force the pool member you are persisting to
omine. instructions for both methods are shown below: (a) for the Configuration utility; (b) for
tmsh.
a. To force th e pool membe r omine using the Configuration utility:
Currant Members section

are
Member Properties section
Click the Forced Offline (Only active connections
State
I radio bunon
When complete. cIlck ...
b. To force the pool member omine using tmsb, substitute the IP address:port combination
of the server you are persisting to for <pool.member;port>:
tmsh modify ltm pool https-pool members modify {
<pool.member'port> { state user-down} }
6. Go back to the browser window connected to https:1I10.10.X.IOO and refresh the page several
times.
Q. Are you still persisting to the same pool member?
7-32 Admlnlstertng BIG-IP v11

Disable the parent node and test the results

7. Use either the Configuration utility OR tmsh to disable the parenl node of the pool member
you are now persisting to. lnstructions for both melhods are shown below: (a) for Ibe
Configuralion ulility; (b) for Imsh.
a. To disable Ihe node using Ihe Configura lion ulility:
Node List section

the checkbox to the left of the parent node of the pool member you are now
to.
When complete. click. .. Disable
a. To disable the node using tmsh, substitute the IP address for the parent node of the pool
member you are persisting to for <node name>:
tmsh mOdify ltm node <node name> session user-disabled
8. Refresb tbe page at https:1I10.10.X.IOO several times.
Q. Are you still persisting to the same node? Why or why not?
View object status from the Network Map

9. View tbe status of all your configuration objects from the Network Map screen. Hover your
cursor over the status icon for the pool member you are persisting to and note the state oftbe pool
member. Hover over the pool member lP address:port and note tbe status of th e parent node.
10. Enable the node and pool member you disabled earlier in this lab using either the Configuratio n
utility or tmsh .
STOP

7-34 Chapter 7 - Modifying TraffiC Behavior with Persistence
7-34 Administenng BIG-IP v11

Chapter 8 - Deploying Application Services with iApps 8-1
Chapter 8: Deploying Application Services with

iApps
Chapter Objectives
After completing this module, you will be able to use an iApp template to deploy an application service.
Simplifying ~pplication Deployment with iApps

Overview
One of the challenges in an application delivery network is the need to deploy applications more quickly,
more easily, and more reliably. However, deploying applications requires a lot of specific information.
Architects ha ve a macro view of the application; developers have most of the application details; the
network team knows how the network should run the application ; and some of the detail s can fall into a
knowledge gap that not in anyone's particular bailiwick.
Initially, FS addressed this need with deployment guides - detailed walkthroughs that described how to
deploy applications. The walkthroughs were eventually replaced with application templates
preconfigured "kick-starter" forms for applications. But configuration objects were still grouped and
managed by object type (e.g. virtual servers, pools, profiles, iRules), as shown in Figure 1, rather than by
the application service they supported (e.g. company website, ecommerce application, Exchange, Oracle).
Virtual Pools Monitors Profiles Policies lRules

Servers
( VI_OW' )( ow.-pool ]( owa )( Te p ] ( e WA Ac.,.1 ) ( HTTPRedl, )
(VI_.n~Whef1! I( 'l'CCI-"ool ] [ e"ywhere )( HTTP )[ AAA ) (OWA APpend)
( pDp3-"ool ) ( active5ync )( NTLM )[ sse ) ( UnlvPer'illit )
( ImapJ>ool ]( autodiscvr ) ( Cliant SSL ]

( Y5_rpl,;t;.H
) ( rpeea ) ( OneConnect )
( "-"DpJ ) ( pap3 )( Cookie

)
( V8_1milp
) ( Imap ) ( srCAddrAffin)
Figure 1: Without iApps, application configuration objects are grouped and managed from a network-centric
perspective - as virtual servers, pools, monitors, profiles, etc, rather than as the application each object supports.

8-2 Chapter 8 - Deploying Application Services with iApps
The real breakthrough came in version 11.0 with the introduction of iA pps, the BIG-IP system's
framework for deploying application serv ices. Using iApps, network administrators can deploy
commonly-used applications such as Oracle or Exchange by answering a series of simple questions that
relate to their application management needs and network infrastructure topology. The responses to these
questions will drive the creation of certain BIG-IP system con fi guration objects that are then grouped
together under a centralized application service, as shown in Figure 2. This alleviates the need to manage
discrete components on the BIG-IP system.
Exchilnge 2010
I
I
Vii_OWl! J (
wwwcocom
V5_com ) ...Inlta.co.coO
V5_intra
[
oW8_pool
pop3
)
)
vpnJlOot
Oriel. )
I www-"ool
I HTTP
)
)
Inlrv-"ool
(
HTTP ,
I
[ ow. J
I Cookie )
I Client SSL I ( ClientSSL ) ( HTTP ) I HTTP )
( TCP )
I TCP ) ( TCP ) ( TCP )
[ OWAAccet ] ( InttaAcCH5)
( SSO )
(OWA Append I I WkEncRedlr I I Proxy Pa&s ) (HTIPThrotue)
( HTTPRed l, , ConlTypeRep
"-----'- -"'-----' '
tlH ffftl :- .. "

r lgure 2: iApps facilitate an application-centric vie w of application delivery network configuration objects
By managing appli cati on services rather than individual networking components and configurations,
application deployment speed is dramatically improved, and it is easier to replicate commonly-used
application services across the enterprise.
Benefits of using iApps include:
• User-customizable
• Easy ed iting of configurations and cleanup
• Reentrancy
• Configuration encapsulation
• Cradle-to-grave configuration management
• Strictness protects against accidental changes to the configuration
• Operational tasks and health status for application service components (configuration objects)
• Copy/import/export capability
• Community support for DevCentral hosted templates

iApps Elements
The iApps framcwork consi sts of two main elements, as shown in Figure 3:
• Templates
• Application services
Templates Template
The template is where all the
groundwork for deploying and
application is defined. Templates
'!iJ!!1 wabt!J! ~
include programmatic information
that will be used to create
• F5-supplied
configuration objects, tbe visual
layout of the form that the iApp user • Shared
Kmt Wtb&ft. POOl )
will interact with on the BIG-lP
system (the GUI), and help
(DevCentral) ( !cme Wt'btrte tim!: !!!Q:n1tQ[
)
information. At the time an • Custom built
application service is generated, its ( i1~ wlibaHe htta
)
associated configuration Objects will
be derived from the template that was ( .em. Wfltl.1t& cookie-
pI,.....~ne. )
used to deploy it, and the values that
the iApp user provides when filling
out the template form ' s various fields. Figure 3 : T&mplates provide the guidance needed 10 deploy an
application service and its assocfaled configuration Objects.
Some iApp templates come pre-
configured on thc BIG-IP system; others can be obtained from tbe DevCentral iApps community pages.
You can use any of these as the basis for developing your own iApps templates, or you can build a
template completely from scratch .
Application services
iApps application services use templates to help drive the configuration process. When gene rating an
application service, the iApps user uses the Configuration utility to deploy the service from a previous ly
developed template, filling out fields and answering questions in the template's visual layout that are then
used by the template'S programming logic to generate BIG-lP system configura tion objects, such as
virtual servers, pools, pool members, profiles, monitors, and so on. All the objects created during
deployment are then bundled as components of the application service, and can be viewed and managed
from a single screen in the Configuration utility.
Note: Because objects that are initially configured by an iApps template can be very difficult to
change, there are configuralion objects that are better suited for inclusion in an iApp template,
and others that are not. In general, avoid elements lhat you configure using the BIG-IP System
option. Examples of configuration objects that are good to include in an iApps template are pool
members, virtual servers, health monitors, and profiles.

Using iApps Templ~__

tes_ _ _ _ __ _ __ _
Overview
iApps templates are the basis from which an application service is deployed. From the iApp user's
perspective, an iApps template asks questions, and the answers provided are then used to create and
associate BIG-IP configuration objects in a bundle that is the application service.
A template contains several key sections, as described below:
Presentation section
The presentation section is written with APL, or application presentation language, and constructs the
user interface for the iApp template. From an iApp user's perspective, the user interface consists of a
series of questions, the aru;wers to which determine the configuration objects that are generated . The APL
describes what questions to ask, when to ask them, how the questions are presented (e.g. free-form text
field, a pull-down list, etc), and the names of the variables used to store the values the user inputs. For
example, the APL code snippet below is from the presentation section of the F5-supplied template called
f5.http. It results in a graphical user interface display that contains a section similar to that sbown in
Figure 4, and sets up for the responses that will feed back into the template's programming logic to
generate the appropriate configuration objects.
section 5s l {
choice mode display "xx large " default "no _551"
•
•
•
5sl "SSL Encryption"
ssl.mode "How should the BIG-IP system handle SSL traffic?" {

"Encrypt to clients, plaintext to servers (SSL Offload) II :> "client_58l",
"Terminate SSL from clients, re-encrypt to servers (SSL Bridging)"
=> "client_ssl_server_ ssl",
"Plaint ex t to c l ients, encryp t to servers" "'> "server_55l" ,
"Plaintex t to both clients and servers"
SSL Encryption
How should the BIG-IP system

to
handle SSL traflJc?
Terminate SSL from dents, re-encrypt to servers (SSL Bridging)
Plaintext to clients, encrypt to servers
Plaintext to both clients and servers
Figure 4: Presentation section code constructs the user interface for the iApp temp/ate.
Implementation section
The implementation section is wrinen with the TeL-based tmsh scripting language. This is the
programmjng section of the template that does the work of building and applying the configuration.
Virrually anything that can be done with tmsh can be accomplished within an iApps template. For
example, in the snippet of implementation seclion code shown below (from the F5-supplied template

fS.http), the script is considering whether or not to set up a Client SSL profile depending on the user's
response to the questions that were asked in the presentation section.
# CLIENT SSL
set do client s8l [iapp: :is : :881 mode client ssl client s81 server 881)
set new - client - s8l lexpr { ! $advanced II liapp 0 -;- is \ - -
: ; ssl_client_sslyrofile $;: CREATE_NEW_ANSWERJ }]
set do- chain- cert [expr { $advanced && \
! [iapp: :is : :ssl_use_chain_cert $: :DO_NOT_USE_ANSWERJ }l
"ltro profile client-s81 ${app}_client-ssl defaults-from clientssl"
Help section
The help section is html-based, and is used to guide the iApp
user in the purpose and function of the iApp template.
[ .... .1 Hetp
1 Maul· 1
I I
For example, the snippet of help section html code below might ~I ,1m E'Pand
produce output similar to what is shown in Figure 5. I
web iApp Temptate
web iApp Template
This template creates a complete
This template creates a complete cOnfiguration optimized for
configuration optimized for managing web managing web traffic.
traffic. Be£ore you start: 

<u1>
Before you start:
I
<li>All of the help for this iApp template • All of the help for this iApp
is found inline. Select Yes, show inline template is found fnline. Select
help from the inline help question.</li> Yes, show inline help from
<li>For a complete walkthrough of this the inline help question.
web iApp, as well as detailed information and • For a complete walkthrough of
help, see httpo//www.fS.com/pdf/deployment this web lApp, as well as
guides/iapp-http-dg.pdf</li> detailed information and help,
<li>Check System :: Resource Provisioning
see http://ww.N.f5.com
to ensure that LTM (Local Traffic Manager) is
Ipdf/deployment-guidesliapp
provisioned.</li>
http-dg.pdf
<li>Set up VLANs and Self IP addresses on
• Check System :: Resource
the networks you use for client-side and
Provisioning to ensure that
server-side traffic.</li>
LTM (Local Traffic Manager)
<li>If configuring SSL Offload on the BIG
IP system, before running the iApp, import the is provisioned.
proper SSL certificate(s) that corresponds to • Set up VLANs and Self tP
the DNS names used by the clients.</li> addresses on the networks
<li>If you plan to use the iApp to deploy you use for client-side and
any of the optional modules, the modules must server-side traffic.
be fully licensed and provisioned before • If configuring SSL Offload on
running the iApp.</li> the BIG-IP system. before
running the iApp, importlhe
</ul> ...._ _proper SSL certificate(s) that
•
• Figure 5: Sample help layout produced by
• the htm! code in the Help section of an
lApp template
Inline help is also a best practice for iApp templates, and is generally turned on or off by the iApp user at
the time they create or reconfigure an application service from a template. For example, turning on inline
help in the fS.http template changes the text around the SSL Encryption section shown in Figure 4 to look
like Figure 6.

8-6 Chapter 8 - Deploying Application Services wilh iApps
SSL Encryption
How shoukllh. BIG-I? system
handle SSllramc?
IEncrypllo clianls , pl~lnlexi to servers (SSL omOlld)
SSL is a cryptographic protocol used 10 secure clienllo server communications. Select hOW you warrtlhe
BtG-IP system to handle encrypted trame. For encryplion between client and BIG-IP system:
tt'your application requires encrypllon and session persistence twh1ch ensures requests from a single usef
are always dislribut8(j to the server on which they started) . we recommend you conftgure the BIG-IP system
for terminating SSL for clienl requests. This allows the system to more accurately persist connecllons based
on granular protocol or applicalion-speciftc variables.
If security requirements do not allow the BIG-'IP system \0 decrypt client connections. select to re-encryplto
the web servers_ With this selection the system will use SSL ID or CllentlServer IP to enforce session
persistence. Because Ihese parameters are less granular. using them may resullin inconsistent distribution or
client requests.
Encryption between BIG-I? syslem and web servers:
Encryption and decryption of SSL is computationally intensive and consumes server CPU resources. In
environments that do not requifll encrypilon between the BIG-IP system and the web servers. select SSL
Offload 10 terminale the SSl session from the client atlhe BIG-IP system and provide elear text
communication rrom Ihe BIG-IP system to the web servers.
For environments that require encryption between the BIG-IP system and the web servers. selee! SSL
re-encryption 10 terminate the SSL session from the ellenl at the BIG-IP system and re-encryptll ror
communication belween the BIG-IP system and the web serve~.
Iryou have already created an Cllenl SSL pronle Ihallncludes the appropriate certiflcate and key, you can
• r;elee!1t rrom the list. Otherwise , the iApp creates a new Client SSl profile.
Figure 6: SSL Encryption sectio" of the f5.h tlp template with tnline Ilelp turned on
Macro section
New in version II A, tbe macro section allows template developers to create generic text that can be used
as iRules, and that can be customized with tbe iApp user's unique input while maintaining syntactical
accuracy and consistency. In essence, it's a bridge between iApps and iRules.
FS-Supplied Templates
The BIG-lP system contains many F5-supplied templates tbat can be used as is to deploy commonly used
applications such as Microsoft Exchange or Sharepoint. These templates all have names tbat begin with
tbe prefix "[5." System-supplied templates cannot be modified, but can be copied to another name and
then edited.
In versions 11.0-11.3, the following iApps templates were shipped with BIG-IP:
• Citrix Presentation Server 4.5

• Citrix XenApp 5.0, 5.1 and 6.0
• Diameter
• DNS Load Balancing
• HTTP
• lP Forwarding
• LDAP
• Microsoft Exchange 2010 and 2010 SPI
• Microsoft Exchange OW A 2007
• Microsoft lIS 7 and 7.5
• Microsoft Lync 2010
• Microsoft OCS 2007 R2
• Microsoft Sharepoint 20 10

• Microsoll Sharepoint 2007

• nPath
• Oracle Application Server 109 (and SSO version 109 Release 2 - v I 0.1.2.0.2)
• Oracle EBS 12
• Oracle PeopleSoft 9
• Oracle WebLogic Server 10J (BEA WebLogic 5.1 and 8.1)
• Radius
• SAP Enterprise Portal 6.0, mySAP ERP 2005
• SAP ERP Central Component 6.0, mySAP ERP 2005
• VMware View 2. 1, 3.0.1, 4.0 and 4.5
In version 11.4, four new templ ates were added primarily for WOM applications:
• ClFS
• FTP
• Replication
• VMware vMotion
Note: There are also many other s upported templates available for download at DevCentral
(devcentral.f5.com). See the iApps Codeshare for a complete list of F5 templates by application .
F5-supported iApp templates are c reated, tested , and sup ported by F5 Networks for customers
with current maintenance contracts.
Accessing iApps Templates on the BIG-IP System

You can use any oftbe F5 -supplied templates as is, or as a starting point for developing your own
templates. Or you can write templates from scratch using tmsh and Tcl for the implementation section, the
iAp ps application presentation language (APL) for the presentation section, and HTML for the hel p
section . Scratch-built templates can be built using the iApps » Templates screen or any text-editi ng
sofrware. lfusing text-ed iting sofrware, you can then import the template into the BIG-IP system to use.
Note : iApps templates a re used to create application services and cannot be used by
themselves. Th is is a fundamental c hange in the way templates are used from BIG-IP versions
prior to 11.0,
Viewing a template's contents

You can view the contenls of any iApps template on a BIG-IP system by navigating to iApps »
Templates and clicking the template name in the Template List. The Template Properties screen opens
so you can view the different seclions of the template, as described earli er.
Note : You can only edit no n-system-supplied templates from this view. System-supplied
templates must be copied and renamed before they can be edited .
Copying a template
At the ti me an iApps template is developed, the developer specifies which BIG-IP modules must be
provisioned in order to use the template (e.g. LTM, ASM, GTM , etc). Before copying and modifyi ng any
temp late, you should license and provision the designated modules to avoid issues during deployment.
You should also ensure that you have administrator privileges on the BIG-IP sys tem where you are going
to modify a copied template, as this could also prcvent successfu l deployment.

DeplC?ying an Application S_
e_rv_i_c_
e_ _ _ _ _ _
Overview
An iApps application service lets you create and deploy new configurations by filling out screens with
fonDS generated by the underlying informati on in an iApps template . Using the B1G-IP Configuration
uti lity, iApps users can manage, reconfigure, and view statistics about an application service once it is
created. (To view application statistics, the Application Visibility and Reporting (A VR) module must be
provisioned.)
Application services deployment requirements

Before deploying any iApps template you should consider tbe following requirements:
• You must license and provision a template's required BIG-IP modu les on all BIG-IP systems that
will be using the template.
• If you are modifying a template, ensure that you have sufficient privileges on the BIG-IP system
you are using so you can test the template.
Note: When creating an application service, users are prompted to license the modules required
by the selected template if the modules are not licensed, and this may require permission that
the user does not have.
Deploying an Application Service

Although you can use either the Configuration utility or tmsh to deploy an iA pp application service, the
forme r is much simpler than the latter. Deploying an iApp from the G UI is an interactive experience,
while deptoying from tmsh is not. That makes the tmsh method sign ifica ntly more difficult. If you
remember back to the components of an iApp template, once of these is a script - defined in the
implementation section - that is executed once you are done filling out the questions defined by the
presentation section and hit the Finished button. The answers that you provide to the questions are passed
to the script as variables, and then the script executes using those variables to create the appropriate
configuration objects.
Deploying an iApp witb tmsh essentially starts at this point, and requires you to figure out what the
variables are and pass tbeir values. Therefore, the Configuration utility is tbe recommended tool for
deploying an application service.
Dep loying an application service usi ng the Configuration utility consists of four simple steps:
1. Create new 3. Answer 4. Click

2. Associate
application
template
template Finished to
service questions deploy

Figure 7 illustrates the deployment of an application service using the F5-supplied template called f5.http.
(Some parts of the GUI generated by the presentation section of the templ ate have been omitted for
discussion purposes.)
Template Selection: BtlsleI

I Nome
I"'.hllp
Template OpHons ------------------------------------~
Do you want 10 see inane nelp? INo, do 1'101 shaw inline help
WhIch conngurellon mode do
you wanllo use?
IBasic· Use FS's recommended selllngs
---.1-----
SSL Encryption
How should Ihe BIG-JP system

handle SSllramc?
IPlaintext 10 both dlents and servers
Vlrtu., Server and Pooll
WhellP address do you
want 10 use for Ihe virtual 1 10.10.1.200
• • rver?
What port do you wanlta I

use ror Ihe \/irIual server? 80
Whet FOONs will c:Jients

use 10 access (he serw~1
I Hosl I www.classroom-websile .com
IAdd I
Do you wenllo erNie I
new pool or us. an exlsllng ICreale a new pool
one7
NodeJIP addren f1]"2."16 .20 .1 po· l·o Connedlon lim _ ' 0 [[)
Which web saNen should NodeJIP 8ddress f 172 .16 .20.2 v Po. 1.
;":-::0- ConnectIon tim" i-I""
0 -- 0
~ induded in this Pllol?
NodallP address 17 2. 16 . 20 .~ \II' portleo Connedlon tlmII l 0 [[]
IAdd l
Application Haallh
Create a new hunh monitor or
use en exisUng one?
ICreale a new H TTP monitor
Whal HTTPURlshouldbeseni
I l1ndex.hlml
to the servers?
Whet is the expedtd response

to the HTTP request? 1 Seov"I' ·3J
I Canto/III Repeal 11 Flnlsho. I

Figure 7: Example of deploying a Simple webSite application service using fhe F5-supplied femplafe. f5.http. (Some
parts of the screen have been omitted.)
As you select the answers to va rious questions, the contents of the screen may change. New questions
may appear or existing questions ma y d isappear depending on your selections. For example, if you did
not select "Create a new poo l," the questi on "Which web servers should be included in this poo)?"
disappears.

If the template follows F5 's best practices, it should also include an inline help selection that provides
additional information as to what each setting might accomplish .
The results of deptoying an application service, as shown in Figure 8, might look something like this:
a 8t~
ilLl"""""'" .......
.3 [] drJ"l~rQl,)ffl_~!8_Y':.
a
...
dS'5SrtXfT1_we~w llttv_1t11J" .Ier
.A_
o 11) III !V , ':It • Ava;:OOfe;
9 Ll m'e'll' ,"""""",
~ ~on :" fj J: Pool Member
9D 1'1} 161(. 1 II,""""""
iil.[] 172 tl:: 103l.Gl • AvalaOle Member
";'0 ","10' II ",,,,,,,,,,,

cIO')"ro"'fTL~_' ...,...."1".aI.li.Jr·lJl;lrS>~~:.
"""'"
"""_
\t' 1 -1 ~oa Virtual Address
~!!I"!'illXIf'I1_~_Cf1r"1,,-p lllt'lI ,h'nt I Va1uaJ Smve r Pel"EJ5hm,. Prl"lfda
"6'3!1rol.lfIL~lfI:_nlll PrQn"j
,Jtl:;VI'JOf11_~_tr~n'OPlll1l1A'J f)rolbe
, 1i!l5!1rfl\.1r:'1.. tbsl"_ttP"1.'!lt- Ttt1l.to oJ Pm'"

PfOft.)
cl8S~rOOf:l_~_'lllJm~lurl? Pro1h,
lB (Iilistoorl ~ w.;n. OJ't~M'IIh\(J-CO"l Prol\»
Figure 8: Sample oulpul (rom deploying an iApp application service, as shown in Figure 6
As you can see in Figure 8, several pro tile objects were created that do not seem to coincide with any
questions presented in the screens shown in Figure 7 (e.g. classroom_ website_oneconnect). In this case,
these objects are controlled by other questions that would appear if you selected "Advanced" in response
to "Which contiguration mode do you want to use?" The important takeaway is that the iApp developer
has anticipated a range of scenarios that could apply to your basic "http" application service, and has
provided means for you to customize the service - using the template - to meet your specitic needs.
Changing an Application Service's Configuration

There may be times when you want to change an application service's configuration after initial
deployment. For example, suppose the user base for our "classroom website" has grown, and we want to
add a fourth pool member into the load balancing pool for this application service. If this was one of the
pools you created earlier in this course (e.g. http~ool), you' d navigate to Local Traffic» Pools, select the
pool, and then add another pool member to the list. However, in the case of a configuration object that is a
component of an application service (e.g. classroom_website-pool), your ability to modifY that object's
settings is controlled by the strict updates setting for the application service.

About strict updates

Strict updates is one oftbe property settings for an application service, and contro ls whether or not
changes to the application service's components (e.g. virtual servers, poo ls, monitors , profiles, etc.) must
be managed exclusively from within the application service and its associated template (i.e strict updates
is enabled), or will be pennitted using otber parts of the Configurati on utility (i.e. strict updates is
disabled).
Modifying an application service's configuration with strict updates enabled

Back to our example, suppose we want to add a fourth pool member - 172. 16.20.4 :80 - to
c1assroom_website~ool, a component of our classroom _website application service. If strict updates
are enabled for classroom_website, our only choice is to reconfigure classroom_website and, in response
to the same questions posed during initial deployment, add a fourth pool member, as shown in Figure 9.
(Some parts of the reconfigure screen have been omitted for discussion purposes.)
Template S.lecHon: IBasic -1

Name classroom_website
tTomplolo I,.·...p (Ch.ng• ... 1
VIrtual Server and Pools
What IP address do you

want to use ror It,.
virtual 11 0 .10.4.200
SeNe'?
WllOI port do you _ to
use ror Ihe virtual Hf\/l!r7
180
Whet FOONs will cllenls I

Host WW'W.classroom-wtbsl• .com
use 10 OCCISS the s. rwn?
IAdd I
00 you wan! to cr,.t I
new pool or us• .." existing ICreal. II new pool
on,?
NodeJiP Sddress f 17 2.16.20.1 v Pon 180 Connection IImlt J 0

0
Nodel1P addreSS r 172 .16.20.2 • pon l 60 I
Connection I1mH 0 ([]
Which web server! should
be Wlduded In th4s pool?
Nod8l1P addr.ss l~-17-2-.'-6.-20- .-3 - - - - - - . Pon leo Connedlon limil! 0
m
NodeJIP address '1"72.16.20 .4
IAddl
v Port 180 Connedlon limn aI m
1=c;nc;;J Finished
Figure 9: Reconfigun'ng an application service to change its configuration when Strict Updates are enabled. In this
case, a fourth pool member-172.16.20.4:BO - is being added.ISome p arts of the screen have been omitted here.)

During a reconfigure operation, the old configuration is changed to the new configuration by the iApp
script using a process called mark-and-sweep. In essence, mark-and-sweep causes ...
• ... any object from the old con figuration that is not present in the new configuration to be deleted.
• ... any object from tbe old configuration that is in tbc new configuration to be modified with the
new configuration's settings.
• ... any object that is in the new configuration but not in the old configuration to be created with
the specified settings.
In the reconfiguration example in Figure 9, assuming all other settings are unchanged from the initial
deployment, the net effect is for pool classroom _ websiteyool to be modified to include pool member
172.16.20.4:80.
Modifying an application service's configuration with strict updates disabled

If strict updates is disabled for an application service, you may cbange the application service's
configuration by either reconfiguring it (using functionality at iApps » Application Services » <service
name> » Reconfigure, or you can navigate directly to the configuration object and make changes there.
For example, to add a fourth pool member to classroom_ websiteyool, you could use tbe Reconfigure
tab on application service ciassroom_website, or you could navigate to Local Traffic » Pools »
classroom_websiteyool » Members, and add the fourth pool member there.
Keep in mind that, in doing so, you may disrupt your ability to manage the application service's
configuration using the Reconfigure method again. Or, you may inadvertently wind up superseding or
removing a change made outside of the application service.
Note: Unless you have a specific reason to lAflP " Allfllu:nUon SOrvlCOS I~""r-. ,('I .' t I·
disable strict updates, F5 recommends that e. Prcpenles ~~~~"1igtl~':! • "'II. ".. ..""
you leave the Strict Updates selling enabled ~
(checked) .
I
Application Service: Mv-anced Id
If you do decide you wisb to manage the ~Ication Service classroom_website
application service's components directly (without Partition I Path Commonlcfassroom_websil e .app
using Reconfigure), you can initially deploy the
application service from the appropriate template, Description
II
then disassociate the application service from any T~late fS.http
template and disable strict updates. The net effect SInd Updates II (recommended)
is that the initial deployment is quick and easy, but
I Update II Delete I
ongoing maintenance is carried out using the Local
Traffic area rather tban the iApps area of the Figure 10: Strict updates enabled on an applicallon
Configuration utility. service.

Note: The ability to disassociate an application service from a template is new in version 11.4.
Once disassociated, the application is referred to as a generic application service.
Enabling/disabling strict updates

To view an application service's strict updates setting, navigate to iApps » Application Services and
select the application service. On the Properties tab, select Advanced from the Application Service:
pull-down. As shown in Figure 10, Strict Updates shows as either unchecked (disabled) or checked
(enabled).
Note: Even with strict updates enabled, you may manually enable and disable some objects
(e.g. virtual servers, pools, nodes, etc.) using other Configuration utility screens or tmsh.

Leveraging the iApps Ecosystem 011 DevC~ntral

iApps configuration poJicies are designed to be portable between BIG-IP systems and between users.
iApp Templates can be exported on a per-application basis and reused throughout the application
network. In addition, they can be exported and shared through the iApp Ecosystem on DevCentral, FS's
community site, where BIG-IP administrators and developers can create, modify, and share their own
iApp Templates for other applications or adjust existing iApp Templates.
FS will routinely release official iApp Templates for new applications through the iApp Ecosystem on
DevCentral; this leverages the engineering work for new applications from FS partners such as Microsoft,
IBM, and Oracle, as well as application templates specific to vertical markets such as financial,
government, and health care.
About DevCentral - http://devcentraI.f5.com/

FS DevCentral is your source for the best technical documentation, discussion forums, blogs, media and
more related to application delivery networking. DevCentral is an amazing FREE resource for all types
of IT organizations and roJes to collaborate and develop cool solutions with peers around the globe.
As a DevCentral member you will have the ability to:
• Ask forum questions
• Rate and comment on content
• Contribute to wikis
• Download lab projects
• Join community interest groups
• Solve problems and search for information
• Attend online community events
tI _ ,. _ . _ .
--
iApps
,-
,- . -"-
---- • --
---
'
> a.--~ __
....-----_...- 0
- .... _
,- ~ ..
- - ..
- _. ._
----
T"PC~
.. - - _....- ....-.. .
...'
_ .... ". ... Pl'
-- .. v- ..---.---.
t. "-'---
_ _ _ L"' _ _
"
,~.,.
III
~
. -------
_.......--
_-_. .. .
FIgure 11: 09vCentral.f5.com pro v;des a weelfh of iApps ~ rel1)fed dOGumentation and templates

Chapter 8 - DeploYing Application Services with IApps 8-15
Lab 8.1 - Deploy a Simple Website Application

Objectives:
• Create a simple website application configuration using an F5-supplied iApp template
Lab Requirements:
• BlG-IP system with standard network configuration (self IPs, VLAN s, etc.)
• Access to the fS.http template (F5-supplied template)

8-16 Chapter 8 - DeploYing Application Services with IApps
Create classroom_website application

I. Create a new HTTPapplication service called classroom_website with the following
characteristics :
Template Selection section
SSL Encryption section

How should the BIG-IP system
Plaintext to both clients and servers
handle SSL traffic?
Virtual Server and Pools section
address do you want
10.10.X.200
Ihe virtual server?
80
www.classroomwebsiteX.com
want to create a new

Create a new pool
one?
Node/lP address: 172.16.20.1 Port: 80 click Add
Which web servers should be
Node/lP address: 172.16.20.2 Port: 80 click Add
included in this pool?
Node/lP address: 172.16.20.3 Port: 80
Application Health section
Create a health monitor or
Create a new HTTP monitor
use an one?
What HTIP URI should be sent
lindex.html
to the servers?
What is the expected response
Server [1-3]
to the HTIP
When complete, click.. . Finished

Chapter 8 - DeploYing Application Services with iApps 8-17
Examine classroom_website components

2. Review the components that were created when you deployed classroom_ website from template
fS.bttp , and answer tbe following questions:
a. Wha l is Ih e status of all the pool members?
b. What is the name and type of the monitor that is checking pool member health?
c. Is the pool membe r monitor part of the classroom _webs ite application service?
d. What a re the statuses of all the nodes?
e. What is the name and type of the monitor that is checking node hea lth?
f. Is the node monitor part of the classroom_website application service?
g. What profiles were created by the template as the result of you acce pting the tem plate' s
default sett ings?
3. Click on the entry for pool cIassroom_websiteyool to navigate directly to its configuration
entry. Note the name of the associated Application in the General Properties section.
4. What load balancing method did tbe te mplate set for classroom_ website.Jlool?
5. Navigate bac k to tbe application service page by clicking on classroom_website in the General
Properties section. Click the Components tab, if necessary, to view the components of the
classroom_website application service again.

Expected results and troubleshooting:

At this point, all your pool members sbould be marked up and available (green circle) by the HTTP
monitor - classroom_website _ http_monitor - that was configured by tbe iApp template and is therefore
part of the classroom _website application service. If your pool members are not marked available, please
consult with the instructor before continuing.
The nodes' status is being set by tbe default node monitor for the BIG-IP system - icmp - which you
configured earlier in thi s class. Although it appears in tbe classroom_website application service's
components view, it is not part of tbe application service.
The fS.bttp template created many profiles (in addition to classroom_website_http) tbat affect the
behavior of the classroom- website- vs virtual server. These include:
• classroom_ websi te_cookie-persistence
• classroom_website_ source-addr-persistence
• classroom_ website_tcp-Ian-optimized
• classroom_ website_tcp-wan-optimized
• classroom_ website_ oneconnect
• classroom_website _optimized-caching
• c1assroom_ website_ wan-optimized-compression
The template set Least Connections (member) as the load balancing method for the pool
classroom_ websiteyool.

Chapter 8 - DeploYing ApplicatIOn Services with iApps 8-19
Test connectivity to your new application service

6. Open a new browser window or tab, and connect to your classroom_website virtual server at
http://10.10.X.200 . Answer the following questions by examining the configuration settings on
the virtual server, pool, and/or pool members.
a. Which pool member did yo u load balance to and why?
b. What is tbe source LP address, as seen by the back end server, and why? Can finn your
answer by viewing the vi rtual server configuration settings for classroom_website_vs.
c. Hard-refresb tbe screen several times. Did you load balance to a different pool member?
Why or why not? Confi.n n your answer by viewing the virtual server configuration
settings for classroom_website _ vs.
7. On your browser window to http://1O.10.x.200, refresh the page several times to ensure you are
persisting, and then delete the BIG-IP cookie and refresh the screen several times again. (Refcr to
the instructions at the start of the first lab in tbis cbapter if you forget how to do this.)
a. Did you continue to persist to the same pool member? Wby or why not? Confinn your
answer by reviewing the persistence settings for the virtual server again .

With http keep-alives disabled on the back end servers (as they are in our classroom environment), the
several http connections required to deliver the entire web page contents would have been load balanced
across all the avaiLable pool members. However, since cookie persistence is configured on tbe virtual
server (via classroom_ website_cookie-persistence profile), once a load balancing decision is made, all
connections will be directed to that same pool member so long as the cookie does not expirc.
Even when you delete tbe session persistence cookie on the client, the next connection will continue to
persist to the same pool member due to the FaUback Persistence Prome which provides source address
affinity persistence. You can look at persistence records statistics to watch how the fallback source
address affinity persistence works in concert with the default cookie persistence to provide persistence
even when no persistence cookie is sent from the client to the BIG-IP system. This configuration can help
in situations where the client has con figured their browser to not accept cookies. However, the expiration
for the fallback source address affi nity persistence profile is only 180 seconds, whiJe tbe expiration in the
cookie persistence profile is session.

8-20 Chapter 8 - Deploying Application Services with IApps
Test the effects of strict updates

8. View the Strict Updates setting for classroom_website by clicking the Properties tab and
selecting Advanced as the Application Service setting. Ensure that the Strict Updates setting is
enabled (cbecked). It should be by default.
Application Service: Advanced section
When complete, click ... Update (if Strict Updates was not already checked)
Test effects of strict updates on enable/disable

9. Click the Components tab of the classroom_website application service, and disable
c1assroom_website_vs. (Check the small box to the left oftbe c1assroom_wcbsite_vs entry and
then click the Disable button at the bottom oftbe page .) Once disabled, its state should continue
to show as Available but with a black circle instead ofa green circle.
a. Were you able to disable the virtual server despite strict updates being enabled?
b. In this disabled state, will the virtual server continue to process traffic? Confinm your
answer by trying to access the virtual server again.
10. Back on the BIG-IJ> system, navigate to Local Traffic » Virtual Servers and enable virtual
server classroom_website_vs from this location in the Configuration utility (rather from the
Components tab of the application service). Were you able to do tbis? What does this tell you
about your ability to enable/disable objects outside of the application service when strict updates
is enabled?
11. Confirm tbat tbe virtual server is now accepting traffic again by refreshing your browser
connection to http://IO.IO.X.200.

Test effects of strict updates on changing configuration settings

12. Attempt to add a fourth pool member directly to pool c1assroom_website-pooJ.
New Pool Members.. . section
Wilen complete, click ...
13. Was your attempt to add a fourth pool member successful? Why or why nor)
14. Disable the Strict Updates setting for classroom_website.
Application Setvice: Advanced section
15. Try again to add a fourth pool member (In.! 6.20.4:80) directly to pool classroom_website~ool
(as you attempted in a previous step).
a. Were you successful this time') Why or why nor)
b. What is the new pool member's status) Is it being monitored? Confinm your answer by
checking the pool member's properties.

8·22 Chapter 8 . Deploying Application Services with iApps
Test effects of making configuration changes outside of the application service

16. Navigate back to application service classroom_website and click the Reconfigure tab to
reconfigure this application service. The responses to the questions will be set as they were the
last time you reconfigured the application service (or, in this case, as you initially deployed it).
17. In the Virtual Server and Pools section, look at the values to the right of the question, "Which
web servers should be included in this pool?"
a. Does the application service know about the fourth pool member you added manually
(meaning outside of the application service)?
b. What do you think will happen if you click the Finished button at this point?
18. Click the Finished button. This will reconfigure the application service using the same settings as
when you initially deployed it. On the Components tab, click the entry for
classroom_ website.Jlool, then click the Members tab. What happened to the fourth pool member
you added manually earlier?

With Strict Updates enabled, you can change the state of an application service's virtual servers, pools,
and pool members (e.g. enabled, disabled, forced offline) using the Components page of the application
server, the configuration object's page, and/or ttnsh. However, you cannot modifY the object's
configuration settings, except through the Reconfigure tab of the application service.
With Strict Updates disabled, you can modify an application service's components settings directly or
using the Reconfigure feature of iApps. However, mixing and matching the two can result in
configuration mistakes, as in the case of the fourth pool member that went missing. It was added
manually, but the application service had no knowledge of it, therefore its association with pool
classroom_ website.Jlool was deleted when you reconfigured classroom_website application service.
Reconfiguring an Application Service

Add a fourth pool member
Now let's add that fourth pool member to classroom_website--",001 using the FS-recommended method
by reconfiguring the application service itself, rather than by modifYing the pool directly.
19. Re-enable strict updates for application service classroom_website.
20. Click the Reconfigure tab to begin the reconfiguration process.
21. Scroll down to Virtual Server and Pools section, and specifically to the question, "Which web
servers should be included in this pool?" Click the Add button to add pool member
172.16.20.4:80. Click the Finished button to generate the reconfigured application service.
22. Is pool member 172.16.20.4:80 now a component of application service classroom_website?
What is its status? Is it being monitored? By what monitor?
8·22 Administering BIG·IP v11

23. Navigate to pool classroom_websiteyool and view its members. Does the fourth pool member
sbow here as well? What is its status?
24. Wait until the fourth pool member's status changes as the result of its associated health monitor
test. (Check the assigned monitor's interval and timeout settings to determine how long you
might have to wait.) What did the pool member's status change to? Why?
25. Reconfigure the application service so that the expected response setting on the healtll monitor
will allow for a successful response from the fourth pool member. Confirm that the monitor is
now receiving a successful response.
Reconfigure classroom_website using "Advanced" Configuration Mode

26. Reconfigure the classroom_website application using the following settings. (For all settings
other tban what is shown here, leave as is.)
Template Options section

Which configuration mode do
Advanced Configure advanced options
want to use?
Natwork section
have you configured Servers have a route to clients through the BIG-IP
web servers?
Virtual Server and Pools section
Should the BIG-IP system
insert the X-Forwarded-For Do not insert X-Forwarded-For HTTP header
header?
Which persistence profile do
Do not use persistence
want to use?
Which load balancing method
Round Robin
do want to use?
0eIiveIy Optimization section
Which Web Acceleration profile
Do not use caching
do want to use for
Which compression profile do
Do not compress HTIP responses
want to use?
Server Offload section
Which OneConnect profile do
Do not use OneConnect
want to use?

27. Refresh your browser window to http://IO.IO.X.200 and view the results. How is traffic through
the application service behaving differently with these new settings?
a. Is source address translation (SNAT) being perfonned?
b. Is traffic pe"isting?
c. Does you r browser sti ll have a cookie from when cookie pe"istence was configured on
classroom_website_ vs? If so, why are you not pe" isting?

During reconfiguration, when you indicated that the servers have a route to clients through tbe BLG- IP
system, tbis caused the virtual server to be configured without source add ress translation (SNAT).
Even though there may have been a pe" istence cookie left over from earlier io the lab, it was ignored by
the BIG-IP system as your virtual server was configured withou t a cookie persistence profile.
Continue with Lab 8.2 Oeploy a Custom Application SeNice

Lab 8.2 - Deploy a Custom Application Service

Objectives:
• Recreate the student's BIG-IP system configuration using an iApp
Lab Requirements:
• BIG-IP system with all configuration objects from the previous labs
• Access to the ClassSetup.tmpl iApp template.
Deploy a Custom Application Service

In this lab, you will deploy an application service that was custom designed and built to recreate the BIG
IP classroom settings you've created and used throughout the course so far (with the exception of the
components you just created in the previous lab). It also creates some other configuration objects that will
be used during later labs. The purpose of the lab is to demonstrate the flexibility of iApps in creating
custom configurations that meet very specific business needs.
Your instructor will let you know where you can find the iApp template required for this lab. Copy it
from the location provided to your workstation desktop before starting this lab.
Save the Current Configuration

I. Confirm your current network configuration using Local Traffic » Network Map. At this point
in the class, it should looks something like Figure 12 (or at least show the same configuration
objects):
Local Trame Network Map
• clanrcom_web$"lte_\' s: 113 .$_hUps tI v S_5Sh
• clanroom_websH..e-p ool QI hUp$J>ool ~ n h_pDol

. 172. 16.20.1: 80 [] 172.1 6.20.1 :443 a 172.16.20.1:22
G 172.16.20.2:80 112.16.20.2:443 172.16.20.2:22
• 171.16.10.3: 80 a , 72.1 6.20.3:443 g 172.16. 20. 3:22
172.16.20.4:80
• VI_ssl
G .._http http_poo l
htlP"'poOI lilt 172.16.20.1:80
• 112.16.20.1 :80 . , 72.16.20.2 :80
172.16.20.2: 80 1 72.16.20.3:80
• '72.16.20.3:80
Figure 12: Prior to the sta rt of this lab, your network configuration should look som &ttling like this.

8-26 Chapter 8 - Deploying Application Services with IApps
2. Create a UCS arcbive of your current BIG-IP system configuration using e ithe r the Configuration
utility or tmsh . Call the archive trainX_ modS.ucs.
3. Confirm the UCS was successfully created before continuing with the next steps. Download the
UCS to your hard drive, if you'd like extra insurance!
4. Restore your BIG-IP system from the UCS archive called trainX_base.ucs using either the
Configuration utility or trnsh . This archive will restore the BIG-IP system to its configuration
state just after you completed the Setup utility in tbe very first lab of this class, in effect removi ng
a ll the o bjects you have created until now, and the c lassroom_website application service you
created in the previous lab.
5. Using either tbe Configuration utility or trnsh (or both), confirm that you no longer have any of
the configuration objects you saw via the Network Map at the start of this lab. Also conlirm that
you are no longer able to access any of your back end applications by trying to establ ish browser
sessions to http :// IO.IO.X.IOO, https://lO.IO.X.IOO, and https://lO.IO.X.I 0 I, and an SSH session
(via PuTTY) to 10.lO.X.100:22. (Remember to refresh via Ctrl-F5 to force a reload of the page
from the website and not from your browser's cache.)
Import the iApp template

6. Import the ClassSetup.trnpl iApp template you copied to your desktop at the start of this lab.
iApp "Templates and click Import
Import File section

Click Choose File and navigate to the location
File Name of the ClassSetup.tmpl you copied to your
desktop earlier
When complete, c lick... I Upload

Deploy the application service from the template

7. Deploy an application service named ClassConfig using the iApps template you imported in the
previous step. When you select the template option, additional screen details will appear below
under the heading Setup Options.
Template section
Setup Options section
Finished
Verify application service's configuration objects status

8. If you deployed your application services successfully, you should now be sitting at the iApPS»
Application Services Components » ClassConfig screen with the Components tab selected in
the menu bar area, and a very long, scrollable list of configuration objects.
9. Compare and contrast the list of objects you see on the ClassConfig components page with the
inventory of objects you saw in the Network Map earlier. You should see the same configuration
objects you created manually throughout the day today - virtual server>, pools, pool members,
profiles, and monitors. Also, the relationship of the objects is clearly mapped out, similarly to but
in more detail than what is available using the Network Map. The only difference is, in this case,
the objects were created by and are grouped together under the common application service called
C1assConfig.
Demonstrate the application service's behavior

10. Open a new browser session and connect to http://IO.IO.X.IOO. Refresh the screen 5-10 times.
Does it work and, more importantly, behave the same way as when you left it at the end of the 7.2
Cookie Persistence Lab? Here are some things to check for and confirm behavior of:
a. Load balancing method
b. Persistence
c. Source address translation

II. Open a new browser session and connect to https:1Il0.10.X.IOO. Refresh the screen 5-10 times.
You should be connecting securely (SSL) all the way through to the back end application servers.
Are you persisting? Ifso, with what method?
12. Open a new browser session and connect to bttps:IIIO.IO.X.IOl and test this virtual server's
functionality . You should be seeing SSL encryption on the session from your PC to the BIG-JP,
and no SSL encryption on the session between B1G-lP and the pool member due to the
assignment of the client SSL profile Pr_ Client_ SSL on this virtual server.
13. Open an SSH session (using PuTTY) to 192.168.X.31. Attempt to log in as root/rootX to verify
access to the bash shell. Are the credentials working?
14. Open an SSH session (usi ng PuTTY) to lO.IO.X.31. Log in as adminiadmiuX to verify access to
tbe basb shell.
15. Open an SSH session (using PuTTY) to lO.10.x.l00:22. Log in as student/student to verify that
this virtual Server is also working correctly.
16. lfall testing was successful, please close all browser sessions except your BIG-LP window. Also
close tbe SSH session window.
Note: If any of your testing was not successful, please notify the instructor immediately. We will
be using this configuration as the foundation for the remaining labs in this class.
View the iApp template that built this application service

17. View the ClassSetup iApp template that was used to create tbe C1assConfig and
Course_Administering application services by navigating to iApp » Templates and clicking on
C1assSetup. Scroll through tbe Implementation window and look at the template code. You
sbould notice many tmsh commands scattered throughout the template. See if you can find the
commands that were used to create the basic network objects (VLANs, SelfLPs, etc .) and the
local traffie objects (virtual servers, pools, pool members, profiles, etc.) for our classroom
"application." Important: Please do NOT modify the template. If you accidentally change
something in the Implementation window, simply click on the Template Properties button in tbe
menu bar area to refresh the screen without saving.
18. Notice the other Properties that can be associated witb an iApp template, including minimum and
maximum BIG-IP version and required BIG-IP modules.
19. View the contents of the Presentation window to see how the iApp builds its own GUI page with
questions and responses for you to respond to during deployment. Important: Please do NOT
modify the template.
8-28 Admmistering BIG-IP v11


The ClassSetup iApp deployed an application service that contains all of tbe configuration objects you
created throughout the day yesterday. The only configuration objects it did not create were those
associated with the first lab in this chapter ~ the classroom~ website application elements.
Deleting an application service deletes all of the configuration objects owned by that application service
with the exception of any nodes that might have been implicitly configured as tbe result of deploying pool
members.
STOP


Chapter 9 - Troubleshooting the BIG-IP System 9-1
Chapter 9: Troubleshooting the BIG-IP System

Chapter Objectives
• Direct BlG-lP system log messages locally, remotely (using legacy syslog functionality), and
remotely (using high-speed logging)
• Configure the BlG-lP system to send SNMP alert messages remotely
• Use the tcpdump command line tool on the BlG-lP system in support of troubleshooting
• Generate and upload a qkview file to BlG-lP iHealth, and use it to view the resulting diagnostics
• Work with F5 Technical Support to open a support request and supply appropriate documentation
Con'figuring Logging
Lesson Objectives
At the end of this lesson, you will be able to
• View and describe BlG-lP log information using the Configuration utility and tmsh
• Set minimum log levels for various local traffic events
• Describe the BlG-LP log rotation process
• Configure remote logging
Introducing BIG-IP System Logging

Viewing and managing log messages are important parts of maintaining a BlG-IP system. Log messages
inform you on a regular basis of the events that are happening on the system.
You can log events either locally on the BlG-LP system or remotely using legacy or high-speed logging
functionality. The recommended way to store logs is on a pool ofremote high-speed logging servers.
For local logging, log data is stored in local files and databases. For remote logging, the high-speed
logging mechanism sends log messages to a pool of logging servers that you define.
BIG-lP has the ability to log different types of events ranging from Linux system events to local traffic
events to changes to the BlG-LP system configuration.
Types of log messages

The high-speed logging mechanism can log many types ofmessages including:
• BIG-lP system-level events
• DNS events (for local and global traffic)
• Network firewall (AFM) events
• Protocol Security (PSM) events
• Carrier-grade NAT (CGNAT) events
• Denial of Service (DoS) protection events

9-2 Chapter 9 - Troubleshooting the BIG-IP System
Existing (legacy) syslog configurations

If you previously configured the BIG-IP system to log messages locally using the syslog utility or
remotely using the syslog-ng utility, you can continue doing so with your current logging configuration in
version 11.4. In other words, you don't bave to specifically configure high-speed logging when
transitioning to version 11.4. Legacy logging configurations will continue to work without modification.
Alternatively, you can configure local syslog logging using the high-speed logging mechanism, which is
the recommended syslog configuration. By configuring syslog using high-speed logging, you can easily
transition to the other features of high-speed logging at a later time, without having to perform significant
reconfiguration.
Logging locally
The mechanism that B1G-IP uses to log events is the Linux utility syslog-ng, an enhanced version of the
standard UNIX and Linux logging utility, syslog. Each type of event is stored in a separate log file, and
the information in each log file varies depending on the event type. By default, BIG-IP logs these event
messages locally in the directory Ivarllogl. Some of the log files contained in this directory are shown in
the table below:
Facility_ C:().I11~()"~ ~..!. .Delll.lI~t Log_ Facility. CO lT1 p().~.ent De~l!.!t ~g

10cal0 LTM Ivar/log/ltm local4 iControl Ivar/log/ltm
locall EM Ivar/loglem local5 Packet filters Ivar/log/pk tfi Iter
locall APM Ivar/log/apm local6 Configuration utility errors /var/log/httpd
local2 GTM Ivar/loglgtm local7 Linux specific boot Ivar/log/boot.log
local3 ASM Ivar/log/asm messages Ivar/log/audit
WebAccelerator Ivar/log/wal Audit messages Ivar/log/daemon.log
System daemon
messages
Syslog-ng uses facilities and levels to describe system messages. Facilities describe the specific element
of the system generating the message, as show in the table above. Levels describe the severity of the
message, as shown in ttle next table.
BIG-IP System Log Records

Log levels
The system log messages that BIG-IP logs contain several types of infonnation. All log messages include
a time stamp. The other information varies depending on the event, as shown in the table below.
(Verbosity indicates the amount of infonnation contained in the message.)
Level Description Verbosity

emerg Emergency system panic messages Minimum
alert Serious errors that require administrator intervention Low
crit Critical errors, including hardware and filesystem failures Low
err Non-critical, but possibly very important, error messages Low
warning Warning messages that should at least be logged for review Medium
notice Messages that contain useful information, but may be ignored Medium
inlo Messages that contain useful information, but may be ignored High
debu!iI Messages that are only necessary for troubleshooting Maximum
9-2 Administering BIG-IP vll

Log message content

The messages that BIG-LP logs contain several types of infonnation. All log messages include a time
stamp. The other infonnation varies depending on the event. Figure I shows sample messages from the
System log, the Local Traffic log, and the Audit log:
I' ~
.. TlfllI!Stamp Log Level Ho!il SeMce Event
Thu Oct 3104:02:05 POT 2013 notice bigip4 syslog- Configuration reload request received, reloading
ng(3005] configuration;
.. Timestamp Level Hosl Service Slalus Code Event
Thu Oct 31 10:00:03 PDT 2013 notice bigip4 mcpd[5828] 01070639 Pool fCommonlhttpsyool member
ICommonl172.1S.20.2:443 session
status enabled.
Thu Oct 31 10:00:03 PDT 2013 notice bigip4 mcpd[5828] 01070638 Pooll/Common/https_pool member
ICommon/172.1S.20.2:443 monitor status
unchecked. [ 1[ was forced down for
19hrs:17mins:24sec 1
SYIOIom H !..'Hl:' A,~H':I: :.. ~l
.0 ... ::i~t'rTI :crtJ'uo,:J r,,,, saCIIO'll P"CI'i!" Frnll'l Loce -rlf1Tl: Audit .. ,. rlr.Yll':tlI11Jl ..
--=:J~
~'l"IMction UEvent
User Name .. T
F rt Nov 109:01 :14 PDT 2013 admin 0-0 htlpd(mod_au1hyam): user=admln(admin) par1illon={AJ~ level=Admlnlslr2llor
lty=lusrlbif1l1msh hosl=192.166.4.30 attempts=1 slart="Fn Nov 1 09 :01:14
M
2013 . :
Fri Nov 1 09:08 :53 PDT 2013 rool Il-O sshd(p am_audlt): user-rool(rool) partilion=[AJ~ level=Admlnislralor tly=ssh
host=10.10.4.30 attempts=1 slar1="Fri Nov 1 09 :06 :532013".:
Fri Nov 1 09 :16:10 PDT 2013 rool 0-0 sshd(pam_2Iudil): user-root(re ol) parti1ion=[AJ~ tevel=Admlnislralor tly=ssh
host=10.10.4.30 attempts=1 slar1="Thu Oct 31 15:22 :24 2013- end="Fri Nov 1
09:16:10201r.:
Fri Nov 109:16:19 PDT 2013 root Il-O sshd(pam_2IudH): user=root(rool) partition=[AJ~ level=Administrator lI'y-ssh
hOst=10.10.4 .30 attempls=1 star1=· Thu ad 3113 :53 :40 2013"end="Frl Nov 1
09 :16:192013-.:
Figure 1: (top) Sample System log messages; (middle) Sample Local Traffle log messages; (bottom) Sample Audit
log messages

Local log access

Access to view the local logs using the Configuration utility and tmsh is controllcd by user role. By
defaul~ Administrators, Resource Administrators, and Auditor roles have access to view the logs. Other
roles do not. If needed, you can change these defaults at System » Logs: Configuration: Options in the
Configuration utility.
Setting local log levels

Using the Configuration utility or tmsh, you can set local log levels on local traffic events (LTM), global
traffic events (GTM), access policy events (APM), and on auditing events. For each type of traffic event
(e.g. HTTP, HTTP Compression, IP, MCP, etc.), you can set a minimum log level. The minimum log
level indicates the minimum severity level at which the BIG-IP system logs that type of event.
For auditing events, you can set a log level that indicates the type of event that the system logs, such as
user-initiated loading of BIG-JP system configurations, or system-initiated configuration changes.
The log levels that you can set for local traffic events are:
...-..Highest
. . ..- ...Severity
. .- - Level
===- - -- --
...
- --=::;;-r;:;:;:;:;;-;:;;;;;;:;;;.----
• Lowest Severity Level
Emergency r Alert Critical [ Error - [ Warning [ Notice I Informational I Debug
For example, by default, only Warning level or higher Network event messages are recorded to local
logs. If you changed the minimum log level for Network events to Error, then the BIG-JP system only
logs Network-generated messages that have a severity of Error or higher. However, when you set up
legacy remote syslog servers, all log messages are delivered remotely, regardless of the local log level
settings, leaving it up to the remote syslog software to filter out and deliver log messages to the
appropriate log server destination.
Note: For detailed instructions on setting local log levels, please see SOL5532: Configuring the
level of information logged for TMM-specific events. Also, check each BIG-IP product's
documentation for specific instructions on what events can be logged, and how to configure
such logs.
Audit log events
The log levels that you can set for audit events are as follows:
o Disable - (Default) Turns audit logging off.
o Enable - Log messages for user-initiated configuration changes only.
o Verbose - Log messages for user-initiated configuration changes and any loading of
configuration data (e.g. via tmsh load / sys conf ig).
o Debug - Log messages for all user-initiated and system-initiated configuration changes.
Local Syslog Management

You can view current local BIG-/P log files and filter the log messages contained within using either the
Configuration utility or trnsh. The Configuration utility provides a simpler interface and an easy search
string filtering mechanism, as shown in Figure 2.
To view standard system, packet filter, local traffic, or audit messages using the Configuration utility,
from the Navigation pane, select System » Logs.

.. Tlmestamo Log LewJ Host Sel\llr:e E!fEIfll
non Cd 1 04:02:04 PDT 20f2 l10tice bloiP2 s)'~lo g - Conligurabo n reload request rece ived, reloading co n ti ~ urallO n:
ng(115061
Figure 2: Sample system log as viewed from the configuration utility
To view log files using tmsh, use the show log command. For example, to display the current Local
Traffic log:
tmsh show /sys log Itm
To use the command line to watch log messages being recorded to a local log file, you can use the Linux
command:
tail -f /var/log/<logfile>
For example, to view log messages as they are recorded to the localltm log file, run:
tail -f /var/log/ltm
Local log file rotation process

Active local log files are automatically archived using a log rotation process that is managed with the
following log configuration elements:
• Log rotation frequency - daily, weekly, or monthly. (Default is daily.)
• Age at which log files become eligible for removal (0 to 100 days; default is 8 days)
• Number of archive copies tbe system retains (0 to 100 copies; default is 24)
• Custom log rotation options (e.g. rotate only when a log file reaches a particular size)
For complete instructions on customizing the log rotation process, please refer SOL 13367:
Managing log files on the BIG-IP system (11.x)
Each archive is a compressed file in standard gzip format with a .gz suffix placed in the
ivarilogldirectory. A number is used just prior to the suffix to indicate the archive's relative position in
the rotation. For example, the most recent LTM log archive will be named Itm,Lgz; the oldest archive
will have the largest number before the .gz suffix (e.g. Ilm.B.gz, if there are 8 archives currently in
rotation).
Note: The Configuration utility can only be used to view active log files. To view log archives,
you can use tmsh or the command line.

Legacy Remote Logging

BIG-IP can be conligured to save log liles on one or more remote syslog servers instead of to local
directories.
Configuring remote syslog servers using the Configuration utility

The BIG-IP Configuration utility provides a basic means for configuring remote syslog servers. Using the
Configuration utility, you can add a server to the remote syslog server list and customize it to specify the
remote lP address and port, and optionally a local IP address for BIG-IP syslog to bind to when sending
logs to the remote server. The default port is preset to 514, and the protocol is UDP only.
System IJ LI"HjS ConflgtH JIIOIl Rerno[(' Logging
0... ::;"{sttll1 PBC+C~I FIIl'!!1 LOC~l ' Traffic AUlllt .. ConfiguralJon ..
Properties
Remote 1P : ~10'10'1 '3~

Remote Port : 514
~~~~~~~~~
LocallP: (Opllonal)
~
10 10 1.30514
Remote Syslog Serve, List
I EdD I Delete I
I Update I
Figure 3: Adding a remote syslog server to the remote sysfog server list using the Configuration utility
The BIG-lP system automatically names each remote syslog server listed using its own naming
convention (e.g. remotesyslogl, remotesyslog2, etc.).
Note: To configure extensive syslog-ng custom izations, you must use the command line. See
the section entitled Customizing syslog-ng later in this chapter.

Configuring and viewing remote syslog servers using tmsh

To make the sa me configuration change as shown in Figure 3 using tmsh:
tmsh mod ify / sys sys l og remote-servers add ( mysysl og1 ( host
10.10 . 4. 30 r e mo te-po rt 514 )}
The port designation is not necessary since 514 is the default. There is also no way on this particular
corrunaod to specify ao LP-protocol other thao UDP. However, when configuring remote syslog servers
using tmsh, you are required to provide a name for each remote server entry. In this example, we're
adding a single remote syslog server using the name mysyslogl at IP address 10.10.4.30, port 514.
This adds the remote syslog server to the running configuration, and log messages irrunediately begin
sending to the destinatioo identified. If the remote server configuration is to be permanent, you should
issue a tmsh save / sys cont ig corrunaod to update the stored configuration files .
Remote syslog configuration files

The BIG-LP system saves remote syslog configuration information in the bigip_base.conffile. For
example, if the previous tmsh command had been executed, and the running configuration saved, an entry
would be created in the bigip_base.conffile that looks similar to this:
sys syslog (
re mo te - servers {
/Co mmon/mysyslog1
host 10.10.4.30
Customizing syslog-ng on the BIG-IP system

In the previous sections, we showed you how to customize the local syslog settings by changing logging
levels and logging access in the Configuration utility. We also showed you how to set up a basic remote
sys log server configuration using the Configuration utility and tmsh. However, any custom.izations to
logging levels apply only to local logs; they do not apply to legacy remote syslog servers - at least not
using tbe techniques presented so far.
As a result, in the previous example, the minute the server with lP 10.10.4.30 is added to tbe remote
syslog Server li st, the BIG-IP system begins sending all syslog messages to this address, regardless of the
logging level or the logging source. 11 is left up to the software on the remote syslog server to filter the
results and direct messages appropriately to their final destioation . In other words, wheo logging locally,
the BlG-IP system has default syslog-ng filters that you can somewhat customize with the Configuration
utility and tmsh in order to affect what gets logged.
In order to make extensive customizations to syslog-ng, you must use the command line. Such
customizations include but are not limited to:
• Logging to a remote syslog server using tbe TCP protocol
• Customizing loggi ng levels
• Setting up multiple logging destinations
• Directing specific log messages to specific destinations
Note: For more info, see SOL 1333: Filtering log messages sent to remote syslog servers (11 .x)

Introducing High-Speed Logging

Prior to 11.3, different systems would produce log messages via different mechanisms, and their
configuration was totally independent of one other. Easy configuration of remote system logging via the
Configuration utility has been available since 11.1. But this legacy remote logging functionality dumped
every log message from every BIO-IP system process to the remote syslog hosts defined. lt was up to the
remote log hosts to filter and route log messages to the correct remote log files.
Starting in version 11.3, it is much easier to separate and direct log messages produced by the many B10
lP system processes. A new system filtering mechanism allows you to direct system log messages based
on any combination of the following criteria:
• The service that generated the log message (e.g. mcpd, tmm, etc.)
• The severity level of the message (e.g. error, notice, warning, etc.)
• The message lD number
Logging systems are now inter-connected and each system can be configured to use the new Higb Speed
Logging (HSL) facility in TMOS to send messages to load-balanced pools of remote log servers. One
practical effect is that the Linux host processes can also log to remote log servers via HSL with a
comprehensive mechanism to filter the log messages outbound.
High-Speed Logging Filters

The key piece of the new HSL functionality is the ability to configure filters that direct particular log
messages to particular log destinations through what's called a publisher. When put into the context of
the B10-lP system's legacy syslog functionality, the relationship is clear, as shown in Figure 7. [fan HSL
filter exists for a generated log message, the log message is processed by the HSL destinations for that
filter. If no filter exists, the log message is processed by the legacy syslog which means the message will
be directed to the local syslog or to a legacy remote syslog server.
Yes
HSL filter match?
Syslog
No (legacy)
Figure 4 ~ When a syste m log message is generated, if a ma fc hing HSL filter exisrs , ",e message will be processed by
HSL. If no filter exists, the message is processed by legacy syslog functions.

Filter criteria
When you create a custom HSL log filte r, you specify criteria that tie the filter back to one or more log
messages. Filter criteria include:
• Message severity level
emergency
• Message source
• Message lD
• Log publisher critical
Message severity level error
The severity level that you select includes that level plus all
higher levels. For example, if you specify severity level as notice, warning
as shown in Figure 8, the filter covers all log messages with a log
level of notice through emergency. (Any other filter criteria
specified also applies.)
Message source
Message SOurce identifies anyone of the BIG-lP system processes
debug
that generate log messages (e.g. big3d, mcpd, tmm, tmsh,
Figure 5: The severily level that you selecl
tcpdump, etc.) You can also set this option to all to log messages for B r.i!er i" c/udes th at level and a/l higher
from all processes, or to no-source as a convenient way to turn severity IOVf::/S
off a log filter without completely removing it.
MessagelD
In addition to specifying a message severity level and message source, you can further fi lter the messages
a fi lter will apply to by specifying the 8-hex-digit lD number that appears in the log message (e.g.
01071434 or 0 13e0002). Only one message 10 is supported in v 11.4.
Log publisher
A filter's log publisher setting specifies the publisher to which the system sends messages that match the
filter criteria. A publisher is the first in a series of new configuration objects on BIG-IP v 11.4 that support
high speed logging functionality. Setting Log Publi sher to None causes the log messages matching the
filter to be discarded.
HSL Configuration Objects

Figure 8 illustrates the new high-speed logging configuration objects and their relations hip to one
another. System log messages that match an HSL filter will be sent to a publisber, a configuration object
whose definition consists of a list of one or more destinations. Generally, those destinations will be
formatted destinations. The formats supported are:
• Remote Syslog
• Remotc High-Specd SysJog
• SpJunk
• ArcSight.

The function of a fonnatted destination is to essentially convert the fonnat of a log message to the fonnat
used by the remote Jogging server. The fonnatted destination then passes the message to its associated
higb-speed logging destination, which consists of a pool name. The high-speed logging destination then
forwards the log messages to the named pool of log servers.
Note: An HSL publisher can point directly to a high-speed logging destination (i.e. without an
intermediary formatted destination).
List of destinations Pool name
Pool
Supported fnr·rT1J~t", Log

• Remote High-Speed Log servers
• Remote Syslog
• Splunk
• ArcSight
Figure 6: The relationship of high-speed configuration objects to one another on the BIG-IP system (publishers,
formatted destinations, high-speed fogging destinations, and log server poois

Monitoring the BIG-IP System Remotely with

SNMP
Lesson Objectives
• Configure the SNMP agent on the BIG-IP system
• Configure a custom SNMP trap on the BIG-lP system
Understanding SNMP
The Simple Network Manage ment Protocol (SNMP) is an industry-standard protocol for monitoring
de vices on lP networks. You can configure the BIG-IP system with SNMP traps and an SNMP agent that
sends data to an SNMP manager, as illustrated in Figure 4. The BIG-lP system supports several SNMP
versions including SNMP vi , v2, and v3.
Note: Effective in version 11 .3, BIG-IP High-Speed Logging (HSL) supersedes SNMP traps
when configured for the same log messages. When HSL is in effect, SNMP traps/alerts and
associated notifications should be configured on the remote syslog server software (e.g. Splunk,
ArcSight, etc.). The SNMP agent functionality on the BIG-IP system is not impacted by HSL.
• 172.16.20.1
Trap: Device unavai lable
S Poll: Collect metrics

manager
Figure 7: The BIG-IP system includes an SNMP agent that call response to polls for performance metrics from a
remote SNMP manager. The B IG-IP system 's a'erld component can also sent alert messages to the SNMP manager
based on default or custom-defined SNMP lIaps.
A standard SNMP implemenl<ltion consists of an SNMP manager, which IUns on a network management
system and makes requests to the BIG-IP system, and an SNMP agent, which runs on the BIG-lP system
and fulfills requests from the SNMP manager. SNMP device management is based on the standard
management informatioD base (MlB-II), as well as object lOs and MLB files.
• MIB - Defines the Sl<lndard objects you can manage for a device, as presented in a hierarchical
tree structure.
• 010 - Each object defined in the MLB has a unique object lD (OLD) written as a series of
integers . An OLD indicates the location of the object within the MLB tree.

• MIS files - A set of Mill files resides on both the SNMP manager system and the managed
device. Mill fil es specity values for the data objects defined in the Mill. This set of Mill files
consists of standard SNMP MlB files and enterprise MIB files - those Mill files that pertain to a
particular company, such as F5 Networks, Inc.
Some of the tasks an SNMP manager performs includes polling for device data, receiving event
notifications from a device, and moditying writable object data.
Big-IP's SNMP implementation

BIG-IP includes an SNMP agent, a set of standard SNMP Mill files, and a set of enterprise MlB files
specific to F5 Networks, Inc. The enterprise Mill files typically reside on both the BIG-IP system and the
system running the SNMP manager. You can use the Configuration utility to download F5's enterprise
Mill files to your SNMP manager.
Using the BIG-IP implementation ofSNMP, your SNMP manager can:
• Poll BIG-JP for information (such as performance metrics)
• Receive notification of specific BIG-JP events
• Set data for SNMP objects that have a read/write access type
Configuring SNMP on BIG-IP

Before you can use an SNMP manager to remotely manage a BIG-IP system, you must perform tile
following activities on BIG-JP, using the Configuration utility:
• Configure the SNMP agent
Several options exist for configuring the SNMP agent on the BIG-JP system. The SNMP manager
can poll (get) the SNMP agent on the BIG-IP system to collect data at specific intervals. This
method use usefu l for capturing performance trends on the BIG-IP. Or traps can be set on the
BIG-IP system to trigger when particular events occur. When the BIG-IP alert daemon detects
such an event, it triggers the appropriate actions, such as sending unsolicited notification
messages to the SNMP manager providing information about the event. Without traps, a network
administrator might not discover a prOblem situation until the next time the SNMP manager
polled (solicited) the SNMP agent.
• Dow nload tbe MIS fLIes
You can download two sets of Mill files to your remote manager system: the standard SNMP
Mill files and the F5 enterprise Mill files. Both set of files are present on the BIG-lP system, in
the directory l usrlsbare/snmp/mibs/. You can download these files from the Welcome SCreen of
the Configuration utility.
Configuring the SNMP agent on BIG-IP

You configure the SMNP age nt on BIG-lP by performing the following tasks:
• Configure SIG-IP system information - Specity a system contact name and the location of the
BIG-IP system
• Configure client access to the SNMP agent - Configure BIG-IP to allow access to the SNMP
agent from an SNMP manager system

• Control access to SNMP data - Assign access levels to SNMP communities or users to control
access to SNMP data
• Configure traps - Enable or disable traps and specify the destination SNMP manager system for
SNMP traps
Note: Only users with either the Administrator or Resource Administrator user role can
configure SNMP on the BIG-IP system.
Collecting performance data

In the Statistics area of the Configuration utility, you'll find graphs showing perfo011ance metrics for the
BIG -IP system. You can use SNMP to collect the same information, including:
• Memory use
• Number of active connections
• Number of new connections
• Throughput in bits per second
• Number of HTTP requests
• RAM cache use
• CPU use
• Number ofSS L transactions
Each metric has one or more SNMP object IDs (OIDs) associated with it. To gather performance data,
you specify these OIDs with the appropriate SNMP command.
SNMP trap configuration

Configuring SNMP traps on a BIG-IP system means configuring the way that the BJG-JP system handles
traps, as well as setting the destination for notifications that the alert system and the SNMP agent send to
an SNMP manager.
The BIG-I.P system stores traps in two specific files:
• /etc/ alert d / aler t. conE - Contains default SNMP traps. important : You sbould not add or
remove traps from this fi Ie.
• /conEig / user_aler t. conE - Contains user-defLDed SNMP traps.
You use the Configuration utility to enable traps and set trap destinations. When yo u configure traps, the
BJG-\.P system automatically updates the appropriate alert file .

System •• SNMP : Traps : D£I!it!n"tlon .. N~w Tr.,p R~cord .
Record Properties
Version ·1
Community I Public
Destination 1 10.10.1.30
Port
1 Cancel I 1 Finished 1
Figure 8: Example of SNMP trap destination configuration using the Configuration utility
BIG-IP pre-configured and custom traps

The BIG-IP system includes standard, pre-configured SNMP traps to enable communication with the
remote SNMP manager regarding events of interest occurring on BIG-IP. These events of interest (alerts)
are defined in the fil e /etc/alertd/alert.conr. Alert defmitions configured to trigger an SNMP trap will
contain the snmptrap command. Here's an example of what such an alert definition might look like:
alert BIGIP_SYSTEM_CHECK_E_CPU_FAN_SP EED_LOW {
enmptrap 100=" . 1.3.6.1. 4.1. 3375.2.4.0.5";
lcdwarn des c ripti o n=" CPU fan too slow." priority ::"3"
BIG-IP also supports custom, user-defined SNMP traps. These are defmed in the /conlig/user_alert.conr
file .
User-<l efin ed SNMP traps take precedence over the pre-configured SNMP traps. Ifule same trap is
configured in both files, BIG-LP will use the user-defined trap instead oftne pre-configured trap .
Note: F5 does not recommend or support the manual addition or removal of traps {or any other
changes) to the alert.cont file. Use the Configuration utility or tmsh to disable unwanted pre
configured traps, Create custom, user-defined SNMP traps in Icontig/user_alert.cont using
either the Cnfiguration utility or tmsh.
For more information on creating custom SNMP traps, refer to the Custom SNMP Traps article
on the DevCentral site or to S0L3727: Configuring custom SNMP traps.
Enabling traps for specific events

You can configure the SNMP agent on the BIG-IP system to send. or refrain from sending, notifications
when the following events occ ur:
• The SNMP agent on the BIG_lP system stops or starts. By default, this trap is enabled,
• The BIG-IP system receives an authentication warning, generated when a client system attempts
to access the SNMP agent. By default, this trap is disabled.
• The BIG-LP system generates a device warning. By default, thi s trap is enabled .

Configurabon
~ge nt stan I ~op tlI En a Dlod

.t.g'8nlAult1£1r'1lic:ati on
De ¥fce: , Enabled
Figure 9.< Enabling traps for specific events using the Configuration utiflty
You can enable or disable these specific events using tbe Configuration utility. Navigate to System»
SNMP » Traps» Configuration.

Using tcpdump on the BIG-IP System
Lesson Objectives
At the end of this lesson, you will be able to use the tcpdump command to observe traffic flowing through
a BIG-lP system.
tcpdump Overview
tcpdump is a common packet analyzer that runs under the command line on most Unix-like operating
systems such as Linux. lt can be used in the BIG-IP environment to intercept and display lP packets being
transmitted or received by BIG-IP. It is the primary command line utility used for troubleshooting packet
flow on BIG-lP and otber network devices.
tcpdump "prints out" a description of the contents of packets on a network interface that match a Boolean
expression. The printout can be directed to the command line screen in real time Cas the packets are
received/sent) or can be saved to a file for later analysis - or both.
A single execution oftbe tcpdump command will report on only one network interface at a time.
However, multiple instances of the command can run concurrently to report on traffic over multiple
network interfaces.
Several tcpdump command options exist to control the network interface on which packets will be
captured, the conditions for capturing packets, and the disposition of the captured results. When tcpdump
finishes capturing packets, it will report counts of:
• Packets captured - the number of packets tcpdwnp received and processed
• Packets received by fIlter - the meaning depends on the OS on which tcpdump is running
• Packets dropped by kernel - the number of packets that were dropped due to insufficient buffer
space
tcpdump options
The table below summarizes a few of the options that can be specified on the tcpdump command:
Option Type Meaning

-i [interface] Switch Specifies the interface or VLAN to listen on (cap!ure packets on). If
omitted , the first interface - often eth(O) - is assumed.
-e Switch Print the Ink-level header (MAC address) on each dump line.
-n Switch Disables name resolution so that IP addresses and ports are
printed as numbers only (not translated). Increases tcpdump
performance Significantly when specijied.
-X Switch Prints each packet (minus its link level header) in hex with ASCII
translations included and is handy for analyzing new protocols.
-r [file] Switch Reads packets from a file created earlier by executing tcpdump
witm the -w option.
-w [file] Switch Causes the tcpdump output to be written to the file specified (rather
than printing to the command line screen) in tibpcap format (.pcap)
which can be read by many analyzers such as WireShark
-----

Option Type Meaning

-c [count] Switch Stops the tcpdump command after count packets are processed . If
this option is not specified, the tcpdump command will continue until
it is cancelled using the <Ctrl-C> command .
-s [snaplen] Switch Capture snaplen bytes of data from each packet rather than the
default of 70 bytes. Packets trun ca ted because of a limited
snapshot are indicated in the output with [proto], where proto is
the name of the protocol level at which the truncation occurred.
Specifying this option reduces the amount of time it takes to
process traffic and increases the amount of packet buffering,
causing fewer packets to be lost. You should limit snaplen to the
smallest number that will capture the protocol information you're
interested in.
host [IP address] Filter Captures packets only when the source address or destination
address is IP address .
port [service] Filter Captures packets only when the source port or destination port is
port.
protocol Filter Captures packets only when they are protocol packets (e.g. icrnp,
udp, arp, tcp , etc. )
and lor I not Boolean Use to form Boolean expressions that chain together filters (e.g.
expression host 172.16.1.100 and port 80). If no expression is given, all
connectors packets on the named interface will be dumped . Otherwise, only
packets for which the expression is true will be dumped.
tcpdump examples
• On the BIG-IP VLAN na med internal, capture and print the next 100 packets that contain the
source/dest ination IP address:port 172.16.20.1 :80.
tcpdump - i internal h os t 172.16.20.1 and port 80 - c 100
o
o
H2.:1.6.20.LBO
:1.72..16.20.2,80
172.:1.6.20.3,80
• On the BlG-lP VLAN na med internal, capture the next 10 packets that are ARPs.
tcpdump - i internal arp -c 10
Administering BIG- IP v11 9-17

Three-Way Handshake Example
0 -1
SYN
- ...
• _ _ _ _ _ SYNjACK
ACK SyN - _ _....
....- - - SyNjACK
ACK _ _ _ +
Figvre 10: Throe way handshake on cllenr-side and server-side
All TCP connections are initiated with a three-way handshake. The synchronize flag (SYN) is set in the
first and second packet; the acknowledgement flag (ACK) is set in the second and third packet, as
illustrated in the client-server connection shown in Figure 10. ACK is also set on all subsequent packe ts.
Within the tcpdump output, SYN fl ags are shown with the single letter "S"; ACK flags are shown with
the string "ack". While ACK flags are sent in most every TCP packet, SYN flags are only sent only
during connection initiation.
In the example below, the packets exchanged during TCP connection initiation between BIG-JP (at IP
address 172. 16. 16.3 1) and a n appl ication service at JP address :port combination 172. 16.20. I :80 are
captured and shown in the tcpdump output below . Name resolution was suppressed using the -n option.
Example tcpdump command

t cpd ump -i inter nal - n hos t 1 72. 1 6.20. 1 and port 80
Example tcpdump output

09:48:00.7811 7 1 1 72 .16. 17 .31.39280 > 172.1 6 .2 0.1.80: S 480360735:48036073 5( 0)
win 16384 <mss 1460, nop, wscale o,nop,nop,time st a mp[ltcp» (OF)
09:48:00.781288 1 72. 16.20.1.80 > 172.16 .l7 .3 1 . 39280 : S
5 493 55377:549355377(0 ) ack 480360736 wi n 175 20 <mss l 46 0 ,nop, wscale
O,nop,nop,timestamp[ltcp» (OF)
0 9 :18:00.781359 172 . 16 . l7 _31.39280 > 172 . 16 .2 0 . 1 . 80 : . ack 1 win 17 520
<nop,nop,ti me st amp 1161959 35520 75 > (D F)
The SYN (S) and ACK (ack) flags are highlighted and underlined in bold above.

Content Monitor Communications Example

A BIG-lP health monitor assigned to a node will periodically open service check connections between
BIG-I? and the monitored node. Once the service check is completed (or times out), the connection is
closed. In the next example, multiple service check connections are shown in the tcpdump output. Notice
the sender indicates it is done sending data by setting a TCP FIN flag, which displays as the letter "F."
Example tcpdump command

tcpdump -i internal -n host 172.16.20.1 and port 80
Example tcpdump output

09:50:32.811118 172.16.17.31.39613 > 172.16.20.1.00, S 444272268:444272268(0)
win 16384 <mss 1460,TIop,wscale O,noPlnop,timestamp [ lt~p]> (OF)
09:50,32.811383 172.16.20.1.80 > 172.16.17.31.39613: S
1938541816:1938541816(0) ack 444272269 win 17520 <mss 1460,nop,wscale
0, nop, nop, timestamp [ I tcpl ;:--(OF)
09:50:32.811430 172.16.17.31.39613 > 172.16.20.1.80: ack 1 win 17520
<nop,nop,timestamp 1162263 355237 9 > (DF)
09:50:32.811759 172.16.17.3 1 .396 1 3 > 172.16.20.1.80: P 1 :8(7) ack 1 win 17520
<TIOp/TIop,timestamp 1162263 3552379> (DF)
09: 50: 32.844 5 89 172. 16 .20.1.80 > 172.16.17.31.396 1 3: 1:1449(1448) ack 8 win
17520 <nop,nop , timestamp 3 552379 1162263> (DF)
09:50:32.844714 172.16 . 17.31.39613 > 172.16.20.1.80: ack 1449 win 16072
<nop,nop,timestamp 11 622 63 3552379> (DF)
09:50:32.844851 172.16.17.31.396 1 3 > 172.16.20.1.80: F 8:8(0) ack 1449 win
16072 <TIOp/nop,timestamp 1162263 3552379> (DF)
09:50:32.845692 172.16.20.1.00 > 172.16.1 7 .31.39613: 1449:2897( 1 448) ack 8
win 17520 <nop,TIop,timestamp 3552379 1162263> (DF)
09:50:37.757819 172.16.17.31.39621 > 172.16.20.1.80, S 454708950:4 5 4708950(0)
win 16384 <mss 1460,nop,wscale o, nop,nop,timestamp[lt~p » (DF)
09:50:37.758031 172.16.20.1.80 > 172.16.17.31.39621: S
1348034315:1348034315(0) ack 454708951 win 17520 <mss 1460,nop,wscale
0, nap, nap, t j mestamp [ I tcp l ;----(DF)
09:50:37.758104 172.16.17.31.39621 > 172.16.20.1.80: ack 1 wi n 17520
<nop,nop,time stamp 1162273 3552389> (DF)
09:50:37.758489 172.16.17.31.39621 > 172.16.20.1.80: P 1:8(7 ) ack 1 win 17520
<nop,nop,timestamp 1162273 3552389> (DF)
09:50:37.794705 172.16.20.1.80 > 172.1 6 .17.31.3 9 621: ack 8 win 17513
<nop,nop , t ime stamp 355 2 3 8 9 11 6 2273>
(OF)
09: 5 0: 3 7. 8 0 4 367 172.16.20.1.80 > 1 72 .16.17.31.39 62 1, 1:144 9( 1448) ack 8 win
17520 <nop,nop,timestamp 3552389 1162273> (DF)
09:50:37.804453 172.16.17.31.39621 > 172.16.20.1.80: ack 1449 win 16072
<nop,nop,t i mestamp 1162273 3552389> (DF)
09:50:37.804605 172.16.17.31.39621 > 172.16.20.1.80: F 8:8(0) ack 1449 win
16072 <nop,nop, timestamp 1 162273 3552389> (DF)

Example analysis
T he timestamps show the two connections occur approximately fi ve (5) seconds apart, at 9:50 :32 a nd
9:50:37 res pecti vely. Notice that the port used by BIG -lP inc reased with each connectio n - fro m 396 13 to
3962 1. Normally, port is increased by o ne with each connectio n. In tbis case, the jump of 8 indicates otber
connections happened that were n' t captured in the tcpdump. T he tcpdump shows both connection
establishment (S - Slack - ack) a nd connection completion (F).
Virtual Server Communications Example

To view compete virtual server communications between the client and the application service, two
tcpd ump commands can be run concurrentl y. You can ru n tbe two tcpdumps in two separate SSH session
wi ndows to the BIG-IP system.
Virtual server 1.72.1.6.20.i:80

1010-.lHOO80
1.72.1.6.20.2 :80
1.0.1.0.1.7.25
1.72.1.6.20.3 :80
In the examp le below, HTTP traffic originates from a client at IP address 10.10.17.25 to a virtual server
on BIG-IP with IP address:port combination ID.I 0.17.1 00:80 . tcpdump outpu t fo r this traffic is sh own in
Example Icpdump oulpul: window I .
BIG -lP load balanced the request to pool member 172. 16.20 .1: 80. tc pdump oulpul for tbis traffic is
shown in Example Icpdump 0 1.11: window 2.
Example tcpdump commands

Window I : t cpdump - i external -n host 10. 1 0. 1 7 .25 and po rt 80
Window 2 : t c pdump - i i nter nal -n host 10 .1 0. 1 7 . 2 5 and po rt 80
Example tcpdump output: window 1

12: 0 3:59 . 2 1 852 0 10.10 . 1 7.2 5. 12 8 7 > 10.10 . 17.100.80: S 1 9 6 0 8 494:1 96 08494 ( 0 )
win 8 1 92 <TnS S 1460 , na p, nap, sa c k OK> (DF )
12:03:59 .21877 5 10. 1 0.1 7 . 1 00.80 > 1 0. 1 0. 1 7.2 5 . 1 28 7: S

40 363 4010 2 : 4 03 6 3 4 010 2 (0 ) a c k 1 9608495 wi n 1 75 20 <mss 1 4 6 0 > (OF )
1 2 :0 3 : 59 . 2 1 9598 10 . 10.1 7.25. 12 8 7 > 1 0 .1 0. 1 7 .100.80: ack 1 wi n 87 6 0 (OF )
12 :0 3 : 59 . 22 0 5 44 1 0 . 10.1 7 . 25 . 128 7 > 10 . 10 . 17.100.80 : P 1: 2 79( 27 8 ) ack 1 win
8 76 0 (O S )
12 :0 3 : 5 9. 22 1 89 1 1 0. 1 0.1 7 . 100.80 > 10. 1 0. 17 . 25.128 7 : P 1: 172 (171 ) ack 2 7 9 wi n
1 752 0 (O F)
9-20 Adm in iste ring BIG-IP v11

12:03 : 59 . 22 1980 10.10.1 7 .1 00 . 80 > 10.10.1 7 . 2 5.1 287: F 1 7 2 : 1 72(0) a ck 279 win
1 7520 ( OF )
1 2:03 : 59.2225 71 1 0 . 10.17.25.1287 > 10.10.1 7 .1 00 . 80: ac k 17 3 wi n 8589 (OF)
1 2:03:59.223080 1 0 .1 0. 17.25. 1 287 > 1 0 . 10 . 17 .1 00.80: F 279 : 279(0) ack 1 73 win
8 5 89 (OF)
1 2:03: 5 9.223252 1 0. 1 0. 1 7. 1 00.80 > 1 0. 1 0. 1 7.2 5 . 1 287: ac k 280 wi n 17520 (O F )
Example tcpdump output: window 2

1 2:03:59.218600 10 .1 0. 1 7.25. 1 287 > 1 72 . 16 . 20 .1 .80: S 1 9608494:1 9608494(0) win
8 1 92 <mss 1 4 6 0,nop, nop ,sackOK> (OF)
12:03 : ~9 . 21 8749 1 7 2.1 6.20 .1 .80 > 10.10.]7.25.1 287: S 40363 40102:40 36340 1 02(0)
ack 1 9608495 win 1 7 520 <mss 1460> (DF)
1 2:03:59 . 2196 19 1 0 . 10 .1 7 . 25.1287 > 17 2.1 6 . 20 .1 .80: ack 1 win 87 60 (DF)
1 2:03:59.22056 4 1 0 .1 0.17.2 5 . 1 287 > 1 72 .1 6 . 20.1 . 80: P 1: 279(27 8 ) ack 1 win
8760 (O F )
1 2:03:59.22 1 874 1 72 .1 6.20. 1 .80 > 1 0 .1 0 .1 7 . 2 5.1 287: P 1: 172( 171 ) ack 279 win
1 7520 (OF )
12:03:59 . 221965 1 72 . 16.20. 1 .80 > 10 . 10 .1 7 . 2 5.1 287 : F 1 72: 172 (0) a ck 279 win
1 7520 (OF)
1 2:03:59 . 22 259 2 10. 10 .1 7.25. 1 287 > 172.16. 20 .1 .80: ack 1 7 3 wi n 8 589 (O F )
1 2:03 : 59 . 223 100 10.1 0 .1 7.25. 12 8 7 > 172.16. 2 0.1. 80: F 279 :27 9 (0) a c k 1 73 win
8589 (DF)
12:03 : 59.2232 20 1 7 2.1 6 . 20. 1 .80 > 10 .1 0 .1 7.25.1287: ack 280 wi n 17 5 2 0 (D F )
Example analysis
The timestamps help relate the packets io the two traces to one another. You can see the address
ITanslat ions BIG-lP performs.
On inbouod ITaffi c (from cl ient to we b applicati on service):
• The client address (1 0. 10.17.25) is the source address in both the client-side and server-side
packets.
• The virtual server address (10.10. 17. 100) is the destination address 00 the client-side packets; the
node address (1 72.16.20.1) is the destination address in the server-side packets.
On outbound traffic (from web application service to client):
• The c lient address ( 10.10. 17.25) is the destination address in both the client-side and server-side
packets.
• The node address (172. 16.20. 1) is the source address in the server-s ide packets; the virtual server
address (10.10.1 7 . lOO) is the source address in the cl ient-side packets.

Saving tcpdump Output to a File

There are two methods that can be used to save tcpdump output to a fil e. The first simply redirects the
output from the standard destination (the command line) to a file with the same fonnat as the command
line display (i .e. straight text output). In the example below, 800 packets that are either sent from or
recei ved by the service with lP address: port combination 10. J0. 10.30:80 are written to the named file:
t c pdump h o st 10. 10. 1 0.30 a nd p o rt 80 > myt c p d ump
F5 Tecnnical Support recommends saving tcpdump output in a compressed file format which can th en be
read by other troubl eshooting tool s such as EtherReal or Wireshark:
tcpdump host 10.10.10.3 0 and port 80 -w myt c p dump
Running tcpdump from the

--
You can also run tcpdump from the
Configuration utility. On the System .. Support
page (same page as for creating qkview files),
click the TCP Dump checkbox to view TCP 0"'-
Dump Conliguration option s, as shown in n::P Dump
Figure 11.
F5 recommends running tcpdump from the

command line rather than the Configuration
utility due to performance considerations.
Task usl
On this screen, you can configure and ru n the
tcpdump utility to collect configuration and
diagnostic utilities from BIG-IP and Enterpri se
Manager systems. Unlike using tcpdump in th e
command line en vironment, all tcpdumps created
o::r:J minutes
from the Configuration utility are written to files
that can then be analyzed with tools like
Wireshark, or provided to F5 Technical Support
Figure 11: Running tcpdump from the Configuration utility
to aid in troubleshooting an open case.
The table below summarizes th e tcpdump configuration options available on the Configuration utility:
_....__.__ .. _-_._ - - - - - -
Configuration Option Description
VlAN SpeCifies the target VLAN on which the utility runs.
Packets Specifies the maximum number of packets to capture. The default is Unlimited .
Options Specifies the additional options to set on the tcpdump command. These are the
same options that you might use on the command line version of tcpdump.
Type a value in the Options box, and click the Add button to add it to the list.
Timeout Specifies, in minutes, how long the Tep dump utility captures packets . The
maximum length of time you can run the utility from the GUI is 5 minutes. The
default setting is 1 minute .

BIG-lP creates a snapshot file which can tben be downloaded to your workstation by clicking the
Download Snapshot File button.
For more information on running tcpdump on a BIG-IP system, please refer to :
SOL6546: Recommended methods and limitations for running tcpdump on a BIG-IP system
SOL 411 : Overview of packet tracing with the tcpdump utility
S0L7227: Using tcpdump to view traffic on a tagged VLAN
SOL 13639: Capturing internal TMM information with tcpdump

Lab 9.1 - Remote Syslog Lab
Objectives:
• Configure B1G-lP to send log messages to a remote log server.
Lab Requirements:
• tcpdu mp to view message transmission. Since log messages are sent using UDP, there is no
connection process; the data will be transmitted on the wire in clear text.
• A virtual server defined on the instructor BIG-IP system with destination lP address
10. 10.17.99:514 with an iRuie configured to drop all traffic.
Configure a Remote Syslog Server and Capture Log

Message Traffic using tcpdump
Configure a remote syslog server
I . Add a remote server using a virtual server on the instructor's BIG-IP system as the syslog server.
Cboose to use EITH ER tbe Configuration utility (a) OR tmsh (b) to carry out tbis step.
a . Use the Configuration utility to configure remote logging ..
Properties section
When complete. click . ..
b. ...OR open a second SSH session to your BIG-IP system and use tmsh to configure
remote logging. Confirm your setup afterward. For example:
(tmos sys)# modify syslog remote-servers add {mylog{hos t lO.10.17.99}}
(cmos sys)# list syslog remote-servers
Set up tcpdump
2. Open an SS H session to your BIG-IP sys tem and set up a tcpdump to capture log messages sent
to 10.10.17.99 via UDP and port 514 on VLAN external. The captured traffic wi ll be saved to a
fil e in the I var / tmp/ te st directory on the BIG-IP system.
con1 i9~ tcpdump -ni external -Xs 0 udp and host 10.1 0.17.99 and po rt 514 - w
! var /t mp /t est / trainX_ re mote_ sys l og

Generate local traffic log messages

3. Generate some local traffic log messages by deliberately modifying the monitor on pool
http-pool in such a way that the monitor health test will fail, and tbe pool members will all be
marked as unavailable. (If you don't remember how to do this, refer back to the labs in the
chapter on monitors earlier in this course.) Wait for the pool member's status to change before
proceeding with the next step.
4. Generate more local traffic log messages by resetting the monitor on pool http-pool such that the
monitor health test will succeed again for all pool members.
Stop the tcpdump and view the resulting file using Wires hark
5. Stop the tcpdump on your SSH session to the BIG-IP system by pressing <Ctrl-C>.
6. Open a WinSCP session to your BIG-IP system using the following specifications:
a. File protocol: SFTP
b. Host name: J92.168X.31
c. Port number: 22
d. User name: root
e. Password: rootX
7. When the WinSCP window opens, elick on the file folder for the /<rool> directory. (It should be
at the top of the list of directories.) Navigate to the /var/tmp/test directory and drag the icon tor
file trainXJemote_syslog from your BIG-IP system to your workstation desktop.
8. Close the WinSCP window.
9. Start the Wireshark application on your workstation, and open file trainXJemote_syslog on
your desktop. You should see many log messages captured by your tcpdump.
10. Set up a filter to view only BIG-IP local traffic messages (LOCALO facility). If you're not
familiar with Wireshark, instructions are provided below:
a. Click the Expression link to the right of the Filter: field at the top left of the Wireshark
screen.
b. In the Field name pane, scroll down to Syslog - Syslog message and click the plus-sign
(+) to the left of the entry.
c. Select syslog.facility - Facility (Message facility) in the Field name pane.
d. Select "= =" in the Relation pane.
e. In the Predefined values: pane, scroll down and select LOCALO - reserved for local
use.
f. Click the OK button to generate the filter. You should see the string syslog.facility = =
16 in the Filter: field. If the string does not appear correctly, you can type it into the
Filter: field manually.
g. Click the Apply button to apply the filter to the log messages. Review the resulting
filtered messages list to see what was generated.


You should see several log messages relating to local traffic events, including:
• The start of your tcpdump command
• The pool members status changing to down/up
• SNMP_TRAP messages when your virtual servers became unavailable/available as the result of
the changes in pool member status.
If you did not capture any local traffic log messages (LOCALO), make sure your monitor check changes
did result in all pool members being marked down/up. You may need to wait a few seconds between
making the monitor mark the members up and terminating your tcpdump command to ensure that any
buffered log messages are actually transmitted.
If you did not capture any log messages at all, check your tcpdump command to ensure that it is specified
correctly.
Clean-up at end of lab

11. Delete 10.10.17.99:514 from the remote syslog server list using either the Configuration utility or
trnsh.
a. Use the Configuration utility to delete 10.10.17.99:514 as a remote syslog server..
System » Lo gs " Configuration » Remote Logging
.. ..; I ;.; .; I.
I Remote Syslog Server List
When complete. click ..• ...

Select 10.10.17.99:514 and click the Delete
button
.
b. ...OR open a second SSH session to your BIG-lP system and use tmsh to remove
10.10.17.99:514 as a remote syslog server. Confirm the deletion afterward. For example:
(tmos.sys)# modify syslog remote-servers none
(tmos.sys)# list syslog remote-servers
Continue with Lab 9.2 SNMP Trap Lab

_Lab 9.2 - SNMP Trap Lab

Objectives:
• Configure the BIG-IP system to send traps to an SNMP management console and view trap
messages using tcpdump
Lab Requirements:
• Although there is no SNMP management console in the classroom, tcpdump can be used to view
tbe output fro m the SNMP trap.
Configure Traps
Configure a destination for traps
I . Configure a destination for traps triggered on BIG-IP. Choose to use EITHER the
Configuration utility (a) OR tmsh (b) to cany out this step.
a. Use the Configuration utility to set up a trap destination ...
Record Properties section
b. ... OR use tmsh to set up a trap destination and display the results, tben quit tmsh.
(Substitute your station number for "X" in both locations.) For example:
(t mo s)# modif y / sys s nmp vl -traps add { tsX {host lO.lO.X.30
commun ity Public} }
(I moa)U li st / sys s nmp

Prepare to view trap messages

2. Use an existing or open a new SSH session to the BIG-IP system, and log in as root.
3. Start tcpdump to capture your trap traffic.
confi gN tcpdump -ni external -Xs 200 udp and host lO.10.X.30 and port 162
Cause traps to be triggered

4. Change the receive string of the my_http monitor such that it marks all the pool members in
http-"001 down again.
Q. Did trap messages appear immediately in your tcpdump output? Why or
why not?
s. On your tepdump window, press the <Enter> key several times to insert some space between the
previous set oftrap messages and any new ones that are generated.
6. Change the receive string of the my_http monitor again such that it marks all the pool members
in http-"ool up again.
Q. Did trap messages appear immediately in your tcpdump output? Why or
why not?
7. Stop your tcpdump by pressing <Ctrl-C> on your SSH session window with BIG-IP.
8. Go look at the SNMP alerts that are pre-configured on BIG-IP.
cO D f ig~ l ess /etc/alertd/alert.conf
Optional tcpdump Lab Steps

Use the tcpdump command to examine BIG-IP local traffic:
9. Capture the traffic between BIG-IP and the pool member 172.16.20.2:80. Once you start the
tcpdump, open a session with http://I0.I0.X.I00 and refresh the screen a few times. How
frequently does the TCP connection (synlsyn-acklack) appear in your tcpdump output? Is the
TCP connection process apparent?
10. Capture the traffic between your PC and BIG-IP on port 22 (SSH). Limit the number of packets
that are captured. Did your tcpdump output show a connection process?


As with the remote syslog server lab, when you configured the my_http monitor such that the health
check would fail for all pool members, you had to wait for the period defined by the monitor's timeout
value before the log messages are generated that trigger tbe SNMP trap messages. However, when you
reset my_http to allow for a successful test to all pool members, as soon as the BIG-JP system receives a
successful test response, he marks the pool member available. As statuses change, a series of local traffic
log messages are written tbat, in tum, trigger more SNMP trap messages.
Depending on how far down in the alert.conf file you scrolled, you mayor may not have come across the
SNMP traps that relate to an LTM virtual server becoming unavailable or available.
Clean-up at end of lab

11. Delete the SNMP trap destination J O. \oA.30 you created at the start of this lab. You can use
either the GU! (System» SNMP : Traps: Destination) or trnsb:
tmsh modify (sys snmp vl-traps delete { tsX }
Continue with Lab 9.3 High Speed Logging Lab

Lab 9.3 - High Speed Logging Lab
Objectives:
• Configure BIG-IP to filter and send certain log messages to a remote high-speed logging pool.
Lab Requirements:
• tcpdump to view message transmission.
Clean-up from SNMP Trap Lab

l. If you did not do so already at the end of the previous lab, remove your workstation as a
destination for SNMP traps. Using the Configuration utility, navigate to System» SNMP :
Traps: Destination and delete the entry you created earlier for 10.1 0.X.30: 162.
Test Legacy Syslog Behavior

2. Use the Configuration utility or the command line to set the state for pool member 172.16.20.1 :80
in pool http_pool to Forced Orfline .
3. View the syslog messages that were generated. You can use the Configuration utility at System »
Logs: Local Traffic or the command line - tail -f / var /1og/1 tm.lfusing the
Configuration utility, ensure the log messages are sorted in descending timestamp sequence (i.e.
newest first) by clicking on tbe Timestamp column header. Using either message, you should see
three messages that relate to the forced offline operation in the previous step. The messages
should look similar to these:
Log lewt SenAe. Slotus coo. Eve'"

Thu Oct 31 14 :03 :09 PDT 2013 notice blglp4 mcpd[5B2B] 01070638 Poot /Commonlhttpyool member
ICommonl172.16.20.1 :60 manNer status
forced down. [/Common/my_http: up 1{
was up for Ohr:1min:23sec]
Thu Ocl31 14:03:09 PDT 2013 nolice biglp4 mcpd[5B2B] 01070639 Pool /CommorvtlHpyool member
/Commonl1'72.16.20.1 :60 session status
forced disabled.
Thu Oct 31 14:03 :09 PDT 2013 notice bigip4 mcpd[5B2B] 01070807 Monitor lCommon/my-hHp inslance
172.16.20.1:80 has been dIsabled.

Note that the log messages were produced by a BIG-IP service called mcpd, and each has a severity level
of notice. Also note the Status Code (message ill) for the second message - 01070639. We will use this
infonnation in the next section to create a high-speed logging filter that specifically causes these
messages to be directed to a high-speed logging publisher rather than to the local logs.
4. Set the state for pool member 172.16.20.1:80 in pool http_poolbackto Enabled. View the Local
Traffic log again for new messages - there should be several indicating the status change for the
pool member and its associated monitor instance.
Configure High-Speed Logging

Create a pool with one remote logging server
Note: Although you would probably not do this in a real world situation, in this lab you can use
your PC as a destination for high-speed logging messages, then use tcpdump to view those
messages as they are transmitted across the network from the BIG-IP system to your PC.
5. Using either the Configuration utility or tmsh, create a new pool using the following
specifications:
Name Member(s) Load Balancing"'---_ _ __

""---
hsLpool 10.10.X.30:514 Default
Create a remote high-speed logging destination

6. Create a log destination called bsLdestination to point to hslyool created in the previous step.
Pool ~tlnt'I" section

Create a publisher
7. Create a publisher called hslyublisher where the BIG-IP system will send log messages for
specific resources.
General Properties sedlon
Log Destinations section

Move hSI_destination from the Available column
Destinations
to the Selected column
Create a logging filter

8. Create a logging filter calJed hsl_mcpd_notice_fIIter that will send all notice severity level
messages from the BIG-IP mcpd service to hslyublisher.
When complete, cIlck...
Start tcpdump to view port 514 traffic from BIG-IP to your PC

9. Open a new PuTTY session to IO. IO.X.3 1:22, login as root, and at the bash prompt, enter tbe
following command to start tcpdump.
c o n( ig# tc pdump -ni externa l - Xs 0 udp and hos t l O. lO. X.30 and port 5 14

Generate notice-level messages from the mcpd service

10. Generate log messages by using the Configuration utility to set the state for pool member
172.16.20.1:80 in pool http_pool to Forced Oilline.
II. View your tcpdump output. You should see the same three log messages that you observed
previously in the Local Traffic log, as captured by tcpdump as they were transmitted to our
pretend high-speed logging server pool.
12. Use the Configuration utility to view the Local Traffic log at System» Logs: Local Traffic, and
notice that the messages that were sent to the remote HSL server are not present in the local log,
but other messages that did not match your HSL filter criteria are. For example, you may see
messages about your tcpdump command statting and/or stopping.
13. Enable pool member 172.16.20.1:80 in pool httpyoolagain,andusetcpdump to confirm that
you see another series of log records transmitted to your "pretend" high-speed logging server.
Change the mcpd notice-level filter

14. Change the hsl_mcpd_notice_filter to send only log messages with JD 01070639 to our pretend
high-speed log server.
15. Force pool member 172.16.20.1:80 in pool httpyooloillineagainandconfirm the change in

behavior with respect to which message(s) are send to the HSL server and which message(s) are
recorded in the Local Traffic log.
Add a formatted destination and view change in log message format

16. Add a formatted destination called hsl_splunk_destination.
17. Change publisher hslyublisher to point to hSI_splunk_destination rather than hSI_destination.

18. Enable pool member 172.16.20.1:80 in pool httpyoolagain,and view your tcpdump output to
see how the fonnat of the log message has changed from previous iterations.
Admmistering BIG-IP v11 9-33


When you set up the high-speed logging filter for notice level messages generated by the mcpd service,
all messages that matched that filter were sent to the remove high-speed logging destination, as defined
by the associated publisher for the filter. All log messages that did not match an HSL filter were directed
to local syslog processing functions. Later, when you changed the filter criteria to be more specific, only
log messages with ill number 01070639 were sent to the HSL destination; the others were sent to the
local logs as they did not match any HSL filter criteria.
Initially, the HSL publisher was unformatted. Later, you introduced a Splunk formatter to sit in-between
the publisher and the unformatted destination. The purpose of the Spiunk formatter destination was to
simply format the log messages differently.
Clean-up
19. Effectively disable high-speed logging by deleting Log Filter hsl_ mcpd _notice _filter. Force
pool member 172.16.20.1:80 in pool httpJ)ool omine and then enable it again. Use either the
Configuration utility or the command line to confirm that log messages that were being filtered
for HSL are now being sent to the local log files again.
STOP

Leveraging the BIG-IP iHealth System
Lesson Objectives
At the end of this lesson, yo u should be able to:
• Generate a qkvi ew diagnostic file and upload it to
Overview of BIG-IP iHealth

B1G-IP iHealth is a tool hosted by F5-hosted on the web at bttps:llihealth.fS.com. It is not a feature or
tool tbat is part of the BIG-lP system . BIG-IF iHeaIth enables you to verify the proper operation of your
BIG-LP system and ensure your hardware and software are functioning at peak effici ency.
The technology at the beart of BIG-I P iHea lth is the qkview file, which provides a running snapshot of
your BIG-IF system with up-to-the-minute configuration and diagnostic infonnation . You caD quickly
download a qkview fil e from your BIG-IF system, and then upload the file to the BIG-IP iHealth system.
(We'll cover more about the qkview file later in this chapter.)
The BIG-IP iHealth system essenti ally translates the raw information pulled from your qkview file and
presents your system data in an easy-to-read format for fast access (see Figure 12) .
:;,..::.v~w case number te-5.i support file far g2 r "''''f-'Jhr·r -, .lIt' • - II! .:. ....... ,'e' ~ I . V} ·e
..... QK'/te'N LLs! - - -

t IOS'~'1me t j'[! ,-; fI I rr I L.I. H"TI _'I." J) _ ..:'rl~" l. "XI
I Slalus Status
Diagnostics
Overview
Results ! 3 Medium
Hardware
Recommendation
Software Status .", No new potential Issues Identified since last update.
links ~ Pnnter.Friend ly (I nc lude Internal) II PDF Include Intern
Failover
licenSing File
Upload Date Nov 19 2013, 07 ' 11 '00 PM (GMT)
Uploaded By
~ Network

F5 Case (none] '"
Command. Non-F5 Case Inone]
Graph. System
~ Diagnoatic.5 Hoslname bigip4 .f51rn.com

Time Zone AmeriCa/Los_Angeles
Filu ChaSSIS S iN 3275792
Blade SIN [No data available]
Status FAILOVER active for about 1 day, 1 hour
Uptime 1 day. 1 hour
Figure 12: Sample BIG·/P iHealth screen from a qkview diagnostics file
Ln addition to translating the raw data, the BIG-IP iHealtb Diagnostics component ortbe BIG-IF iHealth
system evaluates the logs, command output, and configuration of your BIG-I P system against a database
of known issues, common mi stakes, and published F5 best practices. The prioritized results provide

tailored feedback abou t configuration issues or code defects, and provide a description of the issue,
recommendations for resolution, and a link to further information in the AskFSTM Knowledge Base.
BIG-IP iHealth Diagnostics take advantage of the technical knowledge of experienced F5 engineers to
assist you in implementing the best practices for your system. Using advanced diagnostics, iHealth can
determine when your system is operating outside of normal levels so you can take the necessary steps to
improve performance. BIG-JP iHealth Diagnostics also check for security issues and recommend patches
or software updates. F5 recommends upload a qkview file to the BIG-JP iHealth system at least once a
month, since F5 updates the BIG-IP iHealth known issues and best practices on a weekJy basis.
The prioritized results provide tailored feedback about configuration issues or code defects, and provide a
description of the issue, recommendations for resolution, and a link to further information in the AskFSTM
Knowledge Base.
This customized diagnostic information enables you to take the recommended action, and in many cases,
can help you resolve common configuration issues without the need to contact F5 Technical Support. If
you require assistance from F5 Technical Support, your BIG-IP iHealth data will be available to F5
engineers for faster resolution.
Introducing the qkview Utility

In order to use BIG-IP iHealth, a qkview file needs to be created and uploaded to the BIG-IP iHealth
system. You can do this either manually or automatically:
• ManuaUy - You can download a qkview file from your BIG-IP or Enterprise Manager system,
and then upload the file to the BIG-JP iHeallh system.
• Automatically - BIG-IP iHealtb was integrated with the Enterprise Manager system starting with
version 3.0.0. You can configure the Enterprise Manager system to automatically create and
upload qkview files (from BIG-IP and Enterprise Manager devices) to BIG-IP iHealth, and then
view the diagnostics of all your managed devices on a single screen.
F5 recommends that generate a qkview file and run iHealth diagnostics once a month to
determine if your system is operating within normal levels, is properly configured, and to check
for security issues and recommended hotfixes.
You can use either the Configuration utility or the command line (tmsh) to run the qkview utility. The
qkview utility runs a large number of commands when collecting information. This behavior may cause
aD additional performance burden on systems that are already heavily loaded. If possible, run the qkview
utility at non-peak bours or during a regular BIG-IP maintenance window.

Running qkview from the Configuration utility

To run the qkview utility from the Configuration utility, navigate to System» Support, and in the
Support Snapshot area, click the qkview checkbox and tbe Start button, as shown in Figure 13.
Support Snapshot
QKVJew
TCP Dump
Figure 13: Running the qkview utility from the Co nfig uration utility
While the qkview utility is processing, a clock will appear. You may cancel the qkview utility by clicking
tbe Cancel button. (See Figure 14.)
Support Snapshot
~ot Fjj_ _· _ _ _ _ _..1_0_ p_roc,,

_ _ _ _si_nq...
__ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _-1
! Cancel I
Figure 14: Screen shot while the qkview utility is processing
When the qkview utility completes, you have the option of either downloading or deleting the qkview
diagnostic file that was produced by the utility, as shown in Figure 15. To download the file to your
workstation, click the Download Snapshot File button.
Support Snapshot
Dale 1 Thu Sop 2715:35:12 PDT 2012 I'
Size 3 1491343 b!1es
5napshOI ...:..:
F~.______....:J)::'ownI""d::::::
=== S/1a.P::::OFi : ::...-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _J "
's!I::l::io]
~
Figure 15: qkview utility support snapshot screen
The downloaded file is a single compressed tar folder and will be named something like:
case~number_### support flle.tar
Administering BIG-I P vii 9-37

If you already have an open case number, you can rename Ihe .Iar file, substinning Ihe case number for
Ihe hash marks (1##1) in tbe file name, before uploading 10 iHealth.
Note: For more information on the iHealth system, please refer to the BIG-IP iHealth tutorial
available as a link from the BIG-IP iHealth website at ihealth.f5.com .
Uploading the qkview file to BIG-IP iHealth

After you have downloaded the qkview file to your workstation, you can upload tbe file to BIG-IP iHealth
to diagnose the health and proper operation of your BIG-IP system. Open a web browser and navigate
to bttps;iiibealtb.f5.com.
Note: You must have a valid F5 support contract and be registered at https:iilogin .f5.com in
order to use BIG-IP iHealth.
At the login screen, enter your user email and password, and then press LOGIN to continue to BIG-IP
iHealth. On the initial BIG-IP iHealtb page, click the Upload button to begin the upload process, as
shown in Figure J 6.
f5 BIG·IP (Health
I
FIgure 16: SAMPLE ihealth qkview upload and My qkview lists
Navigate to the qkview file you want to upload. If you have an open support case witb F5, you may add
your case number to the F5 Case field. You may also add your own identifier to the External Case field
for tracking purposes. Click the Upload button to upload the file. Once the upload has completed , BIG-lP
iHealth processes the file. This may take several minutes after which the BlG-lP iHealth viewer will
automatically display tbe results of its analysis.
Note : You can upload as many files to iHealth as you would like - one at a time - but qkview
files are only retained on iHealth for 30 days.

My OKViews and Shared OKViews lists

The Upload page also contains a list of already-uploaded files in the My QKViews area, as shown in
Figure 16. You can also navigate directly to this list from anywhere within the iHealth system by clicking
the My QKViews link at the top of the page.
Open a qkview file from the list by clicking on the file's name in the Hostname column. A plus sign (+)
will appear to the left of the Hostname, if the qkview was taken on the primary blade of a BIG-IP chassis.
Click on the plus sign to reveal qkview links for each blade on the chassis. You can also access the blade
specific qkview results from the Overview page that appears after you select the primary blade qkview.
FS Network Support Engineers can share qkview files with your BlG-lP iHealth account. Files that have
been shared will appear in separate area labeled Shared QKViews (not shown).
If the list of qkview files is large, you can sort the list using the blue up and down arrows in the column
headings at the top of each Jist (e.g. Hostname, Version, Generation Date, Upload Date), as shown in
Figure 16.
Adding comments to a qkview entry

You can add comments to a file entry in the My qkview or Shared qkview lists by clicking the plus sign
(+) that appears between the file's Hostname and Generation date, as shown in Figure 6. This brings up
the Comment Editor pop-up where both you and FS Technical Support can keep a running commentary
on the file analysis.
Removing a qkview file

Per FS's data retention policy, the BlG-IP iHealth system will automatically delete a qkview file for
closed cases one month after upload. You can optionally delete one or more uploaded qkview files at any
time by selecting the checkbox to the left of the file's Hostname, then clicking the Remove tab at the top
ofthe list.
Comparing uploaded qkview files

Two or more qkview files can be compared to one another using the BlG-IP iHealth Compare function.
Choose the files to compare by selecting the checkbox to the left of each file's Hostname, and then click
the Compare tab at the top of the list. iHealth will analyze the selected files and display any
configuration differences between the two.
BIG-IP iHealth Viewer

The B1G-lP iHeaIth viewer translates the raw information contained in your qkview diagnostic file and
presents the information in a display format that includes summaries of your B1G-IP system's hardware,
software, failover configuration, and licensing details. Graphs showing performance metrics, such as CPU
usage, throughput, memory, and RAM cache, can be customized to display data from particular time
periods. You can also search for specific information in your configuration files, logs, BlG-lP iHealth
Diagnostics output, commands, and the graphical network map. (See Figure 17.)
If the qkview file was generated on a BIG-IP clustered device such as a VlPRlON, the hostname at the
top ofthe screen will display as a drop-down menu from which you can navigate directly to any blade in
the chassis.

9-40 Chapter 9 - Troubleshooting the BIG-I P System
• Commlndl Identln.d {el
Grop'"
Critica' lOJ
'1' OI.gnOlltcs
c"..,.,
Expt'cwd data may be missing aft.r a qkvi.w 'il. upload
Recommended upgrade version Solution Links Internill Solutions
None None S0111iOi
Log menages report the TMM clock advanced

Recommended upgrade veBlon Solution Links Internal Solution!.
Nonl! SOL10015 None
Figure 17: A portion of the BIG-IP iHealth viewer diagnostics display
Navigating the iHealth Viewer

BIG-lP iHealth analysis and diagnostic information is acccssed using the navigation links on the left side
of the screen. As you view this information, keep in mind that it represents the state of your BIG-IP at the
time the qkview file was generated (i.e. it is not "real time"). The navigation links are summarized in the
table below.
~ilvig ~()n Link _o.~~.cription_ _ _ ~lIb-naVij:Ja_ti()n_

Status Contains key configuration data about your Hardware and software
BIG-IP system's hardware, software, failover Failover status
status, and licensing. Licensing
Network Contains network configuration maps Virtual Addresses and Servers

Pools and Pool Members
iRules
Profiles and Monitors
Classes
Commands Maps out a series of commands that can be
tmsh
used to display configuration information as
UNIX
it would be if you had executed the
Utilities
cOO1mands on BIG-IP itself
Graphs Detailed graphs rendered for all trending

Content varies
data observed in the qkview file.
Diagnostics Displays the results of a series of tests Critical

iHealth performs to see if your BIG-IP is High
operating normally. Test results are broken Medium
out into two categories: Identified and
Low
Passed.

..1II3vigation Link Description Sub-navigation

Files You can drill down into each of the config
configuration files, logs, and other raw data log
contained in the qkview file to help locate etc
issues that may not have been found by
wa
BIG-IP iHealth. Content is broken down by
major file folder. ts
all
Providing feedback
The FS B1G-IP iHealth team makes updates to the iHealth system on a regular basis using feedback from
iHealth system users like you. If you run into issues or have suggestions for improving iHealth
functionality, we welcome your input. Use the Feedback link at the top of any iHealth page to send your
comments to the iHealth team. The team responds to each and every feedback submission, and tracks
reported issues and suggestions in an internal support system.

Analyzing Application Performance with

Analytics
Lesson Objectives
After completing this lesson, you will be able to describe the functionality provided by Analytics.
Overview of Analytics
What is Analytics?
Analytics (also called Application Visibility and Reporting or AVR) is a module on the BIG-IP system
that lets you analyze performance of web applications. It provides detailed metrics such as:
• Transactions per second
• Server and client latency
• Request and response throughput
• Session data
You can view metrics for applications, virtual servers, pool members, URLs, specific countries, and
additional detailed statistics about application traffic running through the BIG-IP system.
Transaction counters for response codes, user agents, HTTP methods, countries, and IP addresses provide
statistical analysis of the traffic that is going through the BIG-IP system. You can capture traffic for
examinatiou, and have the system send alerts so you can troubleshoot problems and immediately react to
sudden changes.
The Analytics module also provides remote logging
capabilities so that your company can consolidate
statistics gathered from multiple BIG-IP appliances
onto syslog servers or SIEM devices, such as Splunk.
Note: You must provision the AVR module

before you can collect application statistics.
Analytics profiles
Unlike other BIG-IP profiles that modify traffic
behavior, the Analytics profile collects information
about traffic behavior. The Analytics profile is a set
of definitions that determines the circumstances
under which the system gathers, logs, notifies, and
graphically displays information regarding traffic to
an application. Thc Analytics module requires that
you select an Analytics profile for each application
you want to monitor. You associatc the Analytics
profile with one or more virtual servers used by the Figure 18. The AnelyOes p rofile determines the
application, as illustrated in Figure 18, or with an CitCUfflSrancas under which application statislics are
iApps application service. Each virtual server can galh6t'6d and published
have only one Analytics profile associated with it.

In the Analytics profile, you customize:

• What statistics to collect
• Where to collect data (locally, remotely, or both)
• Whether to capture the traffic itself
• Whether to send notifications
The BlG-JP> system includes a default Analytics profile called analytics. It is a minimal profile that
internally logs application statistics for server latency, throughput, response codes, and methods. You can
modify the default profile, or create custom Analytics profiles for each application, if you want to track
different data for each one.
Charts shown on the Statistics» Analytics » HTIP screens display the application data saved for all
Analytics profiles associated with iApps application services or virtual servers on the system. You can
filter tbe infonnation, for example, by application, URL, or pool member (among others), as illustrated in
Figure J9. You can also drill down into the specifics on the charts, and use the options to further refine
the infonnation in the charts .
... T'(TIe Period La:5it f-br ...
AvO Server LlIte n~ per Pool Mem~r ovef t61\~ (ms) Avg Gel 'lef I..a(~ per Po ol Member" ( m~ )
20 10
8
15
10
5
2
o+-----~--- o
11/ 19/20) 3 1 3: 4S :W/l 9/201J 14 :OS'm/19 2 3
Me.a~1'I. tD di51llay
lI."V S!:rve;-~ms~· ...
Figure 19: Sample traffic capture statistics from Analytics

Setting up application statistics collection

You can set up the BIG-LP system to collect application statistics locally, remotely, or both. You use these
statistics for troubleshooting and for improving application performance.
You can collect application statistics for one or more virtual servers or for an iApps application service. If
virtual servers are already configured, you can associate them when setting up statistics collection. If you
want to collect statistics for an iApps application service, you should first set up statistics collection,
creating an Analytics profile, and then create the application service.
The system can send alerts regarding the statistics when thresholds are exceeded, and when they cross
back into the normal range. You can customize the threshold values for transactions per second, latency,
page load time, and throughput.
Note: For complete instructions on setting up application statistics collection, please refer to the
chapter entitled Setting Up Application Statistics Collection in the BIG-IP Analyfics:
Implementation manual.
Troubleshooting Applications by Capturing Traffic
Note: System performance is affected when traffic is being captured.
When you set up the BIG-IP system to collect application traffic statistics, you can troubleshoot problems
that have become apparent by monitoring those statistics. For example, by examining captured requests
and responses, you can investigate issues associated with latency, throughput, or reduced transactions
per-second to understand what is affecting application performance. Of course, this assumes that you have
some baseline performance statistics established such that anomalies can be detected.
After A VR is provisioned, you create an Analytics profile that includes traffic capturing instructions. The
BIG-IP system can collection application traffic locally, remotely, or both. If the system is already
monitoring applications, you can also update an existing Analytics profile to make surc it captures traffic.
If logging locally, the BIG-IP system logs the first 1,000 transactions, and displays charts based on the
analysis of those transactions. For VLPRION systems, the local logging consists of the first 1,000
transactions multiplied by however many blades are installed. If logging remotely, the system logs
information on that system; log size is limited only by any constraints of the remote logging system. To
see updated application statistics, you can clear the existing data to display the current statistics.
Capturing traffic for troubleshooting

You typically use traffic capturing if you notice an application issue, such as trouble with throughput or
latency, discovered when examining application statistics, and want to troubleshoot the system by
examining actual transactions. (System performance is affected when traffic is being captured.)
Special considerations apply if you are using Analytics on a BIG-IP system with both Application
Security Manager (ASM) and Access Policy Manager (APM), where security settings (in Portal Access
webtop or an iRule) redirect traffic from one virtual server to another. In this case, you need to attach the
Analytics profile to the second virtual server to ensure that the charts show accurate statistics.
By focusing in on the data and limiting the type ofinformatioll that is captured, you can troubleshoot
particular areas of an application more quickly. For example, capture only requests or responses, specific
status codes or methods, or headers containing a specific string.

Reviewing captured traffic

Before you can review captured traffic details on the BIG-IP system, you need to create an Analytics
profile that is capturing application traffic locally. The settings you enable in the Capture Filter area of the
profile determine what information the system captures. You then associate the Analytics profile with one
or more virtual servers, or with an iApps application service.
The system starts capturing application traffic as soon as you enable it on the Analytics profile. You can
review the captured transactions locally on the BIG-IP system by going to System» Logs» Captured
Transactions. The system logs the flrst 1,000 transactions. (On a VIPRION system, the system logs the
first 1,000 transactions multiplied by the number of installed blades.) Optionally, use the time period and
filter settings to limit which transactions are listed. Click on a specific transaction to examine additional
details.
You can also click the Clear All button to clear all previously captured data records (including those not
displayed on the screen) and start collecting transactions again. The system will capture the next 1,000
transactions locally and display them on the screen. Captured transactions arc available a few seconds
after they occur.
Note: For complete instructions on capturing traffic, see the chapter entitled Troubleshooting
Applications by Capturing Traffic in the BIG-IP Analytics: Implementations manual.

Working with F5 Technical Support
Lesson Objectives
After completing this lesson, you will be able to describe tbe goals and resources of the F5 support
organization.
F5 Support Commitment
F5 is constantly striving to improve our service and create closer customer relationships. Designed to
remotely assist you with specific break-fix issues and ongoing maintenance of your F5 products, you can
always expect consistent, professional, high-quality support services from F5. This means:
• We expect our Network Support Engineers to conduct themselves professionally at all times.
• We are committed to providing the best customer experience possible.
• You will be treated with respect and given every consideration possible.
• Our goal is to provide customers with resolutions the first time, every time.
• You have a right to request manager escalation for unresolved or "network down" issues.
Many of the technical support issues we deal with are due to configuration errors, either within the BJG
IP system or with other devices in your network. In some cases, the issue comes down to a
misunderstanding of BIG-IP's capabilities. And some even involve BIG-IP device flaws. Regardless of
the root cause of a problem, our goal is to resolve your issues quickly and consistently.
F5 Support Resources
F5's support resources are available 24 hours a day, seven days a week, and are distributed around the
globe in multiple support centers. Live technical support is provided by our professional Network Support
Engineers, and hours vary depending on the customer's service contract. Self-service support is provided
through many online tools including AskF5 and Deveentral, which we covered earlier in this course.
These resources can be very useful in helping you to identify whether or not you're dealing with a known
lssue.

Working with F5 Support

At some point, your troubleshooting activities may lead you to conclude that the problem is an F5 issue Or
you may simply decide you want further assistance. Either way, the work you have done during
troubleshooting and self-service support will put you that much ahead of the game as F5 Support will ask
for much of the same kind of infonnation you have already been gathering.
Guidelines for submitting a support case to F5

You can open and manage cases online from the WebSupport portal or you can phone us for tecllnical
support. Once we receive your case andlor verifY your return phone number, we will be happy to contact
you to discuss your case or concern in more detail.
To open a support case with F5 Technical Support, or to register for access to the WebSupport portal, you
must have an active support contract, and you must be autborized to open support cases against that
contract. If you are an end user of an F5 product or client application, such as the Edge Client for iOS, the
Edge Client for Android, or the FirePass controller, and you require technical support, contact your
system administrator or IT department for assistance. Only authorized contacts can open technical support
cases with F5 Technical Support.
Contacting F5 support by phone

The toll free number in North America is 1-888-882-7535. The direct North America phone number is
(206) 272-6500. Outside North America, the Universal Toll Free number is +800 II ASK 4 F5 (or 800
11275435). For other country specific numbers, please refer to the F5 Customer support page at:
bttp:/Iwww.rS.com/support/support-services/contacU
Registering with F5 support online

You can also cOntact F5 Technical Support online at the WebSupport portal (https:/Iwebsupport.r5.com ).
To do so, you must first register for access to the WebSupport portal. You will be notified by email witbin
24 hours that your account has been enabled with WebSupport portal access.
Information required when opening a support case

Wben opening a support case with F5, you will be required to provide several pieccs of infonnation as
well as supporting documentation. Although the complete list varies from product to product, the required
i nfonnat ion is summarized in the list below.
• The serial number of the BIG-lP device requiring support
• A full description of the issue including symptoms, time the problem was noticed, steps to
reproduce, any changes made immediately prior, resolution steps to date, etc.
• A description oftbe impact the issue is having on your site. Is your site down? Is it at risk of
being down? Is perfonnance degraded? Or do you just need general assistance?
• Contact and availability infonnation for you and any alternate contacts
• Remote access infonnation, if possible. If no remote access is possible, you may be asked to
provide a UCS archive of the current configuration when submitting your case.
• Product speci fic infonnation

!upcw<1 :loalooal :..... H.... ""!krr ,~., ••,.. ell'''''!
.ttaOUl I SOL\J11ON:I: .. .'

WebSuppon
Create a New Case - Step 1 of 4
EnlOr 0 Volld Sorial N.umbGr
AoF5 • Case Type : RtogIOI lillr e lise

1l
""""'~ ..
BIG-IP iHfllttl
l lcenaing I Acltvl lion

• TItle for this Case ;
.. S&f1 al Numb_ ,
Regi stration Klly or
o.vC . ntc;sl
Panlnt Syst em 10:
........
Figure 20' Opening a support case al webslipport.l5.com
Product specific information

Refer to the following product-specific articles for details about the information you need to provide
when opening a support case. These articles are available online at AskF5.com.
Product Article Product Article

BIG-IP LTM SOL 135 BIG-IPASM SOL6825
BIG-IPGTM SOL 135 BIG-IP PSM SOL9360
BIG-IP Link Controller SOL 135 WebAccelerator SOL6705
BIG-IPAPM SOL 11898
- -- - -_. Ente_reri.se M ~ ~ger SOL7569
---_.__.•.
'-"-"-- " - - ' - - "' ~

Diagnostic and reporting tools

Many different diagnostic and reporting tools can be used during the troubleshooting process. The table
below summarizes some of the most commonly used (and requ ested) files :
log A qkview file contains the log entries for the last day. If your issue has existed for
more than one day, provide all the log files on the system to F5 Technical Support.
Use the following steps to create a ,tar archive:
1. Access the command line
2. Change directories to the Ivarllog directory: cd /var /log
3. Compress all log files into one:
t ar - czpf Ivar/tmp/ l ogf il es .ta r.gz *
Packet trace If the problem involves the network, perform a packet trace while the problem's
symptoms are showing, and provide the output when you open the case. See Using
tcpdump in a BIG-IP Environment later in this chapter or refer to SOL4714:
Perfonning a packet trace and providing the results to F5 Technical Support
UCS archive If you cannot give F5 Technical Support remote access to your BIG-IP system, you
may be asked to provide a UCS archive of your current configuration at the time you
open a case. UCS archives were covered earlier in this course. For more information,
refer to SOL2250: Overview of UCS archives.
Core files BIG-IP can generate core dump files (also known as core files or cores) for a variety
of reasons. When BIG-IP encounters an issue, it may deliver a signal to the affected
process which terminates the process and writes a core dump file containing an
image of the process's memory at the time of tenmination. Cores are written to the
Ivarlcorel directory. For more information, refer to SOL 10062: Working with BIG-IP
core files.
Providing files to F5 Technical Support

Once you have gathered all of the infonnation for your case, you need to get it to F5 Technical Support.
Much of th e required infonnation is provided over the phone or via the WebSupport portal. However,
product specific information may include any of the diagnostic files described above to help F5 Technical
Support resolve your issue. You can use one of the following two methods to upload files to F5:
• Upload a qkview diagnostic file to BIG-IP iHealth al ihealth,f5,com
• Upload (and download) files using dropbox,f5,com

Uploading qkview diagnostic files to BIG-IP

If you are running BJG-JP IO.x or later and need to provide a qkview diagnostic file to FS, the preferred
way to do so is to upload the file to the BIG-IP iHealth website. BJG-JP iHealth allows you to quick
diagnose the health and proper operation of your BIG-IP system, and is covered in detailed in the next
lesson, BIG-IF iHealth and qkview Diagnosric Files.
Uploading/downloading files using dropbox.f5.com

The dropbox.f5.com site is a widely-available file repository for exchanging incoming and outgoing
diagnostic files with the FS support team, and supports HTTP, FTP, and SFTP for transferring files
to/from FS. (The SCP protocol is not supported.).
Access to the dropbox.fS.com site is associated with an open support ticket number. The username is the
ticket number and the password is the email address ofa user associated with the ticket. For example, if
joeuser@example.com opened ticket C123456, he would log in to the dropbox.f5.com site using the
following information:
Username: C12345
Password: joeuser@example.com
If you experience difficulty logging in to the dropbox.fS.com site, please contact FS Technical Support.
For complete instructions on file upload/download using dropbox.f5.com, please refer to

General Solution SOL2486: Providing files to F5 Technical Support
Running End User Diagnostics

The End User Diagnostics (EUD) software is a set of diagnostic tests that provide reports about various
components in a BIG-IP hardware unit such as sensors, LEOs, memory, SSL hardware, etc. EUD
software is pre-installed on each BIG-IP system beginning with BIG-IP version 9.1.2, and there are
different EUD packages depending on the platform.
In almost all cases, FS Technical Support will be the one asking you to run one or more EUD tests.
When troubleshooting a potential hardware problem, FS recommends downloading and installing the
latest version of the EUD for your platform prior to running system diagnostics, as:
• EUD software is updated regularly for the relevant platform types. The latest EUD versions
contain fixes and up-to-date changes for supported hardware platforms.
• Older versions of EUD software may not contain updates pertaining to platform changes such as
those for RoBS compliance systems.
• Failure to use the latest released version of EUD software may result in false negative or false
positive EUD reports, which can further delay the time required for problem resolution.
Important: When EUD software is running, the BIG-IP system is not'
Note: For information about EUD software, please refer to the End USer Diagnostics release
notes, available at AskF5.com.

Chapter Resources
Courseware
Troubleshooting BIG-'IP Local Traffic Manager
BIG-IP iHealth Tutorial (http://www .f5 .com/flash/ihealth/index.html)
Manual
_ .--._
Chapter
BIG-IP TMOS: I,:!,plementations SNMP Trap Configuration
Solution Solution Title

Number
SOL3727 Configuring custom SNMP traps
SOL 11234 Disabling default SNMP traps
SOL 11127 Testing SNMP traps on BIG-IP (9.4x-11.x)
SOL 135 Infonmation required when opening a support case for BIG-IP systems
SOL 12878 Generating BIG-IP diagnostic data using the qkview utility (10.x-11.x)
SOL2486 Providing files to F5 Technical Support
SOL4717 Perfonming a packet trace and providing the results to F5 Technical Support
SOL 10062 Submitting core files for analysis to F5 Technical Support
SOL2633 Instructions for submitting a support case to F5
SOL 13595 Frequenlly used tools for Iroubleshooting BIG-IP APM and Edge Gateway issues (v11.x)
SOL8187 Troubleshooting BIG-IP device certificates
SOL6546 Recommended melhods and limilations for running tcpdump on a BIG-IP system
SOL411 Overview of packet tracking with the tcpdump utility
SOL7227 Using tcpdump to view traffic on a lagged VLAN
SOL 13639 Capturing internal TMM information with tcpdump
SOL4918 Overview of the F5 critical issue hotfix policy
SOL 13333 Filtering log messages sent 10 remote syslog servers (11.x)
SOL5532 Configuring the level of infonmation logged for TMM-specific events
SOL 13317 Configuring the level of information that syslog-ng sends to log files (11.x)
SOL 13080 Configuring Ihe BIG-IP system to log to a remote syslog server
SOL8002 Determining the End-User Diagnostics version
SOL 12882 Overview of the F5 Return Materials Authorization (RMA) process

Lab 9.4 - Troubleshooting Lab
Objectives:
• Use your knowledge of B[G-IP traffic flow and the troubleshooting tools presented in this chapter
to determine where the instructor has introduced a problem into the network.
Lab Requirements:
• vs _ https virtual server at lO.IO.X. [00:443 and vs _http virtual server at 10.1 O.X.! 00:80
Drive Traffic through Existing Virtual Servers and Debug

Note: If you are having difficulty troubleshooting th is problem or are growing frustrated, ask
questions of the instructor. Asking questions is one of the most fundamental aspects of
troubleshooting, especially for complex problems.
Try to access your existing virtual servers to determine if each still works. Access:
I. http://IO.I0.X.I00 using your browser
2. https:IIIO.IO.X.IOO using your browser
3. 1O.IO.X.IOO port 22 with an SSH client (such as PuTTY)
Q. Which virtual servers are working and which are not?
4. Use statistics, tcpdump, and other troubleshooting tools and techniques you've learned during
class to diagnose the problem.
5. When you figure out what is wrong, determine if you can fix or circumvent the problem with a
configuration change. If so, make the change and retest the non-working virtual server(s) again.
If you have Internet access and an iHealth account, continue with Lab
9.5 - iHealth Lab.

Lab 9.5 - iHealth Lab (Optional)
Objectives:
• Create a qkvicw file and upload to BIG-IP iHealth for analysis.
Lab Requirements:
• This Jab is dependent on connectivity to both BIG-LP and the Internet from the same workstation.
• Student must have an iHealth login.
Generate a qkview File and Upload to BIG-IP iHealth

Generate the qkview file
l. Change the password for your admin user from ad minX back to just ad min.
2. Generate a qkview file on your BIG-IP.
Support Snapshot section
When complete, cUck ...
The qkview process may take several minutes to complete. When it does, continue with the steps
below.
Download the qkview file

3. Download the qkview fiJe to your workstation. (Assumes you have just successfully generated a
qkview file, as in step 1).
Support Snepshot section
I Snapshot File IClick the Download Snapshot File button
4. Find the downloaded qkview file on your workstation and rename it to

case_number_bigipops_support_fIIe.tar. (The file should currently be named something like
case_number_ ###_ support_fIle.tar).

Upload the qkview file to iHealth
Note: If you do not have Internet access from your workstation, the instructor may demonstrate
these steps instead.
5. Open a separate browser window and connect to ihealth.fS.com.

6. Sign in using your F5 WebSupport credentials. The BlG-lP iHealth Upload a qkview screen
appears. Click the Upload button to continue.
7. Click the Choose File button and select the qkview that was downloaded to your workstation in
step 2 and renamed in step 3. Click the Upload button to continue. The BlG-lP iHealth system
may take several minutes to upload and then analyze the file.
8. After the analysis is complete, BlG-IP iHealth automatically opens an iHealth viewer window
with the results of your qkview file analysis. Look in the analysis results for any priority
notifications. You should find at least one that indicates your admin userid is not secure because
you are still using the default password.
9. Change the password for your admin user from admin back to just adminX.
STOP

Chapter 10 - The BIG-IP Product Suite 10-1
Chapter 10: The BIG-IP Product Suite

Chapter Objectives
After completing this module, you will be able to:
• Discuss some of the product features and functions of BIG-IP GTM, ASM, APM, WA, and
WOM
• Describe the basic flow of network traffic through BIG-IP GTM, ASM and APM
BIG-IP Product Family Overview
The BIG-IP product family is a system of integrated application delivery services that work together on
the same best-in-class hardware. From load balancing, SSL offload, and web acceleration to application
security, access control, and much more, the BIG-IP system creates an agile infrastructure to ensure your
applications arc always fast, secure, and available.
Traffic Management Operating System

The modular BIG-IP system is built on FS's Traffic Management Operating System (TMOS) platform,
which offers tremendous scalability and customization. You can start with one specific function to meet
your current business needs and budget, and add more capacity and functionality as your application and
business demands change.
With TMOS, you gain the adaptability to adjust to network conditions and business policies using
iControl, F5's highly versatile open API, and iRules, the F5 custom, event-driven scripting language. You
also get a uruque, application-centric view of your infrastructure with powerful iApps features. iApps
enables you to deploy and manage network services for each of your specifiC applications with
unprecedented speed and accuracy. In addition, TMOS also gives you unique ScaleN functionality,
including Clustered Multiprocessing (CMP), Virtual Clustered Multiprocessing (VCMP), and Device
Service Clustering (DSC) enabling virtualization and scaling up or scaling out on demand.
Local Traffic Manager (L TM)

BIG-IP LTM is a full proxy between users and application servers, creating a layer of abstraction to
secure, optimize, and load balance application traffic. This gives you the flexibility and control to add
applications and servers easily, eliminate downtime, improve application performance, and meet your
security requirements.
Global Traffic Manager (GTM)

BIG-lP GTM automatically resolves DNS queries to the closest or best-performing data center in the
event of an outage, overload, or other disruption. The result is faster response times for users and optimal
use of multiple data centers.

10-2 Chapter 10 - The BIG-IP Product Suite
Application Security Management (ASM)

BIG-LP ASM is an advanced web application firewall that protects critical applications and their data by
defending against application-specific attacks that bypass conventional firewalls.
Access Policy Manager (APM)

BIG-IP APM provides secure, context-aware, and policy-based access control. It centralizes and
simplifies authentication, authorization and accounting (AAA) management directly on the BIG-IP
system.
DNS and GTM System Options
Lesson Objective
Upon completion of this lesson, participants will be able to list the most common implementations of
GTM systems and some of their advantages and disadvantages.
DNS Servers
Many systems provide DNS services. Many are based on recent versions of BIND. Additionally, many
sites use Microsoft DNS services. BIND is used on most UNIX systems and is the more prevalent choice
overall while Microsoft DNS is used in many Window environunents.
DNS Server Implementation Limitations

While both BIND and Microsoft DNS are functional. they have limitations. First, BIND files are prone to
editing errors. The more significant limitations become issues when multiple addresses are associated
with a single name. In this situation, the same service might be available at various sites around the
Internet. As long as all the sites are working, clients should be able to get their content. But if a site fails,
both BIND and Microsoft DNS will continue to resolve DNS queries to that LP address. Even if all sites
are working, what would the desired result be if all the servers are working, but some working better than
others? What if all the servers are working, but the network latency varies between the sites? What if all
the servers are working, but the administrators would like clients to use some servers more than others or
some servers exclusively? For each of these situations, BIND and Microsoft DNS will resolve the
addresses in a round robin fashion. These are the kind of issues the GTM System is designed to resolve.
GTM Advantages
GTM uses its knowledge of your environunent to aid in making name resolution decisions. First, GTM
will determine which addresses are working properly. If desired, GTM can compare the response time
between your customers and your various data centers. Using these metrics, GTM will choose the best of
the available virtual servers and resolve the name request to that LP address. This is known as intelligent
DNS.

Chapter 10 - Th e BIG-IP Product Suite 10-3
GTM and Intelligent Name Resolution

The follo wing process di agram ex plains how a GTM might fit into the DN S query resolution process for
internet clients outside your organi za tio n.
I. A c lient enters the name www.fS.comin a browser.
2. The client system sends a DNS query to its Local DNS (LDN S).
3. The LDN S sends the same query to one or more root servers.
4. A root server responds w ith the lP addresses for .com na me servers.
5. The LD NS sends the same query to one or more o f the .com name servers.
6. A .com name server res ponds with the IP address of the GTM System .
7. The LDNS sends the que ry to the GTM system.
8. T he GTM Syste m determines the best DNS answer and sends that ans wer back to the requesti ng
cl ient's LDNS server. This is a GTM-specific feature and differentiates GTM from othe r DNS
servers.
9. The LDNS caches thi s IP address and sends it to the client that made the request.
10. The cli ent connects to the IP address supplied by the LDNS.
root name server .com name server r5.com name server

192.33.4.1 2 100.1.1.1 216.34.94.17
li: •• _ _ l-a jf fi
BIG-if> GTM
100.1.1.1 216.34.94.17 216.34.94.32
o
192.33.4.12 Loca.I DN S
• http://www.f5.com
Agure 1: ONS query process with GTM

GTM as the LDNS Server

The following process diagram explains how a GTM system improves the DNS query resolution process
for internet clients inside your organization.
I. An in ternal cl ient enters the name www.fS.comin a browser.
2. The client system sends a DNS query for an Internet site ou tside their local organization to its
local GTM system, now ac ting as tbe local DNS (LDNS) server.
3. The GTM system acting as the LDNS resolves the query by any, all, or a combi nation of means,
including:
• Local BIND
• Standard DNS service
• DNS Express
4. The GTM System receives the answer, caches the answer, and sends the answer back to the
requesting client.
5. The client connects to the lP address.
F!5.com NatnQ Server

216.34.94.17
216.34.94.32
VI"ual Server on
BIG-IP System .com Server
100.1 .1.1
216.301.94.' 7
CD -....
([) GTMSystem
Internal Clle~
Root name Sorver
<D
192.33.4 .12
CD http://www.f5.com
Figure 2: OTM as the LONS server

GTM Resolution Options

When a DNS query is received by a GTM system, thcre are several different methods tbat may be used to
resolve each query. Most importantly, for any of the GTM advanced DNS features to be involved in the
resolution, the query must arrive on the system destined to a Listener. A GTM Listener is a special object
on the BIG-IP GTM system that can:
o Resolve DNS resolutions intelligently
o Accelerate DNS resolutions
o Add security and sign responses according to the specifications ofDNSSEC
• Recursive resolution
Intelligent DNS Resolution

When a query arrives on the GTM system, and the query is addressed for a GTM Listener, and the name
being resolved is a Wide IP, the GTM system will resolve the query to the best address based on multiple
parameters. These parameters include various network metrics, server metrics, and site specific policy
choices. Discussion of intelligent DNS resolution and Wide IPs is in a later module.
Accelerated DNS Resolution

Two GTM features are available to help scale DNS resolutions hosted on standard DNS systems (such as
those running BIND).
o Configuring a GTM Listener and associating it witl:t a pool ofDNS servers.
o Configuring DNS Express, a new feature in BlG-IP GTM versions II.
GTM systems can accelerate DNS query resolutions by defining groups of DNS servers, called pools on
the BIG-IP system, and associate such pools with a GTM Listener. When the DNS query arrives destined
to the Listener, the query is load-balanced across the pool ofDNS servers. This technique allows the
DNS structure to scale based on the number of DNS resolutions being processed. As more queries are
processed, additional back-end DNS servers can be added. In addition, the GTM system can use Monitors
as a method to ensure the DNS servers are working properly. Defining a pool ofDNS servers to resolve
DNS querys was made available in version 10.2 ofBIG-IP GTM. For those familiar with the Local
Traffic Manager (LTM) product, this is the kind of processing typically performed by LTM systems.
The second acceleration technique, called DNS Express, is new in GTM version 11.0. When DNS
Express is configured, the GTM system acts as a secondary DNS server and requests a zone transfer from
a primary DNS server. The GTM then resolves queries directly. Performance on GTM Systems with DNS
Express can be measured by handling hundreds of thousands of requests per second. When DNS Express
is used, the primary servers need to allow zone transfers to the GTM system and send notifies to the GTM
system when changes have been made. Additionally, the DNS system can be configured with TSIG
(Transaction SIGnature, defmed in RFC 2845) keys so that the GTM system can be assured all notifies
are legitimate.

Remote DNS Resolution

Finally, if a query arrives on a GTM system destined to a Listener but it is NOT:
J. Anempting to resolve a Wide lP name,
2. Anempting to resolve a name in a zone that is configured for DNS Express,
3. Destined to a Listener associated with a pool of DNS servers
Then the query can be sent to a standard DNS system for resolution.
If the query is addressed to a GTM Listener, and if the Listener's DNS profile has local BIND support
enabled, the query is forwarded to the BIND instance running on the GTM system. If the Listener's DNS
profile does not have local BIND support enabled and the Listener's address is not a self-lP on the GTM
system, the query can be forwarded to tbe remote system tbat hosts that lP address. At that point,
resolution is detennined by tbe configuration on that standard DNS system.
Note: If a DNS query arrives on a GTM system that is not destined for a Listener address but is
destined for a self-IP that has port UDP 53 unlocked, the query will be processed by the
instance of BIND running on the GTM system.
Hierarchy of Options Flow Chart

The resolutions options discussed above can be summarized in the flow chart in Figure 3.

DNS Query arrives on

INote:A U5.lener IS re,qUlrea
GTM Listener
for any DNS resolution
beyond BIND
Intelligent
Name is a Wid€-IP? Yes Original GTM
Resolution
No
Name in a DNS Accelerated

Yes DNS Express vll.0
Express Zone? Resolution
.
No
Name, in ONS Accelerated

Yes ONS Cache vll.2
Cache? Resolution
No
Load Balanced GTM - DNS load

Listener has a Pool? Yes
balanced pools vlO,2
for Resolution
No
LocalONS Option to Validate

Recursive Resolution Yes
Lookup v11.2
and Cache?
No
istener with ONS Local BIND ONS BIND in origInal

Yes
profile to use Resolution GTM
cal BIND
No
Listener is Self-IP >---No
Figurt> 3: GTM DNS query flow options

ASM as a Web Application Firewall

Lesson Objective:
During this lesson, you will learn the anatomy of a web application and how it operates in the network.
The following topics are covered:
• Web Application Concepts
• Web Application Firewalls and security
• HTTP concepts
• HTML concepts
In part 2 of this module, you will use the Fiddler application to view HTTP traffic.
Anatomy of a Web Application

Web applications are highly complex environments that depend on many components to provide users
with answers to their requests. Most commercial web applications consist of at least three main
components: Web server, Application server and Database. Some of the components are developed by
the organization, some by external sources, and some are shelf ware.
In most cases, a browser interacts with tbe web server by sending HTTP requests and awaits a response.
The web server will frequently need to interact with other services, such as application servers to generate
the HTTP response. In addition, the application server may in tum have to query a database to be able to
create its response.
This entire process is the web application. While a browser is the most common client, otber tools such
as cURL, Burp Suite, and Web Scarab can also communicate with web applications and give the client
fine controls over interactions.
ASM is designed to ensure the entire web application is secure from intentional or unintentional misuse
of the application that could compromise a site's security.

Figure 4 shows an example of how infonnation might flow through the entire application, from end-user
to the database. User data is sent via the web browser, accepted by the web server, processed by the CGI
scripts and the application server, and then sent to the backend server and the database server.
Data
\a" Database server
\l Back-end app server
~ ~ Application server
~ .f\ CGI/JavaScript
~ Web server
Hnp
< >
HTML
Request
\t ~
FIg(Jre 4: Application flow fram end user 10 dara/mse and back
Applications differ greatly in functionality. Some applications are based on .asp, .jsp, or .cgi. Some
applications run on Apache, Linux, or Windows. While web applications differ in what they do, they are
relatively similar in the way they do it. Web browsers provide the means by which users interact with
web applications. HTTP is the protocol that governs communication between browsers and web servers.
HTML is the language used to fonnat the pages browsers can display.
Web application logic says that if valid input comes in, then the application knows how to deal with it and
valid output will come out. Using the same logic, if invalid input goes in, invalid output may come out.
Now there are lots of systems within the web applicatlon and some might know how to deal with such
invalid input but some may not.
Each part of the web application can potentially be vulnerable to attacks. While it may seem
unimaginable to any IT manager that a general user from the outside will have direct access to the
database, there is a risk.

An example is a username and password request from a client to an application. In such a scenario,
unsanitized user input can be processed by the database with potentially unwanted results.
If an attacker included database commands in their "username", they might cause the database to act
contrary to the site's policies. This type of attack is known as a SQL injection.
When an organization deploys a web application, they invite the world to send them HTTP requests.
Attacks buried in these requests sail past ftrewalls, ftlters, platform hardening, and intrusion detection
systems without notice because they are inside legal HTTP requests.
There is always a need to inspect the HTTP request before sending that traffic to web application
components. Within ASM, if the HTTP request matches legal policy enforcement, that request is
allowed. If the HTTP request does not match legal policy enforcement, a violation will be issued and that
request can be blocked.
Data
Database server
Back-end app server
Application server
CGI/JavaScript
Web server
t j l ..r I I
(A""' >
r~ ljj HTIP
Appllaaijgn ~tufly Request
HTM L
Menager
tl- - - - .
f3.rowser
Figure 5: ASM blocks illegal HTTP requBsts

Security Options and Application Security

Secure Socket Layer
SSL secures assures the client that they are interacting with the expected server and secures the data in
transit. However, SSL does not securc the application. Even if a uscr is successfully authenticated, that
user can still attack a web application.
Hardened Servers
Security plans include updating applications when issues are found, but this only protects against t1aws in
the application and not t1aws in the application logic. For example, if an undocumented method to access
an application is found, a "back-door", tbat is an application t1aw. That can be patched with application
updates. On the other hand, allowing a user to manipulate an item's price on an ecommercc site is an
application logic t1aw.
Most environments provide some degree of protection against many network-level attacks, but are
vulnerable to logical attacks.
In addition to network-level attacks, sites should have both negative security, protcctions against known
attacks, and positive security, awareness of appropriate client-server interaction.
Positive security is the only protection against "zero-day" attacks - when an attack is so new that
dcvelopcrs have had zero days to address tbe vulnerability.
Network Firewalls
Firewalls offer sophisticated security abilities but only up to the transport layer of the OS! model. The
client may not be able to connect to the SSH server running on your equipment since port 22 is blocked,
but you cannot block port 80.
[ Data Link Layer

)
[ Physical Layer
J
Figure 6: Typical firewall implementation blocks port 22 but aflows traffic on port 80

Firewalls are usually aware of the connect state as well, and can thwart clients attempting to send packets
that are not part of a validated connection. But once a client is validated, they will have access to the
server - to some degree.
Firewalls can inspect !rafiic for RFC compliance and malicious patterns. However, in many cases, traffic
related to port 80 attacks is usually RFC compliant. Such lrafiic may not "look" malicious, so it passes
through network firewalls. The damage that this lrafiic causes is only relevant in the application context.
In addition, if your site is using SSL, the firewall is unable to even to provide this level of security.
Web Application Firewalls

Web application firewalls work at layer 7, the application layer, of the OSI model.
Web
application
firewall
u Presentation Layer 0
li= c
......
em ~
"E::J
0
Session Layer
C'"
0
c
::J
0.
...,-1
]
-e Transport Layer
Ql
:!;
(")
Traditional
firewall
Data Link Layer
Physical Layer
Figure 7" Web application fire waifs work at thGl application layer, not at the transport layer

Why deploy a Web Application Firewall?

There are certain situations where network and security administrators decide whether to deploy web
application firewalls. Below are some questions that administrators should take into consideration.
o Do you perfoml a vulnerability assessment of your web application? If yes, how much time does
it take to fix the vulnerabilities?
o Would you like to control web application security without involving the development team?
o How is your organization securing inbound traffic after passin g through network firewalls and
IDS/IPS devices?
o Do you have a requirement to be Payment Card Industry (PCI) compliant?
o Do you have a requirement to be Sarbanes-Oxley (SOX) compliant?
o How much visibility do you have into what kinds of bots are crawling your site?
o Can you prove that it's not "the network" slowing down application performance?
o Do you currently leverage web services in a business to business fashion?
o Do you implicitly trust yo ur business partncrs to send well-formed SOAP messages that won't
accidently DoS your company's web services endpoints?
o Are you aware of the Open Web Application Security (OWASP) Top 10? Do you need to protect
against these web application vulnerabilities? We will discuss OW ASP in a later module.
Web Application Vulnerabilities

Through a browser, a hacker can use even the smallest bug or backdoor to change, or pervert, the intent of
the operation. Any applicarion that interacts with end-users can be vulnerable to exploitation. Attacks
can be categorized into two areas. One area focuses on attacks on the infrastructure itself, and the other
focuses on attacks on the application code.
There are also various ways to categorize the security problems associated with the web application,
including the systems affected by the attack, the type of attack, by a naw in the web application allowing
the attack, or a combination of them all.
Many of the most dangerous security holes in corporate IT infrastructure are based not on WOmlS or
vi ruses, and not on known vulnerabilities in application servers, but on vulnerabilities in the applications
themselves. These vulnerabilities leave corporate web infrastructures exposed to attacks such as cross-site
scripting, SQL injections, and cookie poisoning. It is often these application vulnerabilities which hackers
exploit to extract sensitive data from corporate databases.
Companies today are making more of their mission-critical applications and data available to web
browsers. As a result, hackers are able to use web-based applications to penetrate corporate systems and
access private customer databases. The resulting identity theft has become a maj or concern to
corporations and consumers alike.
The following is a list of the 2010 OWASP Top 10 web application vulnerabilities:
1. Injection attacks
2. Cross Site Scripting (XSS)
3. Broken Authentication and Session Management.
4. Insecure Direct Object References

5. Cross Site Request Forgery (CSRF)

6. Security Miscontiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards
It is a good practice to frequently refer to the Open Web Application Security Proj ect (www.owasp.org)
for the latest developments in applicati on security.
How ASM Protects

The main concept of application securi ty is the realization that web appl ication code and logic are part of
the organization's perimeter security. While these vulnerabilities have been known for a long time, it is
for various reasons that most web applications are still vulnerable.
Web application vulnerabi lities may occur in any of the fo llowing elements of the HTTP protocol:
• Protocol
• Request
• Data
• Respons e
Protocol Element
In some envi ronments, web appli cations are vulnerable to buffer overflow, encoding attacks, and
unexpected system crashes.
ASM protects the web application from the protocol element by enforcing RFC compliancy of the HTTP
request and domain cookie, cheCking for malicious patterns and allowed characters in request and
response headers, va lidating the HTTP method, and veri tying cookie and total HTTP request lengths.
Request Element
Some web applications are vulnerable to forceful brows ing and 3rd party miscontigura tion attacks.
ASM protects the web application from request resource attacks by veri tying the method and file
extension are valid, checking for malicious patterns in the obj ect and object name, and veri tying object
length.
Data Element
Some web appl ications are vulnerable to stealth commanding, SQL inj ections, cross-s ite scripting, cookie
poisoning, and buffer overllow attacks.
ASM protects the web application from data context attacks by checking for allowed characters in the
parameter name and value, cheCking for malicious patterns in user input parameters, ensuring domain
cookies ha ve not been tampered with , and veri tying query string and POST data request lengths.

Response Element
Some web applications are vulnerable to improper error handling and sensitive information leakage.
ASM protects the web application from response element vuLnerabilities by checking for malicious
patterns in the response, verifying valid response codes, hiding the server header, and performing content
scrubbing.
HTTP Request Flow Process

When an HTTP request is sent to the BIG-lP System, it will handle that request based on several factors.
One of those factors is whether or not that request will be processed through the ASM security policy.
The client sends an HTTP request to a Virtual Server. If an HTTP Class profile is not associated with the
Virtual Server, the HTTPrequest will be sent to the default pool. Ifa default pool is not assigned to the
Virtual Server, the request will be dropped (TCP Reset).
If an HTTP Class profile is associated with the Virtual Server, and Application Security is enabled, tbe
request is processed by ASM. If the request does not match any Class filters, the request is sent to the
default pool.
If the request matches a Class tilter, tbere is a HTTP Class protile match. If this is the case, and ASM is
enabled, the request is sent to the ASM for processing. If the request is valid and a pool is associated
within the HTTP Class profile, the request is sent to the HTTP Class pool.
Ifthere is no pool associated within the HTTP Class protile, the request is forwarded to the default pool.
If there is no default pool contigured, the request will be dropped (TCP Reset).
Virtual Con!iguralion
Reque ~ ,-___S_e~Ne_r
r- __- ,
No
•
HTTP
class
match?
Yes
• Security
enabled?
No Other HTTP
class
processing
Default Yes
pool?
Application Security Manager
(P.,.ing Requalll)
Default
Yes Valid
request?
Pool
(btocking mode)
Figure 8. HTTP traffic flow through ASM

APM and Secure Access
Lesson Objective:
During this lesson, you will learn the concept of the different APM Access methods Portal and Network
Access and how they are built into the Policy engine.
APM Portal Access

Portal Access, enables end users to access internal web applications, like Lotus® iNotes® or Microsoft ®
Outlook® Web Access, with a web browser from outside the network. With Portal Access, the BIG-IP
Access Policy Manager communicates with back-end servers, and rewrites tbe links in the web page so
that further requests from the client browser come back to the Access Policy Manager. The advantage is
that the client computer requires no client software other than a browser application.
Portal Access provides clients with secure access to internal web servers, such as Microsoft Outlook®
Web Access (OW A), Microsoft SharePoint®, and IBM ® Domino® Web Access (also known as Lotus®
iNotes®). Using Portal Access functionality, you can also provide access to most web-based applications
and internal web servers. The rewriting engine also supports rewriting complex JavaScript™ You can
use features such as the web cache, minimal content rewriting mode, and others, to help refine
compatibility and tune performance.
This method of access differs from connections configured for network access, which provide direct
access from the client to the internal network. Network Access does not manipulate or analyze tbe content
being passed between the client and the internal network. The Portal Access configuration gives the
administrator both refined control over the applications that a user can access through Access Policy
Manager, and content inspection for the application data.
The other advantage of Portal Access is security. Even if a workstation might not meet requirements for
security for full Network Access, such a workstation can be passed by the access policy to certa in
required Portal Access, without allowing full network access.
In a Portal Access connection, the clien t computer itself never communicates directly with the end-pOi nt
application. That means that all communication is inspected at a very higb level, and any attacks
originating on the client computer fail because the attack cannot navigate through the links tbat ha ve been
rewritten by the Portal Access engine.
Introducing Portal Access features and operation

Portal Access policies provide secure access to intranet web applications. The application being accessed
and the protocol being supported (HTTP and HTTPS) dictate how Portal Access features operate. Figure
9 shows the process that a Portal Access connection follows.

I. Tbe user starts a secure connection with

a wcb browser to the application URL.
2. The Access Policy Manager establisbes
a connection to the server and receives
content from the server in the native
application format.
3. The Access Policy Manager rewrites
byperlinks and URLs in the HTML page
so that they point to the virtual server lP
address.
4. The Access Policy Manager sends the
content back to the user's web browser
over the connection.
APM Network Access

The BIG-lP® Access Policy Manager network
access feature provides secure access to
corporate applications and data using a standard
web browser, or the BIG-IP Edge Client™
Using network access, employees, partners, and
customers can have access to corporate resources
securely, from any location.
The Access Policy Manager's network access
feature provides users with the functionality of a
traditionallPsec VPN client. Unlike lPsec,
however, network access does not require any
--
--
pre-installed software or configuration on the
remote user's computer. It is also mucb more
robust than lPsec VPN against router and firewall Figuro 9: Portal acCBSS conneclion process
incompatibili ties.
Users connected through network access have equivalent functionality to tbose users directly connected to
the LAN. You can use access policies to control access to network access.
Understanding how network access works

Network access implements a point-to-point network connection over SSL. This is a secure solution that
works well with [lfewalls and proxy servers. Network access gives remote users access to all applications
and network resources.
Network access settings specify IP address pools that the Access Policy Manager uses to assign lP
addresses to a client computer's virtual network adapter. When the end user opens the address of the
Access Policy Manager in his web browser, the browser opens an SSL connection to the Access Policy
Manager. The user can then log on to the Access Policy Manager. You can see a visual representation of
how network access works in Figure 10.

Network access process

1. The user starts a 443 SSL session with the
Access Policy Manager, and logs on.
2. The Access Policy Manager downloads and
installs the ActiveX control or browser plugin
to the client.
3. The ActiveX control or browser plugin
establishes an encryptcd network access tunnel
with the Access Policy Manager.
4. The user connects to internal servers over the
Network Access connection, as if the client is
located directly on the internal network.
Application Access
An app tunnel (application tunnel) provides secure,
application-level TCP/lP connections from the client to
the network.
Additionally, optimization is available for app tunnels.
With compression settings for app tunnels, you can
specify the available compression codecs for client-to
server connections. The BIG-lP compares the available
compression types configured with the available
compression types on the client, and chooses the most
effective mutual compression setting based on the type
of traffic to provide application specific optimization.
The compression settings for the BIG-lP are configured
in the connectivity profile.
Figure 10. Net't\loffl8CCeSs proC:f7SS

BIG-IP Product Traffic Processing
There are similarities across the BIG-lP product line in how traffic is processed using Virtual Servers.
Most BIG-IP products enable features that modify traffic behavior using Profiles. From there the
products vary, but in many cases SNA Ts, Monitors and Pools are also used.
BIG-IP Products together

When using BIG-IP Products together, they might be implemented in the following way. APM can be
used to detemnine whether a client gets access or not. WA and WOM will assist with accelerating the
overall response to the client. GTM is often used to decide which data center to send the client to. ASM
inspects the client request from a security perspective and either allows or denies the client request. And
finally LTM distributes the client request to an available Pool Member based on monitors. We will
discuss this later, but iRules can factor into these decisions on all BIG-IP products .
• APM
WA/WOM
GTM
• ASM
LTM
FIgure 11 : BIG-IP products working together

BIG-IP LTM
In most cases for BIG-IP LTM, client trafflc arrives at BIG-JP, matches a Virtual Server and is distributed
to a Pool Member. If Monitors are enabled they can mark Pool Members offline and then that Pool
Member wiU Dot be considered during the load balancing decision . SNATs can be configured , changin g
the source address and help address routing issues. And of course Profiles added to a Virtual Server
contig wiU affect how tbe trafflc is processed. Figure 12 sbows the examples of SSL termination and
HTTP compression .
Client
c Virtua l
Server
SNAT
- Pool Member
1
Pool Member
Unencrypted
2
Uncompressed
Profiles
Monitors
Figure 12: SSL Termination and HTTPcompressioninL TM
BIG-IP GTM
GTM traffic flow is depicted in Figure 13. As with LTM, a GTM listener (similar to a virtual server)
li stens for DNS requests and then uses one of the four methods available to respond to tbat request.
ClientDNS
~.EJ
Request
IGiIII Listener
~ (VS)
i
l.....
•
DNS Express
Zone
t
•• DNS Load
BalanCing
I Pool
I
I
.... -. Local BIND
Profile
Figure 13: GTM traffic flow

BIG-IP ASM
For BlG-IP ASM, again client traffic arrives at BlG-IP, matches a Virtual Server and then might be
distributed to Pool Member or dropped. For ASM to validate the HTTP request, an HTTP class with
Security enabled must be configured on the Virtual Server. Specific ASM checks are configured within
ASM profIles or the HTTP class itself attached to the Virtual Server. If ASM determines the HTTP
request is valid then as with LTM, the client request is distributed to a Pool Member. This process is
depicted in Figure 14.
Allow
request
Client _ - - - - _ No
Virtual "Profile"
Server
(class)?
Yes Yes
Valid HTTP
request?
Deny
Figure 14: Traffic flow through ASM
BIG-IP APM
For BIG-IP APM, client traffic arrives at BIG-IP, matches a Virtual Server (typically 443 or https) and
then several tests might be performed with the client within the APM policy. One test might be to
validate the viewer's userid / password combo against an Authentication server. Another test might be to
validate the client machine is running a current version of Anti virus software.
x
Re source 1 1
Client
l •
Access --- x
Traffic Virtual
Server
Policy
Checks
,"' [• Re source2 1
Figure 15 ' Treffic flow through APM
Based on these tests, APM has the capability to build a dynamic webtop (Portal) with potentially different
resources given for each test. A resource can be an LTM Pool, an individual application like Remote
Desktop, ssh, or webpage or access to a Network range (SSL VPN). All of the policy and possible
resources are configured in the Visual Policy Editor which builds an Access Profile that is attached to the
Virtual Server, as shown in Figure 15.

_~nterprise Manager (EM)

Lesson Objectives:
• Describe the function of Enterprise Manager in the BIG-IP environment
• Describe the device discovery process
• Describe the function and use of custom lists
• List some of the tasks an administrator can perfonn using EM
• Describe the process of gathering, submitting, and viewing iHealth diagnostics using EM
• Describe how EM can be used to manage BIG-IP system archives
Overview of Enterprise Manager
Management port Indicator LEOs
Console port
10/100/1000 interfaces
1
SFP ports LCD control
buttons
Hard-wired failover port
USB ports LCD display

Figure 16. Enterprise Manager Chassis Layout
Enterprise Manager is an F5 software application that helps you streamline the administrative tasks
associated with managing multiple BIG-IP systems. These administrative tasks include:
• Perfonnance monitoring
• Software installation and upgrades
• Configuration archival and restoration
• Certificate monitoring
• Security policy management
• Software image storage
• User account management

Edge Gateway
,....
Enterpnse Manager
LTM
Figure 17: Enterprise Manager at work In a bl!J-ip network

Enterprise Manager works in many types of network topologies, including those in multi-tiered
configurations containing multiple firewalls .
You can use Enterprise Manager to manage networks with devices running the following software.
• BIG-IP system version 9.3 and later
• BlG-IP Local Trafftc Manager Virtual Edition (VE) version 10.2 and later
• BIG-IP Secure Access Manager version 8.0 and later
• WANJet version 50 and later
• Enterprise Manager version 1.0 and later

Additional resources and documentation for Enterprise Manager

You can access all of the following Enterpri se Manager documentation from the AskF5 Knowledge Base
located at http://support .f5.coml. The procedures and examples described in all documentation and online
help are written for administrator-level users with full access (non-restricted) privileges to Enterprise
Manager.
DOCUMENT DESCRIPTION
Enterprise Manager This guide provides you with the basic concepts and tasks required to set up
Getting Started Guide your Enterprise Manager and start managing devices.
Enterprise Manager: This guide contains information to help use iHealth for diagnostics purposes,
Monitoring Network track certificates, create alerts for events, run reports, and manage statistics
Health and Activity storage.
Enterprise Manager This guide provides information about the basic concepts of device
Administrator Guide management, user management, as well as information specific to
Application Security Manager policy management.
Platform Guide: These guides include Enterprise Manager system hardware platform
Enterprise Manager 4000 specifications, installation instructions, and important environmental
warnings.
Release notes Release notes contain information about the current software release,
including a list of associated documentation, a summary of new features,
enhancements, fixes, known issues and available workarounds, as well as
installation and upgrade instructions.
Solutions and Tech Notes Solutions are responses and resolutions to known issues. Tech Notes
provide additional configuration instructions and how-to information.
Incorporating Enterprise Manager into your network

You incorporate Enterpri se Manager into your network as you would any F5 Networks device. However,
because it requires bilatera l communication with each device for successfu l management, Enterprise
Manager must have open communication with your devices and be able to translate a device's lP address
into an address it can use. The most common network configurations for address translation are:
• Tiered network, BIG-IP Local Traffic Manager performs address translation

Where a device manages load balances requests for multiple devices and translates the IP
addresses for those devices through a firewall
• Tiered network, a SNA T performs network translation

Where a device (located in front of Enterprise Manager) l oad balance requests for multiple
devices, and a SNAT translates the IP addresses for those devices

Ports required for two-way communication

For Enterprise Manager to properly manage devices, the following ports are open by default to allow for
the required two-way communication.
- ----- -- -------- -
OPEN PORT PURPOSE
443 For communication between managed devices and the Enterprise Manager
system, for the purpose of device management
4353 For communication between Enterprise Manager and a managed device's big3d
agent, for the purpose of statistics collection_
3306 For communication between Enterprise Manager and a remote statistics database,
for the purpose of storing and reporting statistics_
Best practices for management network topology

Device communication and management is performed through the following interfaces:
• Traffic Management Microkernel (TMM) interfaces
For eacb of tbe following processes, you must dedicate a TMM interface to perform:
Application traffic and load balancing
Communication between Enterprise Manager and managed devices
Communication between systems in a higb availability configuration (for both static and
floating self IP address support)
• Management (MGMT) interface
Used by F5 devices for administrative traffic and for the Always-On Management (AOM)
subsystem, wbich enables you to manage a system remotely using SSH or serial console, even if
the host is powered down_ Devices do not forward user application traffic, such as traffic slated
for load balancing, through this interfacc_
ManagE!m ent Tta.~ EM atN1 BIG rP

NetworK
Enterprise
""GMT
DeVIce
Managemenl
Netwon, 1'hIJ':)r: EM DoI!'II;S ~nBQ('me.tlf
BfG~P BlG-fP
IdGln MGMT
1l4M TWM
Production
Network
Figure 18: Recommended network topology for-enlerp rise mertager

Tip: Place the Enterprise Manager system on a management subnet that is separate from traffic
management to keep device management and communication independent from traffic
management activities.
You must specify the lP address of your DNS server for communication to the F5 file servers and for
SMTP email notification. After you specify the lP address of your DNS server, you can verify that the
address properly resolves.
Managing Devices with EM

Before you can use Enterprise Manager to manage devices in your network, you must add the devices to
the device Jist. For BIG-lP devices in your network, you can use the discovery process to search specific
IP addresses or lP subnets in your network, and add those devices to Enterprise Manager. During the
discovery process, Enterprise Manager attempts to log in to available devices with an administrator user
name and password that you supply. If Enterprise Manager succeeds in logging on to devices that it
discovers, it adds those devices to the list on the Device List screen.
Discovering devices in your network

After you license and perform initial configuration for Enterprise Manager, you can discover F5 devices
in your network. Discovering devices is the first step toward device management. You can also import a
Jist of lP addresses for discovery.
Important: To perform the discovery task, you must have administrator privileges with root
access for the Configuration utility. To successfully discover devices and receive the user name
and password combination, the device must have an active SSL server listening for traffic on
port 443.
Using the Devices screen

The Devices screen is a powerful management tool that gives you a variety both high-level and detailed
views of every managed devices.
There are three tabbed views in the Devices screen
• Device List - Gives an overview of aJJ discovered devices and their status. Click on the name of a
device name to open the Properties screen where you can view:
• Device Inventory - Basic equipment tracking information: Name, platform, serial number,
version, boot location, base registration key number.
• iHealth Diagnostics - High-level iHealth diagnostic overview list for aJJ devices

Enterprise Manager Custom Lists

A custom list is a collection of selected network objects tbat can span multiple devices in your network.
Creating custom lists allows you to monitor a group of objects from one screen, without restricting the
view to an associated device.
(Note: Prior to Enterprise Manager version 3.0, the Custom Lists section of the configuration
browser was called the Networks Objects Browser.)
There are two types of custom network object lists tbat you can create: static lists and dynamic lists.
• A static list is a fixed selection of network objects.
• A dynamic list is a selection of network objects tbat match characteristics that you define in the
list's rules.
Note: Custom lists are available only for Enterprise Manager version 2.1 and later. Data
collection must be enabled to use this feature. You have the opportunity to enable data
collection as part of the process of creating a list. However, if you upgraded to the current
version of Enterprise Manager from a version prior to 1.7, you must re-license the system before
you can enable data collection. Due to the processing power required to collect and store
statistical information, data collection is available only for the Enterprise Manager 4000 platform.
Custom static lists that you create retain the network objects that you selected until you remove the
objects from the list, or you delete the list.
Creating a static list

If you want to simultaneously view a collection of network objects, or change tbe status of certain nodes
and pool members from one screen, you can create a custom static list that contains those objects. For
example, you could create a custom static list of devices managed by a particular department, or
containing all of the network objects specific to a certain office location.
Removing network objects from a custom static list

Custom static lists retain the same selected network objects until you remove the objects from the list.
Deleting a custom static list

Custom static lists remain active until you delete them.
Creating a custom dynamic network object list

You can create a custom dynamic list to contain network objects that have specific characteristics. After
you create tbis list, you can use it to view (from one page) all of the network objects that match the rules
you specify, and to change the status of nodes and pool members. Enterprise Manager removes an object
from a custom dynamic list when the object's characteristics have changed, and adds an object to the list
when it detects that the object matches the defined ru les.

Managing network objects using custom lists

With Enterprise Manager, you can view the following details for devices, nodes, pools, pool members,
and virtual servers (collectively called network objects) for every managed device in your network.
• Current connections
• Object name or lP address

• Object state (for nodes and pool members only)
• Object status
Using custom lists, you can narrow the type of object displayed, then select specific objects and change
the status for those objects without having to log in to each device individually.
Viewing network object details

When you have data collection enabled, you can view information about objects associated with managed
devices in your network from the Custom Lists screen.
Note: You can view only the objects for which you have administrative partition rights. For
information about administrative partitions, see the TMOS Management Guide for BIG-IP
Systems.
Modifying the status of a network object

When you have statistics enabled, you can enable, disable, or force offline, any network object without
having to log in to each associated device.
Note: You can modify the status of network objects only if you have administrative partition
rights to that object. For information about administrative partitions, see the TMOS Management
Guide for BIG-IP Systems.
Enterprise Manager Tasks

Managing user accounts
Administrators of Enterprise Manager devices manage two kinds of users:
• Users of Enterprise Manager itself
• Users of the devices that Enterprise Manager manages
Note: Be sure to keep the distinction between these two different classifications of users-EM
users and device users--clear.
User roles and authentication for Enterprise Manager

A user role specifies the type of management tasks that an Enterprise Manager user can perform on
managed devices in your network. Permissions for user roles are classified as either non-restricted or
restricted. The user roles are defined as:
• Administrator - This non-restricted role can perform all management functions available to
Enterprise Manager, including managing other user accounts and roles.

• Operator and AppLication Editor -By default, these restricted roles penOlUl fewer management
tasks than the Administrator. You can customize each role by specifying the tasks that the role is
allowed to penorm.
Users a re authenticated through Enterprise Manager's local database.
User role permissions and management tasks

There are eight different types of permissions that you can specifY for each restricted user role. You can
specifY any of these management task permissions to the Operator and Application Editor user roles.
Permission Management Task
Manage Device Configuration Archives Create and manage UCS archives for all managed
devices
Browse Device Configurations View configurations from the Enterprise Manager
configuration browser
Compare Device Configuration Archives Compare UCS configuration files between two
devices
Stage Changesets for Deployment from Published Create a new staged changeset from a published
Templates template
Deploy Staged Changesets Deploy a staged changeset created by a user
Administer Device Lists Manage device list members
Synchronize Device Configuration with Peer Synchronize peer device configurations
Failover Devices Initiate a failover to a peer managed device
About user accounts for managed devices

Managed BIG-IP systems contain accounts that specify the authorization (level of access) for users. When
you configure user account information on a BIG-lP system, you set parameter> such as user names and
passwords, shell access information, web intenace and root access privileges, and an authentication
source. You can use Enterprise Manager to view and copy account parameter> from managed devices to
other managed devices, as well as to modifY passwords.
Viewing user accounts for managed devices

You must first discover a device before Enterprise Manager displays its user account information . Using
Enterprise Manager, yo u can view all managed device use rs and their access privileges from one central
location. This eliminates the need to log on to each individual managed device for user account
information.
Replicating user account information for managed devices

Once you configure a user account on a BlG-IP system, and Enterprise Manager has discovered that
device, you can copy that configuration to other managed devices.
With the Copy User Access Configuration wizard, you can distribute a common user account
configuration, or specifIC elements of configuration data, simultaneously to multiple devices.
Changing user passwords for managed devices

Enterprise Manager increases the efficiency of managing user passwords by centralizing the password
change process for your devices. This saves you time, while ensuring that when you change a password,
the new password is the same for each selected device.
Managing licenses
Two of the more time-consuming tasks of managing multiple devices are renewing the device license on
cach device, or acquiring an initial license. Enterprise Manager provides automated features to expedite
the licensing process for all managed devices in the network.
Enterprise Manager automatically determines which devices need to be licensed and displays this
information on the Device List screen. You can then configure a task using the License Device wizard to
license or renew a license on as many devices as you need.
Licensing a device
Using the License Device wizard, you can select the devices that you want to license, view and accept the
End User License agreement (EULA) for each device (if required), and start a task that updates the
license on the devices you select.
The License Device wizard automates the entire licensing process. It retrieves the license dossier from the
managed device, sends it to the F5 Networks licensing server, acquires a new license from the server, and
provides you the opportunity to back up the device configuration before renewing the license.
Certificate monitoring
When you usc BIG-IP Local Traffic Manager to manage your SSL traffic, you must track both traffic and
system certificates for the devices in your network. Traffic certificates are server certificates that a device
uses for traffic management tasks. System certificates are the web certificates that allow client systems to
Jog into the 8IG-JP Configuration utility.
To assist you in overseeing these certificates, Enterprise Manager provides a summary of vital certificate
information for each managed device in your network. The information that displays on the certificate list
screen provides a summary of:
• Certificate expiration status
• Certificate and organization name
• Device on which the certificate is configured

When you monitor a device list, you automatically monitor all of the certificates on all of the devices that
are members of that device list. By default, certificate monitoring is enabled for all managed devices.
Changesets and Templates

Enterprise Manager offers two versatile options that you can use to simultaneously manage multiple
device configurations: templates and changesets.
• A template is a tool that you use to create and deploy new configurations based on an existing
device configuration. You use a template as a model, changing template variables to modify
elements that are specific to the new (targeted) device. For example, if you manage devices in
multiple data centers that reside in multiple time zones, you may want to create a template to set
the time zone on a device. To do this, create a template that sets the time zone, and make the time
zone setting a template variahle. Then, edit the allowed values for the variable to include all the
necessary times zones.

• A changeset is a collection of user-defined configuration data that you create and save for any
managed device in your network and distribute to other managed devices. For example, when you
configure a BIG-LP system, you typically specitY certain profiles, monitors, and iRules. To set up
these systems individually, you must keep track of each setting, and manually enter those values
for every new device that you add to the network. However, if YOll use changesets, you can
deploy the same profiles, monitors, and iRules configurations from one device to as many devices
as needed.
Temptates offer you the ability to set variables for different devices in the network, so you can use
templates in conjunction with change sets to help manage common network configuration tasks. Since
these options are somewhat inter-related, it helps to have a basic understanding of the elements associated
witb each.
Althougb changesets and templates each represent a collection of configuration files that you can use to
manage device configurations, they differ in three primary ways, as outlined in tbe following table.
Changesets Templates
Used to manage a single set of configuration Used to dep'loy configuration data to devices,
data. without changing any values of the configuration.
Used for a wide variety of tasks, including setting Used to manage elements of configuration data
up a device, maintaining consistent that vary from device to device.
configurations on multiple devices, and creating
new applications.
Used to stage a configuration that is customized Used primarily to stage individualized
for multiple devices, using device-specific configuration changes for multiple devices.
variables.
Creating a changeset
To create a change set, we recommend that you use tbe Changeset wizard, which automatically locates
dependencies for each network object included in the changeset. Additionally, tbe Changeset wizard
writes all of the syntax required to correctly classitY network objects and system settings in the cbangeset
configuration file . This process ensures that you can successfully deploy the cbangeset to otber managed
devices.
Creating a changeset using the Changeset wizard involves the following tasks :
5. Selecting a source
6. Reviewing dependencies for objects
Enterprise Manager stores changeset infomlation in text form, ensuring compatibility with configuration
files on a managed device. You can verify the compatibility of the changeset with managed devices in the
network, then deploy it to those devices. This gives you better control over device configurations in your
network.
By default., only Administrator-level users can create changesets. Administrators can delegate, to the
Operator or Application Editor roles, the ability to stage a changeset using published templates.
Using a device as a changeset source

When you select a managed device as the source for a cbangeset, you specitY the device and the partition
from which you wa nt to copy some or all ofilS device configuration. Administrative partitions are logical
containers witb a defmed set of BIG-IP system objects, and are used for access control purposes.

Using text as a changeset source

Creating a tex t-based changeset requires fewer steps in the wizard, however, the text mus t be accurate.
Unlike when you use a device or template as a source, Enterprise M anager does not automatically manage
dependencies and variable information when you use thi s option.
The text version of a changese t appears similar to what yo u may see in configuration files on a BIG-lP
system . However, when Enterprise Manager creates a changeset, it uses additional directi ves in the tex t to
control how the c hangeset is deployed to target devices.
Using a template as a changeset source

When you select a template as a changeset source, you can view the template and add new variables as
required. See our Enterprise Manager course for more information .
Publishing templates
When you create a custom template, it is available only for you to dep loy and use. To make the template
avai lable for others, you must publish it. Thi s adds an additional layer of control to device configuration
management when combined with the requirement that all staged changesets must be verified before they
are dep loyed.
Importing and exporting templates

Templates are a flexible method for changing device configurations. You can share templates among
Enterprise Manager devices in your network, or with other users through the F5 developer community
DevCentral (htlp:l/devcentral.f5.com) by importing and exporting them.
Finding and Viewing Configuration Objects

In F5 systems, objects are the most basic level of configuration. For example, th ere are three types of
objects in a Network module-Management Route objects, Profil e 11P1P Tun.nel objects, and VLAN
obj ects- and within the VLAN object type, there are two objects : external and internal. The text of those
external and internal objects describe th e configuration of those VLANs in human-readable form like this:
net vlan in te rnal
if-index 96
interfa ces (
1.1 ( }
tag 4094
These configuration details are saved in the UCS file of the ind ividual object and on Enterprise Manager
when you back up the configuration of a device.
Collecting, Viewing, and Storing Statistics

When statistics data collection is enabled, Enterprise Manager stores the following infornlation in its
statistics database for each managed device on which the Data Collection Agent is insta ll ed:
• Specifics about the managed devices, such as host name, IP address, and software version

• Details, such as object type and name, about any enabled network objects associated with a
managed device
• Perfonnance and health data for managed devices and associated network objects
You can use collected statistics to display standardized reports about the health and perfonnance of
managed devices in your network. This helps you identify any systems that are not performing at full
capacity and assists you in detennining when you should add new devices.
Enterprise Manager and iHealth

You can use BIG-IP iHealth to verify that the hardware and software for your managed devices is
operating properly and at peak efficiency. iHealth is a tool that collects data about elements of device
configuration, logs, command output, password security, license compliance, and so on. You can use the
iHealth diagnostics to identify any issues that require your attention.
When you create a task to gather iHealth diagnostics, Enterprise Manager captures a snapshot of the
specified device in the fonn of a qkview file. The iHealth service compares the device's infonnation to an
F5 database containing known issues, common configuration errors, and F5 published best practices.
Enterprise Manager then displays the results of this evaluation, which includes:
• Descriptions of configuration issues or code defects
• Recommended solutions
• Associated Iiok(s) to the AskF5 Knowlcdge Basc for reference
In many cases, you can use this customized diagnostic infonnation to resolve common confIguration
issues without contacting F5 Technical Support for help. If you do require assistance from F5 Technical
Support, this iHealth data can help F5 engineers provide you with a resolution more quickly.
Specifying credentials to access iHealth diagnostics service

To send iHealth data for diagnosis, you must have an AskF5 Knowledge Base user name and password,
which you can obtain at https:lllogin,f5,com/resource/registerEmail.jsp.
Creating an iHealth data collection schedule

Scheduling Enterprise Manager to perfonn a weekly data collection of iHealth diagnostics data ensurcs
that your managed devices are working at peak efficiency and you are apprised of any upcoming system
events.

Managing Archives from Enterprise Manager

The configuration details of managed devices (including Enterprise Manager™ itself) are contained in a
compressed user configuration set (UCS) file with the extension of .ucs. This fil e contains all of the
information required to restore a device's configuration, and consists of these elements:
• System-specific configuration f,les
• License
• User account and password information
• DNS zo ne files
• NameSurfer configuration
• SSL certificates and keys
Enterprise Manager saves UCS files to a UCS archive. You can create a task to save UCS archives for
devices at regularly scheduled intervals. Archives that are created and saved on a schedule are called,
rotati ng archives. When the system creates rotating archives, it compares the most recently stored UCS
archive file to the current configuration on the device at the specified interval. If there are any differences,
Enterprise Manager stores a copy of the current configuration in a UCS archive. If there are no
differences, Enterprise Manager does not store an additional copy oftbe current configuration, which
leaves you room to store a higher number of unique historical UCS archives. When Enterprise Manage r
reaches the maximum number of archives specified to store, it deletes the oldest archive in the rotating
arch.ive list By default, Enterprise Manager stores up to 10 rotating archives each, for itself and every
managed device.
Another option for archive storage is to create an archive of a specific UCS for a device, referred to as a
pinning an archive. Enterprise Manager also creates a pinned archive of a device's current configuration
before it installs new software. Pinned archives are stored until you delete them.
Creating a rotating UCS archive schedule

A device must be listed on the Device List screen before you can create a rotating archive schedule for it
It is best practice to create a rotating archive schedule for each device in your network so that you always
have a copy of a recent configu ration. The UCS archive provides your network with added stabili ty in the
event that a configuration change results in a need for a system restore. You can create a customized
schedule for a specific device, or create several schedules and assign any number of devices to each
schedule.
• Access to an Enterprise Manager VE and at least one LTM VE

Chapter 11 - Administering the BIG-IP System 11-1
Chapter 11: Administering the BIG-IP System

Chapter Objectives
• Understand some of the other network configuration options available on the BIG-IP system
• Restrict administrative access to BIG-IP
• Restrict client traffic through BIG-IP
• Set administrative partitions and user roles
High Availability Concepts
Lesson Objectives
At the end of this lesson, you should be able to articulate the differences in high availability features
between BIG-IP version 10 and version I I.
High Availability and BIG-IP v10

Your choice of redundant systems configuration can have significant impact on operations and ongoing
BIG-IP management. In BIG-IP vlO, only two redundant configurations were supported:
• Active/Standby
• Active/Active
In both cases, two BIG-IP devices (and only two devices) were paired in the redundant configuration. In
the more commonly-used Active/Standby redundant configuration, one system is in an active state,
hosting all the virtual servers, SNATs, NATs, and floating addresses, while the other system is in a
standby state, hosting only its own non-floating addresses. There is no default state for either system;
both systems may assume either the active or standby role, as needed. The Active/Standby configuration
gives a site true redundancy by providing an environment for staging changes, a method for upgrading the
systems without service interruption, and a means for continuous operation in the event of a critical
failure on the active device.
The Active/Standby configuration has its drawbacks though, especially for large sites with many
configured redundant BIG-IP pairs. At any time, 50% of the BIG-IP devices in the network are idle and
not processing network traffiC.
In BIG-IP vlO, you can also configure two BIG-IP devices in an Active/Active redundant configuration.
In an Active/Active configuration, both systems are active but each hosts different virtual servers,
SNA Ts, NATs, and floating addresses. Each of these configuration objects includes a setting that
determines which BIG-IP device it is hosted on. For example, you can configure BIGIPI to process traffic
for virtual addresses A and Band BIG-IP2 to process traffic for virtual servers C and D. If BIGIPI
becomes unavailable, the traffic for virtual addresses A and B is picked up by BIGIP2, which then
logically acts as both BIGIPI and BIGIP2.
Although the Active/Active configuration enables traffic to [Jow through both devices in the pair
simultaneously, it has drawbacks. The typical reason sites implement an Active/Active configuration is to
increase total throughput (i.e. to avoid all those idle devices in Active/Standby). Yet, in an Active/Active

11-2 Chapter 11 - Administering the BIG-IP System
configuration, the load on each BIG-LP system had to be kept at or below 50% so that each device can
process all the workload in the event of a failure. In effect, this still renders 50% of your total BIG-IP
resources unusable.
An Active/Active configuration also cannot be used to distribute a large traffic load associated with a
single virtual server or a group of virtual servers using the same lP address.
Your servers' response path also needs to be considered when configuring an Active/Active pair in v I O. If
using a routed method, each server's default route should be the internal floating IP address of the BIG-IP
device from which that it receives traffic. In an Active/Active configuration, each BIG-IP device has its
own internal floating IP. The net effect is that a server then becomes associated withjust one of the BIG
IPs in the pair. (A SNAT could be used to negate this problem.)
Finally, conversion from Active/Standby to Active/Active (or vice-versa) requires sigoificant planning
and execution. It pays to consider all of the points described above prior to deploying one confIguration or
another.
Device Service Clustering and BIG-IP v11

BIG-IP version II introduces sigoificant improvements to high availability, with the ability to connect
more than just two devices in a redundant systems configuration. Called Device Service Clustering,
many options are possible because as many as eight BIG-LP devices can now be configured for high
availability. The old "Active/Standby" and "Active/Active" are still supported but can be extended into
larger configurations. For example, you can configure up to eight BIG-IP systems in a failover device
group, and use virtually any combination of Active and Standby systems to support traffic processing.
o o o o
trafflc-group-l tr Mfic-grou p-l

(active) (standby)
• Active • Standby
Device Group
Figure .,: BIG-IP v11 introd~d many new features and options for high availability, as well as many new Isrms
including traffic group and de vice group

To support these larger device groups, BIG-LP v II introduces many new features and options, including
some new configuration components described in the table below and shown in Figure 2:
Configuration Description
Component
Device A device is a physical or virtu a! BIG-IP system, as well as a member of a local trust
domain and a device group. Each device member has a set of unique identification
properties that the BIG-IP system generates.
Device group A device group is a collection of BIG-IP devices that trust each other and can
synchronize, and sometimes fail over, their BIG-IP configuration data. A "device" can
include a physical device or a virtual representation of a device, including a vCMP
instance. (See CMP and vCMP later in this chapter.)
Traffic group A traffic group is a collection of related configuration objects (such as floating self IP
addresses, virtual addresses, and SNAT addresses) that run on a BIG-IP device and
process a particular type of application traffic. When a BIG-IP device becomes
unavailable, a traffic group can float - that is, fail over - to another device in the device
group to ensure that application traffic continues to be processed with little to no
perceived interruption in service.
Device trust and Before BIG-IP devices on a local network can synchronize configuration data or fail
trust domains over, they must establish a trust relationship known as device trust. A trust domain
is a collection of BIG-IP devices that trust one another and can therefore synchronize
and fail over their BIG-IP configuration data, as well as exchange status and failover
messages on a regular basis. A local trust domain is a trust domain that includes the
local device-that is, the device you are currently logged in to.
Device Trust
..... - . . .... -. ..... -. . .... - .
..... -. . .... -. .....

Device Group
- . . .... - .
..... - . ..... -.
Device Group
Figure 2: Device Service Clustering (OSe) Introduced new features and associated terminology, including device
trust, sync-faifover and sync-only device groups, and traffic groups.
Note: More information on Device Service Clustering (High Availability) is available in FS's
Configuring Local Traffic Manager (L TM) course.

Always On Management (AOM)

AOM is dedicated, separate subsystem on the BlG-JP hardware platform that provides lights out
management and other supporting functions for the BlG-JP systems. (It's actually an embedded Linux
system.) The 11000 family, 8900, 6900, 3600, and 1600 BIG-IPs all have the AOM chip.
Note: AOM is not available on BIG-IP Virtual Editions

.~~==~~----------------------
AOM allows you to manage the BIG-JP system using SSI-I or the serial console, even if the host
subsystem is turned off. The BIG-IP host subsystem and the AOM subsystem operate independently. If
the AOM is reset or fails, the BlG-lP host subsystem continues operation, and there is no interruption to
load-balanced traffic. Likewise, if the BlG-IP host subsystem locks up, you can use the AOM Command
Menu to reset it, power it on or ofl", or restart it.
AOM is always powered on when power is supplied to BlG-lP; it cannot be turned olI
Accessing the AOM Command Menu

Accessing AOM using the serial console
From a console session with the BlG-JP system, you can access the AOM Command Menu to manage the
system and to configure it for access from a network connection. This is an F5 best practice and should
be done as a part of any initial BIG-IP device installation.
To access the menu on an English-language keyboard, press:
B 0 then (on US keyboards, Shlft+9 together) within 3 seconds ofpressmg Escape
The AOM menu looks something like this:

1 Connect to Host subsystem console
2 Reboot Host subsystem (sends reboot command)
3 Reset Host subsystem (issues hardware reset--USE WITH CARE!)
4 Reset AOM subsystem (issues hardware reset--USE WITH CARE!)
5 Power off Host subsystem (issues hardware shutdown--USE WITH CARE!)
B AOM baud rate configura tor
L AOM subsystem login
N AOM network configura tor
P --- AOM platform information
Accessing AOM using SSH over a network connection

Before you can directly access the AOM over the network using SSH, you must configure an lP address
for the AOM. This can be done by connecting to the AOM using a serial console and running option N -
AOM network configurator. (See SOL9608: Configuring the AOMso that it can be accessed over the
network). The AOM lP address must be different from the BIG-lP management address, but on the same
IP subnet as it will be accessed through the management port.
Once configured, you can access the AOM using SSH by following the instructions in SOL9403:
Overview ofthe Always-On Management subsystem.

Expandi_ng Network Configuration Options

Lesson Objectives
• Describe the relationship between interfaces, VLANs, and self IP addresses
• Describe trunks and tagging in F5 tenns
Interfaces
The interfaces on the BIG-IP system are the physical ports that connect the BIG-lP system to other
devices on the network, such as routers, hubs, switches, destination servers, etc. Through its interfaces,
the BIG-lP system can forward traffic to or from other networks.
There are two types of interfaces - a management interface and TMM switch interfaces. While the
management interface handles administrative traffic to and from the BIG-IP device, application traffic is
handIed via the TMM switch interfaces. The TMM switch interfaces are most often referred to simply as
interfaces.
Note: Throughout the remainder of this course, the term interface will be generically used to
refer to the TMM switch interfaces - the physical ports on the BIG-IP system on which
application traffic is handled. When referring to the management interface, we will use the terms
management interface, management port, or MGMT.
Every BIG-lP system includes multiple interfaces. The exact number of interfaces depends on the
platform type. For example, the BIG-lP 4200v (see Figure 3) includes eight (8) Gigabit Ethernet CU
ports and two (2) optional IO Gigabit Fiber ports (SFP+), while the 1600 contains four (4) Gigabit
Ethernet CU and two (2) optional Gigabit Fiber ports.
Interface names
By convention, the names of the interfaces use the format s.p where s is the slot number of the network
interface card (NIC) and p is the port number on the NIC. For example, the interface at slot l/port I is
named 1.1; slot l/port 2 is named 1.2; slot 2/port 3 is named 2.3, etc.
Note: Interface names are explicitly assigned and cannot be changed.

Figure 3: BIG-IP 4200v inter/aces
Interface properties
Each interface has unique properties, such as a MAC address, media speed, duplex mode, and support for
Link Laye r Discovery Protocol (LLDP).
Some of these properties can be modified; others cannot. All can be viewed to help you assess the way
that a particular interface is forwarding traffic. For example, you can view interface properties to
determine the specific virtual LANs (VLANs) for which an interface is currently forwarding traffic, and
determine the speed at which it is currently operating.
Interfaces and their relationship to VLANs

The traffic that an interface handles depends on its virtual LAN assignment. Interfaces are assigned to
VLANs through VLAN definitions on the BIG-LP system. Depending on the way these assignments are
made, traffic that flows through the interface may be tagged or untagged. (See VLAN intelface
assignment later in this lesson.)
I nterface state
When an interface is enabled, it can accept both ingress and egress traffic; when it is disabled, it cannot
accept any traffic.
Trunking
A truok is a logical grouping of interfaces on the BIG-LP system that functions as a single interface. The
BIG-IP syste m uses a trunk to distribute traffic across multiple links, in a process known as link
aggregation . Link aggregation increases the bandwidth of a link by adding the bandwidth of multiple
links together. For example, when aggregated, four fast Ethernet (100 Mbps) links create a single 400
Mbps link.
You can aggregate a max imum of eight links in a single trunk. For optimal performance, you should
aggregate links in powers of two (e.g. two, four, or eight links).
You can use trunks to transmit traffic from a BIG-IP system to another vendor switch. Two systems that
usc trunks to exchange traffic are known as peer systems.
There are several benefits that come with using trunks:
• Increase bandwidth without upgrading hardware
• Provide link failover if a member link becomes unavailable

How do trunks work?

In a typical trunk configuration, the member links (interfaces) are connected through Ethernet to
corresponding links on a peer system. Figure 4 shows an example of a typical trunk configuration with
two peers and three member links on each peer.
BIG-IP Trunk Switch

Interface 1.1
...... . Interface 1.2

Interface 1.3
Interface 1.4
Figura 4. Trtmking (fink aggreg ation) can be used on the BfG- /P system to increase bandwidth without upgrading
hardwaro. and to provide link fai/over if a mamber 'lnk becomes unavailable.
A primary goal of the trunks feature is to ensure that frames exchanged between peer systems are never
sent out of order or duplicated on the receiving end. The BIG-IP system is able to maintain frame order by
using the source and destination addresses in eacb frame to calculate a hash value, and then transmitting
all frames with that hash value on the same member linIe
The BIG-IP system automatically assigns a unique MAC address to a trunk. However, by default, the
MAC address that the system uses as the source and destination address for frames that the system
transmits and receives (respectively), is the MAC address of the lowest-numbered interface of the trunk.
The BIG-IP system also uses the lowest-numbered interface of a trunk as a reference link. The BIG-IP
system uses the reference link to take certain aggregation actions, such as implementing the automatic
link selection policy. For frames corning into the reference link, the BIG-IP system load balances the
frames across all member links that the BIG-iP system knows to be available. For frames going from any
link in tbe trunk to a destination host, the BIG-IP system treats those frames as if they carne from the
reference link.
Finally, the BIG-IP system uses the MAC address of an individual member link as the source address for
any LACP control frames.
Overview of LACP
A key aspect of trunks is Link Aggregation Control Protocol, or LACP. Defined by IEEE standard
802.3ad, LACP is a protocol that detects error conditions on member links and redistributes traffic to
other member links, tbus preventing any loss of traffic on the failed link. On a BlG-1P system, LACP is
an optional feature that you can configure.
You can also customize LACP behavior. For example, you can specify the way that LACP communicates
its control messages from the BIG-IP system to a peer system. You can also specify the rate at which the
peer system sends LACP packets to the BIG-IP system. If you want to affect the way that tbe BIG-IP
system chooses links for link aggregation, you can specify a link control policy.

Configuring trunking
Trunks can be configured on the BIG-IP system using eitber the Configuration utility (see Figure 5) or
using tmsh.
Configuration
Name seattle
Members' Available:
1.1 I _ 2.1
Interfaces 1.2
1.3
B 2.2
1.4 EI
I--
Link Selection Policy

,Auto
Frame Distribution Hash Source/Destination IP address port ~
I Cancel II Repeat II Finished J

Figure 5: Example of creating a trunk using the Configuration utility
On the Interfaces setting, you specifY the interfaces that you want the BIG-lP system to use as mcmber
links for the trunk. Once you have created the trunk, the BIG-lP system uses these interfaces to perform
link aggregation.
Tip: To optimize bandwidth utilization, F5 recommends that, if possible, the number of links in
the trunk be a power of 2 (for example, 2, 4, or 8).
The BIG-IP system uses the lowest-numbered interface as the reference link to negotiate links for
aggregation.
The interfaces that you specifY for the trunk must operate at the same media speed, and must be set at
full-duplex mode. Otherwise, the BIG-lP system cannot aggregate the links.
Any interface that you assign to a trunk must be an untagged interface. Also, you can assign an interface
only to one trunk. Because of these restrictions, the only interfaces that appear in the Interfaces list in the
Configuration utility are untagged interfaces that are not assigned to another trunk. Before creating a
trunk and assigning any interfaces to it, you should verifY that each interface for the trunk is an untagged
interface.
After creating the trunk, you can assign it to one or more VLANs, using the same VLAN screen that you
normally use to assign an individual interface to a VLAN. The trunk name will appear in the list of
available interfaces.
If you are using one of the spanning tree protocols (STP, RSTP, or MSTP), the BIG-lP system sends and
receives spanning tree protocol packets on a trunk, rather than on individual member links. Likewise, use
of a spanning tree protocol to enable or disable learning or forwarding on a trunk operates on all member
links together, as a single unit.

Virtual LANs (VLANs) and Self IPs

Introducing virtual LANs (VLANs)
A virtual LAN or VLAN is a way of logically partitioning a physical network so that distinct broadcast
domains are created. Grouping hosts with a common set of requirements together in a VLAN - regardless
of their physical location - offers distinct advantages, including:
• Reducing the size of broadcast domains, thereby enhancing overall network performance
• Significantly reducing system and network maintenance tasks (functionally-related hosts no
longer need to physically reside together to achieve optimal network performance)
• Enhance network security by segmenting hosts that transm it sensitive data
VLANs on a BIG-IP system

The BIG-lP system is a port-based switch that provides multilayer processing capabilities. These
capabilities support standard VLAN behavior by offering the following features:
• Interfaces on the BIG-lP system can be associated directly with VLANs (one interface with one
VLAN, multiple interfaces with a single VLAN or a single interface with multiple VLANs).
• The BIG-IP system can process traffic between VLANs eliminating the need for physical routers.
• The BIG-IP system can be incorporated directly into an existing, multi-vendor switcbed
environment, as it supports the LEEE 802.1q VLAN standard.
• Two or more VLANs can be combi ned into a BIG-lP object called a VLAN group. A host in one
VLAN can communicate with a host in another VLAN using a combination of Layer 2
forwarding and IP routing, offering both performance and reliability benefits.
Introducing self IPs

A self lP is an JP addresslnetillask combination on the BIG-JP system that you associate with a VLAN to
allow the BIG-lP system to access hosts in that VLAN. By virtue of its netrnask, a self I.P represents an
address space - that is a range o f lP addresses spanning the hosts in a VLAN, rather than a single host
address. You associate a sel flP address with a VLAN to create a distinct broadcast domain - a logical
subset of a physical network that is independent of the physical network topology .
Self lP addresses serve two purposes:
• First, when sending a message to a destination server, the BIG-IP system uses the self IP
addresses of its VLANs to determine the specific VLAN in which thc destination server resides.
For example, ifVLAN internal has a self lP address of 172.16.1.31 with a netrnask of
255.255.0.0, and the destination server's IP address is 172.16.20.1, the BIG-IP system recognizes
that the server's lP address falls within the range of V LAN internal' s self lP address, and
therefore sends the message to that VLAN. More specifically, the BIG-IP system sends the
message to the interface that is assigned to that VLAN. If more than one interface is assigned to
the V LAN, the BIG-IP system takes additional steps to determine the correct interface, such as
checking the Layer 2 forwarding table.
• Second, a self lP address can serve as the default route for each destination server in the
corresponding VLAN.ln this case, the selflP address ofa VLAN appears as the destination IP
address in the packet header when the server sends a response to the BIG-IP system.

Types of self IP addresses

There are two types of self lP addresses that you can create on the BtG-IP system:
• A non-floating self IP address is au lP address that the BIG-IP system does not share with
another BIG-IP system. This type ofselflP is sometimes referred to as a static address in F5's
documentation.
• A floating self IP address is ao lP address that two or more BIG-lP systems share when
configured for failover.
You can tell if a self lP is floating or non-floating by examining the Traffic Group it belongs to. Non
floating self IP addresses always belong to the traffic group named traffic-group-Iocal-only.
Note: A self IP address can be in either IPv4 or IPv6 format.
ASSigning a self IP address to a VLAN

When you creale a new self lP address on the BIG-lP system, you must associate it with an existing
VLAN. As such , the VLAN definition must be created first.
The network (range of addresses) defined by the IP addresslnetrnask combination on a new self lP entry
must not overlap with other existing VLANs on the BIG-LP system. For example, if 10.10.2.31/16 is
associated with "vlan-a," you could not create a self lP for the address space 10. I 0.10.31 / 16 and associate
it with "vlan-b," as these represent overlapping networks.
Note: A single VLAN can be assigned multiple s to create a logical broadcast domain that is
independent of physical network topology.

Chapter 11 - Administering the BIG-IP System 11 - 11
VLAN interface assignment

A VLAN's interface assignments indirectly control the hosts to and from which the BIG-lP system
interface sends and receives messages. The ratio orVLANs to interfaces can vary, as shown in Figure 6.
~H Hf+H - f5
e:
I
I I
I
I
c I
I I I I
L_ l_.
,-----,
I I
I I
I A I
~ Hf+.H-1 - f5
I e I
I I
1__ ..I
Figure 6: Examples of VLAN inlerface assignment: (lop) 1 VLAN 10 1 inlerface; (second) 1 VLAN 10 multiple
interfaces; (third) multiple VLANs 10 1 inlerface; (bollom) mix and malch
Tagged (802.1q format) vs. port-based (untagged) access

IEEE 802. 1q is the networking standard that supports VLANs on an Ethernet network. T he standard
defines a system of V LAN tagging for Ethernet fi'ames and the accompanying procedures to be used by
bridges and switches in handling such frames. The BIG-IP system supports two methods for sending and
receiving VLAN traffic through a n interface: tagged (802. lq format) and port-based (uotagged). The
method used is determined by the wayan interface is assigned to a VLAN.

On the BIG-IP system, a VLAN is always assigned a unique tag (a.k.a. VLAN JD) at the time the VLAN
is created, as shown in Figure 7. If yo u do not explicitly assign a tag to the VLAN. the BIG-IP system
wi ll assign one automatically. starting with 4094 and working backward toward I.
General Properties
Name external
Description
Tag 4093
Resources
Untagged Available Tagged
Interfaces
EJ [
1 -~ I B ~J'
B ~ EJ I
Figure 7: t xample of assigning a tagged interface to a VLAN
You a lso typically assign one or more interfaces to a VLAN at the time the VLAN is created. An interface
is assigned as either Tagged or Untagged. VLAN tramc that passes through an associated tagged
interface will have the VLAN ill added to the frame header. In doing so. each frame becomes
distinguishable as being within exactly one VLAN. If the interface is assigned as untagged. frames sen t
through the interface for that VLAN will not contain a tag fIeld in the header.
Whenever a packet with a tag in the header comes into a BlG-lP interface. the interface reads the tag and
compares itto the tag associated with each VLAN assigned to that interface. If the tag in the packet
matches a VLAN tag. the packet is accepted for that VLAN. lf the tag does no t match any V LAN tags.
the packet is rejected . If the packet has no tag in the header and there is a VLAN with that interface
assigned as untagged, the packet will be accepted for that VLAN only.
Note: If a single interface is handling traffic for multiple VLANs (i.e. multiple VLANS : 1
interface). only one of the VLANs can have the interface assigned to it as untagged. The other
VLANs must have the interface assigned as tagged . so that the BIG-IP system can determine
which VLAN the traffic belongs to.

Your BIG-IP lab environment in this class

Perhaps the best way to understand how VLANs, tags, and interfaces are all interconnected is to re
examine your BIG-IP lab configuration as you are using it in this class.
Application
Administrators Users Servers
Interface 1.1 Interface 1.2

192.168/16 network
VLAN I VLAN I
I external I I
I
internal I
I
:
i 10.10/16 Ii I
I 172 .16/16
I__ !l~~.d<__ ,
I
:
BIG-IP L_ !lel~Z__ 1
Figure 8. Your classroom lab envlromnenl
As shown in Figure 8, your BIG·JP lab environment in class has two VLANs - one named external and
the other named internal (although their names could have just as easily been something completely
different). VLAN internal is assigned tbe non-floating address 172.16.X.31 (where "X" is your
classroom station number) and its netmask is 255.255.0.0 (or 16) indicating that it participates in a virtual
LAN that logically encompasses the network address space consisting of IP addresses beginning with the
two octets 172.16. Likewise, VLAN external encompasses an address space consisting of IP addresses
beginning with the two octets 10.10.
Your PC workstation is configured with the IP address 192.168.X.30 so that it can participate in the
network that includes the BIG·IP management interface· whose IP address is 192.168.X.3 1/24. Your
PC workstation is also configured with IP address 10.IO.X.30 and connected to the network that is
plugged into interface 1.1, so it is logically part of VLAN external.
The servers that contain the web applications you will be accessing have the IP addresses 172. 16.20.1 ,
J 72.16.20.2, and 172.16.20.3. They are logically part of VLAN internal.
Interface 1.1 is the only interface assigned to VLAN external, and it is assigned as an untagged
resource. This means that all traffic pertaining to VLAN internal will flow through the physical port
configured at interface 1.1, and the packet headers will not include a tag.
Interface 1.2 is the only interface assigned to VLAN internal, and it, too, is assigned as an untagged
resource. This means that all traffic pertaining tn VLAN external will flow through the physical port
configured at interface 1.2, and the packet headers will not include a tag.
Administering BIG-IP v11 11·13

Restricting Traffic on the BIG-IP System
Lesson Objectives
• Restrict administrative access to the BIG-IP system using port lockdown, SSH restrictions, and
packet filters
• Restrict client traffic through tbe BIG-IP system using packet fLlters and virtual server settings
Restricting Access to a Virtual Server

As mentioned earlier in tbis course, a virtual server is a listener object on tbe BIG-IP system that listens
for and processes traffic whose des tination matches tbe lP address and port of the virtual server. By
default, a virtual server is enabled on all VLANs, meaning it accepts incoming (ingress) client traffic from
all networks defined by all tbe VLANs on tbe BIG-IP system, as illustrated in Figure 9.
o
DGliUnalio n
o
Destination
10.10.1.100:80 10.10.1.100:80
r-- ---
BIG-IP
-- · ·---r-----~------:-:~ -----~-----: . 1
: external :: internal :
I 10.10. 1.31 /16 I I 172.1 6.1 .31/16 I
I I I I
l _____ _____) l__________)
~
Virtual Server 10.10. 1 . 100:60

Enabled on all VLANs ~
11
Figure 9: By default, a virtual server listens for incoming traffic on aI/ VLANs
In some cases though, you might want to limit the networks that can reach a particular virtual server. T o
do so, you adjust the VLANs the virtual server is listening on by eithe r:
• Enabling tbe virtual servers on the networks (VLANs) where you want to receive traffic
• Disabling the virtual servers on the networks (VLANs) where you don 't want to receive traffic
Figure 10 shows the virtual server at 10.10.1.100:80 enabled on VLAN internal. Incoming traffic 00 the
10.10116 network destined for this virtual server will be accepted; incoming traffic on the 172.16/16
network destined for tbis virtual server may not be accepted. It depeods on whether or not there is another
listener configured that can process the traffic.

o
Destination
o
DesUnalion
10.10.1.100:80 10.10.1.100:80
t --·--"-II-o-----~I-'r ..--- ---- ,

BIG-IP
I I I I
I external I I I
: 10 .10.1.31/16 :: 6:
l ____ _ _____
I ~
I I l __ _________)I
v.r\lJaI Serwr
10.10.1 100:80
Enlblad on
VLAH exllmll
Figurv 10: Vlr/ual server 10. 10. 1. 100:80 is enabled only on VLAN ex/ernal. Incoming traffic on th o 10. 10/16 network
to this virtual server will be accepted; incoming traffic on the 172.16116 network to this virtual server may not. In fhis
particular case, the same net effect can be achieved by disabling the virtual server on VLAN internal.
Configuring where a virtual server is listening

To limit the VLANs a virtual server is listening on, use the VLAN and Tunnel Traffic setting on the
virtual server definitio n, as shown in Figure I J.
General Properties
N....
Type : Host Networ1c
Oesllnlilon
Address: 10.10.4.100 __ J
Sorvtco Po~
L~~ __ ' HT~
AvoNobll1ty
I Ava~a~. (Enllbled) K The virtual server Is avlJMable
Conftgurauon: Basic
VL.AN and Tunnel Trame Enabled on ..•
Selected Available
ICommon ICommon
Internal
VLANs end Tum.ls
1
Figure 11: In this example, virtual server vs_http is configured to listen exclusively on VLAN external

Securing Administrative Access to the BIG-IP System

Depending on your requirements for securing network systems to meet organizational security policies
and industry standards such as PCI compliance, you may want to restrict the amount and types of
administrative access available to the BlG-IP system. Several access control features are available for you
to configure on the BIG-IP system, and a host of best practices and solutions documentation will help
guide your efforts. At the very least, you should consider policies that address the fo llowing:
• Network access management
• User and password management
Restricting Administrative Access with Port Lockdown

Port lockdown secures the BIG-JP system from unwanted connection attempts by controlling the level of
access to each selflP address defined on the system. Each port lockdown list setti ng speci fies the
protocols and services from which a self LP can accept connections. BIG-IP refuses traffic and
connections made to a service or protocol port that is not in the list, with certain exceptions. (See
SOLl3250: Oven,iew ofport lockdown behavior (IO.x-1 l.x) for more infonnation.)
By default, the BIG-IP system allows access to only a limited set of the available ports, and the default set
includes those ports requi red for administrative access and inter-device communication, such as in a high
availability configuration.
While some ports may need to be open to ensure a properly functioning configuration, access to these
ports cao be further controlled by the use of packet fIlters. Packet filters allow you to control access
based on combinations of criteria including source IP address, destination JP address, MAC address, etc.,
and are presented in more detai.i later in this chapter.
Port lockdown settings

Five port lockdown settings are available:
Allow All Allow None Allow Default Allow Custom Allow Custom
(Include
Defaun)
All traffic No traffic ·OSP F Your list (e.g. Your list, plus
permitted permitted • DNS (port 53) 1 port 443 only) defaults
• F5-iQuery (port 4353) 1
• HTIPS (port 443) 2
• SNMP (port 161) 1
• SSH (port 22) 2
• RIP (port 520) 3
• Network ~ilover (port 1026) 3
1 rcp and UDP; 2 rcp only; 3 UDP only

Port lockdown exceptions

• TCP port 1028: In a redundant pair configuration, the system altows tcp: 1028 for connection and
persistence mirroring, regardl ess of the port lockdown settings.
• TCP port 4353: When BIG-lP 11.0.0 and later devices are configured in a synchronization
group, peer devices communicate using Centralized Management Infrastructure (CMI) on
tcp:4353, regardless of the port lockdown settings.
Note: CMI uses the same port as F5-iQuery, but is independent of iQuery and the port
configuration options available for the port.
• lCMP: ICMP traffic to sel f lP addresses is not affected by the port lockdown list, and is
implicitly allowed in all cases.
Note: In most cases, it is not possible to ping self IP addresses across VLANs . For more
information, refer to SOL3475: The BIG-IP system may not respond to ICMP ping requests for a
self IP address.
Note: Do not specify port 1028 explicitly in an "Allow Custom " list as it can generate an error.
See SOL 12932: The BIG-IP system resets state mirror connections when port 1028 is
configured in the Self IP Port Lockdown list.
Configuring port lockdown

Port lockdown can be configured:
• During initial BIG-IP setup using the Setup utility
• Any time after initial setu p using the Configuration utility, as shown in Figure 12
• Any time after initial setup using tmsh
When running the Setup utility, if the Standard Network Configuration option is selected, the port
lockdown settings for the self lP addresses on VLAN external specify Allow 443 , resulting in a fini shed
configuration setting of Allow Custom with only port 443 on the list. This facilitates administrati ve
access to the BIG-IP system using the external VLAN network.
The default port lockdown setting on V L AN internal's selflP addresses is Allow Default.

Configuration
Name 10.10.4.31
IP Address 10.10.4.31
Netmask I 255.255.0.0 1
VLAN I Tunnel Lexternal 21
Port Lockdown IAllow Custom v
UDP Protocol :
All None • Port: (Addl

I
TCP UDP Protocol
I Custom List 443
Figure 12: Configuring Port Loekdown on one of Ihe BIG-IP system's seil lP addresses. In Ihis example, only port 443
(Mps) Iraffle will be permitted 10 Ihe self IP address 10.10.4.3.

Restricting SSH Access with Platform Configuration

BIG-lP prov·ides a number of "ccess control mechanisms to m"intain secure access to the BIG-IP system.
These include" hierarchy of user accounts and access privileges, password enforcement options, and
support for various authentication technologies. You are familiar witb two of these accounts already
root and admin - and have been using them without any additional access controls throughout the class.
User Administration
password: I ·· ..•.... ·
Root Account
Confirm :
1
password: E .. ]
Admin Account
Conftrm: l::::..
'-----------'
]
SSHAcc8SS Enabled
SSHIP Anow ' Specify Range... :::l 192.16S.4.'10 .10.4124
I Update I
Figure 13. Restricting administrative SSH tra ffic to the BfG-/P sys tem. In this example, only clients in the
192.168.4124 and 10.10.4/24 networks will be permitted administrative access to the BfG-fP system using SSH.
Address ranges can be specified using several methods including wildcard (*) or netmask. This setting does not
impact application SSH traffic. only administrative SSH traffic (i.e. SSH connections to the management interface or
to the self IP addresses) .
Limiting SSH access

The root and admin users are initially configured during BIG-IP setup, typically with the Setup utility.
They both can be maintained after setup: the admin user from the System» Users screen; the root user
from the System» Platform screen; or both using the command line interface.
These accounts cannot be deleted, and their roles cannot be changed, although administrative access via
SSH can be restricted for these - and all other BlG-IP administrative users - by an IP address or range of
addresses, as shown in Figure 13. In this example, two IP ranges are provided for the SSH lP AUow
string and are separated by a space. The 192.168.4. * wildcard range implies the 192.168.4/24 network.
Important: Separate the IP addresses in the SSH IP Allow range with a space. If you separate
the IP addresses with a comma, a non-working entry will be recorded in the BIG-IP
configuration file , potentially preventing you from reconnecting to the network through SSH . For
more information, see SOL5380: Specifying allowable IP ranges for SSH access.

The SSH lP Allow setting is stored in a dynamically created run-time configuration file named
/var/run/conlig/hosts.allow. This is an auto-generated file and should not be edi ted. Instead, limit SSH
access using the Configuration utility or tmsh.
Running BIG-IP Hardware in Appliance Mode

Beginning with the release of BIG-lP I O.2.I-HP3, BIG-lP systems can be configured to run in Appliance
Mode. Appliance mode is designed to meet the needs of customers in industries wi th especially sensitive
data, such as government, healthcare, and fman cial services, by limiting BlG-IP system administrative
access to match thaI of a rypical network appliance rather than a multi-user UNIX device. Appliance
mode " hardens" BlG-lP devices by removing advanced shell (bash) and root user access. Administrative
access is available through the TMOS Shell (tmsh) command line interface and the GUI.
Once Appliance mode has been enabled, it cannot be disabled without obtaining a new license and
performing a clean installation of the software. Administrators can ve rify thaI a device is running in
Appl iance mode from the Configuration utility by na vigating to System » License. The entry App Mode
(TMSH Onty, No Root/ Bash) will appear in the Active Modules area, as shown in Figure J 4.
Technical restrictions in appliance mode

• No access 10 the bash
sheJi
• Administrative access is
limiled to Ihe
Configuration utility and
tmsh F5 Internal Produ d Deyelopment
• The root user cannot log Licensed Date Sop 10.2012
in 10 Ihe BlG-IP device by

lic~nse pu-abon Oate Fob 2. 2013
any means, including the
serial console
• LTIJ. Base (C859992·9723294)
." SWbps
• On platforms thaI include
No R O<)t~!3 s h)
Ihe Always-On • NlP
Management (AOM)
• Ciient AuUlentiCation
subsystem, AOM cannot • comptesSIOII fX 1t.IBPS)
access the host and is only • ONSSeMetl
• EA FeabJrH
able to reset the host using • Global TtaliC !IAn-O.' UO<lIIe
a hardwa re reset • 1PY6 Gatewa1
• Ul\k ConlrOlttf
command. (More on OpIIo"'" UO<lu'•• IASI.I
AOM later in tb is course.) • Ram Cache
• On VlPRION platforms, Figure 14: BIG-IP device running in Appliance Mode

SSH access between
blades is restricted. You can SSH only to the management lP address of each blade.
Note For more information on running the BIG-IP system in Appliance mode , see SOL 12815:
Overview of Appliance mode.
11-20 Admin istering BIG-IP v11

Restricting Traffic with Packet Filters

Packet filters enhance network security by specifYing
"'1_ ,11 .. " ' '. .,
.
whether a BIG-IP system interface should accept or reject
incoming traffic based on certain criteria, such as:
o·
-GWI ...
Pf~r1IeI
• The source lP address of a packet P3(llI'Ir~~

!EnalltiNJ ·1
• The destination lP address of a packet

unniiII>JI..:l f'OJC!': o&-l .Ird(;n 1-.. 1-1
• The destination port of a packet.

Packet filters enforce an access policy on incoming traffic
I'
"""'"'
I ~ ~, . ,mfllbhed COfln". " .
f] s.ocIlQIf' _!fOr on pacbl n-.Ife!
only, and can affect both admi ni strative traffic and client Ellempdons
traffic. (Administrative access via the management port is not ~ .....,.a~ AAP
ProIIocO'1
affected by packet filters.) The criteria for accepting or r.rllM-ajI ~ imc.onal'll lCMP
rejecting packets are defined in expressions contained in IA.&.C "'oar...-u 1,.01'1. H
packet filter rules (not to be confused with iRules). IP MatiUi INone 1·1
There are three basic steps required to configure packet
filters. All three are generally carried out using the
"" . !NQn. H
Configuration utility: [ "'.... 1
I . Enable packet filtering on the BIG-IP system Figure 15: Enabling packet filters and global
packet filter settings
2. Define global packet tilter settings
3. Detine specific packet filter rules
~~ ,. 1"IIdI... ' .... ~ ~
" - , .
Enabling packet filters
cool'igouratlon
Packet filtering is disabled by default on the BIG-lP

system. To enable packe t Jiltering, start at Network»
~.~ 1
",,'" IIB!!:El
Packet Filters and select Enabled from the Packet ..'" 1· 1
Filtering pull-down, as shown in Figure 15. 1..N11 fl.lllflll ...

IAttAIII

IDlu~I · 1
Global packet filter settings ""'"'
r . .rhp .......
Once packet Jilters are enabled, the administrator can =Iilll4 i+.....oo
F...,[g. .... IiIIIIbo:z
1·1
define global actions for hand ling packets that do not
match any packet filter - Unhandled Packet Action ~- I AII1 I· J
s. 11/1.I, ,,,,<::'ltt IR ISIrtaI. . ,,..IIIa 1.. 1
and packets that are exempt from filtering - Exemptions.
The default action for unhandled packets is to accept
them (i .e. allow them to continue within the BIG-IP
system), and is often change to the alternatives, discard
I . Hol . I _. ""
I 10.10 11.)0 !!iii
J
or reject, to ensure the effect iveness of your packet I~~
[J~".-u.. Holb MlG
filtering rules. Exceptions can then be made for incoming !~"'U

I""" H
packets jrom specific MAC Addresses, IP Addresses, IMy
and VLANs. - OU\NllOl'r"""
~[I!«'. I.....- J
I.)
Warning: Changing the default value of the Figure 16: Example of a specific packet filler (tile
Unhandled Packet Action property can produce
unwanted consequences. Before changing this value to Discard or Reject, make sure that any
traffic you want the BIG-IP system to accept meets the criteria specified in packet filter rules .

Specific packet filter rules

After configuring global packet filter settings, you can finally create a speci fic packet filter rule. You can
use the Configuration utility to build an expression for you, or you can write your own expression text
usi ng the same syntax as that of the tcpdump utility. For example, the packet filter rule illustrated in
Figure 16 will allow all packets from tbe host at 10.10. 17.30.
Specific packet filter rules are recorded in the Iconfiglbigip.conf file; general settings are stored in the
IconliglBigDB.dat database file. At run time, as a packet arrives on the BIG-IP system, it is compared to
each packet filter for a match. The order of search is determined by a numerical sequencing value that is
ass igned to the rule. (You can adjust the order manually using Change Order button on tbe Packet Filter
Rules list in the Configuration utility .)
If and when a match is found, one of four actions will take place, as specified in tbe rule:
Action Result at run time, if match

Accept --------
BIG-IP will accept the packet and stop searching any additional packet filter rules that
might apply.
Discard BIG-IP will drop the packet and stop searching for any additional packet filter rules
that might apply.
Reject BIG-IP drops the packet and also sends an leMP reject packet to the sender
indicating that the packet was refused.
Continue BIG-IP acknowledges the packet for logging or statistical purposes, but makes
decision yet on how the packet will be handled . BIG-IP continues searching the
p'~.<:~~f!I~ ~ul_~~ist f.,?~_another_rYl~t<:hing_~ule .

Lab 11.1 - Packet Filters Lab
Objectives:
• Define packet filters on your BIG-lP system to allow and restrict administrative and application
traffic from specific networks and network devices
Lab Requirements:
• Access to multiple BIG-IP systems via the 10.10116 network
• Virtual server on the 10.10116 network with at least one available pool member and source
address translation set to SNA T Auto Map
General Filter Guidelines

When you define an IP filter, you can configure it in many ways to accept or deny traffic:
• To or from a specific address or network address
• To or from a specific port
• From a specific network address to a port
In this lab, you will add packet filters to allow administrative and application traffic to your BIG-LP
system from your client device, your partner's client device, and block all other administrative traffic
from the 10.10/16 network
Test behavior before adding filters

1. Open a browser session to https:IIIO.1O.Y.31 where "Y" is your partner's station number. If it
succeeds, then yo u have access to change the configuration of this BIG-lP system (assuming you
know have valid log in credentials, as well).
Enable packet filtering

2. Enable packet filtering on your BIG-IP, accepting all system defaults for unhand led packet
actions and exemptions.
Properties section
When complete, click...

Create a packet filter rule

3. Create a packet tilter rule named Me to allow access to your BIG-LP from your Pc.
Filter Expression section
Restrict to any in list...

Source Hosts and Networks
Add 10.1 0.X.30 to the list
4. Verify that you can still access your BlG-IP at https:III0.I0.X.31 , and your panner' s BlG-IP at
https:lllO. 10.Y.3!.
Prevent all other traffic

5. Create another packet tilter named Them to restrict access to your BIG -IP from everyone else.
Configuration sectJon
FIlter Expression section
Restrict to any in list.. .

Source Hosts and Networks
Add 10.10.0.0/16 to the list
6. Verify that you can sti ll access your BIG-IP at https:III0.I0.X.31 , but your panner cannot.
Q. Does the packet filter apply only to administrative traffic or to application

traffic as well? (Hint: Have your partner try to access one of your virtual
servers on the 10.10/16 network that has SNAT Auto Map se!.)

Grant access to your partner's PC

7. Create another packet Ii Iter named Partner to allow yo ur partner to access your BIG-LP.
Filter Expression section
Restrict to any in list ...

Source Hosts and Networks Add 10.10.Y.30 to the list (where "Y" is your
station
When complete, click... Finished
8. Verify that your partner still cannot access your BLG-LP.

9. Change the search order fo r your packet filter rules. From Network » Packet Filters » Rules,
click the Cbange Order button. Use the Up, Down, First, andlor Last buttons to change lhe
sequence so that tbe order is as folLows:
a. Me (1)
b. Partner (2)
c. Them (3)
10. Click the Finisbed button when the order is correct.
11. Verify that your partner now has access to your BIG-IP at https:1II0. IO.X.31- and to your
virtual server at bttp :// 1O.10.X.100 - but others in the classroom do not.
12. View the packet filter settings using tmsh and notice the order parameter that appears on each
entry : tmsh 1 ist / net packet - f il ter
Log packet filter events

13. Configure BIG-LP to log packe t filte r events

14. Open an SSH session to your BIG-IP and enter the following command to view the packet filter
logs :
tail - f /var/ l og/pktfil ter
Do you see the log entries?
15. Disable loggi.ng on packet filter rule Me, and enable it on packet filter Them . Have another
student (other tban your partner) try to access your BIG-IP system at bttps:IIIO.IO.X.31 to see the
log messages that are generated on packet discards.
Clean up
16. On your SSH session to your BIG-lP, terminate the tail command by typing <CtrI+C>.
17. Disable packet filtering.
If you are working on BIG-IP hardware , continue with Lab 11.2: Always
On Management

Chapter 11 - Admlnlsterrng the BIG-IP System 11-27
Lab 11.2 - AOM IP Address Lab (Optional)
Objective:
• Configure an IP Address on the AOM
• Reboot the Host (L inux and TMM) from AOM
• Estimated Time: 10 minutes
NOTE: This section of the lab may vary per training location. If you do not have access to a
serial console session in your location, then you may already have an IP Address for your AOM
so ask your instructor for details.
Adding an Address to AOM/SCCP

I. If you have access to a seria l console sessIOn with your BIG-IP System, then from your serial
console session, type ESC (
2. Choose option N, AOM network configurator
3. For Use DHCP? Enter n
4. For Host name (optional): press the Enter key
5. For IP address (required): 192.168.X.35
6. For Network mask (required): 255.255.0.0
7. For Broadcast lP address (optional): press the Enter key
8. For Default gateway IP address (optional): 192.168.20.1
9. For Nameserver IP address (optional): press tbe Enter key
Rebooting the Host System from AOM (Optional)

NOTE : If you don't have access to a serial console, then ask your instructor for options.
10. Open an SS H session to AOM at 192.168.X.35

II. When prompted, log in as root witb a password of rootX
12. From the prompt, enter hostconsh and then ESC ( to access the AOM menu.
13. Select option 1, Co nnect to Host subsystem console and press the Enter key.
14. From the host prompt, enter ESC ( to access the AOM menu again.
15. Select Reboot Host subsystem 2 for AOM and enter Y when prompted.
16. You are automatica lly connected back to the Host subsystem. The Host subsystem now reboots
in the console session and you should not lose your connection during this reboot.
Administerrng BIG-IP v11 11-27

License Dates and Upgrade Considerations
Lesson Objective:
• Compare and contrast license date, Iicense check date, and service check date
• Underst·and tbe impact of service check date on system upgrade and system startup processes
License Date Check Functions

During BIG-IP or Enterprise Manager startup and upgrade processes, the system performs various date
checks to ensure that the system is properly licensed. These checks involve one or more dates:
• License Date - The first date that you used your Registration Key to license your BIG-JP system.
• License Check Date -{better thought of as version release date) is a static date built into each
BIG-JP software version that is roughly equivalent to the official release date of the version.
• Service Check Date - The date tbe license was last activated at the F5 license server. Service
Check Date is updated each time the license is reactivated under a valid service contract.
Wben you activate your BIG-JP or EM license at the F5 license server for the first time (using the
registration key and generated dossier), a license file is generated and installed on your system. The file is
called bigip'/icense and is located in the /config directory.
Note: The license file contains the license date and the service check date, but does not
contain the license check date. License check dates for each BIG-IP and EM version are built
into each BIG-IP software version but not in any way that is viewable. However, there is a list of
the license check date for each BIG-IP version in S0L7727: License activation may be required
prior to software upgrade.
Date enforcement during upgrade

If you are planning an upgrade to a newer B1G-tP or EM version, then you must ensure that the service
check date in the license file is after the license cbeck date (release date) for that version. You should
compare these dates before starting the upgrade as the system will make the very same checks during the
install process. (You can view serv ice check date in the license file itself, or use the tmsh show / sys
license command .) If service check date is later than tbe license check date (release date) for the
software version you are i.nstalling, then the upgrade will proceed normally, as shown in Figure 17. Ifthe
service check date is missing or is earlier tban the license check date, the upgrade stops and an error
message is produced.
You can reactivate the license at tbe F5 license server and begin (or resume) the upgrade process, if you
have an active service contract. If you do not have an active service contract, you must contact F5 to
obtain one before starting (or continuing) the upgrade.

Service
11.4.0 11.4.1
Check
release release
License Upgrade
date to 11.4.1 ............
Figure 17: A successful system upgfllue can be performed If the BIG -IP system's service check dale Is ener the
release date (license check dale) for the upgrade version
Date enforcement during system startup

License dates are also checked during system startup, The system compares the license check date
(release date for the software version you are starting up) to the service check date in the license fil e, If
the service check date is earlier than the license check date, the system initializes, but does not load the
configuration, To allow the configuration to load, you must update the serv ice check date in the license
fil e by reacti vating the system's license, This is best accomplished using the Configuration utility, Under
these circumstances, when you connect to tbe Configuration utility, you will automatically be directed to
the screen where you can reactivate the license,
Enforcement for devices managed with Enterprise Manager

For BIG-LP devices managed with Enterprise Manager, the Enterprise Manager verifies the license check
date and service check date before upgrading a managed system, If required, the Enterprise Manage r
attempts to reacti vate the managed system 's license before performing the upgrade.
For more information , re fer to SOL7702: Upgrades using Enterprise Manager will verify service
check date and aHempt to reactivate system license if required,
Other information contained in bigip.license

o Service Status - Indicates whether or not you have an active service contract based on the
Service Check Date,
o Licensed Version - Shows the software version the device was originally licensed for (as it
relates to the initial purchase order) and has nothing to do with the software version that you may
currently be running,
o Model Name - The model name is usually a four or five digit number (e.g. 8900, 11050) and
indicates the model name for the device,
o Platform Type - Identifi es the chassis type and is usually a letter followed by a two or three digit
number (e,g, D106, EI02).

Viewing license information

[fyour system is properly licensed, you can view the license file itself (e.g. cat
/config/bigip.l icense from the command line) or use the tmsh show /sys license command
output to display licensing and provisioning information similar to what is shown in Figure 18. (Some
sensitive informati on has been omitted or modified for confidentiality.)
Sys: : License
Licensed version 11.1. 0
Registration key EHTUT-UYFJP - JACHK - LECLJ-OIUAUSS
Lice nsed On 20 13 /08/07
l.. icense S ta r t Date 2013/12/ 1 7
Lice nse End Date 2014/01/ 18
Service Check Date 2013/12/ 18
Platform 10 Z100
Active Modu les

GTM-DNS, RL, BIG-IP (vll.4 & later )
DNS Rate Fallback, 50
DNS Licensed Objects, 0
DNS Rate Limit, 50 QPS
GTM Licensed Objects, 0
GTM Rate, 8
GTM Rate Fallback , 8
LTM, VE
IPV6 Gateway
Rate Shaping
Ram Cache
50 Mbps Compress ion
SSL, 500 TPS Per Core
APM, Limited
Application Acc e leration Manager, Core
Anti-Virus Checks
Base Endpo int Security Checks
Fi re wall Checks
Machine Cert ifica te Checks
Network Access
Protec t e d Workspace
Secure Virtual Keyboard
APM, Web Application
App Tunnel
Remote Desktop
SSL, Max T PS, VE
Figure 18: Sample BIG-/P licensing information

BIG-IP Disk and Software Management

o Locate and download BIG-IP software upgrade releases, hotlixes, and other patches,
o Identify the steps required to install a new software release or hotlix ,
o Identify the steps required to reboot the BIG-IP system from a different boot location ,
Overview of the Disk Management Process

Monitoring the hard disk capacity on a BIG-IP unit is critical to maintaining a healthy system, If a BIG-IP
system is running low on disk space, you may experience performance-related issues, such as the inability
to perform upgrades, run ConligSync operations, or save UCS liles, FS recommends periodically
checking disk space utilization and using industry best practices for keeping disk utilization to a
minimum.
The BIG-lP I Lx system utilizes the logical volume management (LVM) disk-formatting scbeme. LYM
is an enhanced software image manager used for deploying logical rather than physical storage. With the
LYM disk-formatting scheme, logical volumes may span across one or more physical bard drives, and
can be resized without interrupting service.
Symptoms of a full or near full disk

When the BIG-IP file systems become full, undesirable or unpredictable behavior may result. Symptoms
Can include:
o System-generated warning log messages andlor SNMP traps
o Upgrades or hottix installations tbat fail to complete
o Daemon log messages that indicate failed write operations or failure to open certain files
o System performance degradation, such as slow Or failed disk write operations
Disk management recommendations

To help prevent disk utilization issues, FS recommends using the following guidelines to maintain
adequate disk space on the system:
o Store maintenance-related files in the isharedltmp directory, including tcpdump files, UCS
archives, qkview liles, or otber liles that an administrator may create while performing
maintenance or troubleshooting-related tasks on the system.
o Store long-term maintenance liles such as UCS archives Or SCF liles on a network sbare,
o When creating or generating a file on the BIG-lP system, provide the full path location so that the
fil e is saved to the intended location and not the current working directory. For example, when
saving tcpdutnp output to a file, specify the complete path for the file:
/shared/tmp/example_tcpdump.pcap
o Avoid storing files in directories that reside on the Linux root filesystem. Directories such as
/home reside on the root filesystem and sbould not be used for lile storage on the BIG-lP system,
o Periodically cbeck tbe available disk space On tbe BIG-IP system. To check available disk space,
you can use the command : dE -h

• Periodically check for and remove non-critical maintenance file s. For example, old tcpdump,
qkviews, or software images (.iso files) should be deleted from the sys tem or moved to a network
share. Of course, if you are unsure of the origin or use of a specific file, contact FS Technical
Support before removing the file from the BIG-IP system.
For more information, see SOL 14403: Maintaining disk space on the BIG-IP system (11.x) and
SOL8865: Overview of the diskmonitor utility.
Overview of the Software Management Process

FS periodically releases new versions of its BlG-lP software including:
• Major software versions - contain major new features and functionality . For example, vll.O.O
introduced Device Service Clustering, iApps, Analytics, and IPv4-to-IPv6 Gateway, among otber
features.
• Minor software versions - contain minor new features and functionality, as well as a roll-up of
all cumulative maintenance since the major version. For example, vIIA .O introduces local traffic
policies, Thales nShield Connect integration, and flexible resource allocation for vCMP systems,
among many others.
• Maintenance versions - contain all cumulative maintenance since the previous minor version as
well as minor new functionality. For example, vI 1.4.1 introduces support for the new VlPRION
82150 blade, NEBS support for the VlPRION 4800 DC platform, and additional vCMP support
for solid-state dri ve platfOims.
• Cumulative hotfixes - contain software fixes between minor or maintenance BIG-lP software
releases.
FS also releases engineering hotfixes (similar to patches) but only by way of a support case. Engineering
hotfixes are rolled up into cumulative hotfixes.
The importance of release notes

The steps to install new software versions can vary from one release to another, and often depend on the
way BlG-lP is configured in your application delivery network. For example, if you wanted to migrate
from v9 to v II , you would need to upgrade to v 10 first, and if your 8tG-IP devices are clustered in a
high-availability configuration, you would need to take that into consideration when planning your
upgrade implementation path .
F5 provides release notes for every new software version, whether it's a major new release or a
cumulative hotfix release. T hese release notes assist with the following tasks:
• Identifying whether or not the release is applicable or appropriate for your environment
• Locating the user documentation for the release
• Identifying the new features and functionality introduced in the release (or rolled into the release
as the result of incorporating prior versions), as well as identifying the issues that are corrected in
the release (fixes)
• Determining your installation checklist, including what steps may be required to upgrade from
eartier versions
• Installing the sofrware

• Performing post-insta llation tasks

• Identifyin g behavior changes and known issues that may impact your test cases and test results
• Contacting FS Networks in the event that you require additional resources or tecnnical support
Note: Your IT Change Management, Problem Management, andlor Release Management

methodologies will typically dictate when and how you perform software (or hardware) upgrades
to your BIG-IP platforms (for example maintenance window, partial roll-out, full roll-out, testing
platforms, staging platforms , and so on). The documentation contained in the remainder of this
section describes only the components of the BIG-IP system that provide software management
functionality and how they work. Any steps described are meant to augment or be integrated
into your existing procedures, not substitute for them.
BIG-IP Hard Disk and Boot Locations

Each BIG-IP system has at least one hard drive that is used to store the BIG -IP software and associated
files, including configuration files. For example, the BIG-JP 4200s comes with one SOO-OB hard drive,
and the BIG-IP 10000s comes with two I-TB drives (RAID I). BIG-IP virtual editio n systems have
virtual hard drives that ulti mately store their data on their host system hard drives.
Software Images
Part of the hard drive can be used to store BIG-IP software images. FS usually distributes so ftware images
as ISO archive tiles ("ISO files," with a .iso file extension), the data from which is eventually stored on
BIG-JP systems in one of three states:
• Available images: software images that have been imported onto the BIO-iP system (using the
Configuration util ity or tmsh) and placed in the Isharedlimages folder.
• Installed images : software images that have been installed into boot locations on the BIG-IP
hard drive . The number of boot locations a BIG-IP device can accommodate depends in large part
on the size of its hard drive.
• Active image: the installed software image from which that the BIO-LP system is currently
booted. There can only be one active image on a BIG-IP system at any time, except when vCM P
is configured.
Logical View
HD1 --- --
- - - Bool locations
30 .9 GB free of 102 .4 G8 • MySQL
AVR
Figure 19: Logical view of a BIG -IP hard drive showing how the disk space is utilized
For example, Figure 19 shows the disk space utilization of HD I (hard drive I) on a BIO-LP YE.
Adminis tering BIG-IP v11 11-33

Figure 20 shows the breakdown of boot locations on the same system shown in Figure J9, and the
software version that is installed on each. The boot location names are in the fonnat HDx.y where x is the
hard drive number and y is a boot location number.
Boot Locations
stilus DoIoul Boot LocllJon Product Vorslon BUlks
Active V•• HOt .t BIG-I? t 1.4.0 2364 .0
Inactive No H01.2 BIG-I? 11 .2.0 2446.0
L~active No H01 3 BIG-I? 11 .3.0 2806.0
Figure 20: Boo/locations on a BIG-IP system

On the BIG-LP system shown in Figure 20, there are three boot locations :
• H01.t - Currently has a vll.4.0 (build 2384.0) software image installed. This is also the active
boot location (indicated by Yes in the Active column), which means that the BIG-IP system is
currently running vIIA.O software.
• HD1.2 - Currently has a vll.2.0 (build 2446.0) software image installed.
• H01.3 - Currently has a vi 1.3.0 (build 2806.0) software image installed .
Only one BIG-JP software image must be installed and active in one boot location to run the BIG-IP
system, process traffic, and administer tbe configuration. Your Release Management methodology will
almost certainly influence how many other software images andlor boot locations may be desired to
support a chosen upgrade path .
When installing a new software version or botfix, you must run the installation process from an active
boot location and specifY ao inactive boot location as the target install location. This allows you to
prepare an inactive boot location in advance by installing the oecessary software imagelhotfix, and then
boot to the new location when you arc ready to test the new configuration .
The installation process automatically copies the saved configuration and license from the current boot
location to the target install location. There are techniques you can use to perfonn a clean ins/all of BlG
IP software in which no configuration information is copied from the current boot location to the target
install location. (See Chapler Resources at the end of this chapter.)
Software Installation Process

The software installation process on the BIG-LP system can be summarized in the following steps:
l. Determine the version to install.
2. Download the software image ftles (.iso, .mdS) and release notes.
3. Import the software image ftles to the BIG-IP system.
4. Use the MDS checksum ftle to verifY the integrity of the software image .
5. Install the software image at an inactive boot location .

6. Activate the new software image's boot location, and test.
Determining the version to install

To determine the ap propriate upgrade andlor hotfixes to install on the BIG-IP system, you ca n review
various documents ava ilable at AskF5.com, including but not limited to:
• SO L9476: The F5 hardware/software compatibility matri x
• SO Ll0288: BIG-IP software and platform support matri x
• BIG-IP Produ ct Matrix (PDF)
• SO L9502: BIG-IP hotfix matrix
You can also review re lease notes to ensure a release is compatible with your BIG-IP environment.
Downloading software upgrade/hotfix files

When preparing to install a software image on a BIG-IP system, F5 recommends that you download the
ISO archive fil e (.iso), the MD5 file (.md5), and, most importantly, the corresponding release notes, as
shown in Figure 21. The MD5 file is used to check the integrity of the ISO archive after download. Read
the release notes before installing the new software image. Download the files from
https:lldownloadSofSocorn to your workstation. (Although not required, it's easier if th at workstation can
also access the BIG-lP system you are upgrading.) A valid support account is required to log in and
access the download area.
Home » Produr: I l .fr)M » Proch.KI Version
Select a Product Version and Container for BIG-IP v11 .x / Virtual Edition
The latest produC I version IS displayed by def' " • you are looking for downloads related 10 a diferent version of Ihis product , please
selec t from the follOWIng optJons.
_1.14 .1[:1
Selec t a product contamer
Name Version Type Date Description

_ I,IIGII' 11 1 1-ti2:> O·HH 11.4 1 HolflX 11:1 9120 13 Holl1x· B1GIP- 11 4 1·625 O-HF 1
<pse< -I 0 IP6°' I) II 4 1 Patc hes 1(JJ()91201 3 OPSWAr_36 7821 2
Gcoolocal>OnUp..lal "" 11 .4 1 Patche ~ 11 1\)812013 GeoLOCcltl nUpdi-Jtes
!Aw-TempIa1es 11 4 1 Patches 0911112013 lApp Ter""lal e5 (10.061)
11 ~ 1 11 4 1 Release 0911712013 BIGI P 11 4.1 608 0 IS O
A,S1J-lalestSl\1nat L<eFie 1141 Release 11113120 13 ASI.\ te_tS ignatureFlle

ASM PaslSlgT1allJreflles 1141 Release 1111312013 ASM-PastStgnalureFtles
~'~Uill-E ~"'" 114 I Release 0911 712013 Virtual Edition
Figure 21: Find software images and hotfixes at downloads.f5.com

Importing the software image files to the BIG-IP system

After you bave downloaded the ISO archive and MD5 files to your local workstation, you can use the
Software Management component oftbe Configuration utility to import the files to the BIG-IP system.
The Software Management component automatically installs the software image files to tbe
!shared!images! directory on the BIG-IP system.
Installed tmages
p,- Version BuIld Disk Boot: LocalJon Active Oefaul Boot Media InstaP St.",.
BIG-IP 11 .4.0 2384.0 HD1 H01.l Ves Ves hd complete
BIG-IP 11 .2. 0 2446.0 HDl H01.2 No No hd complete
BIG-IP 11 .3.0 2806.0 HDI H01.3 No No hd complete
Available Images I lm~rt ..

SotIwore Imago Version Last Modifted Image SIze MDSVor1fted Available
BIGIP-11.4.1.S0B.O.iso 11.4.1 Wed Nov 2713:06:032013 1575 MB Ves Yes
Figure 22: Use the System> Software Management> Image List screen to import a major or mIn or BIG-IP software
release. Use the Hotfix List tab to import a hotfix. H01.1 is the active boot location in thiS screen shot, and a software
image for version 11.4.1 has been imported onto the BIG-IP system in the /sharedlimages directory
To import software upgrade files to BIG-IP:

I. Log in to the Configuration utility and navigate to System» Software Management.
2. If installing a new version of BIG-JP software, click the Images List tab in the menu area, as
shown in Figure 22. If installing a botfix, click tbe Hotfix List tab before begil1J1ing the import .
3. Click Import, then Browse, then navigate to the location on your workstation where the .;so file
is located.
4. Select the file , and then click Import to copy tbe file to the BIG-IP system's !sbared/images!
directory.
Note: Do not navigate away from the Import screen while the import is in progress because this
can cause the import to stop. Remain on the Import screen until the import is complete.
If the import was successful, tbe .iso file should appear in the Available Images list, as shown in Figure
24. You can do an import for the MD5 file as well.
Note: You can also use SCP to copy the files directly to the BIG-IP system. If you do, make sure
the files are copied into the /sharedlimagesi directory, otherwise they will not be accessible to
the installation process via the GUt.

Verifying the integrity of the software image (MD5 checksum)

After importing to the BIG-tP system and before installation, you should check the integrity of the ISO
file to ensure it was downloaded and copied successfully. You can do this using the following steps:
1. Log in to the command line
2. Change to the Ishared/images directory: cd / shared/ images
3. Verify software image integrity: mdSsum - -check <software_ image .md5 >
Note: There is no space between the two hyphens (--) and the word check (--check).
You should receive a response from the md5sum command indicating the associated .iso file is
OK. For example:
md5sum -- check BIGIP-11.4.1.60B.O.iso.md5
BIGIP - 1 1 .4. 1. 60B.O.iso, OK
If you do not receive an " OK" response to the md5sum command, yo u should download/import the ISO
archive again and retry the MD5 checksum.
Installing the software image

After you have verified the MD5 checksum, you can use the Configuration utility or the command line to
install the software image into a boot location on the BIG-IP system. You must have sufficient disk space
available on the BIG-lP' s hard drive to accommodate the software image in its uncompressed fonn. Also,
you must install the software image into an inactive boot location. In other words, the BIG-lP system
must be booted from a location other than the location you wish to install the software into. For example,
if there are three boot locations - HDI.l, HDI.2, and HDI.3 - and the BIG-IF system is currently booted
from HD 1.1, then you may install the software image in either HD 1.2 or HD 1.3, but not in HD 1.1. The
currently active boot location is indicated by a Yes in the Active column on the Installed lmages list, as
shown in Figure 22.
Installation using the Configuration utility

Generally, a software installation should occur during nonnal maintenance windows to ensure there is no
impact to traffic processing. To install a software image using the Configuration utility, navigate to
System » Software Management , and from either the Image List or Hotf1x List tabs:
I. Select an image from the Available lmages list by clicking the checkbox to the left of the entry.
2. Click the lnstall ... button to initiate the installation process. The pop-up lnstall Software Image
screen will appear, as shown in Figure 25.
3. Select an available hard disk from the Select Disk pull-down menu, and seJect an available
volume (boot location) from the Volume set name pull-down menu. (See Figure 23.)
4. Click the Install button to continue.

x
Install Software Image
You are installing BIG-IP version 11.4.1 Build 608.0
Select Disk:
[BD1 (30.9 GB free) ~I
Volume set name:
(Version:11.2. 0 Build:2446.0)
"l>,·",nn ·11 .3.0 Build:2806.0)
Install II Cancel
Figure 23: Select the boot loca tion (disk and volume) in which you wa nt to install the selected software image. then
cfick Install to continue. Type in a number in the ~Volume set nam .. a re fo create a new volume. For example, to
install 11.4.1 into new boot locatIon HD1.4, type a "4" in the volume name
Installed Images
ProdUct Von"" BuIld Disk I Boot Loe""" ~dlYo Dord Boot Media lmIiIIISI.....
BIG-IP 11 .4 .0 2364 .0 HO I H01 .1 Ves Ves hd complele
BIG-IP 11 .2.0 2446 .0 HOI H01 .2 No No hd complete

BIG-IP 11 .3.0 2806 .0 HD 1 H01 .3 No No hd complete
l BIG-IP 11.4.1 608 .0 H0 1 H01.4 No No OetpirS" ...
Available Images L§Po.!!c:J

- Imago Ven:lon Loll Modltled meg. SlzIt uos V.nned Available
(3) BIGIP·1 1.4.1.6Cl8.0 .110 11.4.1 Wed Nov 2713:06:032013 1515 MB Ves Ves
o.lBte- II
R gur8 24: installing BIG·IP 11.4. 1 info a new boot locatIOn, HD1 .4. Install status shows progress currently at 67%.

The installation process can take several minutes to camp tete, and progress is denoted in the green
Progress bar that will automatically update in the boot location 's entry (see Figure 24). If the installation
completes successfully, you shou ld receive a screen similar to Figure 25.
-
Installed Images
BIG-IP
BIG-IP
V",1on
11.4.0
11.2.0
Build
2384.0
2446.0
Oillc
H0 1
HDI
BOOI Location
HD1.1
H01.2
AdM
Ves
No
001,._ EIool
Ves
No
U,dl.
hd
hd
tnst.II st.IUI
complete
complete
IBIG-IP
11.3.0 2806.0 HOI HOD No No hd complete
BIG-IP 11.4.1 608 .0 HOI H01 .4 No No hd complete
Available Images I lmpo~_ 1

Soltwo.. Image Version Last Modllod Imago SIz<o MD5Vorltod Avollablo
BIGIP·11.4 .1.60e .O.iso 11 .4 .1 Wed Nov 2713:06 :032013 1575 MB Ves Ves
1"",/1
Figure 25: Successful installation of BIG-IP version 11.4.1 into boot location, HD1 .4
Installation using tmsh

To install a software image using the command line, use tbe following tmsh commands:
• If installing a release image :
(cmos) # install /sys software image <image_ name >. iso volume <volume name>
for example:
(~ mos) # i nsta ll /sy s software image BIGIP-11.4.1.60S.0.iso vo lume HD1 .4
• If installing a botfix image, use the following command:

(cmos )# install /sys software hotfix <hotfix name> .iso volume <volume name>
for example:
(tmos )# install /sys software hotfix Hotfix - BIGI P-1 1.4.1-625 .0-HFl.iso
volume HD1.4
You can also watch the progress of the installation from the command line using the tmsh show /sys
software status command.

Booting the BIG-IP system from a new location

If the software installation process was success ful, you're now ready to begin testing with the new release
or bottix applied. Generally, this would also be done during a maintenance window andlor according to
your data center's change management policies. Also, release notes for the ve rsionlhotfix will indicate
any pre-requisite, co-requisite, or post-installation activities that must be carried out in conjunction with
running the upgraded BIG-LP software level.
Boot Locations
StatuI Dot.... Boot Lac.lon Procl>d Version IkIId
Active Yes HD1.1 BIG-IP 11 .4.0 2384 .0

Inactive No HD1 .2 BIG-IP 11 .2.0 2446 .0
Inactive No HD1 .3 BIG-IP 11 .3.0 2806 .0
Inactive No HD14 BIG-IP 11 .4 .1 608 .0
Figure 26: Use the Boot Locations tab in Software Management to activate a different boot location
To boot the BIG-LP system from a

different location using the
Configuration utility:
I. Navigate to System »
Software Management»
Boot Locations, as shown in
Figure 26. Generat Properttes
2. Select the boot location you Boot Location HD1 .1 » HD1.4

wish to activate by clicking on Product BIG-IP
its name (e.g. HDI.4)
Versio~ 11.4.0» 11.4.1
3. In the General Properties
area, verify that you are about

Build 2384.0 » 608.0
to boot to the right location
and, more importantly, with
Install Configuration
the desired new software
version/build, as shown in I II
Cancel Activate I
Figure 27. The screen shows
you what version/build you are

Figure 27: BIG-/P shows you what software version/build you are
currently active on and what currently active for as well as what version/build you will move to if you
versionlbuild you will be click the activate buhon
moving to should you click the
Activate button. You can optionally choose to copy the configuration from an existing boot
location to the target boot location by choosing Yes for Install Configuration. This is a new
feature in BIG-LP version 11.4; the default is No indicating the target boot location's
configuration will not be updated.

4. Click the Activate button to activate the selected boot location. The BIG-IP system will take
several minutes to reboot from the new location . During reboot, no traffic is processed and
administrative/unctions are not available!
If the reboot is successful, you should be able to log back into the Configuration utility and begin testing.
To boot the BIG-IP system from a different boot location (volume) usillg the command lille:
( tmoa)~ reboot vo lume <volume>

For example: (tmos)#- reboot volume 001.4
Reverting to a previous version

If you want to revert to a previous version of BIG-I? software, you can reboot to the fonnerly-active boot
location using the same method as above. In our previous example, to revert from IIA.I back to 11.4.0,
we would activate boot location HDI.I again. Keep in mind that any pre-requisite, co-requisite, or post
installation activities may also Ileed to be undone. Refer to release notes for additional infonnation
Note: If at all in doubt about carrying out the software upgrade process, please contact F5
Technical Support for assistance.

BIG-IP User Roles and Administrative Partitions

Lesson Objectives
After completing tbis lesson, you will be able to configure administrative partitions and define user roles
and configuration objects within those partitions.
Understanding User Roles and Administrative Partitions

The concept of a user role wil l be fami liar to anyone wbo has worked with delegated administration .
Entitlement of responsibilities are restricted by job function, thus a developer can have one level of access
and a network administra tor another. BIG-l.P ex tends this paradigm to include the concept of
administrative partitions, which are segmentations based on application function (or other business
needs).
For example, a company might divide tbe administration of their BIG-I? system along the same lines as
their applications are maintained, as shown in Figure 28. The SA? applicat.ion manager(s) could work in
one partition, and the OWA application manager(s) in another, with neither group able to change
configura tions outside of their own. Agility is maintained because the subject matter experts for a
particular application are allowed to carry out their tasks directly without baving to delegate their
expertise to network administrators. Likewise, network administrators can sleep better at nigbt knowing
there's less opportunity for application managers to take their BIG-JP system down.
SAP Partition
Common Partition
Network Administrators
Figure 28: Partitions provide multi-tfmancy on the BfG-IP system from an administrative perspeclive. For example, a
company might divide the administration of a BIG-IP system along the same Jines as their application systems are
mamtained. Here, network administrators maintain the Common partition and the BIG-IP system as 8 whole, while no
SAP manager and an OWA manager are restn"cted to the partitions thaf support /heir respective applications.

Chapter 11 • Administering the BIG·IP System 11--43
Authentication and Authorization

An important part of overall BIG·IP management is the creation and management of system accounts for
BJG·IP administration. The purpose of these accounts is two·fold:
• Authentication - Verify the identity of users logging in to the BIG·]P system
• Authorization - Control access to the BIG·IP system
Authentication is achieved through the account's usemame and password credentials; authorization is
achieved through the account's assigned user role.
The BIG·JP system provides a number of access control mechanisms to maintain secure access to the
device, to ensure interoperability in a variety of environments with established requirements, and to assist
in meeting industry standards such as PCI Compliance. These include a hierarchy of user accounts and
access privileges, password enforcement options, and support for various authentication technologies.
System Accounts
The BIG ·tP system includes two types of system accounts:
• System maintenance accounts - predefined and with full access to all BIG·IP system
maintenance interfaces, utilities, and functions.
• System user accounts - defin ed by a BIG·IP administrator and may be configured with more
limited access to specific portions of the system, as needed , to suit their role.
System maintenance accounts

As you saw earlier in this course, two "default" accounts for system management and maintenance are
provided with the BIG·IP system: the root user and the admin user. These users have full access to the
system and can perform all administrative tasks. The root user has full access by way of the BIG·IP
command line interface, but not through the Configuration utility. The admin user has full access by way
of the Configuration utility, but command line access is disabl ed, by default. These accounts cannot be
deleted, and their roles cannot be changed (although the admin user's access to the command line
interface can be changed, as you saw in the first lab).
The admin user and all system user accounts are maintained through the Configuration utility at System
» Users. The root user is maintained througb the Configuration utility at System »Platform.
You are not required to bave accounts other than tbe root or admin accounts in order to maintain your
BIG·]P system. However, we recommend that you create other user accounts as a way to inte lligentl y
control administrative access to BIG·IP system resources.
System user accounts

System user acco unts can be configured to grant varying degrees of access to BIG·]P users. Access is
controlled by a combination of:
• User roles - Control what actions a user can execute on the BIG·]P system, such as modifying
anotber user's access privileges, writing and applying iRules, and enabling/disabling pool
members.
• Administrative partitions - Control the groups of objects to which a user can apply tbe actions
allowed by their roles.
Administering BIG·I P v11 11--43

Local VS. Remote user management and authentication

The BIG-IP supports both local and remote au thentication schemas . A BIG-lP administrator can use the
Configuratio n utility or the tmsh command line tool to create and delete BIG-lP user accounts, change
passwords, and enforce a global password policy which includes password strength, password aging,
password re-use, allowed number of login failures, and other security settings. By contrast, when remote
user accounts are used, the creation, management, and password policies for the system user accounts are
maintained through a remote authentication server.
The BIG-lP currently supports remote authentication through Active Directory or LDAP, RADIUS,
and TACACS+. Using these remote authentication methods allows the BIG-IP to participate in a
centrally located and managed access schema, and to use the password enforcement policies of the remote
authentication server. However if the remote authentication server experiences a failure, login attem pts
using remotely au thenticated system user accounts will fail, limiting access to system maintenance
accounts that are locally authenticated.
Note: If a remote authentication method is specified for system user accounts, the BIG-IP local
database will still be used to authenticate the system maintenance accounts root and admin.
This ensures that if the remote authentication device is unreachable, the system maintenance
accounts can still access the BIG-IP system.
User Roles
User roles are a means of controlling access to BIG-IP system resources. You assign a user role to each
administrative user and, in doing so grant the user a set of permissions for accessing 8IG-IP system
resources. More specifically, a user role defines:
• Tbe resources a user can manage - For example, a user with the role of Operator can manage
nodes and pool members only. By contrast, a user with the Resource Administrator role can
manage all objects except user accounts.
• The tasks a user can perform on those resources - For example, a user with the role of
Operator can only enable or disable nodes and pools; they cannot create, modify, or delete them.
On the other hand, a user with the role of Administrator can perfonn all tasks on all resources.
The table below summarizes some of the various roles for user accounts:
User Role Description
Administrator This role grants users complete access to all partitioned and non-partitioned objects
on the system . In addition, accounts with the Administrator role can change their own
passwords .
Resource This role grants users complete access to all partitioned and non-partilioned objects
Administrator on the system, except user account objects. In addition, accounts with
the Resource Administrator role can change their own passwords .

User Manager Users with the User Manager role that have access to all partitions can create,
modify, delete, and view all user accounts except those that are assigned
the Administrator role, or the User Manager role with different partition access.
Accounts with the User Manager role that have access to all partitions can also
change their own passwords.
Users with the User Manager role that have access only to a single partition can
create, modify, delete, and view only those user accounts that are in that partition
and that have access to that partition only. For example, if your user account has
a User Manager role and has acoess to Partition A orily, then you can manage only
those user accounts that both reside in and have acoess to Partition A only.
User accounts with the User Manager role can change their own passwords.
Manager This role grants users permission to create, modify, and delete virtual servers, pools,
pool members, nodes, custom profiles, custom monitors, and iRules®. These users
can view all objects on the system and change their own passwords.
Certificate This role grants users permission to manage device certificates and keys, as well as
Manager perform Federallnfonmation Processing Standard (FIPS) operations.
iRule Manager This role grants users permission to create, modify, and delete iRules. Users with
this role cannot affect the way that an iRule is deployed. For example, a user with
this role can create an iRule but cannot assign it to a virtual server or move the iRule
from one virtual server to another. A user with this role can be assigned universal
access to administrative partitions.
Application This role grants users permission to modify nodes, pools, pool members, and
Editor monitors. These users can view all objects on the system and change their own
passwords .
Operator This role grants users permission to enable or disable nodes and pool members.
These users can view all objects and change their own passwords .
Auditor This role grants users permission to view all configuration data on the system,
including logs and archives. Users with this role cannol create, modify, or delete any
data, nor can they view SSL keys or user passwords.
Acceleration This role allows users to view, create, modify, and delete all WebAccelerator policy
PolicyEditor objects in all administrative partitions. Users can also view, create, update, and
delete LTM Web Acceleration and HTTP Class profiles.
Web This role grants users access to Application Security Manager security policy
Application objects, in one or all administrative partitions. These users can modify HTTP Class
Security profiles, but cannot create or delete them. More specifically, these users can access
Administrator LTM objects in these ways:
Ability to enable or disable application security from within an HTIP Class profile.
Read-only permission for these profile types: HTIP, FTP, and SMTP.
These users have no access to other LTM objects, nor to any TMOS objects. They
can, however, change their own passwords. With respect to security policy objects,
this role is similar to the Administrator role. You can assign this role only when the
BIG-IP system includes the Application Security Manager component.

11-46 Chapler 11 - Administering the BIG-IP System
Web This role allows a user to configure or view most parts of the ASM module, in a
Application specified adminislrative partition only. Specifically, these users have limited access
Security Editor to LTM objects, namely read-only permission for these profile types: HTIP, FTP,
SMTP, and HTTP Class.
These users have no access to other LTM objects, nor to any TMOS objects. They
can, however, change their own passwords.
You can assign this role only when the BIG-IP system includes the Application
Security Manager component
Guest This role grants users permission to view all objects on the system except for
sensitive data such as logs and archives. Users with this role can change their own
passwords.
No Access This role prevents users from accessing the system .
Understanding Administrative Partitions

An administrative partition is a logical container for BlG-IP system objects, such as virtual servers,
pools, profiles, and monitors. By putting objects into partitions, you essentia lly establish multi-tenancy on
the BlG-IP system, at least from an adminislration perspective. Rather than have control over all
resources or no resources, a user account can be configured to have contro l over only those resources
defined within a particular partition. For example, users with the role of Operator can enable or disable
nodes but only for those nodes that reside within their designated partition .
Even user account objects can be put into a partition for the n,,'mc,,~ other users administrative
access to those accounts. Each user account
on the BlG-IP system has a property known
as Partition Access that defines the
partitions the user can access . A user
account can have access to ei the r One
partition or all partitions (also known as
universal access).
The following configuration Objects can
exist in separate partitions :
• User accounts
• Virtual servers
• Pools
• Pool members
• Nodes
• Custom profiles
Figure 29 ' Objects in tenant partitions can reference objects in
• Custom monitors the Common parMian. In this example. two virlual servers
• SSL keys one in PartitionA and the other in PartitionB - can both
reference the same client SSL profile called cllenl_ ssl in the
• Certificates
Common partition.
• Certificate revocation lists
• iApps templates and application instances

Referencing Objects across Partitions

A default partition called Common is created when you first install the BIG-IP system. (Up until now, all
the configuration objects you have created on your BIG-IP system have been defined in Common.) This
partition is unique in that the objects in the Common partition can be referenced by objects that are
contained in other partitions that, for lack of a better term, we']j call tenant partitions. For example, as
illustrated in Figure 29, a virtual server definition in tenant PartitionA and another in tenant PartitionB
can both reference the profile called client_ssl that is in default partition Common. Part of the reason for
this special relationship is that the Common partition is "home" to all the default BIG-IP objects such as
default profiles, default monitors, and default authentication iRules, as well as to any custom profiles,
monitors, iRules, and other configuration objects that network administrators might define to be shared
across tenant partitions.
Until tenant partitions are explicitly created on the BIG-IP system, all objects will be placed in the default
Common partition. Once an object is placed in its partition "container," it cannot be moved to another
partition without deleting it first from its existing partition, and then redefining it in the new partition.
Disallowed object references across partitions

Although configuration objects in tenant partitions can reference configuration objects in the Common
partition, the BIG-IP system prevents the reverse from occurring. In other words, objects in the Common
partjtioo cannot reference objects in any tenant partition. (They simply aren't visible during
configuration .) The BIG-IP system also prevents a configuration object in one tenant partition from
referencing a configuration object in another tenant partition. Again, objects in other tenant partitions are
simply Dot visible during configuration.
Avoiding traffic processing conflicts when using administrative partitions

Although other tenant partition objects may not be visible to you during configuration, tbe BIG-IP system
is aware of these other objects and will prevent you from creating or modifying an object such that it
creates a traffic processing conflict. For example, if there is already a node at IP address 172.16.20. 1
dermed in tenant partition PartA, you cannot create a node with the same IP address (either explicitly or
implicitly when creating a pool member) in a different partition.
If the node at IP address 172.16.20. 1 was originally created in the Common partition, it can be referenced
by pools created in any tenant partition . In fact, under tbose circumstances, any pool member that
references this parent node at 172.16.20.1 will also be created in the Commoo partition, even though the
pool object itself is created in a tenant partition. As shown in Figure 30, http-"pool-"parta was defined in
tenaot partition PartA. But it's one pool member at 172.16.20.1:80 is actually defined in partition
Common, as shown in Figure 31.
General Properties
N.... hllp""pool....,psrta
Partllon I Path PartA
Figure 30: hffP•..pool...parfa is defined in partition PartA

11-48 Chapter 11 - Admin istering the BIG-IP System
Load Balanelng
Load Balancing MtlhOd [RD!Jnd Rob n
Prtortly Group ActMltion [OI",bl.O "

------
Current Memben Md
,...&.II.___ M...
...Olm
_IOo,
- ._
______• ...Ad
_ ;;,;;;
ch.,._ . _- _ o.. L___"""___....._ n.dioll Umi
COll Partition I Plitt
172 .1 6 20. 1:80 172.16.20.1 1 0 (Active) o Common
Figure 31 : hNpyoolyarta's one pool member at 172.16.20. 1:80 is defined in Ihe Common partllion, even though the
poolis defined in PartA. In this example, this occurred because node 172.16.20.1 was already defined in Common .
Navigating between partitions

When a user logs in to BIG-JP, they will be automatically placed in the one partition they are assigned to
and have no ability to navigate to other partitions, whether using the GUI or tmsh.
Users with universal access (access to all partitions), will automatically be placed in the Common
partition upon logging in, and can navigate to other partitions, as shown below
• Using the pull-down list that appears in the partition area at the top, right-hand comer orthe GUJ
(to the left of the Log out button):
• Using the cd command within the Traffic Management Shell (tmsh) to switch partitions . For
example, to switch from the Common partition to partition PartA, you could issue the following
command from anywhere withi n the tmsh hierarchy. (There is no equivalent to "All [Read Only)"
in nnsh.):
roo L@( b igip4) • . . (f Common ) (tmo s ) ff cd ( PartA
roo L @( b igip4 ) . . . (f ParL4) (tmo e) #
Important: If your BIG-IP user account gives you access to all partitions. make sure you are in
the correct partition before making changes to the configuration!
Creating a new partition

To create a new partition, you must be logged in using an account that has the role of Administrator or
Resource Administrator. Navigate to System» Users » Partition List and click the C reate button. At
a bare minimu m, your partition needs a name. The configuration of other partition setti ngs, such as traffic
group, is outside the scope of this class.

CMP and vCMP
Lesson Objectives
At the end of this lesson, you should be able to describe the benefits of CMP and vCMP, and how each is
leveraged in a BIG-IP environment.
Multi-Tenancy and Virtualization

Multi-tenancy
Earlier in this chapter, we discussed multi-tenancy in teTITIS of administrative partitioning - the ability to
configure the BIG-IP device to service multiple customers or business units without those entities
realizing that others are also using the same BIG-IP system. While this provides the appearance of
separation between tenants, the reality is that all of them share the same resources on the BIG-IP system
CPU, memory, and hard disk. Therefore, ifany one tenant misconfigures their portion of the system, or
causes excessive use of resources, it can negatively affect other tenants.
Multi-tenancy through administrative partitions has other limitations:
• A single hardware failure affects mUltiple tenants
• Tenants must use the same versions of BlG-1P software modules, which limits flexibility
• While individual tenants only see their unique portion of the system configuration, the overall
configuration of the BIG-IP system includes all the configurations, making it complex and more
difficult to manage for BlG-IP network administrators.
Virtual BIG-IP appliances are also sometimes used to address the need for multi-tenancy. A virtual BIG
IP appliance takes the software that once ran on dedicated hardware and ports it into a virtual machine
instance that typically runs on a general-purpose hypervisor. This provides some significant benefits not
addressed by multi-tenancy:
• Each virtual instance is independent from any other virtual instance on the same host. While the
virtual appliance still shares the same hardware with other virtual appliances, the separation is
much more distinct and controlled than in multi-tenancy.
• If the underlying hardware fails, or if another inst.ance causes excessive resource utilization, the
virtual appliance can be moved to another hardware host fairly simply and with little interruption.
This helps address the issue of hardware failures affecting multiple tenants, and resource
limitations that multi-tenancy generally cannot.
Unfortunately, many organizations find that virtual BIG-lP appliances can't do the same heavy lifting as
their physical counterparts. Multi-tenancy also lacks complete isolation, fault tolerance, and ease of
migration. The ideal solution would provide all these features. That's where Clustered Multiprocessing
(CMP) and, more importantly, Virtual Clustered Multiprocessing (vCMP) come into the picture.

Understanding Clustered Multi-Processing (CMP)

Clustered Multi-Processing (CMP) is a traffic acceleration feature of the BIG-IP system that creates a
separate instance of the Traffic Management Microkemel (TMM) service for each central processing unit
(CPU) core on the system. When CMP is enabled, the workload is shared equally among all cores. In
essence, CMP load balances the cores. With multiple TMM instances simultaneously processing traffic,
system performance is enhanced, and traffic management capacity is expanded. The CMP feature is
automatically enabled on BIG-IP platforms, ensuring that all instances ofTMM arc available to process
application traffic.
Certain BIG-IP platforms use a multi-threaded TMM model for CMP processing, while other platforms
use a single-threaded model. There is currently no performance difference between the two models;
however, the multi-threaded architecture allows BIG-IP performance to more efficiently scale over time,
as hardware and network perfonnance continues to increase.
Multi-threaded TMM
Beginning in BIG-IP 1\.3.0, TMM supports a multi-threaded architecture. The multi-threaded model is
derived from the Symmetric Multi-Processing (SMP) infrastructure, and operates by dividing work into
a basic context of execution called a thread. Multiple threads are spread across multiple processors,
resulting in faster processing and more efficient use of system resources. The number of simultaneous
TMM threads varies by platform.
For example, starting in BIG-IP 11.3.0, the BIG-IP 8950 platform runs two TMM processes, one for each
CPU. Each TMM process creates four separate TMM thread contexts.
You can display the number ofTMM threads running on a BIG-IP system by running:
tmsh show /sys tmm-info
Note: For more information, please see SOL 14358: Overview of Clustered Multi-Processing
(11.3.0 and later)
CMP and the virtual server

When you create a virtual server, the BIG-IP system automatically enables the CMP feature for it, by
default. This means that all TMM instances on the BIG-IP system are available to process traffic for that
virtual server. The BIG-IP system then uses a hashing algorithm to distribute connection processing for a
CMP-enabled virtual server among the available TMM processes. Connections to a CMP-enabled virtual
server from a single client source IP:port are typically sent to the same TMM process.
For performance reasons, F5 recommends that you leave the CMP feature enabled. However, you may
occasionally need to disable CMP for a virtual server. You can do so from the command line by executing
the following command:
tmsh modify ltm virtual <virtual server name> cmp-enabled <yeslno>

Pool member load balancing behavior for CMP-disabled virtual servers

[n order to understand better how CMP affects load balancing decisions for virtual server traffic, let's take
a look at how things work without CMP. Consider an example where a virtual server is associated with a
pool containing four pool members. and the Round Robin load balancing method is in effect for the pool.
In Figure 32, four connections are made from four different clients to a virtual server with CMP disabled.
All of the connections are processed by one TMM instance (in this case, TMMO), regardless of whether
other TMM instances arc present on the BIG-IP system. Depending on how the virtual server is
configured, TMMO then may load balance the four individual connections to the four pool members,
based on the Round Robin load balancing method .
BIG-IP
172.1620.1:80 172.16.20.2 :80 172.16.20.3 :80 172 .1620.4:80
Figure 32: With CMP disabled on a virtual seNer, a/l connections to thai virtual server will be processed by one TMM,
in thIS case. TMMO.
Load balancing behavior on CMP enabled virtual servers

Connections on a CMP-enabled virtual server are distributed among tbe available TMM processes, as
shown in Figure 33. The load balancing algoritlun (specified within the pool associated with the virtual
server) is applied independently in each TMM. Since each TMM handles load balancing independently
from the other TMMs, distribution across the pool members may appear different (or incorrect) when
compared with a non-CMP-enabled virtual server using the same load balancing algorithm.

BIG-IP
172.16.20.1:80 172.16.20.4:80
Figore 33' Connections on a CMP-enablod virtual server are distributed among the avaifab;e TMM processes, and
load ba/ancmg is appllGd indepandentiy in eBch TMM This
When you view standard performance graphs using the Configuration utility, you can see the various
instances of the TMM service (e.g. tmmO, tmml).
Performance testing on a CMP system

CMP relies on an equitable hash distribution of traffic among the available TMM processes and
backplane connecti ons. This architecture is optimized for real-world traffic, which typically includes a
large variati on of I.P addresses and port combinations.
When testing performance on CMP systems, your benchmark tests should be configured to mimic real
world traffic, as much as possible. For example, configuring the benchmark test to use multiple
concurrent connections with many source JP addresses, several virtual servers, and multiple pool
membe rs, will produce a better test result.
CMP and connection limits

When connection limits are configured on pool members or nodes for a CMP system, the BIG-JP system
divides the configured connection limit by the number ofTMMs that are running on the system, and
generally forces the calculated limit to round down to tbe nearest whole number (> 0) per TMM. For
example, suppose a pool member or node is configured with a connection limit of 10, and is associated
with a CMP-enabled virtual server on a BIG-IP system with 4 running TMM instances. The configured
connection Limit (10) is divided by the number of TMM instances (4), giving the calculated
connection limit (2) on each running TMM . In this example, since the conf.gured connection limit is
very low, it may appear as though the BIG-IP system is enforcing lower than ex pected connection limits.

Chapter 11 - Administering the BIG-I P System 11-53
CMP considerations
When CMP is enabled, be aware of the following facts:
• While displaying some statistics individually for each TMM instance, the BIG-lP system displays
other statistics as the combined total of all TMM instances.
• Certain load balancing modes might behave differently than on non-CMP systems.
• FS recommends that you disable the CMP feature if you set a small connection limit on pool
members. For example, if you set the connection limit to 2 on BtG-lP system with 4 running
TMM instances, the calculated connection limit will be I for each running TMM, resulting in a
higher-than-expected overall connection limit.
Virtualized Clustered Multi-Processing Overview

Vlrtualized Clustered Multiprocessing (vCMP) is FS's purpose-built hypervisor that allows the complete
segmentation ofVIPRlON and some BIG-IP hardware devices into independent, virtual application
delivery controllers CADC). The vCMP hypervisor is specifically designed for FS hardware and to host
instances of the BIG-IP product suite.
The vCMP hypervisor allocates CPU, memory, and storage to each BIG-IP instance based on the
specifications of the vCMP administrator. As a vCMP system administrator, you can create BIG-IP
instances and then delegate the management of the BIG-lP software within each instance to individual
administrators.
A key part of the vCMP system is its built-in flexible resource allocation feature. With flexible resource
allocation, you can instruct the vCMP hypervisor to allocate different quantities of resources to each BIG
IP instance according to the particular needs of each instance. The vCMP hypervisor provides these
resources to each instance in the form of cores, each of which contain a portion of system CPU and
memory.
supported platforms
vCM P is supported on both VlPRlON and BIG-J P platforms including:
• VIPRlON B2100, B4200, B4300, B4340N
• BIG-lP S200v, noov, 10200v
Note: Discussions in the remainder of this seclion that reference slots and blades are
applicable only to VIPRION platforms (chassis-type devices). In virtually all cases, BIG-IP
appliance-type systems can be thought of as a device with a single slot.
Important: Before you license, provision , and configure the vCMP feature, verify that you have
correctly configured the hardware platform. For more information, see the relevant platform
guide and configuration guide on AskF5.com.

vCMP host
The vCMP host is the system-wide hypervisor that makes it possible for you to create and view BIG-IP
instances, known as guests. Through the vCMP host, you can also manage guest properties. For each
guest, the vCMP host allocates system resources according to the particular resource needs of the guest.
vCMP guest
A vCMP guest is an instance of the BIG-IP software that you create on the vCMP system for the purpose
of provisioning one or mOre BIG-IP modules to process application traffic. A guest consists of a TMOS
instance, plus one or more BIG-IP modules (e.g. LTM, GTM, and ASM). Each guest has its own share of
hardware resources that the vCMP host allocates to the guest, as well as its own management JP address,
self JP addresses, virtual servers, and so on. This effectively allows each guest to function as a separate
BIG-JP device, configured to receive and process application traffic, with no knowledge of other guests
on the system. Furthennore, each guest can use TMOS features such as route domains and administrative
partitions to create a multi-tenant configuration.
Each guest requires its own guest ad ministrator to provision, configure, and manage BlG -IP modules
within the guest.
Each guest is also able to run a different version of BIG-IP software fro m the other guests. This means
that test and development sta ff can create new guests to test new versions of software with little or no
effect on existing deployments. Or, competing business units can choose if and when they upgrade their
BIG-IP software to meet their unique business requirements.
Figure 34 shows a basic vCMP system with a host and three guests. Note that each guest can have a
different set of modules provisioned, depending on the guest's application delivery requirements.
Guest3
Administrator
GuesU Guest2
Administrator Administrator
vCM~Guest 1 vCMPGuest 2 ~MP

Guest 3
GM'
TMOS
v11.4 v11.2
Administrator
Figure 34: A vCMP host configured with fhre e vCMP guests. EsdI guest consists of a TMOS instanco, plus one or
more BIG-IP modules. Guests can run different versions of BIG-'P software as welf as provision different modules.

Other vCMP system components

In addition to the host and guests, a vCMP system is comprised of other components, including but not
limited to:
• Virtual disk - A virtual disk is a quantity of disk space on a slot that the host allocates to a guest.
Each virtual disk is implemented as an image file with a .img extension (e.g. guest_A.img). For
example, if a guest spans three slots, the system creates three virtual disks for tbat guest.
• Processing core - A processing core (or processing unit - PU) is tbe portion of CPU and memory
that the host allocates to a guest. The amount of CPU and memory that each Core provides varies
by hardware platform. For any processing cores that the host does not allocate to guests on the
system, the corresponding CPUs remain idle.
• VM - A VM is tbe portion of a guest tbat resides on a slot or blade. For example, a guest tbat
spans four slots comprises four VMs.
Administering a vCMP system

There are two distinct types of administrators in a vCMP environment:
• The vCMP host administrator manages the host, creating and managing the network
components (e.g. VLANs, trunks, etc.) that create network isolation for the guests. The host
administrator also creates the vCMP guests and allocates core and disk resources to them.
• The vCMP guest administrator provisions and configures the BIG-I.P modules within a specific
guest.
The administrative user accounts, roles, and associated access control mechanisms of the vCMP host are
separate from those of the guests. This prevents a user from accessing the host or other guests on the
system, ensuring the separation of administrative tasks across the vCMP deployment.
Once the vCMP host administrator sets up the host and defines the guests, the vCMP guest adnninistrator
can then provision and configure the BIG-IP modules within a guest to process application traffic. The
vCMP host administrator can also set up a second vCMP with equivalent guests that the guest
administrator can then use to configure high availability.
BIG-IP license considerations for vCMP

The BIG-IP system license authorizes you to provision and run the vCMP feature and create guests with
one or more BIG-IP system modules provisioned. Note the following considerations:
• Each guest inherits the license of the vCMP host.
• The host license must include all BIG-IP modules that are to be provisioned across all guest
instances (e.g. LTM, GTM, AFM, ASM, etc.).
• Before a guest administrator upgrades the BIG-IP software version in their vCMP guest, the host
administrator may need to update the service check date on the vCMP host license.

11-56 Chapter 11 - Administeri ng the BIG-IP System
vCMP provisioning
To enable the vCMP feature, you perfonn two levels of provisioning:
I. Provisioo the vCMP feature as a whole - The host administrator provi sions the vCMP feature
as a whole, creating the host portion of tbe vCMP system. The host administrator then configures
each of the guests.
2. Provision the guests - Once the guests are created, each vCM P guest administrator logs in to
their relevant guest and provisions the required BIG-IP modules they need to process their
application traffic. For example, ooe guest might provision LTM only, while another might
provision LTM , ASM, and GTM.
Important: Once you provision the vCMP feature, you cannot provision any BIG-IP modules on
the vCMP host. More importantly, if any BIG-IP modules are already provisioned on the system
before you provision the vCMP feature, those modules are de-provisioned and any application
traffic currently being processed is interrupted.
---------------------------
Flexible resource allocation
Flexible resource aUocation is a built-in vCMP feature that allows vCMP host administrators to
optimize the use of ava ilable system resources. Flexible resource allocation gives the host administrator
the ability to configure the vCMP host to allocate a different number of processor cores (processor units
or PUs) to each guest, based on the needs of the BIG-IP modules to be provisioned in the guest, and the
volume of application traffic the guest will process.
When you create each guest, you specify the number of processing cores that you want the host to
allocate to the guest. Configuring these settings detennines the total amount of CPU and memory that the
host allocates to the guest. On a VLPRION, guests can be allocated cores on a single blade, or can span
multiple blades, as shown in Figure 35. Guest can also be configured to automatically expand across new
blade resources that are added on-tho-fly.
Figure 35: vCMP gue sts can exist on single blades or span mulhplo blades. Th ey ca n also be configurod to
automatically expand across new blade resources that are added on-the-fly.

Chapter Resources
Solutions
Solulion Solulion Title

Number
SOL 13092 Overview: Securing access to the BIG-IP system

SOL8537 Configuring SSH host-based authentication on BIG-IP systems
SOL8811 Configuring remote TACACS+ authentication for local BIG-IP administrative users
SOL 11072 Configuring LDAP remote authentication for Active Directory
SOL 13121 Changing system maintenance account passwords (11 .x)
SOL4139 Configuring the BIG-IP system to enforce the use of strict passwords
SOL2873 Characters that should not be used in passwords on F5 products
SOL5523 Configuring the syslog-ng utility to log authentication messages
SOL 13426 Monitoring login attempts p1.x)
S0L13123 Managing BIG-IP product hotfixes (11.x)
SOL9502 BIG-IP hotfix matrix
SOL 167 Downloading software and firmware from F5
SOL8337 Verifying the MD5 checksum for BIG-IP installation files
SOL8986 F5 software life cycle policy
S0L13845 Overview of the supported BIG-IP upgrade paths and upgrade planning reference
SOL9476 The F5 hardware/software compatibility matrix
SOL7727 License activation may be required prior to software upgrade
S0L13117 Performing a clean installation of BIG-IP version 11.x or Enterprise Manager 3.0.0
S0L13438 Controlling configuration import when perfonming software installations (11.x)
SOL 10288 BIG-IP software and platform support matrix
S0L14358 Overview of Clustered Multi-Processing (11.3.0 and later)
SOL9524 Viewing memory utilization for multiple TMM instances on CMP systems
SOL 14340 Change in Behavior: TMM is a multi-threaded process
S0L14135 Defining network resources for BIG-IP high availability features (11.x)
S0L13649 Creating a device group using the Configuration utility
S0L13639 Creating a device group using the Traffic Management Shell
S0l13444 BIG-IP daemons (11 .x)
S0l1689 Differences in trunk load balancing between BIG-IP server appliances and BIG-IP switch
appliances
SOL 14403 Maintaining disk space on the BIG-IP system (11.x)
SOL8865 Overview of the diskmonitor utility
SOL 14727 BIG-IP vCMP hosts and guests configuration options
SOt 14088 vCMP host andl supported guest version matrix
SOL 14218 _ _ vC;fI.1~~u<:.s.t_~~.':"1~~/CPU ~ore allocation matrix

Manuals
Manual Chapter
BIG-IP Device Service Clustering : Administration All
BIG-IP TMOS: Concepts Failsafe and Fast Failover
BIG-IP TMOS: Implementations Creating an Active-Standby Configuration Using
the Setup Utility/Configuration Utility
BIG-IP TMOS: Implementations Creating an Active-Active Configuration Using the
Setup Utility/Configuration Utility
BIG-IP TMOS: Implementations Upgrading Active-Standby Systems
BIG-IP TMOS: Implementations Upgrading Active-Active Systems
BIG-IP System : Upgrading Active-Standby Upgrading BIG-IP Active-Standby Systems to
Systems Version 11 .x
BIG-IP System : Upgrading Active-Active Systems Upgrading BIG-IP Active-Active Systems to
Version 11 .x
vCMP Systems: Configuration
vCMP for Appliance Models : Administration

Lab 11.3 - Administrative Partitions and Users

Objectives:
• Discover the behavior of administrative partitions and different user roles on the BiG-LP system.
Lab Requirements:
• Access to the BiG-i? system as an administrator.
Add Partitions and Users

Create new administrative partitions and users
1. Create two new administrative partitions called PartA and PartS usi ng either the Configuration
utility (a) or trnsh (b).
a. Create administrative partitions using the Configuration utility ...
b. . .. or create administrative partitions using tmsh :

tmsh create l auth partition PartA
tmsh create lauth partition PartB

2. Create two new manager users accounts called managera and managerb using either the
Configuration utility Ca) or tmsh Cb).
a. Create manager user accounts using the Configuration utility. "
Account Properties section
New: managera
Confirm :
When
Repeal
click.
Account Properties section
New: managerb
Confirm:
Finished
b. . .. or create manager user accounts using tmsh:

tmsh c r e a t e / au th u ser ma n agera partition - a ccess PartA
p a sswo rd manage ra role manage r s he ll tmsh
t msh create /au th user ma n agerb pa rt i ti o n -a ccess PartS
password managerb role manag e r she ll tmsh
Modify /Common/my_http monitor to check additional pool members

3. Modify monitor my-hllp such that it will check for successfu l responses from two new pool
members you' ll create in the next rew steps. Change the Receive String to Server [1-5].

Create Configuration Objects in PartB

Log in to the Configuration utility as managerb
4. Log out of any existing browser session with the BIG-IP system, and log in as user managerb
(password managerb). Ensure tbat you are working in parti tion PartB by examining the
Partition specificati on in the upper right comer of your Configuration utility window, just to the
left of the Log out button. Proceed only if your par/ilion is set /0 Par/B!
Create a virtual server and pool in PartB

S. Use the Configuration utility to create a pool and virtual server with the follow ing characteristics:
Object Name I P address :.!,or! Resource(~_
Pool httpbyool 172.16.20.2:80 Round Robin load balancing
172.16.20.4:80 ICommon/my_http monitor

Virtual Server 10.10.X.12280 I Par!B/httpb_pool
ICom mon/Pr_ Src_Persist
As you create and view objects, notice how they are referenced not only by
object name but also by the partition they are defined in .
Q. In what partition was pool member 172.16.20.2:80 created and why?

Pool member 172.16.20.4:80?
Q. Can the ICommon/mLhttp monitor be assigned to httpb_pool?
Q. Can you view all the virtual servers and pools you created throughout
class while you are logged in as the managerb user?
Q. Can you modify any of the configuration objects that are in ICommon?
Q. Can the ICommon/Pr_Src_Persist profile be assigned to vs_httpb?

You should be abl e to vi ew all configuration objects in botb IPartB and ICommon. And, although you can
open a particular configuration object in ICommon, you are prevented from modifying its settings while
you are working in PartB. You can reference objects in ICommon when you are creating objects in
IPartB. For example, you should have successfully added monitor my-http to poo l httpbyool.

Create Configuration Objects in PartA

Log in to the command line interface as manager and navigate partitions
The next series of lab steps wil l help you discover how to navigate administrative partitions wben
working with tmsh.
6. Open an SSH session to your BIO-IP and log in as user managera (password managera) .
Confirm that you enter the TMOS shell immediately upon logging in. Before proceeding, confirm
that you are working in partition PartA by looking at the information contained in tbe prompt. [t
should look something like this :
managera@(bigipX) (c fg- sync Sta ndalone) (Active) (/PartA) (tmos) #
7. View all virtual servers in partition PartA: list /ltm virtual
Are there any virtual servers in PartA?
8. Change partitions to Common and notice how the prompt changes: cd /Common
9. View all virtual servers in partition Common: l i st /ltm virtual
I Q. Which virtual servers can you see here?
10. Try to change partitions to PartB: cd /PartB
Q . Were you successful?
Q. What error message did you receive?

Create configuration objects in PartA using tmsh

II. Change partitions back to PartA and confirm you are in the correct partition before continuing.
12. Create a pool with the following characteristics. If you don't remember how to do this, refer back
to the tmsh chapter, or use tmsh help and auto command completion.
Object Name Members R,:s~~rceJ~)
Pool IPartNhttpa_pool 172.16.20.1:80 Round Robin load balancing
172.16204:80 ICommon/my_http monitor
O. Were you able to successfully create the pool?
O. What error message did you receive?
You should receive a configuration error indicating a conflict over the node with IP address
172.16.204. This node was created automatically by BIG-IP in partition PartB in an earlier lab
step (as pan of creating pool member 172. 16.204:80). Although you're now working in partition
PartA and can ' t see that node 172.16.20.4 actually exists, the BIG-IP system can, and prevents
you from creating a duplicate IP configuration.
Note: Partitions only impact BIG-IP administrative activities; they do not affect how the BIG-IP
system processes application traffic. In other words, the administrative partition a particular
virtual seNer or pool (or other configuration object) is administered in is irrelevant when it oomes
to how that virtual seNer or pool will process application traffic.
13. Change 172.16.20.4:80 to 172.16.20.5:80 in the above configuration and try again to create pool
httpayool. Use tmsh list commands to answer the following questions:
o In what partition was pool member 172.16.20.1 :80 created and why?
Pool member 172.16.20.5:80?
14. Use tmsh to create a virtual server in PartA named vs_httpa at 10.10.X.121 :80, with default pool
httpayool and profile tcp. Use corrunand completion and help to guide you through the process .
15. Back on your BIG-LP session where you are logged in as managerb, can you see the virtual
server vs_ httpa and pool http a_pool you just added in /PartA?

Compare Administrative Partition and User Role Views
Note: If your workstation is only configured with one IP address on the 10.10/16 network, open
the two browser windows to the BIG-IP self IPs using one browser (such as Firefox), then start
up another browser (such as IE) and open a window to https:1I10.10.X.31 for the third user.
16. Close all your browser sessions to BIG-IP. Open three new browser windows as follows:
a. Connect to BIG-IP via the management port at https:1II92.168.X.31 and Jog in as user
admin with password adminX.
b. Connect to BIG-IP via the external non-floating selfIP at https:II IO.l0.X.31 and log in
as user managera with password managera.
c. Connect to BIG-IP via the external floating self IP at https:1I10.10.X.33 and log in as
user manager with password manager.
17. Notice the User: and Role: designations at the top of each window.
18. Compare and contrast the Network Map view in each user role. Which resources do you see for
each?
19. Compare and contrast the Navigation pane selections on the different user roles. For example, as
an Administrator, the admin user has selections for System» SNMP and System» Logs, but
the Manager roles do not. An Administrator role has the ability to switch to anotber boot location
(System» Software Management» Boot Locations) or reboot the BIG-IP system (System»
Configuration » Device) but the Manager role does not.
20. On the admin user window, navigate to the Network Map, and switch the partition you are
working in using the Partition pull-down at the top left corner of the Configuration utility screen
(to tbe left of the Log out button). Notice that this pull·down does not appear on the views for
managera and managerb. View the virtual servers and pools in all partitions by selecting All
(Read Only( from the Partition pull-<lown . Notice bow the view changes yet again.
21. Close all your browser windows before continuing.

View Partition Definitions and Configuration File Structures

22. Open an SSH session to your BIG-IP and log in as the root user account.
23 . Save the currently running configuration: tmsh save /sys config
Q . What files were saved during this operation?
24 . View the saved configuration fil e,/config/bigip.conf, using more or cat . Notice that the virtual
servers and poots created in partitions PartA and PartB are not included in this bigip.conf file.
25. Stop viewing bigip .conf and list the Iconfigl directory. Notice there is a directory named
Iconfiglpartitions/.
26. Change directories to IconfigipartitioDsl and li st its contents. Notice that there are directories for
PartA and PartB, and that there is a bigip.conf file in each. View these two fi les and answer th e
questions below:
Q . What are the differences between the contents of IPartAfbigip.conf and

IPartB/bigip.conf?
Q. Why are the contents of these files different?
27. View the Iconfiglhigip_base.conf file and notice the folder specification for the two partitions is
not ICo mmonl but instead is IPartAi and [PartB/.
STOP


Chapter 12 - Customizing Application Delivery with iRules 12-1
Chapter 12: Customizing Application Delivery

with iRules
iRules Concepts
Overview
An iRule is a script that can examine and potentially alter traffic between tbe BIG-IP system and both its
clients and pool members. iRules are often used to select a pool to process a client's request. In tbis case,
the client's initial packets can be parsed and tbat data be used to select an appropriate pool. Additionally,
iRules are used to c hange tbe traffic as it flows between the client and server. In this case, the traffic
stream is monitored and changed as dictated by the iRule.
iRules give you complete control over wbat, when and how to change application traffic at any point in
the transaction. Application owners now have a programming language in the network focused on
application delivery. The iRules you create can be simple or sophi sticated, depending on your content
switching needs. An example of a si mple iRule would be:
rule IP Address
when CLIENTSS L_ HANDSHAKE
if { [IP, ,remote addr J starts with "10." } {
pool /Common/t e n-pool
else
pool / common / custome r-poo l
This iRule is triggered wh en a client-side SSL bandsbake has been completed . Then, iftbe client's IP
address starts with the character string "10." the connection request is seat to a member of the pool
tenyool. If not, the request is sent to a member of customeryool. Tbis example uses tbe client's lP
address to determine what pool should be used. Rather than using tbe lP address, other iRules could
make the decision based on (be client's data.
iRules can direct traffic to specific pools, pool members, or specific devices, including port numbers and
URI paths, either to implement persistence or to meet specific load balancing requirements.
iRule syntax is based on Tool Command Language (TCL). You can use many of tbe standard TCL
commaads plus BIG-IP system extensions to help you manage traffic more effectively. For information
about standard TCL syntax, see: http://troml. sourceforge.netldocJtcVindex.html.

12-2 Chapter 12 - Customizing Application Delivery with iRules
iRule Components
iRules generally have the following simple structure:
I. When a certain event occurs ..
2. . .. If a particular condition ex ists ..
3. .. .... Perform an action.
Overall, iRules are built from three components: events, conditional statements, and actions. Events
define what occurred that caused the rule processing to begin. Conditional statements use relational
operators to process data and return a Boolean (true or false). Commands or actions define tbe BIG-IP
LTM System's response to the results of the conditional statement.
rule <rule name>
when EVENT (
if { condit ion a l _ statement } {
act i on when cond iti o n true
- - -
Event declarations
iRules are event-driven. Wben various events occur in tbe client-side or server-side connection, the BIG
IP system triggers iRules based on those events. Events include CLIENT_ACCCEPTED, wbich occurs
whenever a client has established a connection and HTTP_REQUEST, wbich occurs whenever a client
sends a valid HTTP request. Within the iRul e, the event declaration includes tbe keyword "when"
followed by the event name.
Operators
An tRule operator compares operands to detennine a relationship. Based on the result, action can be
taken. For example, the following statement, defining a goal to use a specific pool for clients with a
specific IP address, can be accomplished witb the iRule pbrase below.
Goal: "If the remote client address equals 10.10.10.10, send to pool my--'poo]"
iRule Phrase: if { [IP, ,client_addrJ equals "10 .10.10.10 " } (
pool /Common/ http-pool

The table below lists the some of the available operators that you can use within iRules.
Operator Class Operator

Relational Operators contains
matches
equals
starts_with
ends_with
matches_regex
Logical Operators not
and
or
Rule commands
An iRule command causes the BlG-lP system to take action. Command types include:
• Query commands
These commands search for header and content data. An example of a query command is
lP::remote_ addr, which searches for and returns the remote IP address of a connection.
• Action/modification commands
These commands perform actions such as inserting headers into HTTP requests. An example of
ao action command is HTTP::header remove <name>, which removes the last occurrence of
the named header from a request or respoose.
• Statement commands
These commands specify traffic destinations such as pools or URLS (for rewriting HTTP
redirections), An example of a statement command is pool <name>, which directs traffic to the
named load balancing pool.
• UIE commands
These commands are functions that perform deep packet inspection to either directly select a pool
or specific member of a pool based on the result of searching for any data that you specify in the
command. An example of a UlE command is decode_uri <string>, which decodes the named
string using HTTP URI encoding and returns the result.

12-4 Chapter 12 - Customizing Application Delivery with iRules
iRules Events
Events define multiple points in the client's session that can cause the BIG-lP system to impact traffic.
Events are defined in many groups including: Authentication, Global, HTTP, TCP, and SSL. Each group
has specific events that represent stages in the communication between client and server.
iRules and Client-Server Communication

There are a number of ways that events can effect client-server conununication. As events occur, the
BIG-IP system can decide pool selection, redirection, logging, data manipulation, selective address
translation or most any other change.
Not all actions are available at all times. You might want to create an iRule that sends a redirect command
to a client if the server has sent a File not found message. But you would not want an iRule that sends a
client to another pool afier the server connection is established.
Detailed descriptions of each event are provided on DevCentral.
Event Examples
EVElntT~ _ De_script i?n EJ("l'TlpIEl~_
Global Global events deal with connection establishment RULE_INIT
LB_SELECTED
HTTP HTTP events deal with HTTP requests and responses HTTP_REQUEST
HTTP_RESPONSE
SSL SSL events deal with client authentication during the CLiENTSSL_HANDSHAKE
initial SS l handshake. iRules responding to such
CLiENTSSL_CLlENTCERT
events let the BIG-IP system redirect clients if they are
not able to support the encryption 'level desired by the SERVERSSL_HANDSHAKE
site or do not have a client certificate.
Authentication Authentication events deal with client authentication AUTH FAILURE

prior to establishing a connection with any pool
AUTH ERROR
member. Depending on the stage in the process, the
BIG-IP system might redirect the client to an alternate AUTH_WANTCREDENTIAL
site or silently reject them.
AUTH SUCCESS

Responding to HTTP Events

HTTPeventscovera variety ofHTTP exchanges. You can develop iRules to take a spec ific action at
specific points in the communication process between the client and server.
Example of an iRule for a HTTP Event

In the example below, the iRule chooses a pool based on client's browser's user agent. When the client
sends an HTIP request, the B IG-IP system examines the User-Agent HTTP header. If it contains the
string MSIE, a member of the MSIEPool is used for the request. If the header does not contain the string
MSIE but does contain Mozilla, the connection is directed to MozillaPool.
when HTTP_ REQUEST (
if (. [HTTP, :header Us e r-Agent) contains "MSIE" } (
pool !Common!MSIE-FoOl
elseif ( (HTTP, ,header User-Agent) contains "Mozi l la" } (
pool !Common!Mozi l la-F0ol
If a client 's User-Agent does not contain MSIE or Mozilla, its traffic will be sent to a member of the
default pool if it exists or discarded if it does not.
iRules Resources
DevCentral
Resources for iRules and Syntax
F5 hosts an interactive site designed to help users implement iRules more quickly. Additional
documentation and feedback are available at http://devcentral.rS.com .
Configuring iRules
There are a variety of tools that can be used to create iRules. You can down load a copy of the iRule
Editor from DevCentral, use a simple text editor, or use the Configuration utility. Regardless, be sure to
create the pools that you will use in your iRule before creating the iRule. After successful creation of the
iRule, then you can map the iRule to your virtual server as a resource.
Note: When referencing objects in an iRule, make sure the object is created first!

12-6 Chapter 12 - Customizing Application Delivery with IRules
Lab 12.1 - iRules Lab
Objectives:
• Con figure a series of iRules, pools, and virtual servers in o rder to demonstrate a variety of rule
features and functions.
Lab ReqUirements:
• External lP address of the virtual server
• lP addresses of internal nodes
Use an iRule to Process Requests Based on TCP Port

Create three new pools
I . Using either tbe Configuration utility or tmsh, create three new pools as [ollows:
a. iCommonipooll: One member at 172.16.20.1:* (all services)
b. iCommonipool2: One member at 172.16.20.2:* (all services)
c. iCommonipool3: One member at 172.16.20.3:* (all services)
Create an iRule for rcp port checking

2. Create an iRule called Rule_Tcpyort:
Properties section
when CLIENT ACCEPTED (
i f ((TC p~,l oca l-port l equa l s SO ) {
pool /Commo n / pooll
Definition
e l se if ( (TCP" l oca l -port ) equals 443 } (
poo l /Commo n / pool 2
When complete. click... Finished

3. Create virtual server ICommoo/vs_tcpport and assign it iRule Rule_TCP_Port:
Resources section
Verify behavior through statistics

4. Open a browser session to http://10.10.X.103. Which pool did you connect to and why? Which
node did you coonect to?
5. Open a browser session to https:1110.1O.X.103. Which pool did you connect to and why? Which
node did you connect to?
6. Open an SSH session to IO.IO.X.103. Which pool did you connect to and why? Which node did
you connect to?
7. Verify where traffic was routed using statistics.
8. Close your SSH window to IO.IO.X.103 and terminate the session.

12-8 Chapter 12 - Customizing Application Delivery with IRules
Repair iRule to cover all desired traffic scenarios

In this next section, you'll see what happens when an iRule itself does not logically cover all the scenarios
that might occur during traffic processing.
9. Cbange the Default Pool setting on vs_tcpport to None.
10. Try to open an SSH session to 10.10.X.I03 again . Were you able to connect? Why or why not?
II. Correct the iRule Rule_TCP_Port to bave a final "else" statement that will provide a default
pool for all traffic other than http (port 80) and https (port 443). Change the code to this :
when CLIENT ACCEPTED {
if {ITCP-;-, localyortl equals ao} {
pool /Common/poo ll
elseif {[TCP, ,localyortl equals 443} {
pool /Common/pool2
} else {
pool /Common/poo13
}
12 . Try to open an SSH session to 10.10.X.I03 again. Were you able to connect now? Which pool
and node did you connect to?
STOP

Introductions
Instructor:
Name:
• Experience:
Administering BIG-IP vii
Students:
Name:
Company:
Job Ti tle:
Industry experience:
Network Expefl£!fl.Ce:
F5 Producl Exposure:
Classroom Facilities BIG-IP Product Suite
EmergencIes
...
Class Roste(/ Slgn In
Cell phones, email and mlernet use
Bre aks and lunch
Punctuality
1
- ---
--- -
.......
\Mlo" ,.:..,
-
~
-.
...
1Rules IApps. and IControl

Side conversatiOns
Food and beverages
Parking
Restrooms
$mokinR
.!..
Application Delivery Controllers BIG-IP Virtual Editio n (VE)
• Capability VMware
vmware
£$X aod ESX,
•
Expandability • '<C1ood CITRIX"
Flex.ibil ity Cilflx •
..
ViPR ION 4000
"',
• XenSer.e<"
Microsoft
• Hyper-v 00 Wmdows
8JrE7qh,a\.
Windows
Hypef-V-
unux. KVM
• Red Hal Enlefllrise
• CenlOS
CentOS
4 000Se nes Arnawn
3900 • EC2
2000 ......
F5 Instructor Led Training Courses F5 Certification Roadmap
.. ~
"-
Course Agenda Chapter 1- Setting Up the BIG-IP System
Day 1 Day 2
1. $vt11"i up thCli ~ IG-If> Sy.>lem iL Dep lDymg Applil:;llltll'l SeI'VlCe'll
w ll~ IApps
P ~ltl l l a (f1C with LTM
9 Jrcnlbie5hoollng I~ DI G IP
3 LISlnc NAli end $ NATs .,.,.",
4 , Ul1hl!i tMe Jr.tfic Manal:e rnell\ 10. lJIe 8l G·IP Prod !la ~
S/IQII CtmeA/
oIodmi~~n ng itlr, l:IlG 11'

5. Mur'll'lurn'tj
~II. TJUofflC
" .,."'m
-
6, Beha;.,or wllh 12. CU5!Oln Wng ApplDUm}
Pro:A1le!1
OcliYery wllh I Rul ~
1. MQOI)wl& IrlJi'lflC l{e~-.tMO r ",nil
Packet-Based Design
BIG-IP Full Proxy Architecture The BIG-IP System
Encrypted Unencrypted
_O ...- - ........ "'.... " .. •· .. ·.. ·· .....;.....;...:;.;;.~_Cl-_
D -';~;":;';;';;';"... ......... -........ ,.. , lJnl::~

1M
0 ••-----..........................- ..........
IPv4
-
--.11:• . .•
BIG-IP Application Delivery Controller (ADC) LCD Panel and LED Indicators
BIG IP 7000 SERIES

STATUS _ _ A
ALARM l
POWER1 •
-< v' )
1. MafIGQ"'l iMn1 \XJIt 6. LCD d i91X.:i'f POWER2 ~
2. USB pan. 7. LCD con1 rd oot&ot1lJ. ~ •• V

3. CDI'IMlIII pM (.aena19-P1~ nr RJ >lS ) 8 TMM IS'Nilch n"iII'Illc;d;
1 01 t~100D !:1hIIIT'oe(
Fallovef" poI1 ( se ~1319-p in or RJ45)
~I SF P
5. Irxl k:;l lrn lEDs 10G SI'P+

4 0Q£Q SFP-
Initial BIG-IP System Setup Configure Management Port
o eu nne<:l VIa
I I console
US(: LCO panel
•
Default MGMT IP address/netmask
8IG-IP: 192168,1.245/24
• VIPRION ~ 192. 168.1.246/24
config # config
•
BIG-IP Configuration Tools License the BIG-IP System
Graptlical User Interface (GUI)

I•
a.k.a. Configuration uUllty
htlps:fI <management-ip-8ddress>
• e.g. https:jj192.168X31
Command Une Interface (CLI)
.. -
Ii
f l!l ~ nse Ser;er
ac1'yale F5 com
LU1UX bostl
• Automat IC
TraHic M·illl.Jgement Shell rlmSI]!
GUI and CLI typically used interchangeably

oe Start with t>&-% I'8QIBUlihon key
Generate 00s,;115 0"1 DtG-IP system (ir.dudes I . :f ation key)
GUt used almost exclusively for APM and ASM o Send dossier 10 ~ S tceru;e server
o Generate hcef15lJ! Mid bong back to BIG-IP system
" F"nie/:llieerl5ing ~5S OIl BtG,IP sysl'lnl

tI"_ _ 10 _
Provision Resources Install a Device Certificate
---
"""'""',.- --
,
--
Use BIG-IP self-signed cert (default)
Install your own cert (optional)
-
,
~ Mn11n -
I
e
~_Io ,,", ~ ~<)oJOOIQ IIlf ~
U.-...- fIftlUi:s _ ! ~ , I~, _ ...h__ """'lEO ,

~ ~II't"r\"" il .. I.... ltft')ll;~· o.i !l"""l I r ~1n."' I ' r~
.-.t.II Er »Do_rnll1lp1(i mod lJHDtiNI... ... _~ '($1o.IoCtIII
~ _ _,"".;""" M ' ''''LlIllltI __~ C>l Ijad:>
•
Platform Configuration Network and HA Configuration
------1 Configuration Methods

~ . nd l
_ "",I Setup utility (wizard)
~= ,::-=-=-=--- Salflh; I
'1--
-"
Traffic Management Shell (tmsh)
---
"" .".
Classroom Network Configuration Welcome Screen and About Tab
-_.....
-_ ..... _._--
--_
:=-- ---
""::z.-c::.=._"
... _-
. _-_.
: -~- ...
;;=.:-=.. ----_
---
..
--
~-
:;;::-
-==:"'...:.::=:
-. ".
Archiving BIG-IP Configuration Files
1......,.,""',...
II
'-
Fil.,.,..
BlCoF I I 4 0 BUild 238 4.0
DevCentral BIG-IP System Setup Labs " ,
httPS:j/d""""nllOU5.com/
I.JIb 1.1- CQnOC_ IoIQMT Port.
F5 blogs. Wlki. podcasts, tutoria lS, discussion forums l'lJItoo:o"" ",,1
· 1Jn 1.68.:0:31/1$
110 lQ.X 31/t6
1O.JO l.3.3
Tech tiPS, code sharing, developer resources, daily
news • LJc.eflDe D'II\>1IIon,
~Cf'n~1
d"...,
uti t..2 . AC(iva(O! 1l1Q..lP ~1In'O
~ .-.:I
"1.,.. ....
3
Free partlclpalion; requires registratio n ~b L3 - N6t"f1011l / HAc:.,.. UH ffH1 . - .. I,

vVIN I<TttornBl on ~ 1.2
Excellent resource for iRul es examples, tips Y\A"I extem.hm l"IC1taot- .Ll
"""
l r.!.t6 LlV16
-""
HJII i )(l VLAN ~lIltrNtl
11 l' ' . l. 33
t ab 1A - ko!;\ I><Id ~.Up
• MOM1 /1III 1P aoGeoIllTItIII a/IIll4hl

• I!-Yi. IP 10 ln1 lnx....~ I.Q
Your Classroom BIG·IP Lab Environment Chapter 2· Processing Traffic with LTM
.------'--~
'::': ~~
__ ,--Soot'P 1D..1O~ !/ 16
/\)It l..&Klo.).:,... 22 & 4.0 ,,*

o i~
~ !>o.t., 1O,UU.J.).
f\)O\IMtlo,_ " <lallftlo
-
" _""",,,0,1_
,...,
17;>..18$ 11,1'"
tn 11)1.»
,....t'WO_OtI....
~ .:::. 112 16 _10 I
t ~ 112. 16 2Dl
_ _ U 2.I6.20.3
l oad balance lIalfie
MonnO( ser~f health
'Rule!.
nrewan
Pools, Pool Membe rs and Nodes

Processing Traffic with LTM
O --D
la("ntn~-:n~ B.IQ·IP ConIIL!U';.JU(l'It ObJOClS T

111:1:
CollllgL"fl8.I/tIIUSI ~&llnd rca
lir"llk;rstl)IIr.Iu1~AllPlIr..lJon !mUtt Fk"'~
I I I
lDIi:Jd Ekllancin~ AooIIQltlOn Trnfl'tc wl,n lTM
"r\.IvlIOR 1.,lt'(: l'fOces$lng ...... \11 SU)1 151 ICfi ::Jr"\tl Logs 172.16.2Q.1 :80 172.1§.20.2 :80 172.16.20.3 :80
Truflic Proc~jr'l( L.Jl) J

Node '" IP Address
J
Pool Mt1TIbet - Node -+- Serv.ce Port
-+
.. - J" l R Relate<! poUt members.
Pools, Pool Members and Nodes Virtual Server tKl fll l .-w.15.com
o-g 'L,stens' for and

manages traffic
I:lH : _ .. " IP address:port
Normally associated

wrth a pool (LTM)
-
Node 172..1 5.20.3
....
Virtual Server Address Translation Inbound Virtual Server Address Translation
-
0 0
~,,-~.
-~
Destination translated to
pool member based on
~ load balancing decision
~-
~
1 T. . . . .LII:ofI
~ ~ - 1
~-
112..U1.2ClH1O 1·/ 2..1Eo2lU'"8O H;!'..lti20 3 :80
-
Outbound Virtual Server Address Translation Inbound Virtual Server Address Translation
-o
20H H U .20 2OI1.l1 U 7.W
-o BIG-IP translates source
back [0
Can be different ports
virtual server address
.
Outbound Virtual Server Address Translation Not Just NAT. A Full-Proxy Architecture
o -
Q
(!;IG. I' I I _
I EJirn[lI.~~I.I .. 8 IG-IP translates source back

to virtual server address:port III
=
Separate clllitoll .ar..d a.eNI3[ connections
1foIiI ~!_ " ~ _

~ . ... _ (_ IO(!I(;·II')
III
4",_",
-
Configuring Pools Configuring Virtual Servers
..- , --
~~.~ I
1-
-- .
Gi- 1- ...,..
-'-1
_.
-- . ' -
=tJ-
,.,. ., --- J
Tp _ 1"-"""
• _ .. l D l~ .•. l00
~-- - I
-~. -.P~ Saol '"

""
... ................... -.
-
. . . . t,II ~ . . . _ • • •
•--l .~
1 ....:f.r- ~r.-
"
Virtual Server vs. Virtual Address Distributlng Traffic Across Application Servers
--
-
- -
•
•
_
eo-
11.1)01.
_to. ", ...
"'"
-
......'-
BIG~IP Load Balancing Methods Round Robin Load Balancing
w
Statio
• Preoe rined seUings
-o Dynamic
Observed oehavlDr
• Server ca pacity / load
Next four
."-'
'1-., '3
4 4
Ratio Load Balancing Viewing Traffi c Statistics
o ...
[,::...:.. -
-- ?
1---'
~-:-
-
t-::
....... __
Traffic Summary Statistics
,
-""""' ---
---.....
Local Traffic Statistics
_..'- "..a_Qk(:_o..
-
........... "" tuall«'o'l't or
~ ... _dIecI~
. . . . .1
'"'"
"•
."
.... 0::..1_
=dioo,"* '""""
J
i-c:-.-~ - (-.0 4e h.lpJ>OOl
11.... "- 1_ 1NO ;I"". . . CCifN«b'o 0
172116 20.1:60
.. ~~
~ .............. i'¥IlorSNAT
H ..... 172.1620 ,280
.. ,.,.......... _ yb
:l C~~ ."~ 172 1620 380
•
,. ,~ ..
"
•
Traffic Processmg Labs \ Chapter 3 - NATs and SNATs

2 .1 YlrtwI~~.,,1I1'oo1l: lIIb
C':t... ~ ... 1IIIlt.nIIl!!l$I..J»OI

• O'!I )IM -' l Q..,O.:u.OO!\O
• I!!lIJJ)OOI'IO"tt U2.l£.20.l ·~:80 -o
,... ~
· 0...."""' .. ...,.. _ _
• ~~~'" itWI· --. ' iii' .ct;
refr~ h
~ .::"""~ O~,~o~~~,," .~~,·,~.~~,Mj~ 1
• 1SJfII1IJ • .lD. 1!).K.100: "~
• l"tD!I~.1I"111l1'·
CHiil_,",-JI(\Uf """,/If1Il&.pow! '~~~~~~~~~~~~~~
'T]"'"
I"1I:.tCI 1110 I· "l •• )e.~
l.J 44l
l' • ""-,,-/-2-,,,"1 1f:!~.ltL: ...... 112 .l,U•.:.1oU.1
T""t ~
• ConI.n. 10 wn.t --.tIr. n./.'iI....

• Ye~\rI,. II: ..,.SlJ!.' ~lO;1
2.2 PK;""' o..c..w lAo!) !09\1on.1) U1_ItL.M.1 171JiUIU I~

Understanding NATs
,...--....,.
NAT 0riJin AddrMl>

~
201.10...1.103
t12...16.20..3 !----"l[lI.
~on : NAT
-,o1..JO.t...lOO
1 H+H' - - .. ,..
Qrwlo"CIIlll~K
~111I~t lOnal 'l!sl!!ns"
· r..tfI(; ... I IIIf<J IO ~_
• " ... r ~: inU ""'IIOM .... _
Understanding SNATs VS Address Translation and Routing Assumptions
IfI[!I!I.~ M"-dI!,!iif."+
""'"
10J.0.1.30:2181
O'«',t
10.10.1.30:2181
1IbaI~
l /2... 0..0'1' t·w
--
0"""
J O.10.1.3O
,,'-""'"
-
o
202t1D!Dmm2 : at~ !) l
-----
Source:
rn ,..;Kt.ll
172.16.20.3:3155 -1j"u",M 4~!!~

Oleo!
10.10.1.30:2181
\r~"'",
in 1("1 t tP""l.<or·
De fault Gateway Bypasses the BIG-IP System SNAT Ensures Response Goes Back via BIG·IP
A .Ii 8 Jjii
10.10.1...30 ..1.0301.100 1O.lil...1.3O 10.10.1...30 1Q101111O
••,#1'''' fA
• ,'anhA 4~~~
10.J.O .1.30 172.1fI.2'D.l
10.10.1.30 lO...1O.1.roo .112 11U.J3
\U'lf If\
Clients and Servers on the Same Network SNAT Ensures Response Goes Back via BIG-IP
172.16.1.30 lr.!.l6..U OO 172.16.1.30

."
l1'_t6..2Q.1 172.16.1.30 11' ut-:O.l
P 1~ 1I
• 172.16.1.30
@M!!i ;,p 4111'-11 172.16.1.30 171.1C1.1..33 U2.1&"2O...1
._ n:1 \.62t1.t
Configuring SNAT on a Virtual Server Translation Addresses: SNAT Auto Map 'is. SNAT Pool
o
[JI'1ll1n JIoIX......"lI
Chen\$ 11I/.I1 CIlfIl1IOCt
. ,,'
to the "frtual St'l"o'er
,u,.uro
• Tnlr!dI1l!d MidlIISS1I
IP IIddreM:port
on ejJressVlAN
II' ., .. "
(0 'TJ I ~'~
®
172...1.6.20 1 172.16.20.2 172.16.20.3
-
""""
>7 2.1 6 .20....\ 17 2.16 .](1.2
Configuring SNAT on a Virtual Server SNAT and Port Exhaustion
SNAT ~ Source address and port transliJlion

SNAT Pool AutQ Map • SIt,til ij r to PAT "nO f1;\Pl
_-.
f)
..
Associate SNAT pool with virtual server
... ....
""_hlip
~ r ~. t DA . t:IO
-1
If possible, source port is preserved (derault)
1O.10.1.30:21~(lln ., 11X1:M 172, 1(U ~22

" .,
'172..,&2'Ct.l.ltO
~- • ~,
Port IS 16-biL unsigned integer in TCP/UDP header
• Mi:mmum 64K tOOClJmlf1 t connections
Il'':=:~ ,;. I ~- II
1 SNAT address per 64K concurrent connections
=
"- - - . "-
Monitoring SNAT Pools Using Statistics Address Translallon Labs ~ 3 26
:u HAT LBb .........
., ..
DrliIw N ~T lll.1DJf.200 -'l> J r'2..:1EJIl.2
0
_.-
-, ~
3 2 SNAT Lab
"'rw A,u LD~ P
•
r~D:r'lr,rWJr.lI1rtH1'1~",,*,~
CCI'~' ~ :;N.>.T """""KIlfl""Jr11l1 "

25
-
1n II" I "'"' IUIT_ 200.J,1..2
- _. -
llU:lL"'OIl
~ -- '
• T'"'.ll tRfftolv<Ol W')" 'itu.T
SNAf l\tl(>1 La b
~.11INO SNAJ pool
~I~ MII~ C""_
.OM' ....
n ::t ll!l:-tl.l
~ ~
- "" ,. u ~~ ~II f1a:'lS'''''I,Io,no'o\li;l!l;l PooI
~
fKl tt.lr1rr'1flr .. JtItI~ '.f.Ii11lO[ll
~vco~ r!''1'If-'I'IIIr.1SN~1 PIID'f..., ,,·j·;~t
I n I L».l I7~L~ XI. ~ 11:L10 .Xl. l
Chapter 4: Using the Traffic Management Shell (tmsh)
.",. .. .... - ..........

__ ~ l . . ~ (l . .
u,.. .. · . ~~WLl v._b~tp (
T1~ '-' l .... . a.~rp ,
-.-. ~ ''' -,
. .
- ,-
de.tJ..na tJ.on 10,10 4 .100;bt tp
1p-prot.ocol tcp
_ _ lr. ~5 ~ . 255. 25~. 2~~
-
pool bttp..J>OOl
p~ofil •• r
ttp r I
. 0>11:0'1 0 0 . 0 0/0 .~ ,
,,.
-~
•
•_ _...1.._
lftl ~
._-- -
._
Terminal Access to the BIG-IP System Advanced Shell vs. tmsh Access
~~~ LII'IJ~bII[Jl9"1~lri1ffw; M~lT'IIIr" ~...L~~."'-'----1

l oq~ .. .. loloX
Disabled Os1n9 lr.eTboa~d-l"teractl"' iOuUientlcat1on .
• No acc06& Password:
-
La.ot log~n. nil Sep 12 ll'05;5& 2011 fram 192.168.430
froot.f!blgip5;AcUv.. :Bt..o.nd.a.lon!!) conhg I tAU IroI.L.to."-'
-......
Advanced shel)
•
ijlIfri/'IOOIIIIllr;;rrQ •
• 1~1c M:annFment •(root<!blglp5;Acuve;St..o.n6a.lone) contig I ...... " . , .1'. _n• .,-n~~'p.
"""-' sy. maniOg_nt_ip 192.168.4 31/16
-.....""
("oot~blglp5;Acti..-e;St..o.n6a.lo"e) conti,! I ,...10
Imsh
ll11fhr:;MIm~nl
& IMrtar.lnlonly
No _
, logi n • • i dIAl ..
081 no k"yb4aN_ i" t.eriOc<.lve a"u...ndca~lon
l.io.st log1.n:'rim S<tp 12 13.23'432013 fram 192 1H 4 30

root.l' (blglpJ) (cfg-."nc ~und.lo n. ) (A.ctive ) (lC~n) (tmo . ) I
tmsh Overview Hierarchical Structure
Hierarchical structure o Verb-object syntax

••••
••••
-- •
•
•
•
•
•
•
•
.,
Navigating the Hierarchy tmsh Help
• _.
Command completion (tmos H_]' P~.
(root@biqip4: Acti va: Standalone] confiq

Command abbreViation (tmos l~mlj (,r aoUl. ~
.- FlT1kF
Command help
(tmos . HOI), prc t U.
root@(bigip4) ... (tmos)' La. p;iC' L < .... .......~
root@(biqip4) . . (tmos lba.pool) I • •dt UtllltMol

(tmos . Hmo) \'
1M"
root@(biqip4) . .. (tmos lba) •
1-' .Lon . fr....,.." .-to " 'O< Pl, ... ~ ",-, ,_ , .
,.. ''';'''0..... 0'
-'LI.oI .,''', , _
......... .- _ l
root@(bigip4) . .. (tmo8 .net.vIan)' / Till_roc(
root@(bigip4) ... (tmo~) I • Lq

"""
Iroot@bigip4:Active:StandaIoD~J con fig
• p....
.-",(M.',')
..,....
(lC -><_. , .." , ,,, •
,....
I i ...
I
.."6.. •. -" .
~_ 1<"' ......... I _ '-'I
. ",, - _, ~_ n ...... 1 _ 1
,J _~ , - .
Some Global tmsh Commands tmsh Changes Reflected in the Configuration Utility
list
show
modify --.....
create
delete
save
(tao.. . lbl.pool)' e:o..... ot. n -e.n _dol IHi' l6"_20.1::l:DI
(t-o" .I t- .pool)' ~,.. rL -..bor.... ~doli In2 16" ~O.2::I:-II1
load
J (t-o.. . l t- .pool)1 l..nt.
Itm pool PI (
,1.
help
"",mbers (
172 16 20 l:ht.q> addre .. s 172 16 20
exit / qUit
172 16 20 2:ht.q> add.1:e"" 172 16 20
(tmo" Itm.pool).
"-
Creating a Virtual Server BIG·IP Configuration Files
/config/bigip.conf
• /config/bigip_base.conf
- Virtual servers
VLA N ~
- Pools
Interface:!!
- SNATs
SelrlPs
- Monitors
Device groups
- etc.. etc..
(t.o.) ' ..... t... 11:& ... lrt.;o..ll..1 .... UfiIlUU n
~O.10 .1. . UIO 10 pooa1 "
And many others ..
BI G-IP Syste m Configuration State BIG-fP System Configuration State
_.
~_ ...,-. , _ l . v o n 1II"".~ ......... m .• ..".
1_ , C~ ... te
1-" ...... Iq.
Il~
-".
... ~ nuol ... _ htq.. do. . unauOD 10 10 J 100:44).
--
l~iI ........ Il too v L<. ....... 1 v _ _ I><.q.ur
1 tHt,-1'ith~"'P.'-.ftIl~ yi.>< U ••l _~c IIc"""".1"5_ht ~~, .....
.....
''''
1.=
T.". · ... ~
........ 10011.Uoo
.. .
tlH H++I : - .:. t!i
BI(rIP System Configuration State UCS Archives
creatlolOd 5 y .. coo.t:l.<Jll.
cre.u. pool te .. tJ>OOl2.
/ var/ localjucs/
" Mp I[ IQst...JloC1ll
lbo pool U!"~J>OOll.
? lbo pool U!.~J>OO12.
ltD. vl.rt" " l v"_h~t:p,,.

Creating a UCS Archive Single Configuration File (SCF)
~ l~ '_'1_ CQotL(t/i 0.(.,, 1-'

.............-.
.-
I~- 1-..-
1- '
I ~.........
"'" j defauttsj
1=-
--- j ..........
1-·
---
For More Information (AskF5.com ) tmsh Configuration Lab ,.
UMh almmand comp\el ion "nd ii'f'llal

• _ _ pool
(
;
'
~
1
I
l
r
• M ... /s ~ OO"II.1;
• _ '<:t!<lflc.ltllCol:(lo"ln.Io
• C~k~S_ssh
· ""'/!IJ"II('</"" .
· .... ~ .c"'r CO'~"' .,,j
• I)..... V(:!'; ~r>d SCf' .,t'I\IOWj.
• lno6I., boI h a rtroJ"" flI;j I)PJ*
• b<1ract ... od~~ .... UCSI"olor.""'!1IiI
L. ....- ..
Chapter 5 • Monitoring
o -o
•
\ .. _ =
Monitor Concepts Monitor Concepts
TYl)es of ResoUrtes Ty l)eS of Monitors
Nodes Address check
Pools Service check
Pool members Content check
Llnks 1
ClJP.<:;k ..
e . _ - " '001« ,.
e -~ r "'_""I10'\' '
. ' ~"'''' In'''''''''
'GTM "". l oo' Cootie' ",
Address Check Monitor Service Check Monitor
.::. • 11l.l6.20.1
.::. 172.113.20.2
.::. • 172.16.20.3 172.16.20.3.443
l-\6a/lhlest Pi n ~ an IP add ress Health Test OJJen9 . ~ l ion to poo l mem t2r ~ ~'IIi ce )
f1I$I rm mes AVilllabllity 01 • ~ce Determines
Maoo node oUlln<' II no response? Mi)rl\s poo l member (sel"ll lCe) o Hline
II no respo nse?
• Maoo pool mo: ,.100 rs on that nod e olfl'r1-e
Example rcp Half Open
Example ICMP
Content Check Monitor Monitor Interval and Timeout Settings
Interval - number of seconds between each test

Recommended timeout = (3 x Interval) + 1
172,16.20.3:80 c~~~ur.IIO~" t
Intt >W1
i-lelllth Test Open connection. send com rTkmd. exa min e respon se
De lermi ne; AVilllab llity of a sel"ll'ce and appropnate content
If no/Ul'llaLod
Mal1ls pool membe r (service) of/l ine
response?
Example tilTP test test lest test test test

Creating a New Custom Monitor Assigning a Default Node Monitor
(..:;" :.- - _ .. ,, I
-
~
IItt! ...-,,-
-- -
----- .
1-
I'~
~.... -
c..... _, ~
Ir.;;:--
I
!I ""
~,I.'" I
----
I
---
--
r--
---
, r--
"-
-- 1·'I:i~
• •
.. -
~
I
Node Specific Monitors HTTP Monitor Parameters
--
ll2..t1l2ll1
-
.-4IoIJj.I""
• ..:n'll
H71'1;'tJ1
-.
Assigning a Monitor to a Pool Pool Member Specific Monitors
H'.1e20.190 17"' HI ~'l1-:'MI JJ:l'1P,;!I()o~OO
.""....,
I lIn~ J"rem IlOc>I In/lllllllflCIoTIPool
.iwIIl~ •
Iht>il<lllrnJ rn~
"..,.,IIDbID
--
. ~. I\IICl 1"1_"lW • ""_M iLl
_M
l1:<'..!!Ut)..1.l!1(Jo lr;!'-1'.J :':!I).:;.!,l.lO
Viewing Monitor Instances UsIng the Network Map
II...-""-.",:my_....
vs _http
• htto_ _,
-
. 172.16.20.1;80 Pool Member
172.14,2(1 I f 72".11 .:ilLl III
. 172.16.20.2:80 Parent Node
.-....
!11.15_2'O2 172 .16_2'0 _2 &Il
••_.1.72•.•"•2
..0•.'.,8. 0. 172.16.20.1
172.1'-""0.3 172.n.21J,3 10
.m...._
.iJt."".~iIII
• ""<I SO
~
l l t _ ..
Viewing Member Availability and Node Status Determining which MOnitor Changed a Resource's Availability
"....
•• ,--
--.
"'
•••
---
--'- -----
[ "......-d""' ~
'"Hi-'''
-..-..........,
, ~-.., ......
--.
---
.- -
- '"
0·-....tJI......,..
,._1""
:....... "
.'.-
.........
- .._11--
•. ...
.,;111_
--- •
. ... ~ ••Il
• i lt-t4JIIII.-.
,
10"
.IDII-.,;tIIt
• (d.""""
J --
--
_...,,............,-
.~
",,,,..,
.-..
.....
--
_ _• __
......... -- ""'""'-""'- ~
-- _
_ -
i_. ; r_ ,_tr,o ....
. . . II _ _ .=

..
. !_.
Health Monitors Labs --l- 5 2CJ Chapter 6 - Modifying Traffic Behavior with Profiles
IIIIIIIII!!!II .
o
-¢
ID.11k1...lII
GnDc il (Vm:III ~ Ill.lli.II
~ ...., Server
• ~.... ~Minl "'IIUf'.jtors
A.o.slgll o. OS'lloaJl1'l!l6l1llo3f'llW<
• Se11arnp1ll5~nDo:le".-.nD'
-
Ir3ffic belJmIm
--
---
'~"'lWIr
IiI
<M111
hehavlo r
-- ."...""""'"
• ~ IIOdII Wlt;LII l'1llICft IUl~
r;. '''''
---~,
---'I jI---..--'"'>- - '
-- II
C. """, a ",,.-trwnF mo-nlt.o'

• O"".".}II1parlll.~:;:-·;en lD h\tJl.Jllo1l
· '''' I
...-
~ t"U5IIDI
•
rnor..tDI- . nd reWSI
MolIlottntr_tIfa:I~",,~ -
r;. Comll, e~
-....."
"', I
li1cornpressed
r;.
-
~1lU\JITUz.ed
BB
lAI'4OIll~
''--'-'" ".
Typical SSl Encryption (When No BIG-IP)
Traffic encrypted end-lo-end
Certificates and 1o.f..'VS
D, "',,"
2]
- Managed cn il ppl ....JI("" &CIVl:r
,,"Cr\1llH
SSL acc e~ ratlon
I!!luloe!d
MBlItlt,>ed 01'1 a~h::MitXlItt' ,\~ r
- Encrypl10n / ~\.IOI1I\af{Jwa(e
I Ap plica tion
_ !II.'rver
,,,
Client SSl Termination Profile Client SSl Termination Traffic Flow
ODD o Sends encrypted request
o liecer~es encrypted response
BIC-IP o Recei~es encrypted reQuest

Oecry~ packet. processes
Sends unenCl'Yf)'led to pool member
Recel...e5 unencrypted response

Encrypts packet
Sends encrypted \0 clienl
nmlr.r)'TTWd
Receroes unencJYP\ed reQLJe$\

Sends unencrypted IeSponse
,---
SSl Termination Advantages Types of Profiles and Profile Inheritence
vj
-
) i"'i:i .
Protocol (requ ired)
Application-iClYer (serVices)
o
Persistence
-
SSL
Remote server authentication
Analytlcs
BIG·IP performs SSl key exchange ilnd bulk encryption Other
CCnllahl.e5 certificate m llni]~lt
Otiioads SSL traffic and hardwaro acx:e.k:>ration from servers

Al lows IRuk! proceSSing, cockle pe rs,is;tpnce. AS M policies
' ",-
Profile Dependencies Configuring Profiles - Many Choices!
Think !r) Icmns Of OSI Model (;ooI."lI~Nit;ll'
~
All ..i n ual ~fVers have a layer
4 prom!! (e.g. TCP) I•
-
..." m
SOIl'C" profiles are dependent
on others ~ I--~
So n~tw ornes
COIl ~
"",."
can't be
on "me virtua l
M on'
-
~1oI_ ..
Profile Parent-Child Relationship Assigning Profiles to a Virtual Server - Many Choices!
_ -
...... _., .....
...,, - -
~-
--
-
-" -.
~-
-- ....
---, - -
~ =-
.
- "'-
-

<-,,-- -
Profiles Lab ~ 61-0 Lab Review
6.1 Client:5SL !~ l l(1n
O~ l ij Pt .~t,.5$l ;:;I{\>"it ~ SL
'II!!n"n""""","rJI'(II~
o Before SSL Termination: After SSL Termination:
(: "HI IMn.-I!II J 010.x. !n.1... ·~C .1."' . 1"I !!t1D0/10.10.X.10l !!t1D0/10.10.X.10l
~I" """~I
!<::.ilIMlIWMOi' DfItIwB U 'J ~ l 5St
~~dt: folllli poo llo l'mp.JIIIIII
1W'I1t-sJ~lOI"
A:isl1:I1""~SSL IO H~
TIIBL ~ tllM[ll mit.. doe',1 ::'~ L
.n _ _
Chapter 7 - Modifying Traffic Beha".jor with Persistence
Modifying Traffic Behavior
QOQ with Persistence
Ur.de~mfmg PefS.15it~nOE:
InlIodlK:ln~ SOUfl:. II,tJdrlJE.S. ~'Ii l l'ty raz·liisI.mc.

I nLroducln~ CtloIoll;'! ~ta n oe
Ptl I ~I~LL·n.t(l ltJbs
Mil JliJglng Obi~(;t SliltlP
M o nSj.lnljl" Ol)':el'::l S::.a"t'" lrt I)
Stateless Application Stateful Application

Web Application Web AppHca!lon
(mysrte.C'Qm) User ! sh op.myslle.com)
shop.mYSlte.com
mysne.com
(cart 123)
•
K
(home page)
shop.mysne.com
mYSlte.com/about.hlml cart K 123
add2cart camera K
(about page)
myslte.com/brochure.pdf I shop.mysrte.com
cart K 123
add2cart computer
K
(brochure document)
Stateful Application Broken Stateful Interaction Fixed with Persistence
~D
.......
('",~l
Web Application lJ>e, Web Application
o 0-~
- '- ,
o
I-~"""'I
0 -- -. 1n"YII"-......."'~~
1 ~1lIb111t1
."
.Mllllm .. _ '
.... --,
o
•- 0 ."'-....,I3f. ''''·._''''11
.
~
UII!OI 00\ ~1iD"""'1
Source Address Affinity Persistence
Based on client
SoUfce
Addlt!S:>
Affinfty { source IP address
'Er
-
Cookie {
Md,,,,,, {
Dest inatioQ
Afflnlly
'
SSL {
UnM!'rsa l {
.. 100 _ _
Mask Provides the IP Address Range Persistence Records
-o
""0%.»
15cvv!~.,." iT)I
EMimple:
..... 2fI~~.(I O
'IIIOI8cM'U!I)~~
Mask is 255_255_255 0
"'" ""
-o
""-
Viewing Persistence Records Source Address Affinity Considerations
Client device connects with a different IP address

DHCP
Home network VS. work network
- I
-
PIln...__ ~_· 1
Many clients connect through same proxy server
All connections appeM to come from same IP
Uneven lra ffi t: d lslributlon
Uneven traHic distribution depending on mask
' L ' G ftI

Cookie Persistence Cookie Insert
BIG-IP Persistence Cookie
IP address and port of I~ rrr tnnbeJ" + expiralron time
Gan be encrypLed
Cookie Insert method
° 8 ~lP Inserts special cook ie In HITP response
Cookie Rewrite method
Web applica tion creales a -blank" cookie
BIG-IP rewrites to make d spt.'ci<J1 cookie

TCI' handshake
Cookie Passive method
Web rlpplrCiltlon creates <l spoaal c ookie
BIG-IP p(I~ively lets it Ihrol,lgtl
[!J
1:-, . _ Always Send Cookie Enabled
Cookie Rewrite Cookie Passive
''''nl
,...., ( I ... ""
t·d.E..2'J~ U;z..m?f1l:1
0 ,. - : .
-0 ~
,
'C':;':::- - --
~
,,S If.np ~ ...."It-.
--~
~'
Rewnte
~ ,.
,
----
,::""'Tc Phil. ./LiI ...
IfTl!I t~
HW~O
,
~{
,TtP~
•
H
T1P=1INI
IrTTP~
Load b&la ncl!
dcc~OIl
'"~
cookie
Ttf" " q~
lfI1II "MOOM
"'11' ,
,,
,,
Ie
~
""""'"
Configuring Source Address Affinity Persistence Configuring Cookie Persistence
_ 0.-.. -
_-
,.... ".....
....
.. ~.-
--....
. .~-
---- ---
.....
. ...-.
,- -- ' ,
-,~
-...,..
- - I
-.
_
---- - -,-- •
---0-;._.. . --
... ~O.-._ ~
...... ,-
.... I ~_ " 12:111 __

,
,
"
• • -• -•
-- - .......
-
I
.
"
"1"1-"
. ,. ~.~, -
..-....,
Associating Persistence with Virtual Server Cookie Persistence Profile Dependencies
0 HTTPprorile
Cookie
...,.. f) persistence
profile
--
--.....
"-'
-
""'_IIr-,.
--
"-"""'
~-
----.,.
---
Persistence Cookie Persistence Labs c CC o • 00
1..1 SiIouAdd_AJ'(If\II;)'PtIf~
11!IIIl'0'8.-l'I!J r s~tDIP'II~I!!'O::'
o."ill1 1't 5 rc_ I""JM:jl "lid.,.."
ILttI triMlit""lltI""-" !,In", ~~I(~II
T"yI !>+'i'l',.lnru.. IleN ,,",_ ~ l1:li111'1
""_I' IIDS
r l te l'l ~
-0 -
0 0
7.:z~P~IQfN;lll ~-
1IIIC.' 'IiJO'&IJ ~".
w....:!:I~IOO"
S« IJIIIiU lOO! ' 0 R=a.a:I!'tIIIIIn

hal ""-.1'..Il11l>«1l11"Dr 1wIiM, ~1Ir'!a
r::ro- P!_t:.oo6!lC'~ MMI-.sqj.Il Ie
""",
111S111,"'"c OOh awu, .... ,111 &e.WII<III~1C
- -'"-
~--:=--
II ~
lIfS11,.,1& l>;i/u11rt1lr ¥I111L ccDoJII e!lrnU' >fI
l
1....... 1l11'o':llV!i <;o, ,1tI o[.anVr 1IoeIm\m ,
".,- - ~
Pool Member State and Its Impact Persistence During Manual State Change
impaet on Alil'JllflbJl tl),

10 .10" .30
Enabled All traffic allowed Available (Enabled)

Pool member IS available
Disabled Persistent or active

connections only • Available (Disabled)
Pool member 15 av-d,l able,
user disabled
172.16.20.1:80
• lWthr.ll[IEI~for«:d down
Forced
Offline
Active connections
only • Offline (Disabled)
Forceb down
@ Enabled
@ OlSabled
@ Forced ofllrne
Persistence During Manual State Change Manually Controlling Member State
Pe~ Pw-..;., V"t.-l f'o.:> Pool M ~mbe, f4Ce

v"", Iob;III ~
........
---- --
lO..ID. 4 .30
~"" •
172.16.20.2:80
• 1WtI1~{tJ~,orced down
-(2) 1'wIIIio-1 1F-. , n
e'l"':&'
...............-.
@ Enabled ."'-"
@ Oisat>IcQ
@fOO:<"'Gofflor.e
(t172.16.20. 280 172.16.:.10 3;80
- .. ~
~~
(tIrIIQR\j."",loM;·
~
_c-wtc-l _ _ _ _t .......... - ......,
Object State and Persistence Lab p~"c> 7 30 -) 7 D Course Agenda
-
73 ~Sf_~~lster«
~~lIn~ tr.s/.
~1III'I1'OI!1IIJU1~ ~; :;..ro...u
DtA'tItIII1IIIIe.lIlll~I1-A~na
o (5 0 Day
2
~
1. Sdli rof. Up l~ BlG-IP S )"!l h, rn
Proc;:s:;;ng Tra fnc 1I01tn Lr M

Day ?
8.
9.
De(lkJI)"IlC ",*ll(;etJDn Services
wl m lJ\~
TrOlJ bI£<9liOO'11fl&IJio;~ BIG-IP

"'lew ~ 51II1l1!:; i rom Nctwo,h MIIIlo
"].",110 3. Using NATs and $HAl,. S"",m
:.:1" ,-,""c.o
4. iJ!IJrrg I¥te rrtlfl llC ~ ''' 'r? " t to. h e flll:. P~ Su;te
"-'''--
~/U_"'l"""r"--
Str.e ll [ t lT'r~" )
11 Ad .-,~~tlnt 11M!! BIG·IP
Monitoring
......"
5. S""" ~
6. M{)(:hJYlng TraJlK: Behirvklr With 12 C USl;oml.1\il1ll.~ llOn
Profiles De LJoooe ry wt\t1 IliUl$S
~
Modifying TrufJ~ 8i!h:ilv l() r With
Persisielll:e
Chapter 8 - Deploying Application Services with iApps
Application
Administrator
BIG-IP AppilcaUon
DellveryController
-
Man agi ng Applications without iApps Managing Applications with IApps
iApps Elements iApp Template Structure
Template ••••••IIIj~~ Application Service

..,-
~, Presentation secti O ~ • Asks questions
..." Collects user's responses
- -.- 1
~-=--~J ;
Implementation
Processes user's responses
F5-supplied section
Creates application components
Shared
(DevCentral)
~==::::
"''''......_ r . _ );
!
Help section • • How to use the template
Custom built ,o.;;...__ 1"l'a )
New In 11.4
(- -_ ..- - ), Macro section

Creates customized iRules
Easy Deployment: Easy Replication Deploying a New Application Service
How have you configured routing on your web servers?

• 'StIr"", ,;:!: ,10 mllll'llMloll r(ltll_1I;Io tl~l~ \ ~1!J1111e (l1G; IP ~15t1
vi'5i8fIo'llI S haye- " rNiII Illtllfl!1tB U1t4l(!C h the!)ll}-F &)'M8r'11
How should the BIG-IP system handle SSL traffic?
II
• f'\a'J\IiIl'" 10 lXIIIl!! ctIotR:!l.IInD~!L
./.umytl'l ~tltlll1ts.p&;I,1'1)eX1 ~~ lSSl~)
• lij(JlW'il leS5l frV/I'I doRIIG. lit-All'!lirypl to \lll:ll'01!Ifij. ISSl 801l1t.l~
• ~tn~1:1 to :.'Ilellts. ~tf)~!11 ~5
'''
Dat~ Cente, D~na Ce nler '"""'"
Da tB Ce nte r
Hong K<lnl(
Il;Ita ~ntcr
"
Application Service Components Changing an Application Service's Configuration
oAfllI " .r.~rlle",''''' .....~~ -. ,

o . F< ~ r ..~ •• , ..
.
--_,.. ,--_
.. "*r I -~- -: .... Appllc lltlon S.uvlc:e : I~ J \
- ---
' '--.-.-.' .~
~KIIt'lM:IiSlf\li:le
Partpolli P.tf1 I::~' -

Comm d.caoom_'Ht!bdluIpp
- _. [' --- il
Ootscl rpOOn
Temp lale ~ r!lJ'lnp
SlIIQ 1Jpu...
I [ O'~=""""""'I
L~"'" I~
DevCentral iApps Ecosystem
$
Share custom iApp templates
Get updates for F5-supplled lApp templates
iApp forums and discussion groups
O~~nlr.ilt •
O_ e s lmple w n _~
DII\Ib'JI ~'IJ !'U'(l<>l Il_-wm
• i!!lll lu rr-lwlI "if',

• T"'&I&natJ\IO(ll.>......
Di:o; u mfmV SIIve c"" Mnl (;I;It~

iIoom 1t)1-tt[,
(
(
__
-_--.
. .
...
er,lIHlJ !t:s "'W I~
II --
iApps dCV{;en1i'a 1.'5,cClm
· .... ' It'j n't ~"' lu;nl1g ( '-.
>-_.
• f1e310 r(l !f8 "~ I- . L Q
---
C,r a!e mo,,, a ppl icalk1n. _ _
,
.--..-- .
~1)l1Jf Cl-cant,, 11'!lIII (;lB!DcIut'I
~ fe Cou 'i!N!I_~,"Jl
.... ~ Cou r'l'l!_Allmml6\flt"'l ~
C4:Jnn ,"'t lvnf'!'nl';-:.} and I~t.r 10
(III~ ,,, I
-
( -.-.
•
•
•
Chapter 9 - Troubleshooting BtG-tP

Troubleshooting the BIG-IP System
. . 1H~aro~
.. I ~ lheresvlls COrtrl.!l.I.lIlf1ltl(~nlil.
Mt:tnltQI,n~ \h1J BIG-IP Sl'OtBl'n Re.mo[olV ..... Ir:!t Sr-.tMP
I
~ ~cm pl~n UIII L~nfl. \cpdrJm~l Dn til;> OILiW .!ivslE'l'Jr
... 1 t~1 plil n

LOi%lng llnd SNMP LDto
C'eal1ll a
Leveraging II1e BIG-IP IHeelttt SYSli!m
U IIj.:i
..I
}
Dc:velop a hypol.l>Mi:> SNlJlr"&1"., AIl;tI'/"ntl. .... I~IIO(,.Jlll0n PP.I Inl11111 ,r.e wilt! An,l f~IIG!io
~ltrI
.. I Galher fflfDrmil ~on

4f"illr'lICii
'~p(jIJ'1'(l
fUO
WOri-linl"! wi'~ r,) io::<;PtIllr.Il !
Tloubles"O(I(,r,t::: L,!I.J~
Suvpnl[
1 0e1 1f1e U>t! CJIIIOoierWI "5~p.;

P:, lH("hI\~1 ~1JtIOOI1
BIG-IP Logging Methods Log Information Levels
linux (syslog-ng) TMOS
.-.
BIG-IP Log Message Formats as

Seen with the Configuration Utility
BIG-IP Log Message Formats as
Seen in Local Log Files II
No... I t 1 ~'i5'H l U1!... I ~t; .l~ ld.:l""'lfl ""->Lit:>lll .qx.I 111 17 ]
IIItIlll1M.1I: '.i I POO L 1~I/'I!ILl I"~ 1 _ .'f"
-
lo.~" /1") 2. 1 6 :to I ~ Go __ ot t ?'r "t~tus Qr._ .
/Co--;m/a y http ..,nlt;or: down I I w"s " I' t.,r Qohr ~ mln Q 1 ~1I'C I
N"" ' 4 I J . 4 ~ ,lt l oc;. Ir-l.IDoUlI. l o;:,ma i ll lXK.it'll! 1K'pd 1 61~ 7]
011T'1)(.18 :5: Poo l t~tb.tt P p o ol ~ "
J ~ /1n.H. ln 3·~Qo -oooitor BLQU1& Iin'wFl
_ _ III"!J - . , 1~ Il/my_http. lIA'1lLo r , fbi'o1 ] \ 'W.u ~ Il ((I f" Dbr: 2m i 1l6 9",",c I
...... -cKIII _
lQoIr H 13. {; 114 l ocnlbI!Mt. I ')C.IIldoftI ;<l OOC1~ 11CP11 16! n ]:
OI Ol'IHJ.!II'51 POQl l~tllt.l:l!J)OO I ~ f"
/co.Jo ll /l72 16 2U.J,80 .anl t.or "L ~ '. U II doom
JC~:II"I / m y_h t. I[.ll"_~1to r : doom ] I "'"H \Ill t.:; . Ol'tr:~. l nD Bsec
IIIw 1~ 13 :~S:H I DCalhaA t .loe" l,dolTl1U n t1IDI:.lc:.fl . qJI1 l ~ 1;271·

Ol lnU' 8 l1 : 5 : SRNP 'n\AP: Virtual /C~n/Y. ht;tp ball bec~
--
un.!IvlO ihb l .
Legacy System Log Message Processing

.11 Local Logging Facilities and Destinations
II
"''''' "..
iocalt EM
/Y3l/lot/llm
/V".M/log/em
APM /V'(JI/iotVaprn
loc:al2 GlM /WI./logIgtm

loc.al3 IISM /var/l~~m
........
""""'"
/\dI",I1Q&Iltm
localS Packet Fl ltenng /vltf/kltVpk.tfilter
iocal6 HTIPO Errors ( V.f ioWtlr;tllll/l1ItlJljl 4;lrn;rrs
"'.01Zl:l
.
-·0
Joe;,17 Linul specific \)0(){ f!1(."'S&"lb'eS /v<lr/\ogIbooUog
SNMP "<1,1) email _0 • •

Setting Local Log Levels and Access Basic Legacy Remote Log Configuration
- --..
............
--
I..o<" Tr _ ~ _
-'--
-
~ ~ .
-_......
.....
~
~- ,----,
~
--. ,.
_ , '"'0' .
-
~ ~
• ..."
-.......... - . ~. ~
- -.
""""- '' --
-
~ """' E_
Tr"'~ ' )S
,~
(.~ D
--- 'I bllah DIOdify l ays sysloq reJD:ote-servers
add I lIlysysloql [ host 10.10.4.30 remote-port 514 II
HSL Filter Criteria HSL Configuration Objects
List of destmatlons
....
POOl name
What severity level?
What source?
Spec:fic BIG-IP service (e.g. mcpd)
·al!~
"no-source" turns ott filter without
What message IO? Supported

Remote High-Speed Log servers
Where to send?
Remote Syslog
Splunk
ArcSlght
HSL Configuration Steps

.... Interaction of Syslog (Legacy) and HSL LOgging
-,
"
11I1J,tlSp&edLoI'®<'-"
~, I:r
.~ ••,"
..... 50..-. .'1
~lf\"Io"I1t
...
Setting an SNMP Trap Destination Remote Monitoring Using SNMP
• l.72.lli21ll
..,,'"
RKOrd PrOfMrtilS
V..
•Il
~
----
Communlly
SN;:Sgem
. 1.7 ~.3
,-
Setting SNMP Traps on the BIG-IP System Using tcpdump on the BIG-I? System
etC/lllert a,talert.conf
Command line "packet sniffer" (packet
OC I.fl IA S.:'I MP (raps
Captures traffic through interfaces
• Do not moOify1
Output can be saved to binary or text file
conl'gtus.cr_alert.conl
• iJB.fIt-def"~ SN tJI' tlaps
For more information on tcpdump:
WlRESH.-.RK
TriJp examples:
Troubleshooting fl lG-IP LTM course
SOL411: Over.!iew of packet tracing with the tcpdump utility
IIhl.l::t. m GIP_MCPD_ MC PDfJui. _ 'JIli'l'WU...J I.VAIL {
1!1j'. lt rl1r; OID _ " .1. J.~ . 1. 4. 1. B 75.2.4.0 135"
I
al ert B IG I P_MCPD_ MCPDBHll_V I RTUAL_ UNAVAIL I
e m"p t. ra p OID_ " .I. l . ti. l .4 .1. 3 j ·1 5.2.4. () . Db "
.,.- ...
External Moniloring of 8IG·IP Syslems: Imp/emenlafl ons
Frequently Used tcpdump Parameters tcpdump Example
Refer to 'fOur Stucient Guides "internal" interface (VLAN)

• BIG-IP tcpdump Im nlt! :renLatlon
Pr... ""' ... _ _ " " - " _ .....

Source or destination is pool member
1...... _ , _ _" _
~ -j 1.n~.t - ~ 1x4t. 17~.lfi.%(1 1 ~ pon. 80

1~ "" _ _ _..... _ _I"' _ _ ..o'c·
1111.
_ ,_....-,\U .. _ _
-o o
,~
lI,th. '
r.. _ _ - . . - ._ _
,.....,'.1
""""' _ ·~ ....... /famwrnpodool
...... , Ill' ,",lnPtI.1 ~. _ _ _ _ .. _ . _
l ;on. IMI'IfilIIIII
l_"'_____". . . . IAO_._
..._"'_'...,_
('""" .. * .-~_ ... U~ ..16_'IO,3;80
. --,
tcpdump Example
~-~l-.J"""ro.o '
(XO ,'jO,1J tlUl~

l~_L.. 6Q'~,~ or<:{' r"-op.~11
.?;;I . I ... l:f< . I .... _ . ,
171" ' 6 17 31 3:>tU ' 171 II III l£*'i 1J"'11E111

I
~tU~(Of _ It: Capture packet data on internal/external VLANs
where source or destination address is a client and
Jl • .L.UIIIJ 111 \\0 ill 1 51) > kl",LL'.l1 JI...JII<> • li!!.Oo lllLb l!:o:ll6olJ.toJ"IV
So
""" .... 2'l'JlII;, II1n ' ''!,-'J . em; l..ro Ui l) ~ ~ ~ ~ l\l4'I' (.2'1
l::J "'llIo
source or destination service port is http
IT
. 0 n Ill!J03 II) 16 17 31 ~ll • JJ~ l~_:ld_L£IJ ~
... ..,-, r.:;p,~ J.J(.. ~ J~:>!J:,. run
::~~~~~~jJ~~~!'It;j~-- I M ~ t 61~I tEpdullJ3 - .1.. mrt.rn..1 --n IQI t 1[1.1-1),11.]0 .-d P'"rl
tcpdu:lIp - l intarn.a1 -n I1.:nt 10 100.1'" JO Ex\! JUrt 8Q
IfIjJ
O~ 'MI U ".~ l1"l' l£_~ O l ao> ,?:;i. a IT u .lll!iU I "
I-I!'[.IO ~t:a..p,u-."i' ~~~U ! . ll~.b <D1
!I'll 'HI J: . Mf"I'U 1"TZ U . I1 . 3l l 'JoLll , l TI.U....z; l .,;l I>Cl<
~, '""',I.-..." L!=~J ] 5:><!""', 1UF1 SYNjACtl
G''''''O ~ ~I 1l'f: Iii 17 . 31 )"'111 _ I'" l~» 1 N· , ~,~IOI Kt< l "' ~ lo;Q'l';l
~,""",tI-..o!'I' tlr;;2;ll!.) ]~)"" h IIJr'
..... ,'50 J.1 . .Io'\::R!JJ \1';iI.1li en 1 M > n l Jj ,H,n!"CD I H 9.2 ~9~ \ ~ HU.o" ,'In
c 'i<jl~ ~,I"q).LL_~ l 5'i 2 J7 ~ ,~ . ~
G'J I'S(I,1~.1SlIII[jo \'r.iIl .. " ]1.3%11.1'1':0: 1';,:to I &'!::« ' ~F(.,'!';-t! · . !oI1!II!I9:SOm >rU1
1\311.4 _ U~""" . ...:e1. O, rq' . n:tLt~lItql/; > :f:t.'1
Sample BIG-IP System tcpdump Output Logging and SNMP Labs p g,,()2~ -7~'l
!U I.q.IC)'R" mWt ~s.-ut.

• o!:unfll.~ fC lli.LQx .iO.'5 1.1 til' ~~.r. 'L"fT".cte 10.10.x..;:e:)
~
~Il,>
l'J.!rt
_1 ~ , '" ~ ~~~~O'F:":
t "-'"
:. ,":-:~~
n \b J'
'"
,, '~ ",",.,., J",," " " , ..
·
~~ss.«t's
l~ ~~.~m~ o
"""'
I ~,
• l~m D III" tI10w IDA ~ Irnra-n ",~"w
...,. ,+..1
~!.~
~
.....
I·
~ 'Q
II....
IJ~' I I (l) , ." ., 9 2 SNMP Tl1l W...... t 1H
. ...le.u. • e.-oOf'lllJ1f' l (} .1"!U,JOJji :;, "q>tq.... !Vt MP

" .. IQ 1D I
" , , ., ~*"' OfIW;a i7" ~
JJ ~J."'~.
J~ 'I. l'
", U~
U~. ,
~.I
J 1 .." ' ,n -7 1.' , ~-~, 1'1""
11~ ~NM Il'4~
lrl"ll1 " mp \0 ~ ll0W iIIILln rn.Il(Ifoli'i'" ,,",~ mk~. ,on
~ -~L~~I7'I7"":. ~O''''"
,:••:-~.
~L"t~~Y ... UlaII " t 1 ('I' :,I d lf!ndl~
ll._ ..,..
J"'Wl"I _,'
•
~) "1 ' . ~L'" ~ lD L

1_.b.,".fL.J'._KT_~
L' .. ' '~1 I' VI·. l

;~ _ ~ >
LOI!" '
> I
'17
,t"lO
JlJ
J'I"
'Q, JIo"I
~
.... 7
".
'••,~,4"'.II;'j
1 . J" ..
1 '"1123
'):I'D
":;F:
.. 9 .3 ~ed l~Lab
C~ HSL mat. PL<bIIIMr. IR'IILI\a1 t:>Il,
[M"J1)I ..,, \Jl1{l 1U". :t. ~L4 u(JCll1lITlOlll!l )(,~
' ....
II'SlR_
10 Jl)l :J!I""l.
T~IDJ; ,~
u:pa " mp to IiTIOw "l!I1TNIiiIoII", 1r.'G/Tl"'~!O n
BIG-IP iHealth Creating a QKView File
Evaluates logs, command output, and configuration

Compares with database of known issues, common
mistakes, and published F5 best practices

Provides tailored feedback I-ue- No~ 19 10.50 11 PST 2013
Recommend once a month 1t.r\11;)201 byte-s
~D , 0 ....
-- It_ h tUol:l'~.ffi.com
nmmJJii.. SOL12878' Gc r.cIM"'R BIG-IP dtagrlOSltc data USIng \he Qiw<ew ulIhly
Viewing IHealth Diagnostic and Configuration Information
Uploading a QKView File to BIG-IP IHealth
bigi~.f5trn.com
I
fS 81(;.U) IH<!aOlII
Viewing command: list Inet self all-properties
_c.._-..,• .--!lIO'o.... list fnel self all--properties

tl,",," ~""
- . .t :J:.. ~~~~~:iri1f
all ""H:rv:lCWo (
..
l"lll
~.rr- " n!I ~'" IVII1-I'
::I"~r~p(JM' !nil.
tiDel""" '.! :juU!:I.. j

ra. .",t r, ....~ l'-Il "

h"'.rIl.l'!J II~
~::';~i~::r~~~c~ LlLIIB
l"'l~ti._ ~II
tulr'~11J9IlQ! ~nlf..(;jIfUt~,;,..,p. ..-Qllll...
.100_ . .
1,--;.._-

Analyzing Application Performance with Analytics

..
Provision AppllcalJon VISibility
and Repor1mg (AVR)
0 ApplicatIon perfOnTIBnce
w;
-- ... --.-
lalency , ~C"CU' f.rar- ~f
ThrouC"PO"
Ses>1OIl tlala
M,,=
AnphcalOftS
~- -~.-...
. -~-
V"l niJl servO,6
~ ~ ~ ~
I 1'001 rrtvII'liEIr,!
Ulk s
S;-';>CI(IC ~
I-' l..1.fl ' • ....
Local/remota col ~1io n
"-
_ Capturing Application Traffic for Troubleshooting
........
---' --
I'".............
.. --~
_R
..
--
---, - ..
_......
,..._ I I:I.IUI ' "
_,. ."IIUI,,' "
,...,... " ....
""
---- ,_.-
,~
-~ ~ ,
~
_l_ ~f "" ',-..w oJ«<"l~ .... _~ .• _ .. 1"lnlTlClhll
_ -
lI iI.. . ..... '-:T
.... fl •
"-
WebSupport Case Management Opening a Support Case
wctJ15Ul)porl.fS.com Information required when opening a support case

C "-31~ a Nf",\o' Case - Slep 1 of 4
BIG-IP senal num ber
Case descJiption and impact
ConLact mform<ltlon
Product specIfic mformatlon
... . . - ~-= Generate and upload qkview to iHealth
--- SOL2633: Instructions for submitting a support case

to F5
SOL135: Information required when opening a
support case
....,-
Retum Materials Authorization (RMA) End User Diagnostics (EUD) - Hardware Only
-__,'''......
_ ' .. rN_I~_
~ ."" .~ ,
When EuO Is running,.
11:1 T. "
.xr til ......
"-11 ..1
.....
"301 " " ..... _ - .
... ,.- .... n«
.."
II '~ "r J 1>0<_ q ..... - .... '
II u ' .rul ~T.. •
I. · .... ~ ......
uL , .. ,
I . ' HI< to ..
II . _--"_,,.. Twt
BIG-IP Is NOn
........ . . .
"
"'"'-'"
' .. IJJI_ _ _ _ ' _ ' ' '''. _ _ I - . . .
"
.." ......"Y...-_""'"'
........ ow _--.""" ......
· .-,oN ... ' 1_ _ ....... _• • 'lo.I. ,I , ,'O'
Replacement box will need to be relicensed

...,1.-' • -". 1( . . , .
Troubleshooting Labs -) OJ ',4 Chapter 10: The BIG-IP Product Suite
94 T~1I!D
• t_~I.O"-I_InIIl'. nd VSjll1.pS
• T~
9.-5 1IIIIIIh lEI C.~)

~~~fElaCl"l'fT>
... ~s f:;..<,.u cs oo
er..... gIo.......
~~UJ'1'S6IIh 1i1~1 ,u n d1 M~
rn..I'~ ...... ~.."'... bcl C~ •.... 111..... "<;
~~~.""''''' ' .
........-x..,' dl i.S!.r :
•
BIG-IP Local Traffic Manager (LTM)
The BIG-I P Product Suite
A~i on bIIfj' 900 Htlpo<1J(l g (AVR)
lOCc11 Tr,rlilC Mallf,lp-er [I.1M) L7 1~~ i genl l m ~ lliI:~t
GlObal TliJftlC tJanager \GTM I Cor \< protocol oIJilJttIIlSIbO(1(I'Tlf'. ",CP, 51"0'1', SS U
.... POlten~l()n Sl:cutlly Mtll'lllR,rir rASM) s St. pwxy alld Slt:h~

IfJ\oI!,suppon
Access PoliC:1 MtU1o:lf,t.'1 IAF"of)
Prog rammabI IlL1 ~ fIl.~ ~I,IC<.>/'Il rol, lAp",)

....p(JIICFlIIOf'l f,rl?'Alilll Mflflfl~ef (MII'I;
On ",,' ~ a rlQ 1!QIIIlCi.loon Qnr;;! OI/X ' aliOnal 9CII llne

~IJOIICLlIIOfl "l'cct~rct!(l11 Mmta~[J ' I-\AM,
MM Core (CDIli lir-., COAlpr~ , baoow,d lh oonlrolleL..)
fI1u;-rpr:5.? MflC'll!lgp.r IfMI
APM lile (u ser .aLft/'lBl'tlk:8'l rOO . 5Sl VPN ror W .oofOJrrefllll.lSElr.; l
SYN flood prul.el.:11C1Il
Global Traffic Manager (GTM) GTM In the DNS Name Resolution Process
• Gklbal s<:."", kXId baIMW;,,'tl

• ONS servICes
• ReaHime ONSSEC
• Gi4DIi oJppl O:P I'<ln 11,1» ava,!ab<l~y
· ~ltOO
• ON!J. t>OoS aTtaCk prole-:.1jon
01'1 _ _
GTM as the LDNS Load Balancing DNS Queries
-.---
-
0 -"'"""
LH ---
-~ . ?
,..
Accelerated DNS Resolution with Transparent Cache Accelerated DNS Resolution with Resolver Cache
Ttw~~['acM.
-
...----.-
m ,."
o
-
14 . 00
1BIIlt ill IYlII Bm<!lIlI
-..-.IS.com {200 A 208.86.:<09.2'0
--""...
..I:l
--
- J~
~""'-~
IJ
-o [}t ttttl -- I'>
.J:l
IJ

-o -------'
1
--- ---
Accelerated Resolution with DNS Express Wide IPs and Intelligent DNS Resolution
---- -
_ I'" 1 ... 1-...
"--"' ..
-- -- ;;::=='~-111111~-~ '1- "
t
-0 - ",
Application Security Manager (ASM) BIG-IP Application Security Manager (ASM)
Enforces security rules
• PC! Compliant Web ..o.pptIcalion rOl~""
• " dl sc(ap"' ~ Pfe'o'enllon
• Inlr.JI1l lc-d XML nrewall

• ~D~n cOfre!;,l"", and inad€ n l grouping
• ""ppb;:alloo 0D0S protectIon
. .".,,...,....
Mlnlmlle data leak<lge.
~ hide internal envi ronment ...~
Web Application Vulnerabilities ASM Positive and Negative Security Logic
NegrlbVa
• [:I 1uck blt!:ed on iotn:nmll1UK:k s lgnalUl ~.'IOO lil'llx:k JID!11!'J'I15
~ Positive
-
Ailiraffic is 111e.pI1lI1iI5:s IelKned/lold lq 1;)ofl1~1
O- +-'iI • Block b.nsed 01\ ~~ leJl meu f rom tIM! :upPIM;;ltlMJn
Kow;: ~ Il!QI.IIJli.I3 SSL access
r RWaIl allOWs SSL lraJ11C tl lI\II.JiII)t
~~ payloa(l
.
Three Ways to Build a Security Policy ASM Deployed Standalone
r
No load balancing
EJ
One member per pool
ASM Deployed In~line with LTM Access Policy Manager (APM)
o ~"""" ___ ''"'.I''''''VS ''''U'''''

a lTM'<S ~ ... to-r-n n _ (VS _ AS"'1
oo 1,!)I,!~ _ .. ... ......."....--..-I'tI""\lWJ

u >o<V!. _ _ ,. _ _.."" _ _
• Manage appl>C3 l>on access aoo aoceferale reTNlte IoIDII2i
• 500-200K f,~ ,, ( users

• BYOO en.~"'-1fIftI
• Fun proXy lor VDI If;;\ ' .... VMW3re)
• Single Sign"", t!WIio.tfll!o;o-..... OlS (ld enut)' Fe<lt.l<1!bOn .tt/l. SAML 2.0)
BIG-IP Access Policy Manager (APM) Access Profile Visual Policy Editor (VPE)
Access Manilger Policy Manager

~ (\01 \ • WtiJctl rQ5OU rctl..
• CI e"~ IftIiChII'le
Virtual
Server Check Resource
- AuthenHCIl t fO/\ Sel'\'er
.. _
. -
~Dynamic" Webtop Links to Everything! LTM Traffic Flow
f." -
® ,..-..,
..-
G """" ~ SAP f.~"",011
,rrlP c...,,,,,U,;M
... ......
"ff,mKNlS R~_
ORACLE"
1 Desktop
OG5Jllop
...-.,~
~"""'" Q "PMJO
..- ....
GTM Traffic Flow ASM Traffic Flow
.....
-
-~,
L..18tftlc1r
'\is, r-G -- .......
"", 'ilfllJ~
L-i r~(~ ~
I
I _
)
-
I
I
I
I
I
L_{ '-~ )
,-~
APM TraffIc Flow BIG-IP Advanced Firewall Manager (AFM)
~eaource 1 ' I
Consol idates network firewall
~rce2' J services within the BIG-IP system
Le',er.gE.. other BIG-IP functionality
Resources can be ..
• Pool of webse rvers (LTM + APM mode)
• Webtop
Network access
Portal access
Application access
Remote desktop
-_.
BIG4P Application Acceleration Manager (AAM): BIG-IP Application Acceleration Manager (AAM):
Web Acceleration Web Optimization
L~"",W"'Li:I('i\
• Intelligent content
I)yn;;III!II:;: dnla compres·sKlO

Web con tent optimization
~1011 o pj¥ll IZ,l\lOn
0JIf1 l!IOO uDlIr.M lOn
Dynamic compression
BIG-IP Unk Controller Enterprise Manager

Enterprise Manager 4000 Platform Common Uses for Enterprise Manager
-
--
---
,
,-..
, ~
-----
-
Enterprise Management Tasks Device Discovery
o.-o~.
""'......~'~:......
n HU
I.... ~'*-~ ~
-
......,~ II..-. "-'
~. c
,.20 _ _ l:IIopooan
_ _ ~~
.......
"'_~ I '_I
--
btgip_o lm l .rorT\'
192_168_18.1~3
tlIBip._m Lc:IIm
192.168.18.144
""""'
192.168.18.200
1'l2_158_1IU43
192.168.1B.144
192_168..18.145
V"-,
EM 3.0.0
81G-IP 11.4.0
B1G·IP 113_0
B!G- IP 11.3_0
-
\4" ~ _ _ ~ .......... ~I' . . . .I
-- I
l:II"gI(l.gtmLcom
192.168.18-145
- -
--- - ""." ~
~
-,
Understanding Changesets and Templates Deploying a Changeset

Oeplr7jChangese\
Deploy common configurations to new devices
Manage configuration standards across multiple
devices
Rollout new application
Audit configuration changes
Manage network object dependencies
l~
-
I ...... ~ • •
-.l.
Software Installation wlthoul Enterprise Manager Software Installation with Enterprise Man ager
....-
-
-- , --
",.
,
•
-
c ...... -Iit
0"
._-
..
'
Ir.: ,

Iw;1· .~~- B-
•
.~
Backups and Archiving with EM Comparlng Configuration Archives
• By default, up to 10
•- JI_~~ ....-
~ •
rotating archives each ,
.'.
for itself and for every ~\I.
managed devi ce
,1: -... .,.-
~
--
•
\0,.......
-
~.!Ie!!!!
-
-• - -• • • • • •
..... ~~~ ,
~
~.
~
t O"'r ..... ,o ~
~
,
, ~"" ~- .... _ ..,
''''1 """ 0<11_ ... _
c ""....., ~ _""
_
- -
".
Managing User Roles from EM Enterprlse Manager and iHealth
--
View a ~ users of managed devices
View devIces a user has access 10
r........ _ . _
Chango passwords
3 _......,..,.
,
--
liU" . "'.

..
Understanding Alerts Chapter 11 - Administering the BIG-IP System
UIbIfu_ Mu r>aiIB ~ T~pes

"""_n8
...
Application A
-
I'*-_w.,- ~ ,
~~~~IIU' .. virtua l servers y.(lual MrVtt'S
~"JIooawo-.nEM
pools
~_t:I_lbi r.ilu ""
"-3!~IIIl ...aH ~
~ profiles
~ monitors
""""
~rofiles
monitors
GUI.Qs_ ~"*"
90:11 ...... 01-'1 ''''I''-:h(Jl'~~'''''.a
!I.onr.. 0MfIt1d ~!,,"
Common
"'.
"',,,., virtual servers. pools. profiles. monitors
'!!- ~
..... -.
High Availability (Pre-BIG-IP vii.O)
Administering the BIG-IP System
Oyt.:!I".~1 of High ,"w81lobilny
o o o
J\1 ....·:;,yo..(.)(I ·,. tlfl~Rf!ruen r I,'OM I
blX'oll(TUlI'j. NetwOriol C(Jnf'l1ur~llon OpLionli
RestriclJng TrsfflC on thB BIG·IP'S~stam
Pi'lC~ t!l r 'ilf:r'S I _b

• Standby
Disk UlllJ Soli W.fJI 0 M (l!lill~l!lIlctl!l
Adm in5J:ralive Rnles m1d PartltK:Jns
I (p\·rl;,.d.,np, C\IIP ilnrl ~CMP
"d'T1lnI5tri11 ' ~C PJr~llnn-.; LOlli
High Availability (BIG-IP vii.O and Beyond) Device Service Clustering (DSC)
-o -o -o -o
[___'
e- " - - .;"~
'~ G'O ~
P ,_
_e-- J
tie¥\t;e Gr(;o;JJ)
Alwa)/5-Qn-Management (AOM) Network Configuration Interfaces
Keystroke to Access: &- the n within 3 secs

Set IP address (serial console)
Not available on virtua l ed itions
Separate Linux system
I"'-::'-o.i -
;_. _L . . .
1, -
,
~ct
"--" _
_'Y_ _
. . . . . . .<
..... r~_ '~JI

_I.
..-y.t._ .,o..:o.,U . . . . - .
~
.. ••"..
~
_I
. '111 0Jil.,
l 4:11 .:n £:Alllil
J._--1!jC
TMM switcll mlCrf()C{'s
Number/CilpaCl IY Qe~~ Qn the 8IG-IP platfor m type

~ - - _ _ - . pl . LU_ .
I ___ ""-::I: .16
I _ . rat _
.n' .."..,..__
.<at~ ..-r)'~I~ "
IU_. ~ _____ = II'rIJI ::::.IIM..' , Names formal: slot.port (e.g. 1.1, 2.1)
~ -
M ... ~""rn"~"LII
..:to ____ - " l q a. . , o/>I
Interface properties
, _ oat ....LI'IHw. ' . _L'
Interfaces are assignP.d as resource s to VLANs
b •• , .::-.::0. :
Introducing Trunks (B02,1d)

Configuring Trunks
t_ ...,..,J, A . lIII _ '• •
BIG-IP Trunk Switch
<,",""a~I'"'
. .l"'C
11I\!IIfItDI 14
____________...
-
-
Unk~I~Io(,
Bo/lOU1I~;
--
• 1rV'II_ blnltN,dlh w, t~1\ UI I~I>Il'" ~ w
• 1 ~""""' "m.*,ne r ll"I< ~Uft£nIiI~
Ma~JmIm'1 CIl B IInlo5
-
~I til one Of more VlANs
BIG-IP Self IP Addresses VLAN / Interlace Assignment
Not a single host address
Represents an address space
IP address/ netmask combination
10.10.1.31/16
172.16.1.31/8
192.123.2.3/ 24
Non-floating (a.k.a. static) or floating 1 VLAN : 1 interfa ce

Associate with a VLAN to create a distinct broadcast 1 VLAN : multiple interiaces
domain
multiple VLANs : 1 interiace
Mix and match
Tagged (802 .1q) vs. Untagged Configuring Tagging
--
~
-
c...... .... - .
--
_ / P.... -
c
-, El-.
"'"'
,~
--
" "'111110" \/lAN, 11m 1I!111,..-.,d t:I
lhC!' ~ im c rf..ee. only 1 0I 111oMI
VI..A.'b c.o n_1Jrl\.ItilIlW lnI'fic
- "
,
~
~
'
Restricting Network Access Restricting Access on a Virtual Server
0 0
...........
·(I.ur· .tooUl """""'"'

HU£. •. !OO.w
• PorI IOduioWn
• SSH iloce5!J
I1Ir. ...
r---+----:T--~--:
I enl!fIIIIIII I I I
l _____ l_____) l __________)

• AoPII8~ mode : lD..uu..:uttJ5 :: 17 t :
I I I I
• Packet filters
• 1:. " 10 III tOIl tIV
-~
.'u._
l"UI,~
....- ... -
'. .'
~
Restricting Access on a Virtual Server Restricting Self IP Traffic with Port Lockdown
-
0 -..........
"_
1"._
.. " _ _
--
-
_
..
. ,0. 1•
. _ 1 £ ' - . 1100 _ _ 11 .......
~ :-
--- 1
-
- - ~ ,- ..
<-
~""l_
....
Restricting SSH Access Restricting SSH Access
t !l21 M.~
SSH <ICcess lO sel( IPs

UHf_r_.. .
, ~ --
" - F..
SpeQfy Ra nge.,. ."...
• .l ~'JiI$ij, · p.KWOf1l. •••• n ••••
-~""' ~
,~ -
~--
S?llP ,....,. SooKi". R~. Ill2l$8 1 •
~ _ J
Appliance Mode
"--.--.
. ..
_ll.l!It::I
-- .--
....--
,
· llJl_~~
.,
l ' ''-~
.,-_. -..
~-
.. ~, I
-- - .....
.· 11°
~,-u..l·_
.....
.
Packet Filter Rule Configuration Packet Filters and AOM Labs 4
---
N/A \0 MGMl' port 10.10.<30 10..tO.V.30
l1.1 . v,..;ket FlIiIIo's l al/
o o
OfdI:r
Ai.'Uerr.I
,"""'.
'.~a.,o_
--
---- ..-_
,...-
........
llllil botnil';l()J IluIiW

EnBbIIl PIIC
er-.ul(l
"""'InI!'fWn.
lilIcn:iorI
\!.)ol.iI"", wnl. ~'IQI PC
u.,-...
-
~ will \II ~ dW ott..
FUror ExLtltlUlotl 1,o"''''~ttllJer''''''r''!.PC
•
s.:..-,-~ .
..........;;
'-'' '- -- J
''''IliI~ IIt!''f_lI~
Dubie IlICI.« RtoInnoI bl glpX.fStrn.eom
""-
~~'
-1-, j t .1 N)M lab ID!GIP l'ianl_.. ~

• .lOW ~l"P
\1 d.(L- . ~, !)/kf/pl
't )R.!'Ut'1 f
,) O"t V)
vi f'&-__ ~
License Dates and Upgrade Considerations BIG-IP License File
/ conflglblgip.llcense
!•
•
L.lee.nse"- cl.ate 20120801
Servic-e ellee)!. cl.ate 20131113
Storvioe Status 201)-ll-13 this sysu. . has
lui J..t
o.n .eUve servie.. eonU"aet
• ~lat!e"", IntocmaUen
"-9Ut..c... Uon Key

l.> . c~ ... d _uie", 11.1.0
I1hUo,,"",10 ZlOO
-1-_. ,._
Disk Management on the BIG-IP System Software Management on the BIG-IP System
* Image List
~ ..
..-
.--- , ..
,.
.'
. -
Store rnRlIltl'fli!rq-rclill!ld 111(1;<> ;n / -o;I1IJo1"ClljIIT1D
Stor1l k1l'\f-1.tIml m ~l ntenall(:e fl lBG [0 E VCS) o n a nelwork sh",!:'
---
__ 1".u1.._
_ JlI.I.
n .••
~
:::.:: ::'~
Pf(l'ioft rlJ lI l!IalJ1 locallon wh t>l1 creiMl"IlIIoe8
,Inooid '9lO111r,e ~ ., Unul (001' 1Ie::}'!I1M I _ _ _ I
_
PeTIodIc8 Ib' C~ -IMtlllKllc d i!;l\. l1pet11 ... ....;..-;.,
P~ 11r remove rl()(1-crllJ ~i)llnIlltlUlrt;:mce files
--
SOl..lA.CDJ. MClint8ining di~k space on the Blt;.-IP system
. -~
Booting from a New location Defining User Roles
Wha t can the BIG-IP user see? What tan t.he BIG-lP user do?
'"
..., ",.
"". -
~.
uu
_.
_.
,...
..... .-......
.-,
User Roles and Access Configuring User Access
Mcourn PlOperi tH
1=
jotmd oe
WdlA~~ul il ~
Ecl rtOl (ASM\ Guesl
" -j
---
Partitions Allow More Effective Use of Resources Partitions Facilitate Administrative Agility
f->eP<lrtmcnt B
gggg ggog
--------------------- ---------i---------------
---- --------
Allowed Object References across Partitions Disallowed Object References across Partitions
1'.... l llflr.
--- ~ J
"
Traffic Processing Considerations with Partitions Traffic Processing Considerations with Partitions
•• _100
-. "
Configuration Object Names across Partitions Configuring User Partition Access
/O'.. F\A jI"l1rtR

A,tcount Propertln
Usel Namlll
'lta..r tlL t I'lt tp J>dCl l . {~
?•
Ie.:...:", I hl Lp _pool ...
, ,
Term lQ,g l. -
Adm inistering Across Partitions load Balancing Behavlor on CMP Disabled Virtual Servers
....
1'2 ltuO 11)0 172.UL.20.UIO 172..16.20.380 112.1620.• 80
G
_
Load Balancing Behaylor on CMP Enabled Virtual Servers vCMP Components and Administration
yCMP Guest 1.
Ii ~~_."..
vCMP Guest 2
- a
vCMP
Guest 3
112.16.10.411:0
'''-
Flexible Resource Allocation Flexible Resource Allocation
User Roles and Partitions lab ) Chapter 12 -IRules
• C"'*' ~IW! IMInlllonl .....nA 1INI1"1In8, Iftf lo'IIIr.a£cr ~

· C~~~r.L' ...-. CLJ:m r_XDQ'%I'D I
· eon,p.,, ... dl
if { lI tP. : ."~·u· .dd:t-1 ~" 'UI_ '10 ., I {
· v_ ~,"C N~'tI11u,allo" f,1es "".....,1
,,-~ = ...
• ~-
,'Q)",f'I'IiQI,
~ jP3rtB
""t' ''I'
wn... PT_Sn: Persat • ill ft ''''''
",'L""D IlnplJ pool

"""
In. .20.5 172.16.20.1 172.1 .20.4
,. -
I :- . ,. - ....
Common Uses for iRules
LTM ASM
Speallc server
HTTPtoHTTPs
APM
l
Inlell.gern SNAT
u ~ss AD QueI)' resUlt! 10 web seNe'
GTM [J Two.lactor aulhen~
Inlell \:erll DNS
iRule Basic Syntax iRule Events
When event X occurs, if A is true, do this, or else

do that
T
- ~, '-bon !\'IIHf I
I! I A 1 { j( j ~uLl....u_" ~1i.1
.a.~I:,,_...t.en_.:Q1e<,_CC<'dJ t !UII_'. u .
I
I ~rrMpOn" 5fR'tTJI 1],1,111
iRule Example Configuring IRules
'ooiI _ttm>_~t {
LI ~ U IUn'- t~"lc r Ueer-;r,,~1 a::nt.a:I"" ' MSIE"I ) {
' ~f {
1.,..,1 lo-_t lS.JlOcl
111mt' - ~r ~""":J"m l o:;.1t.ala" . ~l.lIat 1{
,.... ,
fXJOl /ttJm<nM F I
Pools Using:
UsingGUI:
Nodes BIG-IP GUI
NewVS:
Profiles lRules edItor
Resources section
Monitors Nolepad++
Exlsling VS:
Resources lab
Configuring iRules Course Agenda
Addl1 101'1011JlIIU)urus
Inlerac::tW UW-. Communltv Day 1 Day 2
hUp IId~lnU S.com
1 Gell;ng Slaflllcf .....'VIBIG-IP 8. oe"""'I'C~lCIItIOn Servl~
2. Pl'oct....slng Trllt'-.'II1I;1l. U W . M """

9. rroublla5hoOOng BIG-tP
3 'Uscog NAltl 8!'\d SNAl ll
10. H-.e BIG IP Product SUJ\l:
4 us.",g the Trun K: ~\I:
Shell (t r lih l U . AclmMl.f'unjl. tf'Ito OlG-lP
Sysw m
5 Morutof1flll.
12. C ~llYl!I.~~IOn
6. Moolf'tlne; r l!lflic B-.; huvlor .....m Oe' .....,. ~h~1u
'j)rofile~
Modifying f lOlhlC- ~ WIth
Pe rslSle nte
--
F5 Certification Roadmap F5 Instructor Led Training Courses
® ..v " ..*1.
iRules lab •
1IoAII~,*,,'1t
l'oUilyl....H 2 1_1fIIIo
• ~1I'r' .... :sc.-
F5 NetwOl'ks Training . ...... J " ~ 1\I.Jl1l..pQft
. ~IoJI.I]
.... ~ l l<>n
I1IIpJlto..tu l: tu)
IIllPYIKl .";0;lIT.
Iil/IID1D'ri . tlB
..................... ®
CERTIFICATE OF COMPLETION
has satisfactorily completed a course entitled
~k\v'\~
Date :
John McAdam
Instructor: President and CEO
FS Networks, Inc . 401 Elliott Avenue West, Seattle, WA 98119 888-882-4447 WVII"'N.f5.(om
F5 Network s, Inc. F5 Network> F5 Networks Ltd . FS Net'Norks

Corporate Headquarters ASia-PaCific Europe/Middle-EastJAf(l(;a Japan K K.
info@f5.com apaonfo@fS com em eainfo@fS.(om fSj-info @f 5.(om
ClJDI1'~ ,j"lwork s. In( All '''lI'I~i~(vW FS. ,~ Nll' rwnrll. thotf., I!'g o, ano IT a()'~ry Your way.. ;If'" IraCl<>m;or lt!: (J f r5 NeI ...IOI ~ ~. In(. In ,fl(. U$ and I" ~~, olltl" UMJl'1f'M Oll"\e' f 5 l f~ Ik'"",r Ale.cIiorl"' 1Ptt
", T~ (<Mj A'ly otht!t PIUOU[b. IoI!IrvkA ~. Or ((I 'npany l\,IroIilh 'fit'<H>led hr.,.>!" .,..., lit u.oelllilrb 0 1 ,tlf'U ICIr-1've own~r~ ..... ,ttl no en L1Of~mIeM or Jltt.,rtOfr. l'l P'rK\ 0< ;"'I"~, (1.1,.,.... by I ~ , (){1().()O(90' 111

F5 Administering BIP-IP V11

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

F5 Administering BIP-IP V11

Uploaded by

Copyright:

Available Formats

-

Administering BIG-Ip® V11

v11.4.0 - December, 2013

Administering BIG-IP v1.1

Sixth Printing; December, 2013

© 2013, F5 Networks, Inc. All rights reserved.

Support and Contact Information

FS Networks, Inc. F5 Networks, Ltd. FS Networks, Inc. FS Networks, lne.

Administering BIG-IP v11

Administering BIG-IP v11

Administering BlG-IP v11

Chapter 1: Selling Up the BIG-IP System ............................................................................ 1-1

Introducing the BIG-IP System .... .............. ...1-1

Initially Setting Up the BIG-IP System ........................................................................................................... 1-10

Configuring the Management Interface ......................................... I-II

Activating the Software License ............................................................................................................... 1-13

Provisioning Modules and Resources ...................................................................................................... 1-15

Specifying BIG-IP Platform Properties .................................................................................................... 1-18

Configuring the Network .............. . .......................................................................................... 1-22

Creating an Archive of the BIG-IP System ...................................................................................................... 1-26

F5 Support Resources and Too]s.. ......................... . ..................... 1-28

Chapter Resources .................. . ... ]-32

BIG-IP System Setup Labs .. 1-33

Lab I.I - Configure the Management Port ............................................................................................... ] -34

Lab 1.2 - Activate the BlG-IP System..... ...................... . .......................................... 1-43

Option A: Activate a licensed BIG-IP system ............. . . ........................................ 1-44

Option B: Activate an unlicensed BIG-1P system ................................. 1-46

Lab 1.3 - Classroom Network Configuration ........................................................................................... I-50

Lab 1.5 - AskF5 Research Lab (Optional) ............................ . ................................................................. 1-61

Administering BIG-IP v11

Chapter 2: Traffic Processing with LTM .............................................................................. 2-1

Overview ofLTM Traffic Processing ........... . .. ........ 2·1

Configuring Virtual Servers and Pools ................... . .......... 2·8

Load Balancing Concepts .......................................... . ................................................................. 2-11

Traffic Statistics and Logs ............................................... . ............................ 2-14

Lab 2.2 - Packet Discards Lab (Optional) .................... . .................................... 2·28

Chapter 3: Using NATs and SNATs ..................................................................................... 3-1

NAT Concepts ..................................................................................... . .............................. 3-2

SNAT Concepts .............................................................................. . ............................ 3·6

SNAT Pools ....... . ...................................................................................... 3·17

Chapter Resources ........................................................................................................................................... 3-20

Address Translation Labs ............................................................................ . .. 1·33

Lab 3.1 - NAT Lab ................................ . .. 3·21

Lab 3.2 - SNAT Lab ................................................................................ . ... 3·23

Chapter 4: Using the Traffic Management Shell (tmsh) ..................................................... 4-1

Traffic Management Shell (trush) .................................. . .................................... ~I

Accessing the Traffic Management Shell (trush). ....................................................................... ~2

Understanding and Navigating the tmsh Hierarchical Structure .4·3

Command Completion Feature ................................................................................. . .... 4-6

tmsh Help Functions ............................................. . ........................................................ ~7

tmsh Command History Feature ........................... .. ........................ 4-8

tmsh on DevCentral .............................................................................................. . ........................... 4-9

BIG·IP Configuration State and Files .............................................................................................................. 4-10

BIG-IP Configuration Files ................................................... . ......................................................... 4-12

Loading and Saving the System Configuration ......................... . ............................................................. 4-13

Shutting Down and Restarting the BTG-IP System .................................................................................. 4·14

Chapter Resources ......................... ................................................................................... 4·21

It Administering BIG-IP v11

Chapter 5: Monitoring ........................................................................................................... 5-1

Monitor Concepts .............................................................................................................................................. 5-1

Configuring Monitors.. . . .. .... ....... . ................. 5-9

Assigning Monitors to Resources. .. 5-12

Managing Pool, Pool Member, and Node Status ............................................................................................. 5-17

Using the Network Map ....... ............. .................. . ... 5-23