Re: [LARTC] ARP limit ?

[Roberto Nibali <ratz@drugphish.ch>]

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/