linux-vrf-general — List for discussion about Linux VRF

Re: [Linux-vrf-general] linux-vrf-patch

[David B. <db...@ch...>]

Sailusha,

AFAIK, the VRF patch has been unmaintained for a very long time.
Linux kernels above ~2.6.22 have network namespaces (read about it in LWN or other such places) which replace most of the functionality of the VRF patch. It's unlikely you'll succeed in patching new kernels with the VRF patch, as it conflicts heavily with the namespaces code.

There was an attempt to extend the namespaces code to be more compatible with the VRF patch code, but I don't know what's the current status. See here:
http://lists.openvz.org/pipermail/devel/2008-October/015055.html

David Bar.

[Linux-vrf-general] linux-vrf-patch

[Sailusha K <sai...@nu...>]

 

 

Hi,

 

I am trying to apply linux-vrf patch "linux-vrf-0.900.tar.gz" to the linux
kernel version 2.6.35, but it is not getting applied. I think there might be
a problem with linux kernel version. Please can you let me know if there is
any latest patch which support to my kernel version mentioned above. If not
can you tell me how VRF in linux is implemented now a days. Also kindly tell
me the step-by-step procedure to implement VRF in linux

 

Thanks and regards,

Sailusha.k

[Linux-vrf-general] ip vrf add ...

[<fou...@or...>]

Hi

I have installed linux vrf 0.900 on a debian 2.6.32-5-686.
I also installed iproute2 .

When i type ip vrf add 1, I have an error message:
Object "vrf" is unknow, "try ip help"

I don't know what's wrong.
Can someone help ?

Fouzia


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

[Linux-vrf-general] Compiling linux-vrf in debian linux

[Siddhartha M. <sid...@gm...>]

Hi There!

I need help regarding linux-vrf package installation in debian linux. Can I
get some help on this.
Please let me know if you need any info ....

-- 
Regards,
Sid

[Linux-vrf-general] VRF Patch Needed - for 2.6.21 or even 2.6.19.

[Chugtu Manish-a. <ma...@mo...>]

Hi All

I am looking for VRF patch for 2.6.21. I remember
<https://sourceforge.net/mailarchive/forum.php?thread_name=2008102817391
1.GA8471%40thomson.net&forum_name=linux-vrf-general> 	Vivien
Chappelier having patched 2.6.19, but I could never see that uploaded on
the site. 

Vivien, if possible can you send me the same as I would like to test it
on my setup. (Also would need the iproute2 patch for the same).

Thanks

Re: [Linux-vrf-general] [PATCH 6/6] netns: configurable number of initial network namespaces

[<ebi...@xm...>]

Patrick McHardy <ka...@tr...> writes:

> Vivien Chappelier wrote:
>>    Yes; the linux-vrf patches had a new netlink message to create/remove the
>> equivalent of a network namespace (ip vrf add 1). I've not ported this feature
>> yet, so this patch is meant to provide another way of setting up networking
>> stacks without the need for a new process for each stack. The ability to
>> dynamically create/remove networking stacks from userspace would definitely be
>> useful.
>
> I see, I didn't realize the process that created a namespace
> needs to be kept running. So yes, creating standalone network
> namespaces seems to make sense

To be clear a reference needs to be kept to the network namespace.
Either by being the network namespace that new sockets are created in
task->nsproxy->netns or the network namespace of an open socket sock_net(sk).

If neither of those two conditions hold the network namespace count drops to
zero and it will be freed.  Probably not ideal if you are just doing routing.

Eric

Re: [Linux-vrf-general] [PATCH 0/6] netns: port linux-vrf features to network namespaces

[David M. <da...@da...>]

From: Vivien Chappelier <viv...@th...>
Date: Tue, 28 Oct 2008 18:35:56 +0100

