F5 Config Guide PDF

F5 Networks Training
Configuring BIG-IP LTM v12

Local Traffic Manager
Instructor Guide
v12.1 June, 2016
Instructor Guide: Configuring BIG-IP LTM v12.1

Configuring BIG-IP LTM v12
Instructor Guide
Ninth Printing; June, 2016
This manual was written for F5 solutions at the version listed on the front cover of this document. Some of the features discussed
in this course were added with this version; but many of the concepts also apply to previous and subsequent versions.
2016, F5 Networks, Inc. All rights reserved.
Support and Contact Information

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

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 KT16 8AP #08-01/02 Suntec Tower 5 4-15-1 Akasaka, Minato-ku
T (888) 88BIG-IP United Kingdom Singapore, 038985 Tokyo 107-0052 Japan
T (206) 272-5555 T (44) 0 1932 582-000 T (65) 6533-6103 T (81) 3 5114-3200
F (206) 272-5557 F (44) 0 1932 582-001 F (65) 6533-6106 F (81) 3 5114-3201
Training@f5.com EMEATraining@f5.com APACTraining@f5.com JapanTraining@f5.com

Legal Notices
Copyright
Copyright 2016, F5 Networks, Inc. All rights reserved.
F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5
assumes no responsibility for the use of this information, nor any infringement of patents or other rights
of third parties which may result from its use. No license is granted by implication or otherwise under any
patent, copyright, or other intellectual property right of F5 except as specifically described by applicable
user licenses. F5 reserves the right to change specifications at any time without notice.
Trademarks
AAM, Access Policy Manager, Advanced Client Authentication, Advanced Firewall Manager, Advanced
Routing, AFM, APM, Application Acceleration Manager, Application Security Manager, AskF5, ASM,
BIG-IP, BIG-IP EDGE GATEWAY, BIG-IQ, Cloud Extender, Cloud Manager, CloudFucious, Clustered
Multiprocessing, CMP, COHESION, Data Manager, DDoS Frontline, DDoS SWAT, Defense.Net,
defense.net [DESIGN], DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client, Edge
Gateway, Edge Portal, ELEVATE, EM, ENGAGE, Enterprise Manager, F5, F5 [DESIGN], F5 Agility,
F5 Certified [DESIGN], F5 Networks, F5 SalesXchange [DESIGN], F5 Synthesis, f5 Synthesis, F5
Synthesis [DESIGN], F5 TechXchange [DESIGN], Fast Application Proxy, Fast Cache, FCINCO, Global
Traffic Manager, GTM, GUARDIAN, iApps, IBR, iCall, iControl, iHealth, Intelligent Browser
Referencing, Intelligent Compression, IPv6 Gateway, iQuery, iRules, iRules OnDemand, iSession, L7
Rate Shaping, LC, Link Controller, LineRate, LineRate Point, LineRate Precision, LineRate Systems
[DESIGN], Local Traffic Manager, LROS, LTM, Message Security Manager, MobileSafe, MSM,
OneConnect, Packet Velocity, PEM, Policy Enforcement Manager, Protocol Security Manager, PSM,
Ready Defense, Real Traffic Policy Builder, SalesXchange, ScaleN, SDAS (except in Japan), SDC,
Signalling Delivery Controller, Solutions for an application world, Software Designed Applications
Services, Silverline, SSL Acceleration, SSL Everywhere, StrongBox, SuperVIP, SYN Check,
SYNTHESIS, TCP Express, TDR, TechXchange, TMOS, TotALL, TDR, TMOS, Traffic Management
Operating System, Traffix, Traffix [DESIGN], Transparent Data Reduction, UNITY, VAULT, vCMP,
VE F5 [DESIGN], Versafe, Versafe [DESIGN], VIPRION, Virtual Clustered Multiprocessing, WebSafe,
and ZoneRunner, are trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries,
and may not be used without F5's express written consent.All other product and company names herein
may be trademarks of their respective owners.
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 one or more patents indicated
at: http://www.f5.com/about/policies/patents

Table of Contents
Table of Contents
Chapter 1: Course Description............................................................................................. 1-1
Course Overview ................................................................................................................................................ 1-1
Audience............................................................................................................................................................. 1-1
Course Objectives............................................................................................................................................... 1-2
Prerequisites ....................................................................................................................................................... 1-3
Additional Documentation and Resources ......................................................................................................... 1-4
Course Outline.................................................................................................................................................... 1-5
Chapter 2: Print Version and Organizational Changes....................................................... 2-1
Chapter 3: Classroom Setup Instructions........................................................................... 3-1

Accessing the Instructor Site on F5 University ................................................................................................. 3-1
Accessing the ATC Support Site on F5 University ............................................................................................ 3-3
Classroom Network Configuration..................................................................................................................... 3-4
Logical Networks ........................................................................................................................................ 3-4
F5 Classroom Network Diagram................................................................................................................. 3-5
Instructor BIG-IP System IP Addresses ...................................................................................................... 3-6
Student Workstation IP Addresses .............................................................................................................. 3-7
Back-end Application Servers IP Addresses ............................................................................................... 3-8
Training Server 3.4 Routing Considerations ............................................................................................... 3-9
Setting Up the Instructor BIG-IP System (LTM17) ......................................................................................... 3-10
Overview ................................................................................................................................................... 3-10
Setup Steps ................................................................................................................................................ 3-10
Sample Script to Set LTM17 as Default Internet Gateway ....................................................................... 3-11
LTM17 Configuration Object Use by Course ........................................................................................... 3-12
Setting Up the Back-End Servers ..................................................................................................................... 3-15
Setting Up Training Server 3.4.................................................................................................................. 3-15
DNS Zones on Training Server 3.4 ........................................................................................................... 3-19
Setting Up Hack-It 2.0 Server ................................................................................................................... 3-23
Setting Up dc.f5trn.com Server ................................................................................................................. 3-23
Setting Up the Student Workstations................................................................................................................ 3-24
Student Workstation Tool Usage............................................................................................................... 3-25
Configuring BIG-IP LTM v12.1 Class Setup ............................................................................................... 3-27
Instructor Guide: Configuring BIG-IP LTM v12.1 T-i

Chapter 1 Course Description
Chapter 1: Course Description
Course Overview
Description
This three-day course gives network professionals a functional understanding of BIG-IP Local Traffic
Manager, introducing students to both commonly used and advanced BIG-IP LTM features and
functionality. Incorporating lecture, extensive hands-on labs, and classroom discussion, the course helps
students build the well-rounded skill set needed to manage BIG-IP LTM systems as part of a flexible and
high performance application delivery network.
Topics covered in this course include:
BIG-IP initial setup (licensing, provisioning, and network configuration)

A review of BIG-IP local traffic configuration objects
Using dynamic load balancing methods
Modifying traffic behavior with persistence (including SSL, SIP, universal, and destination
address affinity persistence)
Monitoring application health with Layer 3, Layer 4, and Layer 7 monitors (including transparent,
scripted, and external monitors)
Processing traffic with virtual servers (including network, forwarding, and reject virtual servers)
Processing traffic with SNATs (including SNAT pools and SNATs as listeners)
Configuring high availability (including active/standby and N+1 sync failover device groups,
connection and persistence mirroring, and sync-only device groups)
Modifying traffic behavior with profiles (including advanced HTTP profile options, caching,
compression, and OneConnect profiles)
Advanced BIG-IP LTM configuration options (including VLAN tagging and trunking, SNMP
features, packet filters)
Deploying application services with iApps
Customizing application delivery with iRules and local traffic policies
By the end of this course, the student should be able to use both the Configuration utility, TMSH,
and Linux commands to configure and manage BIG-IP LTM systems in an application delivery
network. In addition, students should be able to monitor the BIG-IP system to achieve
operational efficiency, and establish and maintain high availability infrastructure for critical
business applications.
Audience
This course is intended for system and network administrators responsible for installation, setup,
configuration, and administration of the BIG-IP LTM system.
Instructor Guide: Configuring BIG-IP LTM v12.1 1-1

Chapter 1 Course Description
Course Objectives
At the end of this course, the student will be able to:
Access the BIG-IP system to configure the management interface
Activate the BIG-IP system for operation, including licensing, provisioning, and optional device
certificate installation
Use the Setup utility to create the classroom lab environment network configuration
Back up the BIG-IP system configuration for safekeeping
Configure virtual servers, pools, monitors, profiles, and persistence objects
Test and verify application delivery through the BIG-IP system using local traffic statistics
Configure priority group activation on a load balancing pool to allow servers to be activated only
as needed to process traffic
Compare and contrast member-based and node-based dynamic load balancing methods
Configure connection limits to place a threshold on traffic volume to particular pool members and
nodes
Differentiate between SSL, SIP, universal, and destination address affinity persistence, and
describe use cases for each
Descript the three Match Across Services persistence options and use cases for each
Configure health monitors to appropriately monitor application delivery through a BIG-IP system
Configure different types of virtual services to support different types of traffic processing
through a BIG-IP system
Configure different types of SNATs to support routing of traffic through a BIG-IP system
Establish device trust and configure an active/standby pair in support of high availability
Configure and manage a sync-failover device group with more than two members
Configure stateful failover using connection mirroring and persistence mirroring
Configure VLAN tagging and trunking
Restrict administrative and application traffic through the BIG-IP system using packet filters, port
lockdown, and virtual server settings
Configure SNMP alerts and traps in support of remote monitoring of the BIG-IP system
Configure the BIG-IP system to act as a gateway between IPv4 and IPv6 networks
Use an F5-supplied iApp template to deploy and manage a website application service
Develop a simple iApp template
Use iRules and local traffic policies appropriately to customize application delivery through the
BIG-IP system
1-2 Instructor Guide: Configuring BIG-IP LTM v12.1

Chapter 1 - Setting Up the BIG-IP System 1-11
BIG-IP System Setup Labs

The BIG-IP System Setup Labs are divided into several sections. Your instructor will tell you which lab
to start with:
Lab 1.1 Configure the Management Port
Lab 1.2 Activate the BIG-IP System and Configure the Network
Lab 1.3 Test Administrative Access
Lab 1.4 Archive the Configuration
Estimated Time for Completion: 35 minutes
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.31 in the lab instructions would be
entered as 192.168.1.31 when carrying out the instruction. A password
specified as rootX in the instructions would be entered as root1.
If lab instructions do not provide a value for a particular configuration

parameter, accept whatever the default is for that parameter.
Lab Preparation Tasks
Verify workstation IP addresses are properly configured
Check your workstations network settings to ensure that it is configured with two IP addresses:
192.168.X.30/16 and 10.10.X.30/16. This will allow you to access the BIG-IP system through both the
management network and external self IP, as well as access the applications you configure it to deliver.
Continue with Lab 1.1: Configure the Management Port
Configuring BIG-IP LTM v12 1-11

1-12 Chapter 1 - Setting Up the BIG-IP System
Lab 1.1 Configure the Management Port

(Optional for BIG-IP VE Classrooms)
Lab Objectives
Configure an IP address and network mask

for the BIG-IP management port to provide
administrative access to the BIG-IP system
from the students workstation
Lab Requirements
For classrooms with BIG-IP hardware devices, serial console access to the BIG-IP system or
physical access to the BIG-IP device if using the LCD option. This lab can be skipped if the
management port is already configured, as is often the case in BIG-IP VE classroom
environments.
Configure the Management Port
Your instructor will tell you which method you will use to configure your
BIG-IP systems management port, or if you will bypass this lab altogether
(e.g. if your management port is already configured):
Lab 1.1A: Configure the Management Port via a Serial Console (pages 1-
13 thru 1-14)
Lab 1.1B: Configure the Management Port via the LCD Panel (page 1-15)
If your management port is already configured, please skip to Lab 1.2,

which begins on page 1-16.
1-12 Configuring BIG-IP LTM v12

Lab 1.1A: Configure the Management Port via a Serial

Console
This lab requires serial console access to your BIG-IP system (not
available in BIG-IP VE classroom environments).
Access the serial console
1. Gain access to the BIG-IP systems serial port

a. For classes using serial cables, connect a null-modem cable between the BIG-IP device
and a terminal with VT-100 emulation. The serial settings should N-8-1 at 19,200bps.
b. For classes using serial terminal emulators, open an SSH session using PuTTY (or other
SSH client) to the serial console IP address provided by your instructor. This should
connect you to the serial port of your BIG-IP system. You may need to log into the
console server before logging into the BIG-IP system in the next step. Your instructor
will provide credentials, if necessary.
2. When prompted to log into the BIG-IP system, enter root for the username and default for the
password.
3. At the Linux bash prompt (e.g. config #), enter the command: config
4. Start the utility by clicking the OK button.
Use the <Tab> key to tab between fields and options in the config tool.
Use the <Backspace> and/or <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.
Select manual configuration of the IP address
5. On the Configure IP Address panel, 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.)

Set the IP address to 192.168.X.31
6. On the Configure IP Address panel, use the <Backspace>, <Delete>, and/or arrow keys to
change the IP address to 192.168.X.31, 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.
Set the netmask to 255.255.0.0
7. On the Configure Netmask panel, set the netmask to 255.255.0.0, press the <Tab> key to
highlight the OK option, then press the <Enter> key to continue.
Set no default route
8. When prompted to create a default route for the management port, select the No option and press
the <Enter> key to continue. In our classroom environment, no default route is required.
Confirm the management port configuration
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. If the
options are not correct, select the No option and rerun the config command.
IP Address 192.168.X.31
Netmask 255.255.0.0
Unless otherwise instructed, please skip forward to Lab 1.2: Activate the
BIG-IP System and Configure the Network on page 1-16.

Lab 1.1B: Configure the Management Port via the LCD

Panel (Optional)
This optional lab can only be performed on BIG-IP hardware devices.
This lab can only be carried out if your classroom environment includes BIG-IP
hardware devices. All steps are done using the buttons to the right of the LCD
display on the 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.
10. Press the red X button to start the configuration process.
11. Using the up/down arrows, navigate to System menu and press the
green check mark button to select it.
12. Navigate to the Management menu and press the green check mark button to select it.
13. Navigate to the IP Address menu and select it.
14. Navigate to the IP Address field and select it.
15. 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 number. Press the green check mark button
to save your setting.
16. Navigate to the Netmask field and select it.
17. Enter the netmask as 255.255.0.0 and save your setting.
18. 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 and Configure the
Network

Lab 1.2 Activate the BIG-IP System and

Configure the Network
Lab Objectives
Ensure the BIG-IP system:
Is properly licensed and provisioned
Has a valid host name, and updated root and admin user credentials
Has the VLANs and Self IPs that are used in support of the classroom lab environment
Is prepared for high availability
Lab Requirements
Access to the BIG-IP systems base registration key

Access to the Internet or to the BIG-IP systems license file
Network access to the BIG-IP systems management port on the 192.168/16 network
Access the Configuration utility via the MGMT Port
Start the Setup utility
1. Open a browser session to https://192.168.X.31 where X is your station number. BIG-IP ships
with a self-signed SSL certificate. Accept the certificate (not permanently, if using Firefox) and
log in with username admin and password admin.
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.
2. Click the Next button to start the Setup utility.
If your BIG-IP system is already licensed, a Reactivate button and a

Next button will appear at the bottom of the License page. If this is the
case, click the Next button and skip forward in this lab to Provision
Your BIG-IP System. Otherwise, continue with the next step.
3. On the subsequent Setup Utility License page, click the Activate button to begin the licensing
process.

License the BIG-IP system
If you have Internet access from your classroom workstation, follow the
instructions in step 4. If you do not have Internet access from your
classroom workstation, follow the instructions in step 5.
4. Manually activate your BIG-IP license at the F5 License Server:

a. Ensure there is already a value present in the Base Registration Key field on the Setup
License page. If the field is blank, please ask your instructor for assistance in locating the
proper registration key to use with your BIG-IP system.
b. In the Activation Method setting, select the Manual radio button.
c. In the Manual Method setting, select the Download/Upload File radio button.
d. In the Step1: Dossier area, click the button that reads Click Here to Download Dossier
File. If prompted where to save the dossier, select your desktop. Note where the dossier
was downloaded, as you will need it to generate a license.
e. In Step2: Licensing Server, click the link that reads Click here to access F5 licensing
server to open a new browser window to the F5 license server.
f. On the F5 License Server, click the Activate License link.
g. Click the Choose File button to the right of the Select your dossier file prompt. Locate
the dossier you downloaded in step 4d, and upload it to the F5 License Server.
h. Click the Next button on the F5 License Server to generate a license from the dossier.
(You may be prompted to accept the terms of the F5 License Agreement.)
i. On the resulting page, click the Download license button to download the generated
license to your workstation. If prompted where to save the license, select your desktop.
Note where the license was downloaded, as you will need it to complete activation.
j. Back on your BIG-IP system, on the Setup License page, click the Choose File button
to the right of the Step 3: License field. Locate the license you downloaded in step 4i,
and upload it to your BIG-IP system.
k. Click the Next button on the BIG-IP system to complete license activation.
l. Your BIG-IP system will take a few moments to verify the license activation. Wait for
the verification to complete successfully, and click the Continue button to return to the
next step in the Setup utility.
Skip forward in this lab to Provision Your BIG-IP System (step 6).

Your instructor will let you know where to find the license file for your
BIG-IP system. Make sure this file is available to you before carrying out
step 5 below. Please skip to step 6 if you licensed your BIG-IP
system in step 4.
5. Manually activate your BIG-IP license using an existing license file.

a. Ensure there is already a value present in the Base Registration Key field on the Setup
License page. If the field is blank, please ask your instructor for assistance in locating the
proper registration key to use with your BIG-IP system.
b. In the Activation Method setting, select the Manual radio button.
c. In the Manual Method setting, check the Download/Upload File radio button.
d. In the Step1: Dossier area, click the button that reads Click Here to Download Dossier
File. If prompted where to save the dossier, select your desktop.
Normally at this point, you would access the F5 License Server and upload the dossier you just
downloaded to generate a license. This has already been done for you in this classroom
environment. Please ask your instructor for assistance if you do now know where the appropriate
license file for your BIG-IP system is located.
e. In the Step3: License area, click the button that reads Choose File. Navigate to the
license file you identified earlier, and upload it to your BIG-IP system.
f. Click the Next button on the BIG-IP system to complete license activation.
g. Your BIG-IP system will take a few moments to verify the license activation. Wait for
the verification to complete successfully, and click the Continue button to return to the
next step in the Setup utility.
Skip forward in this lab to Provision Your BIG-IP System (step 6).

Provision Your BIG-IP System

6. On the Resource Provisioning page of the Setup utility, provision your BIG-IP system, as shown
in the table below.
Setup utility
Setup Utility Resource Provisioning
Current Resource Allocation section

Management (MGMT) Small
Local Traffic (LTM) Nominal
When complete, click Next (or Submit)
Your BIG-IP may produce a warning message that certain system

daemons may restart or the system may reboot, causing your session to
wait for anywhere up to several minutes. This is normal behavior when
changing provisioning settings. Click the OK button to continue.
Accept the BIG-IP Self-Signed Device Certificate

7. After provisioning is complete, you should be taken to the Device Certificates page in the Setup
utility. We will be using the BIG-IP systems self-signed certificate in class. Note the expiration
date for the certificate. (If the certificate is expired, please notify the instructor.) Click the Next
button to continue the Setup utility.

Configure Platform General Properties and User

Administration
8. 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.
Where specific information is not provided in the instructions below, accept the defaults on your
BIG-IP system.
Setup utility
Setup Utility Platform
General Properties section

Management Port Configuration Manual
IP Address[/prefix]: 192.168.X.31
Management Port
Network Mask: 255.255.0.0
Host Name bigipX.f5trn.com
Host IP Address Use Management Port IP Address
Time Zone Set to your classrooms local time zone
User Administration section
Disable login: Unchecked
Root Account Password: rootX
Confirm: rootX
Password: adminX
Admin Account
Confirm: adminX
When complete, click Next, then OK
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 will need to log back in again with your new password.
9. Log back in to BIG-IP as user admin with password adminX. You should be taken directly to
the Setup Utility Network page.

Configure the Classroom Network

10. Continue the Setup utility by performing a Standard Network Configuration. Click the Next
button under the Standard Network Configuration heading.
Configure Redundant Device Wizard options
11. Set Redundant Device Wizard Options to prompt for ConfigSync settings and High
Availability options.
Setup utility
Setup Utility Redundancy
Redundant Device Wizard Options section

Check the box for Display configuration
ConfigSync
synchronization options
Check the box for Display failover and mirroring
High Availability options
Select Network for Failover Method
When complete, click Next
Configure Self IPs and VLANs
12. Configure VLAN internal and its self IPs, interface, and default port lockdown settings.
Setup utility
Setup Utility VLANs
Internal Network Configuration section

Address: 172.16.X.31
Self IP Netmask: 255.255.0.0
Port Lockdown: Allow Default
Address: 172.16.X.33
Floating IP
Port Lockdown: Allow Default
Internal VLAN Configuration section
VLAN Interfaces: Select 1.2
Interfaces Tagging: Select Untagged
Click the Add button

13. Configure VLAN external and its self IPs, interface, and port lockdown settings.
Setup utility
Setup Utility VLANs
External Network Configuration section

External VLAN Click the Create VLAN external radio button
Address: 10.10.X.31
Self IP Netmask: 255.255.0.0
Port Lockdown: Allow None
Default Gateway Leave blank
Address: 10.10.X.33
Floating IP
Port Lockdown: Allow None
External VLAN Configuration section
Interfaces: Select 1.1
Interfaces Tagging: Select Untagged
14. Configure the high availability network to use the existing VLAN named internal.
Setup utility
Setup Utility VLANs
High Availability Network Configuration section

