cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.

external monitor GTM

werner_verheyle
Nimbostratus
Nimbostratus

We are using an external monitor on our F5 GTM (version 12.1.2) for sending curl statements to an openshift platform (https call constructed with DNS name & uri).

 

Up till now this seemed to be working.

 

But now for some applications hosted on this openshift platform , we are seeing strange behavior , when testing in CLI with curl statement like "curl -skv https://<application-name>/probe/liveness"

--> 2 out of 3 requests are coming back with "HTTP /1.1 200 ok" which is the expected answer

--> 1 out of 3 requests is coming back with 'HTTP /1.0 503 "

 

We also have some LTM units in same network & when doing the same request from LTM , we always get the "HTTP /1.1 200 ok" .

 

So the behavior seems only to be present on GTM , not LTM units.

 

When diving into SSL answers which are failing we mainly notice :

* server is presenting different certificates (failing call is using different certificate than the ones that are working)

* failing calls we see answer coming back in http /1.0 and giving a 503 response (rather than answering in 1.1

 

My main problem is that we are only seeing this kind of behavior on GTM . We never have this behavior on LTM units & even tested from other stations .bit here we are always getting the correct answer .

2 REPLIES 2

Simon_Blakely
F5 Employee
F5 Employee

Have you checked the IP address of the failing requests?

 

Is it to an expected pool member?

 

Monitors should probe the IP address supplied to the monitor, and shouldn't do a DNS lookup on a name.

When you do the manual curl testing, you are getting 2 different responses, where you able to compare the successful one with the failed one. Instead of the FQDN, try doing curl with the IP and see what's happening.

 

Possibly, when you try doing with the FQDN, its resolving to 2 different IP's. Maybe one is working and the other one is not working. Find how many records are there for the FQDN. See if there's any issue on the App servers too.