Fri, Mar 03, 2017 at 04:19:13PM CET, nicolas.dich...@6wind.com wrote: >Le 02/03/2017 à 21:39, Dan Geist a écrit : >> ----- On Mar 2, 2017, at 3:11 PM, Cong Wang xiyou.wangc...@gmail.com wrote >> >>> On Thu, Mar 2, 2017 at 10:32 AM, Stephen Hemminger >>> <step...@networkplumber.org> wrote: >>>> >>>> >>>> Begin forwarded message: >>>> >>>> Date: Wed, 01 Mar 2017 21:08:01 +0000 >>>> From: bugzilla-dae...@bugzilla.kernel.org >>>> To: step...@networkplumber.org >>>> Subject: [Bug 194749] New: kernel bonding does not work in a network >>>> nameservice >>>> in versions above 3.10.0-229.20.1 >>>> >>>> >>>> https://bugzilla.kernel.org/show_bug.cgi?id=194749 >>>> >>>> Bug ID: 194749 >>>> Summary: kernel bonding does not work in a network nameservice >>>> in versions above 3.10.0-229.20.1 >>>> Product: Networking >>>> Version: 2.5 >>>> Kernel Version: > 3.10.0-229.20.1 >>>> Hardware: x86-64 >>>> OS: Linux >>>> Tree: Mainline >>>> Status: NEW >>>> Severity: blocking >>>> Priority: P1 >>>> Component: Other >>>> Assignee: step...@networkplumber.org >>>> Reporter: d...@polter.net >>>> Regression: No >>>> >>>> bond interface is being used in active/standby mode with two physical NICs >>>> inside a network nameservice to provide switchpath redundancy. >>>> >>>> netns is instantiated post-boot with the following: >>>> >>>> ip netns add vntp >>>> ip link set p4p1 netns vntp >>>> ip link set p4p2 netns vntp >>>> ip link set bond0 netns vntp >>>> ip netns exec vntp ip link set lo up >>>> ip netns exec vntp ip link set p4p1 up >>>> ip netns exec vntp ip link set p4p2 up >>>> ip netns exec vntp ip link set bond0 up >>>> ip netns exec vntp ifenslave bond0 p4p1 p4p2 >>> >>> This is due to the following commit: >>> >>> commit f9399814927ad9bb995a6e109c2a5f9d8a848209 >>> Author: Weilong Chen <chenweil...@huawei.com> >>> Date: Wed Jan 22 17:16:30 2014 +0800 >>> >>> bonding: Don't allow bond devices to change network namespaces. >>> >>> Like bridge, bonding as netdevice doesn't cross netns boundaries. >>> >>> Bonding ports and bonding itself live in same netns. >>> >>> Signed-off-by: Weilong Chen <chenweil...@huawei.com> >>> Signed-off-by: David S. Miller <da...@davemloft.net> >>> >>> >>> NETIF_F_NETNS_LOCAL was introduced for loopback device which >>> is created for each netns, it is not clear why we need to add it to bond >>> and bridge... >> >> Thank you for tracking this down. Without digging through the code to figure >> it out, does this imply that the existence of a bond interface is not >> possible AT ALL within a netns or simply that it may not be "migrated" >> between the global scope and a netns? >It means that the migration is not possible. I think the only reason to have >this flag on bonding and bridge is the lack of test and fix. There is probably >some work to be done to have this feature. But are there real use cases of >x-netns bonding or x-netns bridge?
If that use case exists I believe it is an abuse. Soft devices that are by definition in upper-lower relationships with other devices should not move to other namespaces. Prevents all kinds of issues. If you need a soft device like bridge of bond within a namespace, just create it there.
