Clone Pool by client IP not working

Is this for TCP or UDP traffic?

 

 

Do you see the log message from CLIENT_DATA?

 

 

Is the clone pool either unmonitored or marked up by a monitor?

 

 

If it's not monitored, can you make a request from the CLI to the pool member(s)?

 

 

If you run a tcpdump filtering on the MAC address(es) of the clone pool member(s), do you see any packets being sent?

 

 

Aaron

This will be for both TCP and UDP traffic (two different VIPS)

 

 

How would I go about finding that out? I did a tcpdump and see the data on the original pool vlan, not sure what event it is on though

 

 

The clone pool is marked up.

 

 

Yes, the MAC address, duh! The traffic is hitting the clone pool with the BIP-IP's IP instead of the original source IP. This is why I did not see the traffic and why the clone pool did not register any syslog from the original host. Any ideas on how to get around this?

The clone pool concept requires the clone destination to accept traffic destined either for the client's destination IP (normally the VIP for a host virtual server) or the virtual server's pool member IP addresses. If your clone destination can't answer for these IPs, a clone pool won't work for your scenario. See SOL8573 for details:

 

 

sol8573: Configuring the BIG-IP system to send traffic to an intrusion detection system (9.x - 10.x)

 

https://support.f5.com/kb/en-us/solutions/public/8000/500/sol8573.html

 

 

If that won't work for you, can you provide more detail on your overall goals? If you want to simply send a TCP or UDP syslog message to more than one destination, you could potentially use an iRule and High Speed Logging:

 

 

https://devcentral.f5.com/wiki/iRules.hsl.ashx

 

 

Aaron

It is not that it cannot accept the traffic, but that the source IP of the syslog message gets changed to the BIP-IP's, so the syslog server thinks it is getting syslog messages from the BIG-IP rather than the original source. The kind of problem you would not see with HTTP traffic...

 

 

The goal is to send syslog messages to two places, correct.

 

 

I have read both articles, but have not been able to apply to this type of traffic. When I played with HSL, I was having similar problems getting the traffic to end up at the correct destination looking like it came from the original source. Let me put together an iRule tomorrow that would be my interpretation of HSL. Maybe you can give some pointers then.

 

 

Thanks!

i do not think you can change HSL source address.

 

 

anyway, just wondering if you are able to configure syslog server to recognize hostname in syslog header instead of source address in ip header.

 

 

The Syslog Protocol

 

http://tools.ietf.org/html/rfc5424

So here is my compromise:

when CLIENT_ACCEPTED {
set hsl [HSL::open -proto UDP -pool syslog_pool]
}

when CLIENT_DATA {
if { [IP::client_addr] equals "10.10.10.10" }{
set dname [RESOLV::lookup @10.10.10.100 -ptr [IP::client_addr]]
scan $dname {%[^.]} shortname
HSL::send $hsl "<190> $shortname - [UDP::payload]"
}
}

We are filtering for the shortname in the syslog configuration