>     The recently introduced network namespaces allow separate
>     standalone network stacks to coexist on the same machine. This
>     is a very useful functionality that we have been using in our
>     products for some time, through the VRF patchset
>     (http://linux-vrf.sourceforge.net/). The goal of the VRF
>     patchset and network namespaces are very similar, yet some
>     features of the VRF are missing that these patches intend to
>     provide.

I'll leave it up to the namespace folks to review this and decide whether
it makes sense to consider these changes seriously or not.

Re: [Linux-vrf-general] [PATCH 6/6] netns: configurable number of initial network namespaces

[Patrick M. <ka...@tr...>]

Vivien Chappelier wrote:
>    Yes; the linux-vrf patches had a new netlink message to create/remove 
> the equivalent of a network namespace (ip vrf add 1). I've not ported 
> this feature yet, so this patch is meant to provide another way of 
> setting up networking stacks without the need for a new process for each 
> stack. The ability to dynamically create/remove networking stacks from 
> userspace would definitely be useful.

I see, I didn't realize the process that created a namespace
needs to be kept running. So yes, creating standalone network
namespaces seems to make sense.

>    There are also some very minor advantages in creating the namespaces 
> statically at boot time, such as increasing the chances that the 
> allocation works (though network namespaces are quite small), and 
> improving boot time by avoiding a few calls to /sbin/ip on startup. 
> Since we are running on embedded devices, that is something that matter 
> to us, but it may not be enough to justify the need for this feature. 
> Anyway, I do not think it hurts to have the ability to create static 
> networking stacks at boot time.

I don't have an opinion on this. Thanks for the explanation.

[Linux-vrf-general] [PATCH 5/6] netlink: add IFLA_NET_NS to move interface to network namespace by nsid

[Vivien C. <viv...@th...>]

This corresponds exactly to IFLA_NET_NS_PID except it takes a nsid parameter instead of a pid.
---
 include/linux/if_link.h |    1 +
 net/core/rtnetlink.c    |   16 ++++++++++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index f9032c8..9e473eb 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -80,6 +80,7 @@ enum
 #define IFLA_LINKINFO IFLA_LINKINFO
 	IFLA_NET_NS_PID,
 	IFLA_IFALIAS,
+	IFLA_NET_NS,
 	__IFLA_MAX
 };
 
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 31f29d2..3e90c0b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -718,6 +718,7 @@ const struct nla_policy ifla_policy[IFLA_MAX+1] = {
 	[IFLA_LINKINFO]		= { .type = NLA_NESTED },
 	[IFLA_NET_NS_PID]	= { .type = NLA_U32 },
 	[IFLA_IFALIAS]	        = { .type = NLA_STRING, .len = IFALIASZ-1 },
+	[IFLA_NET_NS]		= { .type = NLA_U32 },
 };
 
 static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
@@ -779,6 +780,21 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
 		modified = 1;
 	}
 
