From: Lawrence MacIntyre <lpz@ornl.gov>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] ARP limit ?
Date: Thu, 12 Aug 2004 13:59:49 +0000 [thread overview]
Message-ID: <411B77D5.2000505@ornl.gov> (raw)
In-Reply-To: <4119C13F.2090906@drugphish.ch>
You would be better off if you could separate the LAN by using different
channels in the CATV system. Then you actually have a smaller network
and the physical and logical connectivity are identical. However, if
the memory of the router is sufficient to contain the large ARP table
and the bandwidth is sufficient, your large LAN should be ok.
It is not generally desireable to have multiple subnets on the same
physical network, because the broadcasts can become confusing.
raptor@tvskat.net wrote:
>>>2.4.22
>>>That is why I try to use bogger gc_*
>>>thanx for the links.. reading now..
>>
>>gc_* is of course the way to go and as I've stated before, I would
>>rather think of a misconcepted network architecture when seing neighbour
>>table overflows and fix that flaw instead of using arpd. I found myself
>>back a couple of times in a situation where I had to fiddle with the
>>proc-fs values in a load balanced environment using asymmetric routing.
>
>
> ]- i know it is not good to have big LAN's, but I'm in situation if I move
> to more router oriented network, the things will become much more problematic.
> The routers itself will become the biggest botlleneck (much worse than big ARP tables)..
> and also will limit my ability to balance the network (CATV).. with two words better stick to big
> ARP tables rather than introduce other weak links.. and wait until
> it becomes big enought and I can logicaly separate small blocks of the
> network behind routers.. and still have big ARP (but not enourmous :"))
>
> One additional question...if I deploy parallel router i.e. before :
>
> <big LAN>----[router]---Internet
>
> after :
>
> <big LAN>----[router1]---Internet
> |--[router2]--|
>
> so that part of the LAN is routed via router1 and part of it over router2..
> if I follow my thoughts the ARP will spread over the routers and
> as consequence router1 will shrink its arp table.
> (big LAN - is phisicaly one net, but logicaly/IP several subnets)..
> router1 will make arp-request only for its IP-subnets, but not for those
> that router2 take care of.
>
> are my thoghts correct...
>
> tia
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--
Lawrence MacIntyre 865.574.8696 lpz@ornl.gov
Oak Ridge National Laboratory
High Performance Information Infrastructure Technology Group
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2004-08-12 13:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
2004-08-11 7:49 ` raptor
2004-08-11 8:39 ` Peter Surda
2004-08-11 9:46 ` Nachko Halachev
2004-08-11 10:15 ` Peter Surda
2004-08-11 11:21 ` Roberto Nibali
2004-08-12 6:54 ` raptor
2004-08-12 12:01 ` raptor
2004-08-12 13:43 ` raptor
2004-08-12 13:59 ` Lawrence MacIntyre [this message]
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=411B77D5.2000505@ornl.gov \
--to=lpz@ornl.gov \
--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.