All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramoni <ramoni@databras.com.br>
To: netfilter@lists.netfilter.org
Subject: Re: Poll on large sites that deploy Iptables.
Date: Wed, 2 Jun 2004 18:16:01 -0300	[thread overview]
Message-ID: <200406021816.01369.ramoni@databras.com.br> (raw)
In-Reply-To: <7C9884991ADAE0479C14F10C858BCDF591E32C@alderaan.smgtec.com>

Ok, let me show some info about my firewall here:
We have too many aliases in our 5 ethernet interfaces, and some tun 
interfaces. 
This frw is a vpn server too. Do many nats and filter rules.
I'll paste here some line counts just to show you an ideia of this frw:

See some info:


- Iptables rules:
[root(sethi)~]#> iptables -L -n | wc -l
   1313
[root(sethi)~]#> iptables -L -n -t nat | wc -l
    447


- Interfaces: (we have so many aliases here, 5 ethernet interfaces and about 
20 tun interfaces:
[root(sethi)~]#> ifconfig | grep -E "eth|tun" | wc -l
    317


- Routes: We have a laarrge routing table, cause we have many links..
[root(sethi)~]#> route -n | wc -l
    157

- Mem: Rarely we use swap:
[root(sethi)~]#> free
             total       used       free     shared    buffers     cached
Mem:        515544     494492      21052          0     122284     275468
-/+ buffers/cache:      96740     418804
Swap:       498004          0     498004

- Uptime:
[root(sethi)~]#> uptime
 17:57:37  up 58 days,  7:02,  3 users,  load average: 0.00, 0.00, 0.00

- Machine:
[root(sethi)~]#> cat /proc/cpuinfo  | head -8
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 1
model name      : AMD-K7(tm) Processor
stepping        : 2
cpu MHz         : 650.028
cache size      : 512 KB

This frw has a 4mb link to the internet, that is amolst all the time at 90%
[root(sethi)~]#> cat /etc/slackware-version
Slackware 9.1.0

So, I think linux is pretty good for firewall and routing :)





On Wednesday 02 June 2004 17:54, Daniel Chemko wrote:
> Brett Simpson wrote:
> > We are a large organization, 3000 plus users, considering switching
> > from Checkpoint FW1 to Iptables. I was wondering how many large
> > organizations (1000 plus users) are using Iptables in a production
> > environment?
>
> I can't speak for concurrent connections, but I know that stability is
> pretty good for moderate loads. My network has 100 users with about 10
> TB of traffic in the course of 2 months. Linux reboots are rare, but
> when you do, you'll want to make sure to update any critical kernel
> issues. With so much traffic, any bug could impact your setup
> substantially. I can't speak for Checkpoint's qualities, so I'm not the
> best reference.
>
> I imagine the best plan would be to take up a test group and object them
> to the Linux based gateways and see how THEY like it. I don't think
> there should be a show-stopper unless you have a situation that isn't
> iptables compatible, like some L5-7 issues, and maybe a few remote-auth
> type things.
>
> Net stats:
> You can expect to reboot the server quarterly for updates (tested
> beforehand on test env.)
> I've never had Linux crash, so I assume the mean time error is > 1 year
> if you aren't running anything too experimental.
> 25% CPU utilization on a P4 2.66 (not dual-threaded) when filtering
> ~120Mb/s of traffic
> Concurrent connections exceeding 3000 have never peaked the system
> beyond 200MB in the 512MB system (other non-firewall programs as well)
>
> Things to watch out for:
> Control your logging because it will get ugly
> Plan for proper capacity. 3000 ppl feeding into a T-1 isn't such a big
> deal, but if you're edge firewall's hosting a fat pipe, expect to spend
> time tuning all of Linux/Netfilter's settings to utilize the best
> efficiency. Linux perfect out-of-the-box.
> The good thing is that Linux has tons of tools to help you find out
> what's going on in the network.
> Management time/costs will probably go up due to more baby-sitting the
> system. It all depends on how dynamic you network is. The more unique
> things you do, the longer it'll take to implement on Linux.
>
> Conclusions
> I know it isn't what you wanted, but I hope it gives you some idea on
> what to expect.


  reply	other threads:[~2004-06-02 21:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-02 20:54 Poll on large sites that deploy Iptables Daniel Chemko
2004-06-02 21:16 ` Ramoni [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-06-04 16:39 Daniel Chemko
2004-06-04 16:49 ` Alexis
2004-06-03 16:59 Aldo Lagana
2004-06-02 19:54 Brett Simpson
2004-06-02 22:45 ` John A. Sullivan III
2004-06-03 13:19 ` Brett Simpson
2004-06-03 13:32   ` Frank Gruellich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200406021816.01369.ramoni@databras.com.br \
    --to=ramoni@databras.com.br \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.