In this post I give you some information why it is so difficult to manage the UDP traffic with Azure ILB. First let's see TCP. The ILB Health probe configuration is very easy, because the ILB engine can ensure that which of servers in the Availability set is listening the configured TCP port and can send the traffic directly to that or these server(s). This is because the TCP protocol is a connection-oriented protocol, which means that the connection must be established between the local and the remote computers. This establishing process is used by ILB, and this is how it knows which is the correct server.
But how is this with UDP? UDP is a connection-less protocol, which means the connection between the client and server is not required to be established. In this case the client just sends the UDP packet to the server and it cannot ensure that the server received it. This is the problem also with ILB. In the Health Probe configuration within the ILB it is not possible to setup a monitor of a UDP port because ILB cannot ensure that exactly which server is listening on that port.
How to solve this problem?
The easiest way to listen on a dummy TCP port (TCP Probe port) on the server(s) if the UDP port is available.
Here to that post I attached two zip files contain a windows service and its source code. Using this small service, you can monitor either the ip addresses on your server or any UDP port is listened on your server, and you can configure TCP listener port, which will be opened on the server where the configured monitor is available.
How this is working?
By default two monitoring options are added into the service, but of course it is possible to develop as many as you want, because the structure itself is very easy.
The first option I decided to develop this service was that I have a special application farm with three nodes and an application is listening on a UDP port, but only on port at a time. Based on this, it is not possible to send all UDP traffic to all servers, otherwise I will lose some packets. I had figure out some solution to a TCP port listens when the UDP port is available on the server. The other monitor option is checking if an IP address is available on the local server or not. This is an option for the server clusters, when you want to send some port traffic to the cluster ip address, and not to the cluster role ip address.
E.g. 1: If you have a SQL cluster in Azure and use ILB for the cluster, you are not able to connect to the cluster account (to the server which is having the cluster account at the moment). All ip addresses used in azure cluster, are precreated within ILB and after it is assigned to the cluster roles using a specific tcp probe port. But what is with cluster ip address? In this case you cannot use a specific tcp port in the ILB health check, because it does not exist. What you can do that open a tcp port on the server, which owns the cluster ip address and a service listens on that tcp port. Doing nothing, only opens the port and listents on that.
E.g. 2: Other issue is a cluster which runs a SNMP trap receiver (listens on UDP/162). There are 3 nodes behind the ILB and you don't know where the SNMP trap service listens at the moment. It cannot listen on all three servers at the same time to avoid the double processing of the incoming data. You have no chance to configure a proper Health probe rule in ILB because it is not able to monitor the UDP ports on the nodes. To solve this issue, this solution also helps to identify on which servers is the SNMP service listens, and simply opens a tcp dummy port on that server and you just need to configure a proper Health probe for that port in the ILB and with the proper rule you can redirect the traffice to the proper server.
Here is the service: AzureILBMonitorService.zip
Here is the source: AzureILBMonitorService_src.zip
You can download and use it. You can develop own monitor module implement the MonitorBaseline from IMonitor.dll.
It contains a powershell script with you can install/update/remove the service.