Many multi-tier applications use proxy servers (PS). Proxy servers often provide authentication and/or security to allow clients to connect to web application servers (WebAPP).
In this scenario an F5 virtual servers sits in front of the PS server and is using source IP persistence. This means that based on the clients source IP they will be assigned to the same back-end PS server.
The proxy servers in front of the Web APP virtual server will be using HTTP Insertion cookie to maintain persistence. What this means is the F5 will present a cookie to the clients browser even though it is going through the PS server. So when that client connects to the web application through the PS server it will present that cookie in its header and the F5 will decrypt the cookie and send it to the correct Web APP server in the back-end.
Source IP benefits and short comings
Benefit:
There is no dependency on the client’s device or software such as browser or OS.
It is very easy to troubleshoot, and view current state on the clients’ persistence on the F5 using CLI command.
It is proven persistence method and is very dependable.
Many apps i have configured to use source IP have seen fairly balanced load balancing.
Short comings:
It will not give you as evenly distributed load balancing as a session based persistence. (Sites that have users behind a NAT)
It is not the correct load balancing persistence to set on the web application since the only IP addresses it would see are the PS servers.
HTTP cookie benefits and short comings:
Benefits:
This is a session based load balancing which means it doesn’t load balance each machine or IP, but the actual web session the client has open. When the users closes their browser the cookie is destroyed.
Create a very balanced load between back-end servers.
Cons:
Depended on user machines, browsers, security policies, or OS. If there systems or software does not support encrypted cookies, or their policy is not to accept or store cookies, this would break persistence.
More difficult to troubleshoot and map users back to a machine without actually having the clients cookie.
Solution:
The perfect solution would be to find a session based persistence that does not rely on the client’s machine to provide a cookie. At the very least we will need a session based persistence between the PS servers and the Web APP virtual server since we know source IP address is not a viable solution between the PS servers and the Web APP virtual server.
Recommendation:
Load balance the PS virtual server using source IP persistence provides good load balancing as long as there is a diverse client pool, and allows for more visibility into troubleshooting specific end point connections. Then use a session based persistence between the PS servers and the Web APP virtual servers that does not involve the client.
F5 recommended using SSL persistence for the Web APP virtual server and sticking with source IP on the PS Virtual server. What this would do is set persistence based on the SSL session ID between the PS servers and the Web APP virtual server. SSL persistence also makes a persistence table entry so we would have similar troubleshooting visibility we would have with source ip persistence.
In addition we will need to make sure least connection is set as the load balancing algorithm for both the PS and Web APP pools. This will insure we are not blindly load balancing but leveraging the F5 visibility into connections to the pool members.
FYI:
Theoretically you can still use the HTTP cookie persistence on your WebAPP server, but as I found out the hard way many PS servers will combine multiple client HTTP sessions into one back end connection to the WebApp virtual server. The default way F5 handles http cookie persistence is during the creation of an HTTP session it looks at the first HTTP request for the http cookie header, then based on the first cookie will load balance the entire HTTP session to the designated back end HTTP server. Where this breaks is if you are combining multiple HTTP client sessions and the web application servers are not expecting that clients traffic, (web application does not share user session information.) To fix this issue you can enable a OneConnect profile on the WebAPP virtual server. One of the actions that is taken by the OneConnect profile is to look at every HTTP request and load balance based on each request not just the first HTTP request.
If SSL Persistence and Cookie is not an option:
Universal persistence profile allows you to use an irule that will look for the x-forwarded-for header and use a hash value to maintain persistence. F5 warned us there would be some coding on our part to create a custom irule and it that this type of persistence is a very CPU expensive process on the F5. This one is definitely last on the list.
In this scenario an F5 virtual servers sits in front of the PS server and is using source IP persistence. This means that based on the clients source IP they will be assigned to the same back-end PS server.
The proxy servers in front of the Web APP virtual server will be using HTTP Insertion cookie to maintain persistence. What this means is the F5 will present a cookie to the clients browser even though it is going through the PS server. So when that client connects to the web application through the PS server it will present that cookie in its header and the F5 will decrypt the cookie and send it to the correct Web APP server in the back-end.
Source IP benefits and short comings
Benefit:
There is no dependency on the client’s device or software such as browser or OS.
It is very easy to troubleshoot, and view current state on the clients’ persistence on the F5 using CLI command.
It is proven persistence method and is very dependable.
Many apps i have configured to use source IP have seen fairly balanced load balancing.
Short comings:
It will not give you as evenly distributed load balancing as a session based persistence. (Sites that have users behind a NAT)
It is not the correct load balancing persistence to set on the web application since the only IP addresses it would see are the PS servers.
HTTP cookie benefits and short comings:
Benefits:
This is a session based load balancing which means it doesn’t load balance each machine or IP, but the actual web session the client has open. When the users closes their browser the cookie is destroyed.
Create a very balanced load between back-end servers.
Cons:
Depended on user machines, browsers, security policies, or OS. If there systems or software does not support encrypted cookies, or their policy is not to accept or store cookies, this would break persistence.
More difficult to troubleshoot and map users back to a machine without actually having the clients cookie.
Solution:
The perfect solution would be to find a session based persistence that does not rely on the client’s machine to provide a cookie. At the very least we will need a session based persistence between the PS servers and the Web APP virtual server since we know source IP address is not a viable solution between the PS servers and the Web APP virtual server.
Recommendation:
Load balance the PS virtual server using source IP persistence provides good load balancing as long as there is a diverse client pool, and allows for more visibility into troubleshooting specific end point connections. Then use a session based persistence between the PS servers and the Web APP virtual servers that does not involve the client.
F5 recommended using SSL persistence for the Web APP virtual server and sticking with source IP on the PS Virtual server. What this would do is set persistence based on the SSL session ID between the PS servers and the Web APP virtual server. SSL persistence also makes a persistence table entry so we would have similar troubleshooting visibility we would have with source ip persistence.
In addition we will need to make sure least connection is set as the load balancing algorithm for both the PS and Web APP pools. This will insure we are not blindly load balancing but leveraging the F5 visibility into connections to the pool members.
FYI:
Theoretically you can still use the HTTP cookie persistence on your WebAPP server, but as I found out the hard way many PS servers will combine multiple client HTTP sessions into one back end connection to the WebApp virtual server. The default way F5 handles http cookie persistence is during the creation of an HTTP session it looks at the first HTTP request for the http cookie header, then based on the first cookie will load balance the entire HTTP session to the designated back end HTTP server. Where this breaks is if you are combining multiple HTTP client sessions and the web application servers are not expecting that clients traffic, (web application does not share user session information.) To fix this issue you can enable a OneConnect profile on the WebAPP virtual server. One of the actions that is taken by the OneConnect profile is to look at every HTTP request and load balance based on each request not just the first HTTP request.
If SSL Persistence and Cookie is not an option:
Universal persistence profile allows you to use an irule that will look for the x-forwarded-for header and use a hash value to maintain persistence. F5 warned us there would be some coding on our part to create a custom irule and it that this type of persistence is a very CPU expensive process on the F5. This one is definitely last on the list.
The beginning of the end for traditional cable companies may be upon us. More feasible and easy to use cord-cutting options are becoming main streams like Play Station Vue, Sling TV, and YouTube TV. We mustn't forget who started it all. Netflix and Hulu pioneered the over the top streaming services, then HBO leveraged their hit show Game of Thrones to launch HBO Now. But now the big boys have come to play, Disney and Apple are launching their new streaming services.
Disney+ is quickly going to be the big boy on the block. With their purchase of Star Wars, Marvel and Fox in addition to their existing massive archive there are no other studios in Hollywood with a catalog as deep. It only makes since Disney would want to create their app. If you look at their accusations of not only intellectual properties but also technology (BAMTech, LLC) you can see Disney has been planning this move to Digital for a while. If you have been to Disneyland you understand that Disney is the master of creating a curated and controlled experience. it only makes sense they would want to bring that same experience to their video content online.
Apple TV+... Well, there isn't much to be said yet. Apple is investing in its original content but doesn't have any sort of back catalog of content. So it is yet to be seen if Apple can pull off its streaming service.
Horchata No-Bake Cheesecake
Ingredients:
1 box of Jello No-Bake Cheese Cake
½ c. Heavy Whipping Cream
1 c. horchata
1 t. cinnamon
1 t. vanilla
1 pre-made graham cracker crust or use the crust mix that comes with cheese cake mix
caramel sauce
Preparation:
- Mix the horchata, heavy whipping cream, cinnamon, and vanilla in a bowl. (this is your milk alternative)
- Pour it in the mixer with the cheesecake mix and follow the directions on the box.
- Optional: When served drizzle caramel sauce over the slice.
Enjoy
Since the F5 app for spunk has been abandoned I have been playing around with a simple F5 Splunk dashboard. This dashboard can be a quick one-stop health view for any application being load balanced by the F5.
Prerequisites are:
- Your F5 LTM and or ASM are logging HSL (high-speed logging) to Splunk. (ASM is not a requirement)
- Configure an HSL pool that includes the Splunk logging servers.
- Configure the newest iRule on your F5 for logging to Splunk.
- Associate the new logging iRule with virtual servers you want to monitor.
- Lastly set up an ASM logging profile to sending to Splunk.
You can reference the documentation below to configure your F5 to log to Splunk.
https://docs.splunk.com/Documentation/AddOns/released/F5BIGIP/SetupOnce that is complete you can create a new dashboard in Splunk. Then copy and paste the dashboard source code I have uploaded on my GitHub repository. Once you save the dashboard you should be able to type in the URL of the application you want to monitor, the corresponding F5 pool name and the time frame you are interested in.
GitHub link:
https://github.com/wirelessphreak/F5-Dashboard-for-Splunk
If you have improvements or comments please let me know. This is a work in progress and I am always looking to make it better.



