In describing these events, it is easiest to refer to a connection.
Since UDP is a connectionless protocol, we need to define what is
meant by a “UDP connection”. When the LTM receives a UDP datagram on a
virtual server, it creates an entry in the connection table for that
client IP and port (and, once a server has been selected, the server
IP and port). As long as UDP traffic is flowing that matches that
entry (either from the client to the server, or from the server to the
client), it will all be considered a single connection. After data
stops flowing, the connection will timeout after a period (the default
is 60 seconds, but this can be changed on a per-virtual basis via a
UDP profile) and be removed from the table.
With this definition, then, we can describe what the events mean on a
UDP virtual server:
CLIENT_ACCEPTED triggers on the first UDP datagram for a
* Note that (unlike events for TCP virtual servers) the packet data
([UDP::payload]) is available in this event.
CLIENT_DATA triggers on every UDP datagram that the client sends,
including the first one.
SERVER_CONNECTED triggers if and when a server is selected.
For most LTM versions, the LB_SELECTED event
will trigger on the first packet, after the both the
CLIENT_DATA events. Starting with version
9.4.0, it was decided that in most cases a user only wants to
load-balance on the initial packet, so it would be more appropriate to
have only the CLIENT_ACCEPTED event trigger
before LB_SELECTED triggers. Due to this
change, CLIENT_DATA is now too late to add a
persistence entry and CLIENT_ACCEPTED
should be used instead.
Note: Message-based Load Balancing (MBLB), such as implemented by
utilising RADIUS traffic profile, is a use-case where adding
persistence at CLIENT_DATA event is
The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor
or control community code contributions. We make no guarantees or warranties regarding the available code,
and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any
code available in the BIG-IP API reference guides is solely at your own risk.