Forum Discussion
Yes. The IP exists in the pool, but the members are set to listen on any port.
There are two nodes in the pool and the load balancing method is observed(member) (Probably should be observed(node)), but that is why I'm trying to do this after the load balancing decision has been made. By defining what node to use at Client_Accepted I negate the load balancing. Essentially, if srvA is chosen I want to use the original destination port, but if srvB is selected the port must be incremented by one (it has something to do with the application design). We have attempted to use Client_Accepted, the rule was like this:
when CLIENT_ACCEPTED {
eval [LB::select]
if { [IP::addr [LB::server addr] equals 10.234.133.222] } {
set port [clientside {TCP::local_port}]
log local0.debug "Port = $port"
set new_port [expr {$port + 1}]
log local0.debug "New port is $new_port"
node 10.234.133.222 $new_port
} }
Using this rule, however, I never saw the log messages for this rule in /var/log/ltm and using a tcpdump, no traffic was ever forwarded from the backside interface when a connection was attempted to the VIP. It was as if the iRule stopped the traffic processing on that VIP all together. Perhaps the eval statement didn't have anything to evaluate and that is why log messages never appeared and no traffic was forwarded?
We will certainly try the LB::detach idea today. Thanks for the input. It is much appreciated. I will follow up with my results later.
- BinaryCanary_19Oct 21, 2014Historic F5 AccountNote, you will never see a log message in your irule above because: LB::server addr will not equal 10.234.133.222 -- it probably doesn't exist yet.