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 writte n for F5 solutions at th e version listed on the fron t cover of this document . Some of the featur es 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)

[email protected]

Email (suggestions)

[email protected]

Contacting F5 Networks Web

www.f5.com

Email

[email protected] & [email protected]

F5 Networks, Inc.

F5 Networks, Ltd.

F5 Networks, Inc.

F5 Networks, Inc.

Corporate Office 401 Elliott Avenue West Seattle, Washington 98119

United Kingdom Chertsey Gate West Chertsey Surrey KT16 8AP

Asia Pacific 5 Temasek Boulevard #08-01/02 Suntec Tower 5

Japan Akasaka Garden City 19F 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

[email protected]

[email protected]

[email protected]

[email protected]


Legal Notices Copyright Copyright 2016, 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 a ny 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 other intellectual property property right of F5 except as specifically specifically described by applicable applicable user licenses. F5 reserves the right to change specifications specifications at any time without notice. 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, 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], Fa st Application Proxy, Proxy, Fast Cache, FCINCO, Global Traffic Manager, GTM, GUARDIAN, iApps, IBR, iC all, iControl, iHealth, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iQuery, iRules, iRules OnDemand, iSession, L7 Rate Shaping, LC, Link Controller, LineRate, 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 Sec urity Manager, PSM, Ready Defense, Real Traffic Policy Builder, SalesXchange, ScaleN, S DAS (except in Japan), SDC, Signalling Delivery Controller, Solutions for an a pplication 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], [ DESIGN], Versafe, Versafe [DESIGN], [ DESIGN], VIPRION, Virtual Clustered 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 t rademarks 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 Copyright law. Absolutely no Content Content from this manual may be copied, reproduced, exchanged, 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 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 Organizational Changes....................................................... Changes....................................................... 2-1 Chapter 3: Classroom Setup Instructions 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 U p 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 Obj ect 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................. Usage............................... ..................... ..................... .......................... .......................... ........................... .................... .................... ............. 3-25 Configuring BIG-IP LTM v12.1 Class Setup ................ .............................. ...................... ..................... .......................... .......................... .......................... .................. ..... 3-27


T-i

Chapter 1 – Course Description

Chapter 1: Course Description Course Overview Description This three-day course gives network prof essionals a functional understanding of BIG-IP BIG-IP Local Traffic Manager, introducing students to both commonly used and advanced BIG-IP 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 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 destination address affinity persistence) Monitoring application health with Layer 3, Layer 4, and Layer 7 monitors (including transparent, 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 sync failover device groups, connection and persistence mirroring, and sync-only device groups) Modifying traffic behavior with profiles (including advanced HTTP profile options, caching ca ching, 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. applicatio ns.

Audience This course is intended for system and network administrators responsible for installation, setup, configuration, and administration of the BIG-IP BIG-IP LTM system.


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 a ppropriately to customize application delivery through the BIG-IP system

1-2


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 workstation’s 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


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 student’s 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 system’s 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 113 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



1-13

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 system’s 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 key to tab between fields and options in the config tool. Use the and/or keys to remove field content. Use the 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 key. (If the No option is not already highlighted, use the key to tab to it before pressing the key.)


1-13

1-14


Set the IP address to 192.168.X.31 6. On the Configure IP Address panel, use the , , 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 key to highlight the OK option, then press the 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 key to highlight the OK option, then press the 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 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 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.

1-14



1-15

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


1-15

1-16


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 system’s base registration key Access to the Internet or to the BIG-IP system’s license file Network access to the BIG-IP system’s 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 Fir efox) 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.

1-16



1-17

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 t o 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).


1-17

1-18


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

1-18



1-19

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 A llocation 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 system’s self-signed certificate in class. Note t he expiration date for the certificate. (If the certificate is expired, please notify the instructor.) Click the Next button to continue the Setup utility.


1-19

1-20


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

Management Port

IP Address[/prefix]: 192.168.X.31 Network Mask: 255.255.0.0

Host Name

bigipX.f5trn.com

Host IP Address

Use Management Port IP Address

Time Zone

Set to your classroom’s local time zone

User Adm inistration section Root Account

Disable login: Uncheck ed Password: rootX Confirm: rootX

Admin Account

Password: adminX Confirm: adminX


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.

1-20



1-21

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 W izard Options section ConfigSync

Check the box for Display configuration synchronization options

High Availability

Check the box for Display failover and mirroring options Select Network for Failover Method


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

Address: 172.16.X.31 Netmask: 255.255.0.0 Port Lockdown: Allow Default

