Limitation on LB::reselect?

i am having a similar problem too. i think LB_SELECTED is not triggered after executing 2nd LB::reselect command.

[root@ve11a:Active:Changes Pending] config  tmsh show sys version|head

Sys::Version
Main Package
  Product  BIG-IP
  Version  11.3.0
  Build    3022.0
  Edition  Hotfix HF3
  Date     Fri Feb 22 00:00:34 PST 2013

root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos) list ltm virtual bar
ltm virtual bar {
    destination 172.28.20.16:80
    ip-protocol tcp
    mask 255.255.255.255
    pool foo
    profiles {
        tcp { }
    }
    rules {
        myrule
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vlans-disabled
}
root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos) list ltm pool foo
ltm pool foo {
    members {
        200.200.200.101:80 {
            address 200.200.200.101
        }
        200.200.200.102:80 {
            address 200.200.200.102
        }
        200.200.200.111:80 {
            address 200.200.200.111
        }
        200.200.200.112:80 {
            address 200.200.200.112
        }
    }
}
root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos) list ltm rule myrule
ltm rule myrule {
    when CLIENT_ACCEPTED {
  log local0. "--"
  set c 1
}
when LB_SELECTED {
  log local0. "--"
  log local0. "\[LB::server\] [LB::server]"
  log local0. "\$c $c \[active_members foo\] [active_members foo]"
  if { $c < [active_members foo] } {
    LB::reselect
    log local0. "LB::reselect"
    incr c
  }
}
when LB_FAILED {
  log local0. "--"
}
when SERVER_CONNECTED {
  log local0. "--"
  log local0. "server [IP::remote_addr]:[TCP::remote_port]"
}
}

 /var/log/ltm

[root@ve11a:Active:Changes Pending] config  tail -f /var/log/ltm
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : --
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : --
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : [LB::server] /Common/foo 200.200.200.101 80
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : $c 1 [active_members foo] 4
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : LB::reselect
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : --
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : [LB::server] /Common/foo 200.200.200.102 80
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : $c 2 [active_members foo] 4
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : LB::reselect
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : --
Mar 11 14:15:40 ve11a info tmm[10597]: Rule /Common/myrule : server 200.200.200.102:80

I actually do get one more LB_SELECTED event. But not two.

 

 

This is the log output:

 

 

Mar 10 23:30:54 tmm1 info tmm1[9793]: Rule /Common/Cache_service_server-v1 : Server 172.29.39.22:80 Tries 1 Avoid_list "172.29.39.22:80 172.29.39.22:81" Active {172.29.39.22 80} {172.29.39.22 81} {172.29.39.22 82} {172.29.39.22 83}

 

Mar 10 23:30:54 tmm1 info tmm1[9793]: Rule /Common/Cache_service_server-v1 : On avoid list (try 1), retrying

 

Mar 10 23:30:54 tmm1 info tmm1[9793]: Rule /Common/Cache_service_server-v1 : Server 172.29.39.22:81 Tries 2 Avoid_list "172.29.39.22:80 172.29.39.22:81" Active {172.29.39.22 80} {172.29.39.22 81} {172.29.39.22 82} {172.29.39.22 83}

 

Mar 10 23:30:54 tmm1 info tmm1[9793]: Rule /Common/Cache_service_server-v1 : On avoid list (try 2), retrying

 

Mar 10 23:30:54 tmm1 info tmm1[9793]: Rule /Common/Cache_service_server-v1 : Final result: 172.29.39.22:81, tries 2

 

 

 

The last message came from my HTTP_RESPONSE event giving the result of the selection.

I should mention that this is on 11.2.0.

Also, I'm testing on a 1600 with 2 processors, where I'm seeing this behavior.

i have opened a case since a few days back to check whether it is expected behavior (i do not think it is anyway). i will post here when getting feedback.

i was told it is by design. :-/

 

 

ps. the case number is 1-151782045.

 

I should hope that you have suggested that this design decision be documented?

this is an answer from escalation engineer.

 

 

A request comes in and a pool member is selected.

 

LB_SELECTED event occurs, criteria in irule are met, and LB::reselect happens

 

While LB::reselect is running, LB_SELECTED happens again

 

TMM notices that LB::reselect is still occurring, and doesn't call LB::reselect again

 

Traffic is sent to node, and SERVER_CONNECTED occurs, LB::reselect is over

 

 

Ahh. So it's a recursion issue. I wasn't thinking of LB_SELECTED being called directly out of the previous LB::reselect event, but I guess it is.

 

 

Still, it should be documented.

 

 

Too bad they don't offer an iRule interface to affect the load balancing decision itself. What I really need is "pick a server, but not one of the ones in this list, unless you have no other choice".

 

 

My final solution was to check if the assigned server was in the "avoid" list. If it is, I loop through the available nodes and pick the first one not in the avoid list. If there are none, I just let it go through to the selected server.

Wouldn't the Priority Group Activation feature meet your requirements?