Forum Discussion

Brian_69413's avatar
Icon for Nimbostratus rankNimbostratus
Apr 05, 2012

Clone Pool by client IP not working

I am trying to clone syslog data coming into a VIP to a secondary pool. I have the below iRule. I see the traffic hit the main pool and I know the rule fires based on the logs, but not a thing hits the secondary pool. Am I missing something?

    if { [IP::client_addr] equals "" }{
        log local0. "Sent data to clone pool!"
        clone pool



6 Replies

  • 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?



  • 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)




    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:





  • 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.



  • 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

  • So here is my compromise:

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

    We are filtering for the shortname in the syslog configuration