netdev - Re: [RFC net-next 3/3] rcv path changes for vrf traffic

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:	Mon, 8 Jun 2015 15:44:22 -0700
From:	Shrijeet Mukherjee <shm@...ulusnetworks.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	David Ahern <dsahern@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jamal Hadi Salim <hadi@...atatu.com>,
	David Miller <davem@...emloft.net>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Netdev <netdev@...r.kernel.org>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>,
	Jon Toppins <jtoppins@...ulusnetworks.com>,
	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Subject: Re: [RFC net-next 3/3] rcv path changes for vrf traffic

On Mon, Jun 8, 2015 at 1:33 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> On Mon, Jun 8, 2015, at 22:22, Shrijeet Mukherjee wrote:
>> On Mon, Jun 8, 2015 at 12:58 PM, Hannes Frederic Sowa
>> <hannes@...essinduktion.org> wrote:
>> > Hi Shrijeet,
>> >
>> > This let's incoming and arp requests use routing table 100. The system
>> > will stop responding to arp requests as we don't have any entries in
>> > this routing table.
>>
>>
>> I like this model in general, as it addresses the issue that I have
>> not addressed around connected routes.
>>
>> This would force local and directly connected host routes to be learnt
>> into the correct table.
>>
>> It does bring the question up then.
>>
>> 1. The driver already knows the vrf device to table map
>> 2. If the device also knows the final device to table map
>>
>> then do we need to use fib_rules and just lookup the table directly.
>> It does make the configuration a little longer since each component
>> device now needs configuration when you add/del a member from a vrf.
>
> This model is usable on its own, especially if one does not need routing
> daemons
> or user space software dealing with VRFs and sending out packets.
>
>> If people generally agree and we want to skip the fib_rule lookup,
>> then I can make it such that enslaving already takes the dev-table id
>> as well, and then the process of enslaving in the nominal VRF case
>> becomes
>>
>> ip link add vrf-dev type vrf table foo ipv4-rt-table-id bar
>> ip link set eth2 master vrf-dev
>
> I think this would be great.
>
> Last time I looked into the patches it was not yet clear if we can do
> that
> without holding strong references to the other interfaces. Hopefully
> this can
> be done by just passing down the table ids to the slaves during
> initializing
> and teardown of the master vrf interface.
>
> Bye,
> Hannes

We can do that, and the hooks are all available. But do we want to cut
out the fib_rules ? this would close out the opportunity for someone
to insert a fib_rule to override the rule which directs to a VRF
device.

Personally don't have a strong opinion, but want to make sure we
understand that choice.
--
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