Question about source persistence across traffic group
Hello, Hope you are doing great! I would like to know if it is supported to mirror persistence between 2 DC's across 2 Traffic Groups, each one is Active on a DC. DC 1 Active on TG1 DC 2 Active on TG2 Client established connection on DC1, if it reconnected in DC2 traffic should be rerouted to DC1 backend. (There's no application level session synchronization) Any suggestions would be appreciated! Thank you. Regards!
Weblogic JSessionID Persistence
Problem this snippet solves: Contributed by: unRuleY, Summarized by: deb Note: The previous version of this iRule contained escaped newlines following the session command, which in versions 10.0 - 10.2.0 causes TMM to core as documented in CR135937 / SOL11427. This was fixed in 10.2.1. See this related Codeshare example for details on how to take advantage of session replication on the WebLogic servers with targeted node failover in an iRule. Provides persistence on the jsessionid value found in either the URI or a cookie. When a request is received, the iRule first looks for a "jsessionid" cookie, and if not found, for a "jsessionid" parameter in the requested URI. If either is found, a persistence record is created if it doesn't already exist, or followed if it does. If neither is found, the request is load balanced according to the load balancing method applied to the virtual server and persisted based on the client's IP address. In order to ensure the second and subsequent requests follow the first, LTM must create a persistence record indicating the pool member to which the first request was load balanced. If the server is setting the jsessionid in a cookie, the persistence key value may be extracted from the server response to create the persistence record. If the server is setting the jsessionid in the URLs, source address persistence with a short timeout is recommended to track the original destination until the jsessionid is sent. How to use this snippet: To ensure a new persistence record is followed when a request is re-load balanced in a client-side Keep-Alive connection, apply a OneConnect profile to the virtual server. The iRule assumes the jsessionid is in upper case when used as a cookie name. If this isn't the case, please update the example. To persist on jsessionid, create the iRule below and create a custom Universal persistence profile, with Match Across Services enabled, that uses the iRule. Then use this custom Universal persistence profile as the Default Persistence profile on your Virtual Server. Applying a Fallback Persistence profile of type Source Address Affinity with a host mask and a short timeout (the default source_addr persistence profile will do the trick) to your Virtual Server is also recommended. Attention, if you are running firmware 11.0 - 11.2.1 and enabled "Match Across Services"! There is a bug inside. SOL14061 This iRule requires LTM v10. or higher. Code : when HTTP_REQUEST { # Log details for the request set log_prefix "[IP::client_addr]:[TCP::client_port]" log local0. "$log_prefix: Request to [HTTP::uri] with cookie: [HTTP::cookie value JSESSIONID]" # Check if there is a JSESSIONID cookie if { [HTTP::cookie "JSESSIONID"] ne "" }{ # Persist off of the cookie value with a timeout of 1 hour (3600 seconds) persist uie [string tolower [HTTP::cookie "JSESSIONID"]] 3600 # Log that we're using the cookie value for persistence and the persistence key if it exists. log local0. "$log_prefix: Used persistence record from cookie. Existing key? [persist lookup uie [string tolower [HTTP::cookie "JSESSIONID"]]]" } else { # Parse the jsessionid from the path. The jsessionid, when included in the URI, is in the path, # not the query string: /path/to/file.ext;jsessionid=1234?param=value set jsess [findstr [string tolower [HTTP::path]] "jsessionid=" 11] # Use the jsessionid from the path for persisting with a timeout of 1 hour (3600 seconds) if { $jsess != "" } { persist uie $jsess 3600 # Log that we're using the path jessionid for persistence and the persistence key if it exists. log local0. "$log_prefix: Used persistence record from path: [persist lookup uie $jsess]" } } } when HTTP_RESPONSE { # Check if there is a jsessionid cookie in the response if { [HTTP::cookie "JSESSIONID"] ne "" }{ # Persist off of the cookie value with a timeout of 1 hour (3600 seconds) persist add uie [string tolower [HTTP::cookie "JSESSIONID"]] 3600 log local0. "$log_prefix: Added persistence record from cookie: [persist lookup uie [string tolower [HTTP::cookie "JSESSIONID"]]]" } }F5 XC – Persistence and Resiliency pt. I (persistence)
Since we're talking about distributed environments (multiple PoPs, CEs, etc.) and need to ensure consistent behavior without necessarily being able to form a cluster (e.g., PoP Frankfurt and PoP Amsterdam), we use a method that is suitable for distributed structures: Ring Hashing (Consistent Hashing).
iRule resulting in too many redirects
I have two requirements with my virtual server. 1. A redirect to /pc/service/SSOLogin 2. 24 hour persistence based on the JSESSIONID cookie in the request header. The first one was accomplished early on with a policy that redirects to location '/pc/service/SSOLogin' at request time. This has worked without any issues until I tried to implement the JSESSIONID persistence. To accomplish the second, I created an iRule to be used with the Universal persistence profile. When I implemented this persistence profile, the redirect policy no longer worked. My assumption was that the iRule and the policy were conflicting with each other. To resolve this, I created a single iRule to handle both of these requirements. Now, I am getting too many redirects. The iRule is below. when HTTP_RESPONSE { ## PERSISTENCE # If the JSESSIONID exists, we'll pass the cookie along if { [HTTP::cookie exists "JSESSIONID"] } { persist add uie [HTTP::cookie "JSESSIONID"] 86400 } } when HTTP_REQUEST { ## PERSISTENCE # If the JSESSIONID exists, we'll maintain that persistence if { [HTTP::cookie exists "JSESSIONID"] } { persist uie [HTTP::cookie "JSESSIONID"] } ## REDIRECT # This grabs the base url from the incoming request # For Example, https://my.site.com/some/path the base_url is set to https://my.site.com set base_url "https://[HTTP::host]" # Defining the new path set new_path "/pc/service/SSOLogin" # Construct the new URL # For example, https://my.site.com/pc/service/SSOLogin set new_url "$base_url$new_path" # Redirect to the new URL HTTP::redirect $new_url }
Pool round Robin not working with standard virtual server
I have a standard HTTPS virtual server configured with two nodes in the pool. There is no persistence setting enabled and the load balancing method is round robin. For some reason, after I browse to the site and establish a connection with a backend server in the pool, all my future requests go to the same server and it behaves in a way that indicates some persistence is enabled. For example, when I refresh my browser, open the site in a new browser, and open the site in an incognito browser, all my requests keep going to the same node. You can see below that I tried this multiple times and kept getting connected to one server and the number of connections on that server was increasing. According to my research, because there is no persistence profile setting, the load balancing method is round robin, and both servers are available and able to accept traffic, every time I refresh or open the site in a new tab or browser, I should be randomly assigned to a server for that connection via round robin load balancing. But this is not what I observe. Is there a reason that my virtual servers are showing persistence by default? Any ideas? Here are some images of my config:
Ratio (Session) and Least Sessions
Hello, I wanted to fully understand the Ratio(Session) load balancing method. I was reading the description of load balancing methods here and about the Least Session here. I came across this question in the forums, but the links are old and it doesn't provide a clear answer, I want to know what exactly is considered a session in the Ratio(session), it's mentioned for the Least sessions that it depends on a Persistence profile (least number of entries in the persistence table) to determine the sessions for each pool member, for example HTTP cookie determines the session in this case, is it the same case for Ratio(Session)? What is meant by a session exactly in the Ratio(Session) and is there a real-world example for this case? In this article, it's mentioning that Ratio(Session) is used for protocols that transmit multiple messages over the same connection, is this the same case for HTTP for example using Cookie persistence like Least Sessions? It's not very clear to me how the system will count sessions if it's not based on persistence like the Least Sessions. When I applied this load balancing method to a pool with multiple members, I noticed the requests where going to one member only. ThanksMultiple method persistence
Hello. I need to setup load-balancing for a visio application, which is quite complex, as I don't need just to ensure session persistence for a single user, but for multiple users participating to the same conference. According to my understanding of reference documentation, I need to use an universal persistence profile (or eventually hash persistence profile, as it only differs by hashing lookup value), and write an iRule, such as: when HTTP_REQUEST { # extract roomID from room parameter in query string set roomID [getfield [URI::query [HTTP::uri] room] "@" 1 ] if { $roomID != "" } { persist uie $roomID 3600 log local0. "Using Jitsi room ID $roomID for persistence: [persist lookup uie $roomID]" } } Once a corresponding persistence profile assigned to the virtual server, it works as expected. However, I also have to ensure persistence for authentication requests, this time with more classical requirements, ie every authentication requests for a given user must reach the same pool node. I first considered the use of a fallback persistence profile (either cookie, ssl, or source address), so as to keep the irule simple. However, documentation discourage using fallback persistence for this purpose: If Fallback persistence becomes the chosen persistence method, a Default persistence entry will not be created for the client connection until the Fallback persistence idle timeout period expires. Because of this, Fallback persistence may appear to override Default persistence and may not be a good choice. See Recommendations, following, for additional information. So I added another clause in my iRule, still using uie method, but with client address as lookup key, hence reinventing simple persistence: if { [HTTP::path] starts_with "/Shibboleth.sso" } { persist uie [IP::client_addr] 3600 log local0. "Using client IP adress for persistence: [persist lookup uie [IP::client_addr]]" } According to the documentation, I may be able to mix persistence methods in a single iRule (one of the example given here mixes source_addr and cookie methods), but some of those methods (ssl, msrdp, cookie) also requires a corresponding persistence profile assigned to the virtual server. Whereas I already use an universal persistence profile. So basically, I'm a bit lost among multiple options, especially the relation between persistence profiles and persistence methods, and I have a few questions: Is there any recommended practice for using multiples persistence methods in a single iRule ? if only ssl and cookie methods require a corresponding profile, what is the interest of using an universal persistence profile, instead of just assigning the persistence irule to the virtual server ? If I'm assigning a cookie persistence profile and a persistence irule using uie method to the same virtual server, how will persistence work ? I hope I have been clear enough 🙂 Thanks for your interest.
How to generate the persistence cookie with an iRule
Problem this snippet solves: When you configure a cookie persistence profile to use the HTTP Cookie Insert or HTTP Cookie Rewrite method, the BIG-IP system inserts a cookie into the HTTP response. The cookie value contains the encoded IP address and port of the destination server. Exemple of a cookie value : 1677787402.36895.0000 (See SOL6917 for more information about this topic) Let's assume that you want your pool member to receive a copy of this cookie value in an HTTP header. Because for example you want your application to forge an url where the cookie value is in a GET parameter. (NOTE : I cannot modify the behavior of the application, I can only play with headers) Retrieving the cookie value is pretty easy with iRule : [HTTP::cookie value $cookie_name] But you'll notice that there is a little issue with this feature: when you are a new visitor, the persistence cookie is inserted in the HTTP response ... Meaning that for the very first hit made by the visitor, there will be NO cookie value to retrieve ... In my scenario it was an issue to miss this cookie value on the first hit, so I had to come up with a solution to forge the cookie value based on pool member IP and port when the persistence cookie is missing. I chose to adapt the code found here and there (thanks !) EDIT : Well I figured out that if you are not using a default route-domain the persistence cookie value will be different (see https://support.f5.com/csp/article/K6917 ) Here is the alternative code bloc to use IPv4 non-default route domains: set ADDR "[format %02x $a][format %02x $b][format %02x $c][format %02x $d]" set PORT [LB::server port] set COOKIE "rd2o00000000000000000000ffff${ADDR}o${PORT}" How to use this snippet: To summarize what the iRule does : if the persistence cookie doesn't exist (most likely because it's the very first hit), then calculate it from member IP and PORT (it obviously has to be after the "When LB_SELECTED" statement) ; else just read the existing cookie. You can set the $cookie_name parameter manually, or let the iRule identify it Code : when LB_SELECTED { #set cookie_name SERVERID # following function could determine persistence cookie name being used if not manually set by the previous line if {not [info exists cookie_name]} { if { [set cookie_name [PROFILE::persist mode cookie cookie_name]] eq "" } { set cookie_name "BIGipServer[getfield [LB::server pool] "/" 3]" } #Default cookie name requires the getfield "/" 3 purge otherwise it's /Common/pool_name } if { [set COOKIE [HTTP::cookie value $cookie_name]] == "" } { scan [LB::server addr] {%d.%d.%d.%d} a b c d set ADDR [expr { $a + $b * 256 + $c * 65536 + $d * 16777216 }] set PORT [ntohs [LB::server port]] set COOKIE "${ADDR}.${PORT}.0000" ## Following bloc must be used instead if you are using non-default route domains, see K6917 #set ADDR "[format %02x $a][format %02x $b][format %02x $c][format %02x $d]" #set PORT [LB::server port] #set COOKIE "rd2o00000000000000000000ffff${ADDR}o${PORT}" ######### unset a b c d ADDR PORT #log local0. "$cookie_name = $COOKIE created for [HTTP::uri]" } else { #log local0. "$cookie_name = $COOKIE already exists for [HTTP::uri]" } HTTP::header insert X-F5-persist $COOKIE } Tested this on version: 11.5
Hostname based Load balancing (prior to 11.6.0)
Problem this snippet solves: This code is initially developed to provide a forward proxy to Apple Push Notification Services. This code can easily be customized to load balance requests to any resolved FQDN. Several issues are solved here : Forward proxy for several Apple APNs services like gateway.push.apple.com and feedback.push.apple.com Hostname based loadbalancing for BIG-IP under version 11.6.0 Source address persistence using tables (because when using the node command, persistence settings doesn't works) How to use this snippet: Installation This irule can be installed on multiple VS at the same time or on a wilcard VS. During several tests, we configured the following Virtual Server settings : ltm virtual vs_wildcard_apns { description *.push.apple.com destination 192.168.20.200:any ip-protocol tcp mask 255.255.255.255 profiles { fastL4 { } } rules { irule_apns } source 0.0.0.0/0 source-address-translation { type automap } translate-address enabled translate-port disabled vs-index 9 } Code : when RULE_INIT { set static::nameserver "8.8.8.8" set static::max_age 1800 } when CLIENT_ACCEPTED { switch [TCP::local_port] { "2195" { set host "gateway.push.apple.com" } "2196" { set host "feedback.push.apple.com" } default { log local0. "virtual=[virtual], src=[IP::client_addr], dst=$dest:[TCP::local_port], action=reject, reason=\"Request not allowed\"" reject return } } # resolve the hostname using table or dns lookup if { [table lookup "$host.[IP::client_addr]"] ne "" } { set dest [table lookup "$host.[IP::client_addr]"] log local0. "virtual=[virtual], src=[IP::client_addr], dst=$dest:[TCP::local_port], action=resolve, reason=\"from table\"" node $dest [TCP::local_port] } else { set dest [lindex [RESOLV::lookup @$static::nameserver -a $host] 0] log local0. "virtual=[virtual], src=[IP::client_addr], dst=$dest:[TCP::local_port], action=resolve, reason=\"from dns\"" if { $dest ne "" } { table set "$host.[IP::client_addr]" "$dest" indefinite $static::max_age node $dest [TCP::local_port] log local0. "virtual=[virtual], src=[IP::client_addr], dst=$dest:[TCP::local_port], action=forward" } else { log local0. "virtual=[virtual], src=[IP::client_addr], dst=$dest:[TCP::local_port], action=reject, reason=\"DNS resolution failed\"" reject return } } } when CLIENT_CLOSED { table delete conn:[IP::client_addr]:[TCP::client_port] } Tested this on version: 11.3
