Forum Discussion

werner_verheyle's avatar
werner_verheyle
Icon for Altocumulus rankAltocumulus
Oct 29, 2020

external monitor GTM

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 .

application delivery
BIG-IP DNS
EAV monitor

2 Replies

Sort By
  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Nov 01, 2020

    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.

  • jaikumar_f5's avatar
    jaikumar_f5
    Icon for MVP rankMVP
    Nov 02, 2020

    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.