Hello, On Mon, 9 Feb 2004, David S. Miller wrote: > > not for IPVS :) It is mostly to work with other stacks because > > I'm flooded with emails about how Linux ARP can be more friendly. > > So this new 'arp_announce' change suggestion will preempt any need for > hidden and make everyone happy? For IPVS like setups it solves only one part: arp_announce=2 but for such setups we still need per IP filtering of ARP requests which is not possible to filter with ip rules. If you look at http://www.ssi.bg/~ja/hidden-2.5.67-1.diff you will see that: - the arp_solicit change is solvable with arp_announce=2. If hidden touches there it needs IP lookup. The good news is that inet_addr_type is replaced with ip_dev_find. If hidden does not change arp_solicit then the users will use: {all,lo}/hidden=1, eth0/arp_announce=2 If hidden changes arp_solicit then only hidden will be used - hidden adds ip_dev_find call in arp_rcv for the broadcast case, and only if hidden is enabled with all/hidden=1, so it is ugly but fast if all/hidden=0 - hidden changes inet_select_addr() which is not needed for IPVS setups and can be solved with careful preferred source usage, so this change can be ignored So, if hidden exists and is disabled it will not delay too much the processing but it is true that both arp_rcv and arp_solicit become more and more loaded with ugly checks. You do not need to decide today about it :) Another question while I'm looking at arp_rcv: - what happens if request comes with SIP=0, should we provide answer (proxy_arp) if there is valid remote target? Can be useful for setups where we split a logical subnet. But solving this problem will require cleaning up the arp_process function. In any case, it does not look so hard to me :) > About output_route vs. inet_select_addr(), probably the latter is better. > Your goal is to differentiate between primary and seconday addrs on a device > right? Route lookup is also more expensive, probably. ok Regards -- Julian Anastasov <ja@ssi.bg> - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
