forced failback via iRule

Question

Hello, 
Does anybody have idea how to solve following scenario? Need to forward traffic to only one node in a time. If primary node is down traffic if forwarded to the backup node. When primary is up again then traffic is immediatelly (by dropping existing sessions) trasfered back to the primary node (behaviour very similar to the priority group activation, but difference is that those existing connection on the backup node must but dropped by force when primary node is up again). I tried few iRules but no luck. Thank you.&nbsp;
P.&nbsp;

jpv_131616 · Answer

priority groups would probably be best.&nbsp;
Set the primary node to a higher priority group (e.g. 99), 1 for the standby.&nbsp;
Ensure you have a proper monitor on the pool&nbsp;
cheers&nbsp;

pavel_71715 · Answer

Hi,
I tried the priority group config but such configuration didn't cut immediatelly existing connections to the backup node when the primary node is up (this could work if health monitor marked backup node down when primary is up but this should be done on server side and we are looking solution on F5).  True is that I didn't tested such difference - do you have some document referring how the number affect behaviour? I am not aware that is should have affect on the existing sessions.&nbsp;
BR,
    Pavel&nbsp;
P.S. - I tried this iRule but LB_SELECTED event is done only once so code is not working as expected&nbsp;
when CLIENT_ACCEPTED {
  set pool_name [LB::server pool]
}
when LB_SELECTED {
  if { [active_members $pool_name] &gt; 1} {
     if { [IP::addr [LB::server addr] equals 10.10.10.2] } {
       LB::reselect pool $pool_name
     }
  }
}&nbsp;

zdenda · Answer

Hi,
I had the same issue - member with lower priority kept connections eventhough primary member was back online. It is because LB doesn't cut current connections on backup member by default. This made troubles with long-timeout connections. Did anybody have the same issue?&nbsp;

zdenda_101923 · Answer

Hi,
I had the same issue - member with lower priority kept connections eventhough primary member was back online. It is because LB doesn't cut current connections on backup member by default. This made troubles with long-timeout connections. Did anybody have the same issue?&nbsp;

luis_araujo_560 · Answer

Hello,

I had the same issue too and I change the iRule condition from LB::reselected to reject and it´s work very well.

I hope that it can help in this case:

when CLIENT_ACCEPTED {
set pool_name [LB::server pool] 
} 
when LB_SELECTED { 
if { [active_members $pool_name] &gt; 1} { 
if { [IP::addr [LB::server addr] equals  2010::21%2] } { 
reject
log local0. "[LB::reselect] for [IP::server_addr]"
   }
}   
}

Forum Discussion

forced failback via iRule

6 Replies

Recent Discussions

ASM instance creation

[ASM] - what is "Browser Challange file" ?

[ASM] - HTML5 Cross-Domain Request Enforcement - CLI command

Reverse Proxy Not Behaving

Stable Firmware for F5

Related Content

iRule for Brute Force Password Guessing Attacks

What are You a Force For?

Brute Force protection for single parameter like OTP

HTTP Brute Force Mitigation Playbook: Bot Profile for Brute Force Mitigations - Chapter 5

HTTP Brute Force Mitigation Playbook: BIG-IP LTM Mitigation Options for HTTP Brute Force Attacks - Chapter 3