+	if (tb[IFLA_NET_NS]) {
+		struct net *net;
+
+		net = __get_net_ns_by_id(nla_get_u32(tb[IFLA_NET_NS]));
+		if (net == NULL) {
+			err = -EINVAL;
+			goto errout;
+		}
+		err = dev_change_net_namespace(dev, net, ifname);
+		put_net(net);
+		if (err)
+			goto errout;
+		modified = 1;
+	}
+
 	if (tb[IFLA_MAP]) {
 		struct rtnl_link_ifmap *u_map;
 		struct ifmap k_map;
-- 
1.5.4.4

[Linux-vrf-general] [PATCH 4/6] netns: Add SO_NSID and SO_NETID socket option

[Vivien C. <viv...@th...>]

SO_NSID: bind a socket to a network namespace, given its nsid

This allows a process to have individual sockets in different namespaces.
Also, calling setsockopt(SO_NSID) on a socket before using it for ioctl() make the ioctl() operations happen in the given namespace. This is very useful to configure or retrieve networking information in a different namespace.

SO_NETNS: bind a process to an already existing netns, given its nsid

This is an easy way to move a process to a different, already existing, network namespace without creating a new one.

---
 arch/alpha/include/asm/socket.h    |    4 +++
 arch/arm/include/asm/socket.h      |    4 +++
 arch/avr32/include/asm/socket.h    |    4 +++
 arch/blackfin/include/asm/socket.h |    4 +++
 arch/h8300/include/asm/socket.h    |    4 +++
 arch/ia64/include/asm/socket.h     |    4 +++
 arch/mips/include/asm/socket.h     |    4 +++
 arch/parisc/include/asm/socket.h   |    4 +++
 arch/powerpc/include/asm/socket.h  |    4 +++
 arch/s390/include/asm/socket.h     |    4 +++
 arch/sh/include/asm/socket.h       |    4 +++
 arch/sparc/include/asm/socket.h    |    4 +++
 arch/x86/include/asm/socket.h      |    4 +++
 include/asm-cris/socket.h          |    4 +++
 include/asm-frv/socket.h           |    4 +++
 include/asm-m32r/socket.h          |    4 +++
 include/asm-m68k/socket.h          |    4 +++
 include/asm-mn10300/socket.h       |    4 +++
 include/asm-xtensa/socket.h        |    4 +++
 net/core/sock.c                    |   47 +++++++++++++++++++++++++++++++++++-
 20 files changed, 122 insertions(+), 1 deletions(-)

diff --git a/arch/alpha/include/asm/socket.h b/arch/alpha/include/asm/socket.h
index a1057c2..e9f3f47 100644
--- a/arch/alpha/include/asm/socket.h
+++ b/arch/alpha/include/asm/socket.h
@@ -62,6 +62,10 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 /* O_NONBLOCK clashes with the bits used for socket types.  Therefore we
  * have to define SOCK_NONBLOCK to a different value here.
  */
diff --git a/arch/arm/include/asm/socket.h b/arch/arm/include/asm/socket.h
index 6817be9..5162369 100644
--- a/arch/arm/include/asm/socket.h
+++ b/arch/arm/include/asm/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_SOCKET_H */
diff --git a/arch/avr32/include/asm/socket.h b/arch/avr32/include/asm/socket.h
index 35863f2..d500536 100644
--- a/arch/avr32/include/asm/socket.h
+++ b/arch/avr32/include/asm/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* __ASM_AVR32_SOCKET_H */
diff --git a/arch/blackfin/include/asm/socket.h b/arch/blackfin/include/asm/socket.h
index 2ca702e..a56fc0f 100644
--- a/arch/blackfin/include/asm/socket.h
+++ b/arch/blackfin/include/asm/socket.h
@@ -53,4 +53,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif				/* _ASM_SOCKET_H */
diff --git a/arch/h8300/include/asm/socket.h b/arch/h8300/include/asm/socket.h
index da2520d..112c632 100644
--- a/arch/h8300/include/asm/socket.h
+++ b/arch/h8300/include/asm/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/asm/socket.h b/arch/ia64/include/asm/socket.h
index d5ef0aa..246b075 100644
--- a/arch/ia64/include/asm/socket.h
+++ b/arch/ia64/include/asm/socket.h
@@ -63,4 +63,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/mips/include/asm/socket.h b/arch/mips/include/asm/socket.h
index facc2d7..d90fadb 100644
--- a/arch/mips/include/asm/socket.h
+++ b/arch/mips/include/asm/socket.h
@@ -75,6 +75,10 @@ To add: #define SO_REUSEPORT 0x0200	/* Allow local address and port reuse.  */
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #ifdef __KERNEL__
 
 /** sock_type - Socket types
diff --git a/arch/parisc/include/asm/socket.h b/arch/parisc/include/asm/socket.h
index fba402c..cebbd8b 100644
--- a/arch/parisc/include/asm/socket.h
+++ b/arch/parisc/include/asm/socket.h
@@ -54,6 +54,10 @@
 
 #define SO_MARK			0x401f
 
+/* Namespace management */
+#define SO_NETNS		0x4020
+#define SO_NSID			0x4021
+
 /* O_NONBLOCK clashes with the bits used for socket types.  Therefore we
  * have to define SOCK_NONBLOCK to a different value here.
  */
diff --git a/arch/powerpc/include/asm/socket.h b/arch/powerpc/include/asm/socket.h
index f5a4e16..68e9a53 100644
--- a/arch/powerpc/include/asm/socket.h
+++ b/arch/powerpc/include/asm/socket.h
@@ -61,4 +61,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif	/* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/asm/socket.h b/arch/s390/include/asm/socket.h
index c786ab6..48a2e1f 100644
--- a/arch/s390/include/asm/socket.h
+++ b/arch/s390/include/asm/socket.h
@@ -62,4 +62,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_SOCKET_H */
diff --git a/arch/sh/include/asm/socket.h b/arch/sh/include/asm/socket.h
index 6d4bf65..3e1ae9a 100644
--- a/arch/sh/include/asm/socket.h
+++ b/arch/sh/include/asm/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* __ASM_SH_SOCKET_H */
diff --git a/arch/sparc/include/asm/socket.h b/arch/sparc/include/asm/socket.h
index bf50d0c..e64381c 100644
--- a/arch/sparc/include/asm/socket.h
+++ b/arch/sparc/include/asm/socket.h
@@ -50,6 +50,10 @@
 
 #define SO_MARK			0x0022
 
+/* Namespace management */
+#define SO_NETNS		0x0023
+#define SO_NSID			0x0024
+
 /* Security levels - as per NRL IPv6 - don't actually do anything */
 #define SO_SECURITY_AUTHENTICATION		0x5001
 #define SO_SECURITY_ENCRYPTION_TRANSPORT	0x5002
diff --git a/arch/x86/include/asm/socket.h b/arch/x86/include/asm/socket.h
index 8ab9cc8..9023180 100644
--- a/arch/x86/include/asm/socket.h
+++ b/arch/x86/include/asm/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_X86_SOCKET_H */
diff --git a/include/asm-cris/socket.h b/include/asm-cris/socket.h
index 9df0ca8..7550720 100644
--- a/include/asm-cris/socket.h
+++ b/include/asm-cris/socket.h
@@ -56,6 +56,10 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_SOCKET_H */
 
 
diff --git a/include/asm-frv/socket.h b/include/asm-frv/socket.h
index e51ca67..2ea7442 100644
--- a/include/asm-frv/socket.h
+++ b/include/asm-frv/socket.h
@@ -54,5 +54,9 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_SOCKET_H */
 
diff --git a/include/asm-m32r/socket.h b/include/asm-m32r/socket.h
index 9a0e200..06de900 100644
--- a/include/asm-m32r/socket.h
+++ b/include/asm-m32r/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_M32R_SOCKET_H */
diff --git a/include/asm-m68k/socket.h b/include/asm-m68k/socket.h
index dbc64e9..b208e7c 100644
--- a/include/asm-m68k/socket.h
+++ b/include/asm-m68k/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_SOCKET_H */
diff --git a/include/asm-mn10300/socket.h b/include/asm-mn10300/socket.h
index 80af9c4..6665cb8 100644
--- a/include/asm-mn10300/socket.h
+++ b/include/asm-mn10300/socket.h
@@ -54,4 +54,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif /* _ASM_SOCKET_H */
diff --git a/include/asm-xtensa/socket.h b/include/asm-xtensa/socket.h
index 6100682..7882935 100644
--- a/include/asm-xtensa/socket.h
+++ b/include/asm-xtensa/socket.h
@@ -65,4 +65,8 @@
 
 #define SO_MARK			36
 
+/* Namespace management */
+#define SO_NETNS		37
+#define SO_NSID			38
+
 #endif	/* _XTENSA_SOCKET_H */
diff --git a/net/core/sock.c b/net/core/sock.c
index 5e2a313..b085f67 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -110,6 +110,7 @@
 #include <linux/tcp.h>
 #include <linux/init.h>
 #include <linux/highmem.h>
+#include <linux/nsproxy.h>
 
 #include <asm/uaccess.h>
 #include <asm/system.h>
@@ -668,7 +669,51 @@ set_rcvbuf:
 		}
 		break;
 
