All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Surda <surda@shurdix.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Hardware Configuration Ideas
Date: Tue, 16 Aug 2005 17:17:08 +0000	[thread overview]
Message-ID: <20057161917812097@mail.routehat.org> (raw)
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAENEVIhFsNkiQ6vTBNVSNQcKAAAAQAAAAJ07bVuJvEUWsDJDH0zUe+gEAAAAA@web-profile.net>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1252", Size: 2388 bytes --]

On Tue, 16 Aug 2005 11:38:06 -0500 "Taylor, Grant" <gtaylor@riverviewtech.net>
wrote:

>I ended up
>+allocating 1 GB of RAM to just connection tracking.  In fact you need 1 GB (or
>+very close to) to be able to track 65535 connections.
You don't. Maybe that's conntrack's default, but you can set it to a higher
number manually. The required memory is approx 400b per connection (depends on
iptables/kernel compile time options). The rather conservative default (hashsize
= 1/16384th of RAM) is for a generic system. For more info look at
ip_conntrack_core.c

65535 connections need about 25MB in RAM, so before starting iptables, do
modprobe ip_conntrack hashsize92
(contrack_max is auto-set to 8*hashsize, this is the recommended relation). In
fact my distro Shurdix automatically sets up larger hashsize than the default,
depending on system memory.

You can change conntrack_max while the module is loaded (sysctl
net.ipv4.netfilter.ip_conntrack_max), but you can't change the hashsize this
way. If the relation is other than 1:8, you might experience performance
problems (I don't know details, this is recommended on various places on the
net).

>Another problem that you may run in to will be filling your ARP table.  The
>+kernel space ARP table is not very large at all, only like 64 or maybe up to
255
>+IP MAC pairs.
This is also tunable, per sysctl, somewhere like
net.ipv4.neigh.default.gc_thresh[123]. Unfortunately poorly documented, I had to
look at the source to realize this, and I don't remember what means what.

>In short get memory and a lower end proc to save the money for a 2nd identical
>router.
While a redundant system is indeed a good idea, I recommend making sure the
router is rock stable. This doesn't necessarily require high-end / fast
hardware, it is recommended to stress test it before going live
(memtest/cpuburn/whatever).

My tip is not to use "primitive" network cards like those based on rtl8139 which
you require high bandwidth. This has the most noticeable impact on performance.
I have ok experience with 3com's, I've heard intels are even better.

Yours sincerely,
Peter

-- 
http://www.shurdix.org - Linux distribution for routers and firewalls
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2005-08-16 17:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-15 20:53 [LARTC] Hardware Configuration Ideas Mihai Vlad
2005-08-16 13:34 ` Nickola Kolev
2005-08-16 16:38 ` Taylor, Grant
2005-08-16 17:17 ` Peter Surda [this message]
2005-08-16 17:21 ` Peter Surda
2005-08-17  6:12 ` Grant Taylor
2005-08-17  6:20 ` Grant Taylor
2005-08-17 15:46 ` Mihai Vlad
2005-08-17 17:33 ` Peter Surda
2005-08-17 19:18 ` Taylor, Grant
2005-08-17 20:36 ` Carl-Daniel Hailfinger
2005-08-17 21:06 ` Peter Surda

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=20057161917812097@mail.routehat.org \
    --to=surda@shurdix.com \
    --cc=lartc@vger.kernel.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.