F5 BIGIP V 9 Training

Introduction

F5 Product Line Traffic Management Security Access BIG-IP® Global Traffic Managment BIG-IP® Link Controller BIG-IP® Local Traffic Managment Security Access FirePass® - SSL VPN

Connectivity Traffic Management Local Area Traffic Management TM Solutions Global Traffic Management & Disaster Avoidance Internet Send Users: ISP 1 ISP 2 Connectivity Traffic Management To the Best Site Over the Best ISP Local Area Traffic Management PeopleSoft Firewalls Web Servers Application Servers Databases IDS & Virus Scan Any IP Application! BEA Siebel Remote Access To the Best Application and Device SAP Oracle Financials Email Microsoft

Installation

New Switch Platforms 6400 (2U) 3400 (1U) 1500 (1U) 6400 1500 Dual CPU, 2G Ram, ASIC2 16 10/100/1000 & 4Gbg ports 3400 (1U) Single CPU, 1G Ram, ASIC2 8 10/100/1000 & 2Gbg ports 1500 (1U) Single CPU, 768M Ram 4 10/100/1000 & 2Gbg ports 6400 1500

Virtual Servers, Members & Nodes

Pool - Grouping of Members Internet Clients Router BIG-IP Controller Servers

Pool Members and Nodes Nodes refer to Pool Members IP Address only Internet Nodes refer to Pool Members IP Address only Pool Members 192.168.20.3:80 192.168.20.1:80 192.168.20.2:4002 192.168.20.4:8080

Virtual Server Basic mechanism to manage traffic Internet Virtual Server Basic mechanism to manage traffic IP Address + Service (Port) Combination One Virtual Server points to one or more Nodes 216.34.94.17:80 192.168.20.3:80 192.168.20.2:4002 192.168.20.4:8080

Virtual Server to Pool Members Internet Virtual Server 216.34.94.17:80 Maps to 192.168.20.1:80 Pool Members 192.168.20.3:80 192.168.20.2:4002 192.168.20.4:8080

Address Translation Virtual Server Internet 216.34.94.17:80 Virtual Server Address BIG-IP performs network address translation to real server addresses such that all machines are viewed as one Virtual Server Network Address Translation Real Server Address 192.168.20.2:4002 192.168.20.4:8080 192.168.20.1:80 192.168.20.3:80

Network Flow - Packet #1 Internet 207.17.117.20 Packet # 1 Src - 207.17.117.20:4003 Dest – 216.34.94.17:80 Internet 216.34.94.17:80 BIG-IP translates Dest Address to Node based on Load Balancing Packet # 1 Src – 207.17.117.20:4003 Dest – 192.168.20.1:80 192.168.20.1:80 192.168.20.2:4002 192.168.20.3:80 192.168.20.4:8080

Network Flow – Packet #1 Return 207.17.117.20 Packet # 1 - return Dest - 207.17.117.20:4003 Src – 216.34.94.17:80 Internet 216.34.94.17:80 BIG-IP translates Src Address back to Virtual Server Address Packet # 1 - return Dest – 207.17.117.20:4003 Src – 192.168.20.1:80 192.168.20.1:80 192.168.20.2:4002 192.168.20.3:80 192.168.20.4:8080

Network Flow – Packet #2 Internet 207.17.117.21 Packet # 2 Src - 207.17.117.21:4003 Dest – 216.34.94.17:80 Internet 216.34.94.17:80 Packet # 2 Src – 207.17.117.21:4003 Dest – 192.168.20.2:4002 192.168.20.1:80 192.168.20.2:4002 192.168.20.3:80 192.168.20.4:8080

Network Flow – Packet #2 Return 207.17.117.21 Packet # 2 - return Dest - 207.17.117.21:4003 Src – 216.34.94.17:80 Internet 216.34.94.17:80 Packet # 2 - return Dest – 207.17.117.21:4003 Src – 192.168.20.2:4002 192.168.20.1:80 192.168.20.2:4002 192.168.20.3:80 192.168.20.4:8080

Network Flow – Packet #3 Internet 207.17.117.25 Packet # 3 Src - 207.17.117.25:4003 Dest – 216.34.94.17:80 Internet 216.34.94.17:80 Packet # 3 Src – 207.17.117.25:4003 Dest – 192.168.20.4:8080 192.168.20.1:80 192.168.20.2:4002 192.168.20.3:80 192.168.20.4:8080

Network Flow – Packet #3 Return 207.17.117.25 Packet # 3 - return Dest - 207.17.117.25:4003 Src – 216.34.94.17:80 Internet 216.34.94.17 Packet # 3 - return Dest – 207.17.117.25:4003 Src – 192.168.20.4:8080 192.168.20.1:80 192.168.20.2:4002 192.168.20.3:80 192.168.20.4:8080

