Cross-region Load Balancer appears to drop UDP traffic?

Question

For a lab application, I have

• A single VM located in Europe-West with an application listening to port 4242 on TCP and UDP, responding with a dummy resposne
• A regional load balancer located in Europe-West, that has rules for port 4242 on TCP and UDP and that single node as a backend.
• A global load balancer, also with rules for port 4242 on TCP and UDP, with the regoinal LB as backend

Connecting to the VM itself works on both TCP and UDP. I can send packages and I receive the answers. The same goes for the regional LB, to which I can connect just fine via TCP and via UDP and everything works.

However, to the global Load Balancer, I can connect to TCP just fine and I get the answers. However, on UDP, the traffic seems to get lost. From what I can tell, the traffic doesn't even arrive inside the VM - I don't see any incoming packets when looking at a tcpdump port 4242 on a VM - while I'm able to see the TCP packages from the global LB just fine, and I'm also able to observe the TCP and UDP packets from the regional LB.

The introduction YouTube video (https://www.youtube.com/watch?v=3awUwUIv950) explicitly says the global LB works with both TCP and UDP. However, since the rules for TCP and UDP are pretty much identical in my setup, I wonder if that's actually the case? Is this supposed to work?

Answer 1

@Dennis Schubert Thank you for reaching out to Microsoft Q&A.

I understand that you are having issues with reaching your backend on UDP port 4242 while travesrsing the Cross-region LB. At the moment the Cross-Region LB does not support UDP traffic. We are working on updating our documents accordingly. We apologize for any inconvenicence. Please let us know if you have any further questions/concerns and we will be glad to assist further. Thank you!

Remember:

Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.

Want a reminder to come back and check responses? Here is how to subscribe to a notification.

Answer 2

YouTube is not authoritive. rfc768 is authoritive; it is the "standard" for User Datagram Protocol (UDP). It says:

delivery and duplicate protection are not guaranteed

Whereas rfc768 for TCP says it is:

highly reliable

In other words, by definition, you cannot rely on delivery of UDP. That is how it is designed to work; it is a minimum of protocol (simpler) and in exchange it is not guaranteed to work.