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