Load Balancing

Load Balance Modes Static Dynamic Failure Mechanisms Round Robin Ratio Least Connections Fastest Observed Predictive Dynamic Ratio Minimum Active Members Fallback Host Static Dynamic Failure Mechanisms

Round Robin Clients Internet Router Client requests are distributed evenly BIG-IP Controller 1 2 3 4 Servers 5 6 7 8

Ratio Internet Clients Router Administrator sets ratio for distributing Client requests 3:1:1:1 BIG-IP Controller 1 5 6 2 3 4 Servers 7 11 12 8 9 10

Fastest Internet Clients Router Next requests go to member with fastest response time BIG-IP Controller 1 2 Servers 10ms 5ms 20ms 17ms Current Response Times

Least Connections Internet Clients Router Next requests goes to member with fewest number of connections BIG-IP Controller 1 2 Servers 462 460 455 465 Current Connections

Observed Clients Internet Router Next requests goes to member with combination of fewest connections and best response BIG-IP Controller 1 Servers 2

Predictive over time Clients Internet Router Next requests goes to member with combination of fewest connections and best response over time BIG-IP Controller 1 Servers 2

Priority Group Activation Clients Internet If you set Priority Group Activation to 2, and 3 of the highest priority members are available, then lower priority members will not be used. Router BIG-IP Controller Priority 2 Priority 1 1 2 3 Servers 4 5 6

Priority Group Activation Internet Clients If number of members falls below Priority Group Activation (2), then the next highest priority members are used also. Router BIG-IP Controller Priority 2 Priority 1 2 3 4 1 Servers 5 6 7 8

Fallback Host Internet Clients If all members fail, then client is sent an http redirect to the “fallback” server. Router BIG-IP Controller Servers

Pool Member vs. Node Load Balancing by: Pool Member IP Address & service Node Total services for one IP Address

If using Member Internet If http pool Uses Least Connections (member) load balancing method, then… Next http request goes to Pool Member with fewest http connections 1 2 25 3 2 ftp 99 102 100 http Current Connections

If using Node Internet Next http request goes to IP Address with fewest total connections 1 2 25 3 2 ftp 99 102 100 http Current Connections

Questions ? Given the conditions in the chart below, what Node will be selected for the next service request? The last five selections have been Nodes A, B, C, C, D. Load Balancing Least Connections Minimum Active Members 2 Persistence Mode None Member Identifier Node Address Ratio Member Ratio Member Priority Connections Response Time Status A 10.1.1.1:80 1 5 2 ms Up B 10.1.1.2:80 6 Disabled C 10.1.1.1:81 3 7 3 ms D 10.1.1.2:81 4 8 Down Answer: A

Health Monitors

Monitor concepts Address Check Service Check Content Check Node: IP Address Service Check IP: port Content Check IP: port plus check data returned Interactive Check Path Check

Address Check Steps Packets sent to IP Addresses Internet Steps Packets sent to IP Addresses If no response, then no traffic sent to associated Nodes Example - ICMP ICMP 192.168.20.1 192.168.20.2 192.168.20.3

Service Check Steps Opens TCP connection (IP Address : service)‏ Internet Steps Opens TCP connection (IP Address : service)‏ Connection closed If TCP connection fails, then no traffic sent to associated Nodes Example – TCP TCP Connection 192.168.20.1:80 192.168.20.2:80 192.168.20.3:80

Content Check Steps Opens TCP connection (IP Address : service)‏ Internet Steps Opens TCP connection (IP Address : service)‏ Sends a request Response returns data Connection closed If Receive Rule not found in data, then no traffic sent to associated Nodes Example – http http GET / 192.168.20.1:80 192.168.20.2:80 192.168.20.3:80

Interactive Check Steps Opens TCP connection (IP Address : service)‏ Internet Steps Opens TCP connection (IP Address : service)‏ Interactive conversation to simulate real-world Connection closed If expected results do not occur, then no traffic sent to associated Nodes Example – SQL request conversation 192.168.20.1:80 192.168.20.2:80 192.168.20.3:80

Path Check Steps Sends packet through, not to the device Internet Steps Sends packet through, not to the device Can check IP Address, Service or Content If condition not met, then no traffic sent through associated member ISP 2 ISP 1 Link Controler

Profiles

Profile concepts A profile is: Single place to define traffic behavior SSL, compression, persistence…. Apply behavior to multiple VS’s User defined built from template Dependent on other profiles

