Forum Discussion

Jeff_Wise's avatar
Jeff_Wise
Icon for Nimbostratus rankNimbostratus
Mar 08, 2019

F5 VIP listens on udp port 514 and forwards to all servers in pool

Need to configure a VIP to receive syslog messages on udp 514 and then forward to all 3 servers in pool.

 

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

     

  • I had a similar requirement and came across this answer to use High-Speed Logging:

    https://devcentral.f5.com/questions/is-there-a-way-for-a-single-request-to-be-received-by-all-pool-members

    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

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

     

    • AndreasWall's avatar
      AndreasWall
      Icon for Nimbostratus rankNimbostratus

      Yesterday I found out that HSL::send will use the self ip of the outgoing interface. Using the snat command will make no difference.

      • jaikumar_f5's avatar
        jaikumar_f5
        Icon for MVP rankMVP

        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.

    • Scott_Payne's avatar
      Scott_Payne
      Icon for Employee rankEmployee

      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_port

      if {[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)

  • 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]"

    }