netdev - Re: [RFC PATCH 00/29] net: VRF support

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]

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