High Availability VLAN Click the Select existing VLAN radio button
Select VLAN internal
Configure Network Time Protocol
15. If NTP servers are needed in your course, they will be configured in a later lab. Leave this page
with its default settings, and click the Next button to continue.
Configure Domain Name Server
16. If DNS settings are required in your course, they will be configured in a later lab. Leave this page
with its default settings, and click the Next button to continue.

Configure ConfigSync
17. Configure ConfigSync on the non-floating self IP for VLAN internal, the VLAN were using for
high availability (HA).
Setup utility
Setup Utility ConfigSync
ConfigSync Configuration section

Local Address 172.16.X.31 (internal)
Configure Failover Unicast and Failover Multicast settings
18. Use the default settings for Failover Unicast Configuration and Failover Multicast
Configuration, as shown below:
Setup utility
Setup Utility Failover
Failover Unicast Configuration section

172.16.X.31 | 1026 | internal
Local Address | Port | VLAN
192.168.X.31 | 1026 | Management Address
Failover Multicast Configuration section
Use Failover Multicast Address Unchecked (Disabled)
Mirroring configuration
19. Use the default primary and secondary local mirror address settings for Mirroring
Configuration, as shown below:
Setup utility
Setup Utility Mirroring
Mirroring Configuration section

Primary Local Mirror Address 172.16.X.31 (internal)
Secondary Local Mirror Address None

Finish the Setup Utility

You have now completed configuring the network interfaces that are used in support of the basic
classroom environment. If your course requires additional HA configuration, it will be performed in a
later lab.
20. Click the Finished button under the 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 Setup Utility Complete.
Classroom Network Configuration Diagram
Figure 6: Conceptual representation of your classroom environment after lab completion
Continue with Lab 1.3: Test Administrative Access

Lab 1.3 Test Administrative Access

Lab Objectives
Ensure that your BIG-IP network settings are correct

Customize administrative access to the BIG-IP system by allowing SSH and HTTPS traffic
directly to the self IPs for VLAN external
Lab Requirements
Access to a BIG-IP system that has completed the initial setup process, including management
port configuration, licensing, provisioning, device certificate setup, and standard network
configuration.
Test Administrative Access to the BIG-IP System
Test SSH (port 22) access to the management port
21. Using PuTTY, open an SSH session to the management port at 192.168.X.31. Make sure the
protocol is set to SSH (port 22) before connecting. Log in as root with password rootX.
Test HTTPS (port 443) access to VLAN externals self IPs
22. Try to open a browser session to https://10.10.X.31. Were you able to connect?
Your browser connection in the previous step should fail, as the self IP is
currently protected via Port Lockdown. When using the Setup utility to
create VLAN external, the BIG-IP system allows no access to VLAN
externals self IPs by default (Allow None). This is a change in behavior
from previous versions where the Port Lockdown setting for VLAN
externals self IPs defaulted to Allow 443 when running the Setup utility.

23. Navigate to Network Self IPs 10.10.X.31 and reconfigure the self IP address 10.10.X.31 to
also allow access via port 443.
Configuration utility
Network Self IPs 10.10.X.31
Configuration section
Port Lockdown Select Allow Custom
Select the TCP and Port radio buttons
Custom List Enter 443 in the field that appears to the right of Port
When finished Click Update
24. Try to open a browser session to https://10.10.X.31 again. This time you should be successful.
Accept the sites certificate, if and when prompted about the validity of the certificate. If using
Firefox, do not create a permanent exception. (Uncheck the permanent exception box.)
25. Log in as user admin with password adminX.
26. Try to open a browser window to https://10.10.X.33, the floating self IP on VLAN external. If
you were unsuccessful, fix the problem using the same method as you did in an earlier step.
Test SSH (port 22) access to VLAN externals non-floating self IP
27. Using PuTTY, try to open an SSH session to 10.10.X.31. Were you able to connect? Why or why
not? If you were unable to connect, allow SSH access to 10.10.X.31 using the same method as in
an earlier step, and test.
Configure command line access for the admin user
28. On your PuTTY session to 10.10.X.31, attempt to log in with the admin user credentials (admin /
adminX). Were you successful?
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
command line access.

29. Navigate to System Users and update the admin user settings to permit access to the command
line interface, but only to TMSH.
System Users : User List, then click on user admin
Account Properties section

Terminal Access tmsh
When finished, click Update
When changing terminal access for the admin user the user you are
currently logged in as - you may have to log back onto the Configuration
utility again.
30. Open an SSH session to 10.10.X.31 or to 192.168.X.31 and test logging in with the admin user
credentials again.
Check root user access to the Configuration utility
31. Open a browser window to https://10.10.X.31 or https://192.168.X.31 and attempt to log in as

the root user. Were you successful?
Your attempt to log into the Configuration utility as user root should fail.
User root does not have access to the BIG-IP systems administrative
Configuration utility, only to the command line. This cannot be changed.
Continue with Lab 1.4: Archive the Configuration

Lab 1.4 Archive the Configuration

Lab Objectives
Create a UCS archive of the BIG-IP system configuration.
Create a UCS Archive of Your Configuration

32. Open a browser window to https://10.10.X.31 or https://192.168.X.31 and create a backup of
your current configuration
System Archives then click Create

File Name trainX_base.ucs
When complete, click Finished, then click OK when the archive is complete
33. Download your new UCS backup to your workstation hard drive for possible use in a later lab.
System Archives then click trainX_base.ucs

Click Download: trainX_base.ucs, then save to
Archive File
desktop of your management PC, if prompted.

Chapter 2 - Reviewing Local Traffic Configuration 2-43
Lab 2.1 Configure for Application Delivery

using the Configuration Utility
Lab Objectives
Use the Configuration utility to create the configuration objects that will be used to deliver two
applications (one HTTP, the other HTTPS) through the BIG-IP system
Estimated time for completion: 30 minutes
Lab Requirements
BIG-IP base setup configuration
Remember to substitute your station number for the letter X. For example,
10.10.X.100 becomes 10.10.4.100 if you are working at station 4.
Use the Configuration Utility to Create Local Traffic Objects
Create an HTTP monitor
Create a custom HTTP monitor that will check the health of the HTTP application you will be
deploying later. Use the specifications in the table below:
Name Type Settings

Send String: GET /index.php\r\n
configltm_http_monitor HTTP
Receive String: Server [1-3]

2-44 Chapter 2 - Reviewing Local Traffic Configuration
Create pools
Define the load balancing pool whose members serve the HTTP application content. Use the
specifications in the table below:
Load Balancing
Name Members Ratio Monitor
Method
http_pool Ratio (member) 172.16.20.1:80 1 configltm_http_monitor
172.16.20.2:80 2
172.16.20.3:80 3
Define the load balancing pool whose members serve the HTTPS content for our application. Use
the specifications in the table below:
Load Balancing
Name Members
Method
172.16.20.1:443
https_pool Round Robin 172.16.20.2:443
172.16.20.3:443
Create a source address affinity persistence profile
Create a source address affinity persistence profile that will be used on the virtual server that
delivers the HTTPS application. Use the specifications in the table below. (The Timeout setting is
deliberately low so that you can observe persistence records expiring more quickly):
Persistence Parent
Name Type Profile Custom Settings
Source Timeout: 30 seconds
configltm_src_persist Address source_addr
Prefix Length: Specify IPv4 and 16
Affinity
Create virtual servers
Use the specifications in the table below to create the virtual server that will deliver the HTTP
application:
Destination
Name Default Pool
Address:Port
http_vs 10.10.X.100:80 http_pool
Use the specifications in the table below to create the virtual server that will deliver the HTTPS
application.
Destination Default Persistence

Name Default Pool
Address:Port Profile
https_vs 10.10.X.100:443 https_pool configltm_src_persist

Test Application Delivery and View Traffic Statistics
Observe traffic distribution patterns with ratio (member) load balancing
Open a browser session to the HTTP application (http_vs) at http://10.10.X.100. Hard-refresh

(Ctrl+F5) the page 5-10 times.
On your BIG-IP system, view Local Traffic Statistics for the virtual server and pool. (Statistics
Module Statistics : Local Traffic then select Pool and Virtual Servers for Statistics Type)
a. How many connections total to http_vs?
b. How many connections total to http_pool (as a whole)?
c. How many connections to each pool member in http_pool?
d. Are the connections being load balanced to the pool members as you expected them to?
Reset statistics for the virtual server and pool. Change the ratio on each member in http_pool as
shown in the table below:
Pool Member Ratio

172.16.20.1:80 4
172.16.20.2:80 4
172.16.20.3:80 1
Back on your browser session with http://10.10.X.100, hard-refresh the page 5-10 times again.
View the statistics for pool http_pool again and confirm that connections are being load balanced
according to the new ratios.
Observe traffic distribution with round robin load balancing and persistence
Open a browser session to the HTTPS application (https_vs) at https://10.10.X.100. Hard-refresh

(Ctrl+F5) the page 5-10 times.
a. Do you have a secure connection?
b. Are all your connections being load balanced? Why or why not?
View the persistence records for your BIG-IP system from the command line, and determine
which pool member are you persisting to:
tmsh show ltm persistence persist-records
a. When the persistence record expires, refresh the browser session again. Are you
persisting to the same pool member?
b. View local traffic statistics for https_pool to confirm your observations.
Have another student in the classroom (or the instructor) access your HTTPS application
(https_vs) at https://10.10.X.100.
a. Are they able to reach your virtual server? If not, think about the default routes on the
back-end servers and adjust the configuration on http_vs so that they can access your
virtual server.

b. Once they can access your virtual server, are they persisting to the same pool member as
you? Why or why not?
Remove persistence and retest
Remove persistence from https_vs.

Back on your browser session to https://10.10.X.100, hard-refresh the page several times. View
local traffic statistics on your BIG-IP system again to see how connections were distributed to the
pool members.
Expected Results
When you first tested the HTTP application through virtual server http_vs and its associated pool
http_pool, and viewed local traffic statistics, you should have seen connections distributed to all pool
members with a ratio of nearly 1:2:3 for the pool members at 172.16.20.1, 172.16.20.2, and 172.16.20.3
respectively. After changing each members ratio, and retesting, the connections should have been
distributed with a ratio of nearly 4:4:1.
When you first tested the HTTPS application through virtual server https_vs and its associated pool
https_pool, you should have seen one load balancing decision made. Subsequent connections from your
workstation (and the other students workstation) should have been directed to the same pool member as
the result of the source address affinity persistence profile attached to the virtual server. You should have
seen persistence information similar to the following:
Sys::Persistent Connections
source-address 10.10.0.0 10.10.4.100:443 172.16.20.3:443 (tmm: 0)
Total records returned: 1
After waiting 30 seconds for the persistence record to expire, you should have seen another load
balancing decision being made, followed by the creation of a new persistence record.
Also, the other student could not access your application until you added source address translation, such
as Auto Map, to the virtual servers configuration. Once added, that students connections to your virtual
server should have persisted to the same pool member as you, due to the persistence mask - 10.10.0.0.
Continue with Lab 2.2: Configure for Application Delivery using TMSH

Lab 2.2 Configure for Application Delivery

using TMSH
Lab Objectives
Use TMSH to create a virtual server and associated pool and monitor to deliver an SSH
application through the BIG-IP system
Use TMSH to create and assign a monitor to an existing pool
Lab Requirements
Lab Overview
In this lab, you will use TMSH to configure the BIG-IP system for delivery of an SSH application, and
verify traffic by viewing statistics from the command line. Remember to use the TMSH command
completion feature and TMSH help to determine command syntax.
Use TMSH to Create Local Traffic Objects
Create a pool and view its configuration
Use TMSH to define a load balancing pool whose members serve the SSH application content. (A
command hint is shown below the table.)
Load Balancing
Name Members
Method
172.16.20.1:22
ssh_pool Round Robin 172.16.20.2:22
172.16.20.3:22
(tmos)# create /ltm pool ssh_pool

load-balancing-mode round-robin
members add { 172.16.20.1:22 172.16.20.2:22 172.16.20.3:22 }
View the pool in the running configuration: list /ltm pool ssh_pool
Save the running configuration to the stored configuration: save sys config
Exit TMSH to return to the Linux bash prompt: quit

View bigip.conf. (Try both commands below. To terminate the more command, type q) Do
you see configuration data for ssh_pool? Why or why not?
more /config/bigip.conf
grep "ssh_pool" /config/bigip.conf
Create a virtual server and view its configuration
Use TMSH to create a virtual server that will deliver the SSH application.
Destination
Name Default Pool Profiles
Address:Port
ssh_vs 10.10.X.100:22 ssh_pool tcp
(tmos)# create /ltm virtual ssh_vs

destination 10.10.X.100:22
pool ssh_pool
profiles add { tcp }
View the virtual server in the running configuration: list /ltm virtual ssh_vs
Exit TMSH to return to the Linux bash prompt.
View bigip.conf again. Do you see configuration data for ssh_vs? Why or why not?
Save the running configuration to the stored configuration.
Verify ssh_vs is now in the stored configuration.
View general stored configuration data
In viewing /config/bigip.conf, what types of configuration objects do you find stored here?
View /config/bigip_base.conf. What types of configuration objects are stored here?
View /config/bigip_user.conf. What types of configuration objects are stored here?
View /config/bigip.license. What is the service check date for your BIG-IP system?
Test Application Delivery and View Traffic Statistics
Connect to the virtual server and view statistics
Open a separate SSH session (PuTTY, etc.) to ssh_vs at 10.10.X.100:22, and login with user-id
student and password student. Were you able to connect and login?
On your BIG-IP system, use TMSH to view statistics and determine the pool member you load
balanced to:
tmsh show /ltm pool ssh_pool members { all }

View local traffic statistics for the virtual server:

tmsh show /ltm pool ssh_pool
tmsh show /ltm virtual ssh_vs
a. Compare Bits In and Bits Out for the virtual server (client-side) with Bits In and Bits
Out on the pool member you load balanced to (server-side). How do they compare?
Terminate and reestablish your connection to 10.10.X.100:22. Which pool member did you load
balance to this time?
Show the BIG-IP connection table entries for all server-side server connections to port 22.
tmsh show sys connection ss-server-port 22
a. Do you see your connection?
b. More importantly, do you see source and destination IP addresses and ports for both the
client-side and server-side connections? What are the values?
c. How long has the connection been open and idle? (Look at the value to the right of the
tcp string in the connection table entry.)
On your SSH session to virtual server ssh_vs, list the directory you are currently in: ls l
Back on your BIG-IP system, view the connection table entries again. Was the idle time indicator
updated?
Archive the Configuration

Use TMSH to save a UCS backup of your current configuration in the /shared/tmp directory:
tmsh save sys ucs /shared/tmp/trainX_module2b.ucs
Can you see the UCS you just created from the Configuration utility? Why or why not?
Use TMSH to restore the UCS archive you took at the beginning of the class. All of your
configuration objects you created in this lab should be gone. Confirm this by examining the
bigip.conf file and looking for ssh_vs and ssh_pool:
tmsh load sys ucs trainX_base.ucs
Now all of your configuration objects you created in this lab should be gone. Confirm this by
examining the bigip.conf file and looking for ssh_vs and ssh_pool.
Restore the configuration you created earlier named trainX_module2b.ucs. (Remember that its
in the /shared/tmp directory.)

Expected Results and Troubleshooting

After you initially created ssh_vs, its configuration could not be found in bigip.conf. Changes made using
TMSH affect only the running configuration. You had to manually save the running configuration to the
stored configuration in order to view the entry for ssh_vs in bigip.conf. This behavior is different from
the Configuration utility, where changes are recorded to both the running configuration and the stored
configuration immediately upon finishing.
bigip.conf contains application traffic processing objects such as virtual servers, pools, monitors, and
profiles, from the last time the running configuration was saved to the stored configuration.
bigip_base.conf contains network and system-related objects such as VLANs, self IPs, device groups,
and platform information, from the last time the running configuration was saved to the stored
configuration.
bigip_user.conf contains user names and passwords for all users configured on the BIG-IP system from
the last time the running configuration was saved to the stored configuration.
bigip.license contains the license information for your BIG-IP system. The service check date will vary
depending on when the last time the systems dossier was submitted to the F5 License Server for
activation.
UCS archives are only visible to the Configuration utility if they are located in /var/local/ucs. Therefore,
the UCS you saved in /shared/tmp is not visible from the Configuration utility.

Chapter 3 - Load Balancing Traffic with LTM 3-15
Lab 3.1 Test Priority Group Activation

Lab Objectives
Configure priority group activation on a pool and view load balancing behavior with statistics
Lab Requirements

http_pool (as configured at the end of the previous chapter)
http_vs (as configured at the end of the previous chapter)
Test Priority Group Activation
Configure priority group activation on http_pool
Reset the statistics for http_pool.

Modify pool http_pool and, on the Members tab, set Priority Group Activation to Less than
2 Available Member(s).
Modify the members in pool http_pool according to the specifications in the table below:
Member Ratio Priority Group
172.16.20.1:80 1 0
172.16.20.2:80 2 4
172.16.20.3:80 3 4
Test the effects of priority group activation
Open a new browser session, connect to http://10.10.X.100, and hard-refresh the screen 5-10
times.
View the statistics for http_pool.
a. Which pool members processed traffic?
b. How were the connections distributed between the pool members?
Disable pool member 172.16.20.2:80 in http_pool.
Back on your browser session to http://10.10.X.100, hard-refresh the screen 5-10 times.
View the statistics for http_pool again. What are the results now and why?

3-16 Chapter 3 - Load Balancing Traffic with LTM
Test the effects of persistence with priority group activation
Disable pool member 172.16.20.3:80 in pool http_pool to ensure you will load balance and
persist to pool member 172.16.20.1:80.
Assign the F5-supplied Source Address Affinity persistence profile called source_addr to
http_vs.
Back on your browser session to http://10.10.X.100, hard-refresh the screen several times and
ensure you are persisting to pool member 172.16.20.1:80. View persistence records to confirm.
Enable pool members 172.16.20.2:80 and 172.16.20.3:80 in http_pool.
Back on your browser session to http://10.10.X.100, hard-refresh the screen several times. Are
you still persisting to pool member 172.16.20.1:80, even though its priority group is no longer
activated (because the higher priority group now contains 2 members again)? View persistence
records to confirm.
Clean up
Remove persistence from http_vs.
Expected results and troubleshooting
With priority group activation set to less than 2 members and all pool members enabled, 172.16.20.1:80
should receive no traffic. Traffic is distributed to members 172.16.20.2 and 172.16.20.3 in a 2:3 ratio.
With priority group activation set to less than 2 members and pool member 172.16.20.2:80 disabled, the
next lower priority group (0) is activated. Traffic is then distributed to members 172.16.20.1 and
172.16.20.3 in a 1:3 ratio.
When you added a source address affinity persistence profile to http_vs, and forced your connections to
load balance and persist to the pool member in the lowest priority group (172.16.20.1:80), even after re-
enabling the other two members and once again having two members available in the pool, you still
persisted to 172.16.20.1:80, and would continue to do so until the persistence record expires.
Continue with Lab 3.2: Test Ratio (node) Load Balancing

Lab 3.2 Test Ratio (node) Load Balancing

Lab Objectives
Compare the effects a member-based load balancing method with a node-based load balancing
method
Lab Requirements

http_pool (as configured at the end of the previous lab)
http_vs (as configured at the end of the previous lab)
Configure Ratio (node) Load Balancing

Change the load balancing method for pool http_pool from Ratio (member) to Ratio (node).
Change the ratio of node 172.16.20.3 to 5.
Open a new browser session and connect to http://10.10.X.100, and hard-refresh the screen 5-10
times.
View pool statistics for http_pool. What are the results and how do they compare to the results
with Ratio (member) load balancing?

Since priority group activation is still configured on http_pool, only two pool members need be active in
order to meet the minimum. Members 172.16.20.2:80 and 172.16.20.3:80 are in the highest priority
group, and are the only members the BIG-IP system load balances connections across. However, even
though pool member 172.16.20.2:80 has a ratio of 2, and pool member 172.16.20.3:80 has a ratio of 3, the
BIG-IP system ignores these ratios and uses the ones that are configured on the associated nodes instead.
Node 172.16.20.3 has a ratio of 5, compared to node 172.16.20.2, which has a ratio of 1. Therefore, the
pool member at 172.16.20.3:80 receives about 5 times as many connections as the pool member at
172.16.20.2:80.
Continue with Lab 3.3: Test the Effect of Connection Limits on Priority
Group Activation

Lab 3.3 - Test the Effect of Connection Limits

on Priority Group Activation
Lab Objectives
Force a connection limit condition to cause a lower priority group of members to be temporarily
activated
Lab Requirements

Configure and Test Connection Limits
Confirm traffic behavior before connection limits

Open a browser session to http_ vs at http://10.10.X.100 and hard-refresh the screen multiple
times and very rapidly by holding the Ctrl-F5 keys down continuously for several seconds.
Refresh and view the statistics for http_pool:
a. Did pool member 172.16.20.1:80 process any connections?
b. What was the maximum number of concurrent connections processed by pool members
172.16.20.2:80 and 172.16.20.3:80?
Configure a connection limit on one pool member in priority group 4

Change the Connection Limit for pool member 172.16.20.3:80 in http_pool to 3.
On your browser session to http_vs at http://10.10.X.100, hard-refresh the screen rapidly again
by holding the Ctrl-F5 keys down continuously for several seconds.
Refresh and view statistics for pool http_pool.
a. How were the connections distributed across the pool members?
b. What was the maximum number of connections on pool member 172.16.20.3:80? Is this
what you expected?

