> > 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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