-		/* We implement the SO_SNDLOWAT etc to
+	case SO_NETNS:
+		if (!capable(CAP_NET_ADMIN)) {
+			ret = -EPERM;
+		} else {
+			struct nsproxy *new_nsproxy;
+			struct net *old_net, *new_net;
+
+			ret = -EINVAL;
+			new_net = get_net_ns_by_id(val);
+			if (new_net) {
+				ret = unshare_nsproxy_namespaces(CLONE_NEWNS,
+								 &new_nsproxy,
+								 NULL);
+				if (ret == 0) {
+					old_net = new_nsproxy->net_ns;
+					new_nsproxy->net_ns = new_net;
+					put_net(old_net);
+
+					switch_task_namespaces(current,
+							       new_nsproxy);
+				} else
+					put_net(new_net);
+			}
+		}
+		break;
+
+	case SO_NSID:
+		if (!capable(CAP_NET_ADMIN)) {
+			ret = -EPERM;
+		} else {
+			struct net *old_net, *new_net;
+
+			ret = -EINVAL;
+			new_net = get_net_ns_by_id(val);
+			if (new_net) {
+				ret = 0;
+				old_net = sock_net(sk);
+				sock_net_set(sk, get_net(new_net));
+				put_net(old_net);
+			}
+		}
+		break;
+
+
+	/* We implement the SO_SNDLOWAT etc to
 		   not be settable (1003.1g 5.3) */
 	default:
 		ret = -ENOPROTOOPT;
-- 
1.5.4.4

[Linux-vrf-general] [PATCH 2/6] netns: export nets id to /proc/net/netns

[Vivien C. <viv...@th...>]

Patch initially submitted by Benjamin Thery, provided again here for reference.

This patch exports the new 'struct net' net->id value to /proc/net/nsid
file.
---
 net/core/net_namespace.c |   50 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 50 insertions(+), 0 deletions(-)

diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 894b35e..418abe0 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -6,6 +6,7 @@
 #include <linux/delay.h>
 #include <linux/sched.h>
 #include <linux/idr.h>
+#include <linux/proc_fs.h>
 #include <net/net_namespace.h>
 #include <net/netns/generic.h>
 
@@ -211,6 +212,53 @@ struct net *copy_net_ns(unsigned long flags, struct net *old_net)
 }
 #endif
 
