Forum Discussion
- webguy96Nimbostratus
You could simplify this even a bit further by placing all (3) pool members into a single pool and switching from the default distribution of 'adaptive' to 'replicated' for your Log Publisher Destination combined with following iRule.
when CLIENT_ACCEPTED {
set hsl [HSL::open -publisher /Common/syslog_publisher]
}
when CLIENT_DATA {
HSL::send $hsl "[UDP::payload]"
}
- AndreasWallNimbostratus
I have the same scenario and I like the simplicity in the suggested solution. I on the other hand have netflow that I want to duplicate to two different flow collectors.
I tested it and packets are duplicated towards the two destinations but the source address is set to the self IP of the F5.
I tried adding snat under the CLIENT_ACCEPTED section and setting it to the client source address but it did not make any difference.
Is there a way to preserve the source IP address when using HSL::open/HSL::send?
- Scott_PayneEmployee
You can't do that with HSL, but you can do it with a sideband connection. What follows is an example iRule:
when CLIENT_ACCEPTED {# The client source address
set clientIP [IP::client_addr]
# The client source port
set clientPort UDP::client_portif {[catch {connect -myaddr $clientIP -myport $clientPort -timeout 1000 -idle 30 -protocol UDP -status conn_status 10.1.20.200:9995} conn_id] == 0 && $conn_id ne ""}{
log local0. "Connect returns: $conn_id and conn status: $conn_status"} else {
log local0. "Connection could not be established to sideband_virtual_server"
}}
when CLIENT_DATA {
if {$conn_id ne ""} {
# grab UDP payload
set data [UDP::payload]# Send the data out to the netflow collector using the source IP and port from the client
send -timeout 1000 $conn_id $data
#close $conn_id
}
}A version of this was used to send Netflow data to another harvester / collector (in addition to the pool on the virtual server)
- AndreasWallNimbostratus
Yesterday I found out that HSL::send will use the self ip of the outgoing interface. Using the snat command will make no difference.
HSL sends logs from TMM, unlike native syslog-ng which uses mgmt. To get the mgmt, i think you have to create a static route table.
- DennisJannNimbostratus
I had a similar requirement and came across this answer to use High-Speed Logging:
I wound up creating three pools (e.g., syslog_514_pool1, syslog_514_pool2, syslog_514_pool3), each containing a single syslog server.
Then created the following iRule to duplicate the traffic.
ltm rule syslog_message_duplication_rule { when CLIENT_ACCEPTED { set syslog_pool1 [HSL::open -proto UDP -pool syslog_514_pool1] set syslog_pool2 [HSL::open -proto UDP -pool syslog_514_pool2] set syslog_pool3 [HSL::open -proto UDP -pool syslog_514_pool3] } when CLIENT_DATA { HSL::send $syslog_pool1 [UDP::payload] HSL::send $syslog_pool2 [UDP::payload] HSL::send $syslog_pool3 [UDP::payload] } }
Apply the iRule to your port 514 UDP VIP.
ltm virtual vs_syslog_514 { destination 10.1.2.3:514 ip-protocol udp mask 255.255.255.255 profiles { udp { } } rules { syslog_message_duplication_rule } source 0.0.0.0/0 translate-address enabled translate-port enabled }
We've been using the above configuration in production for about 6 months and the team that manages syslog services has been satisfied with the solution.
Alternately, you could take a look at this iApp:
https://devcentral.f5.com/codeshare/udp-tcp-packet-duplication
- RicoCirrus
You can configure a UDP VIP just like you would a TCP VIP. The only change needed is to change the protocol profile to UDP. The magic of BIG-IP will take care of the rest!