lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 29 Sep 2014 11:05:36 -0700 From: Cong Wang <cwang@...pensource.com> To: David Ahern <dsahern@...il.com> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>, Nicolas Dichtel <nicolas.dichtel@...nd.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: VRFs and the scalability of namespaces On Fri, Sep 26, 2014 at 3:37 PM, David Ahern <dsahern@...il.com> wrote: > > Network Namespaces for VRFs > --------------------------- > For the past 4 years or so the response to VRF questions is a drum beat of > "use network namespaces". But namespaces are not a good match for VRFs. > > 1. Network namespaces are a complete separation of the networking stack from > network devices up. VRFs are an L3 concept. Using namespaces forces an L3 > separation concept onto L2 apps -- lldp, cdp, etc. > > There are use cases when you want device level separation, use cases where > you want only L3 and up separation, and cases where you want both (e.g., > divy up the netdevices in a system across some small number of namespaces > and then provide VRF based features within a namespace). With regarding to L3 isolation, not limited to VRF, it _does_ sound like a cleaner solution than the current L2 isolation, given the fact that: 1) Isolating L2 relies on /sys etc. in practice, which means we have to use mount namespace as well. Ideally network isolation should be independent of other namespaces. 2) Some resources still need to be shared, otherwise we have to restart some services in each of network namespaces as you mentioned. The ~200kb memory overhead is not a problem I think, as now most servers have 8Gb+ memory, the real problem is some service, for example udevd, has some dependencies, we would fall back to re-implement a whole init service chain for each netns, which is the expensive part. Overall, rather than all or none isolation, we should give the user some flexibility to specify which network resources we want to isolation, which we don't. Again, I am not saying VRF is the solution, I am looking for some more flexible isolation solution. Thanks. -- 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