----- 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? In order for the CentOS network stack to init the interfaces, I've been creating them with the standard system configuration files: [root@01 network-scripts]# cat ifcfg-p4p1 TYPE=Ethernet BOOTPROTO=none DEVICE=p4p1 ONBOOT=yes MASTER=bond0 SLAVE=yes UUID=4e6c40ee-cc05-4f88-a851-b3185dbdcd0f NAME=p4p1 [root@01 network-scripts]# cat ifcfg-p4p2 TYPE=Ethernet BOOTPROTO=none DEVICE=p4p2 ONBOOT=yes MASTER=bond0 SLAVE=yes UUID=15135328-12b8-4fe3-8940-db02b77b94d9 NAME=p4p2 [root@01 network-scripts]# cat ifcfg-bond0 DEVICE=bond0 TYPE=Bond BONDING_MASTER=yes NAME=bond0 UUID=97674993-0e50-4a00-a210-c66d75481a84 ONBOOT=yes BONDING_OPTS="updelay=0 resend_igmp=1 use_carrier=1 miimon=100 downdelay=0 xmit_hash_policy=0 primary_reselect=0 fail_over_mac=0 arp_validate=0 mode=active-backup lacp_rate=0 arp_interval=0 ad_select=0" IPV6INIT=no Perhaps by not instantiating the bond interface until after the netns is created, this situation can be avoided? Thanks. Dan -- Dan Geist dan(@)polter.net