Clean Up
Change the load balancing method on pool http_pool to Round Robin and disable priority
group activation.
Set the Connection Limit for pool member 172.16.20.3:80 in http_pool to 0.
Set Priority Group to 0 and Ratio to 1 for all pool members in http_pool.
Expected Results
Before setting a connection limit on pool member 172.16.20.3:80, traffic was load balanced only across
the two members in priority group 4: 172.16.20.2:80 and 172.16.20.3:80. The maximum number of
concurrent connections to pool member 172.16.20.3:80 will vary, but should have been well over 3.
After setting the connection limit to 3 on pool member 172.16.20.3:80, traffic was load balanced across
all pool members, as this pool member would have reached its maximum number of connections
periodically, triggering activation of priority group 0, of which 172.16.20.1:80 is a member. After
activation, the BIG-IP system load balanced traffic across all three pool members until the number of
connections on 172.16.20.3:80 went below 3. When viewing statistics for http_pool, the maximum
number of concurrent connections to 172.16.20.3:80 should have been 3. The maximum number of
concurrent connections to the other pool members will vary.


Chapter 4 - Modifying Traffic Behavior with Persistence 4-19
Lab 4.1 Implement Universal Persistence

Lab Objectives
Configure a virtual server with universal persistence using an iRule and confirm traffic behavior
using statistics
Lab Requirements

Configure and Test Universal Persistence

You can use the following command to view persistence records throughout this lab.
tmsh show /ltm persistence persist-records all-properties
Confirm traffic behavior before universal persistence
1. Open a browser session to http_vs at http://10.10.X.100, and hard-refresh the screen several
times.
a. Confirm via local traffic statistics that your connections are load balancing across all
members of http_pool.
b. Verify that no persistence records were created.

4-20 Chapter 4 - Modifying Traffic Behavior with Persistence
Create an iRule to persist on a query parameter in the HTTP URI
2. Create a new iRule named user_persist_irule that will persist on the value of the user query
parameter in the HTTP URI, if present, using the code in the table below. (Note that there are
spaces between user=, the number 5, and the &):
Definition
when HTTP_REQUEST {
if { [HTTP::uri] contains "user=" } {
persist uie [ findstr [HTTP::uri] "user=" 5 "&" ]
}
}
Create a universal persistence profile
3. Create a new universal persistence profile using the specifications in the table below. (The
Timeout setting is deliberately low so that you can observe persistence records expiring more
quickly.):
Local Traffic Profiles : Persistence, then click Create
General Properties
Name configltm_universal_persist
Persistence Type Universal
Parent Profile Universal
Configuration section:
iRule user_persist_irule
Timeout Specify30 seconds
When complete, click Finished
Assign the profile to the virtual server
4. Assign configltm_universal_persist to virtual server http_vs. (Hint: If an error occurs, you can
use the F5-supplied profile called http.)
Confirm traffic behavior after universal persistence
5. Reset the statistics for http_pool.

6. Open a browser session to http://10.10.X.100?user=abc&pw=123, and hard-refresh the screen
several times.

7. View persistence records again. Which pool member are you persisting to? What is the
persistence matching criteria (persistence value) shown in the persistence record?
8. Check the statistics records for http_pool. Is all traffic being load balanced to the same pool
member?
9. Which element(s) of the page are persisting? Why?
10. In your browsers address bar, change the user= query string from abc to something else and
hard-refresh the screen several times.
11. View persistence records again. Which pool member are you persisting to now? What is the
persistence matching criteria shown in the persistence record now?

Expected results
The page you are connecting to at http://10.10.X.100 is comprised of a number of elements. The first
connection request is for the default page, and includes the user= and pw= query parameters in the HTTP
URI. This request is load balanced according to the load balancing method for pool http_pool. The server
that processed the request is displayed in the HTML from Server X line on the page, as shown in
Figure 9 below. The HTML references many other page elements, including .jpg, .png, and .css files.
Each of these generated additional connections, none of which contained the user= parameter. Therefore,
they did not match the persistence record created on the initial connection, and were load balanced, as
shown in the traffic statistics. The only element of the page that persists is the HTML itself, and the
HTML from Server X message should remain constant as long as you are persisting.
Figure 9: The only element on the page that persists is the HTML, as it was requested with the user=
query parameter which is what the persistence criteria is generated from
Continue with Lab 4.2: Implement Match Across Services

Lab 4.2 Implement Match Across Services

Lab Objectives
Configure Match Across Services as a persistence option and observer traffic behavior
Estimated time for completion: 5 minutes.
Lab Requirements

https_vs (as configured at the end of the of Lab 2.1)
configltm_src_persist (as configured at the end of the Lab 2.1)
Confirm Traffic Behavior before Persistence

1. Set configltm_src_persist as the Default Persistence Profile for virtual servers http_vs and
https_vs.
2. Open two browser sessions - one to http://10.10.X.100 and another to https://10.10.X.100 and
refresh the page several times.
a. Are you persisting on both sessions? View persistence records to confirm.
b. How many persistence records are there?
c. Which pool member is your session to http://10.10.X.100 persisting to?
d. Which pool member is your session to https://10.10.X.100 persisting to?
3. Let both persistence records timeout so that they are deleted.
Test Match Across Services

4. Enable the Match Across Services option in the configltm_src_persist persistence profile.
5. Refresh the sessions to http://10.10.X.100 and https://10.10.X.100.
a. Are you persisting on both sessions? View persistence records to confirm.
b. How many persistence records are there?
c. Which pool member are you persisting to on both sessions?

Expected results
Without Match Across Services, the two sessionsone to http://10.10.X.100 and the other to
https://10.10.X.100are treated independently with respect to persistence. There is a chance the sessions
could have been initially load balanced to the same underlying node, but upon viewing persistence
records, you should have seen two - one for each session.
After enabling Match Across Services, and refreshing the page on both sessions, you should have seen
only one persistence record, and both pages should show results from the same underlying node for all
page elements.
Clean Up
6. Remove persistence from both http_vs and https_vs.

Chapter 5 - Monitoring Application Health 5-23
Lab 5.1 Configure and Test Monitors

Lab Objectives
Configure health checks using multiple default and custom monitors to verify pool member
availability
Lab Requirements

https_pool (as configured at the end of the previous chapter)
Establish Baseline Traffic Behavior

1. Remove any monitors from pools http_pool and https_pool. Confirm the status of the pools and
pool members is unknown.
2. Reset virtual server and pool statistics.
3. Connect to your virtual servers http_vs and https_vs, hard refresh the page several times
(Ctrl+F5), and observe traffic behavior using statistics to establish baseline traffic behavior.
Test Multiple Monitors and Availability Requirement
Configure monitors
4. Check the configuration for monitor configltm_http_monitor and ensure it meets the
specifications in the table below:
Monitor Parent Interval, Other Parameters
Type Monitor Timeout
HTTP http 5, 16 Send: GET /index.php\r\n
Receive: Server [1-3]
5. Create a new custom HTTPS monitor using the specifications in the table below:
Monitor Name Monitor Parent Interval, Other Parameters
Type Monitor Timeout
configltm_https_monitor HTTPS https 5, 16 Send String: GET /index.php\r\n
Receive String: Server [1-3]
Alias Service Port: 443 (HTTPS)

5-24 Chapter 5 - Monitoring Application Health
Assign monitors, availability requirement and test effects
6. View the local LTM log from the command line and leave the window open so you can check log
messages throughout the lab: tail f /var/log/ltm
7. Set the default monitors for pool http_pool to configltm_http_monitor and
configltm_https_monitor, and ensure Availability Requirement is set to All health monitors.
a. What is the status of http_pool after monitor assignment?
b. Look at the detail for each pool member in http_pool. Are both monitors producing
successful test results?
c. What log messages were produced as the result of applying the monitors?
d. View monitor statistics to view monitor status changes over time:
tmsh show ltm monitor https configltm_https_monitor
8. Connect to virtual server http_vs at 10.10.X.100, refresh the page several times, and use statistics
to observe how connections were load balanced.
9. Change the Receive String on configltm_https_monitor to Server 2.
a. What is the status of each pool member in http_pool after the monitor change?
b. What if any log messages were produced as the result of the change? Check monitor
statistics, too.
c. If the change in pool member status was not immediate, what explains this behavior?
10. Reset pool statistics and refresh your connection to http_vs again several times. How are
connections load balanced now?
11. Change the Availability Requirement for monitors on pool http_pool to At Least1.
a. How did the pool members status change?
b. Examine each pool members configuration detail. Which monitors are reporting
successful test results and which are not?
c. What log messages were produced and what do monitor statistics show now?
Restore original monitor settings
12. Change the Receive String on configltm_https_monitor so that it once again produces correct
test results for all pool members.
13. Change the Availability Requirement for monitors on pool http_pool back to All.
14. Confirm that all pool members in http_pool are available again.
Expected results
When both monitors are properly configured with Receive String set to Server [1-3], and Availability
Requirement is set to All, the status of http_pool is available, and the status of all pool members is
available. Traffic is load balanced across all pool members. Log messages show the members being
marked up.

Chapter 5 - Monitoring Application Health 5-25
When the Receive String on one of the monitors is set to Server 2, the monitor test will fail for all pool
members except 172.16.20.2:80. Since Availability Requirement is set to All, and not all of the monitor
tests are successful, the status of pool members 172.16.20.1:80 and 172.16.20.3:80 changes to
unavailable (red diamond) after the failing monitors timeout period (16 seconds), and log messages are
produced. Traffic is load balanced only to member 172.16.20.2:80.
When Availability Requirement is set to At Least1, even though one of the monitors is failing on
members 172.16.20.1:80 and 172.16.20.3:80, the other monitor is producing a successful test. After
waiting for the failing monitors timeout period, these members are also marked available since at least
one of the monitor tests is successful.
Test Receive Disabled String

15. On monitor configltm_https_monitor, change the Receive String to Server 2 and the Receive
Disable String to Server 1.
a. What is the status of the pool members in http_pool now?
b. Looking at each pool members detail, how is each monitor impacting the members
availability?
c. What log messages were written? What do monitor statistics indicate?
d. Drive traffic to the pool members through the virtual server and observe load-balancing
behavior using statistics. How is traffic being load balanced?
Clean up
16. Change the settings on configltm_https_monitor so that it is producing a successful test on all
pool members, and there is no Receive Disable String specified. Make sure the status of all pool
members is available (green circle) before continuing.
Expected results
Each member of http_pool now has a different status:

The status of member 172.16.20.1:80 is available but its state is disabled (black circle) by
configltm_https_monitor due to the monitors Receive String and Receive Disable String
settings. The Receive String Server 2 - is not being returned by the service at 172.16.20.1:80,
but the Receive Disable String Server 1 is. Therefore, the monitor disables the pool member.
(Had you left the Receive String as Server [1-3], when the pool member returned the string
Server 1, this would match both the Receive String and the Receive Disable String. In the event
both Receive String and Receive Disable String tests are successful, the Receive String test
prevails and the pool member remains up.) In its disabled state, only existing and persisting
connections will be allowed to this pool member.
The status of member 172.16.20.2:80 is available (green circle) as both monitors are returning
successful test results. Traffic is allowed to this member.
The status of member 172.16.20.3:80 is offline (red diamond) as monitor
configltm_https_monitor is failing and Availability Requirement is set to all. No traffic is
allowed to this pool member.

5-26 Chapter 5 - Monitoring Application Health
Test Manual Resume

17. Change the Receive String on monitor configltm_https_monitor to Server [1-2] and set
Manual Resume to Yes.
a. What is the status of the members in pool http_pool now?
b. What log messages were produced? What do monitor statistics indicate?
18. Change the Receive String on monitor configltm_https_monitor so that it is producing
successful test results for all pool members again.
a. What is the status of the member in pool http_pool now?
b. What log messages were produced? What are they telling you with respect to the action
that needs to be taken? What do monitor statistics indicate?
19. Manually enable pool member 172.16.20.3:80 and view the results again.
Expected results
With the Receive String corrected and Manual Resume set to yes, even though the monitor test for
member 172.16.20.3:80 is successful again, the members status is not yet fully available as it is awaiting
a manual resume operation (black diamond), as indicated by log messages and monitor statistics. When
you manually enable the pool member, its status changes to available (green circle).
Clean Up
20. Set Manual Resume to No on monitor configltm_https_monitor.
21. Remove monitor configltm_https_monitor from pool http_pool.

Chapter 6 - Processing Traffic with Virtual Servers 6-5
Lab 6.1 Test Different Virtual Server Behavior

Lab Objectives
Create a network forwarding virtual server, reject forwarding virtual server, and a host
forwarding virtual server for a specific VLAN
Lab Requirements
Test Virtual Server Order of Precedence

1. From your Windows workstation Command Prompt, check to see if you already have a route to
the 172.16/16 network through your BIG-IP system: route print
Some Windows 7 users may need to Start Search cmd.exe and right-
click and select Run as administrator.
2. If you do not have a route to the 172.16/16 network via your BIG-IP system, add a static one:
route add 172.16.0.0 mask 255.255.0.0 10.10.X.33
Establish baseline behavior
3. Try to open a browser session to 172.16.20.1, 172.16.20.2 or 172.16.20.3. You should not be able
to connect directly to these servers, as there is no listener on your BIG-IP system that can process
the traffic when it is routed there from your client workstation.
Add a network forwarding virtual server
4. Create a network virtual server that will forward traffic destined to the 172.16/16 network, using
the specifications in the table below:
Name Type Destination Address/Mask Service
Port
fwd_vs Forwarding 172.16.0.0/16 *All Ports
(IP)

6-6 Chapter 6 - Processing Traffic with Virtual Servers
5. Open HTTP, HTTPS, and/or SSH sessions to 172.16.20.1, 172.16.20.2, and/or 172.16.20.3. Can
you successfully connect now?
Add a network reject virtual server
6. Create a network reject virtual server that will drop traffic destined to the 172.16/16 network on
port 80, using the specification in the table below:
Name Type Destination Address Service Port
reject_vs Reject 172.16.0.0/16 80
7. Try connecting directly to the HTTP, HTTPS, and SSH services on 172.16.20.1, 172.16.20.2, or
172.16.20.3. Which services can you connect to and why?
Add a host forwarding virtual server
8. Finally, create a host forwarding virtual server that will forward traffic that arrives on VLAN
external destined to 172.16.20.2 on all ports, using the specifications in the table below. What are
your results now?
Name Type Destination Address Service Port VLAN and
Tunnel Traffic
host_vs Forwarding 172.16.20.2 *All Ports Enabled on
(IP) VLAN external
Expected results
With just virtual server fwd_vs, you should be able to connect to all services on all of the 172.16.20.1, .2,
and .3 servers.
After adding reject_vs, you should only be able to connect to the HTTPS and SSH services on those
servers. Attempts to connect to the HTTP service on all the services should fail.
After adding host_vs, you should still be able to access HTTPS and SSH services on all the servers, but
the HTTP service only on 172.16.20.2.
Clean Up
9. Delete all 172.16 virtual servers.

7-12 Chapter 7 - Processing Traffic with SNATs
Lab 7.1 Test SNAT Order of Precedence

Lab Objectives
Test SNAT order of precedence when there are several SNAT configurations that may be eligible
to provide source address translation
Lab Requirements

http_vs (10.10.X.100:80, default pool http_pool)
https_vs (10.10.X.100:443, default pool https_pool)
If you have not already configured a static route on your PC for

172.16.0.0/16 through your BIG-IP system (10.10.X.33), you will need to
add it here for this lab. From the Command prompt on your PC:
route add 172.16.0.0 mask 255.255.0.0 10.10.X.33

Chapter 7 - Processing Traffic with SNATs 7-13
Test SNAT Order of Precedence

In each of the following scenarios, you and your partner will test the specified configuration settings by
connecting to both your virtual servers (http_vs and https_vs), and you will connect to 172.16.20.1
firstly, noting the results in the table below. If you are successfully connected, note the source IP address
used on the server-side connection. If not successfully load balanced, note why. Compare your results to
the Expected Results listed at the end of this lab.
SNAT Auto Map SNAT with

Baseline No All Addresses
on https_vs Origin Network
SNAT (Test 1) SNAT (Test 4)
(Test 2) Range (Test 3)
http_vs
Me https_vs
172.16.20.1
http_vs
Partner
https_vs
Test 1: Establish baseline behavior with no SNAT
1. Remove any Source Address Translation for virtual servers http_vs and https_vs.
2. Test access to http_vs and https_vs for both you and your partner, to 172.16.20.1 for you, and
fill out the Test 1 column in the results table above.
Test 2: Configure SNAT auto map on https_vs
3. On virtual server https_vs, set Source Address Translation to Auto Map.

4. Test again, and fill out the Test 2 column in the results table.
Test 3: Configure a SNAT for a range of origin IP addresses
5. Navigate to Local Traffic Address Translation SNAT Pool List and create a new SNAT
pool using the specifications in the table below:
Name Member List
snat_pool 10.10.X.150
172.16.X.150

6. Navigate to Local Traffic Address Translation SNAT List and create a SNAT listener
using the specifications in the table below:
Name Translation Origin Address List
snat_10.10.X snat_pool Address List 10.10.X.0/24
7. Test, and fill out the Test 3 column in the results table.
Test 4: Configure an all addresses SNAT
8. Create a second SNAT listener using the specifications in the table below:
Name Translation Origin
everyone_snat 172.16.X.200 All Addresses
9. Test and fill out the Test 4 column in the results table.
See Expected Results on the next page

Expected Results
SNAT Auto Map SNAT with

Baseline No All Addresses
on https_vs Origin Network
SNAT (Test 1) SNAT (Test 4)
(Test 2) Range (Test 3)
http_vs 10.10.X.30 10.10.X.30 172.16.X.150 172.16.X.150
Me https_vs 10.10.X.30 172.16.X.33 172.16.X.33 172.16.X.33
Fail; no listener Fail; no listener

172.16.20.1 (SNAT or VS) (SNAT or VS)
172.16.X.150 172.16.X.150
Fail; no route back Fail; no route back Fail; no route back

http_vs to my BIG-IP to my BIG-IP to my BIG-IP
172.16.X.200
Partner
Fail; no route back
https_vs to my BIG-IP
172.16.X.33 172.16.X.33 172.16.X.33
Source address 172.16.X.33 is provided by the SNAT Auto Map setting configured on virtual
server https_vs
Source address 172.16.X.150 is provided by the SNAT listener snat_10.10.X
Source address 172.16.X.200 is provided by the all addresses SNAT, everyone_snat
Continue with Lab 7.2: Restrict SNAT Scope

Lab 7.2 Restrict SNAT Scope

Lab Objectives
Restrict the effect of SNAT listeners by enabling and disabling on various VLANs
Restrict the effect of SNATs by disallowing them on particular pools
Lab Requirements

https_vs (10.10.X.100:443, default pool https_pool)
snat_10.10.X configured with origin addresses in the 172.16/16 network and translation
addresses in SNAT pool snat_pool
everyone_snat configured with all origin addresses and one translation address, 172.16.X.200.
Restrict SNAT Listeners on VLANs

Use the table below to fill in your test results during this lab, as you did in the previous lab.
Baseline SNATs SNATs disabled SNATs enabled Disallow SNAT

enabled on all on VLAN on VLAN on https_pool
VLANs external (Test 1) external (Test 2) (Test 3)
http_vs 172.16.X.150
Me https_vs 172.16.X.33
172.16.20.1 172.16.X.150
http_vs 172.16.X.200
Partner
https_vs 172.16.X.33

Confirm baseline behavior
1. Confirm the baseline behavior shown in the results table above. This is the same behavior you
should have seen upon completion of the previous lab, with Auto Map on https_vs, and the two
SNAT listeners snat_10.10.X and everyone_snat enabled on all VLANs. You and your partner
should be able access the two virtual servers, and you should be able to access 172.16.20.1.
Disable SNAT listeners on VLAN external and test
2. Disable both SNAT listeners - everyone_snat and snat_10.10.X - on VLAN external.

3. Test access to http_vs and https_vs for both you and your partner, to 172.16.20.1 for you, and
fill out the Test 1 column in the results table on the previous page.
Enable SNAT listeners on VLAN external only and test
4. Enable both SNATs - everyone_snat and snat_10.10.X - on VLAN external only, and test
again, filling out the Test 2 column in the results table.
Restrict SNATs at the Pool Level

5. On the Advanced configuration view for pool https_pool, change the Allow SNAT setting to
No, to make this pool ineligible for SNATed connections.
6. Test again, and fill out the Test 3 column in the results table.
Clean Up
7. Delete both SNATs and remove any source address translation settings from your virtual servers.
8. Allow SNAT on pool https_pool again.
See Expected Results on the next page

Expected Results
Baseline SNATs SNATs disabled SNATs enabled Disallow SNAT

enabled on all on VLAN on VLAN on https_pool
VLANs external (Test 1) external (Test 2) (Test 3)
http_vs 172.16.X.150 10.10.X.30 172.16.X.150 172.16.X.150
Me https_vs 172.16.X.33 172.16.X.33 172.16.X.33 10.10.X.30
Fail; no listener
172.16.20.1 172.16.X.150
(SNAT or VS)
172.16.X.150 172.16.X.150
Fail; no route back

http_vs 172.16.X.200
to my BIG-IP
172.16.X.200 172.16.X.200
Partner
Fail; no route back
https_vs 172.16.X.33 172.16.X.33 172.16.X.33 to my BIG-IP since
SNAT not allowed
Source address 172.16.X.33 is provided by the SNAT Auto Map setting configured on virtual
server https_vs
Source address 172.16.X.150 is provided by the SNAT listener snat_10.10.X
Source address 172.16.X.200 is provided by the all addresses SNAT, everyone_snat

