Amos Kong
2012-May-03 05:33 UTC
[Bridge] IPv6 bonding in VM doesn't work (was Re: bonding and IPv6 "doesn't work"?)
On Wed, Jul 13, 2011 at 1:15 AM, Chris Friesen <chris.friesen at genband.com>wrote:> On 07/12/2011 10:25 AM, Tomasz Chmielewski wrote: > >> On 12.07.2011 18:14, David Lamparter wrote: >> > > Your bonding peer is probably looping those >>> packets back on the other link, most likely because... >>> >>> Bonding Mode: load balancing (round-robin) >>>> >>> >>> ... most likely because you maybe have a switch on the other side, and >>> that switch expects you to do 802.3ad? >>> >> >> It's a virtual machine, so the host shouldn't know or care much about >> 802.3ad (I think!). >> >Bonding mode 1 and 5 work when slave nics(guest) connect with same virtual bridge in host. other modes don't work.> > I suspect that connecting multiple links of a bond to the same unmanaged > switch (or virtual bridge) is going to confuse things. > > Try using multiple virtual bridges instead, one for each slave in the > bond. That way they won't interfere with each other. >>> Continue original thread: http://marc.info/?t=131048686200002&r=1&w=2http://en.wikipedia.org/wiki/IEEE_802.1AX """ With modes balance-rr, balance-xor, broadcast and 802.3ad all physical ports in the link aggregation group _must reside on the same_ logical switch, which in most scenarios will leave a single point of failure when the physical switch to which both links are connected goes offline. Modes active-backup, balance-tlb, and balance-alb can also be set up with two or more switches.""" We could not resolve this issue by connect links to different virtual bridges? But it doesn't make sense to connect slave nics with same physical path, NO stable /performance benefit. What will happen if we connect two physical NIC directly (back-to-back)? duplicated address detected? BTW, openvswitch already support 802.3ad, it might resolve this issue. Thanks, Amos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bridge/attachments/20120503/2bc8c257/attachment.html>