Forum Discussion
v10.2 Health monitors
I have done a bit fo searching, but haven't seen anything regarding this, so I hope this has not been asked to death. Anyhow we are in the proccess of upgrading from 9.4.7 --> 10.2 and I am having some issues with health monitors. I was able to make some of them work, but today I found a whole bunch of pools that were using a base https monitor with just "get /" are failed. I am assuming that 10.2 is adding HTTP1.1 to the request which is forcing me to send a Host header, but even when I create a new monitor with the following requests I still get no response.
GET / /HTTP1.1\r\n Host:\r\nConnection: Close
or
GET / HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n
or
GET / HTTP/1.1\r\nHost: \r\nConnection: Close\r\n
I have tested using curl with the following request and I get a response just fine.
curl --insecure -H "Host:" https://10.1.2.3
I am wondering if something major has changed with monitors in v10.2 which is causing this to fail.
- Chris_Miller
Altostratus
Here's what I'm using in 10.2:
GET /sample.html HTTP/1.1\r\nHost:www.sample.com \r\nConnection: Close\r\n\r\n
Response String:
HTTP/1\.(0|1) (2|3)
Your second example looks just like mine accept you're just doing a get for root...odd that it's not working. 
hoolioCirrostratus
In 10.2, the monitoring daemon, bigd, no longer automatically appends two CRLF's (\r\n) to the end of the monitor send string. So you need to include them yourself as Chris has shown in his example. I agree that the second example should work.
For tips on troubleshooting LTM monitors, you can check this page:
http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/TroubleshootingLtmMonitors.html
Aaron
smp_86112What I suspect is happening is that your web server is returning a 302 for the GET /. If you GET / with a browser, is that the URL you end up at, or do you end up at ?
- I guess I should update this to let everyone know that I have gotten this to work for most of these using this.
GET / HTTP/1.1\r\nHost: \r\nConnection: Close\r\n\r\n
I am still having an issue on one or 2 monitors, but I am sure I can work through them.
Regarding receiving a 302 as a response, this really shouldn't cause a monitor that is looking for any response to fail. I mean a 302 is in fact a response right? Have you had issues with this in the past because in my experience unless you are looking for something specific in the response anything will cause the monitor to mark the node up. I have even seen a 500 keep a server live. - smp_86112Oh, I thought that was the middle option you wrote above which you claimed didn't work. And I must have missed your statement about not using any receive string, but if that's the case, then yes I think any HTTP response will result in an Up status.
Glad to hear you got it working. - Luke_Lehman
Employee
I'm running into a similar issue here.
Our current monitor is this:
GET / HTTP/1.1\r\nUser-Agent: CompanyBigIP\r\nHost: \r\nConnection: Close\r\n\r\n
We only have problems with servers that have settings in IIS that "Accept client certificates." I know there is a place in the monitor config that allows you to use a client cert and/or key.
However, I am curious as to why it worked on 9.4.7 and now doesn't work on 10.2.0 ?
Any ideas?
