From: Chris Boot <bootc@bootc.net>
To: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: igb + balance-rr + bridge + IPv6 = no go without promiscuous mode
Date: Fri, 23 Dec 2011 10:56:57 +0000 [thread overview]
Message-ID: <4EF45E79.6020803@bootc.net> (raw)
In-Reply-To: <4EF45C7D.8090409@gmail.com>
On 23/12/2011 10:48, Nicolas de Pesloüan wrote:
> [ Forwarded to netdev, because two previous e-mail erroneously sent in
> HTML ]
>
> Le 23/12/2011 11:15, Chris Boot a écrit :
>> On 23/12/2011 09:52, Nicolas de Pesloüan wrote:
>>>
>>>
>>> Le 23 déc. 2011 10:42, "Chris Boot" <bootc@bootc.net
>>> <mailto:bootc@bootc.net>> a écrit :
>>> >
>>> > Hi folks,
>>> >
>>> > As per Eric Dumazet and Dave Miller, I'm opening up a separate
>>> thread on this issue.
>>> >
>>> > I have two identical servers in a cluster for running KVM virtual
>>> machines. They each have a
>>> single connection to the Internet (irrelevant for this) and two
>>> gigabit connections between each
>>> other for cluster replication, etc... These two connections are in a
>>> balance-rr bonded connection,
>>> which is itself member of a bridge that the VMs attach to. I'm
>>> running v3.2-rc6-140-gb9e26df on
>>> Debian Wheezy.
>>> >
>>> > When the bridge is brought up, IPv4 works fine but IPv6 does not.
>>> I can use neither the
>>> automatic link-local on the brid ge nor the static global address I
>>> assign. Neither machine can
>>> perform neighbour discovery over the link until I put the bond
>>> members (eth0 and eth1) into
>>> promiscuous mode. I can do this either with tcpdump or 'ip link set
>>> dev ethX promisc on' and this
>>> is enough to make the link spring to life.
>>>
>>> For as far as I remember, setting bond0 to promisc should set the
>>> bonding member to promisc too.
>>> And inserting bond0 into br0 should set bond0 to promisc... So
>>> everything should be in promisc
>>> mode anyway... but you shoudn't have to do it by hand.
>>>
>>
>> Sorry, I should have added that I tried this. Setting bond0 or br0 to
>> promisc has no effect. I
>> discovered this by running tcpdump on br0 first, then bond0, then
>> eventually each bond member in
>> turn. Only at the last stage did things jump to life.
>>
>>> >
>>> > This cluster is not currently live so I can easily test patches
>>> and various configurations.
>>>
>>> Can you try to remove the bonding part, connecting eth0 and eth1
>>> directly to br0 and see if it
>>> works better? (This is a test ony. I perfectly understand that you
>>> would loose balance-rr in this
>>> setup.)
>>>
>>
>> Good call. Let's see.
>>
>> I took br0 and bond0 apart, took eth0 and eth1 out of enforced
>> promisc mode, then manually built a
>> br0 with eth0 in only so I didn't cause a network loop. Adding eth0
>> to br0 did not make it go into
>> promisc mode, but IPv6 does work over this setup. I also made sure ip
>> -6 neigh was empty on both
>> machines before I started.
>>
>> I then decided to try the test with just the bond0 in balance-rr
>> mode. Once again I took everything
>> down and ensured no promisc mode and no ip -6 neigh. I noticed bond0
>> wasn't getting a link-local and
>> I found out for some reason
>> /proc/sys/net/ipv6/conf/bond0/disable_ipv6 was set on both servers so I
>> set it to 0. That brought things to life.
>>
>> So then I put it all back together again and it didn't work. I once
>> again noticed disable_ipv6 was
>> set on the bond0 interfaces, now part of the bridge. Toggling this on
>> the _bond_ interface made
>> things work again.
>>
>> What's setting disable_ipv6? Should this be having an impact if the
>> port is part of a bridge?
Hmm, as a further update... I brought up my VMs on the bridge with
disable_ipv6 turned off. The VMs on one host couldn't see what was on
the other side of the bridge (on the other server) until I turned
promisc back on manually. So it's not entirely disable_ipv6's fault.
Chris
--
Chris Boot
bootc@bootc.net
next prev parent reply other threads:[~2011-12-23 10:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-23 9:42 igb + balance-rr + bridge + IPv6 = no go without promiscuous mode Chris Boot
[not found] ` <CAADHFRBWR0JJNmPzQA3=40s5a6fZ3TJEoC0aWzo+3wXruEZC5A@mail.gmail.com>
[not found] ` <4EF454C7.8020305@bootc.net>
2011-12-23 10:48 ` Nicolas de Pesloüan
2011-12-23 10:56 ` Chris Boot [this message]
2011-12-27 21:53 ` Chris Boot
2012-01-03 23:23 ` Wyborny, Carolyn
2012-01-04 16:00 ` Wyborny, Carolyn
2012-01-04 16:58 ` Chris Boot
2012-01-04 18:10 ` Neil Horman
2012-01-09 17:19 ` Wyborny, Carolyn
2012-01-09 19:44 ` Chris Boot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF45E79.6020803@bootc.net \
--to=bootc@bootc.net \
--cc=netdev@vger.kernel.org \
--cc=nicolas.2p.debian@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).