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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 26 Sep 2014 18:25:50 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: David Ahern <dsahern@...il.com> Cc: nicolas.dichtel@...nd.com, "netdev\@vger.kernel.org" <netdev@...r.kernel.org>, Stephen Hemminger <stephen@...workplumber.org> Subject: Re: VRFs and the scalability of namespaces David Ahern <dsahern@...il.com> writes: > Hi Eric: > > As you suggested [1] I am starting a new thread to discuss scalability > problems using namespaces for VRFs. I will accept as a given that using network namespaces at a scale of 1000s and with lots of little applications listening for new connections (but generally not doing anything) is outside the classic networking usage of linux and of namespaces and so does not work out of the box and that very least some fixes are necessary. However your premise that network namespaces are unsupportable unfixable and fundamentally unscalable for what you want to do is unsupported. The most difficult problem for high levels of efficiency is that that of modifying applications so that they are VRF/namespace aware. That they look at the appropriate set of dns resolvers for the namespace, that when messages are logged the messages report not just the ip address but the context that ip address came from. There are no magic solutions to make that kinds of deep and fundamental code modifications. I can totally see it being frustrating to use linux as a switch OS when it doesn't quite do what you want on the hardware you want to use, and definitely not with the efficiencies you want. I will tell you what network namespaces get you. Network namespaces deliver the full power of the linux network stack, every interesting feature works, and network namespaces provide a path where you can use unmodified linux applications. When you say "proper VRF support" what I hear is that you think something new needs to be added to the linux network stack (called a VRF) with a new userspace interface that somehow because it lacks features is better. > Background > ---------- > Consider a single system that wants to provide VRF-based features with > support for N VRFs. N could easily be 2048 (e.g., 6Wind, [2]), 4000 > (e.g., Cisco, [3]) or even higher. > > The single system with support for N VRFs runs M services (e.g., > quagga, cdp, lldp, stp, strongswan, some homegrown routing protocol) > and includes standard system services like sshd. Furthermore, a system > also includes monitoring programs like snmpd and tcollector. In short, > M is easily 20 processes that need to have a presence across all VRFs. And trying to run it all on what would be considered an underpowered in most contexts. > Before droning on even more, does the above provide better context on > the general problem? It provides a rough context on what you are trying to do. Use linux as the OS to run on a switch. It doesn't actually provide much in the way of context actual problems that show up when you try to use network namespaces. Which is what I was expecting the discussion would be about, and which would I expect be a productive conversation. 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