In this week’s Post of the Week, Joe talks about using iControl to automate the process of bleeding off connections from a server, then bringing it all the way down once all connections have closed.  Thanks to poster nevot from Spain for a great question demonstrating how iControl can help automate a common change control function.

BTW, sorry for the background noise.  Remind me to shut down my BIG-IP next time B-).

Here's a link to the post: iControl graceful stop node.

This week, Colin & Deb dig into an interesting scenario presented by poster dchenna requesting feedback on the best way to quickly and reliably swap out the active database server for certain operational & maintenance events.  After reviewing the relative merits of a the suggestions and warnings offered by several respondents, it seems the best solution is an iControl call to modify the pool configuration when required.

Here’s the post:  F5 to load balance MS Sql Servers

In this week’s Post of the Week, Colin & Deb take a look at a question from poster shayne.rinne, and offer some suggestions for determining the source of additional latency when a second virtual server is added into the path between a client, a reverse proxy, and the origin server..

Here's the post: VIP to VIP communication

In this week’s Post of the Week, Deb Allen talks about a forum post by user sojourner9 regarding configuring an application health monitor to check a port besides the one configured for a pool member.

In this week’s Post of the Week, Deb Allen talks about a forum post by DevCentral user michael.trott about setting up an appropriate Response string to mark a server down if it returns a “200 OK” along with a detailed error page.  

This week’s Post of the Week is based on a post by sosa123, entitled  F5 and RTCP, looking for guidance in configuring persistence to the same servers across 2 different virtual servers.  Deb Allen and Colin Walker go through the steps required to support this commonly requested load balancing scenario.

This week’s Post of the Week is based on the post GTM and IP selection by poster cknail.  He was looking for a solution to hand out the same IP address for LTM virtual servers in different data centers, in support of devices that don’t honor the short TTL asserted by GTM.  After an interesting discussion by several F5 engineers regarding the interplay between LTM and GTM regarding monitoring VS status, it turns out that the best solution is LTM only with the ARM (Advanced Routing Module) licensed and configured to provide Route Health Injection based on LTM monitoring results for virtual server peers on a BGP or OSPF peering network.

F5 Solutions Architect Nathan McMahon explains Election Hash Load Balancing And Persistence (find the iRule in the codeshare here).  He developed this Election Hash solution to address the limitations of the Cache Array Routing Protocol, and it provides a nice alternative to any typical  hash solution that are vulnerable to re-factoring on changes to the server pool.  The complete solution is written up here: Hash Load Balancing and Persistence on BIG-IP LTM

This solution was brought to you by the iRules commands: md5, HTTP::uri, and active_members

F5 Field Systems Engineer Christopher Schaefer sits down with Colin & Deb to explore an interesting iRules solution:  Persistence for mobile devices running a proprietary stateful TCP application while roaming across cell towers mid-session.  In the absence of a consistent IP address or any identifying header information, Chris discovered the client mobile ID embedded in the binary data of the traffic stream, and built a custom Universal Persistence solution.  This solution was only possible because of the SSL offload capability of LTM, which allows LTM to decrypt the traffic before examining and acting upon it.

This solution was brought to you by the iRule commands: persist , TCP::collect, and TCP::payload, and the Tcl command binary

F5 Field Systems Engineer Patrick Chang explains an iRules solution that supports 2 active database instances in different data centers behind a web application.  The goal is to provide the optimal user experience by load balancing requests for both the web/application tier and the database tier to a local data center whenever possible.  Since cross-data center database replication takes approximately 20 seconds, one instance is preferred for database writes, and an iRule that reads and inserts time-stamped cookies reliably directs traffic to the closest database instance when possible, and to the remote instance only when necessary to maintain session integrity.

This solution was brought to you by the iRule commands: HTTP::cookie, HTTP::uri, and HTTP::method

F5 Field Systems Engineer Rob Eberhardt talks us through an iRules-based solution that records in-flight transactions and replays them to a new server instance if a server fails mid-session.  This solution could be applied to any applications whose clients are sensitive to disruption and may not reliably or gracefully restart partially completed transactions.

This solution was brought to you by the iRules commands: TCP::collect, TCP::release, and TCP::payload

“Switch” Gone Wild

This week Deb looks at a post from gregt, who was having some trouble with choosing a pool based on the requested URI.

Posters aherrman and cmbhatt (CB) jump in to correct the logical order of comparisons (most specific first, please!).  CB further suggests using switch with wildcards to replace the nested “if” commands that used “starts_with” and “ends_with”.

You’ll probably want to pull up the post to follow along on this one, so here it is:  iRule sends to wrong Pool and Port

• pyControl - Installation
• pyControl - Shell Usage