[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1r54s8lq4.fsf@fess.ebiederm.org>
Date: Thu, 11 Aug 2011 00:13:07 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Renato Westphal <renatowestphal@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: Move interface across network namespaces
Renato Westphal <renatowestphal@...il.com> writes:
> Hello,
>
> I have two questions regarding the process of moving a network
> interface across different network namespaces:
>
> * When I move an interface, all the virtual interfaces attached to it
> are deleted. Is there any reason for such odd behavior? I would like
> to move some network interfaces and keep the attached vlans untouched.
The defined semantics are that a network device is unregistered from
the networking stack in one network namespace and then registered
with the networking stack in another. It is an unfortunate fact
that when vlan devices see their underlying device being unregistered
they decide to delete themselves.
A different vlan implementation might be able to have different
properties but I can't think of any obvious solution other than
don't do move the device that you have your vlans on top of.
> * The target network namespace sends a RTM_NEWLINK netlink message
> when an interface is moved to it. In the other hand, the source
> network namespace doesn't sends a RTM_DELLINK message when an
> interface is moved from it. This is very annoying because user space
> applications (such as zebra) can't detect some interface moving
> operations and then get into an inconsistent state. Anyone knows if
> there's a workaround for this?
Not getting RTM_DELLINK is a bug. The device registration and
unregistration code has changed since dev_change_net_namespace was
written and apparently one of the changes failed to update
dev_change_net_namespace.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists