Forum Discussion
forced failback via iRule
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.
P.
6 Replies
- JPV_131616
Cirrus
priority groups would probably be best.
Set the primary node to a higher priority group (e.g. 99), 1 for the standby.
Ensure you have a proper monitor on the pool
cheers
- Pavel_71715
Nimbostratus
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.
BR, Pavel
P.S. - I tried this iRule but LB_SELECTED event is done only once so code is not working as expected
when CLIENT_ACCEPTED { set pool_name [LB::server pool] } when LB_SELECTED { if { [active_members $pool_name] > 1} { if { [IP::addr [LB::server addr] equals 10.10.10.2] } { LB::reselect pool $pool_name } } }
- Zdenda
Cirrus
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?
- Luis_Araujo_560
Nimbostratus
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] > 1} { if { [IP::addr [LB::server addr] equals 2010::21%2] } { reject log local0. "[LB::reselect] for [IP::server_addr]" } } }
- Zdenda_101923
Altocumulus
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?
- Luis_Araujo_560
Nimbostratus
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] > 1} { if { [IP::addr [LB::server addr] equals 2010::21%2] } { reject log local0. "[LB::reselect] for [IP::server_addr]" } } }
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)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