Apologies if this isn't explained well, or if the answer is very obvious for more experienced posters....
I have a virtual server with 4 different pools associated with it. All four pools are configured exactly the same way, use the same IP, but with different service ports. Two of the pools appear healthy and have green status, but the other two are red (offline) and I can't work out why.
I can see that the affected pool members are up. They're just another outbound vserver I built, and I can see the healthy green status. Connectivity doesn't appear to be an issue because I can telnet from one F5 to the other no problem. I'm looking at the instances in my https monitor and I cannot see anything different between the working pool members and those that are not.
Perhaps there is something really obvious I am not thinking of?
Let me get this straight.. you have 2 different F5 instances, and there's one that's configured to forward traffic to VIPs exposed by the second one, correct?
There's 4 different HTTPS pools on different ports, all pointing to a VS on the second unit, which runs them on a single IP with different ports.
You're using the same HTTPS (standard? custom?) monitor on all pools, but two fail and two don't.
First thing that comes to my mind: on the "back end" F5, do all VS/pools forward traffic to the same nodes?
If you're using a custom string, you should also make sure that your monitor points to a resource that exists on all 4 services, ex. if you run "GET /health" then /health page should exists on all 4 services.
Also, if back end server are not the same, you should tune the "Host:" header in your monitor, in order for traffic to match.
The easiest way to test your monitor is running a curl command or something similar, via F5 cli :
(echo -e "GET /health HTTP/1.1\r\nHost: www.f5.com\r\nConnection: Close\r\n\r\n";sleep 1) | openssl s_client -connect 10.0.0.10:443
Hope this helps
The proxy server we hit requires SNI for inbound traffic coming from our side. We have input the ServerName in the serversslprofile to ensure that the SNI extension is in thr Client Hello. This works.
When we run about 20 tests, about half will work fine because we see the SNI extension in the Client Hello and we hit the API. The other half fail however because there is no SNI extension in the Client Hello and we can't access the API because the server has no idea which certificate to server to us.
When the connection doesn't work we get an error in the logs:
[ssl:error][pid25730:tid 140171399874304]AH02033: No hostname was provided via SNI for a name based virtual host.
Every time we don't see the SNI extension in the Client Hello, it has come from the Self IP. Every time we do see the SNI extension, it has come from the Float IP.
Apologies - disregard the above. Wrong thread.