Re: [Bug 194749] New: kernel bonding does not work in a network nameservice in versions above 3.10.0-229.20.1

Le 02/03/2017 à 21:39, Dan Geist a écrit :

----- On Mar 2, 2017, at 3:11 PM, Cong Wang xiyou.wangcong@gmail.com wrote

quoted

On Thu, Mar 2, 2017 at 10:32 AM, Stephen Hemminger
[off-list ref] wrote:

quoted

Begin forwarded message:

Date: Wed, 01 Mar 2017 21:08:01 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@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: stephen@networkplumber.org
          Reporter: dan@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 [off-list ref]
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 [off-list ref]
   Signed-off-by: David S. Miller [off-list ref]


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?