Forum Discussion
priority group activation
As far as I know, new connections will go to the higher group members of the pool once they become available. I don't think that there is a mechanism to move traffic from lower-priority group members to the higher one when this comes available. The lower priority members will process the established connections , but the new ones will go to the higher priority group members.
found these, they might help if you use an irule:
https://community.f5.com/t5/technical-forum/priority-group-failback/m-p/181850#M165544
https://community.f5.com/t5/technical-forum/priority-group-failback/m-p/52718#M36412
- igorzhukJul 05, 2023Altostratus
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]
- whispererJul 05, 2023MVP
Think you found this here:
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?
- TerryRobinsonJul 14, 2023Nimbostratus
Thank you for the all links 🙂 You saved my day.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com