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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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