Distil Networks & F5 Networks Integration Guide

Transcription

1 INTEGRATIONGUIDE Distil Networks & F5 Networks Integration Guide (w) (e) (US) (UK)

2 Table of Contents INTRODUCTION 3 F5 LTM 4 Testing irule - HTTP Header-Based 4 Onboarding irule - Percentage Allocation 5 Production irule - Full Allocation 7 irule location 8 Health Checking 9 SSL Offload 10 Maintain Persistence Information for Keep-Alive Connections 11 2

3 Introduction The following sample F5 LTM configurations are provided as a very simple guide. While the specific irules you implement may vary based on your unique environment and/or other business rules, the basic logic still applies. The objective for implementing the rules below is to send traffic to Distil if it has not already gone through our system. This logic needs to be placed before any other so as to avoid a situation where your entire traffic for a given domain does not go through the Distil instances. For more information on the load balancer integration methodology, please see the Distil Networks Load Balancer Integration Guide. 3

4 F5 LTM The F5 LTM has the ability to select different backend resource pools based on the logic within irules. The following section outlines specific irules for testing, onboarding, and full production. TESTING irule - HTTP HEADER-BASED Distil recommends this method of testing and validation only on a cloned VIP, as it does incur a small but negligible performance impact to both test and production traffic. But it is useful in cases where it s not possible to provision additional external addresses and firewall NAT to support the cloned VIP testing approach. The following irule (Example irule 1) is in the "when HTTP_REQUEST" context, as it requires layer 7 inspection of all HTTP requests. It should be placed at the top of the irule stack on the testing VIP. Example irule 1 when HTTP_REQUEST { #if Distil is the layer 3 source IP, then exit out of the irule switch [IP::client_addr] { " " - " " { return #Distil Pool Selection if Distil. If Distil is up send traffic to Distil if { ( [active_members distil-support-pool] > 0) and ([ exists "DISTILQA"]) { pool distil-support-pool event disable all 4

5 F5 LTM Testing irule - HTTP Header-Based The first stanza of irule 1 (switch) looks at the source address, and then sends all requests that have been seen by Distil (that is, have a Distil client_addr) to your existing irules so as to follow your existing logic. The return action exits and continues with your existing irules. The second stanza (default) checks that Distil has at least one member available and that the specified HTTP header is present. If both conditions are true, the request is sent to Distil. As with the general production rule, if less than one Distil pool member is available, the request is further evaluated using your existing irules. The second stanza is only executed if the source address is not a Distil client_addr. Requests that do not contain the specified header are not sent to Distil. ONBOARDING irule - PERCENTAGE ALLOCATION After functional and performance testing is complete, and when moving to a full production setup, some customers use percent-based allocation to incrementally allocate traffic to the Distil pool. This is accomplished using F5 ratio-based load balancing. The following irule (Example irule 2) is similar to the production irule, but leverages the F5 rand() function to manage the traffic allocation and looks for Distil-specific URI paths. 5

6 F5 LTM Onboarding irule - Percentage Allocation Example irule 2 when HTTP_REQUEST { #if Distil is the layer 3 source IP, then exit out of the irule switch [IP::client_addr] { " " - " " { return #Distil Pool Selection if Distil. If Distil is up send traffic to Distil if { ( ([active_members distil-support-pool] > 0) and (rand() < 0.5) ) or ( [string tolower [ starts_with "/dstlinjection") or ( [string tolower [ starts_with "/distil") { pool distil-support-pool event disable all The first stanza of irule 2 (switch) looks at the source address and sends all requests that have been seen by Distil (that is, have a Distil client_addr) to your existing irules so as to follow your existing logic. The return action exits and continues with your existing irules. The second stanza (default) checks to make sure that Distil has at least one member available and, if so, sends a percentage of requests to Distil. The percentage is achieved by using the F5 rand() function and can be set to any value between 0 and 1 in increments of hundredths. As with the general production rule, if less than one Distil pool member is available, the request is instead further evaluated using your existing irules. The second stanza is only executed if the source address is not a Distil client_addr. 6

7 F5 LTM Onboarding irule - Percentage Allocation Notably, using irule 2 generates invalid data on bot traffic, as determined by Distil. Additional techniques may be used to mitigate this. For example, you can move this rule to the HTTP_REQUEST context and then check for the presence of Distil cookies to pin those users to the Distil pool. However, this deviates from the intended percent allocation. PRODUCTION irule - FULL ALLOCATION After functional and performance testing is complete, and when moving to a full production setup, apply the following irule (Example irule 3) to the production VIP. Example irule 3 when CLIENT_ACCEPTED { #if Distil is the layer 3 source IP, then exit out of the irule switch [IP::client_addr] { " " - " " { return default { #Distil Pool Selection. If Distil is up send traffic to Distil. Stops the execution of any other irules. if { ( [active_members distil-support-pool] > 0 ) { pool distil-support-pool event disable all 7

8 F5 LTM Production irule - Full Allocation The first stanza of irule 3 (switch) looks at the source address and sends all requests that have been seen by Distil (that is, have a Distil client_addr) to your existing irules so as to follow your existing logic. The return action exits and continues with your existing irules. The second stanza (default) checks that Distil has at least one member available, and if so, sends all requests to our service. If less than one Distil pool member is available, then the request is further evaluated using your existing irules. The second stanza is only executed if the source address is not a Distil client_addr. This irule operates in the "when CLIENT_ACCEPTED" context (TCP layer) and ensures the highest level of performance, as the decisions are made without evaluating the HTTP request (layer 7). This rule is suitable for performance testing the Distil deployment as a baseline against existing production. irule Location Using this cloned VIP method also requires that a new external address be assigned and a firewall NAT be configured, mapping this new external address to the cloned virtual server. Testing is accomplished using standard DNS override techniques. 8

9 HEALTH CHECKING For health checking Distil instances, the F5 should send an HTTP request to the path /distil_ok.html. Distil instances reply with the string OK. Below is a screen capture of the configuration. CLI Configuration ltm monitor http distil-monitor-distil_ok { defaults-from http destination *:* interval 5 ip-dscp 0 recv OK send "GET /distil_ok.html \r\n" time-until-up 0 timeout 16 9

10 SSL OFFLOAD AND CLIENT IP PRESERVATION When offloading SSL, F5 may be configured to add a specific HTTP header/value combination to indicate that the request was received encrypted. This header may be X-Forwarded-Proto or it may be customized in F5. The F5 can also be used to inject the client IP into the HTTP header X-Forwarded-For. The information in X-Forwarded-For will be used to identify the client s IP address since the F5 will present the SNAT IP at layer 3. The following F5 HTTP Profile is used to set the X-Forwarded-Proto header to the value of https. The F5 will also insert the Layer 3 client IP into the Header X-Forwarded-For. (As a note, there is a known typo in the F5 configuration. This is fixed in later versions of F5) ltm profile http https-distil-profile { app-service none defaults-from http header-insert "X-Forwarded-Proto: https" insert-xforwarded-for enabled proxy-type reverse When Distil receives inbound SSL traffic and proxies the traffic to the origin as SSL, Distil also proxy the headers by default. If necessary, Distil may remove the offload header (if present) to avoid a redirection loop or HTTP header spoofing. 10

11 MAINTAIN PERSISTENCE INFORMATION FOR KEEP-ALIVE CONNECTIONS For customers having cloud or on-premise deployments leveraging F5 and cookie-based persistence, F5 may appear to ignore persistence information for Keep-Alive connections. With Distil s upstream behavior, browsers connect to F5 before connecting to the origin server. When the browser makes the initial connection to F5, the TCP connection is different from another client's TCP connection. When the request hits Distil and we have nginx upstream multiplexing enabled, many HTTP requests are on the same TCP stream. To correct this behavior, please refer to F5 s knowledge base article, The BIG-IP system may appear to ignore persistence information for Keep-Alive connections. Contact Distil Support if there are any questions on the Distil behavior or your F5 support for questions on the F5 modification. 11