Floating IP

Address: 172.16.X.33 Port Lockdown: Allow Default

Internal VLAN Configuration section VLAN Interfaces: Select 1.2 Tagging: Select Untagged Click the Add button

Interfaces When complete, click…


Next

1-21

1-22


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

Self IP

Address: 10.10.X.31 Netmask: 255.255.0.0 Port Lockdown: Allow None

Default Gateway

Leave blank Address: 10.10.X.33 Port Lockdown: Allow None

Floating IP

External VLAN Configuration section Interfaces: Select 1.1 Tagging: Select Untagged Click the Add button

Interfaces When complete, click…

Next

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


Next

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.

1-22



1-23

Configure ConfigSync 17. Configure ConfigSync on the non-floating self IP for VLAN internal , the VLAN we’re using for high availability (HA). Setup utility Setup Utility » ConfigSync ConfigSync Configuration s ection 172.16.X.31 (internal)

Local Address When complete, click…

Next

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 Local Address | Port | VLAN

172.16.X.31 192.168.X.31

| 1026 | internal | 1026 | Management Address

Failover Multicast Configuration s ection Use Failover Multicast Address When complete, click…

Unchecked (Disabled)

Next

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



Next

1-23

1-24


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 c lassroom environment after lab completion

Continue with Lab 1.3: Test Administrative Access

1-24



1-25

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 external’s 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 external’s self IPs by default (“Allow None”). This is a change in behavior from previous versions where the Port Lockdown setting for VLAN external’s self IPs defaulted to “Allow 443” when running the Setup utility.


1-25

1-26


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

Custom List

Select the TCP and Port radio buttons Enter 443 in the field that appears to the right of Port Click the Add button

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 site’s 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 external’s 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.

1-26



1-27

29. Navigate to System » Users and update the admin user settings to permit access to the command line interface, but only to TMSH. Configuration utility System » Users : User List, then click on user admin Account Properties section Terminal Access When finished, click…

tmsh 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


1-27

1-28


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 Configuration utility System » Archives then click Create General Properties section File Name When complete, click…

trainX_base.ucs 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. Configuration utility System » Archives then click trainX_base.ucs General Properties section Archive File

1-28

Click Download: trainX_base.ucs, then save to desktop of your m anagement 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

configltm_http_monitor

HTTP

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


2-43

2-44


Create pools Define the load balancing pool whose members serve the HTTP application content. Use the specifications in the table below: Name

Load Balancing Method

http_pool

Ratio (member)

Members

Ratio

Monitor

172.16.20.1:80 172.16.20.2:80 172.16.20.3:80

1 2 3

configltm_http_monitor

Define the load balancing pool whose members serve the HTTPS content for our application. Use the specifications in the table below: Name

https_pool


Members

Round Robin

172.16.20.1:443 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): Name configltm_src_persist

Persistence Type

Parent Profile

Source Address Affinity

source_addr

Custom Settings Timeout: 30 seconds Prefix Length: Specify IPv4 and 16

Create virtual servers Use the specifications in the table below to create the virtual server that will deliver the HTTP application: Name

Destination Address:Port

Default Pool

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.

2-44

Name


Default Pool

Default Persistence Profile

https_vs

10.10.X.100:443

https_pool

configltm_src_persist



2-45

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 172.16.20.2:80 172.16.20.3:80

4 4 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 det ermine 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.


2-45

2-46

Chapter 2 - Reviewing Local Traffic Configuration 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 B IG-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 member’s 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 student’s 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 server’s configuration. Once added, that student’s 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

2-46



2-47

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 Estimated time for completion: 30 minutes


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.) Name

ssh_pool


Members

Round Robin

172.16.20.1:22 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


2-47

2-48

Chapter 2 - Reviewing Local Traffic Configuration 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. Name


Default Pool

Profiles

ssh_vs

10.10.X.100:22

ssh_pool

tcp

(tmos)# create /ltm virtual ss h_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 }

2-48



2-49

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_modul e2b.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 it’s in the /shared/tmp directory.)


2-49

2-50


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 t o 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 system’s 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.

2-50


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 Estimated time for completion: 15 minutes

Lab Requirements BIG-IP base setup configuration 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? Reset the statistics for http_pool. 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-15

3-16


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 t han 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 t han 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 reenabling 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

3-16



3-17

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 Estimated time for completion: 10 minutes

Lab Requirements BIG-IP base setup configuration 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 Reset the statistics for http_pool. 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?

