Hello list. My setup consists of two SER servers behind an F5 Big-IP for load balancing. The servers are "pooled" behind a virtual server (i.e. they present a common IP address to the rest of the world) created at the Big-IP and I'm using call-id persistence. My ser.cfgs are slightly modified mediaproxy examples from onsip.org. Each SER replicates to the other REGISTER messages, so that both servers are the same. So far so good.
Suppose that NATed UAC1 is registered at SER1 (SER1 is sending the 4 byte udp packet every 60sec in order to keep its NAT binding open) and UAC2 sends him an INVITE:
1) If the INVITE gets served by SER1 everything is OK. 2) If the INVITE gets served by SER2 then: a) SER2 sends the message from port 5060, b) but the packet arrives at UAC1 with source port 5061 (or 5062 or whatever).
This means that for some reason the Big-IP changes the source port it receives from SER2 to something other and, of course, the packet does not pass UAC1's NAT binding.
So, the conclusion is that a UAC is only reachable through the SER that keeps it's NAT binding open. In order to solve this problem (and until SER can support path headers) I employed the method and the patch discussed at http://lists.iptel.org/pipermail/serdev/2005-September/005814.html (thanx for the patch Evan).
I have to admit that this system was my first experience with a Big-IP, so I'm wondering: Am I doing something wrong at the Big-IP? Or is this Big-IP behavior (altering source ports received from internal servers) typical to every (even commercial) load balancer? Has anyone ever had success with any load balancer, multiple SERs and NATed clients, especially F5s?
Regards, George
I think you're going to find this is both normal and logical behaviour for the F5s. The problem is that the source address is (and should be) set to the virtual IP of the load balancers. The port, however, increments with the number of connections bound from the inside.
What the load balancer does is essentially bind a particular port on the virtual IP to a particular service/address on an internal machine. Since it can't bind the same port to both the 5060 on one internal IP AND the 5060 on the other internal IP, it increments its values and says that server 1 will get the same source port, server 2 will get the next, server 3 the next, etc.
If you had 4 servers load balanced, you would expect to see 5060,5061,5062, and 5063 as the source ports.
It COULD spoof this information, but that would cause issues for stateful packet inspections.
N.
On Mon, 24 Oct 2005 14:41:38 +0300, George Perantinos wrote
Hello list. My setup consists of two SER servers behind an F5 Big-IP for load balancing. The servers are "pooled" behind a virtual server (i.e. they present a common IP address to the rest of the world) created at the Big-IP and I'm using call-id persistence. My ser.cfgs are slightly modified mediaproxy examples from onsip.org. Each SER replicates to the other REGISTER messages, so that both servers are the same. So far so good.
Suppose that NATed UAC1 is registered at SER1 (SER1 is sending the 4 byte udp packet every 60sec in order to keep its NAT binding open) and UAC2 sends him an INVITE:
- If the INVITE gets served by SER1 everything is OK.
- If the INVITE gets served by SER2 then:
a) SER2 sends the message from port 5060, b) but the packet arrives at UAC1 with source port 5061 (or 5062 or whatever).
This means that for some reason the Big-IP changes the source port it receives from SER2 to something other and, of course, the packet does not pass UAC1's NAT binding.
So, the conclusion is that a UAC is only reachable through the SER that keeps it's NAT binding open. In order to solve this problem (and until SER can support path headers) I employed the method and the patch discussed at http://lists.iptel.org/pipermail/serdev/2005- September/005814.html (thanx for the patch Evan).
I have to admit that this system was my first experience with a Big- IP, so I'm wondering: Am I doing something wrong at the Big-IP? Or is this Big-IP behavior (altering source ports received from internal servers) typical to every (even commercial) load balancer? Has anyone ever had success with any load balancer, multiple SERs and NATed clients, especially F5s?
Regards, George
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
George Perantinos -
sip