Home » Mailing lists » Devel » Re: [patch 2/6] [Network namespace] Network device sharing by view
| Re: [patch 2/6] [Network namespace] Network device sharing by view [message #3986] |
Mon, 26 June 2006 15:27  |
Andrey Savochkin
Messages: 47
Registered: December 2005
|
Member |
|
|
Daniel,
On Mon, Jun 26, 2006 at 04:56:32PM +0200, Daniel Lezcano wrote:
> Andrey Savochkin wrote:
> >
> > It's good that you kicked off network namespace discussion.
> > Although I wish you'd Cc'ed someone at OpenVZ so I could notice it earlier :).
>
> devel@openvz.org ?
devel@openvz.org is fine
>
> > When a device presents an skb to the protocol layer, it needs to know to which
> > namespace this skb belongs.
> > Otherwise you would never get rid of problems with bind: what to do if device
> > eth1 is visible in namespace1, namespace2, and root namespace, and each
> > namespace has a socket bound to 0.0.0.0:80?
>
> Exact. But, the idea was to retrieve the namespace from the routes.
Then you lose the ability for each namespace to have its own routing entries.
Which implies that you'll have difficulties with devices that should exist
and be visible in one namespace only (like tunnels), as they require IP
addresses and route.
>
> IMHO, I think there are roughly 2 network isolation implementation:
>
> - make all network ressources private to the namespace
>
> - keep a "flat" model where network ressources have a new identifier
> which is the network namespace pointer. The idea is to move only some
> network informations private to the namespace (eg port range, stats, ...)
Sorry, I don't get the second idea with only some information private to
namespace.
How do you want TCP_INC_STATS macro look?
In my concept, it would be something like
#define TCP_INC_STATS(field) SNMP_INC_STATS(current_net_ns->tcp_stat, field)
where tcp_stat is a TCP statistics array inside net_namespace.
Regards
Andrey
|
|
|
|
| Re: [patch 2/6] [Network namespace] Network device sharing by view [message #4002 is a reply to message #3986] |
Mon, 26 June 2006 15:49  |
Daniel Lezcano
Messages: 417
Registered: June 2006
|
Senior Member |
|
|
> Then you lose the ability for each namespace to have its own routing entries.
> Which implies that you'll have difficulties with devices that should exist
> and be visible in one namespace only (like tunnels), as they require IP
> addresses and route.
I mean instead of having the route tables private to the namespace, the
routes have the information to which namespace they are associated.
>
> - keep a "flat" model where network ressources have a new identifier
>>which is the network namespace pointer. The idea is to move only some
>>network informations private to the namespace (eg port range, stats, ...)
>
>
> Sorry, I don't get the second idea with only some information private to
> namespace.
>
> How do you want TCP_INC_STATS macro look?
I was thinking in TCP_INC_STATS(net_ns, field)
SNMP_INC_STATS(net_ns->tcp_stat, field)
> In my concept, it would be something like
> #define TCP_INC_STATS(field) SNMP_INC_STATS(current_net_ns->tcp_stat, field)
> where tcp_stat is a TCP statistics array inside net_namespace.
|
|
|
|
| Re: [patch 2/6] [Network namespace] Network device sharing by view [message #4031 is a reply to message #4002] |
Tue, 27 June 2006 09:11 |
Andrey Savochkin
Messages: 47
Registered: December 2005
|
Member |
|
|
Daniel,
On Mon, Jun 26, 2006 at 05:49:41PM +0200, Daniel Lezcano wrote:
>
> > Then you lose the ability for each namespace to have its own routing entries.
> > Which implies that you'll have difficulties with devices that should exist
> > and be visible in one namespace only (like tunnels), as they require IP
> > addresses and route.
>
> I mean instead of having the route tables private to the namespace, the
> routes have the information to which namespace they are associated.
I think I understand what you're talking about: you want to make routing
responsible for determining destination namespace ID in addition to route
type (local, unicast etc), nexthop information, and so on. Right?
My point is that if you make namespace tagging at routing time, and
your packets are being routed only once, you lose the ability
to have separate routing tables in each namespace.
Andrey
|
|
|
|
| Re: [patch 2/6] [Network namespace] Network device sharing by view [message #4042 is a reply to message #4031] |
Tue, 27 June 2006 09:34 |
Daniel Lezcano
Messages: 417
Registered: June 2006
|
Senior Member |
|
|
Andrey Savochkin wrote:
> Daniel,
>
> On Mon, Jun 26, 2006 at 05:49:41PM +0200, Daniel Lezcano wrote:
>
>>>Then you lose the ability for each namespace to have its own routing entries.
>>>Which implies that you'll have difficulties with devices that should exist
>>>and be visible in one namespace only (like tunnels), as they require IP
>>>addresses and route.
>>
>>I mean instead of having the route tables private to the namespace, the
>>routes have the information to which namespace they are associated.
>
>
> I think I understand what you're talking about: you want to make routing
> responsible for determining destination namespace ID in addition to route
> type (local, unicast etc), nexthop information, and so on. Right?
Yes.
>
> My point is that if you make namespace tagging at routing time, and
> your packets are being routed only once, you lose the ability
> to have separate routing tables in each namespace.
Right. What is the advantage of having separate the routing tables ?
|
|
|
|
| Routing tables (Re: [patch 2/6] [Network namespace] Network device sharing by view) [message #4349 is a reply to message #4042] |
Thu, 06 July 2006 09:45 |
Kari Hurtta
Messages: 1
Registered: July 2006
|
Junior Member |
|
|
> Andrey Savochkin wrote:
> > Daniel,
> >
> > On Mon, Jun 26, 2006 at 05:49:41PM +0200, Daniel Lezcano wrote:
> >
> >>>Then you lose the ability for each namespace to have its own routing entries.
> >>>Which implies that you'll have difficulties with devices that should exist
> >>>and be visible in one namespace only (like tunnels), as they require IP
> >>>addresses and route.
> >>
> >>I mean instead of having the route tables private to the namespace, the
> >>routes have the information to which namespace they are associated.
> >
> >
> > I think I understand what you're talking about: you want to make routing
> > responsible for determining destination namespace ID in addition to route
> > type (local, unicast etc), nexthop information, and so on. Right?
>
> Yes.
>
> >
> > My point is that if you make namespace tagging at routing time, and
> > your packets are being routed only once, you lose the ability
> > to have separate routing tables in each namespace.
>
> Right. What is the advantage of having separate the routing tables ?
One application may be following. Consider firewall
(isp1) (isp2)
I I
+----------- red0------------- red1 ---------+
| + + |
| | red routing deamon (BGP) | |
| | | |
| | red routing tables | |
| | | |
| +----------tun(?)-----------------+ |
| |
| +----------tun(?)-----------------+ |
| | | |
| | green routing tables | |
I mana0 | | |
| | green routing deamon (ospf) | |
| + + |
+--------- green0 ---------- green1 ----------+
I I
That may allow running different routing deamon on
red and green side. That is possible if they manage
different routing tables on kernel. They not need
communigate together, when route between them is static.
/ Kari Hurtta
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
|
|
|
|
Goto Forum:
Current Time: Sun Jul 20 08:23:53 GMT 2025
Total time taken to generate the page: 0.09476 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
