-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to add some more to this issue. I did some more testing, and figured out the exact scenario that is causing me problems, here goes. I have my router box, say, 192.168.0.1, and a range of IP's behind it, say, 10.0.0.0/24, for arguments sake. I also have an application on the router box listening on 100 ports, say, 5000-5100. My uplink interface is eth0, and the interface with all the 10.0.0.0 addresses is on eth1. Now, I add an iptables rules something like the following: iptbales -t nat -A PREROUTING -j REDIRECT -i eth0 -p tcp -d 10.0.0.0/24 - --destination-port 1025:65535 --to-ports 5000-5100 If I then telnet to 10.0.0.1 on port 5050, the connection is immediate, and my application receives a new connection on port 5050. If, however, I telnet to 10.0.0.1 on port 5150, there is a small (but noticable) delay between when the telnet session shows the connection as established, and when the application receives the connection (on a random port between 5000 and 5100 inclusive). First, I cannot see why this delay is even there, choosing a random port between 5000 and 5100 is not exactly an onerous task, especially not one that should cause a noticable delay. And the connection itself is quite responsive once established (closing it down takes no more time one way or the other). The problems really start when you multiply this out to enterprise proportions - - I'm talking a system than can get thousands of new connections a second (the hardware is up to it, we're talking gb's of ram, and SMP machines). As with my above small test case, connecting to a port in the 'to-ports' range gives me an immediate connection (on the application), but the delay between telnet showing the connection established, and the application receiving the connection (and establishing it) grows dramaticaly, even taking over a minute for the application to receive the connection. Hell, even the time for telnet to show the connection as established is much greater when connecting to a port outside the 'to-ports' range than when connecting to one within this range. This is just an abserd delay, and I really can't see a logical reason that this delay would be there. Can anyone shed some light onto the situation, and more importantly, how to fix it? I'm willing to test some patches (obviously in my test environment) to see if they resolve the problem as necessary. Thanks in advance for your help, - -- PreZ Systems Administrator Shadow Realm PGP FingerPrint: B3 0C F3 32 DE 5A 7D 90 26 F6 FA 38 CC 0A 2D D8 Finger prez@xxxxxxxxxxxxx for full PGP public key. Shadow Realm, a hobbyist ISP supplying real internet services. http://www.srealm.net.au -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+1u04KFp14D8AGEQRAlg3AJ9c4LBfDIZ+3PQ5NzhM7tCdsqCdhQCfdIFz JFA7Y0hHt0bVtuhKiA+qtMY= =NKyf -----END PGP SIGNATURE-----
