Forum Discussion
JimRiley_106607
Nimbostratus
Nimbostratuspersistant connection
An active in-use node has two health monitors. One health monitor fails and the F5 properly sets the node to RED diamond / inactive state. However, the F5 still sends data to the node. The data in this case is from the same originating device and same IP address, within a few minutes of the failed health monitor.
I need to immediately stop data traffic to the node when either health monitor fails.
How can I get the F5 to break any existing remnant persistance, and send data to other alternate nodes (which would still be green/active)?
thanks
3 Replies
scheuriHello AlexBCT
Thanks a lot for your reply.
- No, I haven't tried to limit the speed. Its certainly worth a try and might give me a hint where to look for the root cause
- The partitions have been checked and I have enough space left for the ISO (many times over actually). So I think that shouldnt be the problem unless F5 is not showing the correct sizes of the partitions on CLI
- Yes, I have taken a qkview. However, as I don't exactly know what I am looking for I am not entirely sure I am missing something. Nothing was obviously faulty or an issue.
- I am uploading via Management-IP. Unfortunately trying to use the selfip will not be easy as I have no real access to that network (and a file on a server that would make me able to reproduce the issue). Thanks though, it might be worth a try once I can actually test it.
AlexBCTCumulonimbus
Hi scheuri,
That's an interesting problem indeed!
Here are a few tips that are hopefully helpful in getting to the bottom of it;
- Have you tried limiting the speed of the upload? (In WinSCP, you can do this under Transfer Settings, but most other tools should have it too) And then check if it still happens. Not that it SHOULD make a difference, but may give an indication of what may be causing it.
- Have you checked the size of the partitions on your system as well? (in linux CLI: "df -lh" - ensure that the /shared partition has enough space left?
- Have you taken a qkview file of the box and checked iHealth for any indications?
- Are you uploading via a SelfIP or via the Management IP? Can you check (if allowed), if the other option works better? Again, SHOULD not make any difference, but may give an indication.
hoolioCirrostratus
Hi Jim,
You can set the pool option for 'action on service down' to reset. The default is to leave existing connections as they are.
Aaron- JimRiley_106607The Action on UNavailble was set to RESELECT, which seems like it would stop existing connections to node-1 and move over to node-2, but it wasn't.
You mention a RESET option, I guess that would mean the REJECT option, since the help states that will do a 'RST' (reset).
I will tryout the REJECT option; would the DROP also work - as long as the F5 will begin using the node when the health checks report it is again ACTIVE (available).
Jim Riley - hoolioReselect only works for these cases:
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-concepts-11-1-0/ltm_pools.html
You should configure the system to select a different node in certain cases only, such as:
•When the relevant virtual server is a Performance (Layer 4) virtual server with address translation disabled.
•When the relevant virtual servers Protocol setting is set to UDP.
•When the pool is a gateway pool (that is, a pool or routers)
And yes, I meant reject which sends a reset for TCP connections. Drop would potentially work as it removes the LTM connection table entry and causes LTM to send a reset to the client and pool member on the next packet from either side. Reject just works quicker to get to the same point. No matter which option you select, LTM will start selecting the pool member again for new connections once it's marked up by the monitor(s).
Aaron
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}