Priority Group Activation Failback with HTTP Cookie Insert

Question

Hello All,&nbsp;Can someone help me the below issue?&nbsp;We have a pool with 3 members. 2 members have high priority (Round Robin) and 1 member has low priority.When both the primary members go down, the low priority member should take over the traffic.We have Cookie Insert persistence enabled on the virtual server. In Cookie persistence, "Expiration: Session Cookie" enabled.&nbsp;When both the primary members were made down, the low priority member took over the traffic.When both the primary members came back UP, the traffic continued to go to low priority backend member.When the browser tab is closed and tried to access the URL in new tab, the traffic went to low priority backend member.When the browser window is closed and tried to access the URL in new tab, the traffic still went to low priority backend member.&nbsp;When the browser cookies were deleted and tried to access the URL in new tab, the traffic was taken over by the high priority members.&nbsp;This behavior is not desired and we need to force the LB to use high priority backend members as soon as they come UP.When user tries the connection from new browser or new tab, the traffic should go to high priority pool members.&nbsp;Please let me know how i can achieve the desired behavior.&nbsp;Regards

simon_blakely · Answer

The overriding principle of persistence is that once a client has established a session to a pool member, it should stay there until the session expires. This is to prevent unexpected session failure due to changing pool member servers.

If a client has a session to the low priority server when the high priority servers are back up, the cookie persistence will keep returning the client to the low priority server until the cookie expires, so that the user sessions do not break.

If this behaviour is not desired, you will need to write an irule that looks at the load-balancing decision and the available members in the pool to determine whether the low priority pool member has been selected, whether any high priority pool members are available, and make a new load-balancing decision based on that information.

sivayenduri · Answer

I have written the below iRule. Could you please validate?

when LB_SELECTED {

if { [IP::addr [LB::server addr] equals "low-priority-ip"] } {

if {[LB::status pool pool_name member 1.1.1.1 8080 ] or [LB::status pool pool_name member 1.1.1.2 8080 ] equals "up"} {

LB::reselect

}

1.1.1.1 and 1.1.1.2 are the High priority IPs of the same pool "pool_name"

simon_blakely · Answer

That looks OK from a logical perspective. Rather than checking if the High Priority pool members are available individually, I would just check to see if the number of available pool members is greater than 1, and reselect in that case.when LB_SELECTED {
  if { ([IP::addr [LB::server addr] equals "low-priority-ip"]) and ([active_members pool_name] &gt; 1) } {
    LB::reselect
  }
}Give that a test.

igorzhuk · Answer

But LB_Selected - its only ones in connections, how the event trigger in same connections?

Forum Discussion

Priority Group Activation Failback with HTTP Cookie Insert

4 Replies

Recent Discussions

preserve client IP on layer 4 VIP

Failed to convert character dclid=%EDclid!

ASM - Parent policy vs OWASPcompliance

Rewrite uri translation not working

CONNECTION IS LOST DUE TO SELF IP IS DELIVERED

Related Content

Active/Active load balancing examples with F5 BIG-IP and Azure load balancer

HTTP with Priority Group Activation

Interrogate Pool Member Priority Group from iRule

priority group activation

Re: Getting Started with iRules: Events & Priorities