Expected Results and Troubleshooting 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


3-17

3-18


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 Estimated time for completion: 10 minutes

Lab Requirements BIG-IP base setup configuration http_pool (as configured at the end of the previous lab) http_vs (as configured at the end of the previous lab)

Configure and Test Connection Limits Confirm traffic behavior before connection limits Reset the statistics for http_pool. 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 Reset the statistics for http_pool. 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?

3-18



3-19

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.


3-19

3-20


3-20


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 Estimated time for completion: 10 minutes

Lab Requirements BIG-IP base setup configuration http_pool (as configured at the end of the previous chapter) http_vs (as configured at the end of the previous chapter)

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 cre ated.


4-19

4-20


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.):

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

Specify…30 seconds


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.

4-20



4-21

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 browser’s address bar, c hange 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?


4-21

4-22


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 w hat the persistence criteria is generated from

Continue with Lab 4.2: Implement Match Across Services

4-22



4-23

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 BIG-IP base setup configuration http_pool (as configured at the end of the previous lab) http_vs (as configured at the end of the previous lab) 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?


4-23

4-24


Expected results Without Match Across Services, the two sessions—one to http://10.10.X.100 and the other to https://10.10.X.100 —are 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 .

4-24


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 Estimated time for completion: 40 minutes

Lab Requirements BIG-IP base setup configuration http_pool (as configured at the end of the previous chapter) https_pool (as configured at the end of the previous chapter) http_vs (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 Type

Parent Monitor

Interval, Timeout

Other Parameters

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 Type

Parent Monitor

Interval, Timeout

Other Parameters

configltm_https_monitor

HTTPS

https

5, 16

Send String: GET /index.php\r\n Receive String: Server [1-3] Alias Service Port: 443 (HT TPS)


5-23

5-24


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 Least…1. a.

How did the pool members’ status change?

b. Examine each pool member’s 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.

5-24



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 monitor’s 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 Least…1, 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 monitor’s 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 member’s detail, how is each monitor impacting the member’s 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 monitor’s 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-25

5-26


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 member’s 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 .

5-26


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 Estimated time for completion: 20 minutes


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 rightclick 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 (IP)

172.16.0.0/16

*All Ports


6-5

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 (IP)

172.16.20.2

*All Ports

Enabled on… 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 ser vices 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.

6-6


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 Estimated time for completion: 15 minutes

Lab Requirements BIG-IP base setup configuration 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

7-12



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. Baseline No SNAT (Test 1)

SNAT Auto Map on https_vs (Test 2)

SNAT with Origin Network Range (Test 3)

All Addresses SNAT (Test 4)

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


7-13

7-14


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

7-14



7-15

Expected Results Baseline No SNAT (Test 1)

Me

SNAT Auto Map on https_vs (Test 2)

SNAT with Origin Network Range (Test 3)

All Addresses SNAT (Test 4)

http_vs

10.10.X.30

10.10.X.30

172.16.X.150

172.16.X.150

https_vs

10.10.X.30

172.16.X.33

172.16.X.33

172.16.X.33

172.16.20.1

Fail; no listener (SNAT or VS)


172.16.X.150

172.16.X.150

http_vs

Fail; no route back to my BIG-IP



172.16.X.200

https_vs


172.16.X.33

172.16.X.33

172.16.X.33

Partner

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


7-15

7-16


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 Estimated time for completion: 10 minutes

Lab Requirements BIG-IP base setup configuration http_vs (10.10.X.100:80, default pool http_pool) 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 enabled on all VLANs

Me

http_vs

172.16.X.150

https_vs

172.16.X.33

172.16.20.1

172.16.X.150

http_vs

172.16.X.200

https_vs

172.16.X.33

SNATs disabled on VLAN external (Test 1)

SNATs enabled on VLAN external (Test 2)

Disallow SNAT on https_pool (Test 3)

Partner

7-16



7-17

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


7-17

7-18


Expected Results

Me

Baseline SNATs enabled on all VLANs

SNATs disabled on VLAN external (Test 1)

SNATs enabled on VLAN external (Test 2)

http_vs

172.16.X.150

10.10.X.30

172.16.X.150

172.16.X.150

https_vs

172.16.X.33

172.16.X.33

172.16.X.33

10.10.X.30

172.16.20.1

172.16.X.150


172.16.X.150

172.16.X.150

http_vs

172.16.X.200


172.16.X.200

172.16.X.200

172.16.X.33

Fail; no route back to my BIG-IP since SNAT not allowed

Partner https_vs

172.16.X.33

172.16.X.33

Disallow SNAT on https_pool (Test 3)

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

7-18



7-21

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 Estimated time for completion: 20 minutes


Solve a Routing Issue w ith Load Balancing Clients and Servers on the Same Subnet Establish baseline behavior 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:


7-21

7-22


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.

7-22


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 Estimated time for completion: 20 minutes

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 r efer 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-9

8-10


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. Configuration utility Device Management » Devices » » Device Connectivity » Failover Network Failover Unicast Configuration section Local Address | Port | VLAN

172.16.X.31 192.168.X.31

| 1026 | internal | 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. Configuration utility Device Management » Devices » » 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?

8-10



8-11

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. Configuration utility Device Management » Device Trust » Peer List, then click the Add button Remote Device Credentials Device IP Address

192.168.B.31 where “B” is the station number of your partner’s BIG-IP system

Administrator Username

admin

Administrator Password

admin


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.

On Both BIGIP-A and BIGIP-B Since both devices are now members of a trust domain, you should see the name of your partner’s 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.


8-11

8-12

Chapter 8 - Configuring High Availability Name your device group DG_AB_failover , substituting your station number for “A” and your partner’s 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 partner’s 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 .

On Both BIGIP-A and BIGIP-B 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.

On Both BIGIP-A and BIGIP-B 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 device’s self IP addresses. Do both BIG-IP systems still have their static and floating self IP addresses? Why?

8-12



8-13

Expected results and troubleshooting 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-IP’s floating self IP addresses; and another traffic group named traffic-group-local-only (non-floating traffic group) which contains the device’s 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 BIGIPB. 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


Members

Port

ssh_pool

Round Robin

172.16.20.1 172.16.20.2 172.16.20.3

22 22 22

Sync the configuration to the device group. On the standby BIG-IP, verify that you can see ssh_pool .


8-13

8-14

Chapter 8 - Configuring High Availability Creating a new virtual server on the standby BIG-IP (where “X” is the standby system’s 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 Traff ic 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 partner’s 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.

8-14



8-15

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.


8-15


8-19

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 Estimated time for completion: 15 minutes

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: Configuration utility Device Management » Traffic Groups » Create General Properties section Name When complete, click…

a.

traffic-group-2 Finished

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, crea te 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.


8-19

8-20


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 partner’s 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 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 » trafficgroup-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?

8-20



8-21

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 B IG-IP device to the other, as a result of the MAC masquerade address floating to the newly-active device along with the traffic group.


8-21

Chapter 9 - Configuring High Availability Part 2

9-5

Lab 9.1 – Configure VLAN Failsafe Lab Objectives Configure the VLAN Failsafe trigger Estimated time for completion: 10 minutes

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


9-5

9-6


Option A: BIG-IP VE Steps Enabling VLAN failsafe 1. On one BIG-IP system only, create an additional VLAN, called null_vlan. Configuration utility Network

VLANs : VLAN List and click Create

General Properties section null_vlan

Name Configuration: Advanced Fail-safe

Checked

Fail-safe Timeout

15

Action

Failover


Finished

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 f or 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.

9-6



9-7

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 ca ble 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. b. c.

At the BIG-IP CLI prompt you can watch the logfile with:

tail –f /var/log/ltm 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.


9-7

9-10


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 Estimated time for completion: 15 minutes

Lab Requirements BIG-IP base setup configuration 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 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 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 th e 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.

9-10



9-11

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


9-11

9-12


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 Estimated time for completion: 20 minutes


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 Type

Profile Type

Name

Persistence

Source configltm_src_persist Address Affinity

Parent Profile

Custom Settings

source_addr

Name


Members

Port

https_pool

Round Robin

172.16.20.1 172.16.20.2 172.16.20.3

443 443 443

Timeout: 30 seconds Prefix length: IPv4 24

Name

Destination

Port

Default Pool

Default Persistent Profiles

Other

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.

9-12



9-13

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.


9-13

9-14


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.

9-14


9-16


Lab 9.4 - Configure N+1 Availability Lab Objectives Add a third member to an existing device group and test failover capabilities Estimated time for completion: 15 minutes

Lab Overview Member of the previous Sync-Failover pair will join as 3 rd 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.

9-16



9-17

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.


9-17

9-20


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 Estimated time for completion: 15 minutes

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 4 th 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 B IGIP-D under Device Management » Devices .

9-20



9-21

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 mem ber 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.


9-21

9-22


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.

9-22



9-23

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


9-23

9-24


9-24


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 Estimated time for completion: 10 minutes


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 Profile (Test 1) Client-Side

Server-Side

With Compression Profile (Test 2) Client-Side

Server-Side

With Compression Exclude List (Test 3) Client-Side

Server-Side

Bits Out

AcceptEncoding header included on request? ContentEncoding 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.)

10-34



10-35

Establish baseline behavior 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.


10-35

10-36


Expected results Without Compression Profile (Test 1)

With Compression Profile (Test 2)

With Compression Exclude List (Test 3)

Client-Side

Server-Side

Client-Side

Server-Side

Client-Side

Server-Side

30.3K*

30.3K*

37.4K*

121.9K*

121.5K*

121.9K*

AcceptEncoding header included on request?

Yes; gzip, deflate

Yes; gzip, deflate

Yes; gzip, deflate

No

Yes; gzip, deflate

No

ContentEncoding header included on response?

Yes; gzip

Yes, gzip

Yes, gzip

No

No

No

Bits Out

* 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 profile’s 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

10-36



10-37

Lab 10.2 – Test Web Acceleration Behavior Lab Objectives Accelerate web application delivery by caching web objects in BIG-IP RAM cache Estimated time for completion: 20 minutes

Lab Requirements BIG-IP base setup configuration 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 Establish baseline behavior 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 browser’s 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.


10-37

10-38


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

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

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 profile’s 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 uri

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

10-38



10-39

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 tr y 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 s izes to the parent’s 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.


10-39

10-40


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. T here 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 keepalives 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 profile’s 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 client’s request.) For any object served from the pool members, the client’s Connection: Keep-Alive request is not honored, as keep-alives are turned off on the back e nd servers. You should see many cache hits when examining web acc eleration 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 (it’s 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

10-40



10-41

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 Estimated time for completion: 5 minutes

Lab Requirements BIG-IP base setup configuration http_vs (10.10.X.100:80, default pool http_pool)

Create and Test a Stream Profile 1. Create a Stream profile using the information in the table below: Configuration utility Local Traffic

Profiles : Other : Stream

New Stream Profile

General Properties section 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?


10-41

10-42


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.

10-42


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 Estimated time for completion: 15 minutes


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.

11-14



11-15

Ensure your PC has access to your BIG-IP system Create a packet filter using the specifications in the table below: Configuration utility Network » Packet Filters » Rules, then click Create Configuration section 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

Source Hosts and Networks

Restrict to any in list… 10.10.X.30, then click Add

Destination Hosts and Networks

Any

Destination Port

Any

Verify that you still have access to your system and your partner’s system.


11-15

11-16


Prevent all other traffic Create another filter using the specifications in the table below: Configuration utility Network » Packet Filters » Rules, then click Create Configuration section Name

them

Order

Last

Action

Discard

Rate Class


VLAN/Tunnel

*All

Logging

Disabled


Build Expression

Protocols

Any

Source Hosts and Network List

Restrict to any in list… Enter either: 10.10 or 10.10.0.0/16, then click Add

Destination Hosts and Network

Any

Destination Port

Any

Verify that your partner has lost access to your system.

11-16



11-17

Grant access to partner PC Create another filter using the specifications in the table below: Configuration utility Network » Packet Filters » Rules, then click Create Configuration section Name

partner

Order

Last

Action

Accept

Rate Class


VLAN/Tunnel

*All

Logging

Disabled


Build Expression

Protocols

Any

Source Hosts and Network List

Restrict to any in list… 10.10.Y.30, then click Add

Destination Hosts and Network

Any

Destination Port

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.


11-17

11-18


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

11-18


11-22


Lab 11.2 - SNMP Traps Lab Objectives Setup the BIG-IP System to send t raps to the SNMP Management console Estimated time for completion: 5 minutes


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. 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: Configuration utility System » SNMP » Traps » Destination, then click Create Record Properties section Version

v1

Community

Public (Note: Public (Note: SNMP community strings are case s ensitive)

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

11-22



11-23

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. 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. down. You can find other options 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 s o that no traps are triggered.


11-23


11-25

Lab 11.3 - IPv6 Lab Lab Objectives Configure an IPv6 client and access backend servers with IPv4 Pool Members. Estimated time for completion: 10 minutes


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 interface’s 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= 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 Configuring BIG-IP LTM v12

11-25

11-26


Create a self IP using the specifications in the table below: Configuration utility Network » Self IPs, then click Create Configuration section Name

ipv6

IP Address

fc00:a0a:0:X::31 (where X is your station 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: Configuration utility Local Traffic » Virtual Server : Virtual Server List, then click Create Configuration section Name

ipv6_vs

Destination Address/Mask

fc00:a0a:0:X::100 (where X is your station 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?

11-26


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 service’s components Estimated time for completion: 20 minutes

Lab Requirements: BIG-IP base setup configuration


12-25

12-26


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

classroom_website

Template

f5.http

SSL Encryption section How should the BIG-IP system handle SSL traffic?

Plaintext to and from both clients an d servers

Virtual Server and Pools section What IP address do you want to use for the virtual server?

10.10.X.108

What port do you want to use for the v irtual server?

80

What FQDNs will clients use to access the servers?

www.classroomwebsiteX.com

Do you want to create a new pool or use an existing one?

Create a new pool

Which web servers should be included in this pool?

Node/IP address: 172.16.20.1 Port: 80 click Add Node/IP address: 172.16.20.2 Port: 80 click Add Node/IP address: 172.16.20.3 Port: 80

Application Health section Create a new health monitor or use an existing one?

Create a new health monitor

What HTTP URI should be sent /index.php to the servers? What is the expected response to the HTT P request? When complete, click…

12-26

Server [1-3]

Finished



12-27

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 template’s 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.


12-27

12-28


Expected results and troubleshooting 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 system– icmp –which you configured earlier in this class. Although it appears in the classroom_website application service’s 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 you’re not pulling elements from your browser’s 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.

12-28



12-29

Expected results and troubleshooting 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, you’ll experiment with using partition and path as part of a configuration object’s full name, and with navigating into and out of the TMOS f older hierarchy using TMSH. You are encouraged to use the TMSH command completion feature to help you c hoose 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


12-29

12-30


Expected results and troubleshooting 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 you’ve 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 . Configuration utility iApps » Application Services » classroom_website, then click Properties Application Service section: Advanced view Strict Updates When complete, click…

(checked) Update (if Strict Updates w as 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 .

12-30



12-31

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 member’s status? Is it being monitored? Confirm your answer by checking the pool member’s properties. c.

If the pool member is being monitored, why is its status currently unknown? Wait for the pool member’s 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 service’s 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?


12-31

12-32


Expected results and troubleshooting With Strict Updates enabled, you can change the state of an application service’s virtual servers, pools, and pool members (for example enabled, disabled, forced offline) using the Components page of the application server, the configuration object’s page, and/or tmsh. However, you cannot modify the object’s configuration settings, except through the Reconfigure tab of the application service. With Strict Updates disabled, you can modify an application service’s components settings using the Reconfigure feature of iApps, or using the other “non-iApp” functions of the Configuration utility. However, mixing and matching the two can r esult 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 service’s 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

12-32



12-33

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 a nd a pool with one pool member Estimated time for completion: 10 minutes

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


12-33

12-34


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, c lick…

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

12-34



12-35

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, you’ll 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 service’s 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 don’t specify a protocol profile, the default is to create a Performance (Layer 4) – or FastL4, f or short – virtual server, as indicated by the F5-supplied profile named /Common/fastL4 that was automatically associated with Lab12_WebService_WebVS.


12-35

12-36


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 .

12-36


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 client’s IP addr ess Insert an X-Forwarded-For header into t he 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 Estimated time for completion: 15 minutes


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 you’re 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 browser’s 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.

13-26



13-27

Create the Configuration Objects the iRule Will Reference Refe rence Create two load balancing pools 1. Create two load l oad balancing pools using the specifications in the table below. below. Pool Name

Members


in_network_http_pool

172.16.20.1:80 172.16.20.2:80 172.16.20.3:80 172.16.20.4:80

Round Robin

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 a nd 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 client’s 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 substitute your workstation number where the 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.


13-27

13-28

Chapter 13 - Customizing Application Delivery with iRule iRules s and Local Traffic Policies

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 server’s 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 f our 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 s omewhere 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 iRule’s HTTP_REQUEST event triggered, and, more importantly, why?

Test from a partner’s 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 f rom partner’s workstation 13. Adjust the iRule so that the source address is translated to a BIG-IP BIG-IP self IP for those clients who are not in 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.

13-28



13-29

Expected Results and Troubleshooting HTTP_REQUEST profile dependencies The HTTP_REQUEST event requires an HTTP-type HTTP-type profile on the virtual server before assigning 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 might prefer to create a custom http profile 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 cla c lassroom, ssroom, 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 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 s uch that the default gateway is the BIG-IP BIG-IP system that matches the third octet in the r esponse’s destination IP address. As such, in order for another student in the classroom to access a virtual server on your BIG-IP BIG-IP system, you must have some sort of source address translation configured for that client. Adding Adding a snat automap statement somewhere in the else code block will do this.

Continue this lab on the next page.


13-29

13-30


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, you’ll 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.

13-30



13-31

Modify the iRule to Send a Custom Response Page on HTTP 404 Status In this section of the lab, you’ll 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] }

wh en HT TP_ RE SP ON SE { if { [HTTP::status] eq "404" } { log local0. "HTTP 404 on $RequestedURL" HTTP::respond 200 content " A po lo gy Pag e< /t it le >< /h ea d> We 'r e so rr y, bu t th e pa ge yo u' re loo ki ng fo r (http://$RequestedURL) is temporarily unavailable. If you feel you've reached this page in error, please try again. " } }


13-31

13-32


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 browser’s 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 browser’s standard 404 Not Found page. That’s 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 : Load balancing to in_network_http_pool Rule /Common/select_pool_irule : 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 : Load balancing to in_network_http_pool Rule /Common/select_pool_irule : 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 client’s IP address range. If the specifications asked you to unconditionally insert an XForwarded-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

13-32



13-33


13-33

13-34


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 Estimated time for completion: 10 minutes

Lab Requirements BIG-IP base setup configuration /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 Chrome’s or Firefox’s 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?

Expected Results and Troubleshooting 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 they’re 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.

13-34



13-35

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 :Load balancing to in_network_http_pool

If you are using the Chrome browser, you may also see t his log message: Rule /Common/select_pool_irule :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: when HTTP_RESPONSE { 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 el ement?

Expected results and troubleshooting If your iRule is written correctly, the unwanted headers you specified should be being removed f rom 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 spec ified 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 :Load balancing to in_network_http_pool Rule /Common/select_pool_irule :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 :Load balancing to in_network_http_pool Rule /Common/select_pool_irule :HTTP 404 on 10.10.4.110/favicon.ico Rule /Common/select_pool_irule :Removing unwanted headers10.10.4.110/favicon.ico 0122001:3:Tcl error: /Common/remove_headers_irule -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 .


13-35

13-36


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 e vents is determined by their assignment order. In this next series of steps, you’ll experiment with assignment order to see how this may affect traffic processing at runtime when duplicate events are handled.

Establish baseline behavior 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.

13-36



13-37

5. Add an event disable command to the HTTP_RESPONSE event in select_pool_irule : when HTTP_RESPONSE { if { [HTTP::status] eq "404" } { log local0. "HTTP 404 on $R equestedURL" HTTP::respond 200 content " • • "

event disable } }

6. Test access to your virtual server again at http://10.10.X.110/garbage.html . a.


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


b. What log messages were written to /var/log/ltm ? c.

Which HTTP_RESPONSE event triggered first?


13-37

13-38


Expected results and troubleshooting 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 it’s 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 :Load balancing to in_network_http_pool Rule /Common/select_pool_irule :HTTP 404 on 10.10.4.110/garbage.html Rule /Common/remove_headers_irule :Removing unwanted headers – 10.10.4.110/garbage.html 01220001:3: Tcl error: /Common/remove_headers_irule - 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 hea der 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 r emove 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

13-38



13-39

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 Estimated time for completion: 15 minutes

Lab Requirements BIG-IP base setup configuration /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)

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 parameter’s 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 parameter’s 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.


13-39

13-40


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 sim ilar)

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.

13-40



13-41

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: HTML from pool…


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 HTML from pool…


No user parameter



user=me



user=you



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 application’s 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.


13-41

13-42


When parsing the TCP payload HTML from pool…


No user parameter



user=me


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

user=you



When parsing the TCP payload, the results may not be what you expected. In part, that’s 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 application’s default page HTML, that request is load balanced to pool in_network_http_pool , as you expected. But, depending on the browser you’re using and how it’s 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 page’s CSS element, therefore its Referrer field does not contain the user=me query string, and is load balanced to out_network_http_pool . When developing iRules, it’s important to understand your application and how clients interact with it so as to avoid unintended results!

13-42


13-60


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 client’s IP address Insert an X-Forwarded-For header into t he 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 Estimated time for completion: 20 minutes

Lab Requirements BIG-IP base setup configuration /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)

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 : Configuration utility Local Traffic » Policies : Policy List » Policy List Page and click Create General Properties section Policy Name

select_pool_policy

Strategy

Execute first matching rule


13-60

Create Policy



13-61

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 out_network_http_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 server’s configuration. a.

Does select_pool_policy appear in the list of Available policies? Why or why not?

8. From the TMOS shell, list the policy’s 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 policy’s configuration: (/Common)(tmos)# cd Drafts (/Common/Drafts)(tmos)# list ltm policy select_pool_policy

a.

Was the policy found now?

b. What are the policy’s requires and controls settings? c.

What is the policy’s status?


13-61

13-62


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 policy’s 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 policy’s configuration: (/Common/Drafts)(tmos)# cd /Common (/Common)(tmos)# list ltm policy select_pool_policy

a.

Was the policy found now?

b. What is the policy’s 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 t hey 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.

13-62



13-63

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 student’s workstation. a.

Are you both able to connect?

b. Is your source address translated (as seen on the web page)? c.

Is your partner’s 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.

Test traffic behavior 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 client’s 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?


13-63

13-64


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 .

Test traffic behavior 33. Back on your browser session to http://10.10.X.110 , hard-refresh the screen. Was there a ny 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

13-64



13-65

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 Estimated time for completion: 15 minutes

Lab Requirements BIG-IP base setup configuration /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 Chrome’s or Firefox’s 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 you’re 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.


13-65

13-66


Expected Results and Troubleshooting In the responses for various page elements, you may see any one or more of the following f ollowing 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 they’re 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 c alled 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 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 t hey what you expected? Did remove_headers_rule trigger? If not, why not?

13-66



13-67

Expected results and troubleshooting Your policy’s 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 r ule 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 policy’s matching strategy from first-match to all-match .

Test Matching Strategy Strate gy 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 re test 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 policy’s matching strategy back to first-match ? (Try it, if you would like to see the effect.)

Expected results and troubleshooting If you still see the Server headers, check your rule logic to make certain the name of the header you’re removing is specified correctly as Server. In this example, changing the order of the rules with with matching strategy set to all-match makes no difference with respect to how traffic is processed. However, if you set matching matching strategy back to first-match 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, r ule 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


13-67

13-68


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 Estimated time for completion: 10 minutes

Lab Requirements BIG-IP base setup configuration /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 /Common/custom_http_vs (10.10.X.110:80, no default pool)

Load Balance Based on URI Query String Parameter Create and assign as sign the local traffic policy 1. Create a new local traffic policy according according to the following specifications: 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 something other than me. For example, http://10.10.X.110?user=you or http://10.10.X.110?user= HTML from pool…


No user parameter user=me user=you (or s imilar)

13-68



13-69

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

Expected Results HTML from pool…


No user parameter



user=me



user=you



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 application’s 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.


13-69

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


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 customer’s 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 a dd 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.

14-2



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 t raffic 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 client’s 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 packet’s 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 system’s 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.)


