Forum Discussion

SivaYenduri's avatar
SivaYenduri
Icon for Cirrus rankCirrus
Mar 02, 2021

Priority Group Activation Failback with HTTP Cookie Insert

Hello All,

 

Can someone help me the below issue?

 

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.

 

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.

 

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.

 

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.

 

Please let me know how i can achieve the desired behavior.

 

Regards

application delivery
BIG-IP
cookies
iRules
LTM
TMOS
TMSH
  • SivaYenduri's avatar
    SivaYenduri
    Icon for Cirrus rankCirrus
    Mar 04, 2021

    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's avatar
      Simon_Blakely
      Icon for Employee rankEmployee
      Mar 04, 2021

      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] > 1) } {
    LB::reselect
  }
}

      Give that a test.

      • igorzhuk's avatar
        igorzhuk
        Icon for Altostratus rankAltostratus
        Jul 05, 2023

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

  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Mar 04, 2021

    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.