NimbostratusPool member with sporadically listening service
We have following setup: a virtual server listening on port 80/http. Behind it is a pool member, which by default does not listen to anything. Only on manual intervention it runs acmetool (for creating a Let's Encrypt certificate request) - intentionally not as a daemon. As soon as it runs it starts listening on tcp port 4402. It then waits for the let's encrypt server to connect to the virtual server, which should forward the request to port 4402 on the pool member and the acmetool (which is supposed to respond to the Let's encrypt challenge). When the challenge is successful or failed the acmetool stops running (and listening).
I have only set up basic health monitors on the node (no http monitors).
This setup always fails, though and I cannot find anything obvious wrong with it, but that might be just me...
If I set up a webserver on the pool member, which listens (always) on e.g. port 4401 and proxies locally to port 4402, i.e. the manually started acmetool, all works fine.
One suspicion is that the F5 does not build the connection to the pool member fast enough when the acmetool is started and listens on port 4402!? I tried to add a delay in an iRule, but that didn't help - so this assumption might be wrong.
Does anyone know if this setup is supposed to work (if an active pool member starts to listen on a port - how fast is F5 expected to connect to it?)? If yes, what could be changed to make it work.
Any hints appreciated.
I recommend looking at how fast your monitor is configured to be (un)available. I recommend tcp_half_open (it's faster).
A very agressive monitor could be configured:
Interval: 1
Up interval: Disabled (it'll be online as soon as a succesful reply is received)
Time Until Up: 0
Time out: (however long you want the service to be available even when there's no successful response)
Manual resume: No
Additionally; you could add an alias service port. If the pool member is 10.10.10.10:4401 but the health monitor is to check 4402, you could specifiy 4402 in your monitor.
if an active pool member starts to listen on a port - how fast is F5 expected to connect to it
However fast your monitor interval + monitor up time + pool slow ramp combination is
Slow Ramp shouldn't prevent traffic as the intention described shouldn't generate too much of it... but you never know.
Possible troubleshooting:
Verify that you haven't configured a connection limit
There's a nice little tool called tcping (for windows). In cmd/powershell try running it before starting the service. Then you can see how quickly the vIP is online.
.\tcping.exe -t 10.10.10.10 4402
The mcpd process reports in your ltm log when it sees them member back online.
