Forum Discussion

Martin_Renneke_'s avatar
Martin_Renneke_
Icon for Nimbostratus rankNimbostratus
May 24, 2017

LTM has lost sticky persistence after one node went down

Our LTM (Version 10.2.4 - Build 817) Hotfix HF2 and HF7 installed will loose the sticky persistence, after one of the nodes is down. After the node is down the LTM will transfer requests to a wrong node. Example: Node 3 of 16 is marked down. Afterwards we observe a request routed via the big IP cookie to node 7, but it arrived on node 10. Is there someout to help on this?

 

4 Replies

  • Hi,

     

    Need a bit of details here :-)

     

    I assume:

     

    Cookie persistence used - what type? Cookie Insert/Rewrite/Passive/Hash?

     

    If node pointed by cookie in request is down BIG-IP has to use LB algorithm to select new node, so for sure stickiness to original node will be gone.

     

    I can't comment on your statement "Afterwards we observe a request routed via the big IP cookie to node 7, but it arrived on node 10" - it depends which cookie persistence is used.

     

    How do you know that cookie is pointing to node 7 and request is in fact send to node 10?

     

    Piotr

     

  • Persistence logic would vary based on the connection type. If its an active existing connection and the pool member is down, then LB algorithm wouldn't be triggered here. This is where we use the action on service down concept.

     

    But if the connection is close, and the following request comes from the same source with the pool member down,then LB algorithm would be applied.

     

    Reset your persistence stats and see whats happening. LB algorithm would choose just 1 member, it cannot jump between 7 and 10.

     

  • Thank you Piotr,

     

    Regarding your questions: The selected option is "cookie insert" We do have Agents established on the member, which are logging every http request at the test system. The behavior is inline with your second post, BUT additional HTTP requests for a member which is not marked down are arriving at the wrong member. We wonder how we can find out, why the F5 seems to send the requests to a wrong member? Is there any option to increase the log level for specific events?

     

    Thank you again. Martin.

     

    • dragonflymr's avatar
      dragonflymr
      Icon for Cirrostratus rankCirrostratus

      Hi,

       

      I really don't know what options and behavior is in v10.x - it's quite old. I am dealing mostly with 11.x, 12.x, 13.x

       

      Can you confirm situation:

       

      • First request send to member 1 (according to cookie value)
      • Second request with the same cookie value is send to member 2 - even if member 1 is still up

      Is that the case?

       

      If so there is either kind of bug or:

       

      • You have OneConnect profile attached to VS and second request is containing cookie value pointing to member 2 - that is exactly as expected - OneConnect is doing LB on per HTTP request base, not per TCP connection base. Easiest way to check is if you can log headers on members, see if BIG-IP cookie is the same in request send to member 1 and member 2. If you can't log headers run tcpdump on BIG-IP or members and see what headers are in request
      • Client is sending request with BIG-IP cookie and without it (this is as well only relevant when OneConnect is used). Request with cookie will be send to member according to cookie value, without to any new member selected by LB decision.
      • There is some iRule, traffic class or something else causing this behavior
      • You have monitor flapping - member goes down/up in rapid succession - should be visible in logs.

      Piotr