From: Ding Tianhong <dingtianhong@huawei.com>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>,
"j.vosburgh@gmail.com >> Jay Vosburgh" <j.vosburgh@gmail.com>,
"vfalico@gmail.com >> Veaceslav Falico" <vfalico@gmail.com>,
Andy Gospodarek <gospo@cumulusnetworks.com>,
Netdev <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
<fengtiantian@huawei.com>,
"hahaer.guo@huawei.com >> Guozhibin (Hahaer)"
<hahaer.guo@huawei.com>
Subject: Re: [PATCH] bonding: correct the MAC address for "follow" fail_over_mac policy
Date: Thu, 16 Jul 2015 19:48:07 +0800 [thread overview]
Message-ID: <55A799F7.8080904@huawei.com> (raw)
In-Reply-To: <55A77840.5010506@cumulusnetworks.com>
On 2015/7/16 17:24, Nikolay Aleksandrov wrote:
> On 07/16/2015 10:30 AM, Ding Tianhong wrote:
>> The "follow" fail_over_mac policy is useful for multiport devices that
>> either become confused or incur a performance penalty when multiple
>> ports are programmed with the same MAC address, but the same MAC
>> address still may happened by this steps for this policy:
>>
>> 1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
>> bond0 has the same mac address with eth0, it is MAC1.
>>
>> 2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
>> eth1 is backup, eth1 has MAC2.
>>
>> 3) ifconfig eth0 down
>> eth1 became active slave, bond will swap MAC for eth0 and eth1,
>> so eth1 has MAC1, and eth0 has MAC2.
>>
>> 4) ifconfig eth1 down
>> there is no active slave, and eth1 still has MAC1, eth2 has MAC2.
>>
>> 5) ifconfig eth0 up
>> the eth0 became active slave again, the bond set eth0 to MAC1.
>>
>> Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
>> MAC address, it will break this policy for ACTIVE_BACKUP mode.
>>
>> This patch will fix this problem by finding the old active slave and
>> swap them MAC address before change active slave.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> ---
>> drivers/net/bonding/bond_main.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>
> This doesn't seem to be true:
> ~# cat /sys/class/net/bond0/bonding/fail_over_mac
> follow 2
> root@debian:~# ip l sh eth1
> 3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
> root@debian:~# ip l sh eth2
> 4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:4f:a5:99 brd ff:ff:ff:ff:ff:ff
> root@debian:~# ip l sh bond0
> 26: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
>
> *eth1 is the first and active slave and bond0 has taken its mac.
> Now trying your steps:
> Step 3) (bringing down the active eth1)
> root@debian:~# ip l set eth1 down
> root@debian:~# ip l sh bond0
> 26: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
> root@debian:~# ip l sh eth1
> 3: eth1: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc pfifo_fast master bond0 state DOWN mode DEFAULT group default qlen 1000
> link/ether 52:54:00:4f:a5:99 brd ff:ff:ff:ff:ff:ff
> root@debian:~# ip l sh eth2
> 4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
>
> *The mac addresses of eth1 and eth2 are correctly swapped, so far so good.
>
> Step 4) (bringing down the active eth2)
> root@debian:~# ip l set eth2 down
> 3: eth1: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc pfifo_fast master bond0 state DOWN mode DEFAULT group default qlen 1000
> link/ether 52:54:00:4f:a5:99 brd ff:ff:ff:ff:ff:ff
> 4: eth2: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc pfifo_fast master bond0 state DOWN mode DEFAULT group default qlen 1000
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
> 26: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
>
> *eth2 has kept the mac address of the bond and they're both down now
>
> Step 5) (bring eth1 up again and observe the macs)
> ~# ip l set eth1 up
> 3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
> 4: eth2: <BROADCAST,MULTICAST,SLAVE> mtu 1500 qdisc pfifo_fast master bond0 state DOWN mode DEFAULT group default qlen 1000
> link/ether 52:54:00:4f:a5:99 brd ff:ff:ff:ff:ff:ff
> 26: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
>
> *The macs are correctly swapped and there's no such bug.
>
> Step 6(?) bring eth2 up
> ~# ip l set eth2 up
> 3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
> 4: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:4f:a5:99 brd ff:ff:ff:ff:ff:ff
> 26: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
> link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
>
> *Still correct.
>
> Also the mac address that gets set is dev_addr which is changed when
> the swapping is done, if you'd like to get the original mac address
> you should be using slave->perm_hwaddr.
>
Hi Nik:
Which kernel version do you use, I test this on kernel 3.19.8 and 4.2-rc2, this problem exist on both version,
maybe I miss something?
Ding
> Cheers,
> Nik
>
> .
>
next prev parent reply other threads:[~2015-07-16 11:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-16 8:30 [PATCH] bonding: correct the MAC address for "follow" fail_over_mac policy Ding Tianhong
2015-07-16 9:24 ` Nikolay Aleksandrov
2015-07-16 11:48 ` Ding Tianhong [this message]
2015-07-16 11:50 ` Nikolay Aleksandrov
2015-07-16 11:54 ` Nikolay Aleksandrov
2015-07-16 12:02 ` Ding Tianhong
2015-07-16 12:04 ` Nikolay Aleksandrov
2015-07-21 3:30 ` David Miller
2015-07-21 7:08 ` Ding Tianhong
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=55A799F7.8080904@huawei.com \
--to=dingtianhong@huawei.com \
--cc=davem@davemloft.net \
--cc=fengtiantian@huawei.com \
--cc=gospo@cumulusnetworks.com \
--cc=hahaer.guo@huawei.com \
--cc=j.vosburgh@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=vfalico@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.