Profile Scenario #1 - Persistence 2 2 3 3

Profile Scenario #2 - SSL Termination Encrypted Decrypted

Persistence

Source Address Persistence Based on Client Source IP Address Netmask → Address Range 1 2 3 205.229.151.11 205.229.152.10 If Netmask is 255.255.255.0

Cookie Persistence Insert mode Rewrite mode Passive mode Hash mode BIG-IP Inserts a cookie into the stream Rewrite mode Web Server creates cookie and BIG-IP Controller changes it Passive mode Web Server creates cookie and BIG-IP Controller Reads it Hash mode Maps a cookie value to a specific node Web server must generate a cookie

Cookie Insert Mode First Hit Second Hit TCP handshake HTTP request (no cookie)‏ pick server TCP handshake HTTP request (no cookie)‏ HTTP reply (no cookie)‏ HTTP reply (with inserted cookie)‏ Client TCP handshake Server Second Hit HTTP request (with same cookie)‏ cookie specifies server Let’s look at insert mode cookie persistence in more detail: Client connects the first time: the web browser has yet to receive a cookie for this site. BIG-IP detects that no cookie is present, and forwards the connection to the most appropriate available node. The node issues its http reply to the client. BIG-IP inserts a cookie with the appropriate expiration value and specific node information. Client connects back a second time. This time the web browser inserts the cookie in its http request. BIG-IP reads the cookie, and forwards the connection to the specified server BIG-IP updates the expiration value in the cookie. The advantage of insert mode cookie persistence is that the web servers remain untouched. The drawback is that the BIG-IP controller has an increased workload. Note that the BIG-IP controller is unable to forward the incoming connection to the appropriate node until it receives the cookie. As such, it needs to perform the initial TCP handshake with the connecting client. Once the BIG-IP controller has received and read the cookie, it can determine which node to forward the connection on to. Again, the controller must perform the initial TCP handshake with the node. As such, the BIG-IP controller behaves very much like a proxy server. TCP handshake HTTP request (with same cookie)‏ HTTP reply (no cookie)‏ HTTP reply (updated cookie)‏

Cookie Rewrite Mode First Hit Second Hit TCP handshake HTTP request (no cookie)‏ pick server TCP handshake HTTP request (no cookie)‏ HTTP reply (with blank cookie)‏ HTTP reply (with rewritten cookie)‏ Client TCP handshake Server Second Hit HTTP request (with same cookie)‏ cookie specifies server Let’s look at rewrite mode cookie persistence in more detail: Client connects the first time: the web browser has yet to receive a cookie for this site. BIG-IP detects that no cookie is present, and forwards the connection to the most appropriate available node. The node issues its http reply to the client which includes a blank cookie. BIG-IP rewrites the cookie with the expiration value and node information. Client connects back a second time. This time the web browser inserts the cookie in its http request. BIG-IP reads the cookie, and forwards the connection to the specified server The node issues its http reply to the client, and again includes a blank cookie in its reply. The advantage of rewrite mode cookie persistence is that it somewhat reduces the workload on the BIG-IP controller. Also, the content servers can still have the same configuration, since they generate identical cookies. The drawback is that each server needs to be modified to generate the cookie, and the BIG- IP controller still needs to rewrite the cookies. TCP handshake HTTP request (with same cookie)‏ HTTP reply (with blank cookie)‏ HTTP reply (with updated cookie)‏

Cookie Passive Mode First Hit Second Hit TCP handshake HTTP request (no cookie)‏ pick server TCP handshake HTTP request (no cookie)‏ HTTP reply (with special cookie)‏ HTTP reply (with special cookie)‏ Client TCP handshake Server Second Hit HTTP request (with same cookie)‏ cookie specifies server TCP handshake Let’s look at passive mode cookie persistence in more detail: Client connects the first time: the web browser has yet to receive a cookie for this site. BIG-IP detects that no cookie is present, and forwards the connection to the most appropriate available node. The node issues its http reply to the client which includes a cookie with the expiration value and its node information. BIG-IP leaves the cookie untouched. Client connects back a second time. This time the web browser inserts the cookie in its http request. BIG-IP reads the cookie, and forwards the connection to the specified server The advantage of passive mode cookie persistence is that it reduces the workload on the BIG-IP controller. The drawback is that each content server needs to be configured to generate a specific cookie. HTTP request (with same cookie)‏ HTTP reply (with special cookie)‏ HTTP reply (with special cookie)‏

