All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerry Creager N5JXS <n5jxs@tamu.edu>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Q: best solution to stop traffic to huge amount of  unregisteredhosts
Date: Fri, 23 Aug 2002 00:02:26 +0000	[thread overview]
Message-ID: <marc-lartc-103006090211566@msgid-missing> (raw)

Karl Gaissmaier wrote:
> Gerry Creager N5JXS schrieb:
> 
>>The answers are not necessarily pretty.
>>
>>I've done a similar task with a Juniper M5 router.  It will handle up to
>>about 180,000 rules at wire speed.  But it is expensive.
>>
>>If your switches were a little newer, we could use 802.1x to enable the
>>switch-use capability flag (:-) and solve the problem.
> 
> 
> you know, 10k hosts are never attached to a network with homogenous
> new network devices :-(

Unfortunately, I do.  We have 50k hosts, more or less, on 2 class B 
address spaces.  We have about 200 buildings, and I'm not sure how many 
wiring closet switches.  And worse, yet, how many wiring closet hubs!

Our (switched) dorm hosts are about 10k.

So, I understand the issues.  The comment about newer gear, and 802.1x, 
however, stands.  This will provide some capability to handle registered 
hosts in the future, perhaps... but I remain skeptical.

>>Instead of policing at a single edge point, you might consider policing
>>at dormatory and building edges, where the load is smaller and you can
>>use masking and diminsh the ruleset some more.
> 
> 
> but the management is very difficult, see above

Correct, but you have several management issues.  One is unnecessary 
delays while filtering, marking and queuing.  Another is device 
configuration.  I've found little existing useful software for real-life 
multiple device (and heterogeneous device) management.  And none I'm 
willing to pay for.  I _do_ have a team of graduate students who are 
working on a heterogeneous-environment configuration tool, but it's not 
nearly ready for prime time.

>>With a sufficiently fast box, or series of boxes, doing specific tasks,
>>you should be able to do this.  Folks like Juniper achieve it by being
>>able to classify and mark in ASIC without having to go to the processor.
> 
> 
> Netfilter and iproute2/tc is very good but I miss just a fast
> matching module for a "pool" of ip addresses and the missing tc-cref
> or better documented tc examples, especially dealing with general
> ingress policing.

We have experimented with A Juniper M5, as a shaping and filtering box 
for specific applications.  It worked well in the tests, but is an 
expensive toy for this.  You might consider a Sitara box for some off 
your work.

I prefer the Linux approach, too, but there are times where scalability, 
due to the state of the art (and certainly not for want of advancement 
in the state of the art!) means a commercial solution.  What HAS 
happened, though, is that my expectations for the commercial products 
are now higher than they were... and the salesmen are somewhat worried.

Regards,
Gerry

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

             reply	other threads:[~2002-08-23  0:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-23  0:02 Gerry Creager N5JXS [this message]
2002-08-25 18:44 ` [LARTC] Q: best solution to stop traffic to huge amount of unregisteredhosts Pedro Larroy

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=marc-lartc-103006090211566@msgid-missing \
    --to=n5jxs@tamu.edu \
    --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.