+#ifdef CONFIG_PROC_FS
+static int netns_seq_show(struct seq_file *seq, void *v)
+{
+	struct net *net = seq->private;
+
+	seq_printf(seq, "%x\n", net->id);
+	return 0;
+}
+
+static int netns_seq_open(struct inode *inode, struct file *file)
+{
+        return single_open_net(inode, file, netns_seq_show);
+}
+
+static const struct file_operations netns_seq_fops = {
+	.owner   = THIS_MODULE,
+	.open    = netns_seq_open,
+	.read	 = seq_read,
+	.llseek	 = seq_lseek,
+	.release = single_release_net,
+};
+
+static int __net_init netns_net_init(struct net *net)
+{
+	if (!proc_net_fops_create(net, "nsid", S_IRUGO, &netns_seq_fops))
+		return -ENOMEM;
+	return 0;
+}
+
+static void __net_exit netns_net_exit(struct net *net)
+{
+	proc_net_remove(net, "nsid");
+}
+
+static struct pernet_operations netns_proc_ops = {
+	.init = netns_net_init,
+	.exit = netns_net_exit,
+};
+
+static int __init netns_proc_init()
+{
+	return register_pernet_subsys(&netns_proc_ops);
+}
+#else
+#define netns_proc_init() 0
+#endif /* CONFIG_PROC_FS */
+
 static int __init net_ns_init(void)
 {
 	int err;
@@ -226,6 +274,8 @@ static int __init net_ns_init(void)
 	if (!netns_wq)
 		panic("Could not create netns workq");
 #endif
+	if (netns_proc_init())
+		panic("Could not register netns subsys");
 
 	mutex_lock(&net_mutex);
 	err = setup_net(&init_net);
-- 
1.5.4.4

[Linux-vrf-general] [PATCH 6/6] netns: configurable number of initial network namespaces

[Vivien C. <viv...@th...>]

This allows the creation of more than one network namespace at boot time.
---
 net/Kconfig              |    7 +++++++
 net/core/net_namespace.c |   19 ++++++++++++++++++-
 2 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/net/Kconfig b/net/Kconfig
index 8c3d97c..c896bdf 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -32,6 +32,13 @@ config NET_NS
 	  Allow user space to create what appear to be multiple instances
 	  of the network stack.
 
+config NET_NS_NR
+	int "Initial number of network namespaces"
+	default 1
+	depends on NET_NS
+	help
+	  Number of network stacks to create at start-up.
+
 source "net/packet/Kconfig"
 source "net/unix/Kconfig"
 source "net/xfrm/Kconfig"
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 596cb83..1cafa31 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -297,8 +297,25 @@ static int __init net_ns_init(void)
 	rtnl_unlock();
 
 	mutex_unlock(&net_mutex);
+
+#if defined(CONFIG_NET_NS) && CONFIG_NET_NS_NR > 1
+	/* Create additional initial namespaces */
+	{
+		struct net *net;
+		int i;
+
+		for (i = 1; i < CONFIG_NET_NS_NR; i++) {
+			net = copy_net_ns(CLONE_NEWNET, &init_net);
+			if (IS_ERR(net)) {
+				err = PTR_ERR(net);
+				break;
+			}
+		}
+	}
+#endif
+
 	if (err)
-		panic("Could not setup the initial network namespace");
+		panic("Could not setup the initial network namespace(s)");
 
 	return 0;
 }
-- 
1.5.4.4

[Linux-vrf-general] [PATCH 3/6] netns: Add get_net_ns_by_id() to get a reference to a network namespace from its nsid

[Vivien C. <viv...@th...>]

This patch adds a __get_net_ns_by_id() to obtain look for and obtain a reference to a network namespace via its nsid.
The corresponding get_net_ns_by_id() takes the rtnl_lock.

---
 include/net/net_namespace.h |   34 +++++++++++++++++++++++++++++++---
 net/core/net_namespace.c    |   12 ++++++++++++
 2 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 8bde629..afb2578 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -104,8 +104,13 @@ static inline struct net *copy_net_ns(unsigned long flags, struct net *net_ns)
 
 extern struct list_head net_namespace_list;
 
+
+#define for_each_net(VAR)				\
+	list_for_each_entry(VAR, &net_namespace_list, list)
+
 #ifdef CONFIG_NET_NS
 extern void __put_net(struct net *net);
+extern struct net *get_net_ns_by_id(int id);
 
 static inline int net_alive(struct net *net)
 {
@@ -141,6 +146,19 @@ int net_eq(const struct net *net1, const struct net *net2)
 {
 	return net1 == net2;
 }
+
+static inline struct net *__get_net_ns_by_id(int id)
+{
+	struct net *net;
+
+	for_each_net(net)
+		if (net->id == id)
+			return maybe_get_net(net);
+
+	return NULL;
+}
+extern struct net *get_net_ns_by_id(int id);
+
 #else
 
 static inline int net_alive(struct net *net)
@@ -167,6 +185,19 @@ int net_eq(const struct net *net1, const struct net *net2)
 {
 	return 1;
 }
+
+static inline struct net *__get_net_ns_by_id(int id)
+{
+	if (id == 0)
+		return &init_net;
+	return NULL;
+}
+
+static inline struct net *get_net_ns_by_id(int id)
+{
+	return __get_net_ns_by_id(id);
+}
+
 #endif
 
 
@@ -195,9 +226,6 @@ static inline void release_net(struct net *net)
 #endif
 
 
-#define for_each_net(VAR)				\
-	list_for_each_entry(VAR, &net_namespace_list, list)
-
 #ifdef CONFIG_NET_NS
 #define __net_init
 #define __net_exit
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 418abe0..596cb83 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -203,6 +203,18 @@ void __put_net(struct net *net)
 }
 EXPORT_SYMBOL_GPL(__put_net);
 
