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
| ||
|
Message-ID: <54D4227B.6080709@gmail.com> Date: Thu, 05 Feb 2015 19:10:03 -0700 From: David Ahern <dsahern@...il.com> To: Stephen Hemminger <stephen@...workplumber.org> CC: netdev@...r.kernel.org, ebiederm@...ssion.com Subject: Re: [RFC PATCH 00/29] net: VRF support On 2/5/15 6:33 PM, Stephen Hemminger wrote: > It is still not clear how adding another level of abstraction > solves the scaling problem. Is it just because you can have one application > connect to multiple VRF's? so you don't need N routing daemons? > > How do you provide a service in N VRFs? "Service" can be a daemon with a listen socket (e.g., bgpd, sshd) or a monitoring app (e.g., collectd, snmpd). For the current namespace only paradigm the options are: 1. replicate the process for each namespace (e.g., N instances of sshd, bgpd, collectd, snmpd, etc.) 2. a single process spawns a thread for each namespace 3. a single process opens a socket in each namespace All of those options are rather heavyweight and the number of 'things' is linear with the number of VRFs. When multiplied by the number of services needed for a full-featured product the end result is a lot of wasted resources. The idea here is to simplify things by allowing a single process to have a presence / provide a service in all VRFs within a namespace without the need to spawn a thread, socket or another process. For example, 1 instance of a monitoring app can still see all of the netdevices in the namespace and in the VRF_ANY context can still report network configuration data. VRF unaware/agnostic L3/L4 apps (e.g., sshd) do not need to be modified and will be able to provide service through any interface. VRF aware apps (e.g., bgpd) might require modifications per the implementation of the VRF construct but they would able to provide service with a single instance. Nesting VRFs within namespaces provides 2 synergistic constructs for building separation within a switch -- namespaces at the device layer (e.g., multiple virtual switches from a single physical switch) with VRFs at the L3 layer. David -- 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