For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

mfkk531_168091's avatar
mfkk531_168091
Icon for Nimbostratus rankNimbostratus
Jun 27, 2017

Uneven Traffic Distribution in the Pool. 2 members are receiving very less traffic

Uneven Traffic Distribution in the Pool. 2 members are receiving very less traffic.   VS is Performance L4 with default fastL4 profile   LB Method is Least Connections (Member)   LTM...
application delivery
BIG-IP
LTM
mfkk531_168091's avatar
mfkk531_168091
Icon for Nimbostratus rankNimbostratus
Jun 29, 2017

The logs are clean, the pool members did not fail at anytime.

 

We are using source address persistence but the clients are high number of differing IP addresses so this shouldnt have caused issue. The same setup in alternate DC is working just fine.

 

The client are NOT behind proxy. In fact the pool members are the proxy servers in this case.

 

I opened a case with F5 support and they stated this is caused by a glitch in Source Address Persistence going along with Least COnnections method. It happens rarely but no pattern or specific cause provided.

 

Solution provided by F5 - Do a failover to standby unit - this will close all connections on current device and re-establish new connections on the other device - that will clear up the distribution issue.

 

Result- It worked as they stated. Now we see evenly balanced traffic accross all 6 pool members after the failover.

 

Thanks for the replies and assistance!

 

  • Ed_Summers's avatar
    Ed_Summers
    Icon for Nimbostratus rankNimbostratus
    Jun 29, 2017

    That's very interesting - have not seen that before. Thanks for providing the work-around.

     

    Curious if the fail-over is required, or if the same result can be achieved by deleting all connections and persistence records for that VS?

     

  • mfkk531_168091's avatar
    mfkk531_168091
    Icon for Nimbostratus rankNimbostratus
    Jul 01, 2017

    Yes, that was the first recommendation from F5 support, but closing all connections on the VS would result in an outage. So failover was the best option.

     

  • mfkk531_168091's avatar
    mfkk531_168091
    Icon for Nimbostratus rankNimbostratus
    Jul 01, 2017

    ***Yes, that was the first recommendation from F5 support, but closing all connections on the VS (and waiting the 180s persistence to timeout) would result in an outage. So failover was the best option.

     

  • jaikumar_f5's avatar
    jaikumar_f5
    Icon for Noctilucent rankNoctilucent
    Jul 02, 2017

    Is this behavior found in 12.x alone. Can you also ask that & confirm. Is yes, is it marked as a BUG ID and article for that. Thanks in advance.

     

  • Ed_Summers's avatar
    Ed_Summers
    Icon for Nimbostratus rankNimbostratus
    Jul 02, 2017

    What variant of source address persistence were you using? If a record-based method (such as vanilla source-address) could you not just delete all of the persistence records when you deleted the connections?

    delete ltm persist persist-records virtual

    Not second-guessing the resolution to this - You got things back online given restrictions you had. Just understanding if other factors were in play here. This could be a frustrating one to troubleshoot having not known about this bug.