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]
Message-ID: <CAJk_L2Ep-HoROtyThk26t8x3HQFy9+5-7k-e4G15Nm_F0KxV-A@mail.gmail.com>
Date:	Tue, 20 Aug 2013 10:05:13 +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

Hi!

Sorry it took me so long to reply back. I've been doing more tests on
xor mode and I see that arp monitoring is not working at all. I
haven't found any doc that says which modes should be compatible with
arp monitoring, maybe xor mode shouldn't be used at all.

My last setup is a Linux with a couple of vlans both interfaces
(eth2.1001 and eth2.1002) with IP 192.168.1.1 (no bonding at all) and
another Linux machine with a 3.11-rc3 with Nicolay's arp fix for
bonding and a bond configured like this:

iface bond0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        bond-slaves eth0.1001 eth0.1002 eth1.1001 eth1.1002
        bond-mode balance-xor
        bond-arp_validate 0
        bond-arp_interval 2000
        bond-arp_ip_target 192.168.1.1

A silly switch connects the couple of ethernets of the machine with
the bond to the interface of the not bonded machine.

What I saw was that the bonded machine didn't detect the ifconfig down
of the interfaces of the not bonded machine at all. That drove me to
the hypothesis that the bonded machine was considering its own traffic
(there was no traffic but the arp requests of the bonding) as
indication that the link was ok.

To test the hypothesis, when the not bonded machine (192.168.1.1)
which is the target for arp requests was unplugged and the bonding was
seeing all interfaces up (not detecting that the other machine was not
responding) I unplugged one of the bonded interfaces and all 4 slaves
went to down, then if I replugged it all 4 would go up.

Maybe this is something to be expected due to arp monitoring not
working with balance-xor, but I haven't found any doc saying this.

If you need the debug info for this I can send it, but the events show
nothing, as there are no event saying that link is lost or anything
:-(

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