HSL sending issue

but the only way to have it working, is for me to add a " log local0. "$test" "

it should work without log local0 command. have you tried to move HSL::open to CLIENT_ACCEPTED?

but the only way to have it working, is for me to add a " log local0. "$test" "

it should work without log local0 command. have you tried to move HSL::open to CLIENT_ACCEPTED?

It should work either way (HSL::open in CLIENT_ACCEPTED or HTTP_REQUEST), but much more efficient in CLIENT_ACCEPTED. Do you see any log messages to the remote syslog? If not, first verify that BIG-IP is at least trying:

tcpdump -lnni  port 514

But the only stuff i see written is my step_3_ and step_4_ on the remote log server. but no data...

I'm a little more confused now. You've issued both local and HSL log statements. The local log statements should be going to /var/log/ltm on the local BIG-IP, unless you've configured remote logging elsewhere in the config or in syslog itself. You're only sending one string to the HSL. Is that showing up on the remote syslog server?

Can I assume you haven't touched Remote Logging on the BIG-IP configuration and haven't made any changes to the syslog configuration directly? If that's true, then let's focus on remote logging only. The log local0. statement will, by default, log to /var/log/ltm locally. Let's remove all of that code and just do HSL::open and HSL::send. With that change we can focus on 1) the BIG-IP config, and 2) the remote syslog server's config. So:

1. Can the BIG-IP access the remote syslog server?
2. Is the remote syslog server listening on the default port (514)?
3. Is the remote syslog server using TCP or UDP?
4. Does the remote syslog server require any kind of access control?
5. Can you send syslog messages to this remote syslog server from other servers?

You make me remember that i did try to set Remote Logging profile (and it must be still set on my VS). I never succeed to have it works neither understand the documentation about it.

I will unset it and test again.

1.BIG-IP can access the remote syslog server. 2.514 is the default listening port. 3. Both TCP and UDP are allowed. 4. No access control 5. Yes, many other devices did send logs successfully.

Okay, here's a thought:

when CLIENT_ACCEPTED {
    set hsl [HSL::open -proto UDP -pool syslog_server_pool]
}
when HTTP_REQUEST {
    HSL::send $hsl "Time: [clock clicks] - request from - [IP::client_addr] to [HTTP::uri]\n"
}

Based on the above TEST iRule, create a syslog server pool that contains a random IP address - something that isn't used by anything else. Then in your TCPDUMP, open it up to all interfaces and look for syslog port (514) traffic going to this IP:

tcpdump -lnni 0.0 port 514 and host 10.10.10.10

Apply this iRule to the VIP and test. If you see ANY syslog traffic then you know that the configuration is probably correct on the BIG-IP side. Look at your original syslog pool and make sure a monitor isn't marking the nodes down.

I don't think you caught my last recommendation. Create a NEW syslog pool that contains an IP address that isn't used ANYWHERE on your network. Use that pool in your HSL::open statement, and then watch TCPDUMP for port 514 traffic sending to that address. If you filter it down to just port 514 and this IP address, you shouldn't see any other traffic than what HSL might be sending.

By the way, what version are you running?

Silly question maybe, but is the VIP in the same partition? Try:

when CLIENT_ACCEPTED { 
    set hsl [HSL::open -proto UDP -pool /CLI01_COPR/POOL_ABC_TEST] 
} 
when HTTP_REQUEST { 
    HSL::send $hsl "Time: [clock clicks] - request from - [IP::client_addr] to [HTTP::uri]\n" 
} 

Okay, another silly set of questions.

1. Please try this and see if it works:

   when CLIENT_ACCEPTED {
       set syslog_pool "/CLI01_COPR/POOL_ABC_TEST" 
       set hsl [HSL::open -proto UDP -pool $syslog_pool] 
   } 
   when HTTP_REQUEST { 
       HSL::send $hsl "Time: [clock clicks] - request from - [IP::client_addr] to [HTTP::uri]\n" 
   } 
   

2. Does your syslog pool attempt to route through the management network?