public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: chenweilong <chenweilong@huawei•com>
To: <nicolas.dichtel@6wind•com>, Michal Kubecek <mkubecek@suse•cz>
Cc: Eric Dumazet <eric.dumazet@gmail•com>, <kaber@trash•net>,
	<davem@davemloft•net>, <netdev@vger•kernel.org>
Subject: Re: [patch net-next] vlan: Don't allow vlan devices to change network namespaces.
Date: Fri, 25 Apr 2014 18:23:58 +0800	[thread overview]
Message-ID: <535A37BE.7020203@huawei.com> (raw)
In-Reply-To: <53590FC9.6090607@6wind.com>

On 2014/4/24 21:21, Nicolas Dichtel wrote:
> Le 24/04/2014 14:41, chenweilong a écrit :
>> On 2014/4/24 19:32, chenweilong wrote:
>>> On 2014/4/24 13:47, Michal Kubecek wrote:
>>>> On Thu, Apr 24, 2014 at 08:59:51AM +0800, chenweilong wrote:
>>>>> On 2014/4/23 15:23, Nicolas Dichtel wrote:
>>>>>> Le 23/04/2014 04:40, chenweilong a écrit :
>>>>>>> And, 2) is not safe, if someone forgets to move eth1, eth1.5 will not work, making
>>>>>>> things complex.
>>>>>> We have to fix this case, because it is a valid use case to have eth1.5 in net0
>>>>>> and eth1 in another ns.
>>>>>>
>>>>> eth1.5 can receive and send packets in net0, the problem is you can't add a new eth1.5
>>>>> in old ns, report 'error: File exists'.
>>>>
>>>> And this is correct, as far as I can tell. If it was possible, which of
>>>> the two interfaces would receive VLAN tagged packets with VID 5 coming
>>>> to eth1?
>>>>
>>>>                                                           Michal Kubecek
>>>>
>>>>
>>>>
>>> If eth1 and eth1.5 can work in different ns,
>>> my fist test(move eth1 first,and then eth1.5) should be success,
>>> but it failed, if eth1 was moved to other ns, all related vlans were unregisted.
>>> Strangely, if I move eth1.5 to net0, then move eth1 to net0, and then
>>> move eth1 to net1, eth1.5 is still there!
>>> It is a bug?
>> Find at last it's a behavior of SUSE's udevd , not the kernel.
>> When move eth1 to net0, udevd call /sbin/ifdown to down eth1
>> and then ifdown eth1.5, and then ifdown-802.1q eth1.5 and then
>> vconfig rem eth1.5!
>>
>> Thanks everybody!
>>>
>>> I agree with you there should be one interface tagged with VID 5 in the system.
>>> But I think the network namespaces are independent, vlan port and its VID interfaces
>>> spread in different ns break the rule.
> VID are unique per interface, for example eth0 can only have one VID 5.
> Even if eth1.5 stands in another netns, it is still "connected" to eth0.
> 
> I agree that network namespaces are independent, but there are mechanism to
> connect them between each other or to connect these netns to a "physical"
> network even if you don't have a NIC for each netns on your system. For
> example, IP tunnels (ipip, sit, ip6_tunnels) allow to have encapsulation
> addresses in one netns and the netdevice in another netns:
> 
> ip netns add ns1
> ip netns exec ns1 ip link set lo up
> 
> ip link add ipip1 type ipip remote 10.16.0.121 local 10.16.0.249
> ip link set ipip1 netns ns1
> ip netns exec ns1 ip link set ipip1 up
> ip netns exec ns1 ip addr add dev ipip1 192.168.2.123 remote 192.168.2.121
> 
> vlan may also provide this kind of mechanism.
> 
> Regards,
> Nicolas
> 
> 
Agree,

Thanks!

      reply	other threads:[~2014-04-25 10:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-22 12:43 [patch net-next] vlan: Don't allow vlan devices to change network namespaces Chen Weilong
2014-04-22 12:54 ` Nicolas Dichtel
2014-04-22 14:26 ` Eric Dumazet
2014-04-23  2:40   ` chenweilong
2014-04-23  7:23     ` Nicolas Dichtel
2014-04-24  0:59       ` chenweilong
2014-04-24  5:47         ` Michal Kubecek
2014-04-24  7:01           ` Nicolas Dichtel
2014-04-24 11:32           ` chenweilong
2014-04-24 12:41             ` chenweilong
2014-04-24 13:21               ` Nicolas Dichtel
2014-04-25 10:23                 ` chenweilong [this message]

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=535A37BE.7020203@huawei.com \
    --to=chenweilong@huawei$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=eric.dumazet@gmail$(echo .)com \
    --cc=kaber@trash$(echo .)net \
    --cc=mkubecek@suse$(echo .)cz \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=nicolas.dichtel@6wind$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox