Duplicate syslogs being delivered

I'm trying to work out what's happening here.

• You have devices out in the field configured with 2 Syslog IP's(Presuming for redundancy?) these are both VIP's that sit on the same F5 Pair?
• You have two VIP's on the F5, separate IP's, each configured on port 514
• Behind the VIP's you have a pool which includes your syslog collectors ?

Because your Client devices are sending 2 Syslog instances you're wanting the F5 to include some intelligence to drop one of the requests?

Can you not just have one IP configured in the first place, as its the same infrastructure its configured on?

Apologies if I've got the wrong message.

I've to second Iain's initial thoughts... ;-)

Cheers, Kai

The Syslog solution is clustered across our two datacentre's using a private link, so not active/standby in respects to the infrastructure utilized for the logging servers. So to ensure logs are still received from the remote peer (stand alone device) in the event of a public link failure it has two VPN's configured one to each DC, as a result duplicate logs are being registered within the logging system.

What I've been asked to confirm is can the F5 in each DC with a VServer with an IP specific to the range within its own DC, with the same pool members perform an upstream check for the VPN tunnel being available. Then have only one VServer active i.e. DC1 but when the VPN into DC1 is found to be down the VServer in DC2 become the active VServer.

Hope this doesn't muddy the water further than it already is.

Are the F5's aware of each other?

It sounds like you'd be best off with a GTM infront of the solution and loadbalancing with the DNS name (If possible)

You could configure a monitor to check an Alias address "Upstream", such as a loopback address on a remote router.

Thanks for the suggestions, after discussing the issue with the SIEM team the duplication issue looks to be down to how the collectors receive the logs. If all the logs got to one collector then it can de-dupe them, if logs are received over multiple collectors that's when the issue occurs. So an initial solution is to see if having the pool members prioritised so traffic is only forwarded to one collector at a time until the highest priority one fails will resolve the issue.

Thanks again

Alan