netdev - Re: bonding + arp monitoring fails if interface is a vlan

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:	Mon, 05 Aug 2013 12:26:14 +0200
From:	Nikolay Aleksandrov <nikolay@...hat.com>
To:	Santiago Garcia Mantinan <manty@...ty.net>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: bonding + arp monitoring fails if interface is a vlan

On 08/05/2013 12:26 PM, Santiago Garcia Mantinan wrote:
> 2013/8/4 Santiago Garcia Mantinan <manty@...ty.net>:
>> 2013/8/2 Nikolay Aleksandrov <nikolay@...hat.com>:
>>> I believe that it is because dev_trans_start() returns 0 for 8021q devices and
>>> so the calculations if the slave has transmitted are wrong, and the flip-flop
>>> happens.
>>> Please try the attached patch, it should resolve your issue (basically it gets
>>> the dev_trans_start of the vlan's underlying device if a vlan is found).
>>
>> Thanks, patched and compiling, I'll try today with my laptops and
>> tomorrow at the lab I had setup and then at the original machine.
>>
>> I'll let you know how things go.
> 
> Ok, initial tests seem to show that a bonding defined like I had on my
> very basic setup that I sent to the list is now working.
> 
> What doesn't seem to be working is if I set it up using bonding under
> the vlans and then doing a bond of those, I mean:
> 
> iface bond0 inet manual
>         bond-slaves eth0
>         bond-mode 802.3ad
>         bond-miimon 100
> ...
> iface bond2 inet static
>         address 192.168.1.2
>         netmask 255.255.255.0
>         bond-slaves bond0.1001 bond0.1002
>         bond-mode active-backup
>         bond-arp_validate 0
>         bond-arp_interval 2000
>         bond-arp_ip_target 192.168.1.1
> ...
> 
> Should this bond of bonds work?
> 
No, because we take the first non-vlan's interface trans_start after the patch
which in this case is a bonding interface which also doesn't update its
trans_start, i.e. bond over bond (or over vlans over bond) with arp monitoring
shouldn't work.

> I'm doing more tests to make sure that the basic eth0.1001 and
> eth0.1002 works 100% after finding that the bond of bonds wasn't
> working ok, just in case the basic was also failing, but at least the
> double bond is failing and basic bond seems to work ok.
> 
> Regards.
> 

--
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