Cookie Hash Mode First Hit Second Hit Third Hit TCP handshake HTTP request (no cookie)‏ pick server TCP handshake Server HTTP request (no cookie)‏ HTTP reply (with cookie)‏ HTTP reply (with cookie)‏ Second Hit TCP handshake cookie hash specifies server HTTP request (with same cookie)‏ Client TCP handshake HTTP request (with same cookie)‏ HTTP reply (with cookie)‏ HTTP reply (with cookie)‏ Server Let’s look at passive mode cookie persistence in more detail: Client connects the first time: the web browser has yet to receive a cookie for this site. BIG-IP detects that no cookie is present, and forwards the connection to the most appropriate available node. The node issues its http reply to the client which includes a cookie with the expiration value and its node information. BIG-IP leaves the cookie untouched. Client connects back a second time. This time the web browser inserts the cookie in its http request. BIG-IP reads the cookie, and forwards the connection to the specified server The advantage of passive mode cookie persistence is that it reduces the workload on the BIG-IP controller. The drawback is that each content server needs to be configured to generate a specific cookie. Third Hit TCP handshake cookie hash specifies server HTTP request (with same cookie)‏ TCP handshake HTTP request (with same cookie)‏ HTTP reply (with cookie)‏ HTTP reply (with cookie)‏

Questions ? A connection is made to the Virtual Server at 150.150.10.10:80 associated with the pool below. The last five connections have been C, D, C, D, C. Given the conditions on the charts below, if a client at IP address 205.68.17.12 connects, what node will be selected for this service request? Load Balancing Fastest Minimum Active Members 2 Member Identifier Node Address Ratio Member Ratio Member Priority Connections Response Time Status A 10.1.1.1:80 1 5 3 ms Up B 10.1.1.2:80 6 2 ms Disabled C 10.1.1.1:81 3 7 D 10.1.1.2:81 4 Down Persistence Mode Simple Timeout = 600, Mask = 255.255.255.0 Client Address Virtual Path Pool Name Member Node Alive Time 200.11.225.0 150.150.10.10 WebPool 10.1.1.1:80 300 200.11.15.0 10.1.1.2:80 500 205.68.17.0 10.1.1.1:81 200 Answer: C

SSL Termination

SSL Concepts Encrypted at each end Certificates & Keys SSL Accelerator Cards Processing work of encryption / decryption done by card Takes load off Server Network Packet Encrypted

SSL Termination Encrypted Decrypted

SSL Termination Advantages SSL key exchange done by hardware SSL bulk encryption done by hardware Centralize certificate management Offload SSL traffic from Web Servers Allows rue processing & cookie persistemce

Traffic Flow through BIG-IP Client sends Encrypted packet BIG-IP takes packet off Network and Decrypts VS load balances to Nodes Response packet is Re-encrypted before external Network Internet

Client SSL Plus Server SSL Encrypted Decrypted inside BIG-IP Encrypted

Server SSL Cookie @#*<5+ Cookie &)$?>{ Cookie Client types something Encrypted Data is encrypted before putting on network @#*<5+ Data is unencrypted inside BIG-IP after taken off network Cookie Decrypted &)$?>{ Data is encrypted before putting on internal network Encrypted Data is unencrypted by Server after taken off network Cookie

NATs & SNATs

NAT One-to-one mapping Bi-directional traffic Dedicated IP address Configuration: Internet 207.10.1.103 192.168.20.3

SNAT Many-to-one mapping Traffic to SNAT Address is refused Internet Many-to-one mapping Traffic to SNAT Address is refused Can share IP with Virtual Server 207.10.1.102 192.168.20.1 192.168.20.2 192.168.20.3

SNAT Configuration Who can be changed Changed to what Where packet arrived from Internet 172.16.2.201 172.16.1.25 172.16.1.26 172.16.1.27

Traffic Flow – Big Picture Transparent Virtual Server Virtual Server NAT SNAT Next, IP Forwarding Client side Address not Translated Address Translation Node side

Redundant Pair

BIG-IP Redundant Pair Internet Console External IP External IP Shared Alias 10.10.X.33 Internal IP 192.168.X.31 Failover 192.168.X.32 Internal IP 192.168.X.32 Failover 192.168.X.31 Shared Alias 192.168.X.33

High Availability

Automatic Failover Standby Active Standby Active

iRules

iRule Example 1 when CLIENT_ACCEPTED { if { [IP::addr [IP::client_addr] equals 192.168.3.1] } { pool lab3_pool1 } else { pool lab3_pool2 }

iRule Example 2 when CLIENT_ACCEPTED { if { [IP::addr [IP::remote_addr] equals 206.0.0.0/255.0.0.0] }{ pool clients_from_206 } else { pool other_clients_pool

Q & A Thank you!!