Forum Discussion

JRahm's avatar
JRahm
Icon for Admin rankAdmin
Oct 10, 2005

Passive 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.

4 Replies

  • drteeth_127330's avatar
    drteeth_127330
    Historic F5 Account
    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?
  • 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...
  • yes, 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?
  • drteeth_127330's avatar
    drteeth_127330
    Historic F5 Account
    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.