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]

Message-ID: <54D373B4.3050603@6wind.com>
Date:	Thu, 05 Feb 2015 14:44:20 +0100
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	David Ahern <dsahern@...il.com>, netdev@...r.kernel.org
CC:	ebiederm@...ssion.com
Subject: Re: [RFC PATCH 00/29] net: VRF support

Le 05/02/2015 02:34, David Ahern a écrit :
[snip]
> This is accomplished by enhancing the current namespace checks to a
> broader network context that is both a namepsace and a VRF id. The VRF
> id is a tag applied to relevant structures, an integer between 1 and 4095
> which allows for 4095 VRFs (could have 0 be the default VRF and then the
> range is 0-4095 = 4096s VRFs). (The limitation is arguably artificial. It
> is based on the genid scheme for versioning networking data which is a
> 32-bit integer. The VRF id is the lower 12 bits of the genid's.)
Would it be possible to avoid this artificial limit?
There could be scenarii with more than 4096 vrf.

Do you plan to have a way to dump or monitor VRF via netlink?
--
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