Maxium concurrent connections with IPTables

Maxium concurrent connections with IPTables

[Small, Jim]

I'm curious, what is the maximum number of concurrent connections possible
with IPTables using connection tracking for udp and for tcp?  (using latest
2.4 kernel and 2.6 kernel)

I'd also be curious if this changes with the TCP window patch.

I'm currently taking a Cisco firewall class and they're claiming that PIX
which supports 500,000 concurrent connections with the appliance version and
1,000,000 with the blade version vastly exceeds the capabilities of all
general purpose O/S'.

<> Jim

Re: Maxium concurrent connections with IPTables

[Antony Stone]

On Monday 02 August 2004 7:15 pm, Small, Jim wrote:

> I'm curious, what is the maximum number of concurrent connections possible
> with IPTables using connection tracking for udp and for tcp?  (using latest
> 2.4 kernel and 2.6 kernel)

Depends on the amount of memory in your machine, and the setting of 
/proc/sys/net/ipv4/ip_conntrack/max

Each connection uses about 300 bytes (see output of dmesg for the exact size 
for your particular system), therefore a system with 1Gbyte RAM could support 
about 3.5 million connections.

> I'm currently taking a Cisco firewall class and they're claiming that PIX
> which supports 500,000 concurrent connections with the appliance version
> and 1,000,000 with the blade version vastly exceeds the capabilities of all
> general purpose O/S'.

I've never tested a fierwall with >256Mbytes RAM, and I'd be hard pushed to 
think of a way to effectively test >1 million connections too (sure, you 
could use a Windows machine infected with a worm, but that would test 
half-open connections with nothing on the other end, not real connections 
passing data).

Regards,

Antony.

-- 
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Maxium concurrent connections with IPTables

[Antony Stone]

On Monday 02 August 2004 8:01 pm, Antony Stone wrote:

> On Monday 02 August 2004 7:15 pm, Small, Jim wrote:
> > I'm curious, what is the maximum number of concurrent connections
> > possible with IPTables using connection tracking for udp and for tcp? 
> > (using latest 2.4 kernel and 2.6 kernel)
>
> Depends on the amount of memory in your machine, and the setting of
> /proc/sys/net/ipv4/ip_conntrack/max

Oops - that should be /proc/sys/net/ipv4/ip_conntrack_max of course.

Incidentally, if you don't change this value, it's calculated so that it uses 
approximately 5% of the system's memory (in other words, you should be able 
to increase the conntrack table capacity by a factor of about 20 on a system 
which isn't using memory for anything else).

Antony.

-- 
Software development can be quick, high quality, or low cost.

The customer gets to pick any two out of three.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Maxium concurrent connections with IPTables

[Jozsef Kadlecsik]

Hi,

On Mon, 2 Aug 2004, Small, Jim wrote:

> I'm curious, what is the maximum number of concurrent connections possible
> with IPTables using connection tracking for udp and for tcp?  (using latest
> 2.4 kernel and 2.6 kernel)
>
> I'd also be curious if this changes with the TCP window patch.

In January-February we tested conntrack where the setup was the
following:

- firewall: dual Xeon CPU, Serverworks chipset, 2GB RAM, Intel copper GE
  cards with the e1000 driver
- two 3Com switches with GB uplink
- 20 "client" and 10 "server" machines. There was a minimal boa httpd
  on the server and two httperf instances started on each client machines

One test series consisted of trying to issue 5000, 10000, 15000, ... 40000
parallel new http sessions trough the firewall per second. The tested
kernels were 2.4.25, 2.4.25+SMP, 2.4.25+SMP+NAPI, 2.6.3(+SMP+NAPI),
2.6.3 conntrack locking patch, 2.6.3 + conntrack locking + nonat patch,
2.6.3 + conntrack locking + nonat patch + TCP window tracking patch.

Overall, 2.6 was better than 2.4, SMP+NAPI and conntrack patches
helped to improve performance. The TCP window tracking patch resulted
practically no loss in performance.

Maximally we could reach ~200,000pps troughput (indifferent from packet
size), ~20,000 new connection/s and ~2,000,000 parallel connection with
this test firewall, in this environment. Delay, jitter, etc was not
measured. There was no iptables rule at all, we loaded in just the
ip_conntrack module.

> I'm currently taking a Cisco firewall class and they're claiming that PIX
> which supports 500,000 concurrent connections with the appliance version and
> 1,000,000 with the blade version vastly exceeds the capabilities of all
> general purpose O/S'.

The number of maximal concurrent connection is mostly limited by the RAM
of the hardware. It'd be interesting to know wether how many new
connection can be opened up trough a PIX per second.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary