On Tue, 22 Nov 2011 06:22:56 -0600, 陆仲达 <zhongda.lu@xxxxxxxxxxxxxxxxx> wrote:
Follows:
Does anyone know about how to drop an idle connection when timeouts?
Thanks for any feedback in advance.
Best Regards.
Lu Zhongda
I think you are referring to what is called "dead gateway detection." There are patches for current kernels to allow netfilter to do this (http://www.ssi.bg/~ja/#routes).
I think these patches allow the kernel to determine when the nexthop router is down, but I don't think they will detect failure beyond that (several hops out). However, I did not try the patches.
In my investigation of the alternatives for detecting a bad uplink and adjusting the routing accordingly, I found an open source program, lsm (Link Status Monitor, http://lsm.foobar.fi/), which actually does configurable ping traffic analysis (to any IP) to determine when an uplink should be removed or replaced. I am not sure, but I think this level of control is not available through the kernel patches linked to above.
lsm detects failed links and executes an user-supplied script on each failure or recovery event, passing parameters with info on which interface was involved and whether it is "up" or "down". You can rewrite your firewall script to accept these lsm-supplied parameters to readjust any load-balancing routing, send emails to announce the event, etc. This will become clear when you check out the lsm package.
If more than one interface may be down at the same time (which is my case), the "state" of the interfaces will need to be saved. This is because lsm only notifies when a single link changes. I suggest using a bit field saved to a file, using bit-wise operators. That's what I did, using bash.
(Since lsm keeps state information about all the monitored links, it would be interesting to modify lsm to pass a "state" bitfield as one of the parameters upon every state change.)
Good luck!
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
