Forum Discussion

Tuckson's avatar
Icon for Altostratus rankAltostratus
Jun 27, 2021

reversed port check (tcp)



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: 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?

3 Replies

  • 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.

  • You may check this old post as your issue sound simillar: