In F5 (v12) we can create a tcp check. So I created one. Very simple.
It is attached this this pool/poolmember
I can reach the member and the checkport (8000) from the cli of the F5
Now on this page: https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-monitors-reference-11-5-0/3.html I read (in TCP settings table)
"Note: If you do not specify both a Send String and a Receive String, the monitor performs a simple service check and connect only." and "Note: If you choose to set the Reverse setting to Yes, the Receive Disable String option becomes unavailable and the monitor marks the pool, pool member, or node Down when the test is successful."
So when I read that, and with the way I set things up, and the fact I can nicely connect when port 8000 is available, I expect the poolmember to be disabled whenever the connection to port 8000 on it's IP can me made and to be enabled whenever the connection can NOT be made.
However, the only state this check ever causes is ' disabled'.
What is going wrong here?
You may check this old post as your issue sound simillar:
Thnx for your reply.
Yes, it's similar. And I indeed already found a way to accomplish it with an external monitor.
However, there's 2 reasons why I still ask this question.
1) All over the internet I encounter warnings that external monitors are resource heavy. Which is logical because each time a check is fired, a bash shell is started. This goes into serious numbers when hundreds of servers have this check attached and fired regularly.
2) As far as I read the documentation correctly it says that when send and receive string are not BOTH filled in, all that is done in the (reverse) tcp check is just a connection check. And for a reverse connection check it makes no sense to go or stay down when no connection can be made. So either I am doing something wrng or this is a nasty bug, which appearantly s there for a long time already.
I really think that F5 just have not explained good the reverse monitor check thing and this is why we all have issues with it. They may tell you that "it is not a bug it a feature" or something like that. For now the external monitor maybe your option but monitor the F5 device for CPU and memory issues as the external scripts may cause cpu or memory leakage in some versions or if the script is not closing correctly the connection or even becuse a bug:
You may raise a TAC case to see if this solved in any version at all and also share it here as I wish also to know but from what I have seen they may ask you to raise a request for enhancement but I could be wrong.