[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53152F0D.2050500@huawei.com>
Date: Tue, 4 Mar 2014 09:40:29 +0800
From: Ding Tianhong <dingtianhong@...wei.com>
To: Alex Lyakas <alex@...arastorage.com>, <netdev@...r.kernel.org>
Subject: Re: bond failover doesn't happen when active slave link is up, but
there is no connectivity
On 2014/3/4 0:49, Alex Lyakas wrote:
> Greetings all,
> We are using bonding interfaces in active-backup (1) mode, with "fail_over_mac" set to "active" (1), with miimon=100 and two slaves. The slaves are "either regular" network interfaces, or vlan interfaces created with "vconfig" over "regular" interfaces. One of the slaves is defined as primary. The purpose of this config is to ensure failover in case one of the interfaces dies. This config usually works as expected.
>
> One scenario that doesn't work for us, is when link status of the active slave is up, but all the packets sent to it are dropped, e.g., because of
> incorrect switch configuration. In that case bond failover doesn't happen. Can this scenario be addressed with bonding?
>
> Thanks,
> Alex.
>
> I found a discussion, which looks relevant, labeled "How to check an inactive slave in a bond?" in http://www.spinics.net/lists/lartc/msg21434.html". But this discussion considers the inactive slave, while in my case, I would like to better handle problems with the active slave.
>
Hi Alex:
I don't understand your problem clearly, normally the fail_over_mac could work well, but in some strange situation, just like the active slave down and up, but
it could not work back again, can you explain your steps to reproduction the problem, I think I can meet the same problem?
Regards
Ding
> --
> 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
>
>
--
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