Events For UDP Virtual Servers¶
Summary: Understanding when events trigger for UDP virtual servers.
Events for UDP virtual servers¶
Most of the iRule events for UDP and TCP virtual servers are the same;
they both share the CLIENT_ACCEPTED,
CLIENT_CLOSED,
CLIENT_DATA,
SERVER_CLOSED,
SERVER_CONNECTED, and
SERVER_DATA events. While the meanings of these
events are pretty easy to understand for TCP virtual servers, it can
be very unclear what they mean for UDP virtual servers.
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 connection.
- * 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.
- * This is before the UDP datagram is sent to the server, and after the CLIENT_ACCEPTED and CLIENT_DATA events have triggered.
- * Note that if something prevents a server from being selected (e.g. “drop” or “reject” is called in CLIENT_ACCEPTED, or no pool members are UP), then this event will not be triggered.
- SERVER_DATA triggers on every UDP datagram that the server sends.
- CLIENT_CLOSED and SERVER_CLOSED trigger when the connection closes (i.e. the connection is removed from the table, likely by timing out).
- * The order that these two events fire in is explicitly not specified.
The other global events (see
https://devcentral.f5.com/wiki/default.aspx/iRules/Events.html) are
also available for UDP virtual servers, of course.
Version-specific behaviors¶
For most LTM versions, the LB_SELECTED event
will trigger on the first packet, after the both the
CLIENT_ACCEPTED and
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
appropriate.
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.