Lab 7.3 Solve a Routing Issue with SNAT Pool

Lab Objectives
Use a SNAT pool to solve a routing issue where clients and servers are on the same subnet
Lab Requirements
Solve a Routing Issue with Load Balancing Clients and

Servers on the Same Subnet
1. Test browser connectivity directly to the web services at http://10.10.20.1, http://10.10.20.2 and
http://10.10.20.3. You should be able to connect to all three services without issue, as the traffic
is not being proxied by your BIG-IP system. The page should look similar to this:

Load balance traffic to the web services through your BIG-IP system
2. Create a new virtual server at 10.10.X.102:80 that load balances to the pool members at
10.10.20.1:80, 10.10.20.2:80, and 10.10.20.3:80.
3. Test connectivity to your virtual server. Are you able to successfully connect? Why not?
4. View local traffic statistics to see what, if any, traffic is going into and out of both the virtual
server and the pool members.
5. Correct the routing issue by enabling source address translation. Choose from the following:
a. All addresses SNAT
b. SNAT for a network range of origin addresses
c. SNAT for a particular origin IP address
d. SNAT within the virtual server
6. Were you able to successfully connect after enabling source address translation? What is the
client address as seen by the pool member?
Clean Up
7. Delete the configuration objects you created in this lab.
Expected Results
After setting up your BIG-IP system to load balance traffic to the web services through a virtual server,
your connection to the virtual server failed, due to the response being sent directly from the pool members
back to the client at Layer 2, bypassing your BIG-IP system. By adding some form of source address
translation, the response can be forced back through your BIG-IP system for address translation to be
undone. The easiest SNAT option is to configure source address translation within the virtual server,
either using Auto Map or a SNAT pool. The other SNAT options will also work, but they have the
potential to apply to any traffic traversing the BIG-IP system, not just the traffic that is load balancing the
web services through the virtual server.

Chapter 8 - Configuring High Availability 8-9
Lab 8.1 - Configure an Active/Standby Pair

Lab Objectives
Setup a redundant pair of BIG-IP systems

Perform initial synchronization (ConfigSync)
Identify which device is in active mode and which is in standby mode
Change modes from active to standby
Lab Overview
In this lab, students will work in pairs to configure their BIG-IP systems as part of a device group. For the
first section of this lab, we will refer to one of the BIG-IP systems as BIGIP-A and the other BIG-IP
system as BIGIP-B. Partner up and agree on which system is BIGIP-A and BIGIP-B. Substitute your
station number with A or B in the lab instructions.
Figure 4: Lab systems

8-10 Chapter 8 - Configuring High Availability
On Both BIGIP-A and BIGIP-B
Backup your systems and reset to default configuration
Before changes are made to either system, backups should be created. Navigate to System
Archives and create a ucs archive named trainX_pre_ha.
Restore trainX_base.ucs on both systems.
For the purpose of this lab, change your admin account password to admin.
Review ConfigSync, Failover and Mirroring settings
On the Main tab, navigate to Device Management Devices. Click the name of your device.
From the Device Connectivity menu, choose ConfigSync.
Ensure that ConfigSync is configured to use 172.16.X.31, the non-floating self IP for VLAN
internal.
Confirm that the Failover Unicast Configuration and Failover Multicast Configuration
options are using the default settings, as shown below.
Device Management Devices <device_name> Device Connectivity Failover
Network
Failover Unicast Configuration section
172.16.X.31 | 1026 | internal
Local Address | Port | VLAN
192.168.X.31 | 1026 | Management Address
Failover Multicast Configuration section
Use Failover Multicast Address Unchecked (Disabled)
Ensure that the default primary and secondary local mirror address settings are being used for
Mirroring Configuration.
Device Management Devices <device_name> Device Connectivity Mirroring
Mirroring Configuration section

Primary Local Mirror Address 172.16.X.31 (internal)
Secondary Local Mirror Address None
Review initial configuration
Examine the information displayed in the upper left-hand corner of the Configuration utility
screen.
Is your BIG-IP system available?
What is its current ConfigSync state?

Go to Network Self IPs. Examine your device self IP addresses.

What traffic groups do they belong to? Why?
Navigate to Device Management Traffic Groups traffic-group-1. Click the Failover
Objects tab.
What failover objects does this traffic group contain?
On BIGIP-A
Establish device trust
Navigate to Device Management Overview. There should be one device group currently
available.
What type of device group is it? (Hint: check the Device Group Type column).
What devices are listed as members of that device group?
Configure device trust using the information in the following table.
Device Management Device Trust Peer List, then click the Add button
Remote Device Credentials

192.168.B.31 where B is the station number
Device IP Address
of your partners BIG-IP system
Administrator Username admin
Administrator Password admin
When complete, click Retrieve Device Information
On the next screen, verify that the name and certificate of the remote device are correct.
Click Finished to complete the device trust process.

Since both devices are now members of a trust domain, you should see the name of your partners
BIG-IP system listed in the Peer List tab.
Examine the ConfigSync state of your BIG-IP devices. Has it changed? Why?
On BIGIP-A
Create a Sync-Failover device group
Navigate to Device Management Device Groups. Click the Create button.

Name your device group DG_AB_failover, substituting your station number for A and your
partners station number for B (for example: DG_89_failover).
In the Group Type field, select Sync-Failover.
In the Configuration section, the Available column shows any devices that are members of your
device's local trust domain but are not currently members of a Sync-Failover device group. Select
the host names of both your and your partners BIG-IP systems and use the arrow icon to move
both to the Includes list.
Select the Network Failover checkbox, to indicate that we want device group members to handle
failover communications over the network. Leave the other checkboxes unselected.
Click Finished.

Navigate to Device Management Devices. You should see both BIG-IP systems listed in the
device list.
What is the ConfigSync state of your BIG-IP devices now?
On BIGIP-B
Perform initial device group synchronization
Navigate to Device Management Overview. Note that now there are two device groups
available. In the Device Groups section, ensure that the Sync-Failover device group is selected.
In the Devices section, click on the entry for your device to select it. The screen should expand to
show sync options.
Ensure that the Sync Device to Group option is selected, then click the Sync button.
Wait for the synchronization operation to complete (it should only take a few seconds) and then
verify that the Sync Summary area now shows the message All devices in the device group are
in sync.
Review configuration changes after initial synchronization
What is the status of your BIG-IP devices now?

Navigate to Device Management Traffic Groups traffic-group-1. Click the Failover
Objects tab and look at its contents.
Does the traffic group still contain the same floating self-IP addresses that you identified
at the beginning of this lab?
Examine each devices self IP addresses.
Do both BIG-IP systems still have their static and floating self IP addresses? Why?

When reviewing the initial configuration, both BIG-IP systems have a ConfigSync state of Standalone,
indicating that the local trust domain currently contains one member only, which is the local device. The
status legend on both devices is ONLINE (ACTIVE). When examining the self-IP addresses, you will
notice that there are two default traffic groups in both BIG-IP systems: traffic-group-1 (floating traffic
group), which currently contains the BIG-IPs floating self IP addresses; and another traffic group
named traffic-group-local-only (non-floating traffic group) which contains the devices static self IP
addresses.
The only device group available before establishing device trust is device_trust_group, and your BIG-IP
system should be the only member of that device group.
Once device trust is established, both devices are listed as members of device_trust_group. The
ConfigSync state for both BIG-IP systems is now In Sync, indicating that all devices in the device group
are synchronized.
The Sync-Failover device group you created includes one BIG-IP system operating in Active mode
(BIGIP-B) and one BIG-IP system operating in Standby mode (BIGIP-A). Before synchronizing the
configuration for the first time, an Awaiting Initial Sync status message is displayed in both BIG-IP
systems, informing you that the devices recently added to the device group are awaiting to be
synchronized.
After synchronizing configuration data in the device group, the ConfigSync state of both devices is In
Sync, indicating that all BIG-IP systems in the device group contain the current configuration. Since the
BIG-IP system synchronizes floating self IP addresses only, and the BIG-IP system that is active at the
time the initial synchronization is performed is the one that hosts the floating Self IP addresses, BIGIP-B
still has its original floating Self IPs, but BIGIP-A floating Self IP addresses are now the same as BIGIP-
B. traffic-group-1 now contains the floating self IP addresses for BIGIP-B only.
If synchronization fails, make sure the system times on both Active and Standby BIG-IPs are within one
minute. Both systems must be in the same time zone. If needed, set the time by running the command
date MMDDHHMMYYYY.SS, then try synchronizing again.
In the following sections, we will refer to each device as Active and

Standby instead of BIGIP-A and BIGIP-B
Create Traffic Objects and Synchronize Configuration

On the active BIG-IP, create a new pool with the following settings:
Name Load Balancing Method Members Port
ssh_pool Round Robin 172.16.20.1 22
172.16.20.2 22
172.16.20.3 22
Sync the configuration to the device group.
On the standby BIG-IP, verify that you can see ssh_pool.

Creating a new virtual server on the standby BIG-IP (where X is the standby systems
workstation number). using the settings below:
Name IP Address Port Resource
ssh_vs 10.10.X.100 22 ssh_pool
On the standby BIG-IP, access the Sync menu by clicking the Changes Pending message to the
right of the F5 logo, and then sync your configuration to the device group
On the active BIG-IP, verify that the synchronization was successful by ensuring that you can see
the ssh_vs virtual server.
Force Active Device to Standby

On both BIG-IP systems, navigate to Device Management Traffic Groups. In the Failover
Status section, note the status of your device.
On the active device, click the traffic-group-1 link.
Review the information in the General Properties section, especially the Current Device and
Next Active Device settings.
Click the Failover Objects tab and examine its contents. What kind of failover objects are part of
traffic-group-1?
Do you see any additional failover objects in addition to the self-IP addresses we
identified previously?
Back on the Properties tab, click the Force to Standby button. On the pop-up window that
appears, click the OK button to confirm the Force this Traffic Group to standby request.
As there is only one Traffic Group in your Device Group, only one of the
two BIG-IP systems will ever be Active at a time the other will be
Standby since it is not processing any traffic.
The BIG-IP systems should switch from active to standby and standby to active. Navigate to
Device Management Overview and review the Sync Summary.
Click Device Management Traffic Groups and review the Failover Status.
Open an SSH session to the Active BIG-IP system and run the following command:
tmsh run /sys failover standby
On the SSH session, press Enter on your keyboard a few times and notice the command line
prompt changing from Active to Standby.
Test access to virtual server
From both your and your partners workstations, open an SSH session to ssh_vs, and use
student/student as login credentials. Are both BIG-IP systems able to access ssh_vs? Why or
why not? Discuss with your partner.

Assign Auto Map to ssh_vs, then sync the configuration to the device group. Are both BIGIP
systems able to access ssh_vs now?
Expected results
When examining the traffic group configuration, the active BIG-IP system should be listed in the Current
Device field. The Standby device should be listed as Next Active Device, indicating that that device will
accept the traffic group if a failover of that traffic group should occur.
In addition to the floating self IPs, traffic-group-1 now also has a virtual address listed, corresponding to
the ssh_vs virtual server.
You should have success opening an SSH session to ssh_vs from both workstations after enabling Auto
Map, which causes the back end servers to send their response back to the BIG-IP system that processed
the original client request.

Lab 8.2 Create a Second Traffic Group

Lab Objectives
Create a new traffic group with its own failover objects including self IP and virtual address
Manage traffic groups and the devices they are active on, resolving any routing issues that arise
Test with Two Traffic Groups

In this next series of steps, you will create a second traffic group and new configuration objects, and put
those objects into the new traffic group, effectively creating an HA pair with two traffic groups. Your
systems may change their active or standby designation as you progress.
Create a second floating traffic group and self IP
1. On one of the BIG-IP systems, create a new Traffic Group using the specifications below:
Device Management Traffic Groups Create

Name traffic-group-2
a. What is the status of each BIG-IP system now?

b. Which BIG-IP is active for traffic-group-2?
c. Which BIG-IP is active for traffic-group-1?
2. On the same BIG-IP system as step 1, navigate to Network Self IPs, create a new floating self
IP on VLAN internal (172.16/16 network) and assign it to traffic-group-2. To avoid conflicts in
the classroom, your best option is to use the same IP address as the floating self IP that was
eliminated when you performed the initial ConfigSync. For example, if you synchronized from
BIGIP4 to BIGIP3, and lost the floating self IP at 172.16.3.33, use this address when creating the
new floating self IP.
3. Synchronize the new configuration to the other BIG-IP system.
Create a new virtual server and pool
4. On one of the BIG-IP systems, create a new virtual server named http2_vs at 10.10.?.101:80,
where ? (the third octet) is the same as either one of your station numbers. The virtual server
should load balance to a new pool that contains at least one pool member (or more) in the
172.16.20.1:80 to 172.16.20.5:80 range.

5. View the virtual address for the virtual server you just created and change its Traffic Group to
traffic-group-2. (Local Traffic Virtual Servers : Virtual Address List)
6. Synchronize the new configuration to the other BIG-IP system.
Test the new configuration
7. From both you and your partners workstations, open browser sessions to your new virtual server
http2_vs. Are you both able to connect properly? Resolve any routing issues you may encounter.
a. What is the status of each BIG-IP system now?
b. Which BIG-IP is active for traffic-group-2?
c. Which BIG-IP is active for traffic-group-1?
8. At Device Management Traffic Groups, experiment with forcing the traffic groups to standby
and confirm that you can still access both ssh_vs and http2_vs from both of your workstations.
9. Use the TMSH command below to show the current failover status of both systems:
tmsh show cm failover-status
10. From the active BIG-IP system, experiment with failing over a specific traffic group and with
failing over all traffic groups on the device. For example:
tmsh run /sys failover standby traffic-group <traffic-group-name>
tmsh run /sys failover standby
Review MAC addresses behavior during failover
11. From your client workstations, ping the virtual address of http2_vs.
12. View the ARP table and note the MAC address associated with the virtual address. (Hint: use the
command arp a.)
13. Force traffic-group-2 to standby and view your ARP table again.
What is the MAC address for the virtual address now? Why?
Configure and test MAC masquerading
14. On one of the BIG-IP systems, navigate to Device Management Traffic Groups traffic-
group-2.
15. Enter the following MAC address in the MAC Masquerade Address field: 02:00:00:00:00:XX,
where XX is your station number, then click Update.
16. Sync your configuration to the device group.
17. View the ARP table.
What is the MAC address associated with http2_vs now?
18. Force traffic-group-2 to standby and view the ARP table again.
Is the MAC address the same as before the failover?

Expected results
Once MAC Masquerade is configured, the MAC address for http2_vs should remain the same after
traffic-group-2 fails over from one BIG-IP device to the other, as a result of the MAC masquerade address
floating to the newly-active device along with the traffic group.

Chapter 9 - Configuring High Availability Part 2 9-5
Lab 9.1 Configure VLAN Failsafe

Lab Objectives
Configure the VLAN Failsafe trigger

Chose the lab steps that correspond to your classroom setup:
Option A: BIG-IP VE
Option B: BIG-IP Hardware

9-6 Chapter 9 - Configuring High Availability Part 2
Option A: BIG-IP VE Steps
Enabling VLAN failsafe
1. On one BIG-IP system only, create an additional VLAN, called null_vlan.
Network VLANs : VLAN List and click Create

Name null_vlan
Configuration: Advanced
Fail-safe Checked
Fail-safe Timeout 15
Action Failover
2. Click OK to the prompt, The VLAN has no interface, do you want to continue?
3. This will take about 2 minutes to complete. At the BIG-IP CLI prompt you can watch the logfile
with: tail f /var/log/ltm
4. Watch both BIG-IP systems to view when the status change occurs when the active system fails
over, the standby system will go active almost immediately.
a. On the GUI, refresh the page repeatedly. (The status should change automatically even
without a page refresh.)
b. On the command line, press in the Enter Key repeatedly and watch for the prompt to
change.
Clean Up
5. Delete null_vlan from the BIG-IP system on which it was created before moving on to the next
lab.

Option B: BIG-IP Hardware Steps
Enabling VLAN failsafe
1. From https://192.168.X.31, navigate to Network VLANs.

2. Click external, select Advanced and configure the following values as parameters:
Failsafe Timeout Action
Check box 30 seconds common.ha.failover
3. When complete, click Finished.

4. Configure the partner system as well; this setting is not synchronized.
5. On the active system, disconnect the Ethernet cable associated with the external VLAN.
6. Watch both systems to view when the state change occurs. When the active system fails over, the
standby system will go active almost immediately.
a. At the BIG-IP CLI prompt you can watch the logfile with:
b. tail f /var/log/ltm
c. Configuration Utility: Refresh the page repeatedly.
d. Command Line: press in the Enter Key repeatedly.
7. Physical Box: View the STATUS light (Green Active / Amber Standby).
8. Reconnect all Ethernet Cables.
Clean Up
9. Remove VLAN Failsafe settings on both systems before next lab.

Lab 9.2 Configure Connection Mirroring

Lab Objectives
Configure connection mirroring

Force all the traffic groups that are active on one BIG-IP device to standby mode
Lab Requirements

ssh_vs (10.10.B.100:80, default pool ssh_pool)
Test Behavior Prior to Configuring Connection Mirroring

1. Verify traffic-group-1 contains failover object 10.10.B.100.
2. Open an SSH session to ssh_vs and login as student / student.
3. Test your connection by typing who <enter> or similar command.
4. Navigate to Device Management Devices and select the BIG-IP device that is active for this
traffic group. Click Force to Standby.
5. Notice that the SSH connection has been lost. (You may need to press the <Enter> key in order
for your SSH software to recognize that the connection was terminated.)
Configure Connection Mirroring and Test Behavior
Configure connection mirroring and synchronize the configuration
6. On one of the BIG-IP systems, navigate to Local Traffic Virtual Servers and select ssh_vs,
the virtual server that corresponds to 10.10.B.100:22.
7. Using the Advanced configuration option, enable the Connection Mirroring setting and save
your changes.
8. Synchronize the changes to the device group.
Establish SSH connection again and failover again
9. Open a new SSH session to 10.10.B.100:22 and log in again.

10. Test the connection by entering a command such as who.
11. Force the BIG-IP device that is active for traffic-group-1 to standby.

12. Test the connection to 10.10.B.100:22 again. Note that the connection was maintained.
Continue with Lab 9.3: Configure Persistence Mirroring

Lab 9.3 - Configure Persistence Mirroring

Lab Objectives
Activate persistence mirroring for a virtual server where source address persistence is enabled
View persistence records to verify persistence mirroring is taking effect
Lab Requirements
Test Behavior Prior to Configuring Persistence Mirroring
Configure persistence and establish an HTTPS session
1. On one of the BIG-IP systems, create the traffic objects specified in the table below:
Persistence Parent
Profile Type Name Type Profile Custom Settings
Timeout: 30
Source seconds
Persistence configltm_src_persist Address source_addr
Affinity Prefix length: IPv4
24
Load
Name Balancing Members Port
Method
172.16.20.1 443
Round
https_pool 172.16.20.2 443
Robin
172.16.20.3 443
Default Default Persistent

Name Destination Port Other
Pool Profiles
https_vs 10.10.B.100 443 https_pool configltm_src_persist Auto Map
2. Synchronize changes to the device group.

3. Open a browser session to https://10.10.B.100.
4. Ensure your session is persisting by hitting Ctrl-F5 several times.

View persistence records
5. View persistence records on both BIG-IP systems using the TMSH command below:
tmsh show ltm persistence persist-records
You should see a persistence record on the BIG-IP system that is active for the traffic group containing
10.10.B.100, but not on the BIG-IP system that is standby for that same traffic group.
6. Wait 30 seconds and view the persistence records on each BIG-IP system again. What happened
to the persistence record?
7. Refresh the https://10.10.B.100 browser session and review the persistence records again.
Perform device failover
8. Force the BIG-IP device that is active for all traffic groups to standby.
9. Refresh the session to https://10.10.B.100. While there is some chance the same pool member
may be chosen, it is not due to persistence. If it does seem to persist to the same pool member,
failover again and test.
Configure Persistence Mirroring and Test Behavior
Configure persistence mirroring and synchronize the configuration
10. On either BIG-IP systems, update the persistence profile to enable the Mirror Persistence
setting. Navigate to Local Traffic Profiles: Persistence and select configltm_src_persist.
Check the Custom box and then the box adjacent to Mirror Persistence.
11. Click Update.
12. Synchronize the configuration changes to the device group.
13. Make sure to check that the Mirror Persistence option was set on the other system for the
configltm_src_persist profile.
Re-establish the https session, failover and retest
14. Open a browser session to https://10.10.B.100 and refresh your connection several times.
15. View persistence records.
16. Force the BIG-IP device that is active for all traffic groups to standby.
17. Refresh the browser session to https://10.10.B.100. Notice that the https session persists to the
same server.
18. View the persistence records on both systems.

Expected results
Now that Persistence Mirroring is enabled, you should see a persistence record on both the Active and
Standby systems. You may have to adjust the timeout value.

Lab 9.4 - Configure N+1 Availability

Lab Objectives
Add a third member to an existing device group and test failover capabilities
Lab Overview
Member of the previous Sync-Failover pair will join as 3rd member of Sync-Failover group and will
become an Active Active Standby Mode. Watch the Traffic Group float to another member of the
Device Group when a traffic group is failed over.
Reset HA settings on BIGIP-C
1. On BIGIP-C, restore the configuration from trainX_base.ucs.

2. If you have not done so, change the admin password to admin.
On BIGIP-A, expand the device trust to include BIGIP-C
3. On BIGIP-A, navigate to Device Management Device Trust.

