Forum Discussion

igorzhuk's avatar
igorzhuk
Icon for Altostratus rankAltostratus
Jul 04, 2023

priority group activation

Hi all, I used f5 priority group activation When my pool member fail and the second pool member come to active the traffic forward to the lower group pool member, But when the higher pool member...
application delivery
priority group activation
igorzhuk's avatar
igorzhuk
Icon for Altostratus rankAltostratus

I found this Irule: it maybe can help me: 

when LB_SELECTED {
  if { ([IP::addr [LB::server addr] equals "low-priority-ip"]) and ([active_members pool_name] > 1) } {
    LB::reselect
  }
}

 But my traffic is not HTTP is SMB traffic [445], when LB_SELECTED trigger - how I know it's only ones in TCP connection - no? Because if yes LB:: reselect will not work for existing connections, [and its not VS that make oneconnect]

 

whisperer's avatar
whisperer
Icon for MVP rankMVP
Jul 05, 2023

Think you found this here:

https://community.f5.com/t5/technical-forum/priority-group-activation-failback-with-http-cookie-insert/td-p/237687

That will not work for you... out of the box, at least. Here is why...

- "low-priority-ip" is a placeholder for the IP addresses of the pool members in the lower priority group. Presume you would need to change the logic to see if the IP is in a list of multiple IP addresses.

- active-members pool_name needs to of course reference the actual name of your pool. Pool_name is a variable placeholder in this example. Also, this gets all of the ative members, those in the 1st priority group and those in the 2nd priority group.

I do not know of any iRules command to effectively distinguish the priority of a group member. If this was possible, there there would be some possible logic to see if the total number of active pool members part of the higher priority gorups equals the total, and if the picked load balance selection has chosen a member from the lower priority group. HOWEVER, LB_SELECTED usually occurs only once for a session. So, this wouldnt really change anything. A user sent to the lower priority group, because of an event, wouldnt have their session auto-started to the higher pool if members become available. For that session, the logic has already completed for which pool member to choose. You need to tear down the session, or someone force a reselection. The issue is also that for an existing session, you will not be able to issue the LB reselect arbitrarily in a different event, as it is only valid for the following events:

  • LB_SELECTED
  • LB_QUEUED
  • PERSIST_DOWN
  • LB_FAILED

Those events will not usually trigger for an already established user session.

Hope this makes sense?