Forum Discussion
HTTPS Monitor not working as expected
I have created an HTTPS monitor as follows:
GET /idauth/isAlive.jsp\r\n
The receive string is set as:
ALIVE
There are 2 servers and when i curl them i get the following:
First Server
curl -k https://server1.domain.com:8443/idauth/isAlive.jsp
OpenAM
Server is DOWN
Second server:
curl -k https://server2.domain.com:8443/idauth/isAlive.jsp
OpenAM
Server is ALIVE:
However. Both servers are being flagged as unavailable.
If I change the receive string to DOWN - both servers are flagged as available.
I have changed curl to verbose to check for separate words showing ALIVE/DOWN but this doesnt show anything:
curl -k -v https://server2.domain.com:8443/idauth/isAlive.jsp
* About to connect() to server2.domain.com port 8443 (0)
* Trying 172.31.151.143... connected
* Connected to server2.domain.com (172.31.151.143) port 8443 (0)
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES128-SHA
* Server certificate:
* subject: C=GB; ST=Scotland; O=STANDARD LIFE; OU=IS; CN=server2.domain.com
* start date: 2014-11-11 21:48:09 GMT
* expire date: 2028-07-20 21:48:09 GMT
* common name: server2.domain.com (matched)
* SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
GET /idauth/isAlive.jsp HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8y zlib/1.2.3 libidn/0.6.5
Host: server2.domain.com:8443
Accept: */*
HTTP/1.1 200 OK
Cache-Control: private
Expires: Thu, 01 Jan 1970 01:00:00 GMT
Set-Cookie: JSESSIONID=A847EA20D06FC26A9B944B9CB5CC397E; Path=/idauth/; Secure; HttpOnly
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 115
Date: Fri, 06 Feb 2015 13:17:35 GMT
Server: Anonymous
html>
head>
OpenAM
/head>
body>
h1>Server is ALIVE:
* Connection 0 to host server2.domain.com left intact
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
Has anyone seen anything like this?
27 Replies
- shaggy
Nimbostratus
this is definitely a strange issue. i don't see anything wrong in your configuration so far. next steps are definitely a packet trace and a support case (if you haven't opened one yet).
can you also post the pool configuration (tmsh list ltm pool (pool-name))?
- LyonsG_85618
Cirrostratus
list ltm pool POOL_SYST_IDAUTH_INTERNAL_LIVE_HTTPS ltm pool POOL_SYST_IDAUTH_INTERNAL_LIVE_HTTPS { load-balancing-mode predictive-member members { slglvmfi:pcsync-https { address 172.31.251.141 session monitor-enabled state up } slglvmfk:pcsync-https { address 172.31.151.143 session monitor-enabled state up } } monitor MONITOR_SYST_IDAUTH_INTERNAL_LIVE_HTTPS partition FEDERATION }
- shaggy_121467
Cumulonimbus
this is definitely a strange issue. i don't see anything wrong in your configuration so far. next steps are definitely a packet trace and a support case (if you haven't opened one yet).
can you also post the pool configuration (tmsh list ltm pool (pool-name))?
- LyonsG_85618
Cirrostratus
list ltm pool POOL_SYST_IDAUTH_INTERNAL_LIVE_HTTPS ltm pool POOL_SYST_IDAUTH_INTERNAL_LIVE_HTTPS { load-balancing-mode predictive-member members { slglvmfi:pcsync-https { address 172.31.251.141 session monitor-enabled state up } slglvmfk:pcsync-https { address 172.31.151.143 session monitor-enabled state up } } monitor MONITOR_SYST_IDAUTH_INTERNAL_LIVE_HTTPS partition FEDERATION }
- LyonsG_85618
Cirrostratus
This issue was eventually discovered as an application problem.
BIG-IP was, as always, not the problem.
Thanks
- Jeff_M_44528
Nimbostratus
I observed similar symptoms as well. Would you mind sharing more about the "application problem" you discovered please? - LyonsG_85618
Cirrostratus
Jeff. The monitor we were using was a .jsp file. Using this via browser or via curl worked (i.e. you got the expected response). However the developers investigated issue and when the F5 monitor was seen on server it did not respond in the same way as a browser. I'll try and get more info next week. Graham - Ellison_Zhang_2
Nimbostratus
I met similar issue. What method does F5 use for HTTPS monitor? curl , telnet, GET or openssl (I am using F5 11.3.0).
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com