+struct net *get_net_ns_by_id(int id)
+{
+	struct net *net;
+
+	rtnl_lock();
+	net = __get_net_ns_by_id(id);
+	rtnl_unlock();
+
+	return net;
+}
+EXPORT_SYMBOL_GPL(get_net_ns_by_id);
+
 #else
 struct net *copy_net_ns(unsigned long flags, struct net *old_net)
 {
-- 
1.5.4.4

Re: [Linux-vrf-general] [PATCH 6/6] netns: configurable number of initial network namespaces

[Vivien C. <viv...@th...>]

Hi,

    Yes; the linux-vrf patches had a new netlink message to 
create/remove the equivalent of a network namespace (ip vrf add 1). I've 
not ported this feature yet, so this patch is meant to provide another 
way of setting up networking stacks without the need for a new process 
for each stack. The ability to dynamically create/remove networking 
stacks from userspace would definitely be useful.
    There are also some very minor advantages in creating the namespaces 
statically at boot time, such as increasing the chances that the 
allocation works (though network namespaces are quite small), and 
improving boot time by avoiding a few calls to /sbin/ip on startup. 
Since we are running on embedded devices, that is something that matter 
to us, but it may not be enough to justify the need for this feature. 
Anyway, I do not think it hurts to have the ability to create static 
networking stacks at boot time.

regards,
Vivien.

Patrick McHardy wrote:
> Vivien Chappelier wrote:
>> This allows the creation of more than one network namespace at boot 
>> time.
>
> I'm wondering, what is the advantage over creating them manually?
> They have to be configured by userspace to be useful anyway, don't
> they?
>
>

[Linux-vrf-general] [PATCH 1/6] netns: add in ida ID to identify the network namespace

[Vivien C. <viv...@th...>]

Patch initially submitted by Benjamin Thery, provided again here for reference.

This patch adds in 'id' member to struct net. This member contains an
IDA ID. The id is allocated at netns creation.

This 'id' will be used to reference network namespaces without the need for a pid.
---
 include/net/net_namespace.h |    2 ++
 net/core/net_namespace.c    |   24 ++++++++++++++++++++++++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 708009b..8bde629 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -75,6 +75,8 @@ struct net {
 #endif
 #endif
 	struct net_generic	*gen;
+
+	int			id;
 };
 
 
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index f1d07b5..894b35e 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -26,6 +26,16 @@ EXPORT_SYMBOL(init_net);
 #define INITIAL_NET_GEN_PTRS	13 /* +1 for len +2 for rcu_head */
 
 /*
+ * IDs allocated from this ida are used as a suffix in sysfs to tag
+ * devices belonging to each netns (other than init_net).
+ * Only 4 characters are left to store a separator plus this tag in sysfs
+ * (BUS_ID_SIZE-IFNAMSIZ)
+ * Thus, this limits us to 4095 ("FFF") simultaneous network namespaces.
+ */
+static DEFINE_IDA(net_id_ida);
+#define NET_ID_MAX 0xFFF
+
+/*
  * setup_net runs the initializers for the network namespace object.
  */
 static __net_init int setup_net(struct net *net)
@@ -40,7 +50,20 @@ static __net_init int setup_net(struct net *net)
 	atomic_set(&net->use_count, 0);
 #endif
 
+	/* Get an ID */
+again:
+	error = ida_get_new(&net_id_ida, &net->id);
+	if (error) {
+		if (error == -EAGAIN) {
+			ida_pre_get(&net_id_ida, GFP_KERNEL);
+			goto again;
+		}
+		goto out;
+	}
 	error = -ENOMEM;
+	if (net->id > NET_ID_MAX)
+		goto out;
+
 	ng = kzalloc(sizeof(struct net_generic) +
 			INITIAL_NET_GEN_PTRS * sizeof(void *), GFP_KERNEL);
 	if (ng == NULL)
@@ -97,6 +120,7 @@ static void net_free(struct net *net)
 	}
 #endif
 	kfree(net->gen);
+	ida_remove(&net_id_ida, net->id);
 	kmem_cache_free(net_cachep, net);
 }
 
-- 
1.5.4.4

[Linux-vrf-general] [PATCH 0/6] netns: port linux-vrf features to network namespaces

[Vivien C. <viv...@th...>]

Hi,

    The recently introduced network namespaces allow separate standalone 
