Getting Data In

Load Balance UDP syslog across an F5 to multiple heavy forwarders

pjaramillo
Engager

The goal is to have all of our syslogging devices point to a VIP on the F5 which will then load balance across multiple heavy forwarders. This allows for an HA configuration and easy expansion of forwarders.

The problem is only TCP syslog seems to work on the F5. UDP either doesn't work or logs with the source address of the F5. Can anyone recommend a good configuration for the F5 to log this correction across multiple forwarders?

jtacy
Builder

We're using the same approach; we use ACE in production but have also tested with F5. You can take advantage of the fact that syslog is a fire-and-forget protocol and therefore don't need to use SNAT; that will keep your source IPs intact. I would create a Standard UDP virtual server with a SNAT Pool of None. You might need to tune the default Action On Service Down on the pool to Reject; on the ACE we were having problems with active connections sticking to servers where the health monitor had failed.

Speaking of health monitors, we run both TCP and UDP on the syslog servers and use a TCP monitor; UDP monitoring didn't work for us.

Here's an F5 config that I just tested, hope this helps (note that the syslog sender, receivers, and F5 are all on different subnets):

ltm virtual udpsyslog_514_vs {
destination 10.10.10.10:514
ip-protocol udp
mask 255.255.255.255
pool udpsyslog_514_pool
profiles {
    udp { }
}
vlans-disabled
}

ltm pool udpsyslog_514_pool {
members {
    10.10.20.10:514 {
        address 10.10.20.10
        session monitor-enabled
        state up
    }
    10.10.20.20:514 {
        address 10.10.20.20
        session monitor-enabled
        state up
    }
}
monitor tcp
service-down-action reset
}

1midniterider
New Member

We are attempting to also load balance syslog. When I set Source Address Translation to None, then no data flows. It works when set to Auto Map, but the hostname gets set to the host and not the original client.

0 Karma
Get Updates on the Splunk Community!

New Splunk Observability innovations: Deeper visibility and smarter alerting to ...

You asked, we delivered. Splunk Observability Cloud has several new innovations giving you deeper visibility ...

Synthetic Monitoring: Not your Grandma’s Polyester! Tech Talk: DevOps Edition

Register today and join TekStream on Tuesday, February 28 at 11am PT/2pm ET for a demonstration of Splunk ...

Instrumenting Java Websocket Messaging

Instrumenting Java Websocket MessagingThis article is a code-based discussion of passing OpenTelemetry trace ...