* [LARTC] ARP limit ?
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
@ 2004-08-11 7:49 ` raptor
2004-08-11 8:39 ` Peter Surda
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: raptor @ 2004-08-11 7:49 UTC (permalink / raw)
To: lartc
what is the limit on the arp cache entires ?!
Does someone have very big LANs with linux-routers ? How big ? (i mean flat L2 network, not segmented)
I want to know how much can my net can scale ?
thanx
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
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
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Peter Surda @ 2004-08-11 8:39 UTC (permalink / raw)
To: lartc
On Wed, Aug 11, 2004 at 10:49:23AM +0300, raptor@tvskat.net wrote:
> what is the limit on the arp cache entires ?! Does someone have very big
> LANs with linux-routers ? How big ? (i mean flat L2 network, not segmented)
It is configurable with /proc/sys/net/ipv4/neigh/default/gc_thresh{1,2,3}. I
don't know what's the exact limit.
> thanx
Bye,
Peter Surda (Shurdeek) <shurdeek@routehat.org>, ICQ 10236103, +436505122023
--
Where do you think you're going today?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
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
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Nachko Halachev @ 2004-08-11 9:46 UTC (permalink / raw)
To: lartc
In case of big LAN ( more than 512 hosts ) you must use arpd daemon .
On Wednesday 11 August 2004 10:49, raptor@tvskat.net wrote:
> what is the limit on the arp cache entires ?!
> Does someone have very big LANs with linux-routers ? How big ? (i mean flat
> L2 network, not segmented)
>
> I want to know how much can my net can scale ?
>
> thanx
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--
Best Regards,
Nachko Halachev
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
` (2 preceding siblings ...)
2004-08-11 9:46 ` Nachko Halachev
@ 2004-08-11 10:15 ` Peter Surda
2004-08-11 11:21 ` Roberto Nibali
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Peter Surda @ 2004-08-11 10:15 UTC (permalink / raw)
To: lartc
On Wed, Aug 11, 2004 at 12:46:09PM +0300, Nachko Halachev wrote:
> In case of big LAN ( more than 512 hosts ) you must use arpd daemon .
No, you don't have to, see my previous post.
Bye,
Peter Surda (Shurdeek) <shurdeek@routehat.org>, ICQ 10236103, +436505122023
--
Where do you think you're going today?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
` (3 preceding siblings ...)
2004-08-11 10:15 ` Peter Surda
@ 2004-08-11 11:21 ` Roberto Nibali
2004-08-12 6:54 ` raptor
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: Roberto Nibali @ 2004-08-11 11:21 UTC (permalink / raw)
To: lartc
Hi,
> from make config --> arpd -> help
>
> ....
> This code is experimental and also obsolete.
> .....
Yeah well, such entries are sprinkled all over the kernel. Fact is that
it's still in the 2.6.x kernel series, which means that even though it
was thought to be experimental and obsolete, it has not been ripped out
of any stable kernel drops. To bo honest, I don't see the experimental
part as the locking looks correct and netlink sockets are used to
communicate, which is a big plus as well. I have only check for 2
minutes though, relevant code excerpts inlined for viewing pleasure:
#ifdef CONFIG_ARPD
if (notify && neigh->parms->app_probes)
neigh_app_notify(neigh);
#endif
#ifdef CONFIG_ARPD
void neigh_app_ns(struct neighbour *n)
{
struct sk_buff *skb;
struct nlmsghdr *nlh;
int size = NLMSG_SPACE(sizeof(struct ndmsg)+256);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb)
return;
if (neigh_fill_info(skb, n, 0, 0, RTM_GETNEIGH) < 0) {
kfree_skb(skb);
return;
}
nlh = (struct nlmsghdr*)skb->data;
nlh->nlmsg_flags = NLM_F_REQUEST;
NETLINK_CB(skb).dst_groups = RTMGRP_NEIGH;
netlink_broadcast(rtnl, skb, 0, RTMGRP_NEIGH, GFP_ATOMIC);
}
static void neigh_app_notify(struct neighbour *n)
{
struct sk_buff *skb;
struct nlmsghdr *nlh;
int size = NLMSG_SPACE(sizeof(struct ndmsg)+256);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb)
return;
if (neigh_fill_info(skb, n, 0, 0, RTM_NEWNEIGH) < 0) {
kfree_skb(skb);
return;
}
nlh = (struct nlmsghdr*)skb->data;
NETLINK_CB(skb).dst_groups = RTMGRP_NEIGH;
netlink_broadcast(rtnl, skb, 0, RTMGRP_NEIGH, GFP_ATOMIC);
}
#endif /* CONFIG_ARPD */
> 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.
The reason why it is marked obsolete is because most probably noone
really is using it since people run sane network environments or use the
proc-fs tunables.
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
` (4 preceding siblings ...)
2004-08-11 11:21 ` Roberto Nibali
@ 2004-08-12 6:54 ` raptor
2004-08-12 12:01 ` raptor
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: raptor @ 2004-08-12 6:54 UTC (permalink / raw)
To: lartc
yep, i'm using them, i needed to know the max and anyone experiencing
problems with very big arp's
arpd is marked as depricated or so!?
> On Wed, Aug 11, 2004 at 10:49:23AM +0300, raptor@tvskat.net wrote:
> > what is the limit on the arp cache entires ?! Does someone have very big
> > LANs with linux-routers ? How big ? (i mean flat L2 network, not segmented)
> It is configurable with /proc/sys/net/ipv4/neigh/default/gc_thresh{1,2,3}. I
> don't know what's the exact limit.
>
> > thanx
> Bye,
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
` (5 preceding siblings ...)
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
8 siblings, 0 replies; 10+ messages in thread
From: raptor @ 2004-08-12 12:01 UTC (permalink / raw)
To: lartc
from make config --> arpd -> help
....
This code is experimental and also obsolete.
.....
2.4.22
That is why I try to use bogger gc_*
thanx for the links.. reading now..
> Hello,
>
> > yep, i'm using them, i needed to know the max and anyone experiencing
>
> Those are int and nothing in the kernel code prevents them having
> MAX_INT-1 assigned as a value. However you have a rather serious
> networking problem anyway if you exceed the predefined gc* values.
>
> Some more information (besides reading the related kernel code):
>
> http://www.rstack.net/arp.html
> http://www.rstack.net/tuning_proc_for_arp.html
>
> > problems with very big arp's
>
> Yes, the time spent in the GC to reach the equilibrium is rather high
> with a high number of stale cache entries. Once gc_tresh3 threshold
> kicks in you get an aggressive table flush concurrent with the new
> neighbour entries.
>
> > arpd is marked as depricated or so!?
>
> No, not at all ;).
>
> Best regards,
> Roberto Nibali, ratz
> --
> echo
> '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
` (6 preceding siblings ...)
2004-08-12 12:01 ` raptor
@ 2004-08-12 13:43 ` raptor
2004-08-12 13:59 ` Lawrence MacIntyre
8 siblings, 0 replies; 10+ messages in thread
From: raptor @ 2004-08-12 13:43 UTC (permalink / raw)
To: lartc
> > 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/
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [LARTC] ARP limit ?
2004-08-11 6:48 [LARTC] ARP limit ? Roberto Nibali
` (7 preceding siblings ...)
2004-08-12 13:43 ` raptor
@ 2004-08-12 13:59 ` Lawrence MacIntyre
8 siblings, 0 replies; 10+ messages in thread
From: Lawrence MacIntyre @ 2004-08-12 13:59 UTC (permalink / raw)
To: lartc
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/
^ permalink raw reply [flat|nested] 10+ messages in thread