Forum Discussion

rvbehren_322318's avatar
rvbehren_322318
Icon for Nimbostratus rankNimbostratus
Jun 08, 2017

Pool persistence almost lost after a pool member has been marked down

We have configured a pool with 3 nodes with cookie persistence and standard HTTP service setup. After a node (N1) has been marked down by a health monitor we see that the following requests for a persisted session will be shifted (load balanced) to the two remaining nodes (N1 -> N2, N1 -> N3). So far, so good.

 

But we also see that some (not all) requests to the two "healthy nodes" lost their persistence (N2 -> N3, N3 -> N2).

 

We already tried different settings to "Action On Service Down", but this didn't change the behavior.

 

Any ideas / hints?

 

Unfortunately we are using BIG-IP 10.2.4 Build 817.0 Hotfix HF7, update is planned in a couple of months.

 

3 Replies

  • Are you using the built-in 'cookie' insert persistence method that uses the 'BIGIP' cookie?

     

    Just to confirm your issue: You've captured traffic to pool member N2 and are observing requests that contain the BIGIP cookie value that decodes to pool member N3's IP address and port (and pool member N3 has not been marked offline in that period)?

     

  • Hi,

     

    Without clarification how you figure out that requests destined (based on cookie) to N3 are going to N2 it's hard to say what's going on.

     

    Anyway - forgot about changing Action on Service down changes for HTTP traffic - if you wish to faster inform clients that member is down you can set it to Reject (if I can recall) but for sure Reselect will not work.

     

    Possible reason for request with cookie pointing to N2 being directed to N3 is lack of OneConnect. Without it LB is done on per TCP connection basis. Once TCP connection is directed to given member all packets belonging to this connection will be send to this member.

     

    If inside this TCP connection client will send HTTP request with cookie pointing to N3 (assuming that connection was LB o N2) this request will land on N2.

     

    So it's necessary to do the trace and review what headers are in client HTTP request (inside one TCP connection).

     

    Piotr