F5 force connection reset on pool member

Hi Satish,

you may take a look to the iRule below.

The iRule deploys a periodic

[after]

taskjob within each TCP connection, which compares every few seconds your selected pool member with the currently prefered pool member (influenced by its health, forced offline status and priority group settings) and reject the ongoing TCP connection if those are not matching anymore.

Cleaned iRule

when RULE_INIT {
    set static::connection_check_interval 5000 ; msec
}
when LB_SELECTED {
    after $static::connection_check_interval -periodic {
        if { [lindex [LB::select] 3] ne [LB::server addr] } then {
            reject          
        }
    }
}

Debug enabled iRule

when RULE_INIT {
    set static::connection_check_interval 5000 ; msec
}
when LB_SELECTED {
    set connection_timestamp "[TMM::cmp_group][TMM::cmp_unit][clock clicks]"
    log local0.debug "Node UP Check: $connection_timestamp : The pool member [LB::server addr] is currently active. Scheduling initial status check in $static::connection_health_interval ms."
    after $static::connection_check_interval -periodic {
        log local0.debug "Node UP Check: $connection_timestamp : Performing status check for pool member [LB::server addr]"
        if { [lindex [LB::select] 3] ne [LB::server addr] } then {
            log local0.debug "Node UP Check: $connection_timestamp : [LB::server addr] is not the active member anymore. Rejecting the TCP connection."
            reject
        } else {
            log local0.debug "Node UP Check: $connection_timestamp : [LB::server addr] is still the active member. Scheduling next status check in $static::connection_health_interval ms."
        }
    }
}

Cheers, Kai

There is no built-in function to delete active connections to a pool member; disabling a pool member keeps new connections from being load-balanced to a pool member, setting a pool member to forced offline will stop persistence from being honored, but to end an active connection, the general advice is to go to the connection table and delete the connection there.

 

You could create the functionality you are looking for (where connections to the secondary instance are reset as soon as the primary node is available) by doing the following:

 

• Change the 'action on service down' setting on your virtual server to 'reject'
• Create a monitor that checks the primary node status, but use the 'reverse' option, which means that the monitor is successful when the primary node is -down- and set the alias address to the IP address of the primary node
• Apply the monitor you just created directly to the secondary node.

When your primary node goes down, the secondary node comes up, new connections get load-balanced to the secondary node. When the primary node comes back up, the reverse logic of the monitor will force the secondary node offline, and the action on service down reject behavior should reset the client connection, forcing the client to make a new connection, which will be load-balanced to the primary node.