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

Forums Technical Forums
,
1

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

2

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!

3

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

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:

4

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?

5

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

6

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.

7

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]”

}

8

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)