Forum Discussion
afreudenr
Nimbostratus
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.
HeinoCirrus
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.
afreudenrHi Heino - thanks a lot for the quick reply. Your tips helped me figure out what was needed to get it working. First - after using tcping - I realized that the acmetool was only listening on localhost when started (my stupid oversight). But after fixing that I still needed to play with the monitoring interval and a delay I had added as an iRule to get it working.
It works now e.g. with a 2 second tcp monitor interval and a 3 second delay in the iRule. Longer tcp intervals and shorter delays make it fail sometimes.
I'll play around a bit more with the parameters and might give the alias service port a try (which might avoid the monitor interval dependency).
It looks a lot more promising now - thanks again!
- afreudenr
One more update: I tested the service port alias using a different port and that works even better. No delay or monitor interval adjustments needed. As long as the alias port is continuously up the connection to port 4402 is set up immediately, which solves my problem.