netdev - when using arp monitoring with bonding, why use broadcast arps?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <47558DFC.5050601@nortel.com>
Date:	Tue, 04 Dec 2007 11:27:24 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	bonding-devel@...ts.sourceforge.net
Subject: when using arp monitoring with bonding, why use broadcast arps?

We have a network with a number of nodes using bonding with arp 
monitoring.  The arp interval is set to 100ms.

Unfortunately, the bonding code sends the arp packets to the hardware 
broadcast address, which means that the number of these arp packets seen 
by each node goes up with the number of nodes on the network.

One of the nodes has a fairly low-powered cpu and handles most things in 
microengine code, but arp packets get handled in software.  All these 
broadcast arps slow this node down noticeably.

Is there any particular reason why the bonding code couldn't use unicast 
arp packets if the "arp_ip_target" has a valid entry in the sender's arp 
table?

Thanks,

Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html