Forum Discussion

Sharabh_111368's avatar
Sharabh_111368
Icon for Nimbostratus rankNimbostratus
Jun 28, 2017

iQuery: big3d version mismatch

Hi all, We have upgraded GTMs to 11.6.1 from 10.2.4. Some LTMs are still on 9.3 or 9.4 in our environment. iQuery seems to be ok except a flap we see everyday following an SSL handshake error which ...
application delivery
BIG-IP DNS
LTM
Samir_Jha_52506's avatar
Samir_Jha_52506
Icon for Noctilucent rankNoctilucent
Jun 28, 2017

The big3d process will attempt to renegotiate SSL keys every 24 hours. When the BIG-IP GTM system receives the SSL Client Hello message during renegotiation, the big3d process responds with a TCP FIN and closes. Its known bug 477240 in f5 GTM v11.5

1.To verify the big3d version in the /shared/bin directory, type the following command: /shared/bin/big3d -v

2.To verify the big3d version in the /usr/bin directory, type the following command: /usr/sbin/big3d -v

Upgrade require to mitigate this bug. see the article. Make sure all the F5 have same 

big3d -v
version, else it will create issue.

https://support.f5.com/csp/article/K16185

  • Sharabh_111368's avatar
    Sharabh_111368
    Icon for Nimbostratus rankNimbostratus
    Jul 20, 2017

    Hi, Thanks for the response. Not related to the bug as we're on 11.6.1 on GTMs. But yes, related to big3d version mismatch without a doubt. Not much support from TAC as of course it's still v9 on LTM :-), so have to live with a daily flap of iQuery unless we upgrade the LTMs. No joy with big3d upgrade as v9 doesn't seem to be able to handle v11 big3d version. v10 handles it well, just to add; not that we see any flap there for v10. You're right about regeneration/renegotiation of keys every 24 hours as that's when we see the flap. It shows "iqmgmt_receive: SSL error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure" and marks LTM down once. Then within seconds, the second attempt is successful and iQuery/ LTM is back online. During the same time, LTM shows "big3d[1154]: 012b2003:5: Unknown message type 191 from ::ffff:" so the best guess is that v9 LTM isn't able to handle SSL protocol/ciphers v11 GTM starts renegotiation attempt with.