Hello,> yep, i''m using them, i needed to know the max and anyone experiencingThose 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''sYes, 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/
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/
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.> thanxBye, 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/
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/
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/
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/
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/
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/
> > 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/
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/