Solaris Server instances ( pool members ) using TCP monitor health check

What exactly do you mean when you say behavior is different with Solaris? The monitor is only attempting to perform a three-way handshake on the specified TCP port. This shouldn't be affected by host operating system.

Actually it could be - I've seen it happen at one point, not on Solaris but still. The BIG-IP cycles through a number of source ports for the monitors and it could happen that connections lie in a time_wait state in the server's connection table for a longer time period and if the connection is in a time_wait state when the BIG-IP has cycled through the ports and starts re-using that port the monitor will fail. I think the server simply ignored the new monitor connection if I remember correctly. But this was an early version 10 and I think the BIG-IP has become less aggressive when it comes to recycling old ports in later version actually. Still... it might very well be an issue - do you see the pool members flapping a lot?

The way I discovered this was when we did a fairly long tcpdump of the monitor traffic and I noticed that the server did not respond to the monitor connection. My natural instinct would have been to assume there was a problem in the server if wireshark hadn't actually pointed out that the port had been re-used and sure enough, the BIG-IP had used the same source port earlier in the capture. So that is a behaviour to look for.

We all have this kind of problems biting us. I wonder why there still isn't a sol article (I am not aware of one) to warn about and advise effective ways of dealing with this; admittedly this can get tricky.

Well, I can't write a sol for you but I can tell you what we did back then - we made liberal use of external monitors, since that seemed to recycle source ports less aggresively than the internal monitors. Maybe bigd has its' own method for assigning source ports?