UDP LOAD BALANCING - $1000
-
We are seeking the following feature:
UDP DNAT based load balancing which solves the following problem:
A single external IP address must forward UDP clients to one of many internal UDP servers. Once a UDP "session" (you know what I mean) is established that source must always have it's packets go to the same server. Imagine for example you had a client send a UDP audio stream to the server but the load balancer threw some packets to one server and then another making it impossible for a single server to re-assemble the stream. I believe connection marking could do what we need.
We are on a tight schedule, and will purchase a commercial solution if no immediate interest is shown.
-
It's for any udp protocol or for sip/rtp?
-
Any UDP and specifically NOT SIP :)
-
The standard features in 2.0.1 do not suffice you for load balancing?
-
If by standard features you mean Services -> Load Balancer, I don't see how one would solve our problem….which features are you referring to...as you can assume if we thought the features could we would not be posting a $1000 bounty...
-
It sounds like the OP is asking for a feature similar to pf's "sticky" with configurable timeout of src.track timer (for inbound connections and UDP protocol).
fannet, is what you are looking for the functionality described in e.g.
http://daveonsoftware.blogspot.com/2007/08/load-balancer-persistence-sticky.html
http://support.f5.com/kb/en-us/products/lc_9_x/manuals/product/lc_config_guide_10_1/lc_persist_profiles.html
? -
This appears to be correct @dhatz:
It sounds like the OP is asking for a feature similar to pf's "sticky" with configurable timeout of src.track timer (for inbound connections and UDP protocol).
This assumptions sounds correct, the setup would look like this with multiples of 'n' :
/ UDP Server Service 1 10.10.0.1
UDP Client –-> [wan]PFSENSE[lan] –---------<
1.2.3.4 10.10.0.254 \ UDP Server Service 1+n 10.10.0.nThe source address of the client must be preserved (DNAT) when it reaches the server service
From PF.conf manual:
random [sticky-address]
The random option selects an address at random within the defined
block of addresses.sticky-address can be specified to ensure that multiple connections
from the same source are mapped to the same redirection address.
Associations are destroyed as soon as there are no longer states
which refer to them; in order to make the mappings last beyond the
lifetime of the states, increase the global options with set
timeout src.track.round-robin [sticky-address]
The round-robin option loops through the redirection address(es).
sticky-address is as described above.When more than one redirection address is specified, round-robin is
the only permitted pool type.source-hash [key]
The source-hash option uses a hash of the source address to
determine the redirection address, ensuring that the redirection
address is always the same for a given source. An optional key can
be specified after this keyword either in hex or as a string; by
default pfctl(8) randomly generates a key for source-hash every
time the ruleset is reloaded.I see the above options available in "outbound nat" only…
-
Well this can be implemented for sure in pfSense.
I would advice you to contact portal.pfsense.org to get this service completed.This way you give the money to pfSense and help us continue further the improvement.
Also you get bonus the feature continuing being present in all up-coming versions of pfSense.If you do not go that route i can give you some modifications to try related to this!
Let me know which way is better for you.
-
@ermal:
If you do not go that route i can give you some modifications to try related to this!
Let me know which way is better for you.Whatever is quickest and documented so we can replicate it in the future….
-
Did this ever happen?
