Forum Discussion
LabanM
Nimbostratus
NimbostratusLoad Balance UDP (Retain Source Client IP)
Good afternoon all. I'm hoping someone on here can point me in the right direction.
I am working on a project to load balance UDP traffic to a few backend nodes for some IOT devices. When the IOT device sends communication to the BIG IP it will be sent to one of the available backend nodes like normal. However, the backend node then needs to respond back to the original IOT device to acknowledge receipt of the communication.
My question is, can this be done with normal SNAT, can the backend node respond back to the SNAT IP:port with the acknowledgement OR will I need to retain the source client IP somehow so I can respond accordingly from the backend node?
If I need to retain the source client ip, how can that be done with UDP?
Unfortunately HTTP is not an option right now.
Thanks in advance for any assistance provided.
The short answer to this is yes - normal SNAT will work fine. When a request comes into a UDP virtual server, the response will be allowed for an Idle Timeout time ie it emulates the TCP functionality. This timeout is configurable in the UDP profile. You can also disable the treating of this traffic as a flow, and instead treat each UDP packet as a new connection ( useful where using iRules and you want to inspect each packet ). This is called Datagram LB.
Take a look at K7535: Overview of the UDP profile for more info
I'll be damned. You learn something new every day. 🙂
Since you have to retain the source IP you can't do any many-to-one source NAT:ing between the IOT device and the node.
However, you could just skip any form of SNAT:ing on the VIP (disable automap, snat pool etc). Then the packets will reach the node with the original client IP as source. Then let the node answer directly to the server using it's routing table. Since it's UDP it should work fine through firewalls etc as long as there's routing and firewall openings back to the IOT device.
Just mind that the routing will be assymetric though which means that packets to and from the node will travel different paths. Some people will find this icky but the smell can be ignored linearly compared to the number of years you've worked in networking. 😂
- xuwen
Cumulonimbus
if F5 enable automap or snat，Unlike the TCP protocol, TCP has tcp option filling options(such as tcp option 28,29,254). If it is not a specific UDP protocol, such as DNS, the edns field of DNS can be inserted into the client ip (this belongs to the application layer inserting the client ip), it can only be used in your UDP data. The first 4 bytes or the last 4 bytes are inserted into the client's ipv4 address. This makes you have to retrofit your application, the useful data is to skip the first 4 bytes or discard the last 4 bytes
PeteWhiteEmployee
The short answer to this is yes - normal SNAT will work fine. When a request comes into a UDP virtual server, the response will be allowed for an Idle Timeout time ie it emulates the TCP functionality. This timeout is configurable in the UDP profile. You can also disable the treating of this traffic as a flow, and instead treat each UDP packet as a new connection ( useful where using iRules and you want to inspect each packet ). This is called Datagram LB.
Take a look at K7535: Overview of the UDP profile for more info
LabanMThis actually worked perfectly and I did not need to reply back to the source client IP. I was able to respond back to the BIG IP SNAT IP : port and the IOT device receieved the acknowledgment. Ended up being way easier than I anticipated.