network stacks to coexist on the same machine. This is a very useful 
functionality that we have been using in our products for some time, 
through the VRF patchset (http://linux-vrf.sourceforge.net/). The goal 
of the VRF patchset and network namespaces are very similar, yet some 
features of the VRF are missing that these patches intend to provide.

    The network namespaces are currently tied to a process, and 
referenced by its pid. However, a networking stack has no particular 
reason to be associated with any process and it should be possible to 
use and setup additional networking stacks without the need to clone() 
or unshare(). The initial version of the "Coexist with the sysfs 
limitations" patches by Benjamin Thery introduced the notion of a unique 
network namespace identifier (nsid)  that is perfectly fit for the 
purpose of referencing networking stacks independently of any process. 
The first two patches of his set are therefore reused here to identify 
networking stacks.

    These patches additionally introduce the following features that 
were initially provided by the VRF patchset:
- the ability to move a socket to a different network namespace, through 
the new SO_NSID setsockopt(), given the nsid
- the ability to move a process to an existing network namespace, 
through the new SO_NETNS setsockopt(), given the nsid
- the ability to move an interface to a different namespace by nsid 
instead of pid
- the ability to create additional network namespaces on startup 
(dynamic addition/deletion is not supported but should be easy to add)

   To test those features, the chvrf tools attached in this mail have 
been ported to the new setsockopt() API. Example usage:

$ chnetns 1 /bin/sh   # This will attach a shell to existing network 
namespace 1

$ port -n 1 -p 3434   # This will open a listening socket on port 3434 
of network namespace 1

   Also attached is a patch to iproute2 to add the ability to move an 
interface to a different namespace by nsid, used this way:

$ ip link set eth0 nsid 1    # This will move eth0 to network namespace 1

   The patches should apply cleanly to the net-next-2.6 git tree, 
version 2.6.28-rc2, at commit 3891845e1ef6e6807075d4241966b26f6ecb0a5c.

   I would be glad to have your impression and comments on these 
patches, and to have them merged upstream once everybody is satisfied 
with them.

regards,
Vivien Chappelier.

Re: [Linux-vrf-general] [PATCH 6/6] netns: configurable number of initial network namespaces

[Patrick M. <ka...@tr...>]

Vivien Chappelier wrote:
> This allows the creation of more than one network namespace at boot time.

I'm wondering, what is the advantage over creating them manually?
They have to be configured by userspace to be useful anyway, don't
they?

Re: [Linux-vrf-general] Current state of things?

[Jon A. <ne...@gm...>]

you can find a patch and some info here:
det.bi.ehu.es/NQAS/MPLS

2008/8/1 Grant Taylor <gt...@ri...>:

> What is the current state of things?
>
> I'm trying desperately to get any version of VRF to patch and compile
> and not having any luck.
>
>
>
> Grant. . . .
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Linux-vrf-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-vrf-general
>



-- 
Saludos!
Jon Ander

[Linux-vrf-general] Current state of things?

[Grant T. <gt...@ri...>]

What is the current state of things?

I'm trying desperately to get any version of VRF to patch and compile 
and not having any luck.



Grant. . . .

Re: [Linux-vrf-general] vrf patch for 2.6.18

[Jon A. <ne...@gm...>]

Hi Igor!

We have already patched a 2.6.18 kernel with vrf support and tested it.

For more info you can visit http://det.bi.ehu.es/NQAS/MPLS  where you can
find some testbeds.

2008/2/10, Igor Smolyar <xre...@gm...>:
>
> Hi,
>
> I am working to patch 2.6.18 kernel so if anyone has working vrf patch
> for Linux 2.6.18 - please let me know.
> Project include extensive tests, performance tunings  and bug fixes -
> so I can provide list with interesting info, hopefully.
>
> Thanks, Igor.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Linux-vrf-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-vrf-general
>



-- 
Saludos!
Jon Ander

[Linux-vrf-general] vrf patch for 2.6.18

[Igor S. <xre...@gm...>]

Hi,

I am working to patch 2.6.18 kernel so if anyone has working vrf patch
for Linux 2.6.18 - please let me know.
Project include extensive tests, performance tunings  and bug fixes -
so I can provide list with interesting info, hopefully.

Thanks, Igor.

Re: [Linux-vrf-general] Loopback address and scalability problems in VRF

[Yue L. <yu...@gm...>]

Hi, James,
Thanks for your advices.
I followed your suggestions, insert the dummy module, associate the dummy
intf to VRF 1, and assign 127.0.0.1/8 to it.

But when I ping 127.0.0.1 in VRF 1, I get no response.
There is a route in VRF 1 : "127.0.0.0/8 dev dummy0 proto kernel scope link
src 127.0.0.1 vrf 1"
but it seems that the dummy intf doesn't act as a loopback intf, so the XORP
processes can not communicate through it.

So I wonder whether I need to add some policy into iptables or change the
dummy module a little bit.


2007/11/29, James R. Leu <jl...@mi...>:
>
> You can create dummy interfaces and assign them to a VRF and then
> assign it the address 127.0.0.1/8.
>
> In /etc/modprobe.conf:
>
>     alias dummy1 dummy
>     install dummy1 insmod dummy -o dummy1
>
> Then:
>
>     ip link set dev dummy1 vrf 1 up
>     ip addr add 127.0.0.1/8 dev dummy1
>
> As far as increasing the number of VRFs, you could try to raise the
> VRF_MAX value, but I heard of issue with the kernel not booting if you
> make it too big.
>
> I am currently working on reimplementing the VRF patch on a 2.6.23 kernel
> which will have a limit of 2^31 - 1 number of VRFs (signed int)
>
> It still has a long way to go, so you should probably look at different
> ways to test your scalability.
>
> On Thu, Nov 29, 2007 at 07:27:04PM -0500, Yue Li wrote:
> > Hi, James and VRF users,
> > We are doing experiment of large scale routing protocol testing using
> VRF
> > and XORP. We want to
> > run multiple XORP instances on a single machine, each XORP instance
> resides
> > in one VRF. We use VRF because it is much more light weight than virtual
> > machines. The VRF version we are using is 0.900. Now we found two
> problems:
> > 1. As known, XORP adopts a multi-process architecture, the processes
> (belong
> > to one XORP instance) bind to different port numbers and communicate
> through
> > the loopback address 127.0.0.1. But it seems that there is no loopback
> > address in VRFs (other than 0). Because many network applications are
> using
> > this default loopback address I think this limitation may hinder a lot
> of
> > applications to run on top of VRF.
> >
> > 2. The current version has a scalability limit, so we can not create
> more
> > than 7 VRFs.
> >
> > So I wonder whether there is a new version or patch which can solve the
> two
> > problems above. I am grateful for any of your suggestions. Thanks.
> >
> > - Yue
>
> --
> James R. Leu
> jl...@mi...
>
>

Re: [Linux-vrf-general] Loopback address and scalability problems in VRF

[James R. L. <jl...@mi...>]

You can create dummy interfaces and assign them to a VRF and then
assign it the address 127.0.0.1/8.

In /etc/modprobe.conf:

    alias dummy1 dummy
    install dummy1 insmod dummy -o dummy1

Then:

    ip link set dev dummy1 vrf 1 up
    ip addr add 127.0.0.1/8 dev dummy1

As far as increasing the number of VRFs, you could try to raise the
VRF_MAX value, but I heard of issue with the kernel not booting if you
make it too big.

I am currently working on reimplementing the VRF patch on a 2.6.23 kernel
which will have a limit of 2^31 - 1 number of VRFs (signed int)

It still has a long way to go, so you should probably look at different
ways to test your scalability.

On Thu, Nov 29, 2007 at 07:27:04PM -0500, Yue Li wrote:
> Hi, James and VRF users,
> We are doing experiment of large scale routing protocol testing using VRF
> and XORP. We want to
> run multiple XORP instances on a single machine, each XORP instance resid=
es
> in one VRF. We use VRF because it is much more light weight than virtual
> machines. The VRF version we are using is 0.900. Now we found two problem=
s:
> 1. As known, XORP adopts a multi-process architecture, the processes (bel=
ong
> to one XORP instance) bind to different port numbers and communicate thro=
ugh
> the loopback address 127.0.0.1. But it seems that there is no loopback
> address in VRFs (other than 0). Because many network applications are usi=
ng
> this default loopback address I think this limitation may hinder a lot of
> applications to run on top of VRF.
>=20
> 2. The current version has a scalability limit, so we can not create more
> than 7 VRFs.
>=20
> So I wonder whether there is a new version or patch which can solve the t=
wo
> problems above. I am grateful for any of your suggestions. Thanks.
>=20
> - Yue

--=20
James R. Leu
jl...@mi...

[Linux-vrf-general] Loopback address and scalability problems in VRF

[Yue L. <yu...@gm...>]

Hi, James and VRF users,
We are doing experiment of large scale routing protocol testing using VRF
and XORP. We want to
run multiple XORP instances on a single machine, each XORP instance resides
in one VRF. We use VRF because it is much more light weight than virtual
machines. The VRF version we are using is 0.900. Now we found two problems:
1. As known, XORP adopts a multi-process architecture, the processes (belong
to one XORP instance) bind to different port numbers and communicate through
the loopback address 127.0.0.1. But it seems that there is no loopback
address in VRFs (other than 0). Because many network applications are using
this default loopback address I think this limitation may hinder a lot of
applications to run on top of VRF.

2. The current version has a scalability limit, so we can not create more
than 7 VRFs.

So I wonder whether there is a new version or patch which can solve the two
problems above. I am grateful for any of your suggestions. Thanks.

- Yue

[Linux-vrf-general] mpls & vrf : 2.6.22+

[Peter V. S. <pe...@al...>]

...

Hello!

Are there any plans to create mpls & vrf patch for 2.6.22 or 2.6.23? These 
kernels contain some critical fixes for network dirvers (e.g. for nvidia 
nics)

Can I help with this? I have some time, and anyway this patch is important to 
me. Is there any collaboration infrastructure, with which we can work 
together, or it is simplier to send patches via maillist?

-- 
Peter V. Saveliev