Hmmm. A random neuron-firing leads me to another idea: Try testing from multiple source IPs simultaneously. Adding 2-3 alias interfaces on the test client (eth0=192.168.1.1,eth0:1=192.168.1.2, etc) and distributing your test connections across them could VERY possibly make the difference. (two separate machines would guarantee a valid test, but I suspect multiple IP's would be sufficient) Connection tracking may see that all the traffic is between the same two IP's (before the DNAT) and keep it coherent by always DNATting to the same destination. If that's not it, (and I have a strange feeling it IS) I have two more suggestions:^) 1 - Try the contiguous-IP setup if possible, even if just changing the two servers to a different subnet for the test. (and changing the IP of the iptables box to match, obviously, or adding a new IP as an alias on the internal interface) 2 - Modify your test approach to transfer a sizeable file on each connection. Maybe a 1mb file, and try several simultaneous: wget -q -O - http://server/onemegfile.tmp >/dev/null Not a tremendous amount of traffic, but certainly enough to ensure several active connections. j On Wednesday 19 February 2003 07:55 pm, Ian Douglas wrote: > > The only reason I can think of (now) that all your traffic went to > > the first on the list is that there simply wasn't any load to speak > > of. How were you testing? > > By blasting traffic at the system that's doing the packet forwarding. > Perhaps I can write some different code on the web servers that will > hold the connection for a while (ie: call a perl script that does a > 'sleep 60' or something) and test it that way. > > > Multiple simultaneous connections? > > Yes. I have a script that cycles through a perl script (I'll call it > blasticv.pl) that calls another perl script (I'll call it icv.pl) with > 3 varying parameters... each occurrence of that icv.pl makes a > connection to the web server to send and retrieve a chunk of data. > "blasticv.pl" cycles through and calls icv.pl 100 times with each of > the 3 parameters, and not sleeping at all in the loop. This should > simulate 300 requests on the web servers that, given the timing to > complete a single request, would mean we'd have about 200 active > requests at the peak of activity, yet every single 'hit' on the > systems landed on 1.1, and not a single hit on 1.12. > > > it will simply keep sending traffic to the first > > on the list, only using the next one if there is more traffic > > 'currently' (presumably based on the connection-tracking data) on > > the first destination than on the second. > > ... which is what I read, also, yet it seemed that causing a good > volume of busy traffic didn't forward anything to 1.12 > > -id