4. Click the Peer List tab, then click the Add button to add a new device to the trust.
5. Enter the Management IP Address of BIGIP-C (192.168.C.31), along with the appropriate login
credentials.
6. Click Retrieve Device Information.
7. Confirm new device trust by clicking Finished.
8. Wait a minute and stations should see systems BIGIP-A, BIGIP-B and BIGIP-C under the Device
Management Devices tab.
On BIGIP-A, add BIGIP-C to the device group
9. On BIGIP-A select the Device Management Device Groups tab, and click the link for the
DG_AB_failover Group.
10. From the Members section of Configuration, select bigipC.f5trn.com and click << to add to
Include list.
11. Click Update.
12. Wait a minute, and then from all partners verify that DG_AB_failover contains all three
members: BIGIP-A, BIGIP-B and BIGIP-C.

Synchronizing the configuration from BIGIP-A
Synchronization should always be from the system with the desired

configuration to the other systems. In this case, we wish to push the
configuration from BIGIP-A to BIGIP-B and BIGIP-C.
13. Verify that the configuration between new and old partners is different by checking Virtual
Servers on each system.
14. Next, from BIGIP-A, click Device Management Overview.
15. Select BIGIP-A and click the radio button Sync Device to Group. Click Sync.
16. If BIGIP-C gets logged off, log back in.
17. Wait a minute, then verify the configuration on all BIG-IPs in the device group match.
Drive client traffic and force to standby
18. Drive traffic to the virtual servers from either BIGIP-A, BIGIP-B, or BIGIP-C. Check statistics
on the BIG-IP that you are driving traffic to.
19. Practice forcing each traffic group to standby. (Device Management Traffic Groups).
Determine which BIG-IP device is active for each traffic group at any given point in time. Notice
how the status of the device changes in response to whether or not there are any traffic groups
active on that device.
20. Access the command line interface and display the failover score with the command:
tmsh run cm watch-trafficgroup-device. Use Ctrl+C to exit.
21. Issue the command watch tmsh show /cm traffic-group
The display from this command automatically updates every 2 seconds.
22. Practice forcing each Device to standby (Device Management Devices).
23. View each traffic group and determine the next available device for that group. Force the traffic
group to standby and confirm it moved to the specified device.

Lab 9.5 Configure a Sync-Only Device Group

Lab Objectives
Create a Sync-Only Device Group and share contents of a

folder with members of the Sync-Only Device Group
Lab Overview
During this lesson, you will learn how to setup a Sync-Only Device Group. If class size accommodates,
add a Sync-Only Group from a 4th member: BIGIP-D. In this lab you will demonstrate that a device in a
trust domain can be a member of a Sync-Only group and a Sync-Failover group simultaneously.
On BIGIP-D only
1. On BIGIP-D, restore the configuration from trainX_base.ucs.

2. If you have not done so, change your admin password to admin.
On BIGIP-A, expand the device trust to include BIGIP-D
It is important to perform these next steps on BIGIP-A.
3. On BIGIP-A, navigate to Device Management Device Trust.

4. Click the Peer List tab, then click the Add button to add a new device to the trust.
5. Enter the Management IP Address of BIGIP-D (192.168.D.31), along with the appropriate
Administrator Username and Administrator Password.
6. Click Retrieve Device Information.
7. Confirm new device trust by clicking Finished.
8. Wait a minute and stations should see systems BIGIP-A, BIGIP-B, BIGIP-C, and BIGIP-D under
Device Management Devices.

On BIGIP-A, set up a sync-only device group
9. On BIGIP-A, navigate to Device Management Device Groups, and click the Create button to
create a new device group.
10. In the General Properties section, set the Name to DG_SyncOnly and for the setting Group
Type select Sync-Only.
11. In the Configuration section, use the << button to move bigipC.f5trn.com and
bigipD.f5trn.com from the Available column to the Includes column.
12. Leave Automatic Sync disabled (unchecked) at the moment.
13. Click Finished to create the Sync-Only device group.
14. On BIGIP-A, B, C, and D, verify that DG_SyncOnly is now configured under Device
Management Device Groups.
15. Notice that:
The Device Management Overview screen on each BIG-IP system displays Sync
Status that is known to the members of the device group and Unknown on the devices
that are not members of the device group.
All four devices are members in the same device trust domain. Therefore each device can
see all the devices groups within that trust. But the status is only known for device
groups for which it is a member as shown below:
Figure 1: Sync Status view from the perspective of a device that is member of the DG_Sync_Only device
group only.
Create a new folder on BIGIP-D
16. Open an SSH session to BIGIP-D and create a folder using the following TMSH command:
tmsh create /sys folder objects traffic-group none device-group DG_SyncOnly
17. Notice that the ConfigSync status indicator next to the F5 logo on BIGIP-C and BIGIP-D indicate
Changes Pending, while the ConfigSync status indicator next to the F5 logo on BIGIP-A and
BIGIP-B show In Sync.

Add objects to folder /common/objects on BIGIP-D
18. On BIGIP-D, create an iRule in the /Common/Objects folder: Navigate to Local Traffic iRules
and click Create. Use the settings in the table below to configure the iRule.
Name Definition
/Common/objects/ir_sync when HTTP_REQUEST {
log local0.
}
19. Click Finished.
Synchronize the device group configuration from BIGIP-D
20. First, verify the configurations are different by viewing the list of iRules on BIGIP-C and
BIGIP-D.
21. Next, sync BIGIP-D to BIGIP-C. On BIGIP-D, click the Device Management Overview.
Select bigipD.f5trn.com in the Devices list. Select Sync Device to Group in the Sync Options
area.
22. Click the Sync button to synchronize the changes. BIGIP-C will get logged off. Login again.
23. Wait a minute, then examine the Network Maps on all the BIG-IP systems (BIGIP-A, BIGIP-B,
BIGIP-C, and BIGIP-D). Are the configurations the same across all the devices?
They should not be. BIGIP-D should have no virtual servers, pools, pool members, or nodes on it.
Verify the sync-only device group configurations
24. Verify that iRule ir_sync was synchronized from BIGIP-D to BIGIP-C, but not to BIGIP-A and
BIGIP-B.
25. Follow the steps below to reset your configuration.

Expected results
The results of this lab are as follows. BIGIP-C and BIGIP-D are in the Sync-Only device group, and
BIGIP-A, BIGIP-B, and BIGIP-C are in the Sync-Failover device group as shown in the graphic below:
Figure 2: Expected results for multiple device groups
Clean Up
IMPORTANT!!! Reset to pre-HA configuration
26. On all BIG-IP systems (BIGIP-A, BIGIP-B, BIGIP-C, and BIGIP-D) restore the configuration
from trainX_pre_ha.ucs to remove all the device group configurations. Wait for the restore to
complete before continuing.
27. Open an SSH session to your BIG-IP and run the following command: bigstart restart


10-34 Chapter 10 - Modifying Traffic Behavior with Profiles
Lab 10.1 Test HTTP Compression Behavior

Lab Objectives
Test various compression options by enabling and disabling compression between the BIG-IP
system and a client with a profile
Lab Requirements
Test HTTP Compression Behavior

Use the table below to fill in your test results during this lab. To view client-side HTTP headers, you can
use your browser Developer Tools Inspect function, Fiddler, or tcpdump. To view server-side HTTP
headers, you can use tcpdump. For example:
tcpdump ni internal vvvs 1024 l A host 10.10.X.30 and port 80
Without Compression With Compression Profile With Compression

Profile (Test 1) (Test 2) Exclude List (Test 3)
Client-Side Server-Side Client-Side Server-Side Client-Side Server-Side
Bits Out
Accept-
Encoding
header
included on
request?
Content-
Encoding
header
included on
response?
Create configuration objects
1. Create a virtual server named compression_vs at destination 10.10.X.104:80 that load balances
to a new pool named compression_pool with one member at 172.16.20.1:80. (This is the only
server that has a copy of the special Compression.HTML page used to test this lab.)

Chapter 10 - Modifying Traffic Behavior with Profiles 10-35
2. Open a browser connection to the virtual server and request Compress.HTML. (Note the URI is
case sensitive): http://10.10.X.104/Compress.HTML
3. View local traffic statistics bits out and HTTP request and response headers on the client-side and
service-side connections, and fill in the Test 1 columns in the results table on the previous page.
Test with default compression profile settings
4. Create an HTTP Compression profile called configltm_compress_profile from parent profile

httpcompression. Take all the default settings, as provided by the parent.
5. Associate configltm_compress_profile with virtual server compression_vs.
6. Test again, and fill in the Test 2 columns in the results table.
Test the effects of a compression exclude list
7. Modify configltm_compress_profile to have a customized URI Compression URI List. Add

