All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: Question, my modifed -j LOG
Date: Sun, 21 Aug 2005 02:27:03 +0200	[thread overview]
Message-ID: <4307CA57.9090600@gmx.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0508210021050.22186@yvahk01.tjqt.qr>

Jan Engelhardt schrieb:
>>> From a FW designer's POV, I would say you have got too much rules.
>> 
>>Its a _very_ large router infront of a student network. It house sover 2000
>>computers behind it and has a traffic amount between 50Mbit and 400Mbit
>>(night and day) for each of the 2 large main interface. Now the machine has
>>and additionally 30 interfaces. Most of them virtual VLAN interfaces. Point
>>is, this is a _very large_ routing machine. The machines work can't be done
>>in 63 rules. No way. Not with all the functions i have. The large amount of
> 
> The question is: how different do all these 2000+ hosts need to be classified?
> I can't think of anything but to let everything through with possibly 
  ^^^^^^^^^^^^^^^^^^^^^^^^^
> exceptions like SMTP and HTTP (going over proxies there).

You haven't yet managed such a big student network, right? Especially if
the same IP range also includes non-students living in the same buildings,
being able to freely roam and still get access to their own services and
having different rules, shaping based on traffic history, IP, port and
building they're sitting in, DoS protection for the hosts behind, limits
on filesharing, redirection of a few services, exceptions to all the
rules above because of people being "important", load distribution etc.
Even with a tree-based approach using goto, ipsets and other useful tools
to shorten chain length, you may end up with >200 iptables rules in your
set plus >100 ebtables rules plus >100 tc rules and still have some work
to do. And in such a scenario most of the logic is in userspace to keep
the ruleset in the kernel short.

Some things in reality can be simplified. Some others are already as
simple as possible.

Please don't criticize other people before understanding their problems.

And please don't strip the author of quoted text.

Regards,
Carl-Daniel

  reply	other threads:[~2005-08-21  0:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-20 17:28 Question, my modifed -j LOG Joakim Axelsson
2005-08-20 20:01 ` Jan Engelhardt
2005-08-20 20:25   ` Joakim Axelsson
2005-08-20 22:14     ` Joakim Axelsson
2005-08-20 22:38     ` Jan Engelhardt
2005-08-21  0:27       ` Carl-Daniel Hailfinger [this message]
2005-08-21  2:41         ` Peter Surda
2005-08-21  4:37       ` Joakim Axelsson
2005-08-21  8:36         ` Jan Engelhardt
2005-08-21 18:30         ` Carl-Daniel Hailfinger
2005-08-21 19:12           ` Joakim Axelsson
2005-08-21 14:16 ` Robbie Dinn

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=4307CA57.9090600@gmx.net \
    --to=c-d.hailfinger.devel.2005@gmx.net \
    --cc=jengelh@linux01.gwdg.de \
    --cc=netfilter-devel@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.