Re: [LARTC] ARP limit ?
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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ARP limit ?
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 / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ARP limit ?
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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ARP limit ?
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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ARP limit ?
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. [EMAIL PROTECTED] 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Lawrence MacIntyre 865.574.8696 [EMAIL PROTECTED] Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ARP limit ?
On Wed, Aug 11, 2004 at 10:49:23AM +0300, [EMAIL PROTECTED] 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) [EMAIL PROTECTED], ICQ 10236103, +436505122023
--
Where do you think you're going today?
___
LARTC mailing list / [EMAIL PROTECTED]
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ARP limit ?
In case of big LAN ( more than 512 hosts ) you must use arpd daemon . On Wednesday 11 August 2004 10:49, [EMAIL PROTECTED] 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 / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Best Regards, Nachko Halachev ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] ARP limit ?
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) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- Where do you think you're going today? ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
