Forum Discussion

Stan_Ward's avatar
Stan_Ward
Icon for Altocumulus rankAltocumulus
Nov 14, 2017

HSL logging hides VS status

I have a conventional L7 VS configured for SSL offload with a single default pool using an HTTP monitor. Both pool members are down (red), as is the pool itself. But the VS still shows green, and the VS is never marked down in the GUI or the LTM log. It appears that the use of HSL logging in a logging iRule is the culprit, but it screws up logging and troubleshooting. Is there any way to not have the HSL log pool not affect the status? We have this rule on nearly every VS, making the status screens useless.

 

application delivery
BIG-IP
iRules
  • rob_carr's avatar
    rob_carr
    Icon for Cirrocumulus rankCirrocumulus
    Nov 15, 2017

    That sounds like a bug to me - I can't think of any reason why the availability of the HSL pool would trump the lack of availability in the resource pool. What happens if you remove the monitor on the HSL pool?

     

  • Simon_Blakely's avatar
    Simon_Blakely
    Icon for Employee rankEmployee
    Nov 15, 2017

    Try the following structure for your HSL irule 

    when RULE_INIT {
   set static::my_hsl_pool syslog_server_pool 
}   
when CLIENT_ACCEPTED {  
   set hsl [HSL::open -proto UDP -pool $static::my_hsl_pool]  
}
when HTTP_REQUEST {
    Log HTTP request as local7.info; see RFC 3164 Section 4.1.1 - "PRI Part" for more info
   HSL::send $hsl "<190> [IP::local_addr] [HTTP::uri]\n"
}

    This is due to

    K6514: The BIG-IP system may not reflect the expected status for virtual servers that use iRules, HTTP classes or local traffic policies to select a pool

    The HSL pool is being attached to the virtual by the irule, even though it is not a target of the VIP connections, and the virtual inherits the HSL pool status. This prevents the HSL pool from being deleted from the config while being used in an irule attached to a virtual. The above irule structure bypasses this link.