/*.HTML to the Exclude List.
8. Test again, and fill in the Test 3 columns in the results table.
Clean Up
9. Remove the HTTP compression profile from the virtual server.
Compare your results with the Expected Results on the next page.

Expected results
Without Compression With Compression Profile With Compression

Profile (Test 1) (Test 2) Exclude List (Test 3)
Client-Side Server-Side Client-Side Server-Side Client-Side Server-Side
Bits Out 30.3K* 30.3K* 37.4K* 121.9K* 121.5K* 121.9K*
Accept-
Encoding
Yes; gzip, Yes; gzip, Yes; gzip, Yes; gzip,
header No No
included on deflate deflate deflate deflate
request?
Content-
Encoding
header Yes; gzip Yes, gzip Yes, gzip No No No
included on
response?
* Your Bits Out may vary slightly, depending on the browser you use. In general, when compressed, the
payload is between 30 and 40K. When uncompressed, the payload is about 120-140K.
You may also see variations in the Accept-Encoding header, depending on the browser you use. For
example, if using Chrome, you may see a third encoding method sdch.
You can control the preferred method the BIG-IP system uses to compress the response to the client on
the HTTP compression profiles Preferred Method setting. BIG-IP supports both gzip and deflate
compression methods, and the default preferred method is gzip.
Continue with Lab 10.2: Test Web Acceleration Behavior

Lab 10.2 Test Web Acceleration Behavior

Lab Objectives
Accelerate web application delivery by caching web objects in BIG-IP RAM cache
Lab Requirements

http_vs (10.10.X.100:80)
http_pool (172.16.20.1:80, 172.16.20.2:80, 172.16.20.3:80)
Accelerate Web Application Delivery with RAM Cache
1. If you have not already done so, remove any Layer 7 profiles from http_vs.
2. Reset local traffic statistics for virtual server http_vs and its associated pool.
3. Empty your browser cache, then open a new browser session to virtual server http_vs and refresh
the page several times.
a. What is the total number of connections on the client-side? On the server side?
b. Are any connections still open on either client-side or server-side?
4. Use your browsers Developer Tools Inspect feature, Fiddler, or tcpdump to view the HTTP
response headers that are received on the client-side connection.
a. What is specified on the HTTP response Connection header for each page element?
b. Are there any HTTP Age headers present indicating the response was provided from
cache?
Test with web acceleration profile and default caching options
5. Create a Web Acceleration profile called configltm_accelerate_profile from parent profile

webacceleration. Take all the default settings, as provided by the parent.
6. Associate configltm_accelerate_profile with virtual server http_vs.
7. Reset statistics for the virtual server and pool again.

8. On your browser session to the virtual server, refresh the page again several times.
a. What is the total number of connections on the client-side now? Server-side?
b. Are any connections still open on either client-side or server-side?
c. How do these results compare with the baseline behavior you observed?
9. View the HTTP response headers again:
a. What is specified on the HTTP response Connection header for each page element, and
how does this compare with the baseline behavior you observed?
b. Are there any HTTP Age headers present now?
c. What objects appear to have been served from cache?
d. What objects appear to have been served from the pool members?
10. View web acceleration profile statistics from the command line. For example:
tmsh show /ltm profile web-acceleration <profile-name>
a. Are items being served from cache (Hits)?
b. Are some items not being served from cache but are eligible to be served from cache
(Misses (Cacheable))?
11. View the contents of RAM cache from the command line. For example:
tmsh show /ltm profile ramcache <profile-name>
a. Examine the objects that are cached. Does the list correspond to the page elements that
were received with an accompanying HTTP Age header?
b. Select one or more of the objects in the cache and note its Received, Last Sent, and
Expires date/timestamp. You will force these objects to be reloaded from the pool
member later in this lab.
c. What objects are not cached? Why? (Hint: Examine the profiles settings to determine
the criteria for caching.)
Manage cache contents
12. Reset virtual server and pool statistics, and remove the objects from cache that you selected
earlier to force them to be served from the pool member again. For example:
tmsh delete /ltm profile ramcache <profile-name> uri <uri-value>
13. Test again and confirm via statistics, object date/timestamp in cache, and other methods that the
objects were served from the pool members and a new version of the object was placed in cache.
14. Reset virtual server and pool statistics, and delete all the cached objects. For example:
tmsh delete /ltm profile ramcache <profile-name>

15. Refresh your browser session to the virtual server again ONCE:
a. How many client-side connections on this refresh? Server-side connections?
b. What is in RAM cache now?
c. Refresh the browser session to the virtual server ONCE and answer the previous
questions again.
Customize web acceleration profile settings
16. Change the settings on your web acceleration profile, retest, and observe the results. Choose to try
any or all of the following:
a. Change the minimum and/or maximum object sizes to cache all the objects on the page.
b. Exclude files of a particular type from caching. (The page contains .jpg, .gif, .png, .css,
and .js objects. The HTML is served from a .php program.)
c. Reset the minimum and maximum object sizes to the parents settings, and use Include
Override to cache specific objects (by their URI) even if they are too small or too large.
Clean Up
17. Remove the web acceleration profile from the virtual server.
Compare your results with the Expected Results on the next page.

Expected Results
Baseline behavior
With no web acceleration profile configured on the virtual server, all objects are served from the pool
members the virtual server load balances to. There should be approximately the same number of
connections to the virtual server as to the pool (about 12 or 13 for each page refresh), as HTTP keep-
alives are turned off on the actual back end servers. All the Connection headers in the client-side
response should indicate close. Since no objects are served from cache, there are no Age headers present
in the responses either.
Behavior with web acceleration profile assigned (default settings)
With a web acceleration profile configured on the virtual server, the first refresh of the page will serve
objects from the pool members, and all objects except 2 will be cached in the profiles RAM cache on the
BIG-IP system. On subsequent refreshes, you should see a significant reduction in connections to the pool
members, as most of the page objects are then served from cache. For any object served from cache, the
BIG-IP system includes Age and Connection: Keep-Alive headers in the response. (BIG-IP honors the
Connection: Keep-Alive on the clients request.) For any object served from the pool members, the
clients Connection: Keep-Alive request is not honored, as keep-alives are turned off on the back end
servers.
You should see many cache hits when examining web acceleration profile statistics. The only two objects
that are not cached are main.png (its size exceeds the Maximum Object Size setting in the profile) and
showCookie.js (its smaller than the Minimum Object size setting in the profile). As these objects are
served from the pool members (where keep-alives are turned off), their Connection response headers
indicate close.
Continue with Lab 10.3: Test Stream Profile Behavior

Lab 10.3 Test Stream Profile Behavior

Lab Objectives
Use a stream profile to make a single replacement of one string with another in the packet
payload
Lab Requirements

Create and Test a Stream Profile

1. Create a Stream profile using the information in the table below:
Local Traffic Profiles : Other : Stream New Stream Profile

Name configltm_stream_profile
Parent Profile stream
Settings section
Source Server 3
Target Node 333
2. Assign both configltm_stream_profile and the F5-supplied html profile to http_vs. (Hint: Set
the Configuration to Advanced. Apply any other dependent profiles, as indicated by any error
messages.)
3. Open a browser session to http://10.10.X.100 and hard-refresh several times to test the change.
Was the payload successfully modified?

Expected Results
Whenever the HTML is served from the pool member at 172.16.20.3:80, instead of showing Server 3, the
web page shows Node 333 instead. You may have to refresh the page numerous times depending on your
load balancing method.
Clean Up
4. Remove the Stream, HTTP, and HTML profiles from the virtual server.

11-14 Chapter 11 - Selected Topics
Lab 11.1 Restricting Network Access with

Packet Filters
Lab Objectives
Configure packet filters to restrict administrative and application

Lab Requirements
General Filter Guidelines

When you define an IP filter, you can filter traffic in many ways. You can:
Accept or deny traffic to or from a specific address or network address.
Accept or deny traffic to or from a specific port.
Accept or deny traffic from a specific or network address to a port.
In this lab, you will add filters to deny traffic from other client machines.
Test behavior before adding IP filters
Ensure that the Port Lockdown settings for the self IP 10.10.X.33 are set to Allow Custom for
port 443.
Open a browser session to https://10.10.Y.33 where Y is a partner machine.
If it succeeds, then you have access to change the configuration of this BIG-IP system. This is
expected.
Enable packet filters
On your BIG-IP expand the Network section then Packet Filters: General.
Within the Properties section, change Packet Filtering to Enabled and accept defaults for other
options.

Chapter 11 - Selected Topics 11-15
Ensure your PC has access to your BIG-IP system
Create a packet filter using the specifications in the table below:
Network Packet Filters Rules, then click Create
Name me
Order First
Action Accept
Rate Class None (note: only available if licensed)
VLAN/Tunnel *All
Logging Disabled
Filter Expression section
Filter Expression Method Build Expression
Protocols Any
Restrict to any in list 10.10.X.30, then click
Source Hosts and Networks
Add
Destination Hosts and Networks Any
Destination Port Any
Verify that you still have access to your system and your partners system.

Prevent all other traffic
Create another filter using the specifications in the table below:
Name them
Order Last
Action Discard
VLAN/Tunnel *All
Logging Disabled
Protocols Any
Restrict to any in list Enter either: 10.10 or
Source Hosts and Network List
10.10.0.0/16, then click Add
Destination Hosts and Network Any
Verify that your partner has lost access to your system.

Grant access to partner PC
Create another filter using the specifications in the table below:
Name partner
Order Last
Action Accept
VLAN/Tunnel *All
Logging Disabled
Protocols Any
Restrict to any in list 10.10.Y.30, then click
Source Hosts and Network List
Add
Destination Hosts and Network Any
Verify that your partner still does not have access to your system.
Note how filter order can be changed. From the Rules tab, click Change Order and sort the
filters so that me is first, partner second, and them is third. Click Finished.
Verify that your partner now has access to your system, but others in the class do not.
View the filters within /config/bigip.conf via TMSH:
tmsh list /net packet-filter
Note the order parameter.

Log filter events
Navigate to Network Packet Filters Rules.

Select the me filter from the existing rules.
Within the Configuration section, change the logging option from Disabled to Enabled then click
Update.
Open a browser session to https://10.10.X.33.
Open an SSH session to your BIG-IP system and run the following command to view the packet
filter logs:
tail -f /var/log/pktfilter
Do you see any of the packet filter log entries?
Clean up
Disable packet filtering.

Lab 11.2 - SNMP Traps

Lab Objectives
Setup the BIG-IP System to send traps to the SNMP Management console
Lab Requirements
Configure and Test SNMP Traps

While we have no SNMP Management console in the classroom, tcpdump can be used to view SNMP
traffic as it flows from the BIG-IP system to the specified trap destination. Since SNMP uses UDP, there
is no connection process; the data is transmitted on the wire in clear text format.
Configure an SNMP trap destination
Create a SNMP trap destination using the Configuration utility or TMSH.

a. If using the Configuration utility:
System SNMP Traps Destination, then click Create
Record Properties section

Version v1
Public (Note: SNMP community strings
Community
are case sensitive)
Destination 10.10.X.30
Port 162
Network Management
b. If using TMSH:
tmsh modify /sys snmp traps add { ts1 { host 10.10.X.30 version 1
community Public network mgmt} }
followed by this command to view the trap destination settings:
tmsh list /sys snmp

Start tcpdump to capture SNMP trap data
Start tcpdump on your BIG-IP system to capture SNMP data as it flows to the trap destination.
For example:
tcpdump ni external Xs 200 udp and port 162
Trigger an SNMP trap
Trigger an SNMP trap. For example, create or modify a health monitor such that one or more
pool members or nodes are marked down. You can find other options for triggering a trap by
looking at the traps configured in /etc/alertd/alert.conf.
a. Were you able to view trap data with your tcpdump?
b. Assuming you used a monitor to trigger a trap, how long must you wait until the resource
is marked down?
Clean Up
Restore all services so that no traps are triggered.

Lab 11.3 - IPv6 Lab

Lab Objectives
Configure an IPv6 client and access backend servers with IPv4 Pool Members.
Lab Requirements
Configure the IPv6 Address for the Interface Type
If your workstation is already configured for IPv6, please skip to Step 4.

Start a Command Prompt on the Windows client, and type ipconfig.
You should see an IPv4 address and also an IPv6 address beginning with fe80:: If you do not
have IPv6 installed, your instructor will provide instructions to install the IPv6 stack.
Locate your interface with the 10.10.X.30 IPv4 address. Note the number that follows the % of
your interfaces IPv6 address ______.
This represents the interface index and becomes important in the next steps.
In the example below, the %13 represents the interface index 13
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : olympus.F5Net.com
Link-local IPv6 Address . . . . . : fe80::7dfb:6a52:9c57:58e4%13
IPv4 Address. . . . . . . . . . . : 10.10.6.30
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 192.168.62.254
Configure the IPv6 address for that interface:

netsh interface ipv6 add address interface=<interface index number>
address=fc00:a0a:0:X::30/48, where the X represents your station number.
For example station 6 would be:
netsh interface ipv6 add address interface=13
address=fc00:a0a:0:6::30/48
You should get the command prompt after entering this command. You can check the new
address with ipconfig.
Configure BIG-IP LTM Self-IP, Virtual Server, and Test

Create a self IP using the specifications in the table below:
Network Self IPs, then click Create
Name ipv6
fc00:a0a:0:X::31 (where X is your station
IP Address
number)
Netmask ffff:ffff:ffff::
VLAN/Tunnel External
Port Lockdown Allow none
Traffic Group Traffic-group-local-only (non-floating)
Create a virtual server using the specifications in the table below:
Local Traffic Virtual Server : Virtual Server List, then click Create
Name ipv6_vs
fc00:a0a:0:X::100 (where X is your station
Destination Address/Mask
number)
Service Port 80
Default Pool http_pool
In your web browser type in the following and be sure to include the brackets:
http://[fc00:a0a:0:X::100]
What are the results?

Chapter 12 - Deploying Application Services with iApps 12-25
Lab 12.1 Deploy a Simple Website Application

Objectives:
Create a simple website application configuration using an iApp template

Explore the TMOS folder hierarchy using TMSH
Test the effects of Strict Updates on reconfiguring an application services components
Lab Requirements:

12-26 Chapter 12 - Deploying Application Services with iApps
Deploy classroom_website application

1. Deploy a new HTTP application service called classroom_website with the following
characteristics:
iApp Application Services, then click Create
Template Selection section

Name classroom_website
Template f5.http
SSL Encryption section
How should the BIG-IP system
Plaintext to and from both clients and servers
handle SSL traffic?
Virtual Server and Pools section
What IP address do you want
10.10.X.108
to use for the virtual server?
What port do you want to use
80
for the virtual server?
What FQDNs will clients use to
www.classroomwebsiteX.com
access the servers?
Do you want to create a new
Create a new pool
pool or use an existing one?
Node/IP address: 172.16.20.1 Port: 80 click Add
Which web servers should be
Node/IP address: 172.16.20.2 Port: 80 click Add
included in this pool?
Node/IP address: 172.16.20.3 Port: 80
Application Health section
Create a new health monitor or
Create a new health monitor
use an existing one?
What HTTP URI should be sent
/index.php
to the servers?
What is the expected response
Server [1-3]
to the HTTP request?

Examine classroom_website components
2. Review the components that were created when you deployed classroom_website from template
f5.http, and answer the following questions:
a. What are the statuses of the pool members?
b. What is the name and type of the monitor that is checking pool member health?
c. Is the pool member monitor part of the classroom_website application service?
d. What are the statuses of the nodes?
e. Is the monitor part of the classroom_website application service? How can you tell?
f. What profiles were created by the template as the result of you accepting the templates
default settings?
3. Click on the entry for pool classroom_website_pool to navigate directly to its configuration
entry. In the General Properties section, note the name of the associated Application.
4. What load balancing method did the template set for classroom_website_pool?
5. Navigate back to the application service page by clicking the Properties tab for the pool, then
clicking on classroom_website in the General Properties section. Click the Components tab to
view the components of the classroom_website application service again.

At this point, all your pool members should be marked up and available (green circle) by the HTTP
monitor - classroom_website_http_monitor - that was configured by the 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 the default node monitor for the BIG-IP systemicmpwhich you
configured earlier in this class. Although it appears in the classroom_website application services
components view, it is not part of the application service.
The f5.http template created many profiles (in addition to classroom_website_http) that affect the
behavior of the classroom_website_vs virtual server. These include:
classroom_website_source-addr-persistence
classroom_website_cookie-persistence
classroom_website_tcp-wan-optimized
classroom_website_tcp-lan-optimized
classroom_website_oneconnect
classroom_website_optimized-caching
classroom_website_wan-optimized-compression
The template set Least Connections (member) as the load balancing method for the pool
classroom_website_pool.
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.108, and hard refresh (Ctrl+F5) the screen at least once to make sure youre not
pulling elements from your browsers cache. Answer the following questions by examining the
configuration settings for the virtual server, pool, and/or pool members.
a. Which pool member(s) did you load balance to and why?
b. What is the client source IP address, as seen by the back end server, and why? Confirm
your answer by viewing the virtual server configuration settings for
classroom_website_vs.
c. Hard-refresh the browser window at 10.10.X.108 several times. Did you load balance to a
different pool member? Why or why not? Confirm your answer by viewing the virtual
server configuration settings for classroom_website_vs.
d. Is the application showing an X-Forwarded-For header was passed to it? Hypothesize as

to who inserted this header and why.

Since cookie persistence is configured on the 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 expire.
View the Underlying Folder Structure using TMSH

In the next series of lab steps, youll experiment with using partition and path as part of a configuration
objects full name, and with navigating into and out of the TMOS folder hierarchy using TMSH. You are
encouraged to use the TMSH command completion feature to help you choose what command parameters
and object names are available for you to use.
7. Open a PuTTY session to your BIG-IP system, log in, and enter tmsh. What partition/path are
you in? (Fill in the blank below.)
root@(bigipX)...(Active)(_________________)(tmos)#
8. List the pools in this partition/path. (Hint: list /ltm pool) What pool(s) do you see?
9. Navigate to the folder that contains the configuration objects created during deployment of the
classroom_website application service. For example:
(tmos)# cd classroom_website.app
10. What partition/path are you in now? (Fill in the blank below.)
root@(bigipX)...(Active)(______________________________________)(tmos)#
11. List the pools in this partition/path. What pool(s) do you see now?
12. From your current location in the folder hierarchy, see if you can find a way to list all properties
of pool http_pool. (Hint: Specify the full name of this pool, including its partition/path
designation.)
13. Navigate back to just the Common folder: cd /Common
14. From your current location in the folder hierarchy, list all properties of virtual server
classroom_website_vs. (Hint: Remember to specify the full name of this virtual server.)
15. List the application service to view its settings:
list /sys application service classroom_website.app/classroom_website

When the command prompt shows partition/path as just (/Common), the only pools you can list are those
that you created before this lab. The pool created by the application service classroom_website_pool
is not shown.
The command prompt changes to (/Common/classroom_website.app) when you issue the cd
classroom_website.app command. Once in this location in the folder hierarchy, the only pool that is
listed is classroom_website_pool.
Once youve navigated into the classroom_website.app folder, the only way to list all properties of
http_pool (without leaving the folder first) is to use its full name on the list command. For example:
list /ltm pool /Common/http_pool all-properties
Likewise, after navigating back to the /Common folder, the only way to list all properties of virtual server
classroom_website_vs is to use its path name on the list command. (Partition name is not required since
you are already in partition /Common.) For example:
list /ltm virtual classroom_website.app/classroom_website_vs all-properties
Test the Effects of Strict Updates

16. Back on the Configuration utility, ensure Strict Updates is enabled for classroom_website.
iApps Application Services classroom_website, then click Properties
Application Service section: Advanced view

Strict Updates (checked)
When complete, click Update (if Strict Updates was not already checked)
Test effects of strict updates on enable/disable
17. Click the Components tab of the classroom_website application service, and disable
classroom_website_vs. (Check the small box to the left of the classroom_website_vs entry and
then click the Disable button at the bottom of the page.) Once disabled, its state should continue
to show as Available but with a black circle instead of a 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? Why or why not?
Confirm your answer by trying to access the virtual server again.
18. Back on the BIG-IP 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 this? What does this tell you
about your ability to enable/disable objects outside of the application service when strict updates
is enabled?
19. Confirm that the virtual server is now accepting traffic again by refreshing your browser
connection to http://10.10.X.108.

Test effects of strict updates on changing configuration settings
20. Navigate to Local Traffic Pools classroom_website_pool, then click Members, then Add
and attempt to add a fourth pool member at 172.16.20.4:80.
21. Was your attempt to add a fourth pool member successful? Why or why not?
22. Attempt to use TMSH to add a fourth pool member. (Hint: Make sure to either navigate to the
correct folder first to specify the full name of the pool.) For example:
modify /ltm pool classroom_website_pool members add {172.16.20.4:80}
23. Was your attempt to add a fourth pool member via tmsh successful? Why or why not?
24. Disable the Strict Updates setting for classroom_website.
25. Try again to add a fourth pool member (172.16.20.4:80) directly to pool classroom_website_pool
(as you attempted in a previous step).
a. Were you successful this time? Why or why not?
b. What is the new pool members status? Is it being monitored? Confirm your answer by
checking the pool members properties.
c. If the pool member is being monitored, why is its status currently unknown? Wait for the
pool members status to become known. What is its status now and why?
d. Look at the components for classroom_website again. Is 172.16.20.4:80 shown in the list
here?
e. Look at the settings for classroom_website.app again to see if 172.16.20.4:80 shows in
the application services settings for pool members:
list /sys application service classroom_website.app/classroom_website
Test effects of making configuration changes outside of the application service
26. 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).
27. 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. Is the fourth pool member shown here?
b. What do you think will happen if you click the Finished button at this point?
28. Click the Finished button. This will reconfigure the application service using the same settings as
when you initially deployed it. What happened to pool member 172.16.20.4:80?

With Strict Updates enabled, you can change the state of an application services virtual servers, pools,
and pool members (for example enabled, disabled, forced offline) using the Components page of the
application server, the configuration objects page, and/or tmsh. However, you cannot modify the objects
configuration settings, except through the Reconfigure tab of the application service.
With Strict Updates disabled, you can modify an application services components settings using the
Reconfigure feature of iApps, or using the other non-iApp functions of the Configuration utility.
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 it was deleted when you reconfigured classroom_website application service (although its
node entry is still on the BIG-IP system).
F5 recommends that you keep Strict Updates enabled and manage an

application services components using the Reconfigure function. Or
disassociate the application service from any template, manage the
components directly, and never use the Reconfigure function.
Clean-Up
29. Delete the application service classroom_website and notice that all of the components it created
are also removed.
You may stop here, or continue with optional Lab 12.2: Create and Test
a Basic Template

Lab 12.2 Create and Test a Basic Template

(Optional)
Lab Objectives
Build and deploy a quick and easy iApp template that creates a virtual server and a pool with one
pool member
Create a New Template

1. Using the Configuration utility, navigate to iApps Templates, and click the Create button.
2. Name your template WebService.12.2.
Code the presentation section
3. In the Presentation section, enter the following:
Presentation section
section Virtual {
string Address validator "IPAddress" required
string Port validator "PortNumber" required default "80"
}
section Pool {
string Address validator "IPAddress" required
string Port validator "PortNumber" required default "80"
}

Code the implementation section
4. In the Implementation section for WebService.12.2, enter the following code:
Implementation section
tmsh::create "/ltm pool ${tmsh::app_name}_WebPool

members replace-all-with { $::Pool_ _ Address:$::Pool_ _ Port }"
tmsh::create "/ltm virtual ${tmsh::app_name}_WebVS

destination $::Virtual_ _ Address:$::Virtual_ _ Port
pool ${tmsh::app_name}_WebPool"
When complete, click Finish
Deploy an Application Service from the Template
Deploy the application service
5. Create a new application service called Lab12_WebService from template WebService.12.2.

Provide the following responses:
a. For virtual server IP address, specify an invalid IP address
b. For virtual server port, specify an invalid port
c. For pool member IP address, specify an invalid IP address
d. For pool member port, specify an invalid port
6. Finish the application service deployment. You should receive error messages relating to the
validators that are coded on the string elements in the presentation section.
7. Change your responses to the following:
a. For virtual server IP address, specify 10.10.X.109 (where X is your station number)
b. For virtual server port, specify 80
c. For pool member IP address, specify 172.16.20.2
d. For pool member port, specify 80
8. Finish the application service deployment

View the application service using the configuration utility
9. Examine the components that were produced by the implementation section code and answer the
following questions:
a. What objects were created/referenced and what are their names/values?
Virtual Server
Pool
Pool Member
Node
Virtual Address
Profile
b. What is the status of the pool and why?
c. What is the status of the virtual server and why?
d. Click on the virtual server component to view its configuration. What type of virtual
server was created and why?
View the application service and its configuration objects using TMSH
In this next series of lab steps, youll experience navigating the TMOS module and folder hierarchies, and
the way the format of a tmsh command can change depending on where you are within the hierarchies:
10. Using PuTTY, open an SSH (port 22) session to your BIG-IP system, enter the TMOS shell, and
view the application services properties:
(tmos)# list /sys application service Lab12_WebService.app/Lab12_WebService
Expected results
After deployment, the application service should have six (6) configuration objects associated with it.
Two were created explicitly by the tmsh commands coded in the implementation section
Lab12_WebService_WebVS and Lab12_WebService_WebPool. Both were created in the new folder
that was also created called Lab12_WebService.app.
Other configuration objects were also automatically created by the BIG-IP system, including a virtual
address object (10.10.X.109), a pool member object (172.16.20.1:80), and a node object (172.16.20.1).
Notice that these were all created in the folder named /Common rather than in the folder named
Lab12_WebService.app.
If you create a virtual server using TMSH, and dont specify a protocol profile, the default is to create a
Performance (Layer 4) or FastL4, for short virtual server, as indicated by the F5-supplied profile
named /Common/fastL4 that was automatically associated with Lab12_WebService_WebVS.

Test Access to the Virtual Server

11. Open a new browser session to the virtual server at http://10.10.X.109.
12. Were you able to connect and load balance to the pool member?
13. Confirm traffic flow via Statistics Module Statistics Local Traffic. Is the application being
delivered as you expected it to be?
Clean-Up
14. Delete application service Lab12_WebService.

13-26 Chapter 13 - Customizing Application Delivery with iRules and Local Traffic Policies
Lab 13.1 Load Balance, Intelligent SNAT, XFF

Header, and Custom 404 Response
Lab Objectives
Use an iRule to:
Select the load balancing pool based on the clients IP address
Insert an X-Forwarded-For header into the HTTP request before passing to the web server
Send a custom response page when the back end server returns an HTTP 404 status
Use a variable to pass a value that is only available in the client-side context to a server-side event
Lab Requirements
Viewing HTTP Headers Using Your Browser

Throughout this lab, you may want to view the HTTP request headers your browser sends to the BIG-IP
system, and the HTTP response headers send by the BIG-IP system back to your browser. If youre
unfamiliar how to do this, here are some general steps for use with Chrome or Firefox:
Right-click somewhere on the page (for example, in the blue area), and select Inspect Element
(or Inspect). Alternatively you can open your browsers Developer Tools.
In the Inspect Element window, click the Network tab.
Reload the page (Ctrl+F5).
In the resulting list of page elements in the Inspect Element window, scroll to the top of the list
and click on the first entry (the GET for the initial HTML document for the page at 10.10.X.110).
This should display both the HTTP request and response headers that were transmitted on the
initial page request.
You can use the same technique view the request and response headers for the other page
elements.

Chapter 13 - Customizing Application Delivery with iRules and Local Traffic Policies 13-27
Create the Configuration Objects the iRule Will Reference
Create two load balancing pools
1. Create two load balancing pools using the specifications in the table below.
Pool Name Members Load Balancing Method
in_network_http_pool 172.16.20.1:80 Round Robin
172.16.20.2:80
172.16.20.3:80
172.16.20.4:80
out_network_http_pool 172.16.20.5:80 Round Robin
Create a virtual server
2. Create a new virtual server called custom_http_vs with destination IP address and port
10.10.X.110:80. Do not give it a default pool.
Create the iRule and Assign It to the Virtual Server
Create the iRule
This iRule will select the appropriate load balancing pool based on the first three octets of the clients IP
address, effectively load balancing all clients in the 10.10.X.0/24 network to pool
in_network_http_pool, and all other clients to pool out_network_http_pool.
3. Navigate to Local Traffic iRules and create a new iRule called select_pool_irule using the
code in the table below. Use the tab key within the Definition field to maintain indentation.
(Remember to substitute your workstation number where the X is.)
when HTTP_REQUEST {
if { [IP::addr [IP::remote_addr] equals 10.10.X.0/24] } {
log local0. "Load balancing to in_network_http_pool"
pool /Common/in_network_http_pool
} else {
log local0. "Load balancing to out_network_http_pool"
pool /Common/out_network_http_pool
}
}
4. Save the iRule, correcting any syntax errors before moving on to the next step.

Assign the iRule to the virtual server
Before you assign an iRule to a virtual server, configure and assign any
profiles the events within the iRule require in order to function. For
example, in the iRule in this lab, what, if any, associated profiles does the
HTTP_REQUEST event require?
5. Edit the configuration for virtual server custom_http_vs, and on the Resources tab, in the iRules
section, click the Manage button.
6. Assign iRule select_pool_irule to the virtual server by moving its entry from the Available
column to the Enabled column.
7. Click Finished to save the virtual servers configuration.
Test the iRule
Test from your workstation
8. Open an SSH session to your BIG-IP system, and view /var/log/ltm: tail f /var/log/ltm
9. Open a browser window and connect to your virtual server at http://10.10.X.110. You should see
your page contents being delivered from all four pool members in pool in_network_http_pool.
10. Check the log messages that were written to /var/log/ltm. Depending on the browser you used,
you should see somewhere around 14 messages indicating the connections were Load balancing
to in_network_http_pool.
11. Based on what you see in the logs, how many times was your iRules HTTP_REQUEST event
triggered, and, more importantly, why?
Test from a partners workstation
12. Ask another student in class to try to access your virtual server at http://10.10.X.110. Were they
able to connect? If not, why not?
Provide access from partners workstation
13. Adjust the iRule so that the source address is translated to a BIG-IP self IP for those clients who
are not in the 10.10.X/24 network. They should see their page contents delivered from just the
one pool member - 172.16.20.5 - in pool out_network_http_pool.
14. Check the log messages that were written to /var/log/ltm. This time the messages should indicate
the connections were Load balancing to out_network_http_pool.

HTTP_REQUEST profile dependencies
The HTTP_REQUEST event requires an HTTP-type profile on the virtual server before assigning the
iRule to the virtual server. The F5-supplied profile named http is sufficient for our purposes in this lab. In
production, you might prefer to create a custom http profile instead.
How many times was the iRule triggered and why
As HTTP keep-alives are turned off on the back end servers in the classroom, each HTTP request
required to completely load the page generated a separate connection request to the virtual server. There
are about 14 elements on the page, therefore at least 14 connections were required. Some browsers open
additional connections to try to speed delivery of the page contents. Therefore, you may see more than 14
connections.
Partner unable to access your virtual server
The routing tables on the back end server are configured such that the default gateway is the BIG-IP
system that matches the third octet in the responses destination IP address. As such, in order for another
student in the classroom to access a virtual server on your BIG-IP system, you must have some sort of
source address translation configured for that client. Adding a snat automap statement somewhere in the
else code block will do this.
Continue this lab on the next page.

Modify the iRule to Insert an X-Forwarded-For Header for

Selected Clients
In order for other clients to be able to successfully access your virtual server, you added an intelligent
SNAT to that traffic. Although you could enable Insert X-Forwarded-For (for all traffic, not just
selected clients) in the associated HTTP profile, in this next series of labs steps, youll conditionally do
the same thing via an iRule.
15. Modify iRule select_pool_irule and add the code shown in bold below in the else portion of the
if code block that selects the pool and does intelligent SNAT for clients that are not in the
10.10.X/24 network:
when HTTP_REQUEST {
if {

} else {

log local0. "Inserting XFF header for [IP::remote_addr]"
HTTP::header insert X-Forwarded-For [IP::remote_addr]
}
}
16. Save the iRule and resolve any syntax errors that arise before continuing on to the next step.
Test the iRule

17. Have you and your partner connect to your virtual server at http://10.10.X.110 again. You
should not see an X-Forwarded-For (XFF) header but your partner should, similar to below.
18. Confirm the log messages that were written to /var/log/ltm by your iRule.

Modify the iRule to Send a Custom Response Page on

HTTP 404 Status
In this section of the lab, youll create a custom response page to send to the client in the event the server
responds with an HTTP 404 status code. The response page will include the host name and URI that was
not found.
Test HTTP 404 response
19. Try accessing a page called garbage.html through your virtual server at http://10.10.X.110.
a. Were you successful?
b. What HTTP status code was returned to your browser? (Use browser developer tools,
Fiddler, or other similar tools to view the status code.)
Modify the iRule to send a custom response page on a 404 status code
HTTP::uri is available only in the client-side context, and HTTP_RESPONSE is a server-side event.
You will have to save the values of HTTP::host and HTTP::uri to a variable in the HTTP_REQUEST
event, then refer to that variable in the HTTP_RESPONSE event.
20. Modify iRule select_pool_irule as shown in the bold text below:
when HTTP_REQUEST {

HTTP::header insert X-Forwarded-For [IP::remote_addr]
}
set RequestedURL [HTTP::host][HTTP::uri]
}
when HTTP_RESPONSE {
if { [HTTP::status] eq "404" } {
log local0. "HTTP 404 on $RequestedURL"
HTTP::respond 200 content "<html>
<head><title>Apology Page</title></head>
<body>We're sorry, but the page you're looking for
(http://$RequestedURL) is temporarily unavailable. If you feel
you've reached this page in error, please try again.</body>
</html>"
}
}

Test the iRule
21. Try connecting to http://10.10.X.110/garbage.html again.

a. Did your custom response page display properly (including the host name and URI that
was not found)?
b. What was the HTTP response code sent to your browser?
c. Was your log message written properly?
Expected results
Before adding the custom response page, you should have received your browsers standard 404 Not
Found page with a 404 status code.
After adding the custom response page code to your iRule, you should see it displayed instead of the
browsers standard 404 Not Found page. Thats because you change the HTTP response status code from
404 to 200.
The log messages written to /var/log/ltm should look similar to this:
Rule /Common/select_pool_irule <HTTP_REQUEST>: Load balancing to in_network_http_pool
Rule /Common/select_pool_irule <HTTP_RESPONSE>: HTTP 404 on 10.10.4.110/garbage.html
If you are using the Chrome browser, you may also see these log messages:
Rule /Common/select_pool_irule <HTTP_REQUEST>: Load balancing to in_network_http_pool
Rule /Common/select_pool_irule <HTTP_RESPONSE>: HTTP 404 on 10.10.4.110/favicon.ico
Lab Review Questions

1. Since HTTP_REQUEST is a client-side event, whose IP address is in IP::remote_addr? Is there
another iRule command you could have used instead of IP::remote_addr and accomplished the
same thing?
2. The specifications for your iRule had you conditionally insert an X-Forwarded-For header based
on the clients IP address range. If the specifications asked you to unconditionally insert an X-
Forwarded-For HTTP header, which method is preferable iRule or HTTP profile setting?
If you wish to, you may continue with optional Lab 13.2: Remove
Unwanted Headers from HTTP Response via an iRule


Lab 13.2 Remove Unwanted Headers from

HTTP Response via an iRule (Optional)
Lab Objectives
Use an iRule to remove unwanted headers from a response before sending it to the client
Test iRule order of precedence
Lab Requirements

/Common/in_network_http_pool (172.16.20.1-4:80)
/Common/out_network_http_pool (172.16.20.5:80)
/Common/custom_http_vs (10.10.X.110:80, no default pool)
Ability to view HTTP request and response headers on the client, such as with Chromes or
Firefoxs Inspect Element developer tool, or with Fiddler.
Examine Existing Headers

1. Before you build and apply a new iRule, view the HTTP response headers sent to your virtual
server at http://10.10.X.110.
a. What Server header(s) do you see, if any?
b. What X-Powered-By headers do you see, if any?
c. What X-Pad headers do you see, if any?
If no headers are displayed, make sure you reload the page (Ctrl-F5). In the response headers for all page
elements, you should see one Server header similar to this: Server: Apache/2.2.22 (Debian)
In the initial request for the default page HTML, you may see an X-Powered-By header similar to this:
X-Powered-By: PHP/5.4.4-14+deb7u7
In many of the requests for images, such as F5-PNG-Logo.png, you may see an X-Pad header similar to
this: X-Pad: avoid browser bug
These and other similar headers can present security vulnerabilities, since they inform a potential attacker
what sort of system theyre dealing with. They are typically unnecessary, and removing them can make
life a little more difficult for a hacker, as well as make the response payload smaller.

For each element on the page, you should see a log message written to /var/log/ltm similar to this:
Rule /Common/select_pool_irule <HTTP_REQUEST>:Load balancing to in_network_http_pool
If you are using the Chrome browser, you may also see this log message:
Rule /Common/select_pool_irule <HTTP_RESPONSE>:HTTP 404 on 10.10.4.110/favicon.ico
Create an iRule to Remove Unwanted HTTP Headers
Create the iRule
2. Create a new iRule called remove_headers_irule that unconditionally removes any unwanted
HTTP headers from responses that you saw in the previous step. For example:
log local0. "Removing unwanted headers - $RequestedURL"
HTTP::header remove "Server"
HTTP::header remove "X-Powered-By"
HTTP::header remove "X-Pad"
}
Assign the iRule to custom_http_vs and test
3. Assign remove_headers_irule to custom_http_vs (after select_pool_irule) and retest. Do you

still see any Server, X-Powered-By or X-Pad response headers on any page element?
If your iRule is written correctly, the unwanted headers you specified should be being removed from the
response headers. If you still see any of these headers present on any of the elements, check your iRule
code and ensure that you have specified the names of the headers correctly.
For each element on the page, you should see log messages written to /var/log/ltm similar to this:
Rule /Common/select_pool_irule <HTTP_RESPONSE>:Removing unwanted headers-10.10.4.110/
If you are using the Chrome browser, you may also see these log messages:
Rule /Common/select_pool_irule <HTTP_RESPONSE>:HTTP 404 on 10.10.4.110/favicon.ico
Rule /Common/select_pool_irule <HTTP_RESPONSE>:Removing unwanted headers-
10.10.4.110/favicon.ico
0122001:3:Tcl error: /Common/remove_headers_irule <HTTP_RESPONSE>-Operation not
supported (line 1) invoked from within "HTTP::header remove "Server""
The last log message that may be produced when using Chrome is due to remove_headers_irule trying
to remove headers from the response after a response has already been sent by select_pool_irule.

Test Order of Precedence

At this point, both select_pool_rule and remove_headers_rule handle the HTTP_RESPONSE event.
Select_pool_irule appears first in the list of iRules assigned to custom_http_vs; remove_headers_irule
appears second. Neither iRule has assigned a priority to their respective HTTP_RESPONSE events, so
the order of execution on those events is determined by their assignment order. In this next series of steps,
youll experiment with assignment order to see how this may affect traffic processing at runtime when
duplicate events are handled.
1. Open a browser session to http://10.10.X.110/garbage.html. This file does not exist on any of
the servers and will generate a 404 response code from the server to BIG-IP. In the
HTTP_RESPONSE event in select_pool_irule, the code that sends the custom response page
should execute, as should the HTTP_RESPONSE event code in remove_headers_irule that
removes unwanted HTTP headers:
a. Did you get your custom response page? If not, what was the result?
b. What log messages were written to /var/log/ltm? Are these what you expected?
Control event evaluation with assignment order
2. Change the order of the iRules on custom_http_vs:

a. Select custom_http_vs and on the Resources tab, click the Manage button in the iRules
section.
b. Select remove_headers_irule in the Enabled column, and click the Up button to move it
above select_pool_irule in the list.
c. Click Finished to save the new order.
3. Retest access to http://10.10.X.110/garbage.html.
a. Did you get your custom response page?
b. What log messages were written to /var/log/ltm? Are these what you expected?
Control event evaluation with event disable
4. Change the order of the iRules on custom_http_vs so that select_pool_irule is first and
remove_headers_irule is second.

5. Add an event disable command to the HTTP_RESPONSE event in select_pool_irule:

if { [HTTP::status] eq "404" } {
log local0. "HTTP 404 on $RequestedURL"
HTTP::respond 200 content "<html>

</html>"
event disable
}
}
6. Test access to your virtual server again at http://10.10.X.110/garbage.html.

b. What log messages were written to /var/log/ltm?
c. Did the HTTP_RESPONSE event in remove_headers_irule trigger?
Control event evaluation with event priority
7. Remove the event disable command from select_pool_irule, and add a priority parameter to the
when HTTP_RESPONSE event statement. For example:
when HTTP_RESPONSE priority 900 {
8. In iRule remove_headers_irule, add a priority parameter to the when HTTP_RESPONSE

event statement that is lower than the priority in select_pool_irule:
when HTTP_RESPONSE priority 100 {
9. Test access to your virtual server again at http://10.10.X.110/garbage.html.

b. What log messages were written to /var/log/ltm?
c. Which HTTP_RESPONSE event triggered first?

In the baseline behavior, accessing garbage.html produces a logical conflict in your iRule code. The
HTTP_RESPONSE event is handled in both iRules, and both events have the same default priority
(500). Therefore, because select_pool_irule appears before remove_headers_irule in the iRule
assignment list on the virtual server, the HTTP_RESPONSE event code in select_pool_irule will be
evaluated before the HTTP_RESPONSE event code in remove_headers_irule.
In select_pool_irule, an HTTP::respond command is executed which sends an HTTP response to the
client; in remove_headers_irule, an attempt is then made to remove HTTP headers from the response, but
its too late - the response has already been sent. This triggers a runtime Tcl error, which causes the
connection with the client to be reset. Your browser probably retries the connection several times before
giving up.
You should see log messages similar to these:
Rule /Common/select_pool_irule <HTTP_RESPONSE>:HTTP 404 on 10.10.4.110/garbage.html
Rule /Common/remove_headers_irule <HTTP_RESPONSE>:Removing unwanted headers
10.10.4.110/garbage.html
01220001:3: Tcl error: /Common/remove_headers_irule <HTTP_RESPONSE> - Operation not
supported (line 2) invoked from within "HTTP::header remove "Server""
When you move remove_headers_irule in front of select_pool_irule in the iRules assignment list, the
logic conflict is bypassed. The remove header commands evaluate before the response command. (It does
not matter that there are no HTTP headers to remove.)
When you move remove_headers_irule back to its second position in the iRules assignment list, but add
an event disable command to the HTTP_REQUEST event in select_pool_irule, the logic conflict is also
bypassed. The event disable command effectively prevents the HTTP_REQUEST event in
remove_headers_irule from being evaluated.
Lastly, when you remove the event disable and assign a lower priority to the HTTP_REQUEST event in
remove_headers_irule than in select_headers_irule, the logic conflict is again bypassed. The remove
header commands in remove_headers_irule evaluate before the response command in select_pool_irule.
If you wish to, you may continue with optional Lab 13.3: Load Balance
Based on Payload Contents HTTP and TCP

Lab 13.3 Load Balance Based on Payload

Contents HTTP and TCP (Optional)
Lab Objectives
Use an iRule to select the load balancing pool based on a string parsed from the HTTP URI
Use an iRule to select the load balancing pool based on the same string as parsed from the TCP
payload
Lab Requirements

Load Balance Based on URI Query String Parameter as

Parsed from HTTP URI
Create and assign the iRule
1. Write a new iRule according to the following specifications:

a. Trigger the iRule on the HTTP_REQUEST event.
b. If the HTTP URI contains a parameter named user and that parameters value is me, load
balance to pool in_network_http_pool. Try either of the following to parse the URI for
the parameter:
[findstr [HTTP::uri] "user=" 5 2] equals "me"
[URI::query [HTTP::uri] "user"] equals "me"
c. If the HTTP URI does not contain a parameter named user or that parameters value is
not me, load balance to pool out_network_http_pool. (Hint: This is the else condition
to step b.)
d. In both cases, write a log message indicating which load balancing pool was selected.
2. Assign the iRule to custom_http_vs, removing any existing iRules first.

Test the iRule
3. Test the iRule by connecting to the virtual server using the following scenarios, and fill out the
table below with your results:
a. Connect with no user parameter. For example, http://10.10.X.110
b. Connect with user parameter set to me. For example, http://10.10.X.110?user=me
c. Connect with user parameter set to something other than me. For example,
http://10.10.X.110?user=you or http://10.10.X.110?user=
HTML from pool Other page elements from pool
No user parameter
user=me
user=you (or similar)
4. Confirm your test results by examining the log messages produced. Is this behavior what you
expected? Why or why not?
Load Balance Based on URI Query String Parameter as

Parsed from TCP Payload
Modify the iRule
5. Modify the iRule you created according to the following specifications:

a. Change the event from HTTP_REQUEST to CLIENT_DATA.
b. Change the command that looks for the user parameter to search the TCP payload (at
layer 4) rather than the HTTP URI (at layer 7):
[findstr [TCP::payload] "user=" 5 2] equals "me"
c. Add a second event to collect TCP payload data upon completion of the client handshake:
when CLIENT_ACCEPTED {
TCP::collect 1
}
d. Leave the log messages that indicate which load balancing pool was selected.

Test the iRule
6. Test the iRule by connecting to the virtual server using the same three scenarios as before, and fill
out the table below with your results:
No user parameter
user=me
user=you
7. Do your results differ when examining the whole TCP payload versus just the HTTP URI? If so,
try to find out why. (Hint: Examine the HTTP headers that are sent on each request for a page
element other than the HTML.)
Expected Results
When parsing the HTTP URI

No user parameter out_network_http_pool out_network_http_pool
user=me in_network_http_pool out_network_http_pool
user=you out_network_http_pool out_network_http_pool
When parsing the HTTP URI, the results are fairly predictable if you understand that our web application
does not include any HTTP query strings on any links. Therefore, when you add the query string
user=me to the initial request for the web applications default page HTML, that request is load balanced
to pool in_network_http_pool. But the subsequent requests for each of the other page elements - such as
.css, .js, .jpg, etc - do not include an HTTP query string, therefore they are all load balanced to pool
out_network_http_pool.
When no query parameter is specified on the initial request, or user= is set to something other than me,
the request for the page HTML is also load balanced to pool out_network_http_pool.
Continue Expected Results on the next page.

When parsing the TCP payload

user=me in_network_http_pool Depends on browser:
May all be load balanced to
in_network_http_pool except the request for
background.gif, which is load balanced to
out_network_http_pool
May all be load balanced to
out_network_http_pool
When parsing the TCP payload, the results may not be what you expected. In part, thats because your
iRule is now examining a much larger string (TCP::payload) looking for the string user= than in the
previous test, where the iRule was only examining the string HTTP::uri (as parsed by the BIG-IP system
from the TCP payload). The chances of encountering that string elsewhere in the payload are greater.
When you add the query string user=me to the initial request for the web applications default page
HTML, that request is load balanced to pool in_network_http_pool, as you expected. But, depending on
the browser youre using and how its configured, the requests for most of the other page elements may
also have been load balanced to in_network_http_pool.
As it happens, many browsers automatically send an HTTP Referrer header to indicate where the link to
the requested element was generated. On all of the page elements except background.gif, if the browser
sent a Referrer header, it might indicate http://10.10.X.110/?user=me. Since your iRule is examining
the entire TCP payload, it finds the user=me string in this header and load balances the request to
in_network_http_pool. The request for background.gif is generated from within the pages CSS element,
therefore its Referrer field does not contain the user=me query string, and is load balanced to
When developing iRules, its important to understand your application and how clients interact with it so
as to avoid unintended results!

Lab 13.4 Load Balance, Intelligent SNAT, Insert

XFF Header, and Log 404 Not Found URI
Lab Objectives
Use a local traffic policy to:
Select the load balancing pool based on the clients IP address
Insert an X-Forwarded-For header into the HTTP request before passing to the web server
Use a variable to pass a value that is only available in the client-side context to a server-side context
Log the HTTP URI in the event the web server responds with a 404 status code
Lab Requirements

Lab Preparation Steps

1. Remove any iRules that are assigned to custom_http_vs.
2. Enable all pool members in in_network_http_pool.
Create a Local Traffic Policy
Create the policy
3. Create a new local traffic policy called select_pool_policy:
Local Traffic Policies : Policy List Policy List Page and click Create

Policy Name select_pool_policy
Strategy Execute first matching rule
When complete, click Create Policy

Add a rule to select load balancing pool based on client IP
4. In the Rules section of the resulting window, click the Create button to add a new rule to policy
select_pool_policy.
a. Name the rule in_network_clients_rule.
b. In the Match all of the following conditions section, click the plus sign (+) button and set
the following: TCP address matches any of 10.10.X.0/24 at request time.
c. In the Do the following when the traffic is matched section, click the plus sign (+) button
and set the following: Forward traffic to pool in_network_http_pool.
d. Save the rule.
5. Use the same technique as in the previous step to add a second rule to policy select_pool_policy:
a. Name the rule out_network_clients_rule.
b. Match all of the following conditions: TCP address matches any of 0.0.0.0/0 at request
time.
c. Do the following when the traffic is matched: Forward traffic to pool
d. Save the rule.
Save a draft of the policy
6. Save a draft copy of policy select_pool_policy by clicking the Save Draft button in the General
Properties section of the page.
7. Try to assign select_pool_policy to the virtual server called custom_http_vs. Use the same
technique that you did to assign an iRule, except use the Manage button in the Policies section
rather than the iRules section of the virtual servers configuration.
a. Does select_pool_policy appear in the list of Available policies? Why or why not?
8. From the TMOS shell, list the policys configuration:
(/Common)(tmos)# list /ltm policy select_pool_policy
a. Was the policy found? Why or why not?
9. Change to the /Drafts folder, and rerun the list command to list the draft policys configuration:
(/Common)(tmos)# cd Drafts
(/Common/Drafts)(tmos)# list ltm policy select_pool_policy
a. Was the policy found now?
b. What are the policys requires and controls settings?
c. What is the policys status?

Save and publish the policy
10. Back in the Configuration utility, navigate to policy select_pool_policy and change Save Draft to
Save and Publish Policy.
a. Does select_pool_policy now appear in the list of Published Policies?
b. Does it also still appear in the list of Draft Policies?
11. Try assigning the policy to virtual server custom_http_vs again. Were you successful this time? If
not, correct any issues that arise before continuing on to the next step.
12. Using TMSH, list the draft policys configuration again.
a. Was the policy found? Why or why not?
13. Change to the /Common folder, and rerun the list command to list the published policys
configuration:
(/Common/Drafts)(tmos)# cd /Common
(/Common)(tmos)# list ltm policy select_pool_policy
a. Was the policy found now?
b. What is the policys status?
Test initial policy behavior with traffic
14. Use a browser to open a connection to the virtual server at http://10.10.X.110. Which pool
members are you load balancing to? (Confirm your answer using local traffic statistics.)
15. Have another student in class access your virtual server. Were they able to connect? If not, why not
and what can be done to correct the issue?
Modify a Published Policy
Create a draft copy of the published policy
16. Navigate back to published policy select_pool_policy and click the Create Draft button to create a
draft copy of the policy to edit.
Add a SNAT automap option on the forward traffic action for out-of-network clients
17. Select the draft version of select_pool_policy to edit.

18. Select rule out_network_clients_rule.
19. In the Do the following when the traffic is matched section, on the Forward traffic option, click
the Options button to open additional action configuration options:
a. Check the box to the left of SNAT.
b. Select automap from the pull-down to the right of SNAT.
c. Click the Done button.
20. Click the Save button to save the modifications to the rule.

21. Change Save Draft to Save and Publish Policy to republish the modified policy.
Test traffic behavior
22. Test access to the virtual server again from your workstation and from another students
workstation.
a. Are you both able to connect?
b. Is your source address translated (as seen on the web page)?
c. Is your partners source address translated?
Write custom log messages from each rule
23. Modify select_pool_policy and add a log action to both rules. Send an info level log message to
/var/log/ltm with the name of the pool the request is being load balanced to.
24. View the local LTM log from the command line: tail f /var/log/ltm
25. Back on your browser session to http://10.10.X.110, hard-refresh the screen. Was there any change
in traffic behavior?
26. View the log messages that were written to /var/log/ltm. Did your policy write any messages? If
so, were they what you expected?
27. Have your partner access your virtual server, and then view the log messages again. Did your
policy write any messages? If so, were they what you expected?
Insert an X-Forwarded-Header and Retest

28. Add another action to out_network_clients_rule to insert the original clients IP address in a
special HTTP header: Insert http header named X-Forwarded-For with value
tcl:[IP::remote_addr] at request time.
29. Back on your browser session to http://10.10.X.110, hard-refresh the screen. Did your policy insert
an X-Forwarded-For header for you? (The web page will indicate in the blue area if an XFF header
was received.)
30. Have another student in class access your virtual server at http://10.10.X.110. Did your policy
properly insert the X-Forwarded-For header for them?

Log the Requested Hostname and URI on 404 Response
Create and assign a second policy
31. Create a new local traffic policy named log_404_policy according to the following specifications:
a. Set Strategy to Execute all matching rule
b. Add a rule named save_hosturi_rule: For All traffic, Set variable named RequestedURL
equal to tcl:[HTTP::host][HTTP::uri] at request time.
c. Add a rule named log_hosturi_rule: If HTTP Status code is equal to any of 404, Log
message tcl:404 status code on $RequestedURL at response time to Facility local0 with
Priority notice.
32. Assign the policy to custom_http_vs after select_pool_policy.
33. Back on your browser session to http://10.10.X.110, hard-refresh the screen. Was there any change
in traffic behavior? How about for your partner?
34. Try to access http://10.10.X.110/garbage.html. Did you receive a 404 Not Found response (from
your browser)? Was a log message written indicating the hostname and URI that caused the 404
response from the web server?
Expected Results
When you initially created select_pool_policy, you may not have thought to add source address translation
so that your partner could access the application through the virtual server, too. Once you intelligently
enabled SNAT automap on out_network_clients_rule, your partner was able to successfully connect.
Your partner should also be the only one who has an X-Forwarded-For header inserted by the policy on
requests to the back-end server.
After adding log_404_policy to custom_http_vs, nothing changes with respect to traffic behavior except
on a 404 status response from the back-end server, as occurs when you try to access garbage.html.
/var/log/ltm should show messages similar to this:
May 19 14:47:57 bigip4 info tmm[15930]:
[/Common/select_pool_policy/in_network_clients_rule]: Load balancing to
in_network_http_pool
May 19 14:47:57 bigip4 notice tmm[15930]: [/Common/log_404_policy/log_hosturi_rule]: 404
status code on tcl:10.10.4.110/garbage.html
Note that you cannot send a custom response page from a local traffic policy. An iRule is required.
You may continue with optional Lab 13.5: Remove Unwanted Headers
from HTTP Response via a Local Traffic Policy

Lab 13.5 Remove Unwanted Headers from

Response via a Local Traffic Policy (Optional)
Lab Objectives
Use a local traffic policy to unconditionally remove unwanted headers from the response before
sending it to the client
Lab Requirements

Ability to view HTTP request and response headers on the client, such as with Chromes or
Firefoxs Inspect Element developer tool, or with Fiddler.
Examine Existing Headers
If you did optional Lab 13.2 Remove Unwanted Headers from HTTP
Response via an iRule, you can skip to step 2.
1. Before you add a new rule to your policy, view the HTTP response headers sent to your virtual
server at http://10.10.X.110. If youre unfamiliar with how to do this, here are some general steps
for use with Chrome or Firefox:
a. Right-click somewhere on the page (for example, in the blue area), and select Inspect
Element.
b. In the Inspect Element window, click the Network tab.
c. Reload the page (Ctrl+F5).
d. In the resulting list of page elements in the Inspect Element window, scroll to the top of
the list and click on the first entry (the GET for the initial HTML document for the page at
10.10.X.110). This should display both the HTTP request and response headers that were
transmitted.
e. Examine any of the other page elements to see if they also contain a Server response
header.


In the responses for various page elements, you may see any one or more of the following headers:
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u7
X-Pad: avoid browser bug
These (and other similar) headers present security vulnerabilities, since they inform a potential attacker
what sort of system theyre dealing with. They are unnecessary and removing them can make life a little
more difficult for a hacker.
Remove Unwanted Response Headers and Test
Create a new policy
2. In select_pool_policy, add a new rule called remove_headers_rule. In the Conditions

section, leave all settings at their defaults. Do not add any conditions to the conditions list. In the
Actions section, configure the following actions:
Target Event Action Parameters
http_header response remove name Server
log response write message Removing Server header
facility local0
3. Save the rule. Your policy should now have three rules, with remove_headers_rule the third and
last rule in the list.
Test the new rule
4. Open a browser session to http://10.10.X.110 and view the HTTP headers for each of the page
elements returned. Is the Server header still present?
5. View messages written to /var/log/ltm. Were messages written? Were they what you expected?
Did remove_headers_rule trigger? If not, why not?

Your policys matching strategy is currently set to first-match. As a result, if you are connecting to the
virtual server from your client workstation at 10.10.X.30, you will match rule in_network_clients_rule,
and no other matching rules will be executed. In order for rule remove_headers_rule to also trigger, you
must change the policys matching strategy from first-match to all-match.
Test Matching Strategy and Order of Precedence
Change the matching strategy and retest
6. Change the matching strategy on select_pool_policy from first-match to all-match.

7. Retest and check for header removal and log messages again. This time, the Server header should
no longer be present, and the log messages from remove_headers_rule should be displayed in
/var/log/ltm.
Change the rule order and retest
8. Change the order of the rules in select_pool_policy:

a. Drag remove_headers_rule from the bottom of the list to the top of the list, making it the
first rule in the policy.
9. Retest with the rules in the new order.
a. Were your results the same or different? Why?
b. What do you suppose will happen now if you changed the policys matching strategy back
to first-match? (Try it, if you would like to see the effect.)
If you still see the Server headers, check your rule logic to make certain the name of the header youre
removing is specified correctly as Server.
In this example, changing the order of the rules with matching strategy set to all-match makes no difference
with respect to how traffic is processed. However, if you set matching strategy back to first-match and try
connecting again, the connection will be reset. This is due to rule remove_headers_rule being
unconditional. It will always match traffic, regardless of traffic content. Therefore, rule
in_network_clients_rule will never execute to select the load balancing pool.
If you wish to, you may continue with optional Lab 13.6: Load Balance
Based on HTTP URI Query String

Lab 13.6 Load Balance Based on HTTP URI

Query String (Optional)
Lab Objectives
Use a local traffic policy to select the load balancing pool based on the value of an HTTP query
string parameter
Lab Requirements

Load Balance Based on URI Query String Parameter
Create and assign the local traffic policy
1. Create a new local traffic policy according to the following specifications:

a. If the HTTP URI query parameter named user has the value me, load balance to pool
in_network_http_pool and write a log message indicating so.
b. If the HTTP URI query parameter named user does not have the value me, load balance to
pool out_network_http_pool and write a log message indicating so.
2. Assign the policy to custom_http_vs, removing any existing policies or iRules first.
Test the policy
3. Test the policy by connecting to the virtual server using the following scenarios, and fill out the
table below with your results:
a. Connect with no user parameter. For example, http://10.10.X.110
b. Connect with user parameter set to me. For example, http://10.10.X.110?user=me
c. Connect with user parameter set to something other than me. For example,
http://10.10.X.110?user=you or http://10.10.X.110?user=
No user parameter
user=me
user=you (or similar)

4. Confirm your test results by examining the log messages produced. Is this behavior what you
expected? Why or why not?
Expected Results

user=me in_network_http_pool out_network_http_pool
When parsing the HTTP URI, the results are fairly predictable if you understand that our web application
does not include any HTTP query strings on any links contained within the default page. Therefore, when
you add the query string user=me to the initial request for the web applications default page HTML, that
request is load balanced to pool in_network_http_pool. But the subsequent requests for each of the other
page elements - such as .css, .js, .jpg, etc - do not include an HTTP query string, therefore they are all load
balanced to pool out_network_http_pool. When no query parameter is specified on the initial request, or
user= is set to something other than me, the request for the page HTML is also load balanced to pool

14-2 Chapter 14 - Final Lab Project
Lab 14.1 Configure BIG-IP from Customer

Specifications
Lab Objectives
Configure BIG-IP LTM based on customer requirements and verify functionality
Lab Requirements
Configure BIG-IP from Customer Specifications

1. Restore the configuration on your BIG-IP system from trainX_base.ucs.
2. Configure your BIG-IP system using the application delivery and administrative specifications
provided below, and test to ensure the configuration is working correctly:
Application Delivery Specifications
Backend servers
Previously, there was just one server delivering the customers HTTP, HTTPS, and SSH applications, and
clients connected to them using the IP address 10.10.X.100. However, the server has since become
overloaded, and a decision was made to add two more servers and load balance traffic using a BIG-IP
LTM system. In addition, the customer wants clients to always connect securely using HTTPS. Therefore,
any clients who try to connect using HTTP are to be redirected to the HTTPS service instead. (Additional
details are provided in Application characteristics.)
The three servers have been moved to a separate network (172.16/16) from clients, and are now available
at the following addresses and service ports:
HTTPS SSH
Server 1 172.16.20.1 443 22
Server 2 172.16.20.2 443 22
Server 3 172.16.20.3 443 22
Server 1 is the original server; servers 2 and 3 are new and have twice the capacity of the original server.
There is very little SSH activity so there is no concern about the impact of that traffic on the HTTPS
application. The customer wants to use servers 2 and 3 primarily, and add server 1 also if one of the
primary servers becomes unavailable. Traffic should be load balanced accordingly.
Client traffic arrives on the 10.10/16 VLAN. The customer wants clients to continue to access the
applications at the same IP address as before, 10.10.X.100. The servers on the 172.16/16 network do not
have a route back to clients through the BIG-IP system.

Chapter 14 - Final Lab Project 14-3
Monitoring application health
The customer wants the BIG-IP system to monitor the health of the HTTPS application by checking for
appropriate content delivery. Examine the page source produced by the application and determine an
appropriate string that you can use as the basis for your monitor test. Use one monitor to check all 3 pool
members.
The SSH application also needs monitoring, but only to check that the SSH service is available.
The customer would also like for server administrators to be able to take a server down for maintenance
without having to contact the BIG-IP administrators. The server will respond with the string
maintenance needed to indicate this is the case.
Application characteristics
With the new configuration, the customer wants clients to always connect using SSL/TLS. However,
clients may still try to connect to the HTTP application. If they do, they should be redirected to the
HTTPS application instead.
The HTTPS application is a stateful e-commerce application, and temporarily stores client-specific
information directly on the server. Compliance regulations require that all traffic must be encrypted on the
wire. Clients that connect to these applications all use browsers that accept cookies.
The HTTPS application needs to know the clients actual IP address for logging and statistical purposes.
The customer wants to avoid having to make modifications to the application in order for them to be
delivered through the BIG-IP system, but has agreed to make changes that will look for this address in an
HTTP header instead of in the packets source IP address.
BIG-IP Administrative Specifications

IT department personnel are the only ones authorized to administer the BIG-IP system, and only through
the management interface, either via the command line (SSH) or the Configuration utility (HTTPS).
Administrative access via the BIG-IP systems client-facing self IP addresses is not permitted. IT
personnel use client workstations that are on the 192.168.X.0/24 network.
Three user accounts are needed:
A user with complete access to all BIG-IP administration functions using the Configuration
utility, Linux bash shell, and TMOS shell
A user that can only enable and disable pool members or nodes using the Configuration utility (no
Linux bash or TMOS shell access)
A user that can only manage certificates and keys on the BIG-IP system using the Configuration
utility or TMOS shell
(One possible solution is provided after the optional Path Load Balancing lab.)

Lab 14.2 Path Load Balancing (Optional)

Lab Objectives
Configure a BIG-IP system to simulate load balancing from outside a DMZ to inside.
Lab Requirements
This lab simulates the network environment illustrated below, where LTM #X is your BIG-IP system.
The Instructor LTM is a special BIG-IP system in the classroom, and includes configuration objects that
simulate the firewall devices.
Set Workstation Static Route to 10.30/16 Network

1. Your workstation needs a static route to the 10.30/16 network via your BIG-IP system. If you
dont have one, add one. For example:
route -p add 10.30.0.0 mask 255.255.0.0 10.10.X.33

Restore the Base BIG-IP Network Configuration

2. Restore the BIG-IP configuration from trainX_base.ucs, and ensure that you have no virtual
servers or pools left over.
Remove HA Preparation Settings

3. Navigate to Device Management Devices, select your BIG-IP system, and on the Device
Connectivity tab:
a. Select ConfigSync, set Local Address to None, and click Update.
b. Select Failover Network, check the box at the left of both entries in the Failover
Unicast Configuration section, and click Delete.
c. Select Mirroring, set Primary Local Mirror Address to None, and click Update.
Change VLAN internal from the 172.16/16 Network to the

10.20/16 Network
4. Add two new self IP addresses for VLAN internal using the specifications below:
Name IP Address Netmask VLAN Traffic Group
10.20.X.31 10.20.X.31 255.255.0.0 internal traffic-group-local-only (non-floating)
10.20.X.33 10.20.X.33 255.255.0.0 internal traffic-group-1 (floating)
5. Delete the self IP addresses on the 172.16/16 network.
Create Transparent Virtual Server and Firewall Device Pool

6. Create a transparent network virtual server that load balances traffic destined to the 10.30/16
network through a pool of simulated firewall devices at 10.20.30.1 and 10.20.30.2.
Test the Configuration

7. Open a browser session to http://10.30.17.100.
a. Were you able to connect? If so, add a transparent monitor to the pool that will check to
ensure appropriate content is being delivered.
b. If you were unable to connect, try your skills at troubleshooting. Some tips are provided
on the next page.


If your configurations are correct, you now have access to the 10.30.17.100:80 virtual server and the
application it delivers. (This is the same blue application youve been using throughout the class.) The
page shows that the back end servers saw the traffic originate from the source IP address 172.16.17.33,
which is one of the self IPs on the Instructor BIG-IP system, LTM17. The page also shows the original
HTTP host requested, in this case 10.30.17.100, which is a virtual server on LTM17 that load balances to
the same pool of servers you have been using in class 172.16.20.1, 172.16.20.2, and 172.16.20.3.
If you do not see these results, focus on the traffic that flows between each network and the status
produced by the monitor. You look at statistics and use other tools such as tcpdump to troubleshoot.
Between your workstation and your transparent network virtual server:
- Is your network virtual server showing any request (in) traffic? If not, check the routes on
your workstation.
- Is your network virtual server showing any response (out) traffic? If not, check the ARP
tables on the BIG-IP system.
Between your transparent network virtual server and through the firewall pool members:
- Are the pool members showing any request (in) traffic? If not, check the state of the nodes. If
the pool members show traffic in, check that address and port translation is disabled on the
virtual server.
- Are the pool members showing any response (out) traffic? If so, check the routes on the
firewalls and the address of the client.
Between the selected firewall pool member and the virtual server 10.30.17.100 on LTM17:
- Does the virtual server on the instructor LTM17 show any request (in) traffic? If not, is it set
on the correct network and responding to the firewalls ARP requests?
- Is the virtual server sending the response back to the firewalls? If not, check whether LTM17
has auto last hop or a last hop pool configured.
Between the virtual server on LTM17 and the 172.16/16 pool member:
- Do the pool members show request (in) traffic? If not, check the state of the nodes. If the pool
members show traffic, check the routes on the web servers and the address on the client (third
octet must be X).
- Does the virtual server show response (out) traffic? If not, check the ARP tables on the web
servers.

Possible Solution to Lab 14.1

There are several ways you might have configured your BIG-IP system to provide application delivery
according to the customers specifications. One such solution has been provided for you below.
HTTPS Monitor
ltm monitor https ecommerce_http_monitor {
adaptive disabled
cipherlist DEFAULT:+SHA:+3DES:+kEDH
compatibility enabled
defaults-from https
destination *:*
interval 5
ip-dscp 0
recv "pool member at <b>172\.16\.20\.[1-3]:443"
recv-disable "maintenance needed"
send "GET /index.php HTTP/1.1\r\nHost:www.f5trn.com\r\n\r\n"
time-until-up 0
timeout 16
}
Certificate and Key

sys file ssl-cert ecommerce_certificate.crt {
certificate-key-size 2048
checksum SHA1:1257:864d95ee62c1bba9c2cd0a2db1e97303405169a9
create-time 2016-02-19:07:29:27
created-by admin
expiration-date 1771255767
expiration-string "Feb 16 15:29:27 2026 GMT"
issuer "CN=www.f5trn.com,OU=Ecommerce Applications,O=F5
Networks,L=Seattle,ST=WA,C=US"
key-type rsa-public
last-update-time 2016-02-19:07:29:27
mode 33188
revision 1
serial-number 193562967
size 1257
source-path /config/ssl/ssl.crt/ecommerce_certificate.crt
subject "CN=www.f5trn.com,OU=Ecommerce Applications,O=F5
Networks,L=Seattle,ST=WA,C=US"
updated-by admin
version 3
}

Profiles
Cookie persistence profile
(You could have used Source Address Affinity persistence with a mask of 255.255.255.255 instead.)
ltm persistence cookie ecommerce_cookie_persist {
app-service none
cookie-encryption required
cookie-encryption-passphrase $M$jr$OBgLvEmkAE9iLm+75+PcCA==
cookie-name F5_Networks_Training
defaults-from cookie
httponly enabled
method insert
timeout 180
}
Client SSL profile (for SSL termination on the BIG-IP system)

ltm profile client-ssl ecommerce_clientssl_profile {
app-service none
cert ecommerce_certificate.crt
cert-key-chain {
ecommerce_certificate {
key ecommerce_certificate.key
}
}
chain none
defaults-from clientssl
inherit-certkeychain false
passphrase none
}
Server SSL profile (to re-encrypt on the wire to pool members)

ltm profile server-ssl ecommerce_serverssl_profile {
app-service none
defaults-from serverssl
}
HTTP profile to insert X-Forwarded-For header with clients original IP address

ltm profile http ecommerce_insertxff_profile {
app-service none
defaults-from http
insert-xforwarded-for enabled
proxy-type reverse
}

Load Balancing Pools
Load balancing pool for HTTPS virtual server

ltm pool ecommerce_https_pool {
members {
172.16.20.1:https {
address 172.16.20.1
priority-group 5
session monitor-enabled
state up
}
172.16.20.2:https {
address 172.16.20.2
priority-group 10
ratio 2
state up
}
172.16.20.3:https {
address 172.16.20.3
priority-group 10
ratio 2
state up
}
}
min-active-members 2
monitor ecommerce_http_monitor
}
Load balancing pool for SSH virtual server

ltm pool maintenance_ssh_pool {
members {
172.16.20.1:ssh {
address 172.16.20.1
state up
}
172.16.20.2:ssh {
address 172.16.20.2
state up
}
172.16.20.3:ssh {
address 172.16.20.3
state up
}
}
monitor tcp_half_open
}

iRules
Rather than write a separate iRule, we chose to use the F5-supplied iRule called _sys_https_redirect,
shown here:
ltm rule _sys_https_redirect {
nodelete nowrite
when HTTP_REQUEST {
HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri]
}
definition-signature
mwyl4XlRKRMQc0prWs7RtpgPcNfocOKb+MaFwAnQgAuUZZyG68OaGZsOCN3poUOFdHOc6fk2XAdGR
mTRiP/7BCT7thsOX5zLFzA1N1wcr57KWVzEZt3ezxVXn2Z974OmbWm7P5Lclcr7N3adrLJMWfyfPP
hFRbHd7PlMPRezrfkVZVeUHA/iBPcYcD+w==
verification-status signature-verified
}
Virtual Servers
Virtual server for HTTPS access

ltm virtual ecommerce_https_vs {
destination 10.10.4.100:https
ip-protocol tcp
mask 255.255.255.255
persist {
ecommerce_cookie_persist {
default yes
}
}
pool ecommerce_https_pool
profiles {
ecommerce_clientssl_profile {
context clientside
}
ecommerce_insertxff_profile { }
ecommerce_serverssl_profile {
context serverside
}
tcp { }
}
source 0.0.0.0/0
source-address-translation {
type automap
}
vlans {
external
}
vlans-enabled
vs-index 34
}

Virtual server for HTTP access
This virtual server has no pool, and uses an iRule to redirect the client to use HTTPS instead.
ltm virtual ecommerce_redirect_vs {
destination 10.10.4.100:http
ip-protocol tcp
mask 255.255.255.255
profiles {
http { }
tcp { }
}
rules {
_sys_https_redirect
}
source 0.0.0.0/0
vs-index 39
}
Virtual server for SSH access

ltm virtual maintenance_ssh_vs {
destination 10.10.4.100:ssh
ip-protocol tcp
mask 255.255.255.255
pool maintenance_ssh_pool
profiles {
tcp { }
}
source 0.0.0.0/0
vs-index 37
}
Administrative Control Settings
Administrative access only from clients in the 192.168.X.0/24 network

sys sshd {
allow { 192.168.4.0/24 }
}
sys httpd {
allow { 192.168.4.0/24 }
}

Administrative user with full access

auth user admin_user {
description admin_user
encrypted-password
$6$lNtqxY1a$F.GOCeZLgThTBP9f6hUa40VJfcdJX133kSChzJlp7S5oO/FN6xOErp7ZlUl2XS2C1
0INKyiod1hlsG0WL4WoN0
partition Common
partition-access {
all-partitions {
role admin
}
}
shell none
}
Certificate manager user

auth user certificate_manager_user {
description certificate_manager_user
encrypted-password
$6$w8KgoB4G$HdqUwuGz40TPAq9OkXuqSHkDfHtkjQ6HzQO.EzplWY9zQePkrAeD.Y2sIxSb9bkW2
cZKqjydJ/0dFLIbtwQTJ/
partition Common
partition-access {
all-partitions {
role certificate-manager
}
}
shell tmsh
}
Operator user
auth user operator_user {
description operator_user
encrypted-password
$6$z8m/7aIr$mO9XjtuTSxxHAO07Vv.YW822Uqmt2/l/O1lBRaJjKc.GIkKW3Cy4FEmi3oP06cNiy
k2mJCEPoob5sZi03ikpz1
partition Common
partition-access {
all-partitions {
role operator
}
}
shell none
}

F5 Config Guide PDF

Uploaded by

Copyright:

Available Formats

You might also like

F5 Config Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

F5 Config Guide PDF

Uploaded by

Copyright:

Available Formats

F5 Networks Training

Configuring BIG-IP LTM v12

v12.1 June, 2016

Instructor Guide: Configuring BIG-IP LTM v12.1

Ninth Printing; June, 2016

2016, F5 Networks, Inc. All rights reserved.

Support and Contact Information

F5 Networks, Inc. F5 Networks, Ltd. F5 Networks, Inc. F5 Networks, Inc.

Instructor Guide: Configuring BIG-IP LTM v12.1

Instructor Guide: Configuring BIG-IP LTM v12.1

Chapter 2: Print Version and Organizational Changes....................................................... 2-1

Chapter 3: Classroom Setup Instructions........................................................................... 3-1

Instructor Guide: Configuring BIG-IP LTM v12.1 T-i

Chapter 1: Course Description

Topics covered in this course include:

BIG-IP initial setup (licensing, provisioning, and network configuration)

Instructor Guide: Configuring BIG-IP LTM v12.1 1-1

1-2 Instructor Guide: Configuring BIG-IP LTM v12.1

BIG-IP System Setup Labs

For all labs, when an X is listed in lab instruction steps, please

If lab instructions do not provide a value for a particular configuration

Lab Preparation Tasks

Verify workstation IP addresses are properly configured

Continue with Lab 1.1: Configure the Management Port

Configuring BIG-IP LTM v12 1-11

Lab 1.1 Configure the Management Port

Configure an IP address and network mask

Configure the Management Port

If your management port is already configured, please skip to Lab 1.2,

1-12 Configuring BIG-IP LTM v12

Lab 1.1A: Configure the Management Port via a Serial

Access the serial console

1. Gain access to the BIG-IP systems serial port

Select manual configuration of the IP address

Configuring BIG-IP LTM v12 1-13

Set the IP address to 192.168.X.31

Set the netmask to 255.255.0.0

Set no default route

Confirm the management port configuration

1-14 Configuring BIG-IP LTM v12

Lab 1.1B: Configure the Management Port via the LCD

This optional lab can only be performed on BIG-IP hardware devices.

Configuring BIG-IP LTM v12 1-15

Lab 1.2 Activate the BIG-IP System and

Access to the BIG-IP systems base registration key

Access the Configuration utility via the MGMT Port

Start the Setup utility

Upon connecting to your BIG-IP system, you should be directed to the

2. Click the Next button to start the Setup utility.

If your BIG-IP system is already licensed, a Reactivate button and a

1-16 Configuring BIG-IP LTM v12

License the BIG-IP system

4. Manually activate your BIG-IP license at the F5 License Server:

Configuring BIG-IP LTM v12 1-17

5. Manually activate your BIG-IP license using an existing license file.

1-18 Configuring BIG-IP LTM v12

Provision Your BIG-IP System

Setup Utility Resource Provisioning