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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJk_L2FU6GcHUoC+UdNJoULN9KewoUQAMhapC0k3RcTqNOymnw@mail.gmail.com>
Date:	Mon, 5 Aug 2013 12:26:16 +0200
From:	Santiago Garcia Mantinan <manty@...ty.net>
To:	Nikolay Aleksandrov <nikolay@...hat.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: bonding + arp monitoring fails if interface is a vlan

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?

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.
-- 
Manty/BestiaTester -> http://manty.net
--
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