[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <568EB575.6010309@cplanenetworks.com>
Date: Thu, 7 Jan 2016 10:59:01 -0800
From: Saurabh Mohan <saurabh@...anenetworks.com>
To: <nicolas.dichtel@...nd.com>, <netdev@...r.kernel.org>,
<stephen@...workplumber.org>, <davem@...emloft.net>,
<pshelar@...ira.com>, <tgraf@...g.ch>
Subject: Re: [PATCH net-next 1/2] Support outside netns for tunnels.
On 01/05/2016 08:47 AM, Nicolas Dichtel wrote:
> Le 04/01/2016 19:45, Saurabh Mohan a écrit :
>>
>> This patch enchances a tunnel interface, like gre, to have the tunnel
>> encap/decap be in the context of a network namespace that is different from
>> the namespace of the tunnel interface.
>>
>> From userspace this feature may be configured using the new 'onetns' keyword:
>> ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
>> remote 10.0.0.2 onetns outside
>>
>> In the above example the tunnel would be in the 'custa' namespace and the
>> tunnel endpoints would be in the 'outside' namespace.
> What is the difference with the following commands?
>
> ip netns exec outside ip link add dev tun1 type gre local 10.0.0.1 \
> remote 10.0.0.2
> ip netns exec outside ip link set tun1 netns custa
>
> or
>
> ip exec custa ip netns set outside 1234
> ip exec custa ip link add tun1 link-netnsid 1234 type gre local 10.0.0.1 \
> remote 10.0.0.2
>
>
these methods would be functionally equivalent to what this patch does.
no point in adding a third way to do the same.
Powered by blists - more mailing lists