Our "WhiteBoard Wednesday" video series will highlight really cool and exciting features of the BIG-IP. In this video, I take a few minutes to walk through the workflow of an HTTP monitor and discuss the differences between the content and application health check monitors. Enjoy!
Clarifications on the Receive Disable String
A few individuals have asked about the timing regarding the receive disable string (and the reverse option) in the monitors. To clarify, the action on receive disable is immediate unless neither the receive nor the receive disable strings match, then it falls back to the timeout process. This table should help:
Matches Receive Str
Matches Receive Disable Str
Status
Icon
Timing
YES
YES
Up (Enabled)
Green Circle
Immediate
YES
NO
Up (Enabled)
Green Circle
Immediate
NO
YES
Up (Disabled)
Black Circle
Immediate
NO
NO
Down (Disabled)
Black Diamond
Timeout Process
Clarification on the Reverse Option
Also in the monitor, but not directly discussed in the video, is the option to mark the pool member down if the receive string is matched by selecting the reverse option in the monitor configuration. Whereas the receive disable setting is more ideal for controlling graceful entry into maintenance windows (by allowing active/persistent connections,) the reverse option immediately marks the pool members hard down.
Let's say I use Least connection load balancing or any method that distributes load approximately even and lets the WMI monitor that I place marks down a particular member using its perfomance check and I have active connections that are to be reassigned , what takes priority here ? Or Do I need to specify action on down condition.
the LB algorithm doesn't play into the status of a pool member. As far as your connection is concerned, yes, the action on service down is what dictates where the connection currently attached to a now down service will go, if anywhere.
Jason, good preso. Can you explain when you would want to use 'receive disable string' in comparison to the 'reverse' option. Seems like its one of the same. Thx,
Hi NikhilB, certainly reverse can be used in much the same way, but to use only reverse is to not really validate a working application, rather you are assuming a functional app in absence of the receive string. By using receive string AND a receive disable string, you validate the app under positive function while capturing the negative scenario as well.
Thx Jason. So to recap from your preso, we must have a receive string that works and until that fails, the receive disable string value kicks in and takes the pool member/s down almost immediately without waiting for the entire timeout value if we didn't have one?
Almost, when the receive string no longer matches, but the receive disabled string does match, it disables the pool member, which allows active connections to bleed off but does not allow new connections. when neither string matches, then the pool member is hard down. Sorry i didn't make that clearer in the presentation. Details: https://support.f5.com/kb/en-us/solutions/public/12000/800/sol12818.html?sr=43351573
It seems that using 'reverse' would immediately turn the member down whereas a 'receive disable string' value when hit, will end connections gracefully. Many thx again for your time presenting and explaining this.
