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:	Tue, 09 Jun 2015 07:41:10 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Shrijeet Mukherjee <shm@...ulusnetworks.com>
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 Tue, Jun 9, 2015, at 00:44, Shrijeet Mukherjee wrote:
> 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.

Hmm, wouldn't that still work with a target I added in my patch?

The only problem I see is that people might build up rules which are not
symmetric and thus vrf behavior differs from input and output path. One
addition to ease this is to add a interface selector which matches on
both, iif and oif. Also we must still keep in mind that rules are
matched linearly by using a list, hundreds of vrfs would thus first have
match hundreds of ip rules.

Bye,
Hannes
--
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