Custom TCP Monitor

Here is a link to something that can be done via custom shell script.

 

http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/HTTPMonitor_cURL_BasicPOST.html

 

In this example they are using cURL to send information and expect a return. You could end up writing some IF ELSE statement which would ultimately result in a status that is either UP or DOWN

 

I hope this helps

 

CB

An external monitor might work well. But, to make the call directly, we would need to build our own executable and place it on the F5. There are some maintanence issues with doing this, so we would rather not go that route if we can help it. Any other methods we can use here?

I think I found an excellent way to create this monitor. I found that if we call these apps by passing all of the pieces at once, the application works fine. After digging a bit, I was able to find ways to embed all of the special characters that are needed for a request to the application into the Send field in a custom TCP monitor:

 

 

https://support.f5.com/kb/en-us/solutions/public/4000/100/sol4186.html

 

 

However, I ran into a wall that I don't know if I can scale. The send string includes ASCII null chars. These should be able to be escaped as:

 

 

\x00

 

 

However, it seems the BIG-IP web interface doesn't allow these chars. For, I got an error when trying to add the custom monitor (see attachment). Is there some other way to get these into the system?

Per SOL4186 I don't think you'll be able to use a null in the send or receive string:

 

 

"Note: The BIG-IP system does not allow the ASCII character 0 (NUL)."

 

 

I tried adding this in both \x00 and \x000 format through the GUI, the CLI and the bigip.conf file but all attempts resulted in the 'embedded zero' error.

 

 

You could either check with F5 Support on why this restriction is in place or use an external monitor to send the null. A standard TCP monitor would be simpler and more efficient, so it might be worth checking with F5 on this.

 

 

Aaron

I have contacted Tech Support. We will see what they have to say. I'll post their response here when I get it. Thanks for all your help so far.

Tech Support said that there have been a few other requests for this kind of thing. However, they didn't know the reason for the design. They will be investigating further. They thought the NUL char was used as a delimiter for the monitor program. Hopefully, the developers can find the time and methods to fix this. We would certainly appreciate it.

 

 

For now, I will use an external monitor in conjunction with netcat and see if I can simulate the same functionality. Thanks for your help.

Using netcat from an external monitor is a good workaround. I'd be interested in what Support finally comes back with. Please do reply back when you get feedback from them.

 

 

Thanks,

 

Aaron

I'll post what they tell me. I'll also share what I eventually come up with using netcat. Hopefully, it works just as well as the native TCP monitor.

From what I've read from Deb in particular, an external monitor will never be as efficient as using an inbuilt monitor. So having F5 provide support for nulls in the send string would probably be the most efficient solution. But please do post your netcat based solution.

 

 

Thanks,

 

Aaron

Alright, I have implemented an external monitor script and the monitor profile needed to run the script from within the F5. Running the script from the prompt works fine. The following call returns "UP" when the application is listening properly and nothing when it is not.

bash runBerryCall 10.1.1.1 18888

However, the same pool member is marked down by the monitor when the BIG-IP runs the external monitor. See attachment for the monitor's settings.

I'm guessing the reason for this is the IP address format that is passed to the script. From the articles I have found, it seems the IP is passed in "IPv4 mapped address notation":

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=151

For, netcat doesn't like the format of the IP address. This fails with the following error:

  
 bash runBerryCall ::ffff:10.1.1.1 18888  
 ::ffff:10.1.1.1: forward host lookup failed: Unknown host  
 

NetCat 6 fully supports IPv6. How can I figure out what version of netcat is installed on the BIG-IP?