14-3

14-4


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 don’t have one, add one. For example: route -p add 10.30.0.0 mask 255.255.0.0 10.10.X.33

14-4



14-5

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.


14-5

14-6


Expected Results and Troubleshooting 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 you’ve 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 s erver:

-

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 se rver 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 t he 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 firewall’s 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:

14-6

-

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.



14-7

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 customer’s 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 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 }


14-7

14-8


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 { cert ecommerce_certificate.crt key ecommerce_certificate.key } } chain none defaults-from clientssl inherit-certkeychain false key ecommerce_certificate.key passphrase none }

Server SSL profile (to re-encrypt on the wire to pool members) ltm profile server-ssl ecommerce_serverssl_profile { app-service none cert ecommerce_certificate.crt defaults-from serverssl key ecommerce_certificate.key }

HTTP profile to insert X-Forwarded-For header with client’s original IP address ltm profile http ecommerce_insertxff_profile { app-service none defaults-from http insert-xforwarded-for enabled proxy-type reverse }

14-8



14-9

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 session monitor-enabled state up } 172.16.20.3:https { address 172.16.20.3 priority-group 10 ratio 2 session monitor-enabled 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 session monitor-enabled state up } 172.16.20.2:ssh { address 172.16.20.2 session monitor-enabled state up } 172.16.20.3:ssh { address 172.16.20.3 session monitor-enabled state up } } monitor tcp_half_open }


14-9

14-10


iRules Rather than write a separate iRule, we c hose 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 }

14-10



14-11

Virtual server for HTTP access This virtual server has no pool, a nd 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 } }


14-11

F5_Config_Guide.pdf

Recommend Documents