Can LTM be used to configure Active and Passive Servers?

We need to forward existing connection to higher priority pool members when it comes back online.

doesn't it break application? what is application traffic? is it http?

It is TCP only, application has a way to renegotiate, it does not break the application

So, devcentral has started CCing me on this thread, even though I have no subscription or prior activity on it. I looked for a place to delete my f5 devcentral account, given that devcentral is routing messages to me that I am not subscribed to. That's not easy, apparently. It might be a hash collision in the subscription ids, or something like that.

There was apparently no better place for me to report such an issue, so I have no choice but to report it here and discard any email from this system.

The pool shows only one pool member per PGA, so configuring F5 to be dumb L3 (nPath) should cause the desired behavior (though with a caveat).

Unless you're running a ridiculously customized TCP stack, however, you'll need to handle L4/L5 session control "some how" (hence caveat). I expect shifting a TCP session mid-stream isn't going to work for you.

This means leveraging OneConnect, but that doesn't work w/fastL4, so I agree that you'll likely need to descend the rabbit hole of iRules. I am moderately confident that a solution is possible, but well beyond the scope of something I would want to develop via this forum. In any case, if this is possible at all, that is where you will find it (via OneConnect & iRules).

Good luck!

Thanks A. Obviously I could post detail information how application works, that is not we need to worry about it here. Would you please to read OneConnect definition.

Agreed, further app details aren't needed at this point -- it is sufficient to know that the back-end app is capable of resuming a session on a new pool member (recovered principle device) from another pool member (secondary device).

SOL7208: Overview of the OneConnect profile https://support.f5.com/kb/en-us/solutions/public/7000/200/sol7208.html

OneConnect cliff notes: Allows abstraction of the client side tcp session from the server side tcp session. Additionally, it allows multiple client side connections within_the_same_tcp_session to be carved up into multiple server side connections (think upstream reverse web proxy; e.g.: Akamai). This OneConnect framework would, in theory, provide the needed hook to redirect the server side tcp session.

It is one of the more complex and sophisticated features of an F5.

To be clear, it is doubtful that a checkbox exists that enables the desired behavior. A useful (needed?) side effect of the OneConnect feature is that the profile enables per packet inspection of the client side traffic which means, in theory (a lot of theory here), that one could evaluate if the principle PGA pool member had recovered and force a pool member reselect once detected.

As such, OneConnect + iRule may accomplish what you're after...

...or cause a TCL error, TMM core, or sundry other possible problems. Be sure to test in a lab (basic fail-over/back during active traffic would be sufficient for a PoC) and load test for performance (anytime iRules are used to solve problems, this is particularly crucial). Making a new LB decision on pool member recovery mid-stream is not going to be a common use case (read: won't be heavily tested by PD nor have the benefit of heavy usage/validation in the field).

Allow me to re-iterate that a solution such as this would really best be addressed by an F5 savvy solution architect.

It may also be worth contacting F5 Support to submit an RFE -- i.e.: PGA higher priority pool member recovery auto-failback feature of some sort; the converse of AoSD Reselect feature, if you will (AoSD = pool feature "Action on Service Down").

Key point is that

The OneConnect feature works with HTTP Keep-Alives to allow the BIG-IP system to minimize the number of server-side TCP connections by making existing connections available for reuse by other clients.

It needs HTTP Keep-Alives, my application is TCP only..

When a OneConnect profile is enabled for a TCP virtual server that does not have an HTTP profile applied, and a client sends multiple requests within a single connection, the BIG-IP system is able to process each request individually. The BIG-IP system sends the requests to different destination servers as determined by the load balancing method. Without a OneConnect profile enabled for the virtual server, the BIG-IP system performs load-balancing only once for each TCP connection.

Does that mean for new connection, not current connection?

It looks clear to me. Without OneConnect, one LB decision per TCP session (connection). With OneConnect, each HTTP request (GET, POST, whatever) within the TCP session is processed for an LB decision.

Within your question, I don't know what "that" means specifically. Which of the statements in the OneConnect behavior detailed in your post needs clarification? [Or perhaps I managed to answer it above?]

It is worth noting that I have limited experience w/higher level HTTP features on the F5, and subsequently the OneConnect feature. Otherwise I would provide greater insight into whether and how one might go about getting the behavior you are after.

As it is, I only have a strong suspicion that OneConnect+iRules are capable of providing the desired behavior.

Alternately, it might be possible to use just iRules to force an LB detach on each server response, which might do what you're after? It was how we supported OneConnect like features (or maybe a workaround) a few years ago. I'll look to see if the SOL is still around.

https://devcentral.f5.com/wiki/iRules.LB__detach.ashx

https://support.f5.com/kb/en-us/solutions/public/14000/400/sol14496

Maybe that will work?

Thanks, I will give a try