Forum Discussion
JRahm
Admin
AdminPassive monitoring with iRules
Our application folks have an app that until now has been behind a LocalDirector, which does passive monitoring. Now that they are behind the BigIP in the lab environment, their error logs are filling up with an uncompleted client connection (tcp monitor) Any advice on something like this
when SERVER_RESPONSE {
if { [IP::protocol] eq "1" } {
[LB::reselect] pool [LB::server pool]
}
}I'd expect that if the port is no longer available, the server will respond with ICMP message and I'll reselect.
Also, any additional IP:: accessors on the horizon? I'd like to have access to ICMP types.
- I don't think that will work. icmp processing occurs before virtual server matching, so you can't write an iRule to override how the icmp is handled. That being said, if the failed connection is going through the virtual server, then you should get an LB_FAILED event. Or is it a BIG-IP tcp monitor that's failing?
Brian_Gupta_115Nimbostratus
Have you tried the TCP half-open monitor?
-Brian
P.S. - I am gathering that the TCP monitor is filling their application logs with failed connection attempts...- JRahmyes, the tcp monitor is filling the logs with errors...tcp_half_open may be an option, I'll talk with the application folks.
Regarding the LB_FAILED event, what are the timers associated with this, and are they configurable? - LB_FAILED is triggered in a variety of circumstances. I'll list a few off the top of my head:
a) no pool selected
b) no available pool members in selected pool
c) no route to pool member
d) failed to connect to pool member
With regard to d). The "max retrans syn" option in the TCP profile will affect the timeout.
