LTM essentials


Published on

Published in: Technology

LTM essentials

  1. 1. Chapter 1 Initial Setup Exploring Big-IP Hardware Exploring Big-IP File System Licensing Big-IP Basic Configuration
  2. 2. Big-IP Hardware Platform
  3. 3. The Hardware Console Cable OOB Management Port 10/100/1000 Mbps Copper Ports 1000 Mbps Fibre Ports Failover USB Port Cable LCD Panel and controls
  4. 4. Looking Inside a 3600Big-IP
  5. 5. Big-IP LTM Software support
  6. 6. Lights Out Management -Two operating systems -TMM for primary use -AOM/SCCP for lights Out management -Always on Mansgment -Switch card control processing
  7. 7. What to do first ?
  8. 8. Setup Overview
  9. 9. Setup Tools  SSH Client -username:- root -Password:-default  Serial Terminal Client -username:- root -Password:-default  Big-IP Config Script -config  Big-IP Wab-based configuration -username:- admin -Password:-admin
  10. 10. Licensing Methods
  11. 11. Entering Registration Key
  12. 12. Manual Licensing
  13. 13. Completing the Licensing Process
  14. 14. Configuring administration Access
  15. 15. File System  Built on top Linux  Has Linux files structure  Files are relevant to the operation  Main file in BIG-IP LTM are mentioned below: -/coinfig/bigip.conf -/config/bigip_base.conf -/config/BigDB.dat -/etc/hosts.allow -/config/bigip.license -/var/log/ltm
  16. 16.  /coinfig/bigip.conf - Holds all information relevant to the load balancing Like: virtual, pool, profile, monitor, irules etc -Shared between 2 units if in a pair configuration  /config/bigip_base.conf -Holds all information relevant to the basic elements of the BigIP Like: management IP, vlans, routes few more things  /etc/hosts.allow -hosts which are allowed to use the local INET services. Such as services are SSH, snmp for the snmp devices
  17. 17.  /config/BigDB.dat -bigdb database holds a set of bigdb configuration keys -Keys define the behaviours of various aspects of the BIG-IP system -For example, the bigdb key Failover.Active Mode, when set to enable, causes a redundant system to operate in active-active mode, instead of the default active/standby mode. -We can edit these values by using -The Configuration utility -The bigpipe db command #bigpipe db all list
  18. 18.  /config/bigip.license -Holds all information about the license of the BigIP system -Without this file or a valid license file, the BigIP will not operate  There are few more vital files /config/ssl/ssl.crt /config/ssl/ssl.key
  19. 19. Management configuration  Giving IP to management port #b mgmt {netmask }  Putting route for management network #b mgmt route netmask ‘{ gateway }’ #b mgmt route netmask ‘{ gateway }’
  20. 20. VLAN Configuration vlan external { tag 10 interfaces 1.1 } vlan internal_phy { tag 4093 interfaces 1.2 } vlan internal_virt { tag 4092 interfaces 1.4 }
  21. 21. Self IP/Port configuration  Assigning IP address the to vlan #b self ‘{ netmask vlan external allow tcp ssh tcp https tcp 4353 }’ #b self ‘{ netmask vlan internal_virt allow tcp https }’  Opening the Port #b self allow ‘{ default udp snmp tcp ssh tcp domain tcp snmp udp efs tcp 4353 udp domain udp 4353 tcp https proto ospf }’
  22. 22. Configuring Floating  This part of configuration is for redundant pair #b self { netmask unit 1 floating enable vlan external allow tcp https } #b self { netmask unit 1 floating enable vlan internal allow default }
  23. 23. Chapter 2 Traffic Processing
  24. 24. Pools , Members & Nodes
  25. 25. Virtual Server -Big-IP is default deny device, so listener (virtual) is must -Virtual server gules everything together -Typically virtual are associated with pool
  26. 26. -Before virtual server can load balance it should mapped to pool -Big-IP translate the destination ip address from virtual server to actual server -Client see the pool servers as single server, hence the term Virtual Server
  27. 27. Asymetric Routing Problem
  28. 28. Full Proxy Architecture -Big-IP do much more than translating the network Address -F5 implemented full proxy architecture in Big-IP -Separate tcp connections for the client & the server
  29. 29. Chapter 3 Load Balancing Load Balancing Method Member vs Node Priority Group Activation Configuring load balancing
  30. 30. Load Balancing Methods -Static method do not take server performance in to consideration -Dynamic method does consider server performance
  31. 31. Round Robin -Round Robin is default & most commonly used method -Big-IP evenly distributes client request across all available pool member
  32. 32. Ratio -Ratio method is appropriate to use if some of the members are powerful than other. -Since Ratio is static method, this means that server with highest ratio value will receive more request then others even if the performance of the server is slow. #b pool lab_Pool { lb method member/node ratio }
  33. 33. Least Connections -This method consider the current connections count to decide where to send next request #b pool lab_Pool { lb method least conn }
  34. 34. Least Connections -After connections counts shown below, the big-IP round robin next requests between all three servers.
  35. 35. Fastest -Fastest uses the outstanding layer 7 request to decide where to send the next request -Request or Response ? #b pool lab_Pool { lb method fastest }
  36. 36. Fastest -Ping response form server doesn’t take into account how fast server will response at port 80. -SYN-ACK response form server at port 80 doesn’t take into account how fast backend database server will populate the content of web page
  37. 37. Observed -It is basically Ratio load balancing but with Ratio assigned by BigIP -Servers with connections lower than average will given ratio of 3 -Servers with connections higher than average will given ratio of 2 #b pool lab_Pool { lb method member observed }
  38. 38. Observed >Connections status -server B & C with Ratio 3 -Servers A & D with Ration 2
  39. 39. Predictive -Predictive method is similar to Observed, but assigns more aggressive value #b pool lab_Pool { lb method member predictive }
  40. 40. Predictive >Connections status -server A & C with Ratio 1 -Servers B & D with Ration 4
  41. 41. Pool Member vs. Node  Load Balancing by: >Node -Total service for one IP Address -Take all transactions for the IP address into account #b node <ip_addr> { ratio <no.>/ session <enable/disable>} >Pool Member -IP Address & Service -Take the decision based transactions happening on the service port.
  42. 42. Priority Group Activation -Use to designate preferred & backup sets of pool members with in a pool -Once priority group activated -The available member with highest priority will consider first
  43. 43. Priority Group Activation -If the number of member falls below the priority group activation set, -The next highest priority member also start serving the requests.
  44. 44. Priority Group Activation Configuration example #b pool lab_pool '{ lb_method predictive min_active_members 2 member member member member member member priority priority priority priority priority priority 10 10 10 5 5 5 }’
  45. 45. Fallback Host -Fallback host feature is designed for HTTP protocol only. -It comes into play if all the members in a pool are unavailable
  46. 46. Configuring Load Balancing bigpipe pool <pool_name> { lb method <method_name> } (rr | node ratio | member ratio | member least conn | member observed | member predictive | fastest | least conn | predictive | observed | dynamic ratio | fastest app resp)
  47. 47. Chapter 4 Monitor Monitor Functionality Monitor Types Configuring Monitor Assigning Monitor Status
  48. 48. Intro to monitor  Big-IP system can monitor the health of nodes & member  Monitor is the test that Big-IP performed -simple test -Highly interactive test  The result of these test will define the status of respective node or member is available  Big-IP perform continues monitoring irrespective of the status of node or member
  49. 49. Step to set-up a monitor Step 1: Create Step 2: Name & Type -name the new monitor select the type from system templates Step 3: Customize Step 4: Assign - to pool/node/pool member Step 5: Status
  50. 50. Types of monitoring  Address Check -IP address –node  Service Check -IP:port  Content Check -IP:port & check data returned  Interactive Check -Interactive with servers -Multiple commands and multiple response
  51. 51. Address Check
  52. 52. Example  System  Custom #b monitor icmp list monitorroot icmp { interval 5 timeout 16 dest * } #b monitor icmp_mon list monitor icmp_mon { defaults from icmp interval 7 timeout 22 }
  53. 53. Service Check -Service checks only test whether server is listening to respective port. -Doesn’t provide any insight into quality of the content that might return
  54. 54. Example  System  Custom #b monitor tcp list #b monitor tcp_port_mon list monitor tcp_port_mon { defaults from tcp interval 15 timeout 47 } monitorroot tcp { interval 5 timeout 16 dest *:* recv "" send "" }
  55. 55. Content Check -Content check go beyond testing whether a node is responding/listening -It also test if it is responding with correct content
  56. 56. Example System: #b monitor http list monitorroot http { interval 5 timeout 16 dest *:* password "" recv "" send "GET /" username "" } Custom: #b monitor http_mon list monitor http_mon { defaults from http recv "Health Check" send "GET /health_check.html HTTP/1.0nn" }
  57. 57. Interactive Check
  58. 58. Example #b monitor ftp list monitorroot ftp { interval 10 timeout 31 dest *:* debug "" get "" mode "passive" password "" username "" }
  59. 59. Assigning Monitor to Nodes #b node ‘{ ratio 100 monitor testwmi_mon }’ #b node { monitor gateway_icmp and icmp }
  60. 60. Assign Monitor to Pool & member  Assigning Monitor to Pool #b pool bluecoat_pool { monitor all tcp } #b pool bsd01_pool { monitor all bsd_mon }  Assigning Monitor to Pool member #b pool lab_Pool '{ member monitor tcp member monitor http }‘
  61. 61. Status Icon  Below are the status Icons
  62. 62. Status: Available  Example-1  Example-2
  63. 63. Status: Offline  Example-1  Example-2
  64. 64. Status: Unknown  Example-1  Example-2
  65. 65. Status: Unavailable  Example -1  Example -2
  66. 66. Chapter 5 Profile Profile Concept Profile Configuration
  67. 67. Profile Concept  Contain settings that instruct how to pass the traffic through virtual server  Why any one want to change default traffic processing behavior of virtual server ?  Are profile overrides the load balancing property ?  How does profile help to improve the performance of actual servers ?
  68. 68. Profile Example  Persistence  SSL Termination
  69. 69. Profile Example  FTP
  70. 70. Profile Dependencies -Some of the profiles are dependent on others -Some can’t be combine in one VS
  71. 71. Types of profile  Services Profiles: -HTTP, FTP, RSTP, SIP, iSession  Persistence Profiles -cookie, dest_addr, source_addr, hash….  Protocol Profiles -tcp, udp, fastL4…  SSl Profiles -client, server  Authentications Profiles -RADIUS servers, CRLDP servers…  Other Profiles -OneConnect, NTLM, stream
  72. 72. Profile Configuration Concepts  Default Profiles – Tamplates -Stored in /config/profile_base.conf -Can’t be deleted  Custom Profiles -Stored in /config/bigip.conf -Created from default profile -Dynamic child & parent relationship
  73. 73. Services Profiles  Parent HTTP profiles profile http http { basic auth realm none oneconnect transformations enable compress disable compress uri include none compress uri exclude none compress prefer gzip compress min size 1024 compress buffer size 4096 compress vary header enable . . . ramcache max age 3600 ramcache min object size 500 ramcache max object size 50000 ramcache uri exclude none ramcache uri include none ramcache uri pinned none ramcache ignore client cache control all ramcache aging rate 9 ramcache insert age header enable }  Custom HTTP profile #b profile http pan_http_profile ‘{ defaults from http_master header insert "X-SSL: True" fallback "[HTTP::host]" }’ #b profile http help ---for more option
  74. 74. Chapter 6 Persistence Persistence profile Source Address Persistence Cookie Persistence
  75. 75. Concept  What is the need of Persistence ?  Persistence profile is required to achieve to change the load balancing behavior of virtual server  Upon the initial connection: -Big-IP store session data in persistence record  Persistence Record store -client characteristics -Pool member information which is serving request  Big-IP use persistence record to serve the next traffic
  76. 76. Source Address Persistence -Support both TCP & UDP protocol -By Default Big-IP create persistence for host
  77. 77. source_addr Persistence configuration  Parent Profile: profile persist source_addr { mode source addr mirror disable timeout 180 mask none map proxies enable rule none }  Custom Profile #b profile persist pan_subnet ‘{ mode source addr mask }’
  78. 78. Cookie Persistence  Why cookie Persistence ?  Modes: >Insert Mode -LTM insert special cookie in HTTP response -Pool name & Pool Member (encoded) >Rewrite Mode -Web server Creates a “blank” cookie -LTM Rewrites to make Special Cookie >Passive Mode -Web server Creates Special Cookie -LTM Passively lets it through
  79. 79. Cookie Insert Mode
  80. 80. Cookie Rewrite Mode
  81. 81. Cookie Passive Mode
  82. 82. Configuring Cookie persistence  Custom Profile #b profile persist pan_cookie { mode cookie cookie mode rewrite cookie name paa }  Parent Profile: profile persist cookie { mode cookie mirror disable timeout immediate cookie mode insert cookie name none cookie expiration 0d 00:00:00 cookie hash offset 0 cookie hash length 0 rule none }
  83. 83. Chapter 7 Processing SSL Traffic Exploring SSL on Big-IP Configuring Big-IP for SSL
  84. 84. Review of SSL Concepts  Establish an encrypted link between a Web server &     browser by using SSL protocol This encryption uses PKI Encrypting & decrypting SSL is impact the server performance Packet processing time can increase 20 to 30 times Use of SSL Accelerator Cards
  85. 85. Advantage of SSL Termination  Allow iRules processing and cookie persistence  Offload SSL traffic from web server  SSL key exchange and bulk encryption dane by hardware  Centralize certificate management
  86. 86. Traffic Flow: Client SSL
  87. 87. Traffic Flow: Server SSL
  88. 88. SSL Acceleration
  89. 89. Enabling Client SSL Profile
  90. 90. Configuring Client SSL Profile  Configuring clientssl profile : #b profile clientssl pan.com_ssl { defaults from clientssl key “" cert “" chain “ca-intermediate.crt" }  Associating the clientssl profile to virtual server #b virtual pan.com_https { profile pan.com_ssl }
  91. 91. Configuring Server SSL Profile  Configuring Serverssl profile : #b profile serverssl pan.com_ssl ‘{ defaults from serverssl"  Associating the clientssl profile to virtual server #b virtual pan.com_https { profile pan.com_ssl }
  92. 92. Chapter 8 Nat & SNAT NAT Concepts and Configuration SNAT Concepts and Configuration
  93. 93. Nat Concepts  One to One mapping  Bi-directional traffic  Dedicated IP Address  Can’t Configure port
  94. 94. Configuring NAT #b #b #b #b nat nat nat nat to to list show
  95. 95. SNAT Concept  “Secure” NAT  Performs Source Nat  Many to one mapping  Traffic initiated to SNAT Address refused  SNAT’s used for Routing problem
  96. 96. SNAT Configuration #b snat pan { origin any translation } # b snat pan ‘{ origin any translation vlan clau_vlan enable }’ #b snatpool pan_spool ‘{ member member }’ #b snat pan ‘{ origin mask snatpool pan_spool }’
  97. 97. Chapter 10 Virtual
  98. 98. Virtual  Big-IP is default deny device, so listener (virtual) is must  Virtual server gules everything together  Virtual are first point of call for traffic
  99. 99. Types of VIP  Standard  Most common type of VIP for general purpose load balancing  Can make use of all functions including iRules, WebAccelerator, ASM etc  Forwarding (Layer 2)  Generally used when LTM is configured in a bridge mode (VLAN Groups)  Essentially just forwards packets at Layer 2  Forwarding (IP)  Used when LTM needs to forward or route packets  Can either just route them based on it’s IP routing table of load balance multiple routers/firewalls etc  Performance (HTTP)  Used for very simple, very fast HTTP load balancing  Loose a number of features (see next slide)  Performance (Layer 4)  Used for general purpose fast load balancing of packets using the PVA ASIC  Loose a number of features depending on PVA Acceleration mode (see next few slides)
  100. 100. Configuration of virtual >Forwarding (IP) #b virtual forward_vip { destination any:any ip forward } >Forwarding (Layer 2) #b virtual forward_vip { destination any:any l2 forward } >Standard b virtual accel_vip ‘{ destination ip protocol tcp profile http_profile oneconnect_master tcp persist simple_1800_profile pool https_pool }’
  101. 101. Chapter 11 iRule
  102. 102. What is an iRule?  An iRule is a TCL script to give more control over how traffic is processed via the LTM  Can do this based on just about anything found in a packet, including client IP address, headers, URI, destination port, etc.  The use of the Universal Inspection Engine (UIE) is also done via iRules, allowing for rule based persistence
  103. 103. What can an iRule work with?      Most commonly seen are HTTP events Can also work with other protocols, such as SIP, RTSP, XML, others Can make adjustments to TCP behavior, such as MSS, checking the RTT, looking into the payload Can work with authentication or encryption, via x509 commands, and AES encryption/decryption Cache, compression, profiles are also available
  104. 104. Example iRules Change server headers when HTTP_RESPONSE { HTTP::header replace Server "Microsoft-IIS/5.1" } Remove all server headers when HTTP_RESPONSE { HTTP::header sanitize ?ETag? ?Header01? ?Header02? } On 404 error, re-load balance when HTTP_REQUEST { set RequestedPage [HTTP::uri] } when HTTP_RESPONSE { if { [HTTP::status] eq "404" } { log "Dooh, page '$RequestedPage' not found on server [IP::server_addr]!" HTTP::redirect $RequestedPage } }
  105. 105. More Samples… (from CodeShare)
  106. 106. iRule Logging (really handy!)  You can turn on logging for any iRule and record anything you like from requests or responses!  Often used when troubleshooting an iRule  Simply add the line “log xxx” (where “xxx” is anything you like) to any iRule, for example: when HTTP_REQUEST { log "Client [IP::remote_addr] has requested page [HTTP::uri] from server [HTTP::host]." }  You can use the CLI command “tail –f /var/log/ltm” to view these logs in real time
  107. 107. Troubleshooting Section         File System Overview and Vi UCS file extracting Qkview Look at the Statistics! CLI Tools Logs Running TCPDUMP and SSLDUMP PXE booting tips
  108. 108. File System Overview  Main VIP, Pool and iRule config is stored in: /config/bigip.conf  Main IP and VLAN settings are stored in: /config/bigip_base.conf  BIG-IP license file is stored in: /config/bigip.license  Log files are stored in: /var/log/  Archived configs are stored in: /var/local/ucs/
  109. 109. Tools/Commands to help  Change directory:  Print working directory:  List directory contents:  View file:  Edit file:  Copy file:  Delete file: cd pwd ls more <filename> vi <filename> cp <source> <dest> rm <filename>
  110. 110. Useful “vi” commands  “i” to start inserting text where the cursor is  “A” to start inserting text at the end of the line  “Esc” exits the editing mode  “dd” delete entire line  “x” delete single character  “Esc” then “:” then “w” to write the file  “Esc” then “:” then “q” to quit vi  “/” starts a search through the file Note: “:wq” would write the file and quit in one go Note: “:w!” would write the file even if read-only file Note: “:q!” would force vi to quit
  111. 111. UCS file extracting  UCS files are simply “.tar.gz” files with a number of configuration files inside  Rename the file with a “.tar.gz” extension and use WinRAR to extract the file  Note that a UCS file contains both the “root” password and license key for that unit – don’t put it on another box unless you have a backup!
  112. 112. “Qkview”  Support will often request these  Can be executed from the GUI or CLI  Contains box configuration, route information, statistics etc
  113. 113. Logs  Logs can often highlight problems  Can be viewed from the GUI  Can be downloaded from the directory “/var/log”  Useful command to watch the LTM log file in real time from the CLI: tail –f /var/log/ltm
  114. 114. CLI Tools  “bigtop” – utility for a quick look at how the BIG-IP is functioning. Provides statistics and information on traffic flow, node operations and troubleshooting (“bigtop –delay 2” useful)
  115. 115. Running TCPDUMP  TCPDUMP is an inbuilt network sniffer  To run TCPDUMP from the CLI and save the output to a file that can be opened in Ethereal/Wireshark use the following command: tcpdump -ni <VLAN> -v -s 1600 -w /var/tmp/filename.dmp Example: tcpdump -ni external -v -s 1600 -w /var/tmp/external.dmp  TIP: Use WinSCP to copy the file from the BIG-IP to your PC  TCPDUMP can be run from the GUI also
  116. 116. Running SSLDUMP  SSLDUMP is a utility available on the BIG-IP that can be used to decode your SSL sessions by pre-loading your SSL keys and using those to convert the session data into ASCII text.  SSLDUMP takes a raw TCPDUMP file as input  To display the handshake only  ssldump –r <capture file>  To display the actual application data (with the key file)  ssldump –r <capture file> -k <key file> -d  Example: ssldump -r /var/tmp/internal.dmp -k /config/ssl/ssl.key/default.key -d > /var/tmp/ssldump.dmp  Documentation for ssldump can be found on
  117. 117. Useful links… F5 related  Compression Test   Devcentral (iRules, iControl, SDK)   Software Downloads   Askf5 (manuals, software, solutions, EOL info) 
  118. 118. Chapter 12 Redundant Pair Redundant pair Concept Redundant Pair Setup Config. Synchronization
  119. 119. Concept..  When is high Availability is required ? Increases Reliability It consist of two identically configured Big-IP system  There are two basic aspect: Synchronizing configurations between two BIG-IP units Configuring fail-safe settings for the VLANs
  120. 120. Big-ip Individual System Settings Big-IP LTM System -1 Big-IP LTM System -2 Hostname:- Admin Password:- XXXXX Unit ID:- 1 Internal VLAN -Self: -Float : -Peer : Hostname:- Admin Password:- XXXXX Unit ID:- 2 Internal VLAN -Self: -Float : -Peer :
  121. 121.  Unit ID used for Identification, do not designate primary and secondary
  122. 122.  Floating IP is always own by Active box
  123. 123. Failing Over >Gratuitous ARP sent to all neighboring network devices
  124. 124. Synchronize Configuration  Initiated from Either System  Redundant pair should service the same monitors, pools & virtual Servers
  125. 125. Synchronization condition  Administrative password must be same on each system  Port 443 must not be blocked by the port lockdown setting or by another system between the redundant pair.  Clock of the system must be within a certain number of minutes of each other.  Pull or Push Operation –Sync in Correct Direction
  126. 126. Synchronization Process 1-Create UCS file. -Which contain all configurations + licensing information 2-Send to peer 3-Peer creates backup of itself 4-Peer opens UCS file a) Matching Hostname > Full Installation b) Different Hostname >Shared Installation
  127. 127. Synchronize to Peer # bigpipe config sync pull # bigpipe config sync all
  128. 128. Determine Active System
  129. 129. Change to Standby Mode
  130. 130. Chapter 13 High Availability Failover Trigger Failover Detection Stateful Failover MAC Masquerading
  131. 131. Failover Managers  Failover Mangers detects a failed process,  takes one of the several action restarting the process, failing back to the standby, reboot the bigip  Watchdog Performs hardware health checks  Overdog Software to correct hardware failures  SOD monitors the switch fabric and takes corrective action for switch failures All failover Managers update and monitor the high Availability Table
  132. 132. High Availability Table  Update & Monitor by Failover Managers  Table Fields -Feature Name -Action on Failure -Enabled -Failed State  Command Line: b ha table show
  133. 133. HA Table
  134. 134. Failover Trigger  Processes (Daemons)  Switchboard  VLAN Failsafe  Gateway Failsafe
  135. 135. Failover Triggers - Daemans
  136. 136. VLAN Failsafe  Detects no network traffic Tries to generate traffic  Timeout reached Time Action; Standby becomes active
  137. 137. Gateway Failsafe
  138. 138. Hardware Failover  Standby notices a loss of voltage, it Takes over the active role
  139. 139. Network Failover  Heartbeat sent over network  No 50 foot (15.24 meter) limitation  Slower than Hardware Failover  Setting not synchronized between peers  If Both Hardware Failover & Network Failover are being used…..
  140. 140. Network Failover Settings
  141. 141. Network Communication
  142. 142. Stateful Failover
  143. 143. Types of Mirroring
  144. 144. Failover without MAC Masquerading
  145. 145. MAC Masquerading
  146. 146. MAC Masquerading
  147. 147. Thanks