netdev - Re: bonding and SR-IOV -- do we need arp_validation for loadbalancing too?

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 24 Jul 2012 15:38:11 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	Jay Vosburgh <fubar@...ibm.com>
CC:	Jiri Pirko <jiri@...nulli.us>, netdev <netdev@...r.kernel.org>,
	andy@...yhouse.net
Subject: Re: bonding and SR-IOV -- do we need arp_validation for loadbalancing
 too?

On 07/24/2012 02:49 PM, Jay Vosburgh wrote:
> Chris Friesen<chris.friesen@...band.com>  wrote:
>
>> In loadbalance mode wouldn't it just work similar to active-backup?  If
>> it's a reply then verify that it came from the arp target, if it's a
>> request then check to see if it came from one of the other slaves.
>
> 	The problem isn't verifying the requests or replies, it's that
> the ARP packets are not distributed across all slaves (because the
> switch ports are in a channel group / aggregator), so some slaves do not
> receive any ARPs.

Yeah, okay.  And if we turn on arp validation then we ignore all the 
other packets and so they looks dead.  Got it.

In our environment (ATCA shelf) the switches have been customized to 
handle some of this stuff so arpmon does work reliably with xor.

In the general case it sounds like the "PF bonding ignores packets from 
VFs" is a better bet then.


>> On 07/24/2012 02:18 PM, Chris Friesen wrote:
>>> A more general solution might be to have the device driver also track
>>> the time of the last incoming packet that came from the external network
>>> (rather than a VF) and having the bond driver ignore those packets for
>>> the purpose of link health.  Doing this efficiently would likely require
>>> some kind of hardware support though--as an example the 82599 seems to
>>> support this with the "LB" bit in the rx descriptor.
>>
>> That should of course be reversed.  We want the bond driver to only use
>> the packets from the external network for the purpose of link health.
>>
>> Does anyone other than bonding actually care about dev->last_rx?  If not
>> then we could just change the drivers to only set it for external packets.
> That should of course be reversed.  We want the bond driver to only use
>> the packets from the external network for the purpose of link health.
>>
> 	I believe bonding is the main user of last_rx (a search shows a
> couple of drivers using it internally).  For bonding use, in current
> mainline last_rx is set by bonding itself, not in the network device
> driver.

Right, I was looking at older code.  In that case presumably the driver 
could set an skb flag (external vs VF loopback) that the bonding code 
could check?

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