[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49B13259.9040701@trash.net>
Date: Fri, 06 Mar 2009 15:25:29 +0100
From: Patrick McHardy <kaber@...sh.net>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] macvlan: Support creating macvlans from macvlans
Eric W. Biederman wrote:
> Patrick McHardy <kaber@...sh.net> writes:
>
>>> So modify macvlan creation to allow automatically forward
>>> a creation of a macvlan on a macvlan to become a creation
>>> of a macvlan on the underlying network device.
>> I'm not sure I understand the constallation, what is the underlying
>> device in this case? A device outside the namespace?
>
> Yes.
>
> Typical usage would be:
>
> eth0 in the initial namespace.
> A macvlan off of eth0 in each child namespace.
>
> Which works fine until I do things like create a network namespace
> when I am already inside of a network namespace. A child of a child.
> In which case I have to start rigging up something like a pair of
> veths an bridging or routing to get outside connectivity.
>
> Or roughly:
> ip link add mv0 link eth0 type macvlan.
> ip link add mv1 link eth0 type macvlan.
> ip link set mv0 netns 1234
> ip link set mv1 netns 6789
>
> Then later I would find it very handy to do:
> echo $$ -> 1234
> ip link add mv3 link mv0 type macvlan
> ip link set mv3 netns 101112
That makes sense of course. I'm mainly wondering whether a namespace
should be able to directly affect the real device like this. This
might move it to promiscous mode, or affect other performce-relevant
settings. Its also looks like you can steal the MAC address of a
different macvlan device this way and have the packets directed to you
(new devices are added to the beginning of the hash chains, so they
are found first on lookups).
--
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