24 Oct
2005
24 Oct
'05
3:52 